* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Shawn Guo @ 2016-10-23 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475371719-28736-1-git-send-email-andrew.smirnov@gmail.com>
On Sat, Oct 01, 2016 at 06:28:39PM -0700, Andrey Smirnov wrote:
> I2C3 bus was only brought out in revision A1 of the board and revision
> B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Applied, thanks.
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Russell King - ARM Linux @ 2016-10-23 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <315017958.66634.5d4fc19c-31cd-4900-8613-af4cadec5da4.open-xchange@email.1und1.de>
On Sun, Oct 23, 2016 at 11:19:26AM +0200, Stefan Wahren wrote:
> Hi,
>
> i'm faced with the issue that on i.MX28 the console is unable to wake up from
> freeze ( suspend to idle). I tested it with Linux 4.9-rc1, 4.8 and 3.18 (
> cmdline has
> no_console_suspend=1 ) and also with a i.MX23 with the same result. The suspend
> seems to work, but there is no reaction to the console after the freeze except
> an hung task warning after some time:
I bet if you remove "no_console_suspend" (it's not =1) then it'll work.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Marek Vasut @ 2016-10-23 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023130143.GT30578@tiger>
On 10/23/2016 03:01 PM, Shawn Guo wrote:
> On Mon, Sep 19, 2016 at 11:40:41PM +0200, Marek Vasut wrote:
>> The board is now manufactured by Aries Embedded GmbH, update compat string.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> ---
>> arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
>> arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
>> index 214bb15..a69856e 100644
>> --- a/arch/arm/boot/dts/imx28-m28.dtsi
>> +++ b/arch/arm/boot/dts/imx28-m28.dtsi
>> @@ -12,8 +12,8 @@
>> #include "imx28.dtsi"
>>
>> / {
>> - model = "DENX M28";
>> - compatible = "denx,m28", "fsl,imx28";
>> + model = "Aries/DENX M28";
>> + compatible = "aries,m28", "denx,m28", "fsl,imx28";
>
> Do we have an entry for Aries Embedded GmbH in vendor-prefixes.txt?
The patch was submitted, not yet applied though:
http://www.spinics.net/lists/arm-kernel/msg533000.html
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Shawn Guo @ 2016-10-23 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
On Mon, Sep 19, 2016 at 11:40:41PM +0200, Marek Vasut wrote:
> The board is now manufactured by Aries Embedded GmbH, update compat string.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
> arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
> index 214bb15..a69856e 100644
> --- a/arch/arm/boot/dts/imx28-m28.dtsi
> +++ b/arch/arm/boot/dts/imx28-m28.dtsi
> @@ -12,8 +12,8 @@
> #include "imx28.dtsi"
>
> / {
> - model = "DENX M28";
> - compatible = "denx,m28", "fsl,imx28";
> + model = "Aries/DENX M28";
> + compatible = "aries,m28", "denx,m28", "fsl,imx28";
Do we have an entry for Aries Embedded GmbH in vendor-prefixes.txt?
Shawn
>
> memory {
> reg = <0x40000000 0x08000000>;
> diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
> index 8d04e57..dbfb8aa 100644
> --- a/arch/arm/boot/dts/imx28-m28evk.dts
> +++ b/arch/arm/boot/dts/imx28-m28evk.dts
> @@ -13,8 +13,8 @@
> #include "imx28-m28.dtsi"
>
> / {
> - model = "DENX M28EVK";
> - compatible = "denx,m28evk", "fsl,imx28";
> + model = "Aries/DENX M28EVK";
> + compatible = "aries,m28evk", "denx,m28evk", "fsl,imx28";
>
> apb at 80000000 {
> apbh at 80000000 {
> --
> 2.9.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1 v8] ARM: imx: Added perf functionality to mmdc driver
From: Shawn Guo @ 2016-10-23 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474307849-7341-1-git-send-email-Frank.Li@nxp.com>
On Mon, Sep 19, 2016 at 12:57:29PM -0500, Frank Li wrote:
> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> MMDC provides registers for performance counters which read via this
> driver to help debug memory throughput and similar issues.
>
> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>
> 898021787 mmdc/busy-cycles/
> 14819600 mmdc/read-accesses/
> 471.30 MB mmdc/read-bytes/
> 2815419216 mmdc/total-cycles/
> 13367354 mmdc/write-accesses/
> 427.76 MB mmdc/write-bytes/
>
> 5.334757334 seconds time elapsed
>
> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
> Signed-off-by: Frank Li <frank.li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Shawn Guo @ 2016-10-23 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
On Mon, Sep 26, 2016 at 03:03:39AM +0300, Vladimir Zapolskiy wrote:
> The change is tested on qemu kzm target and mx31lite board, while both
> targets don't have DTS in upstream, I had to write simple DTS files for
> them, because the proposed change is for i.MX31 targets with OF support.
>
> i.MX31/OF/clock initialization seems to be broken currently, if
> the series is not applied I can not get a working clock source during
> early boot stage on a board with DTB supplied.
>
> Changes from v1 to v2, thanks to Uwe and Stephen for review:
> * added one more new fix in imx31.dtsi which moves CCM device node
> to AIPS2 bus,
> * included to the series a fix of CCM interrupts in imx31.dtsi,
> the change was sent as a separate patch, the change is included
> to avoid a patch application dependency,
> * as suggested by Uwe reworded one of the commits removing "stack
> corruption" mentioning, the overwritten value is passed in a register,
> * as suggested by Uwe squashed clk-imx31.c and imx31-dt.c changes
> to avoid a runtime problem if only one of two patches are applied
>
> Vladimir Zapolskiy (4):
> ARM: dts: imx31: fix clock control module interrupts description
> ARM: dts: imx31: move CCM device node to AIPS2 bus devices
> clk: imx31: fix rewritten input argument of mx31_clocks_init()
> ARM: clk: imx31: properly init clocks for machines with DT
>
> .../devicetree/bindings/clock/imx31-clock.txt | 2 +-
> arch/arm/boot/dts/imx31.dtsi | 14 +++---
> arch/arm/mach-imx/common.h | 1 -
> arch/arm/mach-imx/imx31-dt.c | 6 ---
> drivers/clk/imx/clk-imx31.c | 52 +++++++++++-----------
Hi Stephen,
Can I have you ACK on the clk file, so that we can merge the series from
arm-soc tree? Thanks.
Shawn
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: imx6qdl cleanups
From: Shawn Guo @ 2016-10-23 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437970-15800-1-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 03:09:27PM +0530, Jagan Teki wrote:
> Patchset for imx6qdl devicetree files cleanups.
>
> Jagan Teki (3):
> arm: dts: imx6qdl: Fix "WARNING: please, no space before tabs"
> arm: dts: imx6qdl: Fix "ERROR: code indent should use tabs where
> possible"
> arm: dts: imx6qdl-wandboard-revb: Fix "ERROR: trailing whitespace"
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx: b650v3: Calibrate USB PHY to pass eye diagram test
From: Shawn Guo @ 2016-10-23 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473887689-10792-1-git-send-email-jaret.cantu@timesys.com>
On Wed, Sep 14, 2016 at 05:14:49PM -0400, Jaret Cantu wrote:
> Calibrate the USB PHY TX settings to pass the eye diagram signal
> integrity test. The settings are taken from the i.MX6 reference
> manual's recommended configuration for USB certification (66.2.6).
>
> Signed-off-by: Jaret Cantu <jaret.cantu@timesys.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v4 01/10] ethernet: add sun8i-emac driver
From: Rami Rosen @ 2016-10-23 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-2-git-send-email-clabbe.montjoie@gmail.com>
Hi Corentin,
Trivial comment: rx_saf_fai and rx_daf_fail are not used. This implies that also
rx_saf_error and rx_daf_error should be removed:
> +static const char const estats_str[][ETH_GSTRING_LEN] = {
...
> + "rx_header_error",
> + "rx_overflow_error",
> + "rx_saf_error",
> + "rx_daf_error",
> + "rx_buf_error",
...
> +
> +struct sun8i_emac_stats {
> + u64 rx_payload_error;
...
> + u64 rx_overflow_error;
> + u64 rx_saf_fail;
> + u64 rx_daf_fail;
> + u64 tx_used_desc;
> + u64 napi_schedule;
> + u64 napi_underflow;
> +};
> +
Trivial: typo, should be: can transfer
> +/* The datasheet said that each descriptor can transfers up to 4096bytes
> + * But latter, a register documentation reduce that value to 2048
Regards,
Rami Rosen
^ permalink raw reply
* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Shawn Guo @ 2016-10-23 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962ea92f-870b-e1d0-5bb7-1a6d66c35122@huawei.com>
On Sun, Oct 23, 2016 at 11:21:10AM +0800, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index ef5fbe9..26bc837 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -31,6 +31,12 @@ to deliver its interrupts via SPIs.
> This also affects writes to the tval register, due to the implicit
> counter read.
>
> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
> + QorIQ erratum 161201, which says that reading the counter is
QorIQ is a Freescale/NXP specific name, and shouldn't be there.
Shawn
> + unreliable unless the small range of value is returned by back-to-back reads.
> + This also affects writes to the tval register, due to the implicit
> + counter read.
> +
> ** Optional properties:
>
> - arm,cpu-registers-not-fw-configured : Firmware does not initialize
> --
> 1.9.0
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] ARM: mediatek: add terminate entry for of_device_id tables
From: Wei Yongjun @ 2016-10-23 11:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Make sure of_device_id tables are NULL terminated.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
arch/arm/mach-mediatek/platsmp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-mediatek/platsmp.c b/arch/arm/mach-mediatek/platsmp.c
index b821e34..e6cffc7 100644
--- a/arch/arm/mach-mediatek/platsmp.c
+++ b/arch/arm/mach-mediatek/platsmp.c
@@ -54,11 +54,13 @@ static const struct of_device_id mtk_tz_smp_boot_infos[] __initconst = {
{ .compatible = "mediatek,mt8135", .data = &mtk_mt8135_tz_boot },
{ .compatible = "mediatek,mt8127", .data = &mtk_mt8135_tz_boot },
{ .compatible = "mediatek,mt2701", .data = &mtk_mt8135_tz_boot },
+ { },
};
static const struct of_device_id mtk_smp_boot_infos[] __initconst = {
{ .compatible = "mediatek,mt6589", .data = &mtk_mt6589_boot },
{ .compatible = "mediatek,mt7623", .data = &mtk_mt7623_boot },
+ { },
};
static void __iomem *mtk_smp_base;
^ permalink raw reply related
* [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2016-10-23 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476812509-2760-2-git-send-email-agustinv@codeaurora.org>
On 2016/10/19 1:41, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
[...]
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + ret = acpi_irq_domain_ensure_probed(device);
> + if (ret)
> + goto out_put_device;
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
I think Marc already raised this before, which irqdomain.c is similar to
gsi.c in drivers/acpi/, I prepared another approach [1] which avoid this,
I'm open for comments.
I think it's pretty important to finalize the directions we are going,
then avoid the duplicate work and speedup for upstream, Marc, Rafael,
Lorenzo, could you give us suggestions for this?
Thanks
Hanjun
[1]: https://patchwork.kernel.org/patch/9331771/
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-10-23 9:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
i'm faced with the issue that on i.MX28 the console is unable to wake up from
freeze ( suspend to idle). I tested it with Linux 4.9-rc1, 4.8 and 3.18 (
cmdline has
no_console_suspend=1 ) and also with a i.MX23 with the same result. The suspend
seems to work, but there is no reaction to the console after the freeze except
an hung task warning after some time:
echo freeze > /sys/power/state
Strangely the suspend to RAM from console works without any issues:
echo mem > /sys/power/state
Any ideas what could be the problem?
Here is the console output:
root at duckbill:~# echo mem > /sys/power/state
[ 44.881170] PM: Syncing filesystems ... [ 49.726565] done.
[ 49.787188] Freezing user space processes ... (elapsed 0.008 seconds) done.
[ 49.803455] Freezing remaining freezable tasks ... (elapsed 0.004 seconds)
done.
[ 50.553231] PM: suspend of devices complete after 731.338 msecs
[ 50.566850] PM: late suspend of devices complete after 7.436 msecs
[ 50.581416] PM: noirq suspend of devices complete after 8.124 msecs
[ 50.598957] PM: noirq resume of devices complete after 10.888 msecs
[ 50.615757] PM: early resume of devices complete after 7.115 msecs
[ 50.641481] Suspended for 1.283 seconds
[ 50.646424] PM: resume of devices complete after 24.225 msecs
[ 50.660304] Restarting tasks ... [ 50.706421] done.
root at duckbill:~# echo freeze > /sys/power/state
[ 64.701251] PM: Syncing filesystems ... [ 65.992083] done.
[ 66.014271] Freezing user space processes ... (elapsed 0.004 seconds) done.
[ 66.026151] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
done.
[ 66.204858] PM: suspend of devices complete after 163.009 msecs
[ 66.218808] PM: late suspend of devices complete after 7.762 msecs
[ 66.232985] PM: noirq suspend of devices complete after 7.887 msecs
[ 192.228595] random: crng init done
[ 243.817366] INFO: task ext4lazyinit:69 blocked for more than 120 seconds.
[ 243.824216] Not tainted 4.9.0-rc1 #1
[ 243.828482] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 243.836359] ext4lazyinit D c05a9fdc 0 69 2 0x00000000
[ 243.843028] [<c05a9fdc>] (__schedule) from [<c05aa8e8>] (schedule+0x3c/0xbc)
[ 243.850292] [<c05aa8e8>] (schedule) from [<c05ae768>]
(schedule_timeout+0x23c/0x3d8)
[ 243.858247] [<c05ae768>] (schedule_timeout) from [<c05a9cc8>]
(io_schedule_timeout+0xb8/0x13c)
[ 243.866934] [<c05a9cc8>] (io_schedule_timeout) from [<c05ab308>]
(T.1434+0xac/0x12c)
[ 243.874884] [<c05ab308>] (T.1434) from [<c02c7304>]
(submit_bio_wait+0x50/0x68)
[ 243.882419] [<c02c7304>] (submit_bio_wait) from [<c02d96f4>]
(blkdev_issue_zeroout+0x174/0x1ec)
[ 243.891323] [<c02d96f4>] (blkdev_issue_zeroout) from [<c0196ae8>]
(ext4_init_inode_table+0x1ac/0x3b0)
[ 243.900753] [<c0196ae8>] (ext4_init_inode_table) from [<c01ba40c>]
(ext4_lazyinit_thread+0x280/0x398)
[ 243.910177] [<c01ba40c>] (ext4_lazyinit_thread) from [<c003bce4>]
(kthread+0xc4/0xe0)
[ 243.918213] [<c003bce4>] (kthread) from [<c000a34c>]
(ret_from_fork+0x14/0x28)
[ 243.925479]
[ 243.925479] Showing all locks held in the system:
[ 243.931849] 2 locks held by khungtaskd/10:
[ 243.935987] #0: [ 243.937869] (
rcu_read_lock[ 243.940746] ){......}
, at: [ 243.943624] [<c00936ac>] watchdog+0xb4/0x61c
[ 243.948054] #1: [ 243.949843] (
tasklist_lock[ 243.952700] ){.+.+..}
, at: [ 243.955576] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 243.961074] 4 locks held by ext4lazyinit/69:
[ 243.965380] #0: [ 243.967273] (
&type->s_umount_key[ 243.970673] #22
){++++++}[ 243.973257] , at:
[ 243.975320] [<c01ba260>] ext4_lazyinit_thread+0xd4/0x398
[ 243.980776] #1: [ 243.982566] (
sb_writers[ 243.985167] #3
){.+.+.+}[ 243.987778] , at:
[ 243.989861] [<c01ba278>] ext4_lazyinit_thread+0xec/0x398
[ 243.995201] #2: [ 243.996973] (
jbd2_handle[ 243.999903] ){++++..}
, at: [ 244.002796] [<c01f62b8>] start_this_handle+0xec/0x404
[ 244.008014] #3: [ 244.009805] (
&meta_group_info[i]->alloc_sem[ 244.014141] ){++++..}
, at: [ 244.017138] [<c01969f4>] ext4_init_inode_table+0xb8/0x3b0
[ 244.022619] 4 locks held by bash/386:
[ 244.026306] #0: [ 244.028204] (
sb_writers[ 244.030825] #4
){.+.+.+}[ 244.033326] , at:
[ 244.035390] [<c011f470>] vfs_write+0x194/0x1a4
[ 244.039985] #1: [ 244.041772] (
&of->mutex[ 244.044374] ){+.+.+.}
, at: [ 244.047366] [<c018ff38>] kernfs_fop_write+0xc0/0x1d0
[ 244.052381] #2: [ 244.054154] (
s_active[ 244.056571] #44
){.+.+.+}[ 244.059289] , at:
[ 244.061364] [<c018ff40>] kernfs_fop_write+0xc8/0x1d0
[ 244.066354] #3: [ 244.068247] (
pm_mutex[ 244.070690] ){+.+.+.}
, at: [ 244.073576] [<c005b520>] pm_suspend+0x98/0x784
[ 244.078179]
[ 244.079713] =============================================
[ 244.079713]
[ 244.086660] INFO: task bash:386 blocked for more than 120 seconds.
[ 244.092998] Not tainted 4.9.0-rc1 #1
[ 244.097233] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.105109] bash D c05a9fdc 0 386 289 0x00000000
[ 244.111762] [<c05a9fdc>] (__schedule) from [<c05aa8e8>] (schedule+0x3c/0xbc)
[ 244.119028] [<c05aa8e8>] (schedule) from [<c005aee4>]
(suspend_devices_and_enter+0x480/0xa24)
[ 244.127771] [<c005aee4>] (suspend_devices_and_enter) from [<c005b8a8>]
(pm_suspend+0x420/0x784)
[ 244.136551] [<c005b8a8>] (pm_suspend) from [<c0059dd8>]
(state_store+0x80/0xcc)
[ 244.144075] [<c0059dd8>] (state_store) from [<c02efed0>]
(kobj_attr_store+0x18/0x1c)
[ 244.152030] [<c02efed0>] (kobj_attr_store) from [<c0190e54>]
(sysfs_kf_write+0x48/0x4c)
[ 244.160217] [<c0190e54>] (sysfs_kf_write) from [<c018ff74>]
(kernfs_fop_write+0xfc/0x1d0)
[ 244.168600] [<c018ff74>] (kernfs_fop_write) from [<c011f1e4>]
(__vfs_write+0x2c/0x124)
[ 244.176591] [<c011f1e4>] (__vfs_write) from [<c011f390>]
(vfs_write+0xb4/0x1a4)
[ 244.184093] [<c011f390>] (vfs_write) from [<c011f554>] (SyS_write+0x44/0x88)
[ 244.191326] [<c011f554>] (SyS_write) from [<c000a2c0>]
(ret_fast_syscall+0x0/0x1c)
[ 244.199057]
[ 244.199057] Showing all locks held in the system:
[ 244.205321] 2 locks held by khungtaskd/10:
[ 244.209569] #0: [ 244.211361] (
rcu_read_lock[ 244.214221] ){......}
, at: [ 244.217216] [<c00936ac>] watchdog+0xb4/0x61c
[ 244.221536] #1: [ 244.223308] (
tasklist_lock[ 244.226157] ){.+.+..}
, at: [ 244.229244] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 244.234628] 4 locks held by ext4lazyinit/69:
[ 244.239047] #0: [ 244.240835] (
&type->s_umount_key[ 244.244214] #22
){++++++}[ 244.246796] , at:
[ 244.248987] [<c01ba260>] ext4_lazyinit_thread+0xd4/0x398
[ 244.254340] #1: [ 244.256116] (
sb_writers[ 244.258845] #3
){.+.+.+}[ 244.261355] , at:
[ 244.263417] [<c01ba278>] ext4_lazyinit_thread+0xec/0x398
[ 244.268876] #2: [ 244.270667] (
jbd2_handle[ 244.273350] ){++++..}
, at: [ 244.276230] [<c01f62b8>] start_this_handle+0xec/0x404
[ 244.281439] #3: [ 244.283228] (
&meta_group_info[i]->alloc_sem[ 244.287682] ){++++..}
, at: [ 244.290589] [<c01969f4>] ext4_init_inode_table+0xb8/0x3b0
[ 244.296045] 4 locks held by bash/386:
[ 244.299857] #0: [ 244.301644] (
sb_writers[ 244.304241] #4
){.+.+.+}[ 244.306738] , at:
[ 244.308925] [<c011f470>] vfs_write+0x194/0x1a4
[ 244.313408] #1: [ 244.315183] (
&of->mutex[ 244.317895] ){+.+.+.}
, at: [ 244.320792] [<c018ff38>] kernfs_fop_write+0xc0/0x1d0
[ 244.325791] #2: [ 244.327679] (
s_active[ 244.330126] #44
){.+.+.+}[ 244.332713] , at:
[ 244.334771] [<c018ff40>] kernfs_fop_write+0xc8/0x1d0
[ 244.339881] #3: [ 244.341668] (
pm_mutex[ 244.344087] ){+.+.+.}
, at: [ 244.346963] [<c005b520>] pm_suspend+0x98/0x784
[ 244.351579]
[ 244.353102] =============================================
[ 244.353102]
^ permalink raw reply
* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Hanjun Guo @ 2016-10-23 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1941586c-4c51-60d8-a77a-ad56fe5f3e3f@codeaurora.org>
Hi Harb,
On 2016/10/20 0:59, Abdulhamid, Harb wrote:
> On 10/18/2016 8:44 AM, Hanjun Guo wrote:
>> Hi Tyler,
>>
>> On 2016/10/8 5:31, Tyler Baicar wrote:
>>> ARM APEI extension proposal added SEA (Synchrounous External
>>> Abort) notification type for ARMv8.
>>> Add a new GHES error source handling function for SEA. If an error
>>> source's notification type is SEA, then this function can be registered
>>> into the SEA exception handler. That way GHES will parse and report
>>> SEA exceptions when they occur.
>> Does this SEA is replayed by the firmware (firmware first handling)
>> or directly triggered by the hardware when error is happened?
> Architecturally, an SEA must be synchronous and *precise*, so if you
> take an SEA on a particular load instruction, firmware/hardware should
> not be corrupting the context/state of the PE to allow software to
> determine which thread/process encountered the abort. GHES error status
That's my concern too, and that's why I raised my question :)
> block will be expose to software with information about the type,
> severity, physical address impacted.
>
> Generally the error status block is populated by firmware. However, as
> long as the above requirement is met, I don't think the spec precludes
> error status block being populated by hardware. Those details must be
> completely transparent to software.
>
> Finally, to answer your more specific question: If the implementation
> of firmware-first involves trapping the SEA in EL3 to do some firmware
> first handling, firmware must maintain the context of the offending ELx,
> generate an error record, and then "replay" the exception to normal
> (non-secure) software at the appropriate vector base address.
>
Thank you for your answer, it clears my confusion now, I will try something
similar on ARM64 platform, will get back to you if I get blocks.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v4 01/10] ethernet: add sun8i-emac driver
From: LABBE Corentin @ 2016-10-23 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475852559.1945.2.camel@perches.com>
On Fri, Oct 07, 2016 at 08:02:39AM -0700, Joe Perches wrote:
> On Fri, 2016-10-07 at 10:25 +0200, Corentin Labbe wrote:
> > This patch add support for sun8i-emac ethernet MAC hardware.
> > It could be found in Allwinner H3/A83T/A64 SoCs.
>
> trivial notes:
>
> > diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c b/drivers/net/ethernet/allwinner/sun8i-emac.c
> []
> > +static const char const estats_str[][ETH_GSTRING_LEN] = {
>
> one too many const
>
> > +/* MAGIC value for knowing if a descriptor is available or not */
> > +#define DCLEAN cpu_to_le32(BIT(16) | BIT(14) | BIT(12) | BIT(10) | BIT(9))
>
> Aren't there #defines for these bits?
>
> > +static void sun8i_emac_flow_ctrl(struct sun8i_emac_priv *priv, int duplex,
> > + int fc)
> > +{
> > + u32 flow = 0;
> > +
> > + flow = readl(priv->base + EMAC_RX_CTL0);
> > + if (fc & EMAC_FLOW_RX)
> > + flow |= BIT(16);
> > + else
> > + flow &= ~BIT(16);
> > + writel(flow, priv->base + EMAC_RX_CTL0);
> > +
> > + flow = readl(priv->base + EMAC_TX_FLOW_CTL);
> > + if (fc & EMAC_FLOW_TX)
> > + flow |= BIT(0);
> > + else
> > + flow &= ~BIT(0);
>
> more magic bits that could be #defines
>
> > +static int sun8i_emac_rx_from_ddesc(struct net_device *ndev, int i)
> > +{
> > []
> > + /* the checksum or length of received frame's payload is wrong*/
> > + if (dstatus & BIT(0)) {
> []
> > + if (dstatus & BIT(1)) {
> []
> > + if ((dstatus & BIT(3))) {
>
> etc...
Thanks for the review, I will fix all thoses issue.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: LABBE Corentin @ 2016-10-23 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020203654.2erph2mr73yzksla@lukather>
On Thu, Oct 20, 2016 at 10:36:54PM +0200, Maxime Ripard wrote:
> On Wed, Oct 19, 2016 at 09:40:16AM +0200, LABBE Corentin wrote:
> > On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> > > On Wed, 5 Oct 2016 11:48:24 +0200
> > > Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> > >
> > > > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > index 9f58bb4..abfd29c 100644
> > > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > @@ -211,6 +211,11 @@
> > > > #size-cells = <0>;
> > > > };
> > > >
> > > > + sid: eeprom at 01c14200 {
> > > > + compatible = "allwinner,sun7i-a20-sid";
> > > > + reg = <0x01c14200 0x200>;
> > >
> > > The datasheet says 1Kb starting at 0x01c14000.
> > > Is there any reason to reduce the area and to shift the offset?
> > >
> >
> > According to http://linux-sunxi.org/SID_Register_Guide "For
> > Allwinner A83T and H3 the SID address space starts at 0x01c14000,
> > and the e-fuses are at offset 0x200".
> >
> > So I use this offset, since the sunxi_sid driver need the base
> > address of e-fuses.
> >
> > The easiest solution is to use 0x01c14200 since the other part of
> > sid is not used and not known (A83T/H3 user manual doesnt give any
> > information on all sid space, worse for A64 which reference SID only
> > in memory map).
> >
> > So probably for H3/A64/A83T, there will never any usage of the rest
> > of the SID address space.
>
> And since we can't know that, and we have to maintain the DT ABI,
> using the whole address map and an offset, with a new compatible, is
> definetely the safest thing to do.
>
I have two way of doing it, which one do you prefer ?
- Adding two optionnal properties: efuses-offset and efuses-size defaulting to 0 and resourcesize.
- Adding a subnode called efuses with its own reg=<>
The first one is easy and didnt need any work on previous DT entries.
Regards
Corentin Labbe
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-10-23 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67gDd650TJk_-oHOehnzdH2qor=36HXdPt339Ji=ToAMg@mail.gmail.com>
On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
>
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.
>
> > - it creates the sound card (with sun4i-i2s, the sound card is created
> > by the CODECs)
>
> I think this is wrong. I2S is only the DAI. You typically have a separate
> platform driver for the whole card, or just use simple-card.
An other device is not needed. The layout is simple:
I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
The HDMI CODEC is supported by the HDMI video driver (only one device),
so, it cannot be the card device.
ASoC does not use the CPU DAI device (I2S_controller), so, it is
natural to use it to handle the card.
Otherwise, the simple-card asks for a node definition in the DT and
this node is a pure Linux software entity. On the other side, the
simple-graph-card from Kuninori is not useful for this simple case.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video
From: Jean-Francois Moine @ 2016-10-23 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64fgJShfyEHnjm6ryg00WhHkmnPj+FdjHcXBa6HQbyTuA@mail.gmail.com>
On Sun, 23 Oct 2016 09:38:04 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> > Recently, an announce about Tina OS for the R series
> > https://www.youtube.com/watch?v=h7KD-6HblAU
> > was followed by the upload of a new linux-3.4 source tree
> > https://github.com/tinalinux/linux-3.4
> > with files containing GPL headers.
> >
> > Well, I don't know if these sources are really from Allwinner, but
> > anyway, this is the opportunity to propose a new version of my DRM
> > HDMI driver.
>
> Could you clarify about this bit? Did you just clean up Allwinner's
> existing drivers? Or just use them as reference? Either way I think
> this deserves some mention in all your copyright headers.
>
> Otherwise what difference does the new release make?
- Allwinner's video driver is not DRM.
- their driver has no hardware cursor nor video overlay.
- I wrote the video DRM driver from the document
Allwinner_H3_Datasheet_V1.2.pdf
and the structures defined in
linux-3.4/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_rtmx.h
Reading Allwinner's code helped me to understand how the DE2
is working.
- my lowlevel HDMI is just a cleanup of theirs with explanations
about the registers. Magic constants remain due to the lack of
knowledge about the PHYs.
- the mention of Allwinner in the copyright headers is needed to
indicate the source of the structures (DE2) and code (HDMI).
The main difference is the DRM interface and the use of the EDID,
permitting dynamic video resolution change with xrandr.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* Question about arm64 earlycon
From: Duc Dang @ 2016-10-23 7:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin, Marc, Mark, Arnd,
I am testing with 3.12 kernel with earlyprintk enabled and I see some
garbage characters in the console log right before the message
indicating that the real console device is initialized:
<some garbage characters here>01c020000.serial: ttyS0 at MMIO
0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
console [ttyS0] enabled, bootconsole disabled
I looked through early_prink.c file and printk.c file and it looks
like there is case that some early boot code can touch the UART
hardware via ealy console driver while the 'real' console driver is
setting up the same UART port? Please let me know if I missed some
important piece of code that can prevent this.
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v3 3/6] pwm: imx: support output polarity inversion
From: Lukasz Majewski @ 2016-10-23 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161022140118.7a6cb583@bbrezillon>
Hi Boris,
> >
> > Could you be more specific here?
> >
> > As I mentioned before, the problem is not with the lack of
> > "atomic" API.
>
> Below is a quick and dirty I made on top of this patch to show you how
> atomic update can be implemented in this driver.
Thank you for example patch.
I will implement the ->apply() callback and post patches very soon :-).
I had two issues with the ->apply() implementation:
- Do my work on top of this patch (https://lkml.org/lkml/2016/10/7/454
as you did) to avoid rewriting work already done.
- In the example ->apply() implementation for rockchip
(https://patchwork.kernel.org/patch/7228221/) the ->config() callback
was not removed when ->apply() was implemented. I was confused with
such approach, but as you explained in this mail, the solely ->apply()
is enough.
> It's not tested, and
> probably not working, but it should give you a better idea of what is
> expected.
Thanks for explanation,
?ukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161023/a40e15be/attachment.sig>
^ permalink raw reply
* [V4,3/3] Revert "ACPI,PCI,IRQ: separate ISA penalty calculation"
From: Jonathan Liu @ 2016-10-23 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-4-git-send-email-okaya@codeaurora.org>
On 20 October 2016 at 09:21, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
> calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
> redundant code in acpi_irq_penalty_init()"").
>
> Now that we understand the real issue (SCI and ISA penalty getting
> calculated before ACPI start), there is no need for special handling
> for ISA interrupts.
>
> Let's try to simplify the code one more time to share code.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/pci/acpi.c | 1 -
> drivers/acpi/pci_link.c | 44 +++++---------------------------------------
> include/acpi/acpi_drivers.h | 1 -
> 3 files changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 3cd6983..b2a4e2a 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
> return -ENODEV;
>
> printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
> - acpi_irq_penalty_init();
> pcibios_enable_irq = acpi_pci_irq_enable;
> pcibios_disable_irq = acpi_pci_irq_disable;
> x86_init.pci.init_irq = x86_init_noop;
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 294b190..dd14d78 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
> * If a link is active, penalize its IRQ heavily
> * so we try to choose a different IRQ.
> */
> - if (link->irq.active && link->irq.active == irq)
> + if ((link->irq.active && link->irq.active == irq) &&
> + (link->irq.initialized == 1))
> penalty += PIRQ_PENALTY_PCI_USING;
>
> /*
> @@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
> penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + penalty += acpi_isa_irq_penalty[irq];
>
> - return penalty + acpi_irq_pci_sharing_penalty(irq);
> -}
> -
> -int __init acpi_irq_penalty_init(void)
> -{
> - struct acpi_pci_link *link;
> - int i;
> -
> - /*
> - * Update penalties to facilitate IRQ balancing.
> - */
> - list_for_each_entry(link, &acpi_link_list, list) {
> -
> - /*
> - * reflect the possible and active irqs in the penalty table --
> - * useful for breaking ties.
> - */
> - if (link->irq.possible_count) {
> - int penalty =
> - PIRQ_PENALTY_PCI_POSSIBLE /
> - link->irq.possible_count;
> -
> - for (i = 0; i < link->irq.possible_count; i++) {
> - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> - acpi_isa_irq_penalty[link->irq.
> - possible[i]] +=
> - penalty;
> - }
> -
> - } else if (link->irq.active &&
> - (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> - acpi_isa_irq_penalty[link->irq.active] +=
> - PIRQ_PENALTY_PCI_POSSIBLE;
> - }
> - }
> -
> - return 0;
> + penalty += acpi_irq_pci_sharing_penalty(irq);
> + return penalty;
> }
>
> static int acpi_irq_balance = -1; /* 0: static, 1: balance */
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index 29c6912..797ae2e 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -78,7 +78,6 @@
>
> /* ACPI PCI Interrupt Link (pci_link.c) */
>
> -int acpi_irq_penalty_init(void);
> int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
> int *polarity, char **name);
> int acpi_pci_link_free_irq(acpi_handle handle);
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [V4,2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Jonathan Liu @ 2016-10-23 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-3-git-send-email-okaya@codeaurora.org>
On 20 October 2016 at 09:21, Sinan Kaya <okaya@codeaurora.org> wrote:
> The SCI penalize function was removed in two steps (first refactor
> and then remove) and these changes are reverted here in one go.
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. That change is partially
> reverted here, specifically for the SCI IRQ alone.
>
> The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> penalty API with penalty calculation carried out dynamically and based
> on the acpi_gbl_FADT.sci_interrupt value.
>
> However, that new algorithm relies on the accurate setting of IRQ
> types and that doesn't happen early enough on some platforms which
> leads to incorrect penalty assignments for PCI IRQs. In those cases,
> irq_get_trigger_type() returns incorrect values for the IRQs in
> question, because they have not been registered yet by the time the
> penalties are calculated.
>
> To fix this problem, we only need to fix the penalty for the SCI interrupt.
> It seems better to add a single "sci_penalty" variable, set it to
> PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> otherwise, and add "sci_penalty" in when appropriate. That should fix it
> for *any* SCI IRQ, not just those less than 256, and we don't have to add
> these extra penalty table entries that are all unused (except possibly for
> one entry if we have an SCI in the 16-255 range).
>
> For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> penalize function") completely to restore the correct behavior.
>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 30 +++++++++++++++---------------
> include/linux/acpi.h | 1 +
> 3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 4f37938..294b190 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>
> static LIST_HEAD(acpi_link_list);
> static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>
> /* --------------------------------------------------------------------------
> PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> + if (irq == sci_irq)
> + penalty += sci_penalty;
>
> if (irq < ACPI_MAX_ISA_IRQS)
> return penalty + acpi_isa_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return penalty + acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + sci_irq = irq;
> +
> + if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> + polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> + sci_penalty = PIRQ_PENALTY_PCI_USING;
> + else
> + sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [V4, 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Jonathan Liu @ 2016-10-23 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-2-git-send-email-okaya@codeaurora.org>
On 20 October 2016 at 09:21, Sinan Kaya <okaya@codeaurora.org> wrote:
> The penalty determination of ISA IRQ goes through 4 paths.
> 1. assign PCI_USING during power up via acpi_irq_penalty_init.
> 2. update the penalty with acpi_penalize_isa_irq function based on the
> active parameter.
> 3. kernel command line penalty update via acpi_irq_penalty_update function.
> 4. increment the penalty as USING right after the IRQ is assign to PCI.
>
> acpi_penalize_isa_irq and acpi_irq_penalty_update functions get called
> before the ACPI subsystem is started.
>
> These API need to bypass the acpi_irq_get_penalty function.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..4f37938 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> + new_penalty = acpi_isa_irq_penalty[irq] +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> void acpi_penalize_isa_irq(int irq, int active)
> {
> if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
This series fixes one or more network adapters not working in Linux
32-bit x86 guest running inside VirtualBox if I have 4 network
adapters enabled. The following message no longer appears in the
kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH 3/3] arm64: arch timer: Add timer erratum property for Hip05-d02 and Hip06-d03
From: Ding Tianhong @ 2016-10-23 3:21 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 1 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index bf322ed..9d18875 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -281,6 +281,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161x01;
};
pmu {
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5927bc4..c38c658 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -260,6 +260,7 @@
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ hisilicon,erratum-161x01;
};
pmu {
--
1.9.0
^ permalink raw reply related
* [PATCH 2/3] arm64: arch_timer: Work around QorIQ Erratum Hisilicon-161x01
From: Ding Tianhong @ 2016-10-23 3:21 UTC (permalink / raw)
To: linux-arm-kernel
Erratum Hisilicon-161x01 says that the ARM generic timer counter "has the
potential to contain an erroneous value when the timer value changes".
Accesses to TVAL (both read and write) are also affected due to the implicit counter
read. Accesses to CVAL are not affected.
The workaround is to reread TVAL and count registers until successive
reads return the limited range value (32) by back-to-back reads. Writes to TVAL are
replaced with an equivalent write to CVAL.
The workaround is enabled if the hisilicon,erratum-161x01 property is found in
the timer node in the device tree. This can be overridden with the
clocksource.arm_arch_timer.hisilicon-161x01 boot parameter, which allows KVM
users to enable the workaround until a mechanism is implemented to
automatically communicate this information.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
Documentation/kernel-parameters.txt | 9 ++
arch/arm64/include/asm/arch_timer.h | 41 +++++++--
drivers/clocksource/Kconfig | 14 ++-
drivers/clocksource/arm_arch_timer.c | 153 +++++++++++++++++++++++++++------
5 files changed, 182 insertions(+), 36 deletions(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 405da11..3a79803 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -63,3 +63,4 @@ stable kernels.
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
+| Hisilicon | Hip05/Hip06/Hip07 | #161x01 | HISILICON_ERRATUM_161x01|
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6fa1d8a..175f349 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -707,6 +707,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
erratum. If unspecified, the workaround is
enabled based on the device tree.
+ clocksource.arm_arch_timer.hisilicon-161x01=
+ [ARM64]
+ Format: <bool>
+ Enable/disable the workaround of Hisilicon
+ erratum 161x01. This can be useful for KVM
+ guests, if the guest device tree doesn't show the
+ erratum. If unspecified, the workaround is
+ enabled based on the device tree.
+
clearcpuid=BITNUM [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index eaa5bbe..6b510db 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -29,17 +29,24 @@
#include <clocksource/arm_arch_timer.h>
-#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
extern struct static_key_false arch_timer_read_ool_enabled;
-#define needs_fsl_a008585_workaround() \
+extern struct arch_timer_erratum_workaround *erratum_workaround;
+#define needs_timer_erratum_workaround() \
static_branch_unlikely(&arch_timer_read_ool_enabled)
#else
-#define needs_fsl_a008585_workaround() false
+#define needs_timer_erratum_workaround() false
#endif
-u32 __fsl_a008585_read_cntp_tval_el0(void);
-u32 __fsl_a008585_read_cntv_tval_el0(void);
-u64 __fsl_a008585_read_cntvct_el0(void);
+struct clock_event_device;
+
+struct arch_timer_erratum_workaround {
+ int erratum;
+ u32 (*read_cntp_tval_el0)(void);
+ u32 (*read_cntv_tval_el0)(void);
+ u64 (*read_cntvct_el0)(void);
+};
+extern struct arch_timer_erratum_workaround *erratum_workaround;
/*
* The number of retries is an arbitrary value well beyond the highest number
@@ -59,16 +66,34 @@ u64 __fsl_a008585_read_cntvct_el0(void);
_new; \
})
+#define __hisi_161x01_read_reg(reg) ({ \
+ u64 _old, _new; \
+ int _retries = 200; \
+ \
+ do { \
+ _old = read_sysreg(reg); \
+ _new = read_sysreg(reg); \
+ _retries--; \
+ } while (unlikely((_new - _old) >> 5) && _retries); \
+ \
+ WARN_ON_ONCE(!_retries); \
+ _new; \
+})
+
+
+
#define arch_timer_reg_read_stable(reg) \
({ \
u64 _val; \
- if (needs_fsl_a008585_workaround()) \
- _val = __fsl_a008585_read_##reg(); \
+ if (needs_timer_erratum_workaround()) \
+ _val = erratum_workaround->read_##reg(); \
else \
_val = read_sysreg(reg); \
_val; \
})
+
+
/*
* These register accessors are marked inline so the compiler can
* nicely work out which register we want, and chuck away the rest of
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 8a753fd..fcfcdc7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
help
This option enables a workaround for Freescale/NXP Erratum
A-008585 ("ARM generic timer may contain an erroneous
- value"). The workaround will only be active if the
+ value"). The workaround will be active if the
fsl,erratum-a008585 property is found in the timer node.
+ This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
+ boot parameter.
+
+config HISILICON_ERRATUM_161X01
+ bool "Workaround for Hisilicon Erratum 161201"
+ default y
+ depends on ARM_ARCH_TIMER && ARM64
+ help
+ This option enables a workaround for Hisilicon Erratum
+ 161201. The workaround will be active if the hisi,erratum-161201
+ property is found in the timer node. This can be overridden with
+ the clocksource.arm_arch_timer.hisi-161201 boot parameter.
config ARM_GLOBAL_TIMER
bool "Support for the ARM global timer" if COMPILE_TEST
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 73c487d..e1cf0ad 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -90,16 +90,23 @@ static int __init early_evtstrm_cfg(char *buf)
}
early_param("clocksource.arm_arch_timer.evtstrm", early_evtstrm_cfg);
-/*
- * Architected system timer support.
- */
+#define FSL_A008585 1
+#define HISILICON_161X01 2
+
+struct arch_timer_erratum_workaround *erratum_workaround;
+
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
+static int arch_timer_uses_erratum = 0;
-#ifdef CONFIG_FSL_ERRATUM_A008585
DEFINE_STATIC_KEY_FALSE(arch_timer_read_ool_enabled);
EXPORT_SYMBOL_GPL(arch_timer_read_ool_enabled);
+#endif
-static int fsl_a008585_enable = -1;
+/*
+ * Architected system timer support.
+ */
+#ifdef CONFIG_FSL_ERRATUM_A008585
static int __init early_fsl_a008585_cfg(char *buf)
{
int ret;
@@ -109,28 +116,96 @@ static int __init early_fsl_a008585_cfg(char *buf)
if (ret)
return ret;
- fsl_a008585_enable = val;
+ if (val)
+ arch_timer_uses_erratum = FSL_A008585;
+
return 0;
}
early_param("clocksource.arm_arch_timer.fsl-a008585", early_fsl_a008585_cfg);
-u32 __fsl_a008585_read_cntp_tval_el0(void)
+u32 fsl_a008585_read_cntp_tval_el0(void)
{
return __fsl_a008585_read_reg(cntp_tval_el0);
}
-u32 __fsl_a008585_read_cntv_tval_el0(void)
+u32 fsl_a008585_read_cntv_tval_el0(void)
{
return __fsl_a008585_read_reg(cntv_tval_el0);
}
-u64 __fsl_a008585_read_cntvct_el0(void)
+u64 fsl_a008585_read_cntvct_el0(void)
{
return __fsl_a008585_read_reg(cntvct_el0);
}
-EXPORT_SYMBOL(__fsl_a008585_read_cntvct_el0);
+EXPORT_SYMBOL(fsl_a008585_read_cntvct_el0);
+#else
+u32 fsl_a008585_read_cntp_tval_el0(void)
+{
+ return 0;
+}
+
+u32 fsl_a008585_read_cntv_tval_el0(void)
+{
+ return 0;
+}
+
+u64 fsl_a008585_read_cntvct_el0(void)
+{
+ return 0;
+}
+EXPORT_SYMBOL(fsl_a008585_read_cntvct_el0);
#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#ifdef CONFIG_HISILICON_ERRATUM_161X01
+static int __init early_hisi_161x01_cfg(char *buf)
+{
+ int ret;
+ bool val;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ if (val)
+ arch_timer_uses_erratum = HISILICON_161X01;
+
+ return 0;
+}
+early_param("clocksource.arm_arch_timer.hisilicon-161x01", early_hisi_161x01_cfg);
+
+u32 hisi_161x01_read_cntp_tval_el0(void)
+{
+ return __hisi_161x01_read_reg(cntp_tval_el0);
+}
+
+u32 hisi_161x01_read_cntv_tval_el0(void)
+{
+ return __hisi_161x01_read_reg(cntv_tval_el0);
+}
+
+u64 hisi_161x01_read_cntvct_el0(void)
+{
+ return __hisi_161x01_read_reg(cntvct_el0);
+}
+EXPORT_SYMBOL(hisi_161x01_read_cntvct_el0);
+#else
+u32 hisi_161x01_read_cntp_tval_el0(void)
+{
+ return 0;
+}
+
+u32 hisi_161x01_read_cntv_tval_el0(void)
+{
+ return 0;
+}
+
+u64 hisi_161x01_read_cntvct_el0(void)
+{
+ return 0;
+}
+EXPORT_SYMBOL(hisi_161x01_read_cntvct_el0);
+#endif
+
static __always_inline
void arch_timer_reg_write(int access, enum arch_timer_reg reg, u32 val,
struct clock_event_device *clk)
@@ -280,8 +355,8 @@ static __always_inline void set_next_event(const int access, unsigned long evt,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-#ifdef CONFIG_FSL_ERRATUM_A008585
-static __always_inline void fsl_a008585_set_next_event(const int access,
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
+static __always_inline void erratum_set_next_event(const int access,
unsigned long evt, struct clock_event_device *clk)
{
unsigned long ctrl;
@@ -299,20 +374,35 @@ static __always_inline void fsl_a008585_set_next_event(const int access,
arch_timer_reg_write(access, ARCH_TIMER_REG_CTRL, ctrl, clk);
}
-static int fsl_a008585_set_next_event_virt(unsigned long evt,
+static int erratum_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
+ erratum_set_next_event(ARCH_TIMER_VIRT_ACCESS, evt, clk);
return 0;
}
-static int fsl_a008585_set_next_event_phys(unsigned long evt,
+static int erratum_set_next_event_phys(unsigned long evt,
struct clock_event_device *clk)
{
- fsl_a008585_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
+ erratum_set_next_event(ARCH_TIMER_PHYS_ACCESS, evt, clk);
return 0;
}
-#endif /* CONFIG_FSL_ERRATUM_A008585 */
+#endif /* CONFIG_FSL_ERRATUM_A008585 || CONFIG_HISILICON_ERRATUM_161X01 */
+
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
+static struct arch_timer_erratum_workaround arch_timer_erratum[] = {
+{
+ .erratum = FSL_A008585,
+ .read_cntp_tval_el0 = fsl_a008585_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = fsl_a008585_read_cntv_tval_el0,
+ .read_cntvct_el0 = fsl_a008585_read_cntvct_el0,
+},{
+ .erratum = HISILICON_161X01,
+ .read_cntp_tval_el0 = hisi_161x01_read_cntp_tval_el0,
+ .read_cntv_tval_el0 = hisi_161x01_read_cntv_tval_el0,
+ .read_cntvct_el0 = hisi_161x01_read_cntvct_el0,
+} };
+#endif
static int arch_timer_set_next_event_virt(unsigned long evt,
struct clock_event_device *clk)
@@ -342,16 +432,16 @@ static int arch_timer_set_next_event_phys_mem(unsigned long evt,
return 0;
}
-static void fsl_a008585_set_sne(struct clock_event_device *clk)
+static void erratum_set_sne(struct clock_event_device *clk)
{
-#ifdef CONFIG_FSL_ERRATUM_A008585
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
return;
if (arch_timer_uses_ppi == VIRT_PPI)
- clk->set_next_event = fsl_a008585_set_next_event_virt;
+ clk->set_next_event = erratum_set_next_event_virt;
else
- clk->set_next_event = fsl_a008585_set_next_event_phys;
+ clk->set_next_event = erratum_set_next_event_phys;
#endif
}
@@ -384,7 +474,7 @@ static void __arch_timer_setup(unsigned type,
BUG();
}
- fsl_a008585_set_sne(clk);
+ erratum_set_sne(clk);
} else {
clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
clk->name = "arch_mem_timer";
@@ -890,12 +980,21 @@ static int __init arch_timer_of_init(struct device_node *np)
arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-#ifdef CONFIG_FSL_ERRATUM_A008585
- if (fsl_a008585_enable < 0)
- fsl_a008585_enable = of_property_read_bool(np, "fsl,erratum-a008585");
- if (fsl_a008585_enable) {
+#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161X01)
+ if (!arch_timer_uses_erratum) {
+ if (IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) &&
+ of_property_read_bool(np, "fsl,erratum-a008585"))
+ arch_timer_uses_erratum = FSL_A008585;
+ else if (IS_ENABLED(CONFIG_HISI_ERRATUM_161X01) &&
+ of_property_read_bool(np, "hisilicon,erratum-161x01"))
+ arch_timer_uses_erratum = HISILICON_161X01;
+ }
+
+ if (arch_timer_uses_erratum) {
+ erratum_workaround = &arch_timer_erratum[arch_timer_uses_erratum - 1];
+ pr_info("Enabling workaround for %s\n", arch_timer_uses_erratum == FSL_A008585 ?
+ "FSL erratum A-008585" : "HISILICON ERRATUM 161x01");
static_branch_enable(&arch_timer_read_ool_enabled);
- pr_info("Enabling workaround for FSL erratum A-008585\n");
}
#endif
--
1.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox