* Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Ard Biesheuvel @ 2019-08-21 7:29 UTC (permalink / raw)
To: Mike Rapoport
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
Russell King - ARM Linux admin, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190821071100.GA26713@rapoport-lnx>
On Wed, 21 Aug 2019 at 10:11, Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Wed, Aug 21, 2019 at 09:35:16AM +0300, Ard Biesheuvel wrote:
> > On Wed, 21 Aug 2019 at 09:11, Chester Lin <clin@suse.com> wrote:
> > >
> > > On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> > > > On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > On Fri, Aug 02, 2019 at 05:38:54AM +0000, Chester Lin wrote:
> > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > > --- a/arch/arm/mm/mmu.c
> > > > > > +++ b/arch/arm/mm/mmu.c
> > > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > > phys_addr_t block_start = reg->base;
> > > > > > phys_addr_t block_end = reg->base + reg->size;
> > > > > >
> > > > > > + if (memblock_is_nomap(reg))
> > > > > > + continue;
> > > > > > +
> > > > > > if (reg->base < vmalloc_limit) {
> > > > > > if (block_end > lowmem_limit)
> > > > > > /*
> > > > >
> > > > > I think this hunk is sane - if the memory is marked nomap, then it isn't
> > > > > available for the kernel's use, so as far as calculating where the
> > > > > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > > > > skipped.
> > > > >
> > > >
> > > > I agree.
> > > >
> > > > Chester, could you explain what you need beyond this change (and my
> > > > EFI stub change involving TEXT_OFFSET) to make things work on the
> > > > RPi2?
> > > >
> > >
> > > Hi Ard,
> > >
> > > In fact I am working with Guillaume to try booting zImage kernel and openSUSE
> > > from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, which is
> > > one of the test machines we have. However we want a better solution for all
> > > cases but not just RPi2 since we don't want to affect other platforms as well.
> > >
> >
> > Thanks Chester, but that doesn't answer my question.
> >
> > Your fix is a single patch that changes various things that are only
> > vaguely related. We have already identified that we need to take
> > TEXT_OFFSET (minus some space used by the swapper page tables) into
> > account into the EFI stub if we want to ensure compatibility with many
> > different platforms, and as it turns out, this applies not only to
> > RPi2 but to other platforms as well, most notably the ones that
> > require a TEXT_OFFSET of 0x208000, since they also have reserved
> > regions at the base of RAM.
> >
> > My question was what else we need beyond:
> > - the EFI stub TEXT_OFFSET fix [0]
> > - the change to disregard NOMAP memblocks in adjust_lowmem_bounds()
> > - what else???
>
> I think the only missing part here is to ensure that non-reserved memory in
> bank 0 starts from a PMD-aligned address. I believe this could be done if
> EFI stub, but I'm not really familiar with it so this just a semi-educated
> guess :)
>
Given that it is the ARM arch code that imposes this requirement, how
about adding something like this to adjust_lowmem_bounds():
if (memblock_start_of_DRAM() % PMD_SIZE)
memblock_mark_nomap(memblock_start_of_DRAM(),
PMD_SIZE - (memblock_start_of_DRAM() % PMD_SIZE));
(and introduce the nomap check into the loop)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] soc: ti: omap-prm: add dra7 PRM data
From: Tero Kristo @ 2019-08-21 7:36 UTC (permalink / raw)
To: Suman Anna, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <0e8aa351-4c58-ab6c-890f-094118b812ac@ti.com>
On 20.8.2019 22.03, Suman Anna wrote:
> Hi Tero,
>
> On 8/7/19 2:48 AM, Tero Kristo wrote:
>> Add PRM data for dra7 family of SoCs.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index fadfc7f..05b7749 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -73,6 +73,31 @@ struct omap_prm_data omap4_prm_data[] = {
>> { },
>> };
>>
>> +static struct omap_prm_data dra7_prm_data[] = {
>> + { .name = "mpu", .base = 0x4ae06300, .pwstst = 0x4 },
>> + { .name = "dsp1", .base = 0x4ae06400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
>> + { .name = "ipu", .base = 0x4ae06500, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14, .clkdm_name = "ipu1" },
>> + { .name = "coreaon", .base = 0x4ae06628, .pwstst = 0x4 },
>
> Public TRM marks this region Reserved. Do you need it for anything?
This is copied from existing PRM data from kernel. However, I'll ditch
these for now and only retain the reset enabled domains.
>
>> + { .name = "core", .base = 0x4ae06700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214, .clkdm_name = "ipu2" },
>> + { .name = "iva", .base = 0x4ae06f00, .pwstst = 0x4 },
>
> Missing rstctrl and rstst offsets.
Will add.
>
>> + { .name = "cam", .base = 0x4ae07000, .pwstst = 0x4 },
>> + { .name = "dss", .base = 0x4ae07100, .pwstst = 0x4 },
>> + { .name = "gpu", .base = 0x4ae07200, .pwstst = 0x4 },
>> + { .name = "l3init", .base = 0x4ae07300, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
>> + { .name = "l4per", .base = 0x4ae07400, .pwstst = 0x4 },
>> + { .name = "custefuse", .base = 0x4ae07600, .pwstst = 0x4 },
>> + { .name = "wkupaon", .base = 0x4ae07724, .pwstst = 0x4 },
>
> No pwstctrl and pwstst bits documented in TRM or are marked reserved.
Same as coreaon.
>
>> + { .name = "emu", .base = 0x4ae07900, .pwstst = 0x4 },
>> + { .name = "dsp2", .base = 0x4ae07b00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
>> + { .name = "eve1", .base = 0x4ae07b40, .pwstst = 0x4 },
>> + { .name = "eve2", .base = 0x4ae07b80, .pwstst = 0x4 },
>> + { .name = "eve3", .base = 0x4ae07bc0, .pwstst = 0x4 },
>> + { .name = "eve4", .base = 0x4ae07c00, .pwstst = 0x4 },
>
> All EVEs are missing rstctrl and rstst fields.
Will add.
>
>> + { .name = "rtc", .base = 0x4ae07c60, .pwstst = 0x4 },
>
> Undocumented pwstctrl and pwstst registers.
>
>> + { .name = "vpe", .base = 0x4ae07c80, .pwstst = 0x4 },
>
> Missing "device" and "instr" PRM. The latter doesn't have any pwrstctl
> and pwrstst though.
Will ditch those.
-Tero
>
> regards
> Suman
>
>> + { },
>> +};
>> +
>> struct omap_rst_map am3_wkup_rst_map[] = {
>> { .rst = 3, .st = 5 },
>> { .rst = -1 },
>> @@ -91,6 +116,7 @@ struct omap_prm_data am3_prm_data[] = {
>>
>> static const struct of_device_id omap_prm_id_table[] = {
>> { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
>> + { .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
>> { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
>> { },
>> };
>>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Krzysztof Kozlowski @ 2019-08-21 7:49 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
linux-pm, vireshk, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
Sylwester Nawrocki, pankaj.dubey, linux-tegra, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <1e428c8e-f4b5-0810-77f9-2c899c040fc7@kernel.org>
On Tue, 20 Aug 2019 at 23:38, Sylwester Nawrocki <snawrocki@kernel.org> wrote:
>
> On 8/20/19 21:37, Krzysztof Kozlowski wrote:
> >>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
>
> >>> @@ -51,29 +48,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
> >>> int __init exynos_chipid_early_init(void)
> >>> {
> >>> struct soc_device_attribute *soc_dev_attr;
> >>> - void __iomem *exynos_chipid_base;
> >>> struct soc_device *soc_dev;
> >>> struct device_node *root;
> >>> - struct device_node *np;
> >>> + struct regmap *regmap;
> >>> u32 product_id;
> >>> u32 revision;
> >>> + int ret;
> >>>
> >>> - /* look up for chipid node */
> >>> - np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
> >>> - if (!np)
> >>> - return -ENODEV;
> >>> -
> >>> - exynos_chipid_base = of_iomap(np, 0);
> >>> - of_node_put(np);
> >>> -
> >>> - if (!exynos_chipid_base) {
> >>> - pr_err("Failed to map SoC chipid\n");
> >>> - return -ENXIO;
> >>> + regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
> >>> + if (IS_ERR(regmap)) {
> >>> + pr_err("Failed to get CHIPID regmap\n");
> >>> + return PTR_ERR(regmap);
> >>> }
> >> Following this change, I am now seeing the above error on our Tegra
> >> boards where this driver is enabled. This is triggering a kernel
> >> warnings test we have to fail. Hence, I don't think that you can remove
> >> the compatible node test here, unless you have a better way to determine
> >> if this is a samsung device.
> >
> > Right, this is really wrong... I missed that it is not a probe but
> > early init. And this init will be called on every board... Probably it
> > should be converted to a regular driver.
>
> I'm also inclined to have it converted to a regular driver. We already
> have "exynos-asv" driver matching on the chipid node (patch 3/9).
> The ASV patches will not be merged soon anyway, all this needs some more
> thought. Krzysztof, can we abandon the chipid patches for now? Your
> pull request doesn't appear to be merged to arm-soc yet. Sorry about
> that.
Yes, let's abandon the pull request and rework the concept.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/3] soc: samsung: Exynos for v5.4
From: Krzysztof Kozlowski @ 2019-08-21 7:51 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-kernel@vger.kernel.org, linux-arm-kernel
In-Reply-To: <20190816163042.6604-1-krzk@kernel.org>
On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.4
>
> for you to fetch changes up to 40d8aff614f71ab3cab20785b4f213e3802d4e87:
>
> soc: samsung: chipid: Convert exynos-chipid driver to use the regmap API (2019-08-15 20:25:25 +0200)
>
> ----------------------------------------------------------------
> Samsung soc drivers changes for v5.4
>
> Add Exynos Chipid driver for identification of product IDs and SoC
> revisions. The driver also exposes chipid regmap, later to be used by
> Exynos Adaptive Supply Voltage driver (adjusting voltages to different
> revisions of same SoC).
It turns out that it brings troubles (code is executed on every
platform polluting logs because it is an initcall, not a driver) so
Sylwester (submitter) asked to skip the submission.
Please ignore the pull request.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 3/3] ARM: dts: exynos: DT for v5.4
From: Krzysztof Kozlowski @ 2019-08-21 7:51 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-kernel@vger.kernel.org, linux-arm-kernel
In-Reply-To: <20190816163042.6604-2-krzk@kernel.org>
On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.4
>
> for you to fetch changes up to bfb77169306d5d560a8b62eebaf6d69d02e8d152:
>
> ARM: dts: exynos: Add CAM power domain to Exynos5422/5800 (2019-08-12 19:02:59 +0200)
>
> ----------------------------------------------------------------
> Samsung DTS ARM changes for v5.4
>
> 1. Add AHCI to Exynos5250,
> 2. Add camera and GPU power domains to Exynos5422,
> 3. Minor cleanup.
Just a reminder - this one pull request is good to go. No changes needed.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] ARM: samsung: mach for v5.4
From: Krzysztof Kozlowski @ 2019-08-21 7:52 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-kernel@vger.kernel.org, linux-arm-kernel
In-Reply-To: <20190816163042.6604-3-krzk@kernel.org>
On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.4
>
> for you to fetch changes up to 1fa70c7f49132513fb0da4afa7643395eedc7d35:
>
> ARM: exynos: Enable exynos-chipid driver (2019-08-15 20:29:58 +0200)
>
> ----------------------------------------------------------------
> Samsung mach/soc changes for v5.4
>
> 1. Minor fixup in plat code (S3C platforms),
> 2. Enable exynos-chipid driver to provide SoC related information.
>
> ----------------------------------------------------------------
> Linus Walleij (1):
> ARM: samsung: Include GPIO driver header
>
> Pankaj Dubey (1):
> ARM: exynos: Enable exynos-chipid driver
This last patch should be dropped so I will rework the pull request
and send later v2. Please ignore it for now.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] dm crypt: support diskcipher
From: boojin.kim @ 2019-08-21 7:54 UTC (permalink / raw)
To: 'Mike Snitzer'
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc, 'Herbert Xu',
'Krzysztof Kozlowski', 'Jaehoon Chung',
'Kukjin Kim', linux-ext4, 'Chao Yu', linux-block,
linux-fscrypt, 'Jaegeuk Kim', linux-arm-kernel,
'Jens Axboe', 'Theodore Ts'o', linux-mmc,
linux-kernel, linux-f2fs-devel, linux-crypto, linux-fsdevel,
'David S. Miller'
In-Reply-To: <CGME20190821075432epcas2p3758bf7b07f209fb4094d79bf46c8f4e9@epcas2p3.samsung.com>
On Wed, Aug 21, 2019 at 09:13:36AM +0200, Milan Broz wrote:
>
> NACK.
>
> The whole principle of dm-crypt target is that it NEVER EVER submits
> plaintext data down the stack in bio.
>
> If you want to do some lower/higher layer encryption, use key management
> on a different layer.
> So here, just setup encryption for fs, do not stack it with dm-crypt.
>
> Also, dm-crypt is software-independent solution
> (software-based full disk encryption), it must not depend on
> any underlying hardware.
> Hardware can be of course used used for acceleration, but then
> just implement proper crypto API module that accelerates particular
cipher.
I'm sorry for breaking the basic rules of dm-crypt.
But, if I want to use the H/W crypto accelerator running in storage
controller,
I have to drop plaintext to bio.
I think the "proper crypto API module" that you mentioned is diskcipher
because diskcipher isn't only for FMP.
Diskcipher is a crypto API that supports encryption on storage controllers.
Thanks
Boojin Kim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] dm crypt: support diskcipher
From: boojin.kim @ 2019-08-21 7:57 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc, 'Herbert Xu',
'Krzysztof Kozlowski', 'Jaehoon Chung',
'Kukjin Kim', linux-ext4, 'Chao Yu', linux-block,
linux-fscrypt, 'Jaegeuk Kim', linux-arm-kernel,
'Jens Axboe', 'Theodore Ts'o', linux-mmc,
linux-kernel, linux-f2fs-devel, linux-crypto, linux-fsdevel,
'David S. Miller'
In-Reply-To: <CGME20190821075742epcas2p4b9104e8249067c048d4050f2888da0a9@epcas2p4.samsung.com>
On Wed, Aug 21, 2019 at 09:35:36AM +0200, Herbert Xu Herbert wrote:
> I agree. Please take a look at the recent ESSIV patches on
> linux-crypto and build multi-block operations on top of them
> which can then be implemented by the hardware.
>
> Cheers,
Can you tell me which patch you mentioned? Is this?
https://patches.linaro.org/project/linux-crypto/list/?series=22762
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/3] soc: ti: k3: Allow for exclusive and shared device requests
From: santosh.shilimkar @ 2019-08-21 8:06 UTC (permalink / raw)
To: Lokesh Vutla, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Rob Herring
Cc: Device Tree Mailing List, Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <05218f41-9601-9a6c-8ac1-3bf1482e1c3d@ti.com>
On 8/20/19 2:48 PM, Lokesh Vutla wrote:
>
>
> On 29/07/19 5:54 PM, Lokesh Vutla wrote:
>> Sysfw provides an option for requesting exclusive access for a
>> device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
>> not used, the device is meant to be shared across hosts. Once a device
>> is requested from a host with this flag set, any request to this
>> device from a different host will be nacked by sysfw.
>>
>> Current tisci firmware and pm drivers always requests for device with
>> exclusive permissions set. But this is not be true for certain devices
>> that are expcted to be shared across different host contexts.
>> So add support for getting the shared or exclusive permissions from DT
>> and request firmware accordingly.
>
> Gentle Ping on this series.
>
I can queue this up.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: arm: fsl: add Hummingboard Pulse
From: Baruch Siach @ 2019-08-21 8:20 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: Baruch Siach, Marco Felsch, linux-arm-kernel
In-Reply-To: <250bf15602801b09a1c1e6d286d0eb125029fd49.1566375619.git.baruch@tkos.co.il>
Add binding documentation for the SolidRun Hummingboard Pulse board.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v4: No change
v3: No change
v2: New patch suggested by Fabio
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..14ca94928677 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -219,6 +219,7 @@ properties:
- enum:
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
+ - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- const: fsl,imx8mq
- description: i.MX8QXP based Boards
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/2] arm64: dts: fsl: add support for Hummingboard Pulse
From: Baruch Siach @ 2019-08-21 8:20 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: Baruch Siach, Jon Nettleton, Marco Felsch, linux-arm-kernel
From: Jon Nettleton <jon@solid-run.com>
The SolidRun Hummingboard Pulse carrier board carries the SolidRun
i.MX8MQ based SOM.
Notably missing is PCIe support that depends on analog PLLOUT clock.
Current imx clk driver does not support this clock.
Signed-off-by: Jon Nettleton <jon@solid-run.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v4:
Address Shawn's comments:
- Normalize PDO_FIXED() arguments indentation
- Keep status property last
- Fix alphabetical order of nodes
v3:
Fix SD card power regulator enable gpio
Address Marco's comments:
- Reorder pinctrl properties
- Move imx8mq.dtsi include to the SOM .dtsi
- Add reg_ prefix to regulator labels
- Add pinctrl node to SD card regulator gpio
- Add label to SPI flash node
v2: Address Fabio's comments:
- Remove redundant node nesting
- Fix comments style
- Use mainline DT bindings in UART and USB type C
- Fix node names
- Move &iomuxc to the end of file
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mq-hummingboard-pulse.dts | 256 +++++++++++++++
.../boot/dts/freescale/imx8mq-sr-som.dtsi | 309 ++++++++++++++++++
3 files changed, 566 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c043aca66572..6833b23e2dd2 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
new file mode 100644
index 000000000000..f52e872ac96f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/usb/pd.h"
+#include "imx8mq-sr-som.dtsi"
+
+/ {
+ model = "SolidRun i.MX8MQ HummingBoard Pulse";
+ compatible = "solidrun,hummingboard-pulse", "fsl,imx8mq";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 13 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_v_5v0: regulator-v-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "v_5v0";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ typec_ptn5100: usb-typec@50 {
+ compatible = "nxp,ptn5110";
+ reg = <0x50>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)>;
+ sink-pdos = <PDO_FIXED(5000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)
+ PDO_FIXED(9000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)>;
+ op-sink-microwatt = <9000000>;
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ rtc@69 {
+ compatible = "abracon,ab1805";
+ reg = <0x69>;
+ abracon,tc-diode = "schottky";
+ abracon,tc-resistor = <3>;
+ };
+};
+
+&uart2 { /* J35 header */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&uart3 { /* Mikrobus */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ dr_mode = "otg";
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MikroBus Analog */
+ MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x41
+ /* MikroBus Reset */
+ MX8MQ_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x41
+ /*
+ * The following 2 pins need to be commented out and
+ * reconfigured to enable RTS/CTS on UART3
+ */
+ /* MikroBus PWM */
+ MX8MQ_IOMUXC_ECSPI1_MISO_GPIO5_IO8 0x41
+ /* MikroBus INT */
+ MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x41
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_typec: typecgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x16
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x17059
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ /*
+ * These pins are by default GPIO on the Mikro Bus
+ * Header. To use RTS/CTS on UART3 comment them out
+ * of the hoggrp and enable them here
+ */
+ /* MX8MQ_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x49 */
+ /* MX8MQ_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x49 */
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO12 0x41
+ >;
+ };
+
+ pinctrl_usdhc2_vmmc: usdhc2vmmcgpio {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x41
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xdf
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xdf
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xdf
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xdf
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xdf
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
new file mode 100644
index 000000000000..d7f03c65832b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+#include "imx8mq.dtsi"
+
+/ {
+ reg_vdd_3v3: regulator-vdd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <2>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ };
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ pmic: pmic@8 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3ab {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ regulator-always-on;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+};
+
+&pgc_gpu{
+ power-supply = <&sw1a_reg>;
+};
+
+&pgc_vpu {
+ power-supply = <&sw1c_reg>;
+};
+
+&qspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "okay";
+
+ /* SPI flash; not assembled by default */
+ spi_flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <29000000>;
+ status = "disabled";
+ };
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ assigned-clock-rates = <25000000>;
+ status = "okay";
+};
+
+&uart4 { /* ublox BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ assigned-clock-rates = <80000000>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MQ_IOMUXC_ENET_MDIO_ENET1_MDIO 0x23
+ MX8MQ_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MQ_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MQ_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MQ_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MQ_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MQ_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MQ_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MQ_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MQ_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MQ_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MQ_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MQ_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x74
+ MX8MQ_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0x16
+ MX8MQ_IOMUXC_SAI2_RXFS_GPIO4_IO21 0x16
+ >;
+ };
+
+ pinctrl_qspi: qspigrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_ALE_QSPI_A_SCLK 0x82
+ MX8MQ_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B 0x82
+ MX8MQ_IOMUXC_NAND_DATA00_QSPI_A_DATA0 0x82
+ MX8MQ_IOMUXC_NAND_DATA01_QSPI_A_DATA1 0x82
+ MX8MQ_IOMUXC_NAND_DATA02_QSPI_A_DATA2 0x82
+ MX8MQ_IOMUXC_NAND_DATA03_QSPI_A_DATA3 0x82
+
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
+ MX8MQ_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x19
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART4_TXD_UART4_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART4_RXD_UART4_DCE_RX 0x49
+ MX8MQ_IOMUXC_SAI3_TXD_GPIO5_IO1 0x19
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: irq: Convert Allwinner IRQ Controller to a schema
From: Maxime Ripard @ 2019-08-21 8:21 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Frank Rowand, tglx, jason, maz
Cc: Maxime Ripard, devicetree, Chen-Yu Tsai, Maxime Ripard,
linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner SoCs have an interrupt controller supported in Linux, with a
matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Remove Fixme and add additionalProperties to false
- Add unit address for the example
---
.../allwinner,sun4i-a10-ic.yaml | 47 +++++++++++++++++++
.../allwinner,sun4i-ic.txt | 20 --------
2 files changed, 47 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
new file mode 100644
index 000000000000..23a202d24e43
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-a10-ic.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun4i-a10-ic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A10 Interrupt Controller Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ "#interrupt-cells":
+ const: 1
+
+ compatible:
+ enum:
+ - allwinner,sun4i-a10-ic
+ - allwinner,suniv-f1c100s-ic
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+required:
+ - "#interrupt-cells"
+ - compatible
+ - reg
+ - interrupt-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ intc: interrupt-controller@1c20400 {
+ compatible = "allwinner,sun4i-a10-ic";
+ reg = <0x01c20400 0x400>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
deleted file mode 100644
index 404352524c3a..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Allwinner Sunxi Interrupt Controller
-
-Required properties:
-
-- compatible : should be one of the following:
- "allwinner,sun4i-a10-ic"
- "allwinner,suniv-f1c100s-ic"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 1.
-
-Example:
-
-intc: interrupt-controller {
- compatible = "allwinner,sun4i-a10-ic";
- reg = <0x01c20400 0x400>;
- interrupt-controller;
- #interrupt-cells = <1>;
-};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] dt-bindings: irq: Convert Allwinner NMI Controller to a schema
From: Maxime Ripard @ 2019-08-21 8:21 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Frank Rowand, tglx, jason, maz
Cc: Maxime Ripard, devicetree, Chen-Yu Tsai, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <20190821082138.11049-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner SoCs have an interrupt controller called NMI supported in
Linux, with a matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Changes from v1:
- Remove the custom select and rely on the deprecated property instead
---
.../allwinner,sun7i-a20-sc-nmi.yaml | 70 +++++++++++++++++++
.../allwinner,sunxi-nmi.txt | 29 --------
2 files changed, 70 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
new file mode 100644
index 000000000000..0eccf5551786
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
+
+maintainers:
+ - Chen-Yu Tsai <wens@csie.org>
+ - Maxime Ripard <maxime.ripard@bootlin.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ "#interrupt-cells":
+ const: 2
+ description:
+ The first cell is the IRQ number, the second cell the trigger
+ type as defined in interrupt.txt in this directory.
+
+ compatible:
+ oneOf:
+ - const: allwinner,sun6i-a31-r-intc
+ - const: allwinner,sun6i-a31-sc-nmi
+ deprecated: true
+ - const: allwinner,sun7i-a20-sc-nmi
+ - items:
+ - const: allwinner,sun8i-a83t-r-intc
+ - const: allwinner,sun6i-a31-r-intc
+ - const: allwinner,sun9i-a80-sc-nmi
+ - items:
+ - const: allwinner,sun50i-a64-r-intc
+ - const: allwinner,sun6i-a31-r-intc
+ - items:
+ - const: allwinner,sun50i-h6-r-intc
+ - const: allwinner,sun6i-a31-r-intc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+required:
+ - "#interrupt-cells"
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+
+# FIXME: We should set it, but it would report all the generic
+# properties as additional properties.
+# additionalProperties: false
+
+examples:
+ - |
+ interrupt-controller@1c00030 {
+ compatible = "allwinner,sun7i-a20-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01c00030 0x0c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 0 4>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
deleted file mode 100644
index 24beadf7ba83..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Allwinner Sunxi NMI Controller
-==============================
-
-Required properties:
-
-- compatible : should be one of the following:
- - "allwinner,sun7i-a20-sc-nmi"
- - "allwinner,sun6i-a31-sc-nmi" (deprecated)
- - "allwinner,sun6i-a31-r-intc"
- - "allwinner,sun9i-a80-nmi"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
- interrupt source. The value shall be 2. The first cell is the IRQ number, the
- second cell the trigger type as defined in interrupt.txt in this directory.
-- interrupts: Specifies the interrupt line (NMI) which is handled by
- the interrupt controller in the parent controller's notation. This value
- shall be the NMI.
-
-Example:
-
-sc-nmi-intc@1c00030 {
- compatible = "allwinner,sun7i-a20-sc-nmi";
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x01c00030 0x0c>;
- interrupt-parent = <&gic>;
- interrupts = <0 0 4>;
-};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Mike Rapoport @ 2019-08-21 8:29 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
Russell King - ARM Linux admin, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu99z3V1B68CU8qhNwwffqDxNBOM6t3Q8-V7qpbDkf-Cwg@mail.gmail.com>
On Wed, Aug 21, 2019 at 10:29:37AM +0300, Ard Biesheuvel wrote:
> On Wed, 21 Aug 2019 at 10:11, Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Wed, Aug 21, 2019 at 09:35:16AM +0300, Ard Biesheuvel wrote:
> > > On Wed, 21 Aug 2019 at 09:11, Chester Lin <clin@suse.com> wrote:
> > > >
> > > > On Tue, Aug 20, 2019 at 03:28:25PM +0300, Ard Biesheuvel wrote:
> > > > > On Tue, 20 Aug 2019 at 14:56, Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > >
> > > > > > On Fri, Aug 02, 2019 at 05:38:54AM +0000, Chester Lin wrote:
> > > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > > > --- a/arch/arm/mm/mmu.c
> > > > > > > +++ b/arch/arm/mm/mmu.c
> > > > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > > > phys_addr_t block_start = reg->base;
> > > > > > > phys_addr_t block_end = reg->base + reg->size;
> > > > > > >
> > > > > > > + if (memblock_is_nomap(reg))
> > > > > > > + continue;
> > > > > > > +
> > > > > > > if (reg->base < vmalloc_limit) {
> > > > > > > if (block_end > lowmem_limit)
> > > > > > > /*
> > > > > >
> > > > > > I think this hunk is sane - if the memory is marked nomap, then it isn't
> > > > > > available for the kernel's use, so as far as calculating where the
> > > > > > lowmem/highmem boundary is, it effectively doesn't exist and should be
> > > > > > skipped.
> > > > > >
> > > > >
> > > > > I agree.
> > > > >
> > > > > Chester, could you explain what you need beyond this change (and my
> > > > > EFI stub change involving TEXT_OFFSET) to make things work on the
> > > > > RPi2?
> > > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > In fact I am working with Guillaume to try booting zImage kernel and openSUSE
> > > > from grub2.04 + arm32-efistub so that's why we get this issue on RPi2, which is
> > > > one of the test machines we have. However we want a better solution for all
> > > > cases but not just RPi2 since we don't want to affect other platforms as well.
> > > >
> > >
> > > Thanks Chester, but that doesn't answer my question.
> > >
> > > Your fix is a single patch that changes various things that are only
> > > vaguely related. We have already identified that we need to take
> > > TEXT_OFFSET (minus some space used by the swapper page tables) into
> > > account into the EFI stub if we want to ensure compatibility with many
> > > different platforms, and as it turns out, this applies not only to
> > > RPi2 but to other platforms as well, most notably the ones that
> > > require a TEXT_OFFSET of 0x208000, since they also have reserved
> > > regions at the base of RAM.
> > >
> > > My question was what else we need beyond:
> > > - the EFI stub TEXT_OFFSET fix [0]
> > > - the change to disregard NOMAP memblocks in adjust_lowmem_bounds()
> > > - what else???
> >
> > I think the only missing part here is to ensure that non-reserved memory in
> > bank 0 starts from a PMD-aligned address. I believe this could be done if
> > EFI stub, but I'm not really familiar with it so this just a semi-educated
> > guess :)
> >
>
> Given that it is the ARM arch code that imposes this requirement, how
> about adding something like this to adjust_lowmem_bounds():
>
> if (memblock_start_of_DRAM() % PMD_SIZE)
> memblock_mark_nomap(memblock_start_of_DRAM(),
> PMD_SIZE - (memblock_start_of_DRAM() % PMD_SIZE));
memblock_start_of_DRAM() won't work here, as it returns the actual start of
the DRAM including NOMAP regions. Moreover, as we cannot mark a region
NOMAP inside for_each_memblock() this should be done beforehand.
I think something like this could work:
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 2f0f07e..f2b635b 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1178,6 +1178,19 @@ void __init adjust_lowmem_bounds(void)
*/
vmalloc_limit = (u64)(uintptr_t)vmalloc_min - PAGE_OFFSET + PHYS_OFFSET;
+ /*
+ * The first usable region must be PMD aligned. Mark its start
+ * as MEMBLOCK_NOMAP if it isn't
+ */
+ for_each_memblock(memory, reg) {
+ if (!memblock_is_nomap(reg) && (reg->base % PMD_SIZE)) {
+ phys_addr_t size = PMD_SIZE - (reg->base % PMD_SIZE);
+
+ memblock_mark_nomap(reg->base, size);
+ break;
+ }
+ }
+
for_each_memblock(memory, reg) {
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
> (and introduce the nomap check into the loop)
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: renesas: r8a774a1: sort nodes
From: Simon Horman @ 2019-08-21 8:30 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <1566219295-23003-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 09:54:55PM +0900, Yoshihiro Kaneko wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/9] dm crypt: support diskcipher
From: Herbert Xu @ 2019-08-21 8:17 UTC (permalink / raw)
To: boojin.kim
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc,
'Krzysztof Kozlowski', 'Jaehoon Chung',
'Kukjin Kim', linux-ext4, 'Chao Yu', linux-block,
linux-fscrypt, 'Jaegeuk Kim', linux-arm-kernel,
'Jens Axboe', 'Theodore Y. Ts'o', linux-mmc,
linux-kernel, linux-f2fs-devel, linux-crypto, linux-fsdevel,
'David S. Miller'
In-Reply-To: <001b01d557f6$1c49fd40$54ddf7c0$@samsung.com>
On Wed, Aug 21, 2019 at 04:57:41PM +0900, boojin.kim wrote:
>
> Can you tell me which patch you mentioned? Is this?
> https://patches.linaro.org/project/linux-crypto/list/?series=22762
Yes this is the one.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774c0-cat874: sort nodes
From: Simon Horman @ 2019-08-21 8:41 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <1566219341-23048-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 09:55:41PM +0900, Yoshihiro Kaneko wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Thanks Kaneko-san,
I think that the i2c1_pins and hscif2_pins nodes
are also out of order.
I'm not sure if Geert would prefer you to respin or fix that himself.
In any case, with that problem resolved:
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> This patch is based on the master branch of Geert Uytterhoeven's renesas-devel
> tree.
>
> arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
> index 651383c..aaa37158 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts
> @@ -82,13 +82,13 @@
> simple-audio-card,bitclock-master = <&sndcpu>;
> simple-audio-card,frame-master = <&sndcpu>;
>
> - sndcpu: simple-audio-card,cpu {
> - sound-dai = <&rcar_sound>;
> - };
> -
> sndcodec: simple-audio-card,codec {
> sound-dai = <&tda19988>;
> };
> +
> + sndcpu: simple-audio-card,cpu {
> + sound-dai = <&rcar_sound>;
> + };
> };
>
> vcc_sdhi0: regulator-vcc-sdhi0 {
> @@ -313,16 +313,16 @@
> power-source = <1800>;
> };
>
> - sound_pins: sound {
> - groups = "ssi01239_ctrl", "ssi0_data";
> - function = "ssi";
> - };
> -
> sound_clk_pins: sound_clk {
> groups = "audio_clkout1_a";
> function = "audio_clk";
> };
>
> + sound_pins: sound {
> + groups = "ssi01239_ctrl", "ssi0_data";
> + function = "ssi";
> + };
> +
> usb30_pins: usb30 {
> groups = "usb30", "usb30_id";
> function = "usb30";
> --
> 1.9.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774c0-cat874: sort nodes
From: Geert Uytterhoeven @ 2019-08-21 8:42 UTC (permalink / raw)
To: Yoshihiro Kaneko; +Cc: Linux-Renesas, Simon Horman, Magnus Damm, Linux ARM
In-Reply-To: <1566219341-23048-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 2:55 PM Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774c0: sort nodes
From: Simon Horman @ 2019-08-21 8:46 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <1566219361-23088-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 09:56:01PM +0900, Yoshihiro Kaneko wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774c0-cat874: sort nodes
From: Geert Uytterhoeven @ 2019-08-21 8:46 UTC (permalink / raw)
To: Simon Horman; +Cc: Linux-Renesas, Magnus Damm, Yoshihiro Kaneko, Linux ARM
In-Reply-To: <20190821084101.evn6xeiqcqv772um@verge.net.au>
On Wed, Aug 21, 2019 at 10:41 AM Simon Horman <horms@verge.net.au> wrote:
> On Mon, Aug 19, 2019 at 09:55:41PM +0900, Yoshihiro Kaneko wrote:
> > Sort nodes.
> >
> > If node address is present
> > * Sort by node address, grouping all nodes with the same compat string
> > and sorting the group alphabetically.
> > Else
> > * Sort alphabetically
> >
> > This should not have any run-time effect.
> >
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> Thanks Kaneko-san,
>
> I think that the i2c1_pins and hscif2_pins nodes
> are also out of order.
You're right.
> I'm not sure if Geert would prefer you to respin or fix that himself.
Will fix myself.
> In any case, with that problem resolved:
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774a1: sort nodes
From: Geert Uytterhoeven @ 2019-08-21 8:53 UTC (permalink / raw)
To: Yoshihiro Kaneko; +Cc: Linux-Renesas, Simon Horman, Magnus Damm, Linux ARM
In-Reply-To: <1566219295-23003-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 2:55 PM Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a7796: sort nodes
From: Simon Horman @ 2019-08-21 8:57 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <1566219378-23126-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 09:56:18PM +0900, Yoshihiro Kaneko wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Sorry, I feel that I have missed this in other review's too,
but, isn't canfd out of order. Its bus address seems to place it
before dmac0. Or do we prefer to keep it grouped with the can nodes?
The above notwithstanding,
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> This patch is based on the master branch of Geert Uytterhoeven's renesas-devel
> tree.
>
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 152 +++++++++++++++----------------
> 1 file changed, 76 insertions(+), 76 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index 26df5b8..3dc9d73 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -1833,6 +1833,17 @@
> "ssi.1", "ssi.0";
> status = "disabled";
>
> + rcar_sound,ctu {
> + ctu00: ctu-0 { };
> + ctu01: ctu-1 { };
> + ctu02: ctu-2 { };
> + ctu03: ctu-3 { };
> + ctu10: ctu-4 { };
> + ctu11: ctu-5 { };
> + ctu12: ctu-6 { };
> + ctu13: ctu-7 { };
> + };
> +
> rcar_sound,dvc {
> dvc0: dvc-0 {
> dmas = <&audma1 0xbc>;
> @@ -1849,17 +1860,6 @@
> mix1: mix-1 { };
> };
>
> - rcar_sound,ctu {
> - ctu00: ctu-0 { };
> - ctu01: ctu-1 { };
> - ctu02: ctu-2 { };
> - ctu03: ctu-3 { };
> - ctu10: ctu-4 { };
> - ctu11: ctu-5 { };
> - ctu12: ctu-6 { };
> - ctu13: ctu-7 { };
> - };
> -
> rcar_sound,src {
> src0: src-0 {
> interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1913,6 +1913,59 @@
> };
> };
>
> + rcar_sound,ssi {
> + ssi0: ssi-0 {
> + interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x01>, <&audma1 0x02>;
> + dma-names = "rx", "tx";
> + };
> + ssi1: ssi-1 {
> + interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x03>, <&audma1 0x04>;
> + dma-names = "rx", "tx";
> + };
> + ssi2: ssi-2 {
> + interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x05>, <&audma1 0x06>;
> + dma-names = "rx", "tx";
> + };
> + ssi3: ssi-3 {
> + interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x07>, <&audma1 0x08>;
> + dma-names = "rx", "tx";
> + };
> + ssi4: ssi-4 {
> + interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x09>, <&audma1 0x0a>;
> + dma-names = "rx", "tx";
> + };
> + ssi5: ssi-5 {
> + interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x0b>, <&audma1 0x0c>;
> + dma-names = "rx", "tx";
> + };
> + ssi6: ssi-6 {
> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x0d>, <&audma1 0x0e>;
> + dma-names = "rx", "tx";
> + };
> + ssi7: ssi-7 {
> + interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x0f>, <&audma1 0x10>;
> + dma-names = "rx", "tx";
> + };
> + ssi8: ssi-8 {
> + interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x11>, <&audma1 0x12>;
> + dma-names = "rx", "tx";
> + };
> + ssi9: ssi-9 {
> + interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&audma0 0x13>, <&audma1 0x14>;
> + dma-names = "rx", "tx";
> + };
> + };
> +
> rcar_sound,ssiu {
> ssiu00: ssiu-0 {
> dmas = <&audma0 0x15>, <&audma1 0x16>;
> @@ -2123,59 +2176,6 @@
> dma-names = "rx", "tx";
> };
> };
> -
> - rcar_sound,ssi {
> - ssi0: ssi-0 {
> - interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x01>, <&audma1 0x02>;
> - dma-names = "rx", "tx";
> - };
> - ssi1: ssi-1 {
> - interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x03>, <&audma1 0x04>;
> - dma-names = "rx", "tx";
> - };
> - ssi2: ssi-2 {
> - interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x05>, <&audma1 0x06>;
> - dma-names = "rx", "tx";
> - };
> - ssi3: ssi-3 {
> - interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x07>, <&audma1 0x08>;
> - dma-names = "rx", "tx";
> - };
> - ssi4: ssi-4 {
> - interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x09>, <&audma1 0x0a>;
> - dma-names = "rx", "tx";
> - };
> - ssi5: ssi-5 {
> - interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x0b>, <&audma1 0x0c>;
> - dma-names = "rx", "tx";
> - };
> - ssi6: ssi-6 {
> - interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x0d>, <&audma1 0x0e>;
> - dma-names = "rx", "tx";
> - };
> - ssi7: ssi-7 {
> - interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x0f>, <&audma1 0x10>;
> - dma-names = "rx", "tx";
> - };
> - ssi8: ssi-8 {
> - interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x11>, <&audma1 0x12>;
> - dma-names = "rx", "tx";
> - };
> - ssi9: ssi-9 {
> - interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
> - dmas = <&audma0 0x13>, <&audma1 0x14>;
> - dma-names = "rx", "tx";
> - };
> - };
> };
>
> audma0: dma-controller@ec700000 {
> @@ -2860,6 +2860,18 @@
> thermal-sensors = <&tsc 2>;
> sustainable-power = <3874>;
>
> + cooling-maps {
> + map0 {
> + trip = <&target>;
> + cooling-device = <&a57_0 2 4>;
> + contribution = <1024>;
> + };
> + map1 {
> + trip = <&target>;
> + cooling-device = <&a53_0 0 2>;
> + contribution = <1024>;
> + };
> + };
> trips {
> target: trip-point1 {
> temperature = <100000>;
> @@ -2873,18 +2885,6 @@
> type = "critical";
> };
> };
> - cooling-maps {
> - map0 {
> - trip = <&target>;
> - cooling-device = <&a57_0 2 4>;
> - contribution = <1024>;
> - };
> - map1 {
> - trip = <&target>;
> - cooling-device = <&a53_0 0 2>;
> - contribution = <1024>;
> - };
> - };
> };
> };
>
> --
> 1.9.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a774c0: sort nodes
From: Geert Uytterhoeven @ 2019-08-21 8:57 UTC (permalink / raw)
To: Yoshihiro Kaneko; +Cc: Linux-Renesas, Simon Horman, Magnus Damm, Linux ARM
In-Reply-To: <1566219361-23088-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 2:56 PM Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a77970: sort nodes
From: Simon Horman @ 2019-08-21 9:00 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <1566219393-23169-1-git-send-email-ykaneko0929@gmail.com>
On Mon, Aug 19, 2019 at 09:56:33PM +0900, Yoshihiro Kaneko wrote:
> Sort nodes.
>
> If node address is present
> * Sort by node address, grouping all nodes with the same compat string
> and sorting the group alphabetically.
> Else
> * Sort alphabetically
>
> This should not have any run-time effect.
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> This patch is based on the master branch of Geert Uytterhoeven's renesas-devel
> tree.
>
> arch/arm64/boot/dts/renesas/r8a77970.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> index 5b6164d..0cd3b37 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> @@ -1181,6 +1181,9 @@
> polling-delay = <1000>;
> thermal-sensors = <&thermal>;
>
> + cooling-maps {
> + };
> +
> trips {
> cpu-crit {
> temperature = <120000>;
> @@ -1188,9 +1191,6 @@
> type = "critical";
> };
> };
> -
> - cooling-maps {
> - };
> };
> };
>
> --
> 1.9.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a7796: sort nodes
From: Geert Uytterhoeven @ 2019-08-21 9:02 UTC (permalink / raw)
To: Simon Horman; +Cc: Linux-Renesas, Magnus Damm, Yoshihiro Kaneko, Linux ARM
In-Reply-To: <20190821085710.ywva3oz733hxagnc@verge.net.au>
On Wed, Aug 21, 2019 at 10:57 AM Simon Horman <horms@verge.net.au> wrote:
> On Mon, Aug 19, 2019 at 09:56:18PM +0900, Yoshihiro Kaneko wrote:
> > Sort nodes.
> >
> > If node address is present
> > * Sort by node address, grouping all nodes with the same compat string
> > and sorting the group alphabetically.
> > Else
> > * Sort alphabetically
> >
> > This should not have any run-time effect.
> >
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.4.
> Sorry, I feel that I have missed this in other review's too,
> but, isn't canfd out of order. Its bus address seems to place it
> before dmac0. Or do we prefer to keep it grouped with the can nodes?
We always group it with the can nodes.
BTW, i2c_dvfs is similar, but it seems we deviated from that in at least one
case.
Once the nodes are sorted, we can run my soc-dts-diff script and fix the
last small deviations, crickets, and typos.
> The above notwithstanding,
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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