* [PATCH] arm64: dts: uniphier: add eMMC controller node for LD11/LD20
From: Masahiro Yamada @ 2016-12-23 3:18 UTC (permalink / raw)
To: linux-arm-kernel
Add Cadence's eMMC controller node for LD11/LD20.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/boot/dts/uniphier-pinctrl.dtsi | 5 +++++
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 12 ++++++++++++
3 files changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index 10a7110..be353af15 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -43,6 +43,11 @@
*/
&pinctrl {
+ pinctrl_emmc: emmc_grp {
+ groups = "emmc", "emmc_dat8";
+ function = "emmc";
+ };
+
pinctrl_i2c0: i2c0_grp {
groups = "i2c0";
function = "i2c0";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 43b6583..e1e45b4 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -300,6 +300,18 @@
};
};
+ emmc: sdhc at 5a000000 {
+ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
+ reg = <0x5a000000 0x400>;
+ interrupts = <0 78 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc>;
+ clocks = <&sys_clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ };
+
usb0: usb at 5a800100 {
compatible = "socionext,uniphier-ehci", "generic-ehci";
status = "disabled";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index fcaecc6..1e61a04 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -374,6 +374,18 @@
};
};
+ emmc: sdhc at 5a000000 {
+ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
+ reg = <0x5a000000 0x400>;
+ interrupts = <0 78 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc>;
+ clocks = <&sys_clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ };
+
soc-glue at 5f800000 {
compatible = "socionext,uniphier-ld20-soc-glue",
"simple-mfd", "syscon";
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2016-12-23 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222184514.hfd4g7ifrz5cv627@rob-hp-laptop>
Hi, Rob,
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Friday, December 23, 2016 2:45 AM
> To: Jerry Huang <jerry.huang@nxp.com>
> Cc: balbi at kernel.org; mark.rutland at arm.com; catalin.marinas at arm.com;
> will.deacon at arm.com; linux at armlinux.org.uk; devicetree at vger.kernel.org;
> linux-usb at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
>
> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> > New property "snps,incr-burst-type-adjustment = <x>, <y>" for USB3.0
> DWC3.
> > Field "x": 1/0 - undefined length INCR burst type enable or not; Field
> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
> >
> > While enabling undefined length INCR burst type and INCR16 burst type,
> > get better write performance on NXP Layerscape platform:
> > around 3% improvement (from 364MB/s to 375MB/s).
> >
> > Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> > ---
> > Changes in v3:
> > - add new property for INCR burst in usb node.
> >
> > Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
> > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
> > 4 files changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> > b/Documentation/devicetree/bindings/usb/dwc3.txt
> > index e3e6983..8c405a3 100644
> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> > @@ -55,6 +55,10 @@ Optional properties:
> > fladj_30mhz_sdbnd signal is invalid or incorrect.
> >
> > - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be
> reallocated.
> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of
> GSBUSCFG0
> > + register, undefined length INCR burst type enable and INCRx type.
> > + First field is for undefined length INCR burst type enable or not.
> > + Second field is for largest INCRx type enabled.
>
> Why do you need the first field? Is the 2nd field used if the 1st is 0?
> If not, then just use the presence of the property to enable or not.
The first field is one switch.
When it is 1, means undefined length INCR burst type enabled, we can use any length less than or equal to the largest-enabled burst length of INCR4/8/16/32/64/128/256.
When it is zero, means INCRx burst mode enabled, we can use one fixed burst length of 1/4/8/16/32/64/128/256 byte.
So, the 2nd field is used if the 1st is 0, we need to select one largest burst length the USB controller can support.
If we don't want to change the value of this register (use the default value), we don't need to add this property to usb node.
^ permalink raw reply
* [PATCH 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
From: Krzysztof Kozlowski @ 2016-12-23 2:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482408689-21971-4-git-send-email-m.szyprowski@samsung.com>
On Thu, Dec 22, 2016 at 01:11:29PM +0100, Marek Szyprowski wrote:
> This patch replaces irq-safe runtime pm with non-irq-safe version.
>
> Till now non-irq-safe runtime PM implementation was only possible by calling
> pm_runtime_get/put functions from alloc/free_chan_resources. All other DMA
> engine API functions cannot be called from a context, which allows sleeping.
> Such implementation in practice resulted in keeping PL330 DMA controller
> device active almost all the time, because most of the slave device drivers
> (DMA engine clients) acquired DMA channel in their probe() function and
> released it during driver removal.
I think that is not accurate (unless something changed recently and I
missed it)... The runtime PM in pl330 was infact suspending device when
the queue was empty. It was working during the regular work of DMA and
slave devices.
Maybe your recent fix changed this?
> This patch provides a new approach.
Please say why this approach is better because the previous one - was
suspending the dma channel when not used. Otherwise, it would make no
sense of implement the irq-safe runtime PM at the beginning!
Of course, a change from irq-safe to non-irq-safe is a good reason to
implement changes. But that was not mentioned in the first paragraph at
all.
> The main assumption for it is an
> observation that there can be only one slave device using each DMA channel.
Wait, observation, real requirement or assumption?
Later in the code I see adding such requirement.
> Using recently introduced device dependencies (links) infrastructure one can
> ensure proper runtime PM state of PL330 DMA controller. In this approach in
> pl330_alloc_chan_resources() function a new dependency is being created
> between PL330 DMA controller device (as supplier) and given slave device
> (as consumer). This way PL330 DMA controller device runtime active counter
> is increased when the slave device is resumed and decreased the same time
> when given slave device is put to suspend. This way it has been ensured to
> keep PL330 DMA controller runtime active if there is an active used of any
> of its DMA channels. Slave device pointer is initially stored in per-channel
> data in of_dma_xlate callback. This is similar to what has been already
> implemented in Exynos IOMMU driver in commit 2f5f44f205cc958b
> ("iommu/exynos: Use device dependency links to control runtime pm").
Sounds convincing... Interesting approach!
My doubts are:
1. What with more then one slave device? (assumption?)
2. If slave device does not implement runtime PM, then pl330 will be
active all the time?
3. If slave device implements runtime PM in a way that it's enabled in
probe and released in remove, then pl330 will be active all the time?
>
> If one requests memory-to-memory chanel, runtime active counter is
> increased unconditionally. This might be a drawback of this approach, but
> PL330 is not really used for memory-to-memory operations due to poor
> performance in such operations compared to CPU.
>
> Introducing non-irq-safe runtime power management finally allows to turn
> audio power domain off on Exynos5 SoCs.
... and actually any domain which contained pl330 device so this is nice
benefit!
>
> Removal of irq-safe runtime pm is based on the revert of the following
> commits:
> 1. "dmaengine: pl330: fix runtime pm support" commit <no stable id yet>
> 2. "dmaengine: pl330: Fix hang on dmaengine_terminate_all on certain boards"
> commit 81cc6edc08705ac0146fe6ac14a0982a31ce6f3d
> 3. "ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12"
> commit ae43b3289186480f81c78bb63d788a85a3631f47
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 133 +++++++++++++++++++++++++++-------------------------
> 1 file changed, 70 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 3c80e71..2cffbb4 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -268,9 +268,6 @@ enum pl330_byteswap {
>
> #define NR_DEFAULT_DESC 16
>
> -/* Delay for runtime PM autosuspend, ms */
> -#define PL330_AUTOSUSPEND_DELAY 20
> -
> /* Populated by the PL330 core driver for DMA API driver's info */
> struct pl330_config {
> u32 periph_id;
> @@ -449,7 +446,8 @@ struct dma_pl330_chan {
> bool cyclic;
>
> /* for runtime pm tracking */
> - bool active;
> + struct device *slave;
> + struct device_link *slave_link;
> };
>
> struct pl330_dmac {
> @@ -2015,7 +2013,6 @@ static void pl330_tasklet(unsigned long data)
> struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
> struct dma_pl330_desc *desc, *_dt;
> unsigned long flags;
> - bool power_down = false;
>
> spin_lock_irqsave(&pch->lock, flags);
>
> @@ -2030,18 +2027,10 @@ static void pl330_tasklet(unsigned long data)
> /* Try to submit a req imm. next to the last completed cookie */
> fill_queue(pch);
>
> - if (list_empty(&pch->work_list)) {
> - spin_lock(&pch->thread->dmac->lock);
> - _stop(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = true;
> - pch->active = false;
> - } else {
> - /* Make sure the PL330 Channel thread is active */
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - }
> + /* Make sure the PL330 Channel thread is active */
> + spin_lock(&pch->thread->dmac->lock);
> + _start(pch->thread);
> + spin_unlock(&pch->thread->dmac->lock);
>
> while (!list_empty(&pch->completed_list)) {
> struct dmaengine_desc_callback cb;
> @@ -2054,13 +2043,6 @@ static void pl330_tasklet(unsigned long data)
> if (pch->cyclic) {
> desc->status = PREP;
> list_move_tail(&desc->node, &pch->work_list);
> - if (power_down) {
> - pch->active = true;
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = false;
> - }
> } else {
> desc->status = FREE;
> list_move_tail(&desc->node, &pch->dmac->desc_pool);
> @@ -2075,12 +2057,6 @@ static void pl330_tasklet(unsigned long data)
> }
> }
> spin_unlock_irqrestore(&pch->lock, flags);
> -
> - /* If work list empty, power down */
> - if (power_down) {
> - pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
> - pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
> - }
> }
>
> bool pl330_filter(struct dma_chan *chan, void *param)
> @@ -2113,14 +2089,63 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> if (chan_id >= pl330->num_peripherals)
> return NULL;
>
> + if (!pl330->peripherals[chan_id].slave)
> + pl330->peripherals[chan_id].slave = slave;
> + else if (pl330->peripherals[chan_id].slave != slave) {
> + dev_err(pl330->ddma.dev,
> + "Can't use same channel with multiple slave devices!\n");
> + return NULL;
> + }
This could be nicely split into separate patch.
Best regards,
Krzysztof
> +
> return dma_get_slave_channel(&pl330->peripherals[chan_id].chan);
> }
>
> +static int pl330_add_slave_link(struct pl330_dmac *pl330,
> + struct dma_pl330_chan *pch)
> +{
> + struct device_link *link;
> + int i;
> +
> + if (pch->slave_link)
> + return 0;
> +
> + link = device_link_add(pch->slave, pl330->ddma.dev,
> + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
> + if (!link)
> + return -ENODEV;
> +
> + for (i = 0; i < pl330->num_peripherals; i++)
> + if (pl330->peripherals[i].slave == pch->slave)
> + pl330->peripherals[i].slave_link = link;
> + return 0;
> +}
> +
> +static void pl330_del_slave_link(struct pl330_dmac *pl330,
> + struct dma_pl330_chan *pch)
> +{
> + struct device_link *link = pch->slave_link;
> + int i, count = 0;
> +
> + for (i = 0; i < pl330->num_peripherals; i++)
> + if (pl330->peripherals[i].slave == pch->slave &&
> + pl330->peripherals[i].thread)
> + count++;
> +
> + if (count > 0)
> + return;
> +
> + device_link_del(link);
> + for (i = 0; i < pl330->num_peripherals; i++)
> + if (pl330->peripherals[i].slave == pch->slave)
> + pch->slave_link = NULL;
> +}
> +
> static int pl330_alloc_chan_resources(struct dma_chan *chan)
> {
> struct dma_pl330_chan *pch = to_pchan(chan);
> struct pl330_dmac *pl330 = pch->dmac;
> unsigned long flags;
> + int ret = 0;
>
> spin_lock_irqsave(&pch->lock, flags);
>
> @@ -2137,6 +2162,14 @@ static int pl330_alloc_chan_resources(struct dma_chan *chan)
>
> spin_unlock_irqrestore(&pch->lock, flags);
>
> + if (pch->slave)
> + ret = pl330_add_slave_link(pl330, pch);
> + else
> + ret = pm_runtime_get_sync(pl330->ddma.dev);
> +
> + if (ret < 0)
> + return ret;
> +
> return 1;
> }
>
> @@ -2171,9 +2204,7 @@ static int pl330_terminate_all(struct dma_chan *chan)
> unsigned long flags;
> struct pl330_dmac *pl330 = pch->dmac;
> LIST_HEAD(list);
> - bool power_down = false;
>
> - pm_runtime_get_sync(pl330->ddma.dev);
> spin_lock_irqsave(&pch->lock, flags);
> spin_lock(&pl330->lock);
> _stop(pch->thread);
> @@ -2182,8 +2213,6 @@ static int pl330_terminate_all(struct dma_chan *chan)
> pch->thread->req[0].desc = NULL;
> pch->thread->req[1].desc = NULL;
> pch->thread->req_running = -1;
> - power_down = pch->active;
> - pch->active = false;
>
> /* Mark all desc done */
> list_for_each_entry(desc, &pch->submitted_list, node) {
> @@ -2200,10 +2229,6 @@ static int pl330_terminate_all(struct dma_chan *chan)
> list_splice_tail_init(&pch->work_list, &pl330->desc_pool);
> list_splice_tail_init(&pch->completed_list, &pl330->desc_pool);
> spin_unlock_irqrestore(&pch->lock, flags);
> - pm_runtime_mark_last_busy(pl330->ddma.dev);
> - if (power_down)
> - pm_runtime_put_autosuspend(pl330->ddma.dev);
> - pm_runtime_put_autosuspend(pl330->ddma.dev);
>
> return 0;
> }
> @@ -2221,7 +2246,6 @@ static int pl330_pause(struct dma_chan *chan)
> struct pl330_dmac *pl330 = pch->dmac;
> unsigned long flags;
>
> - pm_runtime_get_sync(pl330->ddma.dev);
> spin_lock_irqsave(&pch->lock, flags);
>
> spin_lock(&pl330->lock);
> @@ -2229,8 +2253,6 @@ static int pl330_pause(struct dma_chan *chan)
> spin_unlock(&pl330->lock);
>
> spin_unlock_irqrestore(&pch->lock, flags);
> - pm_runtime_mark_last_busy(pl330->ddma.dev);
> - pm_runtime_put_autosuspend(pl330->ddma.dev);
>
> return 0;
> }
> @@ -2238,11 +2260,11 @@ static int pl330_pause(struct dma_chan *chan)
> static void pl330_free_chan_resources(struct dma_chan *chan)
> {
> struct dma_pl330_chan *pch = to_pchan(chan);
> + struct pl330_dmac *pl330 = pch->dmac;
> unsigned long flags;
>
> tasklet_kill(&pch->task);
>
> - pm_runtime_get_sync(pch->dmac->ddma.dev);
> spin_lock_irqsave(&pch->lock, flags);
>
> pl330_release_channel(pch->thread);
> @@ -2252,19 +2274,20 @@ static void pl330_free_chan_resources(struct dma_chan *chan)
> list_splice_tail_init(&pch->work_list, &pch->dmac->desc_pool);
>
> spin_unlock_irqrestore(&pch->lock, flags);
> - pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
> - pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
> +
> + if (pch->slave)
> + pl330_del_slave_link(pl330, pch);
> + else
> + pm_runtime_put(pl330->ddma.dev);
> }
>
> static int pl330_get_current_xferred_count(struct dma_pl330_chan *pch,
> struct dma_pl330_desc *desc)
> {
> struct pl330_thread *thrd = pch->thread;
> - struct pl330_dmac *pl330 = pch->dmac;
> void __iomem *regs = thrd->dmac->base;
> u32 val, addr;
>
> - pm_runtime_get_sync(pl330->ddma.dev);
> val = addr = 0;
> if (desc->rqcfg.src_inc) {
> val = readl(regs + SA(thrd->id));
> @@ -2273,8 +2296,6 @@ static int pl330_get_current_xferred_count(struct dma_pl330_chan *pch,
> val = readl(regs + DA(thrd->id));
> addr = desc->px.dst_addr;
> }
> - pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
> - pm_runtime_put_autosuspend(pl330->ddma.dev);
>
> /* If DMAMOV hasn't finished yet, SAR/DAR can be zero */
> if (!val)
> @@ -2360,16 +2381,6 @@ static void pl330_issue_pending(struct dma_chan *chan)
> unsigned long flags;
>
> spin_lock_irqsave(&pch->lock, flags);
> - if (list_empty(&pch->work_list)) {
> - /*
> - * Warn on nothing pending. Empty submitted_list may
> - * break our pm_runtime usage counter as it is
> - * updated on work_list emptiness status.
> - */
> - WARN_ON(list_empty(&pch->submitted_list));
> - pch->active = true;
> - pm_runtime_get_sync(pch->dmac->ddma.dev);
> - }
> list_splice_tail_init(&pch->submitted_list, &pch->work_list);
> spin_unlock_irqrestore(&pch->lock, flags);
>
> @@ -2987,11 +2998,7 @@ static int __maybe_unused pl330_resume(struct device *dev)
> pcfg->data_buf_dep, pcfg->data_bus_width / 8, pcfg->num_chan,
> pcfg->num_peri, pcfg->num_events);
>
> - pm_runtime_irq_safe(&adev->dev);
> - pm_runtime_use_autosuspend(&adev->dev);
> - pm_runtime_set_autosuspend_delay(&adev->dev, PL330_AUTOSUSPEND_DELAY);
> - pm_runtime_mark_last_busy(&adev->dev);
> - pm_runtime_put_autosuspend(&adev->dev);
> + pm_runtime_put(&adev->dev);
>
> return 0;
> probe_err3:
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: zhangfei @ 2016-12-23 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222205112.GD8288@codeaurora.org>
Hi, Stephen
On 2016?12?23? 04:51, Stephen Boyd wrote:
> On 12/22, zhangfei wrote:
>> On 2016?12?22? 07:25, Stephen Boyd wrote:
>>> On 12/15, Zhangfei Gao wrote:
>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>>> +
>>>> + switch (type) {
>>>> + case HI3660_CRGCTRL:
>>>> + hi3660_clk_crgctrl_init(np);
>>>> + break;
>>>> + case HI3660_PCTRL:
>>>> + hi3660_clk_pctrl_init(np);
>>>> + break;
>>>> + case HI3660_PMUCTRL:
>>>> + hi3660_clk_pmuctrl_init(np);
>>>> + break;
>>>> + case HI3660_SCTRL:
>>>> + hi3660_clk_sctrl_init(np);
>>>> + break;
>>>> + case HI3660_IOMCU:
>>>> + hi3660_clk_iomcu_init(np);
>>>> + break;
>>> This "multi-device" driver design is sort of odd. Why not have
>>> different files and struct drivers for the different devices in
>>> the system that are clock controllers? I don't really understand
>>> why we're controlling the devices with one struct driver
>>> instance. Is something shared between the devices?
>> Do you mean put in different .c / drivers?
> Yes.
>
>> They have to be put in the same file, since the parent / child
>> relate to each other.
> We handle clk parent/child relationships through strings. So why
> does that mean we need to put these in the same file with the
> same struct driver?
Yes, you are right.
But we still prefer to put in the same file for as a hi3660-clock driver,
since it is easy to maintain.
There may too many files if each chip split to small pieces,
there may many chips for hisilicon in the futures.
And some clocks has less entries, like hi3660_pmu_gate_clks only have
one entry.
Also put in one file is easy to find parent/child relation, so easier to
find bugs.
After all, they just put in different region for privilege control, no
other special reason.
What do you think.
Thanks
>
>> They are for the same chip, but some put in different region for
>> privilege control.
> Ok.
>
^ permalink raw reply
* [PATCH] dmaengine: pl330: Fix runtime PM support for terminated transfers
From: Krzysztof Kozlowski @ 2016-12-23 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481884751-21411-1-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 16, 2016 at 11:39:11AM +0100, Marek Szyprowski wrote:
> PL330 DMA engine driver is leaking a runtime reference after any terminated
> DMA transactions. This patch fixes this issue by tracking runtime PM state
> of the device and making additional call to pm_runtime_put() in terminate_all
> callback if needed.
>
> Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 030fe05ed43b..9f3dbc8c63d2 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -448,6 +448,9 @@ struct dma_pl330_chan {
>
> /* for cyclic capability */
> bool cyclic;
> +
> + /* for runtime pm tracking */
> + bool active;
> };
>
> struct pl330_dmac {
> @@ -2031,6 +2034,7 @@ static void pl330_tasklet(unsigned long data)
> _stop(pch->thread);
> spin_unlock(&pch->thread->dmac->lock);
> power_down = true;
> + pch->active = false;
> } else {
> /* Make sure the PL330 Channel thread is active */
> spin_lock(&pch->thread->dmac->lock);
> @@ -2050,6 +2054,7 @@ static void pl330_tasklet(unsigned long data)
> desc->status = PREP;
> list_move_tail(&desc->node, &pch->work_list);
> if (power_down) {
> + pch->active = true;
It's been a while since I was playign with the driver so I don't
remember everything... but I can't get the logic behind this.
The device is marked as inactive and scheduled to power down. But you
mark chanel as active.
Maybe it is correct but for me it is unreadable.
I understand that you wanted to mark the device as active at some point,
in case transfer was terminated?
Best regards,
Krzysztof
> spin_lock(&pch->thread->dmac->lock);
> _start(pch->thread);
> spin_unlock(&pch->thread->dmac->lock);
> @@ -2164,6 +2169,7 @@ static int pl330_terminate_all(struct dma_chan *chan)
> unsigned long flags;
> struct pl330_dmac *pl330 = pch->dmac;
> LIST_HEAD(list);
> + bool power_down = false;
>
> pm_runtime_get_sync(pl330->ddma.dev);
> spin_lock_irqsave(&pch->lock, flags);
> @@ -2174,6 +2180,8 @@ static int pl330_terminate_all(struct dma_chan *chan)
> pch->thread->req[0].desc = NULL;
> pch->thread->req[1].desc = NULL;
> pch->thread->req_running = -1;
> + power_down = pch->active;
> + pch->active = false;
>
> /* Mark all desc done */
> list_for_each_entry(desc, &pch->submitted_list, node) {
> @@ -2191,6 +2199,8 @@ static int pl330_terminate_all(struct dma_chan *chan)
> list_splice_tail_init(&pch->completed_list, &pl330->desc_pool);
> spin_unlock_irqrestore(&pch->lock, flags);
> pm_runtime_mark_last_busy(pl330->ddma.dev);
> + if (power_down)
> + pm_runtime_put_autosuspend(pl330->ddma.dev);
> pm_runtime_put_autosuspend(pl330->ddma.dev);
>
> return 0;
> @@ -2350,6 +2360,7 @@ static void pl330_issue_pending(struct dma_chan *chan)
> * updated on work_list emptiness status.
> */
> WARN_ON(list_empty(&pch->submitted_list));
> + pch->active = true;
> pm_runtime_get_sync(pch->dmac->ddma.dev);
> }
> list_splice_tail_init(&pch->submitted_list, &pch->work_list);
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Guenter Roeck @ 2016-12-23 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fc2558d-fe05-14a7-745e-f71d2178bad6@mleia.com>
On 12/11/2016 03:21 AM, Vladimir Zapolskiy wrote:
> On 12/11/2016 12:26 PM, Uwe Kleine-K?nig wrote:
>> Hello Vladimir,
>>
>> On Sun, Dec 11, 2016 at 12:01:08PM +0200, Vladimir Zapolskiy wrote:
>>> On 12/11/2016 11:35 AM, Uwe Kleine-K?nig wrote:
>>>> On Sun, Dec 11, 2016 at 03:06:48AM +0200, Vladimir Zapolskiy wrote:
>>>>> Power down counter enable/disable bit switch is located in WMCR
>>>>> register, but watchdog controllers found on legacy i.MX21, i.MX27 and
>>>>> i.MX31 SoCs don't have this register. As a result of writing data to
>>>>> the non-existing register on driver probe the SoC hangs up, to fix the
>>>>> problem add more OF compatible strings and on this basis get
>>>>> information about availability of the WMCR register.
>>>>>
>>>>> Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
>>>>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>>>>> ---
>>>
What is the ultimate conclusion of this exchange ?
Are we going to get another version of the patch, or did everyone agree that
the patch is good as it is and does not require further changes ?
Guenter
>>> [snip]
>>>
>>>>>
>>>>> static const struct of_device_id imx2_wdt_dt_ids[] = {
>>>>> - { .compatible = "fsl,imx21-wdt", },
>>>>> + { .compatible = "fsl,imx21-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> + { .compatible = "fsl,imx25-wdt", },
>>>>> + { .compatible = "fsl,imx27-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> + { .compatible = "fsl,imx31-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> + { .compatible = "fsl,imx35-wdt", },
>>>>> + { .compatible = "fsl,imx50-wdt", },
>>>>> + { .compatible = "fsl,imx51-wdt", },
>>>>> + { .compatible = "fsl,imx53-wdt", },
>>>>> + { .compatible = "fsl,imx6q-wdt", },
>>>>> + { .compatible = "fsl,imx6sl-wdt", },
>>>>> + { .compatible = "fsl,imx6sx-wdt", },
>>>>> + { .compatible = "fsl,imx6ul-wdt", },
>>>>> + { .compatible = "fsl,imx7d-wdt", },
>>>>> + { .compatible = "fsl,vf610-wdt", },
>>>>
>>>> Up to now we only had fsl,imx21-wdt, now it seems that iMX31, i.MX27 and
>>>> i.MX21 form a group of equal watchdog IPs and the others form another
>>>> group, right?
>>>>
>>>> So conceptually we should differenciate between
>>>>
>>>> fsl,imx21-wdt (which is used on i.MX21, i.MX27 and i.MX31)
>>>> fsl,imx35-wdt (which is used on all others)
>>>>
>>>
>>> The problem is that "fsl,imx35-wdt" is not used on all others in the
>>> existing DTS, i.e. in the old firmware, which shall be compatible with
>>> new changes.
>>
>> So old i.MX53 has
>>
>> compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>
>> . With the change to the driver it's like using the watchdog driver in
>> it's pre-5fe65ce7ccbb4-state on it. If this is bad, we must indeed make
>> fsl,imx53-wdt known to the driver. If not, just adding a single new
>> compatible to the driver is just fine.
>
> The change under discussion preserves the current runtime behaviour for
> i.MX53 and its friends, the watchdog power down counter in WMCR is
> disabled on boot (you may want to confirm it by testing though), another
> question is if it is wanted for e.g. i.MX53 right from the beginning.
>
> To keep the runtime compatibility of a newer kernel with old DTBs such
> a long list of device compatibles has to be inserted.
>
>>
>> If you want to call it imx25 or imx35 doesn't matter much. The reason I
>> picked imx35 is that this one was already picked before for cspi. This
>> suggests that i.MX35 is older than i.MX25 and so this is the canonical
>> choice.
>
> Accepted, from the Wikipedia both i.MX25 and i.MX35 are released in 2009,
> which one is the first I don't know for sure, I supposed it could be
> i.MX25 as a SoC with a weaker core.
>
>>
>>> $ grep -H 'fsl,imx.*-wdt' arch/arm/boot/dts/*.dtsi
>>> arch/arm/boot/dts/imx25.dtsi: compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx27.dtsi: compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx35.dtsi: compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx50.dtsi: compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx51.dtsi: compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx51.dtsi: compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx53.dtsi: compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx53.dtsi: compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6qdl.dtsi: compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6qdl.dtsi: compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sl.dtsi: compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sl.dtsi: compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi: compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi: compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi: compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6ul.dtsi: compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6ul.dtsi: compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi: compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi: compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi: compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi: compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/ls1021a.dtsi: compatible = "fsl,imx21-wdt";
>>> arch/arm/boot/dts/vfxxx.dtsi: compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
>>>
>>> I don't see a confirmation of the fact that "fsl,imx35-wdt" is the best
>>> selection, hence definitely "fsl,imx25-wdt" overscores it.
>>
>> I stated my reason to pick imx35 over imx25 above. Why do yo prefer
>> imx25?
>
> As you said right now and until it is added into DTS files "fsl,imx25-wdt" and
> "fsl,imx35-wdt" are equal as a compatible representation of WMCR-aware watchdogs.
>
> I may be wrong, if I assume that i.MX25 is released before i.MX35 (looks like
> they are released in parallel), but "imx25" precedes in alphanumerically sorted
> list of SoC names.
>
>>>> A reason to add e.g. fsl,imx6sl-wdt is that dtbs in the wild use
>>>>
>>>> "fsl,imx6sl-wdt", "fsl,imx21-wdt"
>>>>
>>>> . But then I wonder if
>>>>
>>>> 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
>>>>
>>>> is that important to justify to add these all.
>>>
>>> About this comment I don't know, you may have better insight about the original
>>> change. By the way, in barebox you may want to fix the same hang-up, because
>>> you touch WMCR unconditionally.
>>
>> Sure.
>>
>>>> Independant of this I'd like to have all dtsi for the newer SoCs changed
>>>> to get
>>>>
>>>> "fsl,imx6sl-wdt", "fsl,imx35-wdt"
>>>>
>>>> and if you really want to add all these compatibles, add a comment that
>>>> these are really fsl,imx35-wdt and were added to work around broken
>>>> dtbs.
>>>
>>> No objections, but
>>>
>>> 1) I'd like to see "fsl,imx25-wdt" as a new common compatible, and that's
>>> what have been proposed and shared in RFC 2/2.
>>
>> Yeah, I missed that other patch (which was not part of this series).
>>
>>> 2) Please remind me, why do you ask to drop "fsl,imx21-wdt" from the list?
>>>
>>> compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt", "fsl,imx21-wdt";
>>>
>>> The list of compatibles above is valid (from the most specific on the left
>>> to the most generic on the right), and that compatible property is rightly
>>> handled in the driver with this change applied. I don't see a need to
>>> drop "fsl,imx21-wdt".
>>
>> If the wdt in the i.MX6SX can be operated by the watchdog driver in it's
>> imx21 mode, you should keep the imx21 entry. If not, you shouldn't.
>
> The DTS description shall be rather independent from any particular software
> implementation, someone may want to reuse the same DTB in bootloaders and OS
> kernels of different versions. Assuming that I have a bootloader/kernel
> with a pure i.MX21 watchdog driver and run it on i.MX6SX, I'd prefer to match
> "fsl,imx21-wdt" compatible.
>
> --
> With best wishes,
> Vladimir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog
From: Guenter Roeck @ 2016-12-23 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214231237.17496-7-sebastien.bourdelin@savoirfairelinux.com>
On 12/14/2016 03:12 PM, Sebastien Bourdelin wrote:
> This watchdog is instantiated in a FPGA and can only be access using a
> GPIOs bit-banged bus, called the NBUS by Technologic Systems.
> The watchdog is made of only one register, called the feed register.
> Writing to this register will re-arm the watchdog for a given time (and
> enable it if it was disable). It can be disabled by writing a special
> value into it.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> ---
> .../devicetree/bindings/watchdog/ts4600-wdt.txt | 16 ++
> arch/arm/boot/dts/imx28-ts4600-common.dtsi | 5 +
> drivers/watchdog/Kconfig | 10 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ts4600_wdt.c | 213 +++++++++++++++++++++
> 5 files changed, 245 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> create mode 100644 drivers/watchdog/ts4600_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> new file mode 100644
> index 0000000..61d620e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> @@ -0,0 +1,16 @@
> +TS-4600 Technologic Systems Watchdog
> +
> +Required properties:
> +- compatible: must be "technologic,ts4600-wdt"
> +- reg: offset to the FPGA's watchdog register
> +
> +Optional property:
> +- timeout-sec: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> +wdt {
> + compatible = "technologic,ts4600-wdt";
> + reg = <0x2a>;
> + timeout-sec = <10>;
> +};
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> index b668933..dd7318c 100644
> --- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -116,6 +116,11 @@
> strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
> rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> +
> + wdt at 2a {
> + compatible = "technologic,ts4600-wdt";
> + reg = <0x2a>;
> + };
> };
>
> };
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 3eb58cb..7a8e176 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -500,6 +500,16 @@ config NUC900_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called nuc900_wdt.
>
> +config TS4600_WATCHDOG
> + tristate "TS-4600 Watchdog"
> + depends on HAS_IOMEM && OF
> + depends on SOC_IMX28 || COMPILE_TEST
Asd 0day reports, this does not work.
> + select WATCHDOG_CORE
> + help
> + Technologic Systems TS-4600 has watchdog timer implemented in
> + an external FPGA. Say Y here if you want to support for the
> + watchdog timer on TS-4600 board.
> +
> config TS4800_WATCHDOG
> tristate "TS-4800 Watchdog"
> depends on HAS_IOMEM && OF
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index caa9f4a..d4b4bd2 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
> obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> +obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
> obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
> new file mode 100644
> index 0000000..db91b40
> --- /dev/null
> +++ b/drivers/watchdog/ts4600_wdt.c
> @@ -0,0 +1,213 @@
> +/*
> + * Watchdog driver for TS-4600 based boards
> + *
> + * Copyright (c) 2016 - Savoir-faire Linux
> + * Author: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The watchdog on the TS-4600 based boards is in an FPGA and can only be
> + * accessed using a GPIO bit-banged bus called the NBUS by Technologic Systems.
> + * The logic for the watchdog is the same then for the TS-4800 SoM, only the way
> + * to access it change, therefore this driver is heavely based on the ts4800_wdt
> + * driver from Damien Riegel <damien.riegel@savoirfairelinux.com>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/ts-nbus.h>
> +#include <linux/watchdog.h>
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout,
> + "Watchdog cannot be stopped once started (default="
> + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +/* possible feed values */
> +#define TS4600_WDT_FEED_2S 0x1
> +#define TS4600_WDT_FEED_10S 0x2
> +#define TS4600_WDT_DISABLE 0x3
> +
> +struct ts4600_wdt {
> + struct watchdog_device wdd;
> + u32 feed_offset;
> + u32 feed_val;
> +};
> +
> +/*
> + * TS-4600 supports the following timeout values:
> + *
> + * value desc
> + * ---------------------
> + * 0 feed for 338ms
> + * 1 feed for 2.706s
> + * 2 feed for 10.824s
> + * 3 disable watchdog
> + *
> + * Keep the regmap/timeout map ordered by timeout
> + */
> +static const struct {
> + const int timeout;
> + const int regval;
> +} ts4600_wdt_map[] = {
> + { 2, TS4600_WDT_FEED_2S },
> + { 10, TS4600_WDT_FEED_10S },
> +};
> +
> +#define MAX_TIMEOUT_INDEX (ARRAY_SIZE(ts4600_wdt_map) - 1)
> +
> +static void ts4600_write_feed(struct ts4600_wdt *wdt, u32 val)
> +{
> + ts_nbus_write(wdt->feed_offset, val);
> +}
> +
> +static int ts4600_wdt_start(struct watchdog_device *wdd)
> +{
> + struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + ts4600_write_feed(wdt, wdt->feed_val);
> +
> + return 0;
> +}
> +
> +static int ts4600_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + ts4600_write_feed(wdt, TS4600_WDT_DISABLE);
> + return 0;
> +}
> +
> +static int ts4600_wdt_set_timeout(struct watchdog_device *wdd,
> + unsigned int timeout)
> +{
> + struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> + int i;
> +
> + for (i = 0; i < MAX_TIMEOUT_INDEX; i++) {
> + if (ts4600_wdt_map[i].timeout >= timeout)
> + break;
> + }
An if/else would be much simpler here.
> +
> + wdd->timeout = ts4600_wdt_map[i].timeout;
> + wdt->feed_val = ts4600_wdt_map[i].regval;
> +
> + return 0;
> +}
> +
> +static const struct watchdog_ops ts4600_wdt_ops = {
> + .owner = THIS_MODULE,
> + .start = ts4600_wdt_start,
> + .stop = ts4600_wdt_stop,
> + .set_timeout = ts4600_wdt_set_timeout,
> +};
> +
> +static const struct watchdog_info ts4600_wdt_info = {
> + .options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
> + .identity = "TS-4600 Watchdog",
> +};
> +
> +static int ts4600_wdt_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct watchdog_device *wdd;
> + struct ts4600_wdt *wdt;
> + u32 reg;
> + int ret;
> +
> + ret = of_property_read_u32(np, "reg", ®);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "missing reg property\n");
> + return ret;
> + }
> +
> + /* check for the NBUS state and defer the probing if it is not ready */
> + if (!ts_nbus_is_ready())
> + return -EPROBE_DEFER;
> +
> + /* allocate memory for watchdog struct */
> + wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> + if (!wdt)
> + return -ENOMEM;
> +
> + /* set offset to know where to write */
> + wdt->feed_offset = reg;
> +
> + /* Initialize struct watchdog_device */
> + wdd = &wdt->wdd;
> + wdd->parent = &pdev->dev;
> + wdd->info = &ts4600_wdt_info;
> + wdd->ops = &ts4600_wdt_ops;
> + wdd->min_timeout = ts4600_wdt_map[0].timeout;
> + wdd->max_timeout = ts4600_wdt_map[MAX_TIMEOUT_INDEX].timeout;
> +
Your call, but it might be better and more flexible to just use a single
hardware timeout (such as the 2.x second one), provide it here as
max_hw_heartbeat_ms, and let the kernel handle the actual (and larger)
timeouts.
> + watchdog_set_drvdata(wdd, wdt);
> + watchdog_set_nowayout(wdd, nowayout);
> + watchdog_init_timeout(wdd, 0, &pdev->dev);
> +
> + /*
> + * As this watchdog supports only a few values, ts4600_wdt_set_timeout
> + * must be called to initialize timeout and feed_val with valid values.
> + * Default to maximum timeout if none, or an invalid one, is provided in
> + * device tree.
> + */
> + if (!wdd->timeout)
> + wdd->timeout = wdd->max_timeout;
> + ts4600_wdt_set_timeout(wdd, wdd->timeout);
> +
> + /*
> + * The feed register is write-only, so it is not possible to determine
> + * watchdog's state. Disable it to be in a known state.
> + */
> + ts4600_wdt_stop(wdd);
> +
> + ret = watchdog_register_device(wdd);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to register watchdog device\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, wdt);
> +
> + dev_info(&pdev->dev,
> + "initialized (timeout = %d sec, nowayout = %d)\n",
> + wdd->timeout, nowayout);
> +
> + return 0;
> +}
> +
> +static int ts4600_wdt_remove(struct platform_device *pdev)
> +{
> + struct ts4600_wdt *wdt = platform_get_drvdata(pdev);
> +
> + watchdog_unregister_device(&wdt->wdd);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ts4600_wdt_of_match[] = {
> + { .compatible = "technologic,ts4600-wdt", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, ts4600_wdt_of_match);
> +
> +static struct platform_driver ts4600_wdt_driver = {
> + .probe = ts4600_wdt_probe,
> + .remove = ts4600_wdt_remove,
> + .driver = {
> + .name = "ts4600_wdt",
> + .of_match_table = ts4600_wdt_of_match,
> + },
> +};
> +
> +module_platform_driver(ts4600_wdt_driver);
> +
> +MODULE_AUTHOR("Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:ts4600_wdt");
>
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-12-23 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVNS9n9_ty8y3CyqfRaLitqDKdk1mMOrQHM-enOgJtUBeQ@mail.gmail.com>
Hi?Ming,
On 2016/12/22 16:15, Ming Lei wrote:
> Hi Guys,
>
> On Tue, Nov 8, 2016 at 11:47 AM, zhichang.yuan
> <yuanzhichang@hisilicon.com> wrote:
>> For arm64, there is no I/O space as other architectural platforms, such as
>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>> known port addresses are used to control the corresponding target devices, for
>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>> normal MMIO mode in using.
>>
>> To drive these devices, this patch introduces a method named indirect-IO.
>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>> redefined. When upper layer drivers call in/out with those known legacy port
>> addresses to access the peripherals, the hooking functions corrresponding to
>> those target peripherals will be called. Through this way, those upper layer
>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/Kconfig | 6 +++
>> arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
>> arch/arm64/include/asm/io.h | 29 +++++++++++++
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/extio.c | 27 ++++++++++++
>> 5 files changed, 157 insertions(+)
>
> When I applied these three patches against current linus tree and
> enable CONFIG_HISILICON_LPC, the following build failure[1] is
> triggered when running 'make modules'.
>
Thanks for your report!
This patch has compilation issue on some architectures, sorry for the inconvenience caused by this!
The ongoing v6 will solve these issues.
I will trace this failure and provide a fix if you can not wait for the next version.
Could you send me your .config in private? I don't want to bother all the hacker in the mail-list.
Thanks,
Zhichang
>
> Thanks,
> Ming
>
> [1] 'make modules' failure log
>
> Building modules, stage 2.
> MODPOST 2260 modules
> ERROR: "inb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "inb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "outw" [drivers/video/vgastate.ko] undefined!
> ERROR: "outb" [drivers/video/vgastate.ko] undefined!
> ERROR: "inb" [drivers/video/vgastate.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tdfxfb.ko] undefined!
> .....
> ERROR: "inb" [drivers/ata/pata_cmd64x.ko] undefined!
> ERROR: "inb" [drivers/ata/pata_artop.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1196: recipe for target 'modules' failed
> make: *** [modules] Error 2
>
>
>> create mode 100644 arch/arm64/include/asm/extio.h
>> create mode 100644 arch/arm64/kernel/extio.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 969ef88..b44070b 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
>> config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> default 16
>>
>> +config ARM64_INDIRECT_PIO
>> + bool "access peripherals with legacy I/O port"
>> + help
>> + Support special accessors for ISA I/O devices. This is needed for
>> + SoCs that do not support standard read/write for the ISA range.
>> +
>> config NO_IOPORT_MAP
>> def_bool y if !PCI
>>
>> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
>> new file mode 100644
>> index 0000000..6ae0787
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/extio.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __LINUX_EXTIO_H
>> +#define __LINUX_EXTIO_H
>> +
>> +struct extio_ops {
>> + unsigned long start;/* inclusive, sys io addr */
>> + unsigned long end;/* inclusive, sys io addr */
>> +
>> + u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
>> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
>> + size_t dlen);
>> + u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
>> + size_t dlen, unsigned int count);
>> + void (*pfouts)(void *devobj, unsigned long ptaddr,
>> + const void *outbuf, size_t dlen,
>> + unsigned int count);
>> + void *devpara;
>> +};
>> +
>> +extern struct extio_ops *arm64_extio_ops;
>> +
>> +#define DECLARE_EXTIO(bw, type) \
>> +extern type in##bw(unsigned long addr); \
>> +extern void out##bw(type value, unsigned long addr); \
>> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
>> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
>> +
>> +#define BUILD_EXTIO(bw, type) \
>> +type in##bw(unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + return read##bw(PCI_IOBASE + addr); \
>> + return arm64_extio_ops->pfin ? \
>> + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
>> + addr, sizeof(type)) : -1; \
>> +} \
>> + \
>> +void out##bw(type value, unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + write##bw(value, PCI_IOBASE + addr); \
>> + else \
>> + if (arm64_extio_ops->pfout) \
>> + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>> + addr, value, sizeof(type)); \
>> +} \
>> + \
>> +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + reads##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfins) \
>> + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +} \
>> + \
>> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + writes##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfouts) \
>> + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +}
>> +
>> +static inline void arm64_set_extops(struct extio_ops *ops)
>> +{
>> + if (ops)
>> + WRITE_ONCE(arm64_extio_ops, ops);
>> +}
>> +
>> +#endif /* __LINUX_EXTIO_H*/
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0bba427..136735d 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -31,6 +31,7 @@
>> #include <asm/early_ioremap.h>
>> #include <asm/alternative.h>
>> #include <asm/cpufeature.h>
>> +#include <asm/extio.h>
>>
>> #include <xen/xen.h>
>>
>> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>
>> +
>> +/*
>> + * redefine the in(s)b/out(s)b for indirect-IO.
>> + */
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define inb inb
>> +#define outb outb
>> +#define insb insb
>> +#define outsb outsb
>> +/* external declaration */
>> +DECLARE_EXTIO(b, u8)
>> +
>> +#define inw inw
>> +#define outw outw
>> +#define insw insw
>> +#define outsw outsw
>> +
>> +DECLARE_EXTIO(w, u16)
>> +
>> +#define inl inl
>> +#define outl outl
>> +#define insl insl
>> +#define outsl outsl
>> +
>> +DECLARE_EXTIO(l, u32)
>> +#endif
>> +
>> +
>> /*
>> * String version of I/O memory access operations.
>> */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 7d66bba..60e0482 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
>> sys_compat.o entry32.o
>> arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
>> arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
>> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
>> arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
>> arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
>> arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> new file mode 100644
>> index 0000000..647b3fa
>> --- /dev/null
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/io.h>
>> +
>> +struct extio_ops *arm64_extio_ops;
>> +
>> +
>> +BUILD_EXTIO(b, u8)
>> +
>> +BUILD_EXTIO(w, u16)
>> +
>> +BUILD_EXTIO(l, u32)
>> --
>> 1.9.1
>>
>
>
>
^ permalink raw reply
* [PATCH] pinctrl: single: fix spelling mistakes on "Ivalid"
From: Colin King @ 2016-12-23 0:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fixe to spelling mistake "Ivalid" to "Invalid" in
dev_err error message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/pinctrl/pinctrl-single.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a5a0392..25edadf 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1134,7 +1134,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
rows = pinctrl_count_index_with_args(np, name);
if (rows <= 0) {
- dev_err(pcs->dev, "Ivalid number of rows: %d\n", rows);
+ dev_err(pcs->dev, "Invalid number of rows: %d\n", rows);
return -EINVAL;
}
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Sarangdhar Joshi @ 2016-12-23 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222130246.GA8359@builder>
On 12/22/2016 5:02 AM, Bjorn Andersson wrote:
> On Wed 21 Dec 19:16 PST 2016, Suman Anna wrote:
>
>> Hi Sarang,
>>
>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>> firmware loading to complete successfully before calling
>>> rproc_boot(). The same can be achieved by just setting
>>> rproc->auto_boot flag. Change this. As a result this change
>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>> initialization to the wkup_m3_ipc_probe().
>>>
>>> Other than the current usage, the firmware_loading_complete is
>>> only used in rproc_del() where it's no longer needed. This
>>> change is in preparation for removing firmware_loading_complete
>>> completely.
>>
>> Based on the comments so far, I am assuming that you are dropping this
>> series.
>>
>
> Following up on those comments only revealed that we have several other
> similar race conditions, so I'm hoping that Sarangdhar will continue to
> work on fixing those - and in this process get rid of this completion.
>
>> In any case, this series did break our PM stack. We definitely don't
>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>> need to stay with the wkup_m3_ipc driver.
>>
>
> Reviewing the wkup_m3 situation again I see that as we have moved the
> resource table parsing to the rproc_boot() path there's no longer any
> need for the wkup_m3_ipc driver to wait for the remoteproc-core-internal
> completion.
>
> If rproc_get_by_phandle() returns non-NULL it is initialized. We still
> don't want to call rproc_boot() from wkup_m3_ipc_probe(), so let's keep
> the wkup_m3_rproc_boot_thread().
Did you mean it's okay to call rproc_boot() from wkup_m3_ipc_probe()?
rproc_boot() calls request_firmware() anyways and so there is no need to
wait for completion of asynchronous firmware loading.
>
> Sarangdhar, could you update the wkup_m3_ipc patch to just drop the
> wait_for_completion() call?
Sure, assuming we should still keep the rproc_boot() call in the kthread.
Regards,
Sarang
>
> Regards,
> Bjorn
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Sarangdhar Joshi @ 2016-12-23 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f5b2631-f744-a5c1-55c1-82eb27d5cbd7@ti.com>
Hi Suman,
On 12/21/2016 7:16 PM, Suman Anna wrote:
> Hi Sarang,
>
> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>> firmware loading to complete successfully before calling
>> rproc_boot(). The same can be achieved by just setting
>> rproc->auto_boot flag. Change this. As a result this change
>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>> initialization to the wkup_m3_ipc_probe().
>>
>> Other than the current usage, the firmware_loading_complete is
>> only used in rproc_del() where it's no longer needed. This
>> change is in preparation for removing firmware_loading_complete
>> completely.
>
> Based on the comments so far, I am assuming that you are dropping this
> series.
No, may not be dropping this. Will try to handle it differently in
rproc_del() (probably by making use of some state flag).
>
> In any case, this series did break our PM stack. We definitely don't
> want to auto-boot the wkup_m3_rproc device, that responsibility will
> need to stay with the wkup_m3_ipc driver.
Which scenario did it break? Booting up rproc device before
wkup_m3_ipc_probe() causes issues?
Nevertheless, I think Bjorn's suggestion of just dropping the call to
wait_for_completion() and keeping kthread looks good, also because of
the fact that rproc_boot() anyways calls request_firmware() and no
longer needed to wait on asynchronous loading of firmware.
Regards,
Sarang
>
> regards
> Suman
>
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>> ---
>>
>> Hi Suman,
>>
>> Unfortunately, I don't have a TI device and couldn't test this
>> change. Is it possible for you to test this change on TI device?
>>
>> Thanks in advance.
>>
>> Regards,
>> Sarang
>>
>> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
>> drivers/soc/ti/wkup_m3_ipc.c | 35 ++---------------------------------
>> 2 files changed, 3 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
>> index 18175d0..79ea022 100644
>> --- a/drivers/remoteproc/wkup_m3_rproc.c
>> +++ b/drivers/remoteproc/wkup_m3_rproc.c
>> @@ -167,7 +167,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
>> goto err;
>> }
>>
>> - rproc->auto_boot = false;
>> + rproc->auto_boot = true;
>>
>> wkupm3 = rproc->priv;
>> wkupm3->rproc = rproc;
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..31090d70 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -17,7 +17,6 @@
>>
>> #include <linux/err.h>
>> #include <linux/kernel.h>
>> -#include <linux/kthread.h>
>> #include <linux/interrupt.h>
>> #include <linux/irq.h>
>> #include <linux/module.h>
>> @@ -365,22 +364,6 @@ void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc)
>> }
>> EXPORT_SYMBOL_GPL(wkup_m3_ipc_put);
>>
>> -static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> -{
>> - struct device *dev = m3_ipc->dev;
>> - int ret;
>> -
>> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> - init_completion(&m3_ipc->sync_complete);
>> -
>> - ret = rproc_boot(m3_ipc->rproc);
>> - if (ret)
>> - dev_err(dev, "rproc_boot failed\n");
>> -
>> - do_exit(0);
>> -}
>> -
>> static int wkup_m3_ipc_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -388,7 +371,6 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>> phandle rproc_phandle;
>> struct rproc *m3_rproc;
>> struct resource *res;
>> - struct task_struct *task;
>> struct wkup_m3_ipc *m3_ipc;
>>
>> m3_ipc = devm_kzalloc(dev, sizeof(*m3_ipc), GFP_KERNEL);
>> @@ -402,6 +384,8 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>> return PTR_ERR(m3_ipc->ipc_mem_base);
>> }
>>
>> + init_completion(&m3_ipc->sync_complete);
>> +
>> irq = platform_get_irq(pdev, 0);
>> if (!irq) {
>> dev_err(&pdev->dev, "no irq resource\n");
>> @@ -449,25 +433,10 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>>
>> m3_ipc->ops = &ipc_ops;
>>
>> - /*
>> - * Wait for firmware loading completion in a thread so we
>> - * can boot the wkup_m3 as soon as it's ready without holding
>> - * up kernel boot
>> - */
>> - task = kthread_run((void *)wkup_m3_rproc_boot_thread, m3_ipc,
>> - "wkup_m3_rproc_loader");
>> -
>> - if (IS_ERR(task)) {
>> - dev_err(dev, "can't create rproc_boot thread\n");
>> - goto err_put_rproc;
>> - }
>> -
>> m3_ipc_state = m3_ipc;
>>
>> return 0;
>>
>> -err_put_rproc:
>> - rproc_put(m3_rproc);
>> err_free_mbox:
>> mbox_free_channel(m3_ipc->mbox);
>> return ret;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC] arm64/acpi: make ACPI boot preference configurable
From: Mark Rutland @ 2016-12-22 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7eba0601099f75f19021c4259eca75ada06f4511.1482341997.git.jtoppins@redhat.com>
Hi,
On Wed, Dec 21, 2016 at 12:54:05PM -0500, Jonathan Toppins wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
>
> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is empty. If the dtb passed to the kernel is non-empty then device-tree
> will be chosen as the boot method of choice even if it is not correct.
> To prevent this situation where a system is only intended to be booted
> via ACPI a user can set this kernel configuration so it ignores
> device-tree settings unless ACPI table checks fail.
I'm a little confused here. Judging by the comment inside acpi_boot_table_init,
and the code immediately below it, in the absence of a "real" DTB, ACPI will be
used.
Could you elaborate on the situation where "a system is only intended to be
booted via ACPI"? e.g. whose preference or requirement is this? The HW vendor,
distro, or user? Why/when would the current behaviour not be correct?
Thanks,
Mark.
>
> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
> ---
> arch/arm64/Kconfig | 13 +++++++++++++
> arch/arm64/kernel/acpi.c | 2 +-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 111742126897..e432e84245b9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -954,6 +954,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
> protocol even if the corresponding data is present in the ACPI
> MADT table.
>
> +config ARM64_PREFER_ACPI
> + bool "Prefer usage of ACPI boot tables over device-tree"
> + depends on ACPI
> + help
> + Normally device-tree is preferred over ACPI on arm64 unless
> + explicitly preferred via kernel command line, something like: acpi=on
> + This configuration changes this default behaviour by pretending
> + the user set acpi=on on the command line. This configuration still
> + allows the user to turn acpi table parsing off via acpi=off. If
> + for some reason the table checks fail the system will still fall
> + back to using device-tree unless the user explicitly sets acpi=force
> + on the command line.
> +
> config CMDLINE
> string "Default kernel command string"
> default ""
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 252a6d9c1da5..b5dfa5752ff7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -43,7 +43,7 @@ int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
> EXPORT_SYMBOL(acpi_pci_disabled);
>
> static bool param_acpi_off __initdata;
> -static bool param_acpi_on __initdata;
> +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
> static bool param_acpi_force __initdata;
>
> static int __init parse_acpi(char *arg)
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Rob Herring @ 2016-12-22 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-5-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 22, 2016 at 05:13:27PM +1300, Chris Packham wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 10 +
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 231 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 78 +++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 78 +++++++
> 4 files changed, 397 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> new file mode 100644
> index 000000000000..e7dc9b2dd90b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> @@ -0,0 +1,10 @@
> +Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
> +----------------------------------------------------------------------
> +
> +Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
> +shall have the following property:
> +
> +Required root node property:
> +
> +compatible: one of "marvell,armadaxp-98dx3236", "marvell,armadaxp-98dx3336"
> + or "marvell,armadaxp-98dx4251"
The 3336 and 4251 are compatible with 3236 according to the dts files.
That needs to be expressed here.
Rob
^ permalink raw reply
* [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Rob Herring @ 2016-12-22 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-4-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 22, 2016 at 05:13:26PM +1300, Chris Packham wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> .../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 +++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 145 +++++++++++++++++++++
> 2 files changed, 191 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
^ permalink raw reply
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Mark Rutland @ 2016-12-22 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-3-alexander.stein@systec-electronic.com>
Hi,
On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote:
> This driver can only built into the kernel. So disallow driver bind/unbind
> and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is
> enabled.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> arch/arm/kernel/perf_event_v7.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index b942349..795e373 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -2029,6 +2029,7 @@ static int armv7_pmu_device_probe(struct platform_device *pdev)
> static struct platform_driver armv7_pmu_driver = {
> .driver = {
> .name = "armv7-pmu",
> + .suppress_bind_attrs = true,
> .of_match_table = armv7_pmu_of_device_ids,
> },
While this patch looks correct, the other perf_event_* drivers (e.g. those
under arch/arm/) will need similar treatment.
More generally, updating each and every driver in this manner seems like a
scattergun approach that is tiresome and error prone.
IMO, it would be vastly better for a higher layer to enforce that we don't
attempt to unbind drivers where the driver does not have a remove callback, as
is the case here (and I suspect most over cases where DEBUG_TEST_DRIVER_REMOVE
is blowing up).
Is there any reason that can't be enforced at the bus layer, say?
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Rob Herring @ 2016-12-22 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-3-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 22, 2016 at 05:13:25PM +1300, Chris Packham wrote:
> Compared to the armada-xp the 98DX3336 uses different registers to set
> the boot address for the secondary CPU so a new enable-method is needed.
> This will only work if the machine definition doesn't define an overall
> smp_ops because there is not currently a way of overriding this from the
> device tree if it is set in the machine definition.
Doesn't look like you documented the enable-method value.
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> .../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 ++++++
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/common.h | 1 +
> arch/arm/mach-mvebu/platsmp.c | 43 ++++++++++++++
> arch/arm/mach-mvebu/pmsu-98dx3236.c | 69 ++++++++++++++++++++++
> 5 files changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
> create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
^ permalink raw reply
* [PATCH] mm: pmd dirty emulation in page fault handler
From: Andreas Schwab @ 2016-12-22 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222145203.GA18970@bbox>
On Dez 22 2016, Minchan Kim <minchan@kernel.org> wrote:
> From b3ec95c0df91ad113525968a4a6b53030fd0b48d Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@kernel.org>
> Date: Thu, 22 Dec 2016 23:43:49 +0900
> Subject: [PATCH v2] mm: pmd dirty emulation in page fault handler
>
> Andreas reported [1] made a test in jemalloc hang in THP mode in arm64.
> http://lkml.kernel.org/r/mvmmvfy37g1.fsf at hawking.suse.de
>
> The problem is page fault handler supports only accessed flag emulation
> for THP page of SW-dirty/accessed architecture.
>
> This patch enables dirty-bit emulation for those architectures.
> Without it, MADV_FREE makes application hang by repeated fault forever.
>
> [1] b8d3c4c3009d, mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called
Successfully tested a backport to 4.9.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs
From: Corey Minyard @ 2016-12-22 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>
It looks like this is ready. Should I take this in the IPMI tree, or is
there a better tree for it?
-corey
On 12/20/2016 01:15 AM, Andrew Jeffery wrote:
> Hi Lee,
>
> Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:
>
> https://lkml.org/lkml/2016/12/5/835
>
> Changes since v3:
>
> * Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
> directory as well as the the last patch in v3, which moved a number of
> existing bindings. Eventually the Aspeed display controller will have a
> device-specific driver so it doesn't belong there either.
>
> * Add a compatible string for the AST2400 in the LPC Host Controller bindings
> as requested by Joel and slightly tweak the reg description for Rob.
>
> [1] https://lkml.org/lkml/2016/12/13/202
>
> Andrew Jeffery (5):
> mfd: dt: Fix "indicates" typo in mfd bindings document
> mfd: dt: ranges, #address-cells and #size-cells as optional properties
> mfd: dt: Add Aspeed Low Pin Count Controller bindings
> mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
> mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
>
> .../devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +++++++++++++++++++++
> Documentation/devicetree/bindings/mfd/mfd.txt | 12 +-
> 3 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>
^ permalink raw reply
* [PATCH] drivers: remoteproc: constify rproc_ops structures
From: Suman Anna @ 2016-12-22 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481974176-19912-1-git-send-email-bhumirks@gmail.com>
On 12/17/2016 05:29 AM, Bhumika Goyal wrote:
> Declare rproc_ops structures as const as they are only passed as an
> argument to the function rproc_alloc. This argument is of type const, so
> rproc_ops structures having this property can be declared const too.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct rproc_ops i at p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> rproc_alloc(...,&i at p,...)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i at p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct rproc_ops i;
>
> File sizes before:
> text data bss dec hex filename
> 1258 416 0 1674 68a remoteproc/omap_remoteproc.o
> 2402 240 0 2642 a52 remoteproc/st_remoteproc.o
> 2064 272 0 2336 920 remoteproc/st_slim_rproc.o
> 2160 240 0 2400 960 remoteproc/wkup_m3_rproc.o
>
> File sizes after:
> text data bss dec hex filename
> 1297 368 0 1665 681 remoteproc/omap_remoteproc.o
> 2434 192 0 2626 a42 remoteproc/st_remoteproc.o
> 2112 240 0 2352 930 remoteproc/st_slim_rproc.o
> 2200 192 0 2392 958 remoteproc/wkup_m3_rproc.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Thanks for the cleanup. The da8xx_remoteproc.c file could also use the
same fix.
regards
Suman
> ---
> drivers/remoteproc/omap_remoteproc.c | 2 +-
> drivers/remoteproc/st_remoteproc.c | 2 +-
> drivers/remoteproc/st_slim_rproc.c | 2 +-
> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index fa63bf2..a96ce90 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -177,7 +177,7 @@ static int omap_rproc_stop(struct rproc *rproc)
> return 0;
> }
>
> -static struct rproc_ops omap_rproc_ops = {
> +static const struct rproc_ops omap_rproc_ops = {
> .start = omap_rproc_start,
> .stop = omap_rproc_stop,
> .kick = omap_rproc_kick,
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> index da4e152..f21787b 100644
> --- a/drivers/remoteproc/st_remoteproc.c
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -107,7 +107,7 @@ static int st_rproc_stop(struct rproc *rproc)
> return sw_err ?: pwr_err;
> }
>
> -static struct rproc_ops st_rproc_ops = {
> +static const struct rproc_ops st_rproc_ops = {
> .start = st_rproc_start,
> .stop = st_rproc_stop,
> };
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> index 507716c..6cfd862 100644
> --- a/drivers/remoteproc/st_slim_rproc.c
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -200,7 +200,7 @@ static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> return va;
> }
>
> -static struct rproc_ops slim_rproc_ops = {
> +static const struct rproc_ops slim_rproc_ops = {
> .start = slim_rproc_start,
> .stop = slim_rproc_stop,
> .da_to_va = slim_rproc_da_to_va,
> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
> index 18175d0..1ada0e5 100644
> --- a/drivers/remoteproc/wkup_m3_rproc.c
> +++ b/drivers/remoteproc/wkup_m3_rproc.c
> @@ -111,7 +111,7 @@ static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> return va;
> }
>
> -static struct rproc_ops wkup_m3_rproc_ops = {
> +static const struct rproc_ops wkup_m3_rproc_ops = {
> .start = wkup_m3_rproc_start,
> .stop = wkup_m3_rproc_stop,
> .da_to_va = wkup_m3_rproc_da_to_va,
>
^ permalink raw reply
* [PATCH] devicetree: bindings: clk: mvebu: fix description for sata1 on Armada XP
From: Rob Herring @ 2016-12-22 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220212005.26139-1-uwe@kleine-koenig.org>
On Tue, Dec 20, 2016 at 10:20:05PM +0100, Uwe Kleine-K?nig wrote:
> SATA Host 0 clock is (as correctly documented) id 15/sata0.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
> Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Rob
>
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> index cb8542d910b3..5142efc8099d 100644
> --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> @@ -117,7 +117,7 @@ ID Clock Peripheral
> 25 tdm Time Division Mplx
> 28 xor1 XOR DMA 1
> 29 sata1lnk
> -30 sata1 SATA Host 0
> +30 sata1 SATA Host 1
>
> The following is a list of provided IDs for Dove:
> ID Clock Peripheral
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH 1/3] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: Rob Herring @ 2016-12-22 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482265384-715-2-git-send-email-david@lechnology.com>
On Tue, Dec 20, 2016 at 02:23:02PM -0600, David Lechner wrote:
> This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> Documentation/devicetree/bindings/serial/8250.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes
From: kbuild test robot @ 2016-12-22 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a6cc4637621d2ef0d84754817128c43795cb022.1482424395.git.cyrille.pitchen@atmel.com>
Hi Cyrille,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto-atmel-authenc-add-support-to-authenc-hmac-shaX-Y-aes-modes/20161223-015820
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:305:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_cpu':
>> drivers/crypto/atmel-sha.c:465:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
>> drivers/crypto/atmel-sha.c:465:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^~~~~~~
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_pdc':
drivers/crypto/atmel-sha.c:494:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/crypto/atmel-sha.c:494:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^~~~~~~
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma':
drivers/crypto/atmel-sha.c:541:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/crypto/atmel-sha.c:541:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
^~~~~~~
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma_map':
>> drivers/crypto/atmel-sha.c:620:26: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
^
In file included from include/linux/printk.h:305:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_slow':
drivers/crypto/atmel-sha.c:641:19: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/crypto/atmel-sha.c:641:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
^~~~~~~
drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_start':
drivers/crypto/atmel-sha.c:669:19: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/crypto/atmel-sha.c:669:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
^~~~~~~
drivers/crypto/atmel-sha.c:711:27: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_err(dd->dev, "dma %u bytes error\n",
^
In file included from include/linux/printk.h:305:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-sha.c:17:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_finish':
drivers/crypto/atmel-sha.c:891:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
^
include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/crypto/atmel-sha.c:891:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
^~~~~~~
vim +465 drivers/crypto/atmel-sha.c
ebc82efa Nicolas Royer 2012-07-01 459 size_t length, int final)
ebc82efa Nicolas Royer 2012-07-01 460 {
ebc82efa Nicolas Royer 2012-07-01 461 struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer 2012-07-01 462 int count, len32;
ebc82efa Nicolas Royer 2012-07-01 463 const u32 *buffer = (const u32 *)buf;
ebc82efa Nicolas Royer 2012-07-01 464
d4905b38 Nicolas Royer 2013-02-20 @465 dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer 2013-02-20 466 ctx->digcnt[1], ctx->digcnt[0], length, final);
ebc82efa Nicolas Royer 2012-07-01 467
ebc82efa Nicolas Royer 2012-07-01 468 atmel_sha_write_ctrl(dd, 0);
ebc82efa Nicolas Royer 2012-07-01 469
ebc82efa Nicolas Royer 2012-07-01 470 /* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer 2013-02-20 471 ctx->digcnt[0] += length;
d4905b38 Nicolas Royer 2013-02-20 472 if (ctx->digcnt[0] < length)
d4905b38 Nicolas Royer 2013-02-20 473 ctx->digcnt[1]++;
ebc82efa Nicolas Royer 2012-07-01 474
ebc82efa Nicolas Royer 2012-07-01 475 if (final)
ebc82efa Nicolas Royer 2012-07-01 476 dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
ebc82efa Nicolas Royer 2012-07-01 477
ebc82efa Nicolas Royer 2012-07-01 478 len32 = DIV_ROUND_UP(length, sizeof(u32));
ebc82efa Nicolas Royer 2012-07-01 479
ebc82efa Nicolas Royer 2012-07-01 480 dd->flags |= SHA_FLAGS_CPU;
ebc82efa Nicolas Royer 2012-07-01 481
ebc82efa Nicolas Royer 2012-07-01 482 for (count = 0; count < len32; count++)
ebc82efa Nicolas Royer 2012-07-01 483 atmel_sha_write(dd, SHA_REG_DIN(count), buffer[count]);
ebc82efa Nicolas Royer 2012-07-01 484
ebc82efa Nicolas Royer 2012-07-01 485 return -EINPROGRESS;
ebc82efa Nicolas Royer 2012-07-01 486 }
ebc82efa Nicolas Royer 2012-07-01 487
ebc82efa Nicolas Royer 2012-07-01 488 static int atmel_sha_xmit_pdc(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
ebc82efa Nicolas Royer 2012-07-01 489 size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
ebc82efa Nicolas Royer 2012-07-01 490 {
ebc82efa Nicolas Royer 2012-07-01 491 struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer 2012-07-01 492 int len32;
ebc82efa Nicolas Royer 2012-07-01 493
d4905b38 Nicolas Royer 2013-02-20 494 dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer 2013-02-20 495 ctx->digcnt[1], ctx->digcnt[0], length1, final);
ebc82efa Nicolas Royer 2012-07-01 496
ebc82efa Nicolas Royer 2012-07-01 497 len32 = DIV_ROUND_UP(length1, sizeof(u32));
ebc82efa Nicolas Royer 2012-07-01 498 atmel_sha_write(dd, SHA_PTCR, SHA_PTCR_TXTDIS);
ebc82efa Nicolas Royer 2012-07-01 499 atmel_sha_write(dd, SHA_TPR, dma_addr1);
ebc82efa Nicolas Royer 2012-07-01 500 atmel_sha_write(dd, SHA_TCR, len32);
ebc82efa Nicolas Royer 2012-07-01 501
ebc82efa Nicolas Royer 2012-07-01 502 len32 = DIV_ROUND_UP(length2, sizeof(u32));
ebc82efa Nicolas Royer 2012-07-01 503 atmel_sha_write(dd, SHA_TNPR, dma_addr2);
ebc82efa Nicolas Royer 2012-07-01 504 atmel_sha_write(dd, SHA_TNCR, len32);
ebc82efa Nicolas Royer 2012-07-01 505
ebc82efa Nicolas Royer 2012-07-01 506 atmel_sha_write_ctrl(dd, 1);
ebc82efa Nicolas Royer 2012-07-01 507
ebc82efa Nicolas Royer 2012-07-01 508 /* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer 2013-02-20 509 ctx->digcnt[0] += length1;
d4905b38 Nicolas Royer 2013-02-20 510 if (ctx->digcnt[0] < length1)
d4905b38 Nicolas Royer 2013-02-20 511 ctx->digcnt[1]++;
ebc82efa Nicolas Royer 2012-07-01 512
ebc82efa Nicolas Royer 2012-07-01 513 if (final)
ebc82efa Nicolas Royer 2012-07-01 514 dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
ebc82efa Nicolas Royer 2012-07-01 515
ebc82efa Nicolas Royer 2012-07-01 516 dd->flags |= SHA_FLAGS_DMA_ACTIVE;
ebc82efa Nicolas Royer 2012-07-01 517
ebc82efa Nicolas Royer 2012-07-01 518 /* Start DMA transfer */
ebc82efa Nicolas Royer 2012-07-01 519 atmel_sha_write(dd, SHA_PTCR, SHA_PTCR_TXTEN);
ebc82efa Nicolas Royer 2012-07-01 520
ebc82efa Nicolas Royer 2012-07-01 521 return -EINPROGRESS;
ebc82efa Nicolas Royer 2012-07-01 522 }
ebc82efa Nicolas Royer 2012-07-01 523
d4905b38 Nicolas Royer 2013-02-20 524 static void atmel_sha_dma_callback(void *data)
d4905b38 Nicolas Royer 2013-02-20 525 {
d4905b38 Nicolas Royer 2013-02-20 526 struct atmel_sha_dev *dd = data;
d4905b38 Nicolas Royer 2013-02-20 527
b48b114c Cyrille Pitchen 2016-12-22 528 dd->is_async = true;
b48b114c Cyrille Pitchen 2016-12-22 529
d4905b38 Nicolas Royer 2013-02-20 530 /* dma_lch_in - completed - wait DATRDY */
d4905b38 Nicolas Royer 2013-02-20 531 atmel_sha_write(dd, SHA_IER, SHA_INT_DATARDY);
d4905b38 Nicolas Royer 2013-02-20 532 }
d4905b38 Nicolas Royer 2013-02-20 533
d4905b38 Nicolas Royer 2013-02-20 534 static int atmel_sha_xmit_dma(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
d4905b38 Nicolas Royer 2013-02-20 535 size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
d4905b38 Nicolas Royer 2013-02-20 536 {
d4905b38 Nicolas Royer 2013-02-20 537 struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
d4905b38 Nicolas Royer 2013-02-20 538 struct dma_async_tx_descriptor *in_desc;
d4905b38 Nicolas Royer 2013-02-20 539 struct scatterlist sg[2];
d4905b38 Nicolas Royer 2013-02-20 540
d4905b38 Nicolas Royer 2013-02-20 @541 dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer 2013-02-20 542 ctx->digcnt[1], ctx->digcnt[0], length1, final);
d4905b38 Nicolas Royer 2013-02-20 543
d4905b38 Nicolas Royer 2013-02-20 544 dd->dma_lch_in.dma_conf.src_maxburst = 16;
d4905b38 Nicolas Royer 2013-02-20 545 dd->dma_lch_in.dma_conf.dst_maxburst = 16;
d4905b38 Nicolas Royer 2013-02-20 546
d4905b38 Nicolas Royer 2013-02-20 547 dmaengine_slave_config(dd->dma_lch_in.chan, &dd->dma_lch_in.dma_conf);
d4905b38 Nicolas Royer 2013-02-20 548
d4905b38 Nicolas Royer 2013-02-20 549 if (length2) {
d4905b38 Nicolas Royer 2013-02-20 550 sg_init_table(sg, 2);
d4905b38 Nicolas Royer 2013-02-20 551 sg_dma_address(&sg[0]) = dma_addr1;
d4905b38 Nicolas Royer 2013-02-20 552 sg_dma_len(&sg[0]) = length1;
d4905b38 Nicolas Royer 2013-02-20 553 sg_dma_address(&sg[1]) = dma_addr2;
d4905b38 Nicolas Royer 2013-02-20 554 sg_dma_len(&sg[1]) = length2;
d4905b38 Nicolas Royer 2013-02-20 555 in_desc = dmaengine_prep_slave_sg(dd->dma_lch_in.chan, sg, 2,
d4905b38 Nicolas Royer 2013-02-20 556 DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
d4905b38 Nicolas Royer 2013-02-20 557 } else {
d4905b38 Nicolas Royer 2013-02-20 558 sg_init_table(sg, 1);
d4905b38 Nicolas Royer 2013-02-20 559 sg_dma_address(&sg[0]) = dma_addr1;
d4905b38 Nicolas Royer 2013-02-20 560 sg_dma_len(&sg[0]) = length1;
d4905b38 Nicolas Royer 2013-02-20 561 in_desc = dmaengine_prep_slave_sg(dd->dma_lch_in.chan, sg, 1,
d4905b38 Nicolas Royer 2013-02-20 562 DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
d4905b38 Nicolas Royer 2013-02-20 563 }
d4905b38 Nicolas Royer 2013-02-20 564 if (!in_desc)
b48b114c Cyrille Pitchen 2016-12-22 565 atmel_sha_complete(dd, -EINVAL);
d4905b38 Nicolas Royer 2013-02-20 566
d4905b38 Nicolas Royer 2013-02-20 567 in_desc->callback = atmel_sha_dma_callback;
d4905b38 Nicolas Royer 2013-02-20 568 in_desc->callback_param = dd;
d4905b38 Nicolas Royer 2013-02-20 569
d4905b38 Nicolas Royer 2013-02-20 570 atmel_sha_write_ctrl(dd, 1);
d4905b38 Nicolas Royer 2013-02-20 571
d4905b38 Nicolas Royer 2013-02-20 572 /* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer 2013-02-20 573 ctx->digcnt[0] += length1;
d4905b38 Nicolas Royer 2013-02-20 574 if (ctx->digcnt[0] < length1)
d4905b38 Nicolas Royer 2013-02-20 575 ctx->digcnt[1]++;
d4905b38 Nicolas Royer 2013-02-20 576
d4905b38 Nicolas Royer 2013-02-20 577 if (final)
d4905b38 Nicolas Royer 2013-02-20 578 dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
d4905b38 Nicolas Royer 2013-02-20 579
d4905b38 Nicolas Royer 2013-02-20 580 dd->flags |= SHA_FLAGS_DMA_ACTIVE;
d4905b38 Nicolas Royer 2013-02-20 581
d4905b38 Nicolas Royer 2013-02-20 582 /* Start DMA transfer */
d4905b38 Nicolas Royer 2013-02-20 583 dmaengine_submit(in_desc);
d4905b38 Nicolas Royer 2013-02-20 584 dma_async_issue_pending(dd->dma_lch_in.chan);
d4905b38 Nicolas Royer 2013-02-20 585
d4905b38 Nicolas Royer 2013-02-20 586 return -EINPROGRESS;
d4905b38 Nicolas Royer 2013-02-20 587 }
d4905b38 Nicolas Royer 2013-02-20 588
d4905b38 Nicolas Royer 2013-02-20 589 static int atmel_sha_xmit_start(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
d4905b38 Nicolas Royer 2013-02-20 590 size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
d4905b38 Nicolas Royer 2013-02-20 591 {
d4905b38 Nicolas Royer 2013-02-20 592 if (dd->caps.has_dma)
d4905b38 Nicolas Royer 2013-02-20 593 return atmel_sha_xmit_dma(dd, dma_addr1, length1,
d4905b38 Nicolas Royer 2013-02-20 594 dma_addr2, length2, final);
d4905b38 Nicolas Royer 2013-02-20 595 else
d4905b38 Nicolas Royer 2013-02-20 596 return atmel_sha_xmit_pdc(dd, dma_addr1, length1,
d4905b38 Nicolas Royer 2013-02-20 597 dma_addr2, length2, final);
d4905b38 Nicolas Royer 2013-02-20 598 }
d4905b38 Nicolas Royer 2013-02-20 599
ebc82efa Nicolas Royer 2012-07-01 600 static int atmel_sha_update_cpu(struct atmel_sha_dev *dd)
ebc82efa Nicolas Royer 2012-07-01 601 {
ebc82efa Nicolas Royer 2012-07-01 602 struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer 2012-07-01 603 int bufcnt;
ebc82efa Nicolas Royer 2012-07-01 604
ebc82efa Nicolas Royer 2012-07-01 605 atmel_sha_append_sg(ctx);
ebc82efa Nicolas Royer 2012-07-01 606 atmel_sha_fill_padding(ctx, 0);
ebc82efa Nicolas Royer 2012-07-01 607 bufcnt = ctx->bufcnt;
ebc82efa Nicolas Royer 2012-07-01 608 ctx->bufcnt = 0;
ebc82efa Nicolas Royer 2012-07-01 609
ebc82efa Nicolas Royer 2012-07-01 610 return atmel_sha_xmit_cpu(dd, ctx->buffer, bufcnt, 1);
ebc82efa Nicolas Royer 2012-07-01 611 }
ebc82efa Nicolas Royer 2012-07-01 612
ebc82efa Nicolas Royer 2012-07-01 613 static int atmel_sha_xmit_dma_map(struct atmel_sha_dev *dd,
ebc82efa Nicolas Royer 2012-07-01 614 struct atmel_sha_reqctx *ctx,
ebc82efa Nicolas Royer 2012-07-01 615 size_t length, int final)
ebc82efa Nicolas Royer 2012-07-01 616 {
ebc82efa Nicolas Royer 2012-07-01 617 ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
d4905b38 Nicolas Royer 2013-02-20 618 ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
ebc82efa Nicolas Royer 2012-07-01 619 if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
ebc82efa Nicolas Royer 2012-07-01 @620 dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
d4905b38 Nicolas Royer 2013-02-20 621 ctx->block_size);
b48b114c Cyrille Pitchen 2016-12-22 622 atmel_sha_complete(dd, -EINVAL);
ebc82efa Nicolas Royer 2012-07-01 623 }
:::::: The code at line 465 was first introduced by commit
:::::: d4905b38d1f6b60761a6fd16f45ebd1fac8b6e1f crypto: atmel-sha - add support for latest release of the IP (0x410)
:::::: TO: Nicolas Royer <nicolas@eukrea.com>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47848 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161223/43b808a1/attachment-0001.gz>
^ permalink raw reply
* [PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Rob Herring @ 2016-12-22 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-5-andrew@aj.id.au>
On Tue, Dec 20, 2016 at 05:45:34PM +1030, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>
> Linus: I've retained your r-b tag I don't think the addition of the ast2400
> compatible string will fuss you. Please let me know if you feel this is
> inappropriate.
>
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [BISECTED] v4.9: OMAP MMC regression
From: Aaro Koskinen @ 2016-12-22 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217220120.xgyzq2hwxn3lsmm2@raspberrypi-2.musicnaut.iki.fi>
Hi,
On Sun, Dec 18, 2016 at 12:01:21AM +0200, Aaro Koskinen wrote:
> OMAP MMC is silently missing when booting v4.9 on Nokia 770 (OMAP1).
>
> Bisected to:
>
> commit 2d1a9a946faebfedd660a1f1c2b90984fff41f91
> Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Date: Wed Jul 20 11:50:29 2016 +0300
>
> dmaengine: omap-dma: Dynamically allocate memory for lch_map
>
> Reveting the commit makes MMC to appear and work again...
This commit basically reduces dma_requests count to 17 (from 127)
on OMAP1.
This cannot be correct, since OMAP1 MMC is using requests (from
omap1_init_mmc):
rx_req = 22;
tx_req = 21;
[...]
rx_req = 55;
tx_req = 54;
MMC probe will fail because omap_dma_filter_fn() will fail during
dma_request_chan().
I think 2d1a9a946faebfedd660a1f1c2b90984fff41f91 should be reverted.
I cannot anymore boot my 770 with >= 4.9 kernel.
A.
^ permalink raw reply
* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-22 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc7bebd2-ad03-6479-d6e7-42f5d724216c@linaro.org>
On 12/22, zhangfei wrote:
> On 2016?12?22? 07:25, Stephen Boyd wrote:
> >On 12/15, Zhangfei Gao wrote:
> >>Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >
> >>+
> >>+ switch (type) {
> >>+ case HI3660_CRGCTRL:
> >>+ hi3660_clk_crgctrl_init(np);
> >>+ break;
> >>+ case HI3660_PCTRL:
> >>+ hi3660_clk_pctrl_init(np);
> >>+ break;
> >>+ case HI3660_PMUCTRL:
> >>+ hi3660_clk_pmuctrl_init(np);
> >>+ break;
> >>+ case HI3660_SCTRL:
> >>+ hi3660_clk_sctrl_init(np);
> >>+ break;
> >>+ case HI3660_IOMCU:
> >>+ hi3660_clk_iomcu_init(np);
> >>+ break;
> >This "multi-device" driver design is sort of odd. Why not have
> >different files and struct drivers for the different devices in
> >the system that are clock controllers? I don't really understand
> >why we're controlling the devices with one struct driver
> >instance. Is something shared between the devices?
> Do you mean put in different .c / drivers?
Yes.
> They have to be put in the same file, since the parent / child
> relate to each other.
We handle clk parent/child relationships through strings. So why
does that mean we need to put these in the same file with the
same struct driver?
> They are for the same chip, but some put in different region for
> privilege control.
Ok.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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