* Re: [PATCH] pwm: mxs: use devm_platform_ioremap_resource() to simplify code
From: Uwe Kleine-König @ 2019-08-24 0:26 UTC (permalink / raw)
To: Anson Huang
Cc: Aisheng Dong, linux-pwm@vger.kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
thierry.reding@gmail.com, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB3PR0402MB3916423A6E334EDD4C06B884F5AB0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hello,
On Tue, Aug 20, 2019 at 05:56:40AM +0000, Anson Huang wrote:
> Gentle ping...
My impression[1] is that Thierry collects patches in bulk once or twice
per release cycle. The last two such bulks were between 5.2-rc6 and
5.2-rc7 and in the 5.2 merge window. So given we're at v5.3-rc5 now I
expect some action soon :-)
> > > From: Anson.Huang@nxp.com <Anson.Huang@nxp.com>
> > > Sent: Thursday, July 18, 2019 9:32 AM
> > >
> > > Use the new helper devm_platform_ioremap_resource() which wraps the
> > > platform_get_resource() and devm_ioremap_resource() together, to
> > > simplify the code.
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> >
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
[1] from git log --committer=Thierry --format=%ci drivers/pwm | cut -d\ -f1 | uniq -c
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 03/10] PCI: designware-ep: Move the function of getting MSI capability forward
From: Xiaowei Bao @ 2019-08-24 0:20 UTC (permalink / raw)
To: Andrew Murray
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: <20190823133837.GF14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月23日 21:39
> 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 03/10] PCI: designware-ep: Move the function of
> getting MSI capability forward
>
> On Thu, Aug 22, 2019 at 07:22:35PM +0800, Xiaowei Bao wrote:
> > Move the function of getting MSI capability to the front of init
> > function, because the init function of the EP platform driver will use
> > the return value by the function of getting MSI capability.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Thanks a lot, I think move this to ep_init is better.
>
> > ---
> > v2:
> > - No change.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index b8388f8..0a6c199 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -656,6 +656,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > if (ret < 0)
> > epc->max_functions = 1;
> >
> > + ep->msi_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSI);
> > +
> > + ep->msix_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSIX);
> > +
> > if (ep->ops->ep_init)
> > ep->ops->ep_init(ep);
> >
> > @@ -672,9 +676,6 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > dev_err(dev, "Failed to reserve memory for MSI/MSI-X\n");
> > return -ENOMEM;
> > }
> > - ep->msi_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSI);
> > -
> > - ep->msix_cap = dw_pcie_ep_find_capability(pci, PCI_CAP_ID_MSIX);
> >
> > offset = dw_pcie_ep_find_ext_capability(pci, PCI_EXT_CAP_ID_REBAR);
> > if (offset) {
> > --
> > 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 v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-08-24 0:18 UTC (permalink / raw)
To: Andrew Murray
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: <20190823142756.GI14582@e119886-lin.cambridge.arm.com>
> -----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?
Yes, but I don't know how to comments, ^_^
>
> >
> > 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.
Yes, I have not find the PCI_HEADER_TYPE_MULTIDEVICE define. OK, I will add
The comments in next version patch.
>
> 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.
OK, thanks
>
> 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;
Thanks a lot, this looks better.
>
> 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.
got it, thanks.
>
> 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
* [PATCH v2 3/6] pwm: atmel: replace loop in prescale calculation by ad-hoc calculation
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
The calculated values are the same with the modified algorithm. The only
difference is that the calculation is a bit more efficient.
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Changes since (implicit) v1 sent with Message-Id:
20190815214133.11134-3-uwe@kleine-koenig.org
- Added Claudiu's Ack
drivers/pwm/pwm-atmel.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index f497f84771f0..3786ab9db5cf 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -60,7 +60,7 @@ struct atmel_pwm_registers {
};
struct atmel_pwm_config {
- u32 max_period;
+ u32 period_bits;
};
struct atmel_pwm_data {
@@ -119,17 +119,27 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
{
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
unsigned long long cycles = state->period;
+ int shift;
/* Calculate the period cycles and prescale value */
cycles *= clk_get_rate(atmel_pwm->clk);
do_div(cycles, NSEC_PER_SEC);
- for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
- (*pres)++;
+ /*
+ * The register for the period length is cfg.period_bits bits wide.
+ * So for each bit the number of clock cycles is wider divide the input
+ * clock frequency by two using pres and shift cprd accordingly.
+ */
+ shift = fls(cycles) - atmel_pwm->data->cfg.period_bits;
- if (*pres > PWM_MAX_PRES) {
+ if (shift > PWM_MAX_PRES) {
dev_err(chip->dev, "pres exceeds the maximum value\n");
return -EINVAL;
+ } else if (shift > 0) {
+ *pres = shift;
+ cycles >>= *pres;
+ } else {
+ *pres = 0;
}
*cprd = cycles;
@@ -289,7 +299,7 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
},
.cfg = {
/* 16 bits to keep period and duty. */
- .max_period = 0xffff,
+ .period_bits = 16,
},
};
@@ -302,7 +312,7 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
},
.cfg = {
/* 16 bits to keep period and duty. */
- .max_period = 0xffff,
+ .period_bits = 16,
},
};
@@ -315,7 +325,7 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
},
.cfg = {
/* 32 bits to keep period and duty. */
- .max_period = 0xffffffff,
+ .period_bits = 32,
},
};
--
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 related
* [PATCH v2 4/6] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
This documents the my findings while reading through the driver and the
reference manual.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Changes since (implicit) v1 sent with Message-Id:
20190816093748.11769-1-uwe@kleine-koenig.org:
- Add some prosa to commit log
drivers/pwm/pwm-atmel.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 3786ab9db5cf..89f3a62f7541 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -7,6 +7,16 @@
*
* Links to reference manuals for the supported PWM chips can be found in
* Documentation/arm/microchip.rst.
+ *
+ * Limitations:
+ * - Periods start with the inactive level.
+ * - Hardware has to be stopped in general to update settings.
+ *
+ * Software bugs/possible improvements:
+ * - When atmel_pwm_apply() is called with state->enabled=false a change in
+ * state->polarity isn't honored.
+ * - Instead of sleeping to wait for a completed period, the interrupt
+ * functionality could be used.
*/
#include <linux/clk.h>
--
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 related
* [PATCH v2 6/6] pwm: atmel: implement .get_state()
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
This function reads back the configured parameters from the hardware. As
.apply rounds down (mostly) I'm rounding up in .get_state() to achieve
that applying a state just read from hardware is a no-op.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
New in v2
drivers/pwm/pwm-atmel.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 152c2b7dd6df..f788501ab6ca 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -295,8 +295,47 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
return 0;
}
+static void atmel_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
+ u32 sr, cmr;
+
+ sr = atmel_pwm_readl(atmel_pwm, PWM_SR);
+ cmr = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, PWM_CMR);
+
+ if (sr & (1 << pwm->hwpwm)) {
+ unsigned long rate = clk_get_rate(atmel_pwm->clk);
+ u32 cdty, cprd, pres;
+ u64 tmp;
+
+ pres = cmr & PWM_CMR_CPRE_MSK;
+
+ cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, atmel_pwm->data->regs.period);
+ tmp = (u64)cprd * NSEC_PER_SEC;
+ tmp <<= pres;
+ state->period = DIV64_U64_ROUND_UP(tmp, rate);
+
+ cdty = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, atmel_pwm->data->regs.duty);
+ tmp = (u64)cdty * NSEC_PER_SEC;
+ tmp <<= pres;
+ state->duty_cycle = DIV64_U64_ROUND_UP(tmp, rate);
+
+ state->enabled = true;
+ } else {
+ state->enabled = false;
+ }
+
+ if (cmr & PWM_CMR_CPOL)
+ state->polarity = PWM_POLARITY_INVERSED;
+ else
+ state->polarity = PWM_POLARITY_NORMAL;
+
+}
+
static const struct pwm_ops atmel_pwm_ops = {
.apply = atmel_pwm_apply,
+ .get_state = atmel_pwm_get_state,
.owner = THIS_MODULE,
};
--
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 related
* [PATCH v2 5/6] pwm: atmel: use atmel_pwm_writel in atmel_pwm_ch_writel; ditto for readl
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
This makes it a bit easier when instrumenting register access to only have
to add code in one place.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
New in v2
drivers/pwm/pwm-atmel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 89f3a62f7541..152c2b7dd6df 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -111,7 +111,7 @@ static inline u32 atmel_pwm_ch_readl(struct atmel_pwm_chip *chip,
{
unsigned long base = PWM_CH_REG_OFFSET + ch * PWM_CH_REG_SIZE;
- return readl_relaxed(chip->base + base + offset);
+ return atmel_pwm_readl(chip, base + offset);
}
static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
@@ -120,7 +120,7 @@ static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
{
unsigned long base = PWM_CH_REG_OFFSET + ch * PWM_CH_REG_SIZE;
- writel_relaxed(val, chip->base + base + offset);
+ atmel_pwm_writel(chip, base + offset, val);
}
static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
--
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 related
* [PATCH v2 2/6] pwm: atmel: use a constant for maximum prescale value
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
The maximal prescale value is 10 for all supported variants. So drop the
member in the variant description and introduce a global constant instead.
This reduces the size of the variant descriptions and the .apply() callback
can be compiled a bit more effectively.
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Changes since (implicit) v1, sent with Message-Id:
20190815214133.11134-2-uwe@kleine-koenig.org:
- Added Claudiu's Ack
drivers/pwm/pwm-atmel.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index a61a30fa8b7e..f497f84771f0 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -50,6 +50,8 @@
#define PWMV2_CPRD 0x0C
#define PWMV2_CPRDUPD 0x10
+#define PWM_MAX_PRES 10
+
struct atmel_pwm_registers {
u8 period;
u8 period_upd;
@@ -59,7 +61,6 @@ struct atmel_pwm_registers {
struct atmel_pwm_config {
u32 max_period;
- u32 max_pres;
};
struct atmel_pwm_data {
@@ -126,7 +127,7 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
(*pres)++;
- if (*pres > atmel_pwm->data->cfg.max_pres) {
+ if (*pres > PWM_MAX_PRES) {
dev_err(chip->dev, "pres exceeds the maximum value\n");
return -EINVAL;
}
@@ -289,7 +290,6 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
.cfg = {
/* 16 bits to keep period and duty. */
.max_period = 0xffff,
- .max_pres = 10,
},
};
@@ -303,7 +303,6 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
.cfg = {
/* 16 bits to keep period and duty. */
.max_period = 0xffff,
- .max_pres = 10,
},
};
@@ -317,7 +316,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
.cfg = {
/* 32 bits to keep period and duty. */
.max_period = 0xffffffff,
- .max_pres = 10,
},
};
--
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 related
* [PATCH v2 1/6] pwm: atmel: Add a hint where to find hardware documentation
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190824001041.11007-1-uwe@kleine-koenig.org>
Most Microchip (formerly Atmel) chips have publicly available manuals.
A comprehensive list is already contained in the documentation folder.
Reference this list in the header of the driver to allow reviewers to
find the relevant manuals.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Changes since (implicit) v1 sent with Message-Id:
20190815214133.11134-1-uwe@kleine-koenig.org:
- Only reference Documentation/arm/microchip.rst instead of starting
another list of links
drivers/pwm/pwm-atmel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index e5e1eaf372fa..a61a30fa8b7e 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -4,6 +4,9 @@
*
* Copyright (C) 2013 Atmel Corporation
* Bo Shen <voice.shen@atmel.com>
+ *
+ * Links to reference manuals for the supported PWM chips can be found in
+ * Documentation/arm/microchip.rst.
*/
#include <linux/clk.h>
--
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 related
* [PATCH v2 0/6] Updates for the atmel PWM driver
From: Uwe Kleine-König @ 2019-08-24 0:10 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Hello,
this is v2 of my series to update the atmel PWM driver. (Implicit) v1
was sent on Aug 15, starting with Message-Id:
20190815214133.11134-1-uwe@kleine-koenig.org.
I updated the patches from the feedback I got in v1, see the individual
patches for the details.
Best regards
Uwe
Uwe Kleine-König (6):
pwm: atmel: Add a hint where to find hardware documentation
pwm: atmel: use a constant for maximum prescale value
pwm: atmel: replace loop in prescale calculation by ad-hoc calculation
pwm: atmel: document known weaknesses of both hardware and software
pwm: atmel: use atmel_pwm_writel in atmel_pwm_ch_writel; ditto for
readl
pwm: atmel: implement .get_state()
drivers/pwm/pwm-atmel.c | 86 ++++++++++++++++++++++++++++++++++-------
1 file changed, 73 insertions(+), 13 deletions(-)
--
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: Xiaowei Bao @ 2019-08-24 0:08 UTC (permalink / raw)
To: Andrew Murray
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: <20190823135816.GH14582@e119886-lin.cambridge.arm.com>
> -----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.
>
> 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 v2 05/10] PCI: layerscape: Fix some format issue of the code
From: Xiaowei Bao @ 2019-08-24 0:00 UTC (permalink / raw)
To: Andrew Murray
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: <20190823134527.GG14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月23日 21:45
> 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 05/10] PCI: layerscape: Fix some format issue of the
> code
>
> On Thu, Aug 22, 2019 at 07:22:37PM +0800, Xiaowei Bao wrote:
> > Fix some format issue of the code in EP driver.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Thanks.
>
>
> > ---
> > v2:
> > - No change.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index be61d96..4e92a95 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -62,7 +62,7 @@ static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
> > }
> >
> > static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > - enum pci_epc_irq_type type, u16 interrupt_num)
> > + enum pci_epc_irq_type type, u16 interrupt_num)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> >
> > @@ -86,7 +86,7 @@ static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > };
> >
> > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > - struct platform_device *pdev)
> > + struct platform_device *pdev)
> > {
> > struct dw_pcie *pci = pcie->pci;
> > struct device *dev = pci->dev;
> > --
> > 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 v2 02/10] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
From: Xiaowei Bao @ 2019-08-23 23:51 UTC (permalink / raw)
To: Andrew Murray
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: <20190823133540.GE14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月23日 21:36
> 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 02/10] PCI: designware-ep: Add the doorbell mode of
> MSI-X in EP mode
>
> On Thu, Aug 22, 2019 at 07:22:34PM +0800, Xiaowei Bao wrote:
> > Add the doorbell mode of MSI-X in EP mode.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Remove the macro of no used.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++++++++++++++
> > drivers/pci/controller/dwc/pcie-designware.h | 12 ++++++++++++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 3e2b740..b8388f8 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -480,6 +480,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> *ep, u8 func_no,
> > return 0;
> > }
> >
> > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> func_no,
> > + u16 interrupt_num)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + u32 msg_data;
> > +
> > + msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
> > + (interrupt_num - 1);
> > +
> > + dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
> > +
> > + return 0;
> > +}
> > +
> > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > u16 interrupt_num)
> > {
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index a0fdbf7..895a9ef 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -88,6 +88,9 @@
> > #define PCIE_MISC_CONTROL_1_OFF 0x8BC
> > #define PCIE_DBI_RO_WR_EN BIT(0)
> >
> > +#define PCIE_MSIX_DOORBELL 0x948
> > +#define PCIE_MSIX_DOORBELL_PF_SHIFT 24
> > +
> > /*
> > * iATU Unroll-specific register definitions
> > * From 4.80 core version the address translation will be made by
> > unroll @@ -400,6 +403,8 @@ int dw_pcie_ep_raise_msi_irq(struct
> dw_pcie_ep *ep, u8 func_no,
> > u8 interrupt_num);
> > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > u16 interrupt_num);
> > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> func_no,
> > + u16 interrupt_num);
> > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > #else static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep) @@
> > -432,6 +437,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct
> dw_pcie_ep *ep, u8 func_no,
> > return 0;
> > }
> >
> > +static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep
> *ep,
> > + u8 func_no,
> > + u16 interrupt_num)
> > +{
> > + return 0;
> > +}
> > +
>
> Looks OK to me.
>
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
Thanks a lot.
>
> > static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
> > pci_barno bar) { }
> > --
> > 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 v2 01/10] PCI: designware-ep: Add multiple PFs support for DWC
From: Xiaowei Bao @ 2019-08-23 23:50 UTC (permalink / raw)
To: Andrew Murray
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: <20190823132526.GD14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月23日 21:25
> 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 01/10] PCI: designware-ep: Add multiple PFs support
> for DWC
>
> On Thu, Aug 22, 2019 at 07:22:33PM +0800, Xiaowei Bao wrote:
> > Add multiple PFs support for DWC, different PF have different config
> > space we use pf-offset property which get from the DTS to access the
> > different pF config space.
>
> It looks like you're missing a --cover-letter again.
>
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Remove duplicate redundant code.
> > - Reimplement the PF config space access way.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 122
> ++++++++++++++++--------
> > drivers/pci/controller/dwc/pcie-designware.c | 59 ++++++++----
> > drivers/pci/controller/dwc/pcie-designware.h | 11 ++-
> > 3 files changed, 134 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 2bf5a35..3e2b740 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -19,12 +19,17 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > pci_epc_linkup(epc);
> > }
> >
> > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> bar,
> > - int flags)
> > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > + enum pci_barno bar, int flags)
> > {
> > u32 reg;
> > + unsigned int func_offset = 0;
> > + struct dw_pcie_ep *ep = &pci->ep;
> >
> > - reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > +
> > + reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
>
> This pattern of checking if func_conf_select exists and using it to get an offset
> is repeated a lot throughout this file. You could move this functionality into a
> new function (similar to dw_pcie_read_dbi etc). Or perhaps a new variant of
> dw_pcie_writel_ should be created that writes takes a func_no argument.
Thanks for your comments, I thought about this method before, but there is a issue
about the method of access the different func config space, due to our platform use
this method that different func have different offset from dbi_base to access the
different config space, but others platform maybe use the way that write a register
to implement different func config space access, so I think reserve a callback function
to different platform to implement the own method, my point is that, if use register
method they can implement the code in this function and return offset is 0, if use
offset method, they can return the offset value which can be use by dw_pcie_ep driver.
>
>
> > dw_pcie_dbi_ro_wr_en(pci);
> > dw_pcie_writel_dbi2(pci, reg, 0x0);
> > dw_pcie_writel_dbi(pci, reg, 0x0);
>
>
> > @@ -235,7 +257,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc
> *epc, u8 func_no,
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> >
> > - ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> > + ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > if (ret) {
> > dev_err(pci->dev, "Failed to enable address\n");
> > return ret;
> > @@ -249,11 +271,15 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> *epc, u8 func_no)
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > + unsigned int func_offset = 0;
> > +
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> >
> > if (!ep->msi_cap)
> > return -EINVAL;
> >
> > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
>
> This makes me nervous.
>
> From a PCI viewpoint, each function has it's own capability structure and
> within each function there may exist a MSI capability. Yet what we're doing
> here is using dw_pcie_ep_find_capability to get the list of capabilities for
> function 0, and then applying offsets from that for subsequent functions. I.e.
> we're applying DW specific knowledge to find the correct capability, rather
> than following the general PCI approach.
>
> I think the above hunk shouldn't be required - but instead
> dw_pcie_ep_find_capability is updated to take a func_no parameter.
>
> Have I understood this correctly?
Yes, this is a issue, I think the different func maybe have different capability,
but the dw_pcie_ep_find_capability function is called by dw_pcie_ep_init
function, we can't add func_no parameter to dw_pcie_ep_find_capability,
I will try to fix it use a new patch, I think move this function to ep_init callback
function If better, thanks.
>
> > val = dw_pcie_readw_dbi(pci, reg);
> > if (!(val & PCI_MSI_FLAGS_ENABLE))
> > return -EINVAL;
> > @@ -268,11 +294,15 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> *epc, u8 func_no, u8 interrupts)
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > + unsigned int func_offset = 0;
> > +
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> >
> > if (!ep->msi_cap)
> > return -EINVAL;
> >
> > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > val &= ~PCI_MSI_FLAGS_QMASK;
> > val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -288,11 +318,15
> > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > + unsigned int func_offset = 0;
> > +
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> >
> > if (!ep->msix_cap)
> > return -EINVAL;
> >
> > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
>
> Same for MSIX.
Yes.
>
> > val = dw_pcie_readw_dbi(pci, reg);
> > if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > return -EINVAL;
> > @@ -307,11 +341,15 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> *epc, u8 func_no, u16 interrupts)
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > + unsigned int func_offset = 0;
> > +
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> >
> > if (!ep->msix_cap)
> > return -EINVAL;
> >
> > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > + reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > val &= ~PCI_MSIX_FLAGS_QSIZE;
> > val |= interrupts;
> > @@ -398,29 +436,33 @@ int dw_pcie_ep_raise_msi_irq(struct
> dw_pcie_ep *ep, u8 func_no,
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct pci_epc *epc = ep->epc;
> > unsigned int aligned_offset;
> > + unsigned int func_offset = 0;
> > u16 msg_ctrl, msg_data;
> > u32 msg_addr_lower, msg_addr_upper, reg;
> > u64 msg_addr;
> > bool has_upper;
> > int ret;
> >
> > + if (ep->ops->func_conf_select)
> > + func_offset = ep->ops->func_conf_select(ep, func_no);
> > +
>
> You could probably move this hunk below the test for msi_cap to save some
> cycles.
Sorry, I didn't understand the means, please explain it detailly, thanks a lot, ^_^
>
> > if (!ep->msi_cap)
> > return -EINVAL;
> >
> > /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > - reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> > msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > if (has_upper) {
> > - reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> > msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > - reg = ep->msi_cap + PCI_MSI_DATA_64;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> > msg_data = dw_pcie_readw_dbi(pci, reg);
> > } else {
> > msg_addr_upper = 0;
> > - reg = ep->msi_cap + PCI_MSI_DATA_32;
> > + reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> > msg_data = dw_pcie_readw_dbi(pci, reg);
> > }
> > aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
>
>
>
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102..305e73d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -158,9 +158,10 @@ static void dw_pcie_writel_ob_unroll(struct
> dw_pcie *pci, u32 index, u32 reg,
> > dw_pcie_writel_atu(pci, offset + reg, val); }
> >
> > -static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int
> index,
> > - int type, u64 cpu_addr,
> > - u64 pci_addr, u32 size)
> > +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, u8
> func_no,
> > + int index, int type,
> > + u64 cpu_addr, u64 pci_addr,
> > + u32 size)
> > {
> > u32 retries, val;
> >
> > @@ -175,7 +176,7 @@ static void
> dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> > upper_32_bits(pci_addr));
> > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > - type);
> > + type | PCIE_ATU_FUNC_NUM(func_no));
>
> Much better :)
Do you mean that use the expression "a? b:c"
>
> > dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > PCIE_ATU_ENABLE);
> >
> > @@ -194,8 +195,9 @@ static void
> dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> >
> > -void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > - u64 cpu_addr, u64 pci_addr, u32 size)
> > +static void __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8
> func_no,
> > + int index, int type, u64 cpu_addr,
> > + u64 pci_addr, u32 size)
> > {
> > u32 retries, val;
> >
> > @@ -203,8 +205,8 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> *pci, int index, int type,
> > cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> >
> > if (pci->iatu_unroll_enabled) {
> > - dw_pcie_prog_outbound_atu_unroll(pci, index, type, cpu_addr,
> > - pci_addr, size);
> > + dw_pcie_prog_outbound_atu_unroll(pci, func_no, index, type,
> > + cpu_addr, pci_addr, size);
> > return;
> > }
> >
>
>
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index ffed084..a0fdbf7 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -71,9 +71,11 @@
> > #define PCIE_ATU_TYPE_IO 0x2
> > #define PCIE_ATU_TYPE_CFG0 0x4
> > #define PCIE_ATU_TYPE_CFG1 0x5
> > +#define PCIE_ATU_FUNC_NUM(pf) (pf << 20)
>
> "Macro argument 'pf' may be better as '(pf)' to avoid precedence issues"
>
> > #define PCIE_ATU_CR2 0x908
> > #define PCIE_ATU_ENABLE BIT(31)
> > #define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
> > +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> > #define PCIE_ATU_LOWER_BASE 0x90C
> > #define PCIE_ATU_UPPER_BASE 0x910
> > #define PCIE_ATU_LIMIT 0x914
> > @@ -197,6 +199,7 @@ struct dw_pcie_ep_ops {
> > int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
> > enum pci_epc_irq_type type, u16 interrupt_num);
> > const struct pci_epc_features* (*get_features)(struct dw_pcie_ep
> > *ep);
> > + unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
>
> Given that this function will return an offset, I'm not sure the name you have
> is suitable. Something like get_pf_offset or similar is more descriptive.
As above explain, my initial view is that this function can return 0 or offset depends on
the platform implement mechanism, so I named it func_conf_select, I think add a
comment for this function, like this:
/*
* provide a method to implement the method of different func config space access,
* if use offset method, return the offset from dbi_base, if your register method, implement
* the code in this callback function and return 0.
*/
How about it?
>
> Thanks,
>
> Andrew Murray
>
> > };
> >
> > struct dw_pcie_ep {
> > @@ -265,8 +268,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> > int type, u64 cpu_addr, u64 pci_addr,
> > u32 size);
> > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > - u64 cpu_addr, enum dw_pcie_as_type as_type);
> > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> index,
> > + int type, u64 cpu_addr, u64 pci_addr,
> > + u32 size);
> > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > + int bar, u64 cpu_addr,
> > + enum dw_pcie_as_type as_type);
> > void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> > enum dw_pcie_region_type type);
> > void dw_pcie_setup(struct dw_pcie *pci);
> > --
> > 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
* [GIT PULL 1/2] ti-sysc driver changes for v5.3
From: Tony Lindgren @ 2019-08-23 22:24 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 5b63fb90adb95a178ad403e1703f59bf1ff2c16b:
ARM: dts: Fix incomplete dts data for am3 and am4 mmc (2019-08-13 04:03:30 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/ti-sysc-signed
for you to fetch changes up to c8a738f4cfaeccce40b171aca6da5fc45433ce60:
bus: ti-sysc: remove set but not used variable 'quirks' (2019-08-13 04:40:11 -0700)
----------------------------------------------------------------
Driver changes for ti-sysc for v5.4
Few changes to prepare for using a reset driver for PRM rstctrl mostly
to deal with the clocks for reset. Then few minor clean-up patches and
SPDX license identifier changes, and add a MAINTAINERs file entry.
----------------------------------------------------------------
Suman Anna (4):
MAINTAINERS: Add ti-sysc files under the OMAP2+ entry
dt-bindings: ti-sysc: Add SPDX license identifier
bus: ti-sysc: Switch to SPDX license identifier
bus: ti-sysc: Add missing kerneldoc comments
Tero Kristo (3):
bus: ti-sysc: re-order the clkdm control around reset handling
bus: ti-sysc: rework the reset handling
bus: ti-sysc: allow reset sharing across devices
YueHaibing (1):
bus: ti-sysc: remove set but not used variable 'quirks'
MAINTAINERS | 2 ++
drivers/bus/ti-sysc.c | 56 ++++++++++++++---------------------
include/dt-bindings/bus/ti-sysc.h | 1 +
include/linux/platform_data/ti-sysc.h | 7 +++--
4 files changed, 31 insertions(+), 35 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/2] dts changes for omap variants for v5.4
From: Tony Lindgren @ 2019-08-23 22:24 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
In-Reply-To: <pull-1566599057-142651@atomide.com>
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.4/dt-take2-signed
for you to fetch changes up to a27401cecf7795cda7e0c17751feb98fedbaa99d:
ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi (2019-08-13 04:51:31 -0700)
----------------------------------------------------------------
dts changes for omap variants for v5.4
Remove regulator-boot-off properties that we never had in the mainline
kernel so they won't do anything. We add stdout-path for gta04, and
make am335x-boneblue use am335x-osd335x-common.dtsi file.
----------------------------------------------------------------
David Lechner (1):
ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi
Ezequiel Garcia (2):
ARM: dts: am335x-cm-t335: Remove regulator-boot-off property
ARM: dts: omap3-n950-n9: Remove regulator-boot-off property
H. Nikolaus Schaller (1):
ARM: dts: gta04: define chosen/stdout-path
arch/arm/boot/dts/am335x-boneblue.dts | 92 +----------------------------------
arch/arm/boot/dts/am335x-cm-t335.dts | 1 -
arch/arm/boot/dts/omap3-gta04.dtsi | 4 ++
arch/arm/boot/dts/omap3-n950-n9.dtsi | 1 -
4 files changed, 6 insertions(+), 92 deletions(-)
_______________________________________________
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 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Nicolin Chen @ 2019-08-23 22:11 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Tony Lindgren, Catalin Marinas, Will Deacon, Max Filippov,
Christoph Hellwig, Marek Szyprowski, Stephen Rothwell,
Joerg Roedel, Russell King, Thierry Reding, linux-xtensa,
Kees Cook, Andrew Morton, linux-arm-kernel, Chris Zankel,
Wolfram Sang, Robin Murphy, Linux Kernel Mailing List, iommu,
iamjoonsoo.kim, David Woodhouse
In-Reply-To: <CAK7LNARacEorb38mVBw_V-Zvz-znWgBma1AP1-z_5B_xZU4ogg@mail.gmail.com>
On Fri, Aug 23, 2019 at 09:49:46PM +0900, Masahiro Yamada wrote:
> On Tue, May 7, 2019 at 7:36 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> >
> > The addresses within a single page are always contiguous, so it's
> > not so necessary to always allocate one single page from CMA area.
> > Since the CMA area has a limited predefined size of space, it may
> > run out of space in heavy use cases, where there might be quite a
> > lot CMA pages being allocated for single pages.
> >
> > However, there is also a concern that a device might care where a
> > page comes from -- it might expect the page from CMA area and act
> > differently if the page doesn't.
> >
> > This patch tries to use the fallback alloc_pages path, instead of
> > one-page size allocations from the global CMA area in case that a
> > device does not have its own CMA area. This'd save resources from
> > the CMA global area for more CMA allocations, and also reduce CMA
> > fragmentations resulted from trivial allocations.
> >
> > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
>
>
> This commit (bd2e75633c8012fc8a7431c82fda66237133bf7e)
> broke the DMA for my MMC driver in the following way:
>
>
>
>
> [ 1.876755] mmc0: ADMA error
> [ 1.883385] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 1.889834] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 1.896284] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 1.902733] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 1.909182] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 1.915631] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 1.922081] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa07
> [ 1.928530] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 1.934981] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 1.941429] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 1.947880] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 1.954329] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 1.960778] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 1.967229] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 1.973678] mmc0: sdhci: Host ctl2: 0x00000000
> [ 1.978125] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 1.985271] mmc0: sdhci: ============================================
> [ 1.991758] mmc0: error -5 whilst initialising MMC card
> [ 1.991913] 43fb0000.uart: ttyS1 at MMIO 0x43fb0000 (irq = 0,
> base_baud = 768000) is a 16550A
> [ 2.011011] hctosys: unable to open rtc device (rtc0)
> [ 2.017694] Freeing unused kernel memory: 2368K
> [ 2.027131] Run /init as init process
> Starting syslogd: OK
> Starting klogd: OK
> Initializing random number generator... [ 2.074399] random: dd:
> uninitialized urandom read (512 bytes read)
> done.
> Starting network: OK
> [ 2.109593] mmc0: ADMA error
> [ 2.112488] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.118941] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.125389] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.131840] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.138289] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 2.144738] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.151188] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00004e47
> [ 2.157637] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.164087] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.170536] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.176987] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.183435] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.189886] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.196335] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.202784] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.207232] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.214379] mmc0: sdhci: ============================================
>
> [ 2.220881] mmc0: error -5 whilst initialising MMC card
> Welcome to Buildroot
> buildroot login: [ 2.332786] mmc0: ADMA error
> [ 2.335668] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.342119] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.348568] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.355018] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.361468] mmc0: sdhci: Present: 0x01ff02f6 | Host ctl: 0x00000019
> [ 2.367917] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.374367] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
> [ 2.380816] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.387267] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.393716] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.400166] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.406615] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.413065] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.419515] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.425963] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.430412] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.437557] mmc0: sdhci: ============================================
> [ 2.444031] mmc0: error -5 whilst initialising MMC card
> [ 2.572203] mmc0: ADMA error
> [ 2.575089] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 2.581540] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
> [ 2.587989] mmc0: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000001
> [ 2.594439] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> [ 2.600889] mmc0: sdhci: Present: 0x01ef02f6 | Host ctl: 0x00000019
> [ 2.607339] mmc0: sdhci: Power: 0x0000000b | Blk gap: 0x00000000
> [ 2.613788] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000e8c7
> [ 2.620237] mmc0: sdhci: Timeout: 0x0000000b | Int stat: 0x00000001
> [ 2.626686] mmc0: sdhci: Int enab: 0x03ff008b | Sig enab: 0x03ff008b
> [ 2.633137] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 2.639586] mmc0: sdhci: Caps: 0x546ec800 | Caps_1: 0x00000000
> [ 2.646036] mmc0: sdhci: Cmd: 0x0000083a | Max curr: 0x00000000
> [ 2.652485] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
> [ 2.658936] mmc0: sdhci: Resp[2]: 0x320f5903 | Resp[3]: 0x3fd05e00
> [ 2.665384] mmc0: sdhci: Host ctl2: 0x00000000
> [ 2.669832] mmc0: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x000000013965b200
> [ 2.676979] mmc0: sdhci: ============================================
> [ 2.683450] mmc0: error -5 whilst initialising MMC card
>
> CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline
> | ttyUSB0
>
> Reverting this commit fixed the problem.
We are having another problem with the new API and Christoph
submitted a patch at: https://lkml.org/lkml/2019/8/20/86
Would it be possible for you to test to see if it can fix?
We can revert my fallback change after all, if Christoph's
patch doesn't work for you either.
Thanks
Nicolin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: cleanup the dma_pgprot handling
From: Paul Burton @ 2019-08-23 21:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k@lists.linux-m68k.org, Will Deacon,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Russell King, linux-mips@vger.kernel.org,
iommu@lists.linux-foundation.org, Geert Uytterhoeven,
Catalin Marinas, James Hogan, Guan Xuetao,
linux-arm-kernel@lists.infradead.org, Robin Murphy
In-Reply-To: <20190816070754.15653-1-hch@lst.de>
Hi Christoph,
On Fri, Aug 16, 2019 at 09:07:48AM +0200, Christoph Hellwig wrote:
> I'd still like to hear a confirmation from the mips folks how
> the write combibe attribute can or can't work with the KSEG1
> uncached segment.
Quoting section 4.8 "Cacheability and Coherency Attributes and Access
Types" of "MIPS Architecture Volume 1: Introduction to the MIPS32
Architecture" (MD00080, revision 6.01):
https://www.mips.com/?do-download=introduction-to-the-mips32-architecture-v6-01
> Memory access types are specified by architecturally-defined and
> implementation-specific Cacheability and Coherency Attribute bits
> (CCAs) generated by the MMU for the access.
>
> Slightly different cacheability and coherency attributes such as
> “cached coherent, update on write” and “cached coherent, exclusive on
> write” can map to the same memory access type; in this case they both
> map to cached coherent. In order to map to the same access type, the
> fundamental mechanisms of both CCAs must be the same.
>
> When the operation of the instruction is affected, the instructions
> are described in terms of memory access types. The load and store
> operations in a processor proceed according to the specific CCA of the
> reference, however, and the pseudocode for load and store common
> functions uses the CCA value rather than the corresponding memory
> access type.
So I believe uncached & uncached accelerated are another case like that
described above - they're 2 different CCAs but the same "access type",
namely uncached.
Section 4.9 then goes on to forbid mixing access types, but not CCAs.
It would be nice if the precise mapping from CCA to access type was
provided, but I don't see that anywhere. I can check with the
architecture team to be sure, but to my knowledge we're fine to mix
access via kseg1 (ie. uncached) & mappings with CCA=7 (uncached
accelerated).
Thanks,
Paul
_______________________________________________
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/3] arm64: dts: meson-g12b-ugoos-am6: add initial device-tree
From: Kevin Hilman @ 2019-08-23 20:55 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Chrisitian Hewitt
In-Reply-To: <1566565717-5182-4-git-send-email-christianshewitt@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> writes:
> Tested-by: Oleg Ivanov <balbes-150@yandex.ru>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
nit: empty changelog. I'd rather see the changelog from patch2 here.
> ---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 567 +++++++++++++++++++++
> 2 files changed, 568 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
>
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 07b861f..21e2810 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-g12b-ugoos-am6.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nanopi-k2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nexbox-a95x.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-odroidc2.dtb
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
> new file mode 100644
> index 0000000..27d1d62
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
> @@ -0,0 +1,567 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 BayLibre, SAS
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + * Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
This is a bit confusing.
I'm assuming you kept Neil's authorship because you copied from another
g12b board. If so, it would be helpful in the changelog to describe the
origins of this file. I'm assuming it was copied from odroid-n2 and
then tweaked. That's fine, just note that as "originally based on
meson-g12b-odroid-c2".
Other than that, thanks a lot for your work on adding these new boards!
Neil, I'm starting to see a lot of duplication in the g12b .dtb files.
Should we start thinking about factoring out some of the common stuff
that's standard across all these boards?
Kevin
_______________________________________________
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 5/7] media: use the BIT() macro
From: Laurent Pinchart @ 2019-08-23 20:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Kate Stewart, Richard Fontana, Lad, Prabhakar, Thierry Reding,
Bluecherry Maintainers, Krzysztof Kozlowski, Sylwester Nawrocki,
devel, linux-samsung-soc, Michal Simek, Andrey Utkin,
Jonathan Hunter, Kukjin Kim, linux-arm-kernel, Ismael Luceno,
Linux Media Mailing List, Mauro Carvalho Chehab, Benoit Parrot,
linux-tegra, Thomas Gleixner, Anton Sviridenko, Allison Randal,
Andy Walls, Hyun Kwon, Greg Kroah-Hartman, linux-renesas-soc,
Kyungmin Park, Kieran Bingham, Sakari Ailus, Hans Verkuil
In-Reply-To: <d6c04bf604084af63fec603b4afbd72c648e0394.1566553525.git.mchehab+samsung@kernel.org>
Hi Mauro,
Thank you for the patch.
On Fri, Aug 23, 2019 at 06:47:30AM -0300, Mauro Carvalho Chehab wrote:
> As warned by cppcheck:
>
> [drivers/media/dvb-frontends/cx24123.c:434]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> [drivers/media/pci/bt8xx/bttv-input.c:87]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> [drivers/media/pci/bt8xx/bttv-input.c:98]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
> ...
> [drivers/media/v4l2-core/v4l2-ioctl.c:1391]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
>
> There are lots of places where we're doing 1 << 31. That's bad,
> as, depending on the architecture, this has an undefined behavior.
>
> The BIT() macro is already prepared to handle this, so, let's
> just switch all "1 << number" macros by BIT(number) at the header files
> with has 1 << 31.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>
> v2:
> As suggested by Laurent:
> - Don't touch multi-bit masks
> - remove explicit casts
>
> drivers/media/pci/cobalt/cobalt-driver.h | 63 +-
> drivers/media/pci/ivtv/ivtv-irq.h | 28 +-
> drivers/media/pci/mantis/mantis_reg.h | 152 ++---
> drivers/media/pci/solo6x10/solo6x10-regs.h | 286 ++++-----
> .../media/platform/am437x/am437x-vpfe_regs.h | 26 +-
> .../media/platform/davinci/dm644x_ccdc_regs.h | 20 +-
> .../media/platform/exynos4-is/fimc-lite-reg.h | 80 +--
> drivers/media/platform/exynos4-is/fimc-reg.h | 138 +++--
> drivers/media/platform/omap3isp/ispreg.h | 580 +++++++++---------
> drivers/media/platform/s3c-camif/camif-regs.h | 118 ++--
> drivers/media/platform/tegra-cec/tegra_cec.h | 80 +--
> drivers/media/platform/ti-vpe/vpe_regs.h | 94 +--
> drivers/media/platform/vsp1/vsp1_regs.h | 224 +++----
> drivers/media/platform/xilinx/xilinx-vip.h | 29 +-
> drivers/media/radio/wl128x/fmdrv_common.h | 88 +--
> drivers/staging/media/ipu3/ipu3-tables.h | 4 +-
> 16 files changed, 1011 insertions(+), 999 deletions(-)
[snip]
> diff --git a/drivers/media/platform/omap3isp/ispreg.h b/drivers/media/platform/omap3isp/ispreg.h
> index 38e2b99b3f10..4c6ebc0b74d1 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
[snip]
> @@ -1167,14 +1167,14 @@
> #define ISPHIST_HV_INFO_MASK 0x3FFF3FFF
>
> #define ISPCCDC_LSC_ENABLE 1
This is a bit too, it could be replaced with BIT(0).
> -#define ISPCCDC_LSC_BUSY (1 << 7)
> +#define ISPCCDC_LSC_BUSY BIT(7)
> #define ISPCCDC_LSC_GAIN_MODE_N_MASK 0x700
> #define ISPCCDC_LSC_GAIN_MODE_N_SHIFT 8
> #define ISPCCDC_LSC_GAIN_MODE_M_MASK 0x3800
> #define ISPCCDC_LSC_GAIN_MODE_M_SHIFT 12
> #define ISPCCDC_LSC_GAIN_FORMAT_MASK 0xE
> #define ISPCCDC_LSC_GAIN_FORMAT_SHIFT 1
> -#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK (1<<6)
> +#define ISPCCDC_LSC_AFTER_REFORMATTER_MASK BIT(6)
>
> #define ISPCCDC_LSC_INITIAL_X_MASK 0x3F
> #define ISPCCDC_LSC_INITIAL_X_SHIFT 0
[snip]
With this small issue addressed,
For omap3isp, vsp1, xilinx, wl128x and ipu3,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
--
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 3/3] mailmap: map old company name to new one @microchip.com
From: Alexandre Belloni @ 2019-08-23 19:51 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Ludovic Desroches, linux-kernel, linux-arm-kernel
In-Reply-To: <20190823083158.2649-3-nicolas.ferre@microchip.com>
On 23/08/2019 10:31:58+0200, Nicolas Ferre wrote:
> Map my old email address @atmel.com to my new company name. It happened 3
> years ago but I realized the existence of this file recently.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks.
--
Alexandre Belloni, 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 2/3] MAINTAINERS: at91: remove the TC entry
From: Alexandre Belloni @ 2019-08-23 19:51 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Ludovic Desroches, linux-kernel, linux-arm-kernel
In-Reply-To: <20190823083158.2649-2-nicolas.ferre@microchip.com>
On 23/08/2019 10:31:57+0200, Nicolas Ferre wrote:
> "MICROCHIP TIMER COUNTER (TC) AND CLOCKSOURCE DRIVERS" is better
> removed because one file entry is outdated and basically, the
> maintainer's pool of Alexandre, Ludovic and myself is better suited.
>
> drivers/misc/atmel_tclib.c file is going away in a patch to come and
> drivers/clocksource/tcb_clksrc.c file is actually named timer-atmel-tcb.c.
> This new name is catches by AT91 entry regular expression.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> MAINTAINERS | 7 -------
> 1 file changed, 7 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, 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 1/3] MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry
From: Alexandre Belloni @ 2019-08-23 19:51 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: Ludovic Desroches, linux-kernel, linux-arm-kernel
In-Reply-To: <20190823083158.2649-1-nicolas.ferre@microchip.com>
On 23/08/2019 10:31:56+0200, Nicolas Ferre wrote:
> Andrei's address is not valid anymore, collect all pinctrl/gpio
> entries in the common "PIN CONTROLLER - MICROCHIP AT91" one
> and remove the PIOBU specific one.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> MAINTAINERS | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, 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] ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91
From: Alexandre Belloni @ 2019-08-23 19:50 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kernel, Ludovic Desroches, linux-arm-kernel, Russell King
In-Reply-To: <20190823024346.591-1-yamada.masahiro@socionext.com>
On 23/08/2019 11:43:45+0900, Masahiro Yamada wrote:
> <generated/at91_pm_data-offsets.h> is only generated and included by
> arch/arm/mach-at91/, so it does not need to reside in the globally
> visible include/generated/.
>
> I renamed it to arch/arm/mach-at91/pm_data-offsets.h since the prefix
> 'at91_' is just redundant in mach-at91/.
>
> My main motivation of this change is to avoid the race condition for
> the parallel build (-j) when CONFIG_IKHEADERS is enabled.
>
> When it is enabled, all the headers under include/ are archived into
> kernel/kheaders_data.tar.xz and exposed in the sysfs.
>
> In the parallel build, we have no idea in which order files are built.
>
> - If at91_pm_data-offsets.h is built before kheaders_data.tar.xz,
> the header will be included in the archive. Probably nobody will
> use it, but it is harmless except that it will increase the archive
> size needlessly.
>
> - If kheaders_data.tar.xz is built before at91_pm_data-offsets.h,
> the header will not be included in the archive. However, in the next
> build, the archive will be re-generated to include the newly-found
> at91_pm_data-offsets.h. This is not nice from the build system point
> of view.
>
> - If at91_pm_data-offsets.h and kheaders_data.tar.xz are built at the
> same time, the corrupted header might be included in the archive,
> which does not look nice either.
>
> This commit fixes the race.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> arch/arm/mach-at91/.gitignore | 1 +
> arch/arm/mach-at91/Makefile | 5 +++--
> arch/arm/mach-at91/pm_suspend.S | 2 +-
> 3 files changed, 5 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-at91/.gitignore
>
Applied, thanks.
--
Alexandre Belloni, 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 12/16] arm64: prefer __section from compiler_attributes.h
From: Miguel Ojeda @ 2019-08-23 19:35 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Will Deacon,
Daniel Borkmann, clang-built-linux, Allison Randal, Yonghong Song,
Masayoshi Mizuma, Suzuki K Poulose, Andrey Konovalov,
Shaokun Zhang, Alexios Zavras, Josh Poimboeuf, Sedat Dilek,
Thomas Gleixner, bpf, Linux ARM, Greg Kroah-Hartman, linux-kernel,
Network Development, Andrew Morton, Enrico Weigelt,
Martin KaFai Lau
In-Reply-To: <CANiq72nUyT-q3A9mTrYzPZ+J9Ya7Lns5MyTK7W7-7yXgFWc2xA@mail.gmail.com>
On Thu, Aug 15, 2019 at 11:12 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Btw, I guess that is the Oops you were mentioning in the cover letter?
Pinging about this...
Cheers,
Miguel
_______________________________________________
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