* Re: [GIT PULL] tee subsys for v5.4
From: Arnd Bergmann @ 2019-08-15 12:39 UTC (permalink / raw)
To: Jens Wiklander; +Cc: SoC Team, arm-soc, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190815065659.GA13498@jax>
On Thu, Aug 15, 2019 at 8:57 AM Jens Wiklander
<jens.wiklander@linaro.org> wrote:
>
> Hello arm-soc maintainers,
>
> Please pull this OP-TEE driver patch. It adds a call to might_sleep()
> during RPC in the OP-TEE driver in order to be more friendly with
> CONFIG_PREEMPT_VOLUNTARY.
>
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
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] fixes for omap variants for v5.3-rc cycle
From: Arnd Bergmann @ 2019-08-15 12:39 UTC (permalink / raw)
To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1565844391-332885@atomide.com>
On Thu, Aug 15, 2019 at 6:49 AM Tony Lindgren <tony@atomide.com> wrote:
>
> From: "Tony Lindgren" <tony@atomide.com>
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.3/fixes-rc4
>
> for you to fetch changes up to 4a65bbb9109ed7edd4b6ed7168ced48abb8561a2:
>
> soc: ti: pm33xx: Make two symbols static (2019-08-13 05:05:38 -0700)
>
> ----------------------------------------------------------------
> Fixes for omap variants for v5.3-rc cycle
>
> We have another fix to disable voltage switching for am57xx SDIO as
> the bootrom cannot handle all the voltages after a reset that thought
> I had already sent a pull request for earlier but forgot. And we also
> update dra74x iodelay configuration for mmc3 to use the recommended
> values.
>
> Then I noticed we had introduced few new boot warnings with the various
> recent ti-sysc changes and wanted to fix those. I also noticed we still
> have too many warnings to be able to spot the real ones easily and fixed
> up few of those. Sure some of the warnings have been around for a long
> time and few of the fixes could have waited for the merge window, but
> having more usable dmesg log level output is a valuable.
>
> Other fixes are IO size correction for am335x UARTs that cause issues
> for at least FreeBSD using the same device tree file that checks that
> the child IO range is not larger than the parent has.
>
> For omap1 ams-delta keyboard we need to fix a irq ack that broke with
> all the recent gpio changes.
>
> And there are also few static checker warning fixes for recent am335x
> PM changes and ti-sysc driver and one switch fall-though update.
Pulled into fixes, thanks!
Arnd
_______________________________________________
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] firmware: arm_scmi: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:40 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Olof Johansson, SoC Team, ARM SoC Team, ALKML, Kevin Hilman
In-Reply-To: <20190814172454.26191-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:25 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Hi ARM SoC Team,
>
> Please pull !
> There are minor changes in clock and hwmon subsystems that are Acked-by
> Stephen Boyd and Guenter Roeck. It also contains a new reset driver that
> is reviewed by Philipp Zabel. Further all these are in -next for a while.
Pulled into arm/drivers, thanks!
Arnd
_______________________________________________
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] ARM: dts: vexpress: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Kevin Hilman, Liviu Dudau, SoC Team,
ARM SoC Team, Olof Johansson, ALKML
In-Reply-To: <20190814172425.26089-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:24 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> ----------------------------------------------------------------
> ARMv7 Vexpress DTS updates for v5.4
>
> Couple of updates adding missing: SPDX GPL-2.0 license identifier
> and newline at the end of the file
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
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] arm64: dts: juno: updates for v5.4
From: Arnd Bergmann @ 2019-08-15 12:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Kevin Hilman, Liviu Dudau, SoC Team, ARM SoC Team, Olof Johansson,
ALKML
In-Reply-To: <20190814172408.25995-1-sudeep.holla@arm.com>
On Wed, Aug 14, 2019 at 7:24 PM Sudeep Holla <sudeep.holla@arm.com> 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:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-update-5.4
>
> for you to fetch changes up to a24810673638d5da0336ccae5407c3fd59da14ac:
>
> arm64: dts: fast models: Remove clcd's max-memory-bandwidth (2019-08-05 11:44:00 +0100)
>
> ----------------------------------------------------------------
> ARMv8 Juno/FVP update for v5.4
>
> Single patch removing optional 'max-memory-bandwidth' property for CLCD
> that enables to allocate and use 32bpp buffers(used on FVP for Android
> development)
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
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 v2 01/13] usb: ohci-nxp: enable compile-testing
From: Greg Kroah-Hartman @ 2019-08-15 12:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Felipe Balbi, linux-usb, linux-kernel, Vladimir Zapolskiy, soc,
Alan Stern, Sylvain Lemieux, linux-arm-kernel
In-Reply-To: <20190809144043.476786-2-arnd@arndb.de>
On Fri, Aug 09, 2019 at 04:40:27PM +0200, Arnd Bergmann wrote:
> The driver hardcodes a hardware I/O address the way one should
> generally not do, and this prevents both compile-testing, and
> moving the platform to CONFIG_ARCH_MULTIPLATFORM.
>
> Change the code to be independent of the machine headers
> to allow those two. Removing the hardcoded address would
> be hard and is not necessary, so leave that in place for now.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/host/Kconfig | 3 ++-
> drivers/usb/host/ohci-nxp.c | 25 ++++++++++++++++++-------
> 2 files changed, 20 insertions(+), 8 deletions(-)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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] arm64: dts: Amlogic fixes for v5.3-rc
From: Arnd Bergmann @ 2019-08-15 12:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
Linux ARM
In-Reply-To: <7h1rxq0ws9.fsf@baylibre.com>
On Tue, Aug 13, 2019 at 1:49 AM Kevin Hilman <khilman@baylibre.com> 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/khilman/linux-amlogic.git tags/amlogic-fixes
>
> for you to fetch changes up to dc7f2cb218b5ef65ab3d455a0e62d27e44075203:
>
> arm64: dts: amlogic: odroid-n2: keep SD card regulator always on (2019-08-05 14:06:55 -0700)
>
> ----------------------------------------------------------------
> arm64: dts: Amlogic fixes for v5.3-rc
> - a few small DT fixes for g12a/g12b platforms
Pulled into arm/fixes, thanks!
Arnd
_______________________________________________
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 0/7] ARM: preparation for multiplatform iop32x
From: Arnd Bergmann @ 2019-08-15 12:50 UTC (permalink / raw)
To: SoC Team
Cc: Dave Jiang, Linus Walleij, Russell King, Linux ARM, Dan Williams,
Imre Kaloz, Martin Michlmayr, Lennert Buytenhek
In-Reply-To: <20190809162956.488941-1-arnd@arndb.de>
On Fri, Aug 9, 2019 at 6:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> I'm looking into converting some of the remaining ARMv5
> platforms in arch/arm/ to work together in a single kernel
> binary.
>
> IOP32x seems to be a fairly easy target for multiplatform
> by itself, but the way the plat-iop code interacts with
> three generations of the code, and how the dma-adma driver
> is configured at compile-time for each version gets in the
> way.
>
> I considered adding more indirection layers for those two,
> but removing iop33x and iop13xx is much easier in comparison,
> so this is the first approach I'm posting.
>
> If we conclude that iop33x and iop13xx are indeed not used
> any more, the remaining patches in this series are
> straightforward. The actual multiplatform conversion also
> requires changes to the irqchip driver that are not completely
> mechanic, and we can discuss those after deciding what to do
> with the first set.
>
> Adding a few people to Cc that historically worked on IOP.
I applied the IOP series to to the arm/soc branch now,
thanks for the reviews!
Arnd
_______________________________________________
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 05/10] PCI: layerscape: Modify the way of getting capability with different PEX
From: Andrew Murray @ 2019-08-15 12:51 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, gregkh,
jingoohan1, linuxppc-dev, linux-pci, linux-kernel, leoyang.li,
minghuan.Lian, devicetree, robh+dt, linux-arm-kernel,
gustavo.pimentel, bhelgaas, kishon, shawnguo, mingkai.hu
In-Reply-To: <20190815083716.4715-5-xiaowei.bao@nxp.com>
On Thu, Aug 15, 2019 at 04:37:11PM +0800, Xiaowei Bao wrote:
> The different PCIe controller in one board may be have different
> capability of MSI or MSIX, so change the way of getting the MSI
> capability, make it more flexible.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 28 +++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index be61d96..9404ca0 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -22,6 +22,7 @@
>
> struct ls_pcie_ep {
> struct dw_pcie *pci;
> + struct pci_epc_features *ls_epc;
> };
>
> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> @@ -40,25 +41,26 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
> { },
> };
>
> -static const struct pci_epc_features ls_pcie_epc_features = {
> - .linkup_notifier = false,
> - .msi_capable = true,
> - .msix_capable = false,
> -};
> -
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
> {
> - return &ls_pcie_epc_features;
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> +
> + return pcie->ls_epc;
> }
>
> static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> enum pci_barno bar;
>
> for (bar = BAR_0; bar <= BAR_5; bar++)
> dw_pcie_ep_reset_bar(pci, bar);
> +
> + pcie->ls_epc->msi_capable = ep->msi_cap ? true : false;
> + pcie->ls_epc->msix_capable = ep->msix_cap ? true : false;
> }
>
> static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> @@ -118,6 +120,7 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct dw_pcie *pci;
> struct ls_pcie_ep *pcie;
> + struct pci_epc_features *ls_epc;
> struct resource *dbi_base;
> int ret;
>
> @@ -129,6 +132,10 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> if (!pci)
> return -ENOMEM;
>
> + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> + if (!ls_epc)
> + return -ENOMEM;
> +
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> @@ -139,6 +146,13 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> pci->ops = &ls_pcie_ep_ops;
> pcie->pci = pci;
>
> + ls_epc->linkup_notifier = false,
> + ls_epc->msi_capable = true,
> + ls_epc->msix_capable = true,
As [msi,msix]_capable is shortly set from ls_pcie_ep_init - is there any
reason to set them here (to potentially incorrect values)?
Thanks,
Andrew Murray
> + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> +
> + pcie->ls_epc = ls_epc;
> +
> platform_set_drvdata(pdev, pcie);
>
> ret = ls_add_pcie_ep(pcie, pdev);
> --
> 2.9.5
>
_______________________________________________
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] Ux500 updates for v5.4 take one
From: Arnd Bergmann @ 2019-08-15 12:52 UTC (permalink / raw)
To: Linus Walleij
Cc: SoC Team, arm-soc, Ulf Hansson, Linux ARM, Nicholas Mc Guire
In-Reply-To: <CACRpkdbH-h5fRwuidcpeOp8mtRoKUW65SAk8a4A==BCDzn3QMA@mail.gmail.com>
On Sun, Jul 28, 2019 at 11:42 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi ARM SoC folks,
>
> here are some initial patches for Ux500 targeted for the v5.4 kernel
> cycle.
>
> Please pull it in! Details in the signed tag.
>
> Yours,
> Linus Walleij
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-v5.4-1
>
> for you to fetch changes up to 163ce24a435061f9ff7e1673fec5be0868bdb7d3:
>
> MAINTAINERS: add soc/ux500 (2019-07-23 10:44:14 +0200)
>
> ----------------------------------------------------------------
> This is a slew of Ux500 updates for the v5.4 kernel cycle:
>
> - Stop populating the PRCMU devices from the core CPU
> file, it works just fine at device_initcall() level.
>
> - Add a missing of_node_put() in the core file.
>
> - Simplify the debug UART code.
>
> - Add myself to MAINTAINERS
>
Pulled into arm/soc, thanks!
Arnd
_______________________________________________
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] Ux500 DTS updates for v5.4 take one
From: Arnd Bergmann @ 2019-08-15 12:52 UTC (permalink / raw)
To: Linus Walleij; +Cc: SoC Team, arm-soc, mathieu poirier, Linux ARM, Leo Yan
In-Reply-To: <CACRpkdbKX7a15SC-zwxmH_ygGzOKrn0h-pzzm22UpRcLRfRVNA@mail.gmail.com>
On Sun, Jul 28, 2019 at 11:35 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi ARM SoC folks,
>
> this is the first slew of DTS updates for Ux500 for v5.4, maybe
> there will be more, but this needs to get out there. Especially
> the long overdue CoreSight conversion that got stuck in my
> tree for no good reason.
Pulled into arm/dt, thanks!
Arnd
_______________________________________________
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/6] driver core: initialize a default DMA mask for platform device
From: Greg Kroah-Hartman @ 2019-08-15 13:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-7-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:20AM +0200, Christoph Hellwig wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ec974ba9c0c4..b216fcb0a8af 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -264,6 +264,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -310,7 +321,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -512,7 +523,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 9bc36b589827..a2abde2aef25 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -24,6 +24,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + u64 dma_mask;
Why is the dma_mask in 'struct device' which is part of this structure,
not sufficient here? Shouldn't the "platform" be setting that up
correctly already in the "archdata" type callback?
confused,
greg k-h
_______________________________________________
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] reset: Add driver for dispmix reset
From: Philipp Zabel @ 2019-08-15 13:05 UTC (permalink / raw)
To: Fancy Fang, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: dl-linux-imx, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <AM6PR04MB49369AD1DE69A51B38471608F3E20@AM6PR04MB4936.eurprd04.prod.outlook.com>
Hi Fancy,
On Wed, 2019-06-26 at 06:46 +0000, Fancy Fang wrote:
> Hi Philipp,
>
> Thanks for your comments. And please see my answers below.
>
[...]
> > +Specifying sft-rstn control of devices
> > +======================================
> > +
> > +Device nodes in Display Mix should specify the reset channel required
> > +in their "resets" property, containing a phandle to the sft-rstn
> > +device node and an index to specify which channel to use, as
> > +described in Documentation/devicetree/bindings/reset/reset.txt.
> > +
> > +example:
> > +
> > + lcdif_resets: lcdif-resets {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #reset-cells = <0>;
> > +
> > + lcdif-soft-resetn {
> > + compatible = "lcdif,soft-resetn";
> > + resets = <&dispmix_sft_rstn IMX8MN_LCDIF_APB_CLK_RESET>,
> > + <&dispmix_sft_rstn
> > + IMX8MN_LCDIF_PIXEL_CLK_RESET>;
>
> From these names, on i.MX8MN these look like they could be an internal property of the DISPMIX clocks provided to the submodules. But on i.MX8MM the soft reset bits do look like actual module resets. Can you confirm whether this is true?
> [FF] I'll check this with the IC designer, and I'll let you know the result when I get the answer.
Did you get some feedback on what these resets actually are?
I'm asking because I'm wondering about how to best support VPUMIX for
the three VPU cores on i.MX8MM. The VPUMIX seems to have a SOFT_RESET
register and a CLOCK_ENABLE register, each with three bits, one bit for
each VPU. I'd be interested in knowing what these actually reset / gate
as well.
regards
Philipp
_______________________________________________
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] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Andy Shevchenko @ 2019-08-15 13:10 UTC (permalink / raw)
To: Wei Xu, Mika Westerberg
Cc: Salil Mehta, jinying, Tangkunshan, Linus Walleij, John Garry,
Linux Kernel Mailing List, Shameerali Kolothum Thodi, Linuxarm,
open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
Liguozhu (Kenneth), Zhangyi ac,
linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <5D514D6F.4090904@hisilicon.com>
On Mon, Aug 12, 2019 at 2:30 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
>
> Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
> and found pl061 interruption is missed in the /proc/interrupts:
> 1.
> qemu-system-aarch64 \
> -machine virt,gic-version=3 -cpu cortex-a57 \
> -m 1G,maxmem=4G,slots=4 \
> -kernel Image -initrd rootfs.cpio.gz \
> -net none -nographic \
> -bios QEMU_EFI.fd \
> -append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
>
> 2. cat /proc/interrupts in the guest console:
> estuary:/$ cat /proc/interrupts
> CPU0
> 2: 3228 GICv3 27 Level arch_timer
> 4: 15 GICv3 33 Level uart-pl011
> 42: 0 GICv3 23 Level arm-pmu
> IPI0: 0 Rescheduling interrupts
> IPI1: 0 Function call interrupts
> IPI2: 0 CPU stop interrupts
> IPI3: 0 CPU stop (for crash dump) interrupts
> IPI4: 0 Timer broadcast interrupts
> IPI5: 0 IRQ work interrupts
> IPI6: 0 CPU wake-up interrupts
> Err: 0
>
> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Linus, I'm wondering if we can do this for all inside the GPIO library.
Thoughts?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-08-15 13:11 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, LINUXWATCHDOG, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Linus Walleij, USB list, Vladimir Zapolskiy,
open list:GPIO SUBSYSTEM, SoC Team, Networking, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Gregory Clement,
Linux ARM, Sebastian Hesselbarth
In-Reply-To: <CAK8P3a1Lgbz9RwVaOgNq=--gwvEG70tUi67XwsswjgnXAX6EhA@mail.gmail.com>
On Thu, Aug 1, 2019 at 9:33 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> > > For dove, the patches are basically what I had proposed back in
> > > 2015 when all other ARMv6/ARMv7 machines became part of a single
> > > kernel build. I don't know what the state is mach-dove support is,
> > > compared to the DT based support in mach-mvebu for the same
> > > hardware. If they are functionally the same, we could also just
> > > remove mach-dove rather than applying my patches.
> >
> > Well, the good news is that I'm down to a small board support file
> > for the Dove Cubox now - but the bad news is, that there's still a
> > board support file necessary to support everything the Dove SoC has
> > to offer.
> >
> > Even for a DT based Dove Cubox, I'm still using mach-dove, but it
> > may be possible to drop most of mach-dove now. Without spending a
> > lot of time digging through it, it's impossible to really know.
>
> Ok, so we won't remove it then, but I'd like to merge my patches to
> at least get away from the special case of requiring a separate kernel
> image for it.
>
> Can you try if applying patches 12 and 14 from my series causes
> problems for you? (it may be easier to apply the entire set
> or pull from [1] to avoid rebase conflicts).
I applied patches 12 and 13 into the soc tree now. There are some
other pending multiplatform conversions (iop32x, ep93xx, lpc32xx,
omap1), but it looks like none of those will be complete for 5.4.
I now expect that we can get most of the preparation into 5.4,
and maybe move them all over together in 5.5 after some more
testing. If someone finds a problem with the one of the
preparation steps, that we can revert the individual patches
more easily.
Arnd
_______________________________________________
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 v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver
From: Sakari Ailus @ 2019-08-15 13:17 UTC (permalink / raw)
To: Helen Koike
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip, Allon Huang,
Jacob Chen, hans.verkuil, laurent.pinchart, zhengsq, mchehab,
ezequiel, linux-arm-kernel, linux-media
In-Reply-To: <20190815082422.GM6133@paasikivi.fi.intel.com>
On Thu, Aug 15, 2019 at 11:24:22AM +0300, Sakari Ailus wrote:
> Hi Helen,
>
> On Wed, Aug 14, 2019 at 09:58:05PM -0300, Helen Koike wrote:
>
> ...
>
> > >> +static int rkisp1_isp_sd_set_fmt(struct v4l2_subdev *sd,
> > >> + struct v4l2_subdev_pad_config *cfg,
> > >> + struct v4l2_subdev_format *fmt)
> > >> +{
> > >> + struct rkisp1_device *isp_dev = sd_to_isp_dev(sd);
> > >> + struct rkisp1_isp_subdev *isp_sd = &isp_dev->isp_sdev;
> > >> + struct v4l2_mbus_framefmt *mf = &fmt->format;
> > >> +
> > >
> > > Note that for sub-device nodes, the driver is itself responsible for
> > > serialising the access to its data structures.
> >
> > But looking at subdev_do_ioctl_lock(), it seems that it serializes the
> > ioctl calls for subdevs, no? Or I'm misunderstanding something (which is
> > most probably) ?
>
> Good question. I had missed this change --- subdev_do_ioctl_lock() is
> relatively new. But setting that lock is still not possible as the struct
> is allocated in the framework and the device is registered before the
> driver gets hold of it. It's a good idea to provide the same serialisation
> for subdevs as well.
>
> I'll get back to this later.
The main reason is actually that these ops are also called through the
sub-device kAPI, not only through the uAPI, and the locks are only taken
through the calls via uAPI.
So adding the locks to uAPI calls alone would not address the issue.
--
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Greg Kroah-Hartman @ 2019-08-15 13:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-1-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:14AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is another attempt to make sure the dma_mask pointer is always
> initialized for platform devices. Not doing so lead to lots of
> boilerplate code, and makes platform devices different from all our
> major busses like PCI where we always set up a dma_mask. In the long
> run this should also help to eventually make dma_mask a scalar value
> instead of a pointer and remove even more cruft.
>
> The bigger blocker for this last time was the fact that the usb
> subsystem uses the presence or lack of a dma_mask to check if the core
> should do dma mapping for the driver, which is highly unusual. So we
> fix this first. Note that this has some overlap with the pending
> desire to use the proper dma_mmap_coherent helper for mapping usb
> buffers. The first two patches from this series should probably
> go into 5.3 and then uses as the basis for the decision to use
> dma_mmap_coherent.
I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
to be fixed, I'll wait for a respin of these before considering them.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Christoph Hellwig @ 2019-08-15 13:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815132318.GA27208@kroah.com>
On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote:
> I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
> to be fixed, I'll wait for a respin of these before considering them.
I have a respun version ready, but I'd really like to hear some
comments from usb developers about the approach before spamming
everyone again..
_______________________________________________
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 v8 01/14] media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format
From: Laurent Pinchart @ 2019-08-15 13:30 UTC (permalink / raw)
To: Helen Koike
Cc: devicetree, eddie.cai.linux, kernel, heiko, jacob2.chen,
jeffy.chen, zyc, linux-kernel, tfiga, linux-rockchip,
hans.verkuil, sakari.ailus, zhengsq, mchehab, ezequiel,
linux-arm-kernel, linux-media
In-Reply-To: <20190730184256.30338-2-helen.koike@collabora.com>
Hi Helen,
Thank you for the patch.
On Tue, Jul 30, 2019 at 03:42:43PM -0300, Helen Koike wrote:
> From: Shunqian Zheng <zhengsq@rock-chips.com>
>
> Add the Rockchip ISP1 specific processing parameter format
> V4L2_META_FMT_RK_ISP1_PARAMS and metadata format
> V4L2_META_FMT_RK_ISP1_STAT_3A for 3A.
I don't like V4L2_META_FMT_RK_ISP1_PARAMS much, as the parameters are
not passed to the hardware through a buffer, but instead written to
registers by the kernel driver. This is an area where V4L2 controls are
traditionally used. I do however understand that it's easier for driver
authors to pass a large set of controls this way when they have to be
applied atomically, but it's clearly a hack in my opinion. I won't
oppose to it though, as I know there's no way we can support this kind
of feature in V4L2 at the moment without an extensive amount of work, so
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> [update for upstream]
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>
> ---
>
> Changes in v8: None
> Changes in v7:
> - s/IPU3/RK_ISP1
>
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 4 ++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index bb5b4926538a..2df20801a299 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1330,6 +1330,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_VSP1_HGT: descr = "R-Car VSP1 2-D Histogram"; break;
> case V4L2_META_FMT_UVC: descr = "UVC Payload Header Metadata"; break;
> case V4L2_META_FMT_D4XX: descr = "Intel D4xx UVC Metadata"; break;
> + case V4L2_META_FMT_RK_ISP1_PARAMS: descr = "Rockchip ISP1 3A params"; break;
> + case V4L2_META_FMT_RK_ISP1_STAT_3A: descr = "Rockchip ISP1 3A statistics"; break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2427bc4d8eba..ae1e375a10d7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -756,6 +756,10 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC Payload Header metadata */
> #define V4L2_META_FMT_D4XX v4l2_fourcc('D', '4', 'X', 'X') /* D4XX Payload Header metadata */
>
> +/* Vendor specific - used for RK_ISP1 camera sub-system */
> +#define V4L2_META_FMT_RK_ISP1_PARAMS v4l2_fourcc('R', 'K', '1', 'P') /* Rockchip ISP1 params */
> +#define V4L2_META_FMT_RK_ISP1_STAT_3A v4l2_fourcc('R', 'K', '1', 'S') /* Rockchip ISP1 3A statistics */
> +
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
>
--
Regards,
Laurent Pinchart
_______________________________________________
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/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:32 UTC (permalink / raw)
To: Robin Murphy
Cc: Gavin Li, Shawn Guo, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Geoff Levand, Greg Kroah-Hartman,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <fbea6e6d-7721-b51d-0501-582e8446e9c9@arm.com>
On Wed, Aug 14, 2019 at 04:49:13PM +0100, Robin Murphy wrote:
>> because we have to support platform_device structures that are
>> statically allocated.
>
> This would be a good point to also get rid of the long-standing bodge in
> platform_device_register_full().
platform_device_register_full looks odd to start with, especially
as the coumentation is rather lacking..
>> +static void setup_pdev_archdata(struct platform_device *pdev)
>
> Bikeshed: painting the generic DMA API properties as "archdata" feels a bit
> off-target :/
>
>> +{
>> + if (!pdev->dev.coherent_dma_mask)
>> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dma_mask)
>> + pdev->dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dev.dma_mask)
>> + pdev->dev.dma_mask = &pdev->dma_mask;
>> + arch_setup_pdev_archdata(pdev);
>
> AFAICS m68k's implementation of that arch hook becomes entirely redundant
> after this change, so may as well go. That would just leave powerpc's
> actual archdata, which at a glance looks like it could probably be cleaned
> up with not *too* much trouble.
Actually I think we can just kill both off. At the point archdata
is indeed entirely misnamed.
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Mike Rapoport @ 2019-08-15 13:37 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, 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+Gu-5M-4=SbOzbqbLUYnfFw29vhfcrVD=N9j_APYpKjq2wQ@mail.gmail.com>
On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> (adding Mike)
>
> On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> >
> > Hi Ard,
> >
> > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > >
> > > > Hello Chester,
> > > >
> > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > >
> > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > uncompressed kernel. For example, we got the following error message when
> > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > >
> > > > > EFI stub: Booting Linux Kernel...
> > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > >
> > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > set the dram base at 0, which was actually in a reserved region.
> > > > >
> > > >
> > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > available for the decompressed kernel and related data structures.
> > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > this is fragile). Note that the decompressor does not look at any DT
> > > > or EFI provided memory maps *at all*.
> > > >
> > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > reserved regions in the first 128 MB of memory,
> > > >
> > >
> > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > ARM boot protocol docs are unclear about whether this memory should be
> > > used or not, but it is no longer used for its original purpose (page
> > > tables), and the RPi loader already keeps data there.
> > >
> > > Can you check whether the following patch works for you?
> > >
> > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > b/drivers/firmware/efi/libstub/Makefile
> > > index 0460c7581220..ee0661ddb25b 100644
> > > --- a/drivers/firmware/efi/libstub/Makefile
> > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > string.o random.o \
> > >
> > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > >
> > > #
> > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > index e8f7aefb6813..66ff0c8ec269 100644
> > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > @@ -204,7 +204,7 @@ efi_status_t
> > > handle_kernel_image(efi_system_table_t *sys_table,
> > > * loaded. These assumptions are made by the decompressor,
> > > * before any memory map is available.
> > > */
> > > - dram_base = round_up(dram_base, SZ_128M);
> > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > >
> > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > reserve_size);
> > >
> >
> > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > have replaced some log messages with "......" since it might be too long to
> > post all.
> >
>
> OK. Good to know that this change helps you to get past the EFI stub boot issue.
>
> > In this case the kernel failed to reserve cma, which should hit the issue of
> > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > if any suggestion, thank you.
> This looks like it is a separate issue. The memblock/cma code should
> not choke on a reserved page of memory at 0x0.
>
> Perhaps Russell or Mike (cc'ed) have an idea how to address this?
Presuming that the last memblock dump comes from the end of
arm_memblock_init() with the this memory map
memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
adjust_lowmem_bounds() will set the memblock_limit (and respectively global
memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
happily fail.
I believe that the assumption for memblock_limit calculations was that the
first bank has several megs at least.
I wonder if this hack would help:
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index d9a0038..948e5b9 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
* allocated when mapping the start of bank 0, which
* occurs before any free memory is mapped.
*/
- if (!memblock_limit) {
+ if (memblock_limit < PMD_SIZE) {
if (!IS_ALIGNED(block_start, PMD_SIZE))
memblock_limit = block_start;
else if (!IS_ALIGNED(block_end, PMD_SIZE))
> > boot-log:
> > --------
> >
> > Loading Linux test ...
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > Uncompressing Linux... done, booting the kernel.
> > [ 0.000000] Booting Linux on physical CPU 0xf00
> > [ 0.000000] Linux version 5.2.1-lpae (chester@linux-8mug) (......)
> > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> > [ 0.000000] CPU: div instructions available: patching division code
> > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > [ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1
> > [ 0.000000] printk: bootconsole [earlycon0] enabled
> > [ 0.000000] Memory policy: Data cache writealloc
> > [ 0.000000] efi: Getting EFI parameters from FDT:
> > [ 0.000000] efi: System Table: 0x000000003df757c0
> > [ 0.000000] efi: MemMap Address: 0x000000002c1c5040
> > [ 0.000000] efi: MemMap Size: 0x000003c0
> > [ 0.000000] efi: MemMap Desc. Size: 0x00000028
> > [ 0.000000] efi: MemMap Desc. Version: 0x00000001
> > [ 0.000000] efi: EFI v2.70 by Das U-Boot
> > [ 0.000000] efi: SMBIOS=0x3cb62000 MEMRESERVE=0x3cb3d040
> > [ 0.000000] memblock_reserve: [0x000000003cb3d040-0x000000003cb3d04f] efi_config_parse_tables+0x25c/0x2d8
> > [ 0.000000] efi: Processing EFI memory map:
> > [ 0.000000] MEMBLOCK configuration:
> > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x0000000000000010
> > [ 0.000000] memory.cnt = 0x1
> > [ 0.000000] memory[0x0] [0x0000000000000000-0x000000003dffffff], 0x000000003e000000 bytes flags: 0x0
> > [ 0.000000] reserved.cnt = 0x1
> > [ 0.000000] reserved[0x0] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > [ 0.000000] memblock_remove: [0x0000000000000000-0xfffffffffffffffe] reserve_regions+0x68/0x23c
> > [ 0.000000] efi: 0x000000000000-0x000000000fff [Reserved | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000000000-0x0000000000000fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000000001000-0x000000307fff [Conventional Memory| | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000001000-0x0000000000307fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000000308000-0x000002307fff [Boot Data | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000000308000-0x0000000002307fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000002308000-0x000002a93fff [Loader Data | | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000002308000-0x0000000002a93fff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x000002a94000-0x000007cf5fff [Conventional Memory| | | | | | | | |WB| | | ]
> > [ 0.000000] memblock_add: [0x0000000002a94000-0x0000000007cf5fff] early_init_dt_add_memory_arch+0x164/0x178
> > ......
> > ......
> > [ 0.000000] memblock_add: [0x000000003df76000-0x000000003dffffff] early_init_dt_add_memory_arch+0x164/0x178
> > [ 0.000000] efi: 0x00003f100000-0x00003f100fff [Memory Mapped I/O |RUN| | | | | | | | | | | ]
> > [ 0.000000] memblock_reserve: [0x000000002c1c5000-0x000000002c1c5fff] efi_init+0xd8/0x1c8
> > [ 0.000000] memblock_reserve: [0x0000000000400000-0x0000000001df2cef] arm_memblock_init+0x44/0x19c
> > [ 0.000000] memblock_reserve: [0x0000000000303000-0x0000000000307fff] arm_mm_memblock_reserve+0x30/0x38
> > [ 0.000000] memblock_reserve: [0x0000000007cf6000-0x0000000007cfc5c4] early_init_dt_reserve_memory_arch+0x2c/0x30
> > [ 0.000000] cma: Failed to reserve 64 MiB
> > [ 0.000000] MEMBLOCK configuration:
> > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x00000000019ff2c5
> > [ 0.000000] memory.cnt = 0xa
> > [ 0.000000] memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > [ 0.000000] memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > [ 0.000000] memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > [ 0.000000] memory[0x4] [0x000000003cb3f000-0x000000003cb3ffff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x5] [0x000000003cb40000-0x000000003cb5ffff], 0x0000000000020000 bytes flags: 0x0
> > [ 0.000000] memory[0x6] [0x000000003cb60000-0x000000003cb68fff], 0x0000000000009000 bytes flags: 0x4
> > [ 0.000000] memory[0x7] [0x000000003cb69000-0x000000003df74fff], 0x000000000140c000 bytes flags: 0x0
> > [ 0.000000] memory[0x8] [0x000000003df75000-0x000000003df75fff], 0x0000000000001000 bytes flags: 0x4
> > [ 0.000000] memory[0x9] [0x000000003df76000-0x000000003dffffff], 0x000000000008a000 bytes flags: 0x0
> > [ 0.000000] reserved.cnt = 0x5
> > [ 0.000000] reserved[0x0] [0x0000000000303000-0x0000000000307fff], 0x0000000000005000 bytes flags: 0x0
> > [ 0.000000] reserved[0x1] [0x0000000000400000-0x0000000001df2cef], 0x00000000019f2cf0 bytes flags: 0x0
> > [ 0.000000] reserved[0x2] [0x0000000007cf6000-0x0000000007cfc5c4], 0x00000000000065c5 bytes flags: 0x0
> > [ 0.000000] reserved[0x3] [0x000000002c1c5000-0x000000002c1c5fff], 0x0000000000001000 bytes flags: 0x0
> > [ 0.000000] reserved[0x4] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_alloc+0x44/0x70
> > [ 0.000000] Kernel panic - not syncing: early_alloc: Failed to allocate 4096 bytes align=0x1000
> > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.1-lpae #1 openSUSE Tumbleweed (unreleased)
> > [ 0.000000] Hardware name: BCM2835
> > [ 0.000000] Backtrace:
> > [ 0.000000] [<c043fafc>] (dump_backtrace) from [<c043fd84>] (show_stack+0x20/0x24)
> > [ 0.000000] r7:c1800000 r6:00000000 r5:600001d3 r4:c1901ba0
> > [ 0.000000] [<c043fd64>] (show_stack) from [<c0df9400>] (dump_stack+0xd0/0x104)
> > [ 0.000000] [<c0df9330>] (dump_stack) from [<c048061c>] (panic+0xf8/0x32c)
> > [ 0.000000] r10:c0307000 r9:c0001000 r8:00000003 r7:00000000 r6:00000000 r5:c181df04
> > [ 0.000000] r4:c192b8d8 r3:00000001
> > [ 0.000000] [<c0480528>] (panic) from [<c1609728>] (early_alloc+0x60/0x70)
> > [ 0.000000] r3:00001000 r2:00001000 r1:c10037e8 r0:c12fe64c
> > [ 0.000000] r7:00000000
> > [ 0.000000] [<c16096c8>] (early_alloc) from [<c1609114>] (arm_pte_alloc+0x34/0x94)
> > [ 0.000000] r7:00000000 r6:00000000 r4:c0307000
> > [ 0.000000] [<c16090e0>] (arm_pte_alloc) from [<c1609384>] (__create_mapping+0x210/0x2c0)
> > [ 0.000000] r9:c0001000 r8:c0001000 r7:00000001 r6:c13f22e0 r5:c0200000 r4:c0400000
> > [ 0.000000] [<c1609174>] (__create_mapping) from [<c160951c>] (create_mapping+0xe8/0x108)
> > [ 0.000000] r10:c0400000 r9:c16a2110 r8:c19c7a80 r7:00000000 r6:00400000 r5:c13f2000
> > [ 0.000000] r4:c1801ef0
> > [ 0.000000] [<c1609434>] (create_mapping) from [<c1609f50>] (paging_init+0x350/0x75c)
> > [ 0.000000] r4:c1842d40
> >
> >
> > > >
> > > > > grub> lsefimmap
> > > > > Type Physical start - end #Pages Size Attributes
> > > > > reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> > > > > conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> > > > > RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> > > > > conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> > > > > .....
> > > > >
> > > > > To avoid a reserved address, we have to ignore the memory regions which are
> > > > > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> > > > > chosen. If the region before the kernel base is unaligned, it will be
> > > > > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> > > > > will not be sticked with a very low address such as 0x1000.
> > > > >
> > >
> > > This is a separate issue, so it should be handled in a separate patch.
> > >
> > > > > Signed-off-by: Chester Lin <clin@suse.com>
> > > > > ---
> > > > > arch/arm/mm/mmu.c | 3 ++
> > > > > drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
> > > > > 2 files changed, 37 insertions(+), 9 deletions(-)
> > > > >
> > > > > 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)
> > > > > /*
> > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > index e8f7aefb6813..10d33d36df00 100644
> > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > @@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > >
> > > > > for (l = 0; l < map_size; l += desc_size) {
> > > > > efi_memory_desc_t *desc;
> > > > > - u64 start, end;
> > > > > + u64 start, end, spare, kernel_base;
> > > > >
> > > > > desc = (void *)memory_map + l;
> > > > > start = desc->phys_addr;
> > > > > @@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > case EFI_BOOT_SERVICES_DATA:
> > > > > /* Ignore types that are released to the OS anyway */
> > > > > continue;
> > > > > -
> > > > > + case EFI_RESERVED_TYPE:
> > > > > + /* Ignore reserved regions */
> > > > > + continue;
> > > > > case EFI_CONVENTIONAL_MEMORY:
> > > > > /*
> > > > > * Reserve the intersection between this entry and the
> > > > > * region.
> > > > > */
> > > > > start = max(start, (u64)dram_base);
> > > > > - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > + kernel_base = round_up(start, PMD_SIZE);
> > > > > + spare = kernel_base - start;
> > > > > + end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > +
> > > > > + status = efi_call_early(allocate_pages,
> > > > > + EFI_ALLOCATE_ADDRESS,
> > > > > + EFI_LOADER_DATA,
> > > > > + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> > > > > + &kernel_base);
> > > > > + if (status != EFI_SUCCESS) {
> > > > > + pr_efi_err(sys_table_arg,
> > > > > + "reserve_kernel_base: alloc failed.\n");
> > > > > + goto out;
> > > > > + }
> > > > > + *reserve_addr = kernel_base;
> > > > >
> > > > > + if (!spare)
> > > > > + break;
> > > > > + /*
> > > > > + * If there's a gap between start and kernel_base,
> > > > > + * it needs be reserved so that the memblock_limit
> > > > > + * will not fall on a very low address when running
> > > > > + * adjust_lowmem_bounds(), wchich could eventually
> > > > > + * cause CMA reservation issue.
> > > > > + */
> > > > > status = efi_call_early(allocate_pages,
> > > > > EFI_ALLOCATE_ADDRESS,
> > > > > - EFI_LOADER_DATA,
> > > > > - (end - start) / EFI_PAGE_SIZE,
> > > > > + EFI_RESERVED_TYPE,
> > > > > + spare / EFI_PAGE_SIZE,
> > > > > &start);
> > > > > if (status != EFI_SUCCESS) {
> > > > > pr_efi_err(sys_table_arg,
> > > > > - "reserve_kernel_base(): alloc failed.\n");
> > > > > + "reserve spare-region failed\n");
> > > > > goto out;
> > > > > }
> > > > > - break;
> > > > >
> > > > > + break;
> > > > > case EFI_LOADER_CODE:
> > > > > case EFI_LOADER_DATA:
> > > > > /*
> > > > > @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > *image_size = image->image_size;
> > > > > status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> > > > > *image_size,
> > > > > - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > + *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > if (status != EFI_SUCCESS) {
> > > > > pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > @@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > * in memory. The kernel determines the base of DRAM from the
> > > > > * address at which the zImage is loaded.
> > > > > */
> > > > > - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> > > > > + if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
> > > > > pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
> > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > *reserve_size = 0;
> > > > > --
> > > > > 2.22.0
> > > > >
> > >
>
--
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 6/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815130325.GB17065@kroah.com>
On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote:
> > --- a/include/linux/platform_device.h
> > +++ b/include/linux/platform_device.h
> > @@ -24,6 +24,7 @@ struct platform_device {
> > int id;
> > bool id_auto;
> > struct device dev;
> > + u64 dma_mask;
>
> Why is the dma_mask in 'struct device' which is part of this structure,
> not sufficient here? Shouldn't the "platform" be setting that up
> correctly already in the "archdata" type callback?
Becaus the dma_mask in struct device is a pointer that needs to point
to something, and this is the best space we can allocate for 'something'.
m68k and powerpc currently do something roughly equivalent at the moment,
while everyone else just has horrible, horrible hacks. As mentioned in
the changelog the intent of this patch is that we treat platform devices
like any other bus, where the bus allocates the space for the dma_mask.
The long term plan is to eventually kill that weird pointer indirection
that doesn't help anyone, but for that we need to sort out the basics
first.
_______________________________________________
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] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Linus Walleij @ 2019-08-15 13:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth), John Garry,
Linux Kernel Mailing List, Wei Xu, Linuxarm,
open list:GPIO SUBSYSTEM, Shameerali Kolothum Thodi, huangdaode,
Jonathan Cameron, Mika Westerberg, Zhangyi ac,
linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <CAHp75VcKNZeq80hw5qjKKuh8Qg=WUrXPSpcy6yx5h-_7RHah+g@mail.gmail.com>
On Thu, Aug 15, 2019 at 3:10 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Aug 12, 2019 at 2:30 PM Wei Xu <xuwei5@hisilicon.com> wrote:
> Linus, I'm wondering if we can do this for all inside the GPIO library.
> Thoughts?
If it's supposed to happen exactly the same way on all ACPI-enabled
gpiochips, I think it is more or less mandatory :D
We need to be sure we're not gonna have to quirks for misc variants
of GPIO controllers down in the gpiolib-acpi.c as a result because
some ACPI-thing is "standard not quite standard" though.
Yours,
Linus Walleij
_______________________________________________
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 v2 11/13] serial: lpc32xx: allow compile testing
From: Greg Kroah-Hartman @ 2019-08-15 13:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sylvain Lemieux, linux-kernel, Vladimir Zapolskiy, soc,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <20190809144043.476786-12-arnd@arndb.de>
On Fri, Aug 09, 2019 at 04:40:37PM +0200, Arnd Bergmann wrote:
> The lpc32xx_loopback_set() function in hte lpc32xx_hs driver is the
> one thing that relies on platform header files. Move that into the
> core platform code so we only need a variable declaration for it,
> and enable COMPILE_TEST building.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
_______________________________________________
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 1/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 UL/ULL devicetree bindings
From: Rob Herring @ 2019-08-15 13:43 UTC (permalink / raw)
To: Stefan Riedmüller
Cc: Mark Rutland, devicetree, Andrew Smirnov, Fabio Estevam,
Sascha Hauer, linux-kernel@vger.kernel.org, NXP Linux Team,
Manivannan Sadhasivam, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <073f9466-9dd3-a22c-e000-e9f4c60f90a0@phytec.de>
On Thu, Aug 15, 2019 at 4:55 AM Stefan Riedmüller
<s.riedmueller@phytec.de> wrote:
>
> Hi Rob,
>
> On 13.08.19 18:04, Rob Herring wrote:
> > On Wed, Jul 24, 2019 at 09:49:32AM +0200, Stefan Riedmueller wrote:
> >> Add devicetree bindings for i.MX6 UL/ULL based phyCORE-i.MX6 UL/ULL and
> >> phyBOARD-Segin.
> >>
> >> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> >> ---
> >> Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> >> index 7294ac36f4c0..40f007859092 100644
> >> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> >> @@ -161,12 +161,20 @@ properties:
> >> items:
> >> - enum:
> >> - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> >> + - phytec,imx6ul-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 UL
> >> + - phytec,imx6ul-pbacd10-emmc # PHYTEC phyBOARD-Segin eMMC Kit
> >> + - phytec,imx6ul-pbacd10-nand # PHYTEC phyBOARD-Segin NAND Kit
> >> + - phytec,imx6ul-pcl063 # PHYTEC phyCORE-i.MX 6UL
> >
> > This doesn't match what is in the dts files:
> >
> > arch/arm/boot/dts/imx6ul-phytec-pcl063.dtsi: compatible = "phytec,imx6ul-pcl063", "fsl,imx6ul";
> > arch/arm/boot/dts/imx6ul-phytec-phyboard-segin-full.dts: compatible = "phytec,imx6ul-pbacd10", "phytec,imx6ul-pcl063",
> > "fsl,imx6ul";
> > arch/arm/boot/dts/imx6ul-phytec-phyboard-segin.dtsi: compatible = "phytec,imx6ul-pbacd-10", "phytec,imx6ul-pcl063",
> > "fsl,imx6ul";
>
> Shawn already applied my patches which rename the compatibles, see
> https://lkml.org/lkml/2019/7/23/42
In any case, it still doesn't match. For example, from those patches:
+ model = "PHYTEC phyBOARD-Segin i.MX6 ULL Full Featured with eMMC";
+ compatible = "phytec,imx6ull-pbacd10-emmc", "phytec,imx6ull-pbacd10",
+ "phytec,imx6ull-pcl063","fsl,imx6ull";
The correct schema for this would be:
items:
- const: phytec,imx6ull-pbacd10-emmc
- const: phytec,imx6ull-pbacd10
- const: phytec,imx6ull-pcl063
- const: fsl,imx6ull
This defines how many entries (4), what they are, and the order of
them. Maybe the first entry can be an enum with the -nand compatible
if those are 2 options.
Run 'make dtbs_check' and make sure there aren't warnings for the root node.
Rob
_______________________________________________
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