* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-24 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYOuuPzPHyUSm_zyq1iq1FeaCoQ03Ko4yO8mmM+PDGm5gw@mail.gmail.com>
Hi, Tobias
Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
Best Regards.
Anson huang ???
?
Freescale Semiconductor Shanghai
?????????192?A?2?
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 4:17 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Hi Anson / Shawn,
>
>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of Freescale
>alpha release. In alpha, the usleep_range did not exist. I tried removing it,
>build the kernel again and it works.
>I didn't get crashes anymore...
>
>Regards,
>
>john
>
>
>
>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
><Anson.Huang@freescale.com> wrote:
>> Hi, Tobias and Shawn
>> I debug into this issue today, the root cause is that we have a
>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's clk_pllv3_wait_lock
>function, which will cause kernel schedule during cpufreq change, and the idle
>thread has another clk operation which will cause mutex nest, and it will try
>to wake up previous mutex hold by cpufreq change's pll1 clk_set_rate.
>> So, to fix this issue, we should not use any usleep in the wait
>function of pllv3's code, or we should not call any clk API in the
>imx6sl_set_wait_clk function. What do you think?
>>
>> BTW, I found another issue, if EVK board boot up with 396MHz, then
>the initialized clock parent status is wrong, as ARM is from PFD 396MHz, I
>will generate another patch to fix that once I have bandwidth.
>>
>> Best Regards.
>> Anson huang ???
>>
>> Freescale Semiconductor Shanghai
>> ?????????192?A?2?
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: Huang Yongcai-B20788
>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>To: John Tobias
>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi, Tobias
>>> I will debug it next week and feedback to you. Thanks.
>>>
>>>Sent from Anson's iPhone
>>>
>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>
>>>> Hi Anson,
>>>>
>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>> called in imx6sl_enter_wait.
>>>>
>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>> [<80045650>]
>>>> (deactivate_task+0x30/0x34)
>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>> (schedule+0x38/0x88)
>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>> (schedule_preempt_disabled+0x10/0x14)
>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585] [<8001e54c>]
>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>> r4:00000001 [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c)
>>>> from [<80317608>] (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>> r7:00000001
>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>> r4:806d2000
>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>> [<800590f4>]
>>>> (cpu_startup_entry+0xe0/0x120)
>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>> [<806a2b00>]
>>>> (start_kernel+0x348/0x354)
>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>> (0x80008070)
>>>>
>>>>
>>>> Regards,
>>>>
>>>> john
>>>>
>>>>
>
^ permalink raw reply
* Freescale FEC packet loss
From: fugang.duan at freescale.com @ 2014-01-24 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231520.56990.marex@denx.de>
From: Marek Vasut <marex@denx.de>
Data: Thursday, January 23, 2014 10:21 PM
>To: Duan Fugang-B38611
>Cc: netdev at vger.kernel.org; Li Frank-B20596; Estevam Fabio-R49496; Hector
>Palacios; linux-arm-kernel at lists.infradead.org; Detlev Zundel; Eric Nelson
>Subject: Re: Freescale FEC packet loss
>
>On Thursday, January 23, 2014 at 02:49:48 AM, fugang.duan at freescale.com wrote:
>[...]
>
>> >[ 3] 71.0-72.0 sec 23.4 MBytes 196 Mbits/sec
>> >[ 3] 72.0-73.0 sec 12.2 MBytes 103 Mbits/sec
>> >[ 3] 73.0-74.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 74.0-75.0 sec
>> >0.00 Bytes 0.00 bits/sec [ 3] 75.0-76.0 sec 10.9 MBytes 91.2 Mbits/sec
>> >[ 3] 76.0-77.0 sec 22.4 MBytes 188 Mbits/sec
>> >[ 3] 77.0-78.0 sec 23.0 MBytes 193 Mbits/sec
>>
>> I will debug the issue when I am free, and then report the result to you.
>> Thanks for your reporting the issue.
>
>Hi Andy,
>
>Thanks for looking into this. Is there any way I can help you with figuring out
>the issue ? Do you need any more feedback or anything please ?
>
No, the information is enough. Thanks for your testing.
Best Regards,
Andy
^ permalink raw reply
* [PATCH v3 2/2] i2c: New bus driver for the QUP I2C controller
From: Philip Elcan @ 2014-01-24 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389999819-10648-3-git-send-email-bjorn.andersson@sonymobile.com>
On 01/17/2014 06:03 PM, Bjorn Andersson wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> This bus driver supports the QUP i2c hardware controller in the Qualcomm
> MSM SOCs. The Qualcomm Universal Peripheral Engine (QUP) is a general
> purpose data path engine with input/output FIFOs and an embedded i2c
> mini-core. The driver supports FIFO mode (for low bandwidth applications)
> and block mode (interrupt generated for each block-size data transfer).
> The driver currently does not support DMA transfers.
>
> Shamelessly based on codeaurora version of the driver.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> [bjorn: updated to reflect i2c framework changes
> splited up qup_i2c_enable() in enable/disable
> don't overwrite ret value on error in xfer functions
> initilize core for each transfer
> remove explicit pinctrl selection
> use existing clock instead of setting new core clock]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
<snip>
> +
> + io_mode = readl(qup->base + QUP_IO_MODE);
> +
> + size = QUP_OUTPUT_BLOCK_SIZE(io_mode);
> + if (size)
> + qup->out_blk_sz = size * 16;
> + else
> + qup->out_blk_sz = 16;
> +
> + size = QUP_INPUT_BLOCK_SIZE(io_mode);
> + if (size)
> + qup->in_blk_sz = size * 16;
> + else
> + qup->in_blk_sz = 16;
> +
> + qup->xfer_time = msecs_to_jiffies(qup->out_fifo_sz);
qup->xfer_time should be set after you calculate qup->out_fifo_sz below.
> +
> + /*
> + * The block/fifo size w.r.t. 'actual data' is 1/2 due to 'tag'
> + * associated with each byte written/received
> + */
> + qup->out_blk_sz /= 2;
> + qup->in_blk_sz /= 2;
> +
> + size = QUP_OUTPUT_FIFO_SIZE(io_mode);
> + qup->out_fifo_sz = qup->out_blk_sz * (2 << size);
> +
> + size = QUP_INPUT_FIFO_SIZE(io_mode);
> + qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
> +
> + /*
> + * Wait for FIFO number of bytes to be absolutely sure
> + * that I2C write state machine is not idle. Each byte
> + * takes 9 clock cycles. (8 bits + 1 ack)
> + */
> + qup->wait_idle = qup->one_bit_t * 9;
> + qup->wait_idle *= qup->out_fifo_sz;
> +
> + dev_info(qup->dev, "IN:block:%d, fifo:%d, OUT:block:%d, fifo:%d\n",
> + qup->in_blk_sz, qup->in_fifo_sz,
> + qup->out_blk_sz, qup->out_fifo_sz);
> +
> + i2c_set_adapdata(&qup->adap, qup);
> + qup->adap.algo = &qup_i2c_algo;
> + qup->adap.nr = pdev->id;
> + qup->adap.dev.parent = qup->dev;
> + qup->adap.dev.of_node = pdev->dev.of_node;
> + strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name));
> +
> + ret = i2c_add_numbered_adapter(&qup->adap);
> + if (!ret) {
> + pm_runtime_set_autosuspend_delay(qup->dev, MSEC_PER_SEC);
> + pm_runtime_use_autosuspend(qup->dev);
> + pm_runtime_enable(qup->dev);
> + return 0;
> + }
> +fail:
> + qup_i2c_disable_clocks(qup);
> + return ret;
> +}
> +
> +static int qup_i2c_remove(struct platform_device *pdev)
> +{
> + struct qup_i2c_dev *qup = platform_get_drvdata(pdev);
> +
> + disable_irq(qup->irq);
> + qup_i2c_disable_clocks(qup);
> + i2c_del_adapter(&qup->adap);
> + pm_runtime_disable(qup->dev);
> + pm_runtime_set_suspended(qup->dev);
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int qup_i2c_pm_suspend_runtime(struct device *device)
> +{
> + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> +
> + dev_dbg(device, "pm_runtime: suspending...\n");
> + qup_i2c_disable_clocks(qup);
> + return 0;
> +}
> +
> +static int qup_i2c_pm_resume_runtime(struct device *device)
> +{
> + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> +
> + dev_dbg(device, "pm_runtime: resuming...\n");
> + qup_i2c_enable_clocks(qup);
> + return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int qup_i2c_suspend(struct device *device)
> +{
> + dev_dbg(device, "system suspend");
> + qup_i2c_pm_suspend_runtime(device);
> + return 0;
> +}
> +
> +static int qup_i2c_resume(struct device *device)
> +{
> + dev_dbg(device, "system resume");
> + qup_i2c_pm_resume_runtime(device);
> + pm_runtime_mark_last_busy(device);
> + pm_request_autosuspend(device);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops qup_i2c_qup_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(
> + qup_i2c_suspend,
> + qup_i2c_resume)
> + SET_RUNTIME_PM_OPS(
> + qup_i2c_pm_suspend_runtime,
> + qup_i2c_pm_resume_runtime,
> + NULL)
> +};
> +
> +static const struct of_device_id qup_i2c_dt_match[] = {
> + {.compatible = "qcom,i2c-qup"},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
> +
> +static struct platform_driver qup_i2c_driver = {
> + .probe = qup_i2c_probe,
> + .remove = qup_i2c_remove,
> + .driver = {
> + .name = "i2c_qup",
> + .owner = THIS_MODULE,
> + .pm = &qup_i2c_qup_pm_ops,
> + .of_match_table = qup_i2c_dt_match,
> + },
> +};
> +
> +module_platform_driver(qup_i2c_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:i2c_qup");
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference
From: Simon Horman @ 2014-01-24 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390525593.git.horms+renesas@verge.net.au>
From: Ben Dooks <ben.dooks@codethink.co.uk>
The R8A7790's dtsi file i2c0, i2c1, i2c2, and i2c3 nodes have clock
references to the mstp3_clks clock node, however these clocks are in the
mstp9_clks node.
The error was introducted in 72197ca7a1cb1cea5 ("ARM: shmobile: r8a7790:
Reference clocks") which is in Simon's current development tree.
This patch fixes the following error:
of_clk_src_onecell_get: invalid clock index 31
i2c-rcar e6508000.i2c: cannot get clock
i2c-rcar: probe of e6508000.i2c failed with error -2
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a179125..46ac214 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -197,7 +197,7 @@
reg = <0 0xe6508000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C0>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
status = "disabled";
};
@@ -208,7 +208,7 @@
reg = <0 0xe6518000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C1>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
status = "disabled";
};
@@ -219,7 +219,7 @@
reg = <0 0xe6530000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C2>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
status = "disabled";
};
@@ -230,7 +230,7 @@
reg = <0 0xe6540000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C3>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
status = "disabled";
};
--
1.8.4
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Fixes for v3.14
From: Simon Horman @ 2014-01-24 1:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
please consider this second round of renesas ARM Based SoC DT fixes for v3.14.
This pull-request is based on the first round of such fixes,
tagged as renesas-dt-fixes-for-v3.14, which you have previously pulled.
The following changes since commit 3effae8c26f451a9d572255c08dfbe342dd1dc98:
Revert "ARM: shmobile: r8a7791: Add SSI clocks in device tree" (2013-12-26 14:16:54 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-fixes2-for-v3.14
for you to fetch changes up to 2450badfc19b67340d3570665cc02a22df03dfab:
ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference (2014-01-21 09:45:50 +0900)
----------------------------------------------------------------
Second Round of Renesas ARM Based SoC DT Fixes for v3.14
Correct i2c clock references for r8a7790 (R-Car H2) SoC
The error was introduced in 72197ca7a1cb1cea5 ("ARM: shmobile: r8a7790:
Reference clocks") which is queued up for v3.14.
----------------------------------------------------------------
Ben Dooks (1):
ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference
arch/arm/boot/dts/r8a7790.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114616.GB15591@e106331-lin.cambridge.arm.com>
On 2014?01?22? 19:46, Mark Rutland wrote:
> On Mon, Jan 20, 2014 at 09:08:32AM +0000, Hanjun Guo wrote:
>> On 2014-1-17 22:21, Arnd Bergmann wrote:
>>> On Friday 17 January 2014, Hanjun Guo wrote:
>>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>>
>>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>>> name from the ACPI timer table is matched with all the registered
>>>> timer controllers and matching initialisation routine is invoked.
>>> I wouldn't anticipate this infrastructure to be required. Shouldn't all
>>> ARMv8 machines have an architected timer?
>> I not sure of this, could anyone can give some guidance? if only arch
>> timer is available for ARM64, this will make thing very simple.
> All ARMv8 systems should have an architected timer.
Thanks for the clarification :)
>
> However, they may also have other timers (e.g. global timers for use
> when CPUs are in low power states and their local architected timers
> aren't active).
Only arch timer (generic timer) is defined as a table in ACPI 5.0
spec at now, so other timers will not described as table and will
described as device object in DSDT table, so do you think we need
this framework or not?
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Olof Johansson @ 2014-01-24 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjwDg0TzhEGi-sZhtngXPbg=5u54ew6USpq3P7J9QQWjg@mail.gmail.com>
On Thu, Jan 23, 2014 at 4:20 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Jan 23, 2014 at 4:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 12/23/2013 10:37 AM, Olof Johansson wrote:
>>> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>>> multi_v7_defconfig was missing a large number of options that were in
>>>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>>>> following categories:
>> ...
>>>> Ok, fair enough. Applied.
>>>
>>> Actually, this one ended up getting messy. We've had
>>> multi_v7_defconfig updates in several branches so this doesn't apply
>>> cleanly anywhere.
>>>
>>> I'll apply it on top of for-next where the various branches are
>>> merged. It means we'll have to merge it late. Not a big deal, but
>>> please help me remember it in case it for some reason gets lost in the
>>> shuffle.
>>
>> I guess this is the correct time to remind you about this? That said,
>> the patch is in linux-next, so perhaps that counts as not having been
>> lost:-)
(Gah, fumbled the send button).
Yeah, i'm aware of this one, we'll include it with the late/* branches
once Linus merges our initial set of stuff.
-Olof
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114537.GA15591@e106331-lin.cambridge.arm.com>
On 2014?01?22? 19:45, Mark Rutland wrote:
> On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
>> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>
>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>
>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>> name from the ACPI timer table is matched with all the registered
>>> timer controllers and matching initialisation routine is invoked.
>>>
>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
>> to TIMER_OF_DECLARE() and I think this macro, if needed, should
>> be named TIMER_ACPI_DECLARE().
>>
>> The reason is that "clocksource" is a Linux-internal name and this
>> macro pertains to the hardware name in respective system
>> description type.
>>
>>> +#ifdef CONFIG_ACPI
>>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
>>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
>>> + __used __section(__clksrc_acpi_table) \
>>> + = { .id = compat, \
>>> + .driver_data = (kernel_ulong_t)fn }
>>> +#else
>>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
>>> +#endif
>> This hammers down the world to compile one binary for ACPI
>> and one binary for device tree. Maybe that's fine, I don't know.
> How does it do that?
>
> As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
> exclusive, and this just means that we only build the datastructures for
> matching from ACPI when CONFIG_ACPI is enabled.
>
> Have I missed something?
>
> I definitely don't want to see mutually exclusive ACPI and DT support.
ACPI and DT did the same job so I think they should mutually exclusive.
if we enable both DT and ACPI in one system, this will leading confusions.
Further more, firmware guys will be happy to present all the devices
in one way, not both of them.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Olof Johansson @ 2014-01-24 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E1B0EE.6080808@wwwdotorg.org>
On Thu, Jan 23, 2014 at 4:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 12/23/2013 10:37 AM, Olof Johansson wrote:
>> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>> multi_v7_defconfig was missing a large number of options that were in
>>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>>> following categories:
> ...
>>> Ok, fair enough. Applied.
>>
>> Actually, this one ended up getting messy. We've had
>> multi_v7_defconfig updates in several branches so this doesn't apply
>> cleanly anywhere.
>>
>> I'll apply it on top of for-next where the various branches are
>> merged. It means we'll have to merge it late. Not a big deal, but
>> please help me remember it in case it for some reason gets lost in the
>> shuffle.
>
> I guess this is the correct time to remind you about this? That said,
> the patch is in linux-next, so perhaps that counts as not having been
> lost:-)
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Stephen Warren @ 2014-01-24 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMj-nvMZhoX4fCe-mf0pBS27=EsS0o2bX7MgmZzjWhYVzQ@mail.gmail.com>
On 12/23/2013 10:37 AM, Olof Johansson wrote:
> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> multi_v7_defconfig was missing a large number of options that were in
>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>> following categories:
...
>> Ok, fair enough. Applied.
>
> Actually, this one ended up getting messy. We've had
> multi_v7_defconfig updates in several branches so this doesn't apply
> cleanly anywhere.
>
> I'll apply it on top of for-next where the various branches are
> merged. It means we'll have to merge it late. Not a big deal, but
> please help me remember it in case it for some reason gets lost in the
> shuffle.
I guess this is the correct time to remind you about this? That said,
the patch is in linux-next, so perhaps that counts as not having been
lost:-)
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYKwaH5DX27irzmcTDAMhQMUhuzz6N7mjKWv9tZchv0Ug@mail.gmail.com>
Hi Linus,
Sorry for the late reply.
On 2014?01?22? 16:26, Linus Walleij wrote:
> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>
>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>> name from the ACPI timer table is matched with all the registered
>> timer controllers and matching initialisation routine is invoked.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> be named TIMER_ACPI_DECLARE().
>
> The reason is that "clocksource" is a Linux-internal name and this
> macro pertains to the hardware name in respective system
> description type.
That make sense to me too, I will update in next version if
this patch is still needed.
>
>> +#ifdef CONFIG_ACPI
>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
>> + __used __section(__clksrc_acpi_table) \
>> + = { .id = compat, \
>> + .driver_data = (kernel_ulong_t)fn }
>> +#else
>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
>> +#endif
> This hammers down the world to compile one binary for ACPI
> and one binary for device tree. Maybe that's fine, I don't know.
This is a problem we can have some discussion on it.
I prefer mutually exclusive ACPI and DT support.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v3 07/24] drm/i2c: tda998x: set the video mode from the adjusted value
From: Darren Etheridge @ 2014-01-23 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195840.1ecab03b@armhf>
Jean-Francois Moine <moinejf@free.fr> wrote on Sun [2014-Jan-19 19:58:40 +0100]:
> This patch uses always the adjusted video mode instead of a mix of
> original and adjusted mode.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 66 +++++++++++++++++++--------------------
> 1 file changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index b688801..5d82301 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -773,7 +773,7 @@ tda998x_encoder_mode_valid(struct drm_encoder *encoder,
> static void
> tda998x_encoder_mode_set(struct drm_encoder *encoder,
> struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + struct drm_display_mode *adj_mode)
> {
> struct tda998x_priv *priv = to_tda998x_priv(encoder);
> uint16_t ref_pix, ref_line, n_pix, n_line;
> @@ -802,13 +802,13 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * So we add +1 to all horizontal and vertical register values,
> * plus an additional +3 for REFPIX as we are using RGB input only.
> */
> - n_pix = mode->htotal;
> - n_line = mode->vtotal;
> + n_pix = adj_mode->htotal;
> + n_line = adj_mode->vtotal;
>
> - hs_pix_e = mode->hsync_end - mode->hdisplay;
> - hs_pix_s = mode->hsync_start - mode->hdisplay;
> - de_pix_e = mode->htotal;
> - de_pix_s = mode->htotal - mode->hdisplay;
> + hs_pix_e = adj_mode->hsync_end - adj_mode->hdisplay;
> + hs_pix_s = adj_mode->hsync_start - adj_mode->hdisplay;
> + de_pix_e = adj_mode->htotal;
> + de_pix_s = adj_mode->htotal - adj_mode->hdisplay;
> ref_pix = 3 + hs_pix_s;
>
> /*
> @@ -816,37 +816,38 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * those to adjust the position of the rising VS edge by adding
> * HSKEW to ref_pix.
> */
> - if (adjusted_mode->flags & DRM_MODE_FLAG_HSKEW)
> - ref_pix += adjusted_mode->hskew;
> + if (adj_mode->flags & DRM_MODE_FLAG_HSKEW)
> + ref_pix += adj_mode->hskew;
>
> - if ((mode->flags & DRM_MODE_FLAG_INTERLACE) == 0) {
> - ref_line = 1 + mode->vsync_start - mode->vdisplay;
> - vwin1_line_s = mode->vtotal - mode->vdisplay - 1;
> - vwin1_line_e = vwin1_line_s + mode->vdisplay;
> + if ((adj_mode->flags & DRM_MODE_FLAG_INTERLACE) == 0) {
> + ref_line = 1 + adj_mode->vsync_start - adj_mode->vdisplay;
> + vwin1_line_s = adj_mode->vtotal - adj_mode->vdisplay - 1;
> + vwin1_line_e = vwin1_line_s + adj_mode->vdisplay;
> vs1_pix_s = vs1_pix_e = hs_pix_s;
> - vs1_line_s = mode->vsync_start - mode->vdisplay;
> + vs1_line_s = adj_mode->vsync_start - adj_mode->vdisplay;
> vs1_line_e = vs1_line_s +
> - mode->vsync_end - mode->vsync_start;
> + adj_mode->vsync_end - adj_mode->vsync_start;
> vwin2_line_s = vwin2_line_e = 0;
> vs2_pix_s = vs2_pix_e = 0;
> vs2_line_s = vs2_line_e = 0;
> } else {
> - ref_line = 1 + (mode->vsync_start - mode->vdisplay)/2;
> - vwin1_line_s = (mode->vtotal - mode->vdisplay)/2;
> - vwin1_line_e = vwin1_line_s + mode->vdisplay/2;
> + ref_line = 1 + (adj_mode->vsync_start -
> + adj_mode->vdisplay)/2;
> + vwin1_line_s = (adj_mode->vtotal - adj_mode->vdisplay)/2;
> + vwin1_line_e = vwin1_line_s + adj_mode->vdisplay/2;
> vs1_pix_s = vs1_pix_e = hs_pix_s;
> - vs1_line_s = (mode->vsync_start - mode->vdisplay)/2;
> + vs1_line_s = (adj_mode->vsync_start - adj_mode->vdisplay)/2;
> vs1_line_e = vs1_line_s +
> - (mode->vsync_end - mode->vsync_start)/2;
> - vwin2_line_s = vwin1_line_s + mode->vtotal/2;
> - vwin2_line_e = vwin2_line_s + mode->vdisplay/2;
> - vs2_pix_s = vs2_pix_e = hs_pix_s + mode->htotal/2;
> - vs2_line_s = vs1_line_s + mode->vtotal/2 ;
> + (adj_mode->vsync_end - adj_mode->vsync_start)/2;
> + vwin2_line_s = vwin1_line_s + adj_mode->vtotal/2;
> + vwin2_line_e = vwin2_line_s + adj_mode->vdisplay/2;
> + vs2_pix_s = vs2_pix_e = hs_pix_s + adj_mode->htotal/2;
> + vs2_line_s = vs1_line_s + adj_mode->vtotal/2 ;
> vs2_line_e = vs2_line_s +
> - (mode->vsync_end - mode->vsync_start)/2;
> + (adj_mode->vsync_end - adj_mode->vsync_start)/2;
> }
>
> - div = 148500 / mode->clock;
> + div = 148500 / adj_mode->clock;
>
> /* mute the audio FIFO: */
> reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
> @@ -896,9 +897,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * TDA19988 requires high-active sync at input stage,
> * so invert low-active sync provided by master encoder here
> */
> - if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NHSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_H_TGL);
> - if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NVSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_V_TGL);
>
Using the adj_mode->flags breaks a workaround I had done on BeagleBone Black
(tilcdc + tda998x) to resolve an issue with out of spec syncs from the
tlcdc. I invert the HSYNC in adj_mode->flags but don't want the tda998x to
really know that I am doing that so I use adj_mode in the tilcdc driver, and
mode here in the tda998x driver. The theory being adj_mode contains whatever
workarounds I need to do for the driving device and mode has the pristine
values that I want to send to the monitor. I would need to look if there is a
different way to solve this as I am guessing you are actually using adj_mode in
the manner it was intended.
Otherwise this patch series is working on BeagleBone Black - I have only tried
video so far (not audio).
Darren
> /*
> @@ -906,9 +907,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * revert input stage toggled sync at output stage
> */
> reg = TBG_CNTRL_1_TGL_EN;
> - if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NHSYNC)
> reg |= TBG_CNTRL_1_H_TGL;
> - if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NVSYNC)
> reg |= TBG_CNTRL_1_V_TGL;
> reg_write(priv, REG_TBG_CNTRL_1, reg);
>
> @@ -949,11 +950,10 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> reg_write(priv, REG_ENC_CNTRL, ENC_CNTRL_CTL_CODE(1));
> reg_set(priv, REG_TX33, TX33_HDMI);
>
> - tda998x_write_avi(priv, adjusted_mode);
> + tda998x_write_avi(priv, adj_mode);
>
> if (priv->params.audio_cfg)
> - tda998x_configure_audio(priv, adjusted_mode,
> - &priv->params);
> + tda998x_configure_audio(priv, adj_mode, &priv->params);
> }
> }
>
> --
> 1.8.5.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] ARM: dts: mxs: Fix the RTC compatible prop on M28EVK
From: Marek Vasut @ 2014-01-23 23:23 UTC (permalink / raw)
To: linux-arm-kernel
The compatible property should be m41t62, not mt41t62, so fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/boot/dts/imx28-m28evk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 8536b0d..f0ad7b9 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -194,7 +194,7 @@
};
rtc: rtc at 68 {
- compatible = "stm,mt41t62";
+ compatible = "stm,m41t62";
reg = <0x68>;
};
};
--
1.8.5.2
^ permalink raw reply related
* [PATCH v2 3/3] irqchip: orion: clear stale interrupts in irq_startup
From: Sebastian Hesselbarth @ 2014-01-23 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390516686-2224-4-git-send-email-sebastian.hesselbarth@gmail.com>
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_startup callback to ensure stale
irqs are cleared before initial unmask.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- use .irq_startup instead of .irq_enable (Reported by Jason Gunthorpe)
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
drivers/irqchip/irq-orion.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index 1f636f719065..0dfdc5c824a1 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -123,6 +123,19 @@ static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
}
}
+/*
+ * Bridge IRQ_CAUSE is asserted regardless of IRQ_MASK register.
+ * To avoid interrupt events on stale irqs, we clear them before unmask.
+ */
+static unsigned int orion_bridge_irq_startup(struct irq_data *d)
+{
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
+ ct->chip.irq_ack(d);
+ ct->chip.irq_unmask(d);
+ return 0;
+}
+
static int __init orion_bridge_irq_init(struct device_node *np,
struct device_node *parent)
{
@@ -176,6 +189,7 @@ static int __init orion_bridge_irq_init(struct device_node *np,
gc->chip_types[0].regs.ack = ORION_BRIDGE_IRQ_CAUSE;
gc->chip_types[0].regs.mask = ORION_BRIDGE_IRQ_MASK;
+ gc->chip_types[0].chip.irq_startup = orion_bridge_irq_startup;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_clr_bit;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 3/3] irqchip: orion: clear stale interrupts in irq_enable
From: Sebastian Hesselbarth @ 2014-01-23 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123225208.GA24778@obsidianresearch.com>
On 01/23/2014 11:52 PM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
>> Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
>> IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
>> them before unmask. This installs an .irq_enable callback to ensure stale
>> irqs are cleared before initial unmask.
>
> I'm not sure if putting this in irq_enable is correct. I think this
> should only happen at irq_startup.
>
> The question boils down to what is supposed to happen with this code
> sequence:
>
> disable_irq(..);
> write(.. something to cause an interrupt edge ..);
> .. synchronize ..
> enable_irq(..);
>
> Do we get the interrupt or not?
Jason,
I get the point and actually I'd chosen .irq_enable because using
.irq_startup didn't work. I rechecked this and now it works.. maybe
it is getting too late for me. I'll send a v2 of this patch shortly.
Sebastian
> I found this message from Linus long ago:
> http://yarchive.net/comp/linux/edge_triggered_interrupts.html
>> Btw, the "disable_irq()/enable_irq()" subsystem has been written so that
>> when you disable an edge-triggered interrupt, and the edge happens while
>> the interrupt is disabled, we will re-play the interrupt at enable time.
>> Exactly so that drivers can have an easier time and don't have to
>> normally worry about whether something is edge or level-triggered.
>
> And found this note in Documentation/DocBook/genericirq.tmpl:
>
>> This prevents losing edge interrupts on hardware which does
>> not store an edge interrupt event while the interrupt is disabled at
>> the hardware level.
>
> So I think it is very clear that the chip driver should not discard
> edges that happened while the interrupt was disabled.
>
> Regards,
> Jason
>
^ permalink raw reply
* [PATCH v5 7/8] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Marc C @ 2014-01-23 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGVrzcauDKeNM-Tqxt67Km6r6sjqvwe9_ki_GLc9_ZiXOauN8Q@mail.gmail.com>
Hi Florian,
>> Patch #8 [1] of this series has the "compatible" string set exactly that way. I was
>> following the pattern seen in the other reference DTS files, where "arm,cortex-a15-gic" is
>> used as the fall-back.
>
> Ah, I missed that, thanks! How about the CPU compatible property?
> AFAIK it is only used by arch/arm/kernel/topology.c, I am not sure if
> we have the exact same number to use as the "vanilla" Cortex-A15 here,
> or if we should have another number match against "brcm,brahma-b15".
> What do you think?
I think we should let the code fall-through to use the "SCHED_POWER_SCALE" defaults for
now, and not have an entry in the efficiency table. There are currently no BCM7xxx
platforms architected with heterogeneous multi-processing or multiple disparate CPU
clusters (like big.LITTLE).
Thanks,
Marc
On 01/23/2014 10:26 AM, Florian Fainelli wrote:
> Hi Marc,
>
> 2014/1/22 Marc C <marc.ceeeee@gmail.com>:
>> Hi Florian,
>>
>>> Do not we also need to update drivers/irqchip/irq-gic.c to look for
>>> this compatible property? Alternatively should the example DTS contain
>>> the following:
>>>
>>> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
>>
>> Patch #8 [1] of this series has the "compatible" string set exactly that way. I was
>> following the pattern seen in the other reference DTS files, where "arm,cortex-a15-gic" is
>> used as the fall-back.
>
> Ah, I missed that, thanks! How about the CPU compatible property?
> AFAIK it is only used by arch/arm/kernel/topology.c, I am not sure if
> we have the exact same number to use as the "vanilla" Cortex-A15 here,
> or if we should have another number match against "brcm,brahma-b15".
> What do you think?
>
>>
>> Thanks,
>> Marc C
>>
>> [1] https://lkml.org/lkml/2014/1/21/649
>>
>> On 01/22/2014 02:40 PM, Florian Fainelli wrote:
>>> Hi Marc,
>>>
>>> 2014/1/21 Marc Carino <marc.ceeeee@gmail.com>:
>>>> Document the Broadcom Brahma B15 GIC implementation as compatible
>>>> with the ARM GIC standard.
>>>>
>>>> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
>>>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>>>
>>> Do not we also need to update drivers/irqchip/irq-gic.c to look for
>>> this compatible property? Alternatively should the example DTS contain
>>> the following:
>>>
>>> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
>>>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/gic.txt | 1 +
>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>>> index 3dfb0c0..d7409fd 100644
>>>> --- a/Documentation/devicetree/bindings/arm/gic.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>>> @@ -15,6 +15,7 @@ Main node required properties:
>>>> "arm,cortex-a9-gic"
>>>> "arm,cortex-a7-gic"
>>>> "arm,arm11mp-gic"
>>>> + "brcm,brahma-b15-gic"
>>>> - interrupt-controller : Identifies the node as an interrupt controller
>>>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>>> interrupt source. The type shall be a <u32> and the value shall be 3.
>>>> --
>>>> 1.7.1
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
^ permalink raw reply
* [PATCH 3/3] irqchip: orion: clear stale interrupts in irq_enable
From: Jason Gunthorpe @ 2014-01-23 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390516686-2224-4-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
> Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
> IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
> them before unmask. This installs an .irq_enable callback to ensure stale
> irqs are cleared before initial unmask.
I'm not sure if putting this in irq_enable is correct. I think this
should only happen at irq_startup.
The question boils down to what is supposed to happen with this code
sequence:
disable_irq(..);
write(.. something to cause an interrupt edge ..);
.. synchronize ..
enable_irq(..);
Do we get the interrupt or not?
I found this message from Linus long ago:
http://yarchive.net/comp/linux/edge_triggered_interrupts.html
> Btw, the "disable_irq()/enable_irq()" subsystem has been written so that
> when you disable an edge-triggered interrupt, and the edge happens while
> the interrupt is disabled, we will re-play the interrupt at enable time.
> Exactly so that drivers can have an easier time and don't have to
> normally worry about whether something is edge or level-triggered.
And found this note in Documentation/DocBook/genericirq.tmpl:
> This prevents losing edge interrupts on hardware which does
> not store an edge interrupt event while the interrupt is disabled at
> the hardware level.
So I think it is very clear that the chip driver should not discard
edges that happened while the interrupt was disabled.
Regards,
Jason
^ permalink raw reply
* [PATCH v2 1/2] dmaengine: add Qualcomm BAM dma driver
From: Andy Gross @ 2014-01-23 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9038342A-D629-479C-819B-EF5F4DB52B50@codeaurora.org>
On Thu, Jan 23, 2014 at 02:17:19PM -0600, Kumar Gala wrote:
[....]
> >
> >
> > Thanks for the clarification. I think I'll probably do:
> > ARCH_MSM_DT || (COMPILE_TEST && ARM)
>
> Didn?t you need it to be:
>
> ARCH_MSM_DT || (COMPILE_TEST && OF && ARM)
>
> - k
Yes. That's the version I am going with. I might be able to get away without the
OF if it compiles fine without it, provided it stubs out the OF stuff if the
config option is not present.
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v4 00/18] Armada 370/XP watchdog support
From: Sebastian Hesselbarth @ 2014-01-23 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390431915-5115-1-git-send-email-ezequiel.garcia@free-electrons.com>
On 01/23/2014 12:04 AM, Ezequiel Garcia wrote:
> After some lengthy discussion on the [v2] and [v3] patchsets, here's a new
> round. I hope I haven't forgotten anything.
>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
on Dove.
^ permalink raw reply
* [PATCH 3/3] irqchip: orion: clear stale interrupts in irq_enable
From: Sebastian Hesselbarth @ 2014-01-23 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390516686-2224-1-git-send-email-sebastian.hesselbarth@gmail.com>
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_enable callback to ensure stale
irqs are cleared before initial unmask.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
drivers/irqchip/irq-orion.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index 1f636f719065..80b13c1a0947 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -123,6 +123,18 @@ static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
}
}
+/*
+ * Bridge IRQ_CAUSE is asserted regardless of IRQ_MASK register.
+ * To avoid interrupt events on stale irqs, we clear them before unmask.
+ */
+static void orion_bridge_irq_enable(struct irq_data *d)
+{
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
+ ct->chip.irq_ack(d);
+ ct->chip.irq_unmask(d);
+}
+
static int __init orion_bridge_irq_init(struct device_node *np,
struct device_node *parent)
{
@@ -176,6 +188,7 @@ static int __init orion_bridge_irq_init(struct device_node *np,
gc->chip_types[0].regs.ack = ORION_BRIDGE_IRQ_CAUSE;
gc->chip_types[0].regs.mask = ORION_BRIDGE_IRQ_MASK;
+ gc->chip_types[0].chip.irq_enable = orion_bridge_irq_enable;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_clr_bit;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/3] irqchip: orion: use handle_edge_irq on bridge irqs
From: Sebastian Hesselbarth @ 2014-01-23 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390516686-2224-1-git-send-email-sebastian.hesselbarth@gmail.com>
Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high
transitions and not on the level of the downstream interrupt line.
This replaces handle_level_irq by the more appropriate handle_edge_irq.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
drivers/irqchip/irq-orion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index 4137c3d15284..1f636f719065 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -143,7 +143,7 @@ static int __init orion_bridge_irq_init(struct device_node *np,
}
ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
- handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
+ handle_edge_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
if (ret) {
pr_err("%s: unable to alloc irq domain gc\n", np->name);
return ret;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/3] irqchip: orion: clear bridge cause register on init
From: Sebastian Hesselbarth @ 2014-01-23 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390516686-2224-1-git-send-email-sebastian.hesselbarth@gmail.com>
It is good practice to mask and clear pending irqs on init. We already
mask all irqs, so also clear the bridge irq cause register.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
drivers/irqchip/irq-orion.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index e51d40031884..4137c3d15284 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -180,8 +180,9 @@ static int __init orion_bridge_irq_init(struct device_node *np,
gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
- /* mask all interrupts */
+ /* mask and clear all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
+ writel(0, gc->reg_base + ORION_BRIDGE_IRQ_CAUSE);
irq_set_handler_data(irq, domain);
irq_set_chained_handler(irq, orion_bridge_irq_handler);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 0/3] irqchip: orion: bridge irq fixes for v3.14-rc1
From: Sebastian Hesselbarth @ 2014-01-23 22:38 UTC (permalink / raw)
To: linux-arm-kernel
This is a small patch set to fix some shortcomings how Orion bridge
irqs are handled. The patches are based on v3.13-rc8 and should go
into v3.14. They can possibly also marked for -stable down to v3.10.
This patches are the result of a discussion about a stale watchdog irq,
that can accidentially trigger the watchdog's irq handler and cause a
reset [1].
The first patch will add a write to clear already pending interrupts
on init. The second patch replaces handle_level_irq with handle_edge_irq
which is more appropriate for bridge irqs which are edge-triggered.
The last patch finally, fixes stale interrupts by installing an
.irq_enable callback, that will clear a possible pending interrupt
before unmasking it.
[1] http://www.spinics.net/lists/arm-kernel/msg302106.html
Sebastian Hesselbarth (3):
irqchip: orion: clear bridge cause register on init
irqchip: orion: use handle_edge_irq on bridge irqs
irqchip: orion: clear stale interrupts in irq_enable
drivers/irqchip/irq-orion.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
---
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
--
1.8.5.2
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Tomasz Figa @ 2014-01-23 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3955130.WSqWacB8SI@phil>
On 23.01.2014 20:02, Heiko St?bner wrote:
> Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
>> On 23.01.2014 19:36, Heiko St?bner wrote:
>>> Am Donnerstag, 23. Januar 2014, 19:12:04 schrieb Tomasz Figa:
>>>> Hi Heiko,
>>>>
>>>> On 06.01.2014 19:40, Heiko St?bner wrote:
>>>>> This converts all boards to use the new common restart function instead
>>>>> of SoC specific ones.
>>>>>
>>>>> The mach-s3c2416-dt board now tries to setup either a swrst- or
>>>>> watchdog-
>>>>> reset so that it will be able to handle more s3c24xx-SoCs later on.
>>>>
>>>> [snip]
>>>>
>>>>> diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>>>> b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c index 0a86953..88716fa4 100644
>>>>> --- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>>>> +++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>>>> @@ -24,6 +24,7 @@
>>>>>
>>>>> #include <plat/cpu.h>
>>>>> #include <plat/pm.h>
>>>>>
>>>>> +#include <plat/watchdog-reset.h>
>>>>>
>>>>> #include "common.h"
>>>>>
>>>>> @@ -34,6 +35,14 @@ static void __init s3c2416_dt_map_io(void)
>>>>>
>>>>> static void __init s3c2416_dt_machine_init(void)
>>>>> {
>>>>>
>>>>> + s3c24xx_swrst_reset_of_init();
>>>>> +
>>>>> +#ifdef CONFIG_SAMSUNG_WDT_RESET
>>>>> + /* if no special swrst-device exists try to find a watchdog */
>>>>> + if (!s3c24xx_swrst_reset_available())
>>>>> + samsung_wdt_reset_of_init();
>>>>> +#endif
>>>>
>>>> Hmm... I think it would be safe to assume availability of soft reset,
>>>> especially if you could move the restart code to the clock driver.
>>>
>>> ok, so something like the following:
>>>
>>> the boards would simply use samsung_watchdog_reset, which should according
>>> to the manuals be available on all architectures. And the ccf-driver on
>>> appropriate architectures would simple replace the arm_pm_restart
>>> callback with its own SoC specific one?
>>>
>>> For the s3c2412 this also means that the clock-logic would get simplified.
>>>
>>>
>>> Like this, or do I overlook something?
>>
>> Hmm, this would mean a dependency on CONFIG_SAMSUNG_WDT_RESET then. Is
>> there a need to fall back to it on platforms which support soft reset
>> (assuming that CCF driver would always install its restart handler on
>> applicable platforms)?
>
> s3c2410, s3c2440 and s3c2442 do not have the swrst facility. They always use
> samsung_wdt_reset.
>
> In general, I want to try establishing some sort of general restart way, as in
> the future one dt-board should hopefully be enough to cover all s3c24xx soc
> variants.
If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
it's fine.
>
>
>> Note that you can make the restart field NULL in mach_desc in board files.
>
> As I said above, this is mainly meant for the dt-case. The legacy-board files
> are more or less only secondary, and the affected boards can of course then
> have a NULL restart handle :-) .
>
> So for this the dt-board could simply use the wdt-reset, which then gets
> replaced by the ccf-based reset if appropriate.
OK. By the way, are there any benefits of using this software reset over
watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
special handling of those with swrst would be needed.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 0/2] Enable clock controllers on MSM
From: Olof Johansson @ 2014-01-23 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69BE1300-36E8-400B-BD77-DB89740C10D2@codeaurora.org>
On Thu, Jan 23, 2014 at 1:57 PM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Jan 23, 2014, at 2:43 PM, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala <galak@codeaurora.org> wrote:
>>>
>>> On Jan 23, 2014, at 11:25 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>
>>>> Stephen Boyd <sboyd@codeaurora.org> writes:
>>>>
>>>>> These patches add the clock controller nodes, enable the clock drivers
>>>>> on MSM based platforms, and hook it up enough to get the serial console
>>>>> working. This is based on the merge of Mike's clk-next branch with
>>>>> linux-next-20140116. The changes need the clk-next branch because that's
>>>>> where the DTS include files landed.
>>>>
>>>> I forgot to repond to this earlier, but I tested this on top of -next
>>>> and it gets the dragonboard booting w/mainline. Yay!
>>>>
>>>>> Perhaps this can be applied after 3.14-rc1 is out?
>>>>
>>>> Yeah, sounds good.
>>>>
>>>> Kevin
>>>
>>> We?ll need arm-soc to pull in the clk changes from Mike?s tree for that.
>>
>> They're queued for this merge window, right? If so, they'll be in -rc1
>> and the dependency will be solved before we apply the patches.
>>
>
> Yeah, they look like they are in Mike?s pull request for Linus. So hopefully they?ll show up in -rc1 (wasn?t sure if Mike intended them for 3.14 or not).
>
> What?s the feeling about pushing DT and defconfig changes into 3.14 (or do we just queue them up for 3.15)?
I can probably pick them up in a late/* branch and merge for 3.14, no
promises though.
-Olof
^ 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