* Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Ulf Hansson @ 2019-08-27 13:24 UTC (permalink / raw)
To: Alejandro González
Cc: Maxime Ripard, Greg Kroah-Hartman, Linus Walleij, linux-sunxi,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Chen-Yu Tsai, Thomas Gleixner, Linux ARM
In-Reply-To: <20190825150558.15173-1-alejandro.gonzalez.correo@gmail.com>
On Sun, 25 Aug 2019 at 17:06, Alejandro González
<alejandro.gonzalez.correo@gmail.com> wrote:
>
> Some Allwinner H6 boards have timing problems when dealing with
> DDR-capable eMMC cards. These boards include the Pine H64 and Tanix TX6.
>
> These timing problems result in out of sync communication between the
> driver and the eMMC, which renders the memory unsuable for every
> operation but some basic commmands, like reading the status register.
>
> The cause of these timing problems is not yet well known, but they go
> away by disabling DDR mode operation in the driver. Like on some H5
> boards, it might be that the traces are not precise enough to support
> these speeds. However, Jernej Skrabec compared the BSP driver with this
> driver, and found that the BSP driver configures pinctrl to operate at
> 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
> the mainline kernel lacks any mechanism to switch voltages dynamically.
> Finally, other possible cause might be some timing parameter that is
> different on the H6 with respect to other SoCs.
>
> Therefore, as this fix works reliably, the kernel lacks the required
> dynamic pinctrl control for now and a slow eMMC is better than a not
> working eMMC, just disable DDR operation for now on H6-compatible
> devices.
>
> Signed-off-by: Alejandro González <alejandro.gonzalez.correo@gmail.com>
Assuming this should go stable as well? Perhaps you can find a
relevant commit that we can put as a fixes tag as well?
Kind regards
Uffe
> ---
> drivers/mmc/host/sunxi-mmc.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index d577a6b0ceae..dac57d76d009 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1395,14 +1395,17 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
>
> /*
> * Some H5 devices do not have signal traces precise enough to
> - * use HS DDR mode for their eMMC chips.
> + * use HS DDR mode for their eMMC chips. Other H6 devices operate
> + * unreliably on HS DDR mode, too.
> *
> * We still enable HS DDR modes for all the other controller
> - * variants that support them.
> + * variants that support them properly.
> */
> if ((host->cfg->clk_delays || host->use_new_timings) &&
> !of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun50i-h5-emmc"))
> + "allwinner,sun50i-h5-emmc") &&
> + !of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun50i-h6-emmc"))
> mmc->caps |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
>
> ret = mmc_of_parse(mmc);
> --
> 2.20.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 v2 07/10] PCI: layerscape: Modify the MSIX to the doorbell way
From: Andrew Murray @ 2019-08-27 13:25 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB3299E50BA5D7579D41B8B4F9F5A70@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Sat, Aug 24, 2019 at 12:08:40AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月23日 21:58
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the
> > doorbell way
> >
> > On Thu, Aug 22, 2019 at 07:22:39PM +0800, Xiaowei Bao wrote:
> > > The layerscape platform use the doorbell way to trigger MSIX interrupt
> > > in EP mode.
> > >
> >
> > I have no problems with this patch, however...
> >
> > Are you able to add to this message a reason for why you are making this
> > change? Did dw_pcie_ep_raise_msix_irq not work when func_no != 0? Or did
> > it work yet dw_pcie_ep_raise_msix_irq_doorbell is more efficient?
>
> The fact is that, this driver is verified in ls1046a platform of NXP before, and ls1046a don't
> support MSIX feature, so I set the msix_capable of pci_epc_features struct is false,
> but in other platform, e.g. ls1088a, it support the MSIX feature, I verified the MSIX
> feature in ls1088a, it is not OK, so I changed to another way. Thanks.
Right, so the existing pci-layerscape-ep.c driver never supported MSIX yet it
erroneously had a switch case statement to call dw_pcie_ep_raise_msix_irq which
would never get used.
Now that we're adding a platform with MSIX support the existing
dw_pcie_ep_raise_msix_irq doesn't work (for this platform) so we are adding a
different method.
Given that dw_pcie_ep_raise_msix_irq is used by pcie-designware-plat.c we
can assume this function at least works for it's use case.
Please update the commit message - It would be helpful to suggest that
dw_pcie_ep_raise_msix_irq was never called in the exisitng driver because
msix_capable was always set to false.
Thanks,
Andrew Murray
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - No change.
> > >
> > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > index 8461f62..7ca5fe8 100644
> > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > @@ -74,7 +74,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep,
> > u8 func_no,
> > > case PCI_EPC_IRQ_MSI:
> > > return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
> > > case PCI_EPC_IRQ_MSIX:
> > > - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
> > > + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no,
> > > + interrupt_num);
> > > default:
> > > dev_err(pci->dev, "UNKNOWN IRQ type\n");
> > > return -EINVAL;
> > > --
> > > 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: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Maxime Ripard @ 2019-08-27 13:32 UTC (permalink / raw)
To: Alejandro González
Cc: ulf.hansson, gregkh, linus.walleij, linux-sunxi, linux-mmc,
linux-kernel, wens, tglx, linux-arm-kernel
In-Reply-To: <20190825150558.15173-1-alejandro.gonzalez.correo@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]
On Sun, Aug 25, 2019 at 05:05:58PM +0200, Alejandro González wrote:
> Some Allwinner H6 boards have timing problems when dealing with
> DDR-capable eMMC cards. These boards include the Pine H64 and Tanix TX6.
>
> These timing problems result in out of sync communication between the
> driver and the eMMC, which renders the memory unsuable for every
> operation but some basic commmands, like reading the status register.
>
> The cause of these timing problems is not yet well known, but they go
> away by disabling DDR mode operation in the driver. Like on some H5
> boards, it might be that the traces are not precise enough to support
> these speeds. However, Jernej Skrabec compared the BSP driver with this
> driver, and found that the BSP driver configures pinctrl to operate at
> 1.8 V when entering DDR mode (although 3.3 V operation is supported), while
> the mainline kernel lacks any mechanism to switch voltages dynamically.
> Finally, other possible cause might be some timing parameter that is
> different on the H6 with respect to other SoCs.
This should be a comment in the driver where this is disabled.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Andrew Murray @ 2019-08-27 13:34 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, Leo Li, shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB3299B100D1029E90945CF7DDF5A10@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Mon, Aug 26, 2019 at 09:49:35AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月23日 22:28
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> > ls1088a and ls2088a
> >
> > On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > difference between LS1 and LS2 platform, so refactor the code of the
> > > EP driver.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - New mechanism for layerscape EP driver.
> >
> > Was there a v1 of this patch?
> >
> > >
> > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > > ++++++++++++++++++++------
> > > 1 file changed, 58 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > index 7ca5fe8..2a66f07 100644
> > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > @@ -20,27 +20,29 @@
> > >
> > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > >
> > > -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)
> > > +
> > > +struct ls_pcie_ep_drvdata {
> > > + u32 func_offset;
> > > + const struct dw_pcie_ep_ops *ops;
> > > + const struct dw_pcie_ops *dw_pcie_ops;
> > > };
> > >
> > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > +struct ls_pcie_ep {
> > > + struct dw_pcie *pci;
> > > + struct pci_epc_features *ls_epc;
> > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > >
> > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > return 0;
> > > }
> > >
> > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > .start_link = ls_pcie_establish_link, };
> > >
> > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > - { .compatible = "fsl,ls-pcie-ep",},
> > > - { },
> > > -};
> > > -
> > > static const struct pci_epc_features* ls_pcie_ep_get_features(struct
> > > dw_pcie_ep *ep) { @@ -82,10 +84,44 @@ static int
> > > ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > }
> > > }
> > >
> > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > > + u8 func_no)
> > > +{
> > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > + u8 header_type;
> > > +
> > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > +
> > > + if (header_type & (1 << 7))
> > > + return pcie->drvdata->func_offset * func_no;
> > > + else
> > > + return 0;
> >
> > It looks like there isn't a PCI define for multi function, the nearest I could find
> > was PCI_HEADER_TYPE_MULTIDEVICE in hotplug/ibmphp.h. A comment
> > above the test might be helpful to explain the test.
>
> OK, I will add a comment above this code.
>
> >
> > As the ls_pcie_ep_drvdata structures are static, the unset .func_offset will be
> > initialised to 0, so you could just drop the test above.
>
> Due to the different PCIe controller have different property, e.g. PCIe controller1 support
> multiple function feature, but PCIe controller2 don't support this feature, so I need to check
> which controller support it and return the correct offset value, but each board only have one
> ls_pcie_ep_drvdata, ^_^.
Yes but if they don't support the feature then func_offset will be 0.
>
> >
> > However something to the effect of the following may help spot
> > misconfiguration:
> >
> > WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > pcie->drvdata->func_offset * func_no;
> >
> > The WARN is probably quite useful as if you are attempting to use non-zero
> > functions and func_offset isn't set - then things may appear to work normally
> > but actually will break horribly.
>
> As discussion before, I think the func_offset should not depends on the function
> number, even if other platforms of NXP may be use write registers way to access
> the different function config space.
I agree that func_offset is an optional parameter. But if you are attempting
to determine the offset of a function and you are given a non-zero function
number - then something has gone wrong if func_offset is 0.
Thanks,
Andrew Murray
>
> I have added the comments above the code, as follow, do you have any advice?
> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> + u8 func_no)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> + u8 header_type;
> +
> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> +
> + /*
> + * Read the Header Type register of config space to check
> + * whether this PCI device support the multiple function.
> + */
> + if (header_type & (1 << 7))
> + return pcie->drvdata->func_offset * func_no;
> +
> + return 0;
> +}
>
> Thanks a lot for your detail comments.
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > +}
> > > +
> > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > .ep_init = ls_pcie_ep_init,
> > > .raise_irq = ls_pcie_ep_raise_irq,
> > > .get_features = ls_pcie_ep_get_features,
> > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > +
> > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > + .ops = &ls_pcie_ep_ops,
> > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > > +};
> > > +
> > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > + .func_offset = 0x20000,
> > > + .ops = &ls_pcie_ep_ops,
> > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > > +};
> > > +
> > > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > > + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > + { },
> > > };
> > >
> > > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -98,7
> > > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > > int ret;
> > >
> > > ep = &pci->ep;
> > > - ep->ops = &pcie_ep_ops;
> > > + ep->ops = pcie->drvdata->ops;
> > >
> > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "addr_space");
> > > if (!res)
> > > @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct
> > platform_device *pdev)
> > > 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))
> > > - return PTR_ERR(pci->dbi_base);
> > > + pcie->drvdata = of_device_get_match_data(dev);
> > >
> > > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > pci->dev = dev;
> > > - pci->ops = &ls_pcie_ep_ops;
> > > + pci->ops = pcie->drvdata->dw_pcie_ops;
> > > +
> > > pcie->pci = pci;
> > >
> > > ls_epc->linkup_notifier = false,
> > > @@ -152,6 +185,13 @@ static int __init ls_pcie_ep_probe(struct
> > > platform_device *pdev)
> > >
> > > pcie->ls_epc = ls_epc;
> > >
> > > + 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))
> > > + return PTR_ERR(pci->dbi_base);
> > > +
> > > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > +
> > > 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: [PATCH] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay
From: Maxime Ripard @ 2019-08-27 13:34 UTC (permalink / raw)
To: Jernej Skrabec
Cc: mark.rutland, devicetree, Ondrej Jirman, linux-sunxi,
linux-kernel, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20190825130336.14154-1-jernej.skrabec@siol.net>
[-- Attachment #1.1: Type: text/plain, Size: 690 bytes --]
On Sun, Aug 25, 2019 at 03:03:36PM +0200, Jernej Skrabec wrote:
> Depending on kernel and bootloader configuration, it's possible that
> Realtek ethernet PHY isn't powered on properly. It needs some time
> before it can be used.
>
> Fix that by adding 100ms ramp delay to regulator responsible for
> powering PHY.
>
> Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
> Suggested-by: Ondrej Jirman <megous@megous.com>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
How was that delay found?
It should at least have a comment explaining why it's there.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-08-27 13:35 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org; +Cc: linux-imx@nxp.com
Hi,
We are updating our kernel on our custom board with an iMX6UL from 3.14
to 4.19, and when loading linux-firmware/imx/sdma/sdma-imx6q.bin v3.5
the kernel hangs when booting, only "Starting kernel ..." is printed (by
uBoot I think).
When I remove the sdma bin (built-in the kernel via EXTRA_FIRMWARE),
then it boots.
I found that the slab allocator (menu config -> General setup -> Choose
SLAB allocator) is the culprit: when using imx_v6_v7_defconfig the
kernel boots, but not with our config (based on a tiny config I think).
And the config that makes the difference is the slab allocator: with
SLUB or SLAB the kernel (with sdma bin) boots, but not with SLOB.
I don't know how to force selecting SLUB in Kconfig when selecting
IMX_SDMA, but anyhow first this issue must be confirmed on other
processors from the iMX family.
Kind Regards,
Jürgen Lambrecht
_______________________________________________
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 02/20] dt-bindings: arm: Convert Marvell MMP board/soc bindings to json-schema
From: Rob Herring @ 2019-08-27 13:36 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <136a57cf3d293e3233f31d5ee660a6418726333a.camel@v3.sk>
On Tue, Aug 27, 2019 at 8:24 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> On Tue, 2019-08-27 at 06:59 -0500, Rob Herring wrote:
> > On Thu, Aug 22, 2019 at 4:27 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
> > > Convert Marvell MMP SoC bindings to DT schema format using json-schema.
> > >
> > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> > >
> > > ---
> > > Changes since v1:
> > > - Added this patch
> > >
> > > .../devicetree/bindings/arm/mrvl/mrvl.txt | 14 ---------
> > > .../devicetree/bindings/arm/mrvl/mrvl.yaml | 31 +++++++++++++++++++
> > > 2 files changed, 31 insertions(+), 14 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > create mode 100644 Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > deleted file mode 100644
> > > index 951687528efb0..0000000000000
> > > --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > +++ /dev/null
> > > @@ -1,14 +0,0 @@
> > > -Marvell Platforms Device Tree Bindings
> > > -----------------------------------------------------
> > > -
> > > -PXA168 Aspenite Board
> > > -Required root node properties:
> > > - - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
> > > -
> > > -PXA910 DKB Board
> > > -Required root node properties:
> > > - - compatible = "mrvl,pxa910-dkb";
> > > -
> > > -MMP2 Brownstone Board
> > > -Required root node properties:
> > > - - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> > > new file mode 100644
> > > index 0000000000000..dc9de506ac6e3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
> > > @@ -0,0 +1,31 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Marvell Platforms Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Lubomir Rintel <lkundrak@v3.sk>
> > > +
> > > +properties:
> > > + $nodename:
> > > + const: '/'
> > > + compatible:
> > > + oneOf:
> > > + - description: PXA168 Aspenite Board
> > > + items:
> > > + - enum:
> > > + - mrvl,pxa168-aspenite
> > > + - const: mrvl,pxa168
> > > + - description: PXA910 DKB Board
> > > + items:
> > > + - enum:
> > > + - mrvl,pxa910-dkb
> >
> > Doesn't match what's in dts file:
> >
> > arch/arm/boot/dts/pxa910-dkb.dts: compatible =
> > "mrvl,pxa910-dkb", "mrvl,pxa910";
>
> It corresponds to the .txt bindings specification this commit is
> converting. I thought it wouldn't be a good idea to do any changes to
> the contents at the time the conversion is done.
There are so many errors like this, that it's fine to do it in the
conversion. A separate patch is fine too.
> I also don't understand why does the dts file specify the board-
> specific compatible string. Surely "mrvl,pxa910" alone would be
> sufficient?
To potentially work around any board specific issue without a dtb change.
>
> > > + - description: MMP2 Brownstone Board
> >
> > If this entry is only for this board...
> >
> > > + items:
> > > + - enum:
> > > + - mrvl,mmp2-brownstone
> >
> > ...then this can be a 'const' instead. Same for the others.
>
> Sure, but is it preferable? I've actually done a "git grep -A3 enum
> Documentation/devicetree/bindings/" to see if the single-element is
> typically used and it seems like it is. Perhaps it's a good idea to
> indicate to a human reader that this is a list that's expected to
> eventually be extended with new elements.
Then the description should match and say 'MMP2 based boards'.
> In any case, there are more boards with MMP2 currently supported,
> notably the XO-1.75 laptop. I've actually sent out the dts file for
> review some time ago. I haven't added a separate compatible string for
> it because I thought it is not necessary (see above).
You should add one.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Continuous SD IO causes hung task messages
From: Russell King - ARM Linux admin @ 2019-08-27 13:43 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, linux-mmc
Hi,
While dd'ing the contents of a SD card, I get hung task timeout
messages as per below. However, the dd is making progress. Any
ideas?
Presumably, mmc_rescan doesn't get a look-in while IO is progressing
for the card?
ARM64 host, Macchiatobin, uSD card.
Thanks.
root@arm-d06300000000:~# dd if=/dev/mmcblk1 | md5sum
INFO: task kworker/2:1:52 blocked for more than 120 seconds.
Not tainted 5.2.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/2:1 D 0 52 2 0x00000028
Workqueue: events_freezable mmc_rescan
Call trace:
__switch_to+0xb0/0x198
__schedule+0x22c/0x604
schedule+0x38/0xc8
__mmc_claim_host+0xcc/0x1ec
mmc_get_card+0x30/0x3c
mmc_sd_detect+0x1c/0x78
mmc_rescan+0x1c4/0x35c
process_one_work+0x14c/0x408
worker_thread+0x140/0x3f4
kthread+0xfc/0x128
ret_from_fork+0x10/0x18
INFO: task kworker/2:1:52 blocked for more than 120 seconds.
Not tainted 5.2.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/2:1 D 0 52 2 0x00000028
Workqueue: events_freezable mmc_rescan
Call trace:
__switch_to+0xb0/0x198
__schedule+0x22c/0x604
schedule+0x38/0xc8
__mmc_claim_host+0xcc/0x1ec
mmc_get_card+0x30/0x3c
mmc_sd_detect+0x1c/0x78
mmc_rescan+0x1c4/0x35c
process_one_work+0x14c/0x408
worker_thread+0x140/0x3f4
kthread+0xfc/0x128
ret_from_fork+0x10/0x18
INFO: task kworker/2:1:52 blocked for more than 241 seconds.
Not tainted 5.2.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/2:1 D 0 52 2 0x00000028
Workqueue: events_freezable mmc_rescan
Call trace:
__switch_to+0xb0/0x198
__schedule+0x22c/0x604
schedule+0x38/0xc8
__mmc_claim_host+0xcc/0x1ec
mmc_get_card+0x30/0x3c
mmc_sd_detect+0x1c/0x78
mmc_rescan+0x1c4/0x35c
process_one_work+0x14c/0x408
worker_thread+0x140/0x3f4
kthread+0xfc/0x128
ret_from_fork+0x10/0x18
INFO: task kworker/2:1:52 blocked for more than 362 seconds.
Not tainted 5.2.0+ #309
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/2:1 D 0 52 2 0x00000028
Workqueue: events_freezable mmc_rescan
Call trace:
__switch_to+0xb0/0x198
__schedule+0x22c/0x604
schedule+0x38/0xc8
__mmc_claim_host+0xcc/0x1ec
mmc_get_card+0x30/0x3c
mmc_sd_detect+0x1c/0x78
mmc_rescan+0x1c4/0x35c
process_one_work+0x14c/0x408
worker_thread+0x140/0x3f4
kthread+0xfc/0x128
ret_from_fork+0x10/0x18
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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 3/5] perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
From: Arnaldo Carvalho de Melo @ 2019-08-27 13:44 UTC (permalink / raw)
To: Igor Lubashev
Cc: Mathieu Poirier, Suzuki Poulouse, Alexander Shishkin,
Alexey Budankov, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-4-git-send-email-ilubashe@akamai.com>
Em Mon, Aug 26, 2019 at 09:39:14PM -0400, Igor Lubashev escreveu:
> Perf was too restrictive about sysctl kernel.perf_event_paranoid. The
> kernel only disallows profiling when perf_event_paranoid > 1. Make perf do
> the same.
Thanks for following up on this, I added these notes to this cset commit
log message:
--------------------------------- 8< ------------------------------------
perf evsel: Kernel profiling is disallowed only when perf_event_paranoid > 1
Perf was too restrictive about sysctl kernel.perf_event_paranoid. The
kernel only disallows profiling when perf_event_paranoid > 1. Make perf
do the same.
Committer testing:
For a non-root user:
$ id
uid=1000(acme) gid=1000(acme) groups=1000(acme),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$
Before:
We were restricting it to just userspace (:u suffix) even for a
workload started by the user:
$ perf record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
$ perf evlist
cycles:u
$ perf evlist -v
cycles:u: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, read_format: ID, disabled: 1, inherit: 1, exclude_kernel: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
# Total Lost Samples: 0
#
# Samples: 8 of event 'cycles:u'
# Event count (approx.): 1040396
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ......................
#
68.36% sleep libc-2.29.so [.] _dl_addr
27.33% sleep ld-2.29.so [.] dl_main
3.80% sleep ld-2.29.so [.] _dl_setup_hash
#
# (Tip: Order by the overhead of source file name and line number: perf report -s srcline)
#
$
$
After:
When the kernel allows profiling the kernel in that scenario:
$ perf record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.023 MB perf.data (11 samples) ]
$ perf evlist
cycles
$ perf evlist -v
cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1
$
$ perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
# Total Lost Samples: 0
#
# Samples: 11 of event 'cycles'
# Event count (approx.): 1601964
#
# Overhead Command Shared Object Symbol
# ........ ....... ................ ..........................
#
28.14% sleep [kernel.vmlinux] [k] __rb_erase_color
27.21% sleep [kernel.vmlinux] [k] unmap_page_range
27.20% sleep ld-2.29.so [.] __tunable_get_val
15.24% sleep [kernel.vmlinux] [k] thp_get_unmapped_area
1.96% perf [kernel.vmlinux] [k] perf_event_exec
0.22% perf [kernel.vmlinux] [k] native_sched_clock
0.02% perf [kernel.vmlinux] [k] intel_bts_enable_local
0.00% perf [kernel.vmlinux] [k] native_write_msr
#
# (Tip: Boolean options have negative forms, e.g.: perf report --no-children)
#
$
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1566869956-7154-4-git-send-email-ilubashe@akamai.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author: Igor Lubashev <ilubashe@akamai.com>
# Date: Mon Aug 26 21:39:14 2019 -0400
#
# On branch perf/core
# Changes to be committed:
# modified: tools/perf/util/evsel.c
#
# Untracked files:
# a
# a.c
# bla
# f_mode
# perf.data
# perf.data.old
# q
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7c704b8f0e5c..d4540bfe4574 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -282,7 +282,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return perf_event_paranoid_check(-1);
+ return perf_event_paranoid_check(1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
_______________________________________________
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] mt76: mt7603: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-27 13:44 UTC (permalink / raw)
To: nbd, lorenzo.bianconi83, ryder.lee, royluo, kvalo, davem,
matthias.bgg, swboyd, yuehaibing, weiyongjun1
Cc: netdev, linux-mediatek, linux-wireless, linux-kernel,
linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/mediatek/mt76/mt7603/soc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
index c6c1ce6..c22715e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/soc.c
@@ -9,7 +9,6 @@
static int
mt76_wmac_probe(struct platform_device *pdev)
{
- struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct mt7603_dev *dev;
void __iomem *mem_base;
struct mt76_dev *mdev;
@@ -20,7 +19,7 @@ mt76_wmac_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- mem_base = devm_ioremap_resource(&pdev->dev, res);
+ mem_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(mem_base)) {
dev_err(&pdev->dev, "Failed to get memory resource\n");
return PTR_ERR(mem_base);
--
2.7.4
_______________________________________________
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 net-next] phy: mdio-bcm-iproc: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-27 13:46 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, rjui, sbranden
Cc: netdev, YueHaibing, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/mdio-bcm-iproc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
index 7d0f388..7e9975d 100644
--- a/drivers/net/phy/mdio-bcm-iproc.c
+++ b/drivers/net/phy/mdio-bcm-iproc.c
@@ -123,15 +123,13 @@ static int iproc_mdio_probe(struct platform_device *pdev)
{
struct iproc_mdio_priv *priv;
struct mii_bus *bus;
- struct resource *res;
int rc;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->base = devm_ioremap_resource(&pdev->dev, res);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
dev_err(&pdev->dev, "failed to ioremap register\n");
return PTR_ERR(priv->base);
--
2.7.4
_______________________________________________
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 v2] ARM: kirkwood: ts219: disable the SoC's RTC
From: Gregory CLEMENT @ 2019-08-27 13:47 UTC (permalink / raw)
To: Uwe Kleine-König, Jason Cooper, Sebastian Hesselbarth
Cc: Andrew Lunn, Alexandre Belloni, tbm, linux-arm-kernel,
Oliver Hartkopp
In-Reply-To: <20190731223233.GA15900@taurus.defre.kleine-koenig.org>
Hi Uwe Kleine-König,
> The internal RTC doesn't work, loading the driver only yields
>
> rtc-mv f1010300.rtc: internal RTC not ticking
>
> . So disable it.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Applied on mvebu/dt with both acked-by
Thanks,
Gregory
> ---
> Hello,
>
> This patch is (one) result of a discussion on the rtc list. v1 was sent
> there only. This v2 is just a resend to the mvebu maintainers.
>
> Alexandre Belloni said to v1: Seems good to me then.
>
> This sounds a bit like an ack, but I didn't add it as it was not
> explicit.
>
> Best regards
> Uwe
>
> arch/arm/boot/dts/kirkwood-ts219.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> index a88eb22070a1..994cabcf4b51 100644
> --- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
> @@ -104,3 +104,11 @@
> &pcie0 {
> status = "okay";
> };
> +
> +&rtc {
> + /*
> + * There is a s35390a available on the i2c bus, the internal rtc isn't
> + * working (probably no crystal assembled).
> + */
> + status = "disabled";
> +};
> --
> 2.20.1
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.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: [PATCH] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay
From: Ondřej Jirman @ 2019-08-27 13:48 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, Jernej Skrabec, linux-sunxi,
linux-kernel, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20190827133443.fdxl5wjmgkerc3uh@flea>
Hi,
On Tue, Aug 27, 2019 at 03:34:43PM +0200, Maxime Ripard wrote:
> On Sun, Aug 25, 2019 at 03:03:36PM +0200, Jernej Skrabec wrote:
> > Depending on kernel and bootloader configuration, it's possible that
> > Realtek ethernet PHY isn't powered on properly. It needs some time
> > before it can be used.
> >
> > Fix that by adding 100ms ramp delay to regulator responsible for
> > powering PHY.
> >
> > Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
> > Suggested-by: Ondrej Jirman <megous@megous.com>
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>
> How was that delay found?
I suggested it. There's no delay in the dwmac-sun8i driver, so after enabling
the phy power, it will start accessing it over MDIO right away, which is not
good.
I suggested the value based on post-reset delay in the PHY's datasheet (30ms).
Multiplied ~3x (if I remember correctly) to get some safety margin. Chip has
more to do then after the HW reset, and regulator also needs some time to
ramp-up.
regards,
o.
> It should at least have a comment explaining why it's there.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.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: [PATCH] Documentation: add link to stm32mp157 docs
From: Jonathan Corbet @ 2019-08-27 13:48 UTC (permalink / raw)
To: Gerald BAEZA
Cc: Alexandre TORGUE, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566908347-92201-1-git-send-email-gerald.baeza@st.com>
On Tue, 27 Aug 2019 12:19:32 +0000
Gerald BAEZA <gerald.baeza@st.com> wrote:
> Link to the online stm32mp157 documentation added
> in the overview.
>
> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
> ---
> Documentation/arm/stm32/stm32mp157-overview.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
> index f62fdc8..8d5a476 100644
> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
> @@ -14,6 +14,12 @@ It features:
> - Standard connectivity, widely inherited from the STM32 MCU family
> - Comprehensive security support
>
> +Resources
> +---------
> +
> +Datasheet and reference manual are publicly available on ST website:
> +.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
> +
Adding the URL is a fine idea. But you don't need the extra syntax to
create a link if you're not going to actually make a link out of it. So
I'd take the ".. _STM32MP157:" part out and life will be good.
Thanks,
jon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next] phy: mdio-mux-meson-g12a: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-27 13:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, khilman
Cc: netdev, YueHaibing, linux-kernel, linux-arm-kernel, linux-amlogic
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/mdio-mux-meson-g12a.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-meson-g12a.c b/drivers/net/phy/mdio-mux-meson-g12a.c
index 6644762..7a9ad54 100644
--- a/drivers/net/phy/mdio-mux-meson-g12a.c
+++ b/drivers/net/phy/mdio-mux-meson-g12a.c
@@ -302,7 +302,6 @@ static int g12a_mdio_mux_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct g12a_mdio_mux *priv;
- struct resource *res;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -311,8 +310,7 @@ static int g12a_mdio_mux_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->regs = devm_ioremap_resource(dev, res);
+ priv->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
--
2.7.4
_______________________________________________
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] mmc: bcm2835: Take SWIOTLB memory size limitation into account
From: Ulf Hansson @ 2019-08-27 13:49 UTC (permalink / raw)
To: Stefan Wahren
Cc: Florian Fainelli, Scott Branden, Ray Jui,
linux-mmc@vger.kernel.org, Eric Anholt, Lukas Wunner, Linux ARM
In-Reply-To: <1566628264-3289-1-git-send-email-wahrenst@gmx.net>
On Sat, 24 Aug 2019 at 08:31, Stefan Wahren <wahrenst@gmx.net> wrote:
>
> Make sure the sdhost driver doesn't use requests bigger than SWIOTLB
> can handle.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Applies for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/bcm2835.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
> index 7e0d3a4..7ec0d95 100644
> --- a/drivers/mmc/host/bcm2835.c
> +++ b/drivers/mmc/host/bcm2835.c
> @@ -1314,7 +1314,7 @@ static int bcm2835_add_host(struct bcm2835_host *host)
> }
>
> mmc->max_segs = 128;
> - mmc->max_req_size = 524288;
> + mmc->max_req_size = min_t(size_t, 524288, dma_max_mapping_size(dev));
> mmc->max_seg_size = mmc->max_req_size;
> mmc->max_blk_size = 1024;
> mmc->max_blk_count = 65535;
> --
> 2.7.4
>
_______________________________________________
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] dt-bindings: mmc: aspeed: Update example ranges property
From: Ulf Hansson @ 2019-08-27 13:49 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, DTML, linux-aspeed, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Joel Stanley, Linux ARM
In-Reply-To: <20190826021620.11915-1-andrew@aj.id.au>
On Mon, 26 Aug 2019 at 04:15, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> The example node in the binding uses the AST2500 compatible string for
> the SD controller with a 64kiB ranges property, but the SD controller is
> allocated 128kiB of MMIO space according to the AST2500 datasheet. Fix
> the example to correctly reflect the hardware in the AST2500, however it
> should be noted that the MMIO region is reduced to 64kiB in the AST2600
> where a second SD controller block has been introduced into the address
> space.
>
> Also add the IBM copyright header that I left out of the initial patch.
>
> Suggested-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Applied for next, thanks!
FYI, I took the liberty to amend all aspeed patches, by putting
"sdhci-of-aspeed" as the prefix of the commit message header.
Kind regards
Uffe
> ---
> Hi Ulf, this is the follow-up fix as discussed here:
>
> http://patchwork.ozlabs.org/patch/1143090/
>
> Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> index 570f8c72662b..200de9396036 100644
> --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-or-later
> +# Copyright 2019 IBM Corp.
> %YAML 1.2
> ---
> $id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
> @@ -84,7 +85,7 @@ examples:
> reg = <0x1e740000 0x100>;
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <0 0x1e740000 0x10000>;
> + ranges = <0 0x1e740000 0x20000>;
> clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
>
> sdhci0: sdhci@100 {
> --
> 2.20.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 -next] mmc: aspeed: Fix return value check in aspeed_sdc_probe()
From: Ulf Hansson @ 2019-08-27 13:49 UTC (permalink / raw)
To: Julia Lawall, Dan Carpenter, Andrew Jeffery, Wei Yongjun
Cc: linux-aspeed, linux-mmc, kernel-janitors, Adrian Hunter,
Joel Stanley, Linux ARM
In-Reply-To: <alpine.DEB.2.21.1908270845410.2537@hadrien>
On Tue, 27 Aug 2019 at 02:47, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
>
> On Tue, 27 Aug 2019, Andrew Jeffery wrote:
>
> >
> >
> > On Mon, 26 Aug 2019, at 22:34, Dan Carpenter wrote:
> > > > Fixes: 09eed7fffd33 ("mmc: Add support for the ASPEED SD controller")
> > > ^^^^
> > > When we're adding new files, could we use the prefix for the new driver
> > > instead of just the subsystem? "mmc: aspeed: Add new driver"?
> > > Otherwise it's tricky to know what people want for the driver.
> >
> > I don't have any issue with the request, but I don't understand this last
> > bit. What do you mean by "it's tricky to know what people want for the
> > driver"?
>
> There is no obvious algorithm that tells how to go from a file name to an
> appropriate subject line prefix.
For MMC we normally use the name of the host driver file (excluding
".c") as part of the prefix.
For this case that means I amended the header into: mmc:
sdhci-of-aspeed: Fix return value check in aspeed_sdc_probe() and
applied it for next.
I also took the liberty to change this for the other related patches
for the "aspeed" driver to follow the same pattern.
Kind regards
Uffe
_______________________________________________
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 v1 1/2] dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM eMMC
From: Ulf Hansson @ 2019-08-27 13:49 UTC (permalink / raw)
To: Ramuthevar, Vadivel MuruganX
Cc: Mark Rutland, DTML, qi-ming.wu, andriy.shevchenko, cheol.yong.kim,
linux-mmc@vger.kernel.org, Michal Simek,
Linux Kernel Mailing List, Rob Herring, Adrian Hunter, Linux ARM
In-Reply-To: <20190826072800.38413-1-vadivel.muruganx.ramuthevar@linux.intel.com>
On Mon, 26 Aug 2019 at 09:28, Ramuthevar,Vadivel MuruganX
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> Add a new compatible to use the sdhc-arasan host controller driver
> with the eMMC PHY on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 1edbb049cccb..7ca0aa7ccc0b 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -17,6 +17,8 @@ Required Properties:
> For this device it is strongly suggested to include arasan,soc-ctl-syscon.
> - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY
> Note: This binding has been deprecated and moved to [5].
> + - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY
> + For this device it is strongly suggested to include arasan,soc-ctl-syscon.
>
> [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
>
> @@ -80,3 +82,18 @@ Example:
> phy-names = "phy_arasan";
> #clock-cells = <0>;
> };
> +
> + emmc: sdhci@ec700000 {
> + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1";
> + reg = <0xec700000 0x300>;
> + interrupt-parent = <&ioapic1>;
> + interrupts = <44 1>;
> + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>,
> + <&cgu0 LGM_GCLK_EMMC>;
> + clock-names = "clk_xin", "clk_ahb", "gate";
> + clock-output-names = "emmc_cardclock";
> + #clock-cells = <0>;
> + phys = <&emmc_phy>;
> + phy-names = "phy_arasan";
> + arasan,soc-ctl-syscon = <&sysconf>;
> + };
> --
> 2.11.0
>
_______________________________________________
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 v1 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM eMMC
From: Ulf Hansson @ 2019-08-27 13:49 UTC (permalink / raw)
To: Ramuthevar, Vadivel MuruganX
Cc: Mark Rutland, DTML, qi-ming.wu, andriy.shevchenko, cheol.yong.kim,
linux-mmc@vger.kernel.org, Michal Simek,
Linux Kernel Mailing List, Rob Herring, Adrian Hunter, Linux ARM
In-Reply-To: <20190826072800.38413-2-vadivel.muruganx.ramuthevar@linux.intel.com>
On Mon, 26 Aug 2019 at 09:28, Ramuthevar,Vadivel MuruganX
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
> From: Ramuthevar Vadivel Muruganx <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> The current arasan sdhci PHY configuration isn't compatible
> with the PHY on Intel's LGM(Lightning Mountain) SoC devices.
>
> Therefore, add a new compatible, to adapt the Intel's LGM
> eMMC PHY with arasan-sdhc controller to configure the PHY.
>
> Signed-off-by: Ramuthevar Vadivel Muruganx <vadivel.muruganx.ramuthevar@linux.intel.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index b12abf9b15f2..7023cbec4017 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -114,6 +114,12 @@ static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> .hiword_update = true,
> };
>
> +static const struct sdhci_arasan_soc_ctl_map intel_lgm_emmc_soc_ctl_map = {
> + .baseclkfreq = { .reg = 0xa0, .width = 8, .shift = 2 },
> + .clockmultiplier = { .reg = 0, .width = -1, .shift = -1 },
> + .hiword_update = false,
> +};
> +
> /**
> * sdhci_arasan_syscon_write - Write to a field in soc_ctl registers
> *
> @@ -373,6 +379,11 @@ static struct sdhci_arasan_of_data sdhci_arasan_rk3399_data = {
> .pdata = &sdhci_arasan_cqe_pdata,
> };
>
> +static struct sdhci_arasan_of_data intel_lgm_emmc_data = {
> + .soc_ctl_map = &intel_lgm_emmc_soc_ctl_map,
> + .pdata = &sdhci_arasan_cqe_pdata,
> +};
> +
> #ifdef CONFIG_PM_SLEEP
> /**
> * sdhci_arasan_suspend - Suspend method for the driver
> @@ -474,6 +485,10 @@ static const struct of_device_id sdhci_arasan_of_match[] = {
> .compatible = "rockchip,rk3399-sdhci-5.1",
> .data = &sdhci_arasan_rk3399_data,
> },
> + {
> + .compatible = "intel,lgm-sdhci-5.1-emmc",
> + .data = &intel_lgm_emmc_data,
> + },
> /* Generic compatible below here */
> {
> .compatible = "arasan,sdhci-8.9a",
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next] phy: mdio-sun4i: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-27 13:50 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, mripard, wens
Cc: netdev, YueHaibing, linux-kernel, linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/mdio-sun4i.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/phy/mdio-sun4i.c b/drivers/net/phy/mdio-sun4i.c
index 20ffd8f..58d6504 100644
--- a/drivers/net/phy/mdio-sun4i.c
+++ b/drivers/net/phy/mdio-sun4i.c
@@ -92,7 +92,6 @@ static int sun4i_mdio_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct mii_bus *bus;
struct sun4i_mdio_data *data;
- struct resource *res;
int ret;
bus = mdiobus_alloc_size(sizeof(*data));
@@ -106,8 +105,7 @@ static int sun4i_mdio_probe(struct platform_device *pdev)
bus->parent = &pdev->dev;
data = bus->priv;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- data->membase = devm_ioremap_resource(&pdev->dev, res);
+ data->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(data->membase)) {
ret = PTR_ERR(data->membase);
goto err_out_free_mdiobus;
--
2.7.4
_______________________________________________
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: Continuous SD IO causes hung task messages
From: Ulf Hansson @ 2019-08-27 13:55 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-mmc@vger.kernel.org, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20190827134337.GK13294@shell.armlinux.org.uk>
On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Hi,
>
> While dd'ing the contents of a SD card, I get hung task timeout
> messages as per below. However, the dd is making progress. Any
> ideas?
>
> Presumably, mmc_rescan doesn't get a look-in while IO is progressing
> for the card?
Is it a regression?
There not much of recent mmc core and mmc block changes, that I can
think of at this point.
>
> ARM64 host, Macchiatobin, uSD card.
What mmc host driver is it? mmci?
Kind regards
Uffe
>
> Thanks.
>
> root@arm-d06300000000:~# dd if=/dev/mmcblk1 | md5sum
> INFO: task kworker/2:1:52 blocked for more than 120 seconds.
> Not tainted 5.2.0+ #309
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/2:1 D 0 52 2 0x00000028
> Workqueue: events_freezable mmc_rescan
> Call trace:
> __switch_to+0xb0/0x198
> __schedule+0x22c/0x604
> schedule+0x38/0xc8
> __mmc_claim_host+0xcc/0x1ec
> mmc_get_card+0x30/0x3c
> mmc_sd_detect+0x1c/0x78
> mmc_rescan+0x1c4/0x35c
> process_one_work+0x14c/0x408
> worker_thread+0x140/0x3f4
> kthread+0xfc/0x128
> ret_from_fork+0x10/0x18
> INFO: task kworker/2:1:52 blocked for more than 120 seconds.
> Not tainted 5.2.0+ #309
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/2:1 D 0 52 2 0x00000028
> Workqueue: events_freezable mmc_rescan
> Call trace:
> __switch_to+0xb0/0x198
> __schedule+0x22c/0x604
> schedule+0x38/0xc8
> __mmc_claim_host+0xcc/0x1ec
> mmc_get_card+0x30/0x3c
> mmc_sd_detect+0x1c/0x78
> mmc_rescan+0x1c4/0x35c
> process_one_work+0x14c/0x408
> worker_thread+0x140/0x3f4
> kthread+0xfc/0x128
> ret_from_fork+0x10/0x18
> INFO: task kworker/2:1:52 blocked for more than 241 seconds.
> Not tainted 5.2.0+ #309
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/2:1 D 0 52 2 0x00000028
> Workqueue: events_freezable mmc_rescan
> Call trace:
> __switch_to+0xb0/0x198
> __schedule+0x22c/0x604
> schedule+0x38/0xc8
> __mmc_claim_host+0xcc/0x1ec
> mmc_get_card+0x30/0x3c
> mmc_sd_detect+0x1c/0x78
> mmc_rescan+0x1c4/0x35c
> process_one_work+0x14c/0x408
> worker_thread+0x140/0x3f4
> kthread+0xfc/0x128
> ret_from_fork+0x10/0x18
> INFO: task kworker/2:1:52 blocked for more than 362 seconds.
> Not tainted 5.2.0+ #309
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/2:1 D 0 52 2 0x00000028
> Workqueue: events_freezable mmc_rescan
> Call trace:
> __switch_to+0xb0/0x198
> __schedule+0x22c/0x604
> schedule+0x38/0xc8
> __mmc_claim_host+0xcc/0x1ec
> mmc_get_card+0x30/0x3c
> mmc_sd_detect+0x1c/0x78
> mmc_rescan+0x1c4/0x35c
> process_one_work+0x14c/0x408
> worker_thread+0x140/0x3f4
> kthread+0xfc/0x128
> ret_from_fork+0x10/0x18
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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: marvell: armada-37xx: add mailbox node
From: Gregory CLEMENT @ 2019-08-27 13:58 UTC (permalink / raw)
To: Marek Behún, linux-arm-kernel; +Cc: Miquel Raynal, Marek Behún
In-Reply-To: <20190812163003.23016-1-marek.behun@nic.cz>
Hi Marek,
> This adds the rWTM BIU mailbox node for communication with the secure
> processor. The driver already exists in
> drivers/mailbox/armada-37xx-rwtm-mailbox.c.
>
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
> Cc: Gregory Clement <gregory.clement@bootlin.com>
> Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index f43c43168b00..7f69e3dfcb13 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -419,6 +419,13 @@
> clocks = <&nb_periph_clk 15>;
> };
>
> + rwtm: mailbox@b0000 {
> + compatible = "marvell,armada-3700-rwtm-mailbox";
> + reg = <0xb0000 0x100>;
> + interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> + #mbox-cells = <1>;
> + };
> +
> sdhci1: sdhci@d0000 {
> compatible = "marvell,armada-3700-sdhci",
> "marvell,sdhci-xenon";
> --
> 2.21.0
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: stm32-dcmi: Delete an unnecessary of_node_put() call in dcmi_probe()
From: Markus Elfring @ 2019-08-27 14:09 UTC (permalink / raw)
To: linux-media, linux-stm32, linux-arm-kernel, Alexandre Torgue,
Hugues Fruchet, Mauro Carvalho Chehab, Maxime Coquelin
Cc: kernel-janitors, LKML
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 27 Aug 2019 16:00:13 +0200
A null pointer would be passed to a call of the function “of_node_put”
immediately after a call of the function “of_graph_get_next_endpoint”
failed at one place.
Remove this superfluous function call.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/media/platform/stm32/stm32-dcmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index cb1daf8217ff..9392e3409fba 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -1861,7 +1861,6 @@ static int dcmi_probe(struct platform_device *pdev)
np = of_graph_get_next_endpoint(np, NULL);
if (!np) {
dev_err(&pdev->dev, "Could not find the endpoint\n");
- of_node_put(np);
return -ENODEV;
}
--
2.23.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
* [PATCHv6] drivers/amba: add reset control to amba bus probe
From: Dinh Nguyen @ 2019-08-27 14:11 UTC (permalink / raw)
To: linux-kernel
Cc: robh, daniel.thompson, tony.luck, manivannan.sadhasivam, keescook,
devicetree, linus.walleij, anton, linux, dinguyen, p.zabel,
ccross, frowand.list, linux-arm-kernel
The primecell controller on some SoCs, i.e. SoCFPGA, is held in reset by
default. Until recently, the DMA controller was brought out of reset by the
bootloader(i.e. U-Boot). But a recent change in U-Boot, the peripherals
that are not used are held in reset and are left to Linux to bring them
out of reset.
Add a mechanism for getting the reset property and de-assert the primecell
module from reset if found. This is a not a hard fail if the reset properti
is not present in the device tree node, so the driver will continue to
probe.
Because there are different variants of the controller that may have
multiple reset signals, the code will find all reset(s) specified and
de-assert them.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v6: remove the need to reset_control_get_count as
of_reset_control_array_get_optional_shared is already doing that
v5: use of_reset_control_array_get_optional_shared()
v4: cleaned up indentation in loop
fix up a few checkpatch warnings
add Reviewed-by:
v3: add a reset_control_put()
add error handling
v2: move reset control to bus code
find all reset properties and de-assert them
---
drivers/amba/bus.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 100e798a5c82..f39f075abff9 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -18,6 +18,7 @@
#include <linux/limits.h>
#include <linux/clk/clk-conf.h>
#include <linux/platform_device.h>
+#include <linux/reset.h>
#include <asm/irq.h>
@@ -401,6 +402,19 @@ static int amba_device_try_add(struct amba_device *dev, struct resource *parent)
ret = amba_get_enable_pclk(dev);
if (ret == 0) {
u32 pid, cid;
+ struct reset_control *rstc;
+
+ /*
+ * Find reset control(s) of the amba bus and de-assert them.
+ */
+ rstc = of_reset_control_array_get_optional_shared(dev->dev.of_node);
+ if (IS_ERR(rstc)) {
+ if (PTR_ERR(rstc) != -EPROBE_DEFER)
+ dev_err(&dev->dev, "Can't get amba reset!\n");
+ return PTR_ERR(rstc);
+ }
+ reset_control_deassert(rstc);
+ reset_control_put(rstc);
/*
* Read pid and cid based on size of resource
--
2.20.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
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