* [PATCH] ARM: dts: vf610: fix IRQ flag of global timer
From: Shawn Guo @ 2016-10-24 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018015127.16981-1-stefan@agner.ch>
On Mon, Oct 17, 2016 at 06:51:27PM -0700, Stefan Agner wrote:
> The global timer IRQ (PPI[0], PPI 11 in device tree terms) is a
> rising edge interrupt. The ARM Cortex-A5 MPCore TRM in Chapter
> 10.1.2. Interrupt types and sources says:
> "Interrupt is rising-edge sensitive."
>
> The bits seem to be read-only, hence this missconfiguration had
> no negative effect. However, with commit 992345a58e0c
> ("irqchip/gic: WARN if setting the interrupt type for a PPI fails")
> warnings such as this get printed:
> GIC: PPI11 is secure or misconfigured
>
> With this change the new configuration matches the default
> configuration and no warning is printed anymore.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Nicolas Ferre @ 2016-10-24 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m535dti.fsf@linux.intel.com>
Le 26/09/2016 ? 09:18, Felipe Balbi a ?crit :
>
> Hi,
>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>> On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
>>> Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
>>>> Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
>>>>> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>>>>> atmel_usba_udc fails with:
>>>>>
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>>>>> ecm_do_notify+0x188/0x1a0
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>>>>> Hardware name: Atmel SAMA5
>>>>> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
>>>>> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
>>>>> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
>>>>> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
>>>>> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
>>>>> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
>>>>> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
>>>>> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
>>>>> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
>>>>> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
>>>>> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
>>>>> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
>>>>> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
>>>>> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
>>>>> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
>>>>> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
>>>>> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
>>>>> ---[ end trace e7cf9dcebf4815a6 ]---
>>>>>
>>>>> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>>>>> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>
>>>> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>>
>>>> Felipe, Greg,
>>>> It is clearly a regression and material for 4.8-fixes. But I do know
>>>> that we are very late in the process :-(
>>>> Please do what you can to make it progress before 4.8-final but I'm
>>>> truly aware of the challenge.
>>>
>>> Any chance that we can have it (aka ping)?
>>
>> It's Felipe's area, not mine :)
>
> Sorry, I had missed this one. Greg, seems like this would be the only
> pending fix. Do you want it in a pull request or would you prefer to
> just pick it up as a patch? Works either way for me. In case you decide
> to pick it up as a patch:
>
> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>
> If you prefer to pick it up as a pull request, I already have the patch
> in my 'fixes' branch, just need to tag it and send it to you.
Felipe,
We agreed to delay this patch after the merge window is closed. But I
feel that it's beginning to be urgent to make this patch go forward:
actual users of our kernel are facing the issue:
https://lkml.org/lkml/2016/10/17/493
We're already at -rc2 and I don't see USB-fixes included...
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/4] mtk_mdp_vpu: remove a double unlock at the error path
From: Minghsiu Tsai @ 2016-10-24 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <768767961c64dea3fdd86132c9eba87ae652d588.1477058332.git.mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> As warned by smatch:
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:98 mtk_mdp_vpu_send_msg() error: double unlock 'mutex:&ctx->mdp_dev->vpulock'
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> index b38d29e99f7a..5c8caa864e32 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> @@ -91,7 +91,6 @@ static int mtk_mdp_vpu_send_msg(void *msg, int len, struct mtk_mdp_vpu *vpu,
> mutex_lock(&ctx->mdp_dev->vpulock);
> err = vpu_ipi_send(vpu->pdev, (enum ipi_id)id, msg, len);
> if (err) {
> - mutex_unlock(&ctx->mdp_dev->vpulock);
Hi Mauro,
It has been fixed by Hans in the later patch.
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date: Mon Sep 19 05:00:34 2016 -0300
[media] mtk-mdp: fix double mutex_unlock
Fix smatch error:
media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:100
mtk_mdp_vpu_send_msg() error: double unlock 'mutex:&ctx->
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
minghsiu
> dev_err(&ctx->mdp_dev->pdev->dev,
> "vpu_ipi_send fail status %d\n", err);
> }
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Sekhar Nori @ 2016-10-24 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-6-git-send-email-david@lechnology.com>
On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> This adds a device tree definition file for LEGO MINDSTORMS EV3.
Thanks for the patch!
>
> What is working:
>
> * Pin muxing
> * MicroSD card reader
> * UART on input port 1
>
> What is partially working:
>
> * Buttons - working after GPIO fix
> * LEDs - working after GPIO fix
> * Poweroff/reset - working after GPIO fix
Is the GPIO fix something that will go in v4.9-rc cycle ?
> * Flash memory - driver loads but can't read the block devices - this is
> probably due to the fact that we are not able to configure the SPI to
> use DMA via device tree
Hmm, I would not have expected PIO mode to be so inefficient that you
are unable to even read the block device.
> * EEPROM - there seems to be a hardware bug that causes the first byte
> read to be corrupted - this can be worked around by adding an I2C stop
> between writing the register and reading the data, but the at24 driver
> does not have an option to do this
>
> What is not working/to be added later:
>
> * Display - waiting for "tiny DRM" to be mainlined
> * Speaker - needs new PWM sound driver
> * USB - waiting for OHCI and MUSB device tree support to be mainlined
> * ADC - needs new iio driver
> * GPIOs - broken because of recent changes to core gpio driver
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver
> * Battery - needs new power supply driver (depends on ADC iio driver)
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 456 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/lego-ev3.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f80f5b7..5f91c1a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -116,7 +116,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
> dtb-$(CONFIG_ARCH_DAVINCI) += \
> da850-lcdk.dtb \
> da850-enbw-cmc.dtb \
> - da850-evm.dtb
> + da850-evm.dtb \
> + lego-ev3.dtb
> dtb-$(CONFIG_ARCH_DIGICOLOR) += \
> cx92755_equinox.dtb
> dtb-$(CONFIG_ARCH_EFM32) += \
> diff --git a/arch/arm/boot/dts/lego-ev3.dts b/arch/arm/boot/dts/lego-ev3.dts
> new file mode 100644
> index 0000000..a6b4c7d
> --- /dev/null
> +++ b/arch/arm/boot/dts/lego-ev3.dts
> @@ -0,0 +1,454 @@
> +/*
> + * Device tree for LEGO MINDSTORMS EV3
> + *
> + * Copyright (C) 2016 David Lechner <david@lechnology.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation, version 2.
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +#include "da850.dtsi"
> +
> +/ {
> + compatible = "lego,ev3", "ti,da850";
> + model = "LEGO MINDSTORMS EV3";
> +
> + soc at 1c00000 {
> + /*
> + * (ab)using pinctrl-single to disable all internal pullups/
> + * pulldowns on I/O.
> + */
> + pinmux at 22c00c {
> + compatible = "pinctrl-single";
> + reg = <0x22c00c 0x4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,bit-per-mux;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xf>;
> + /*
> + * There is a bug in pinctrl-single that prevents us
> + * from setting function-mask to 1, so doing things
> + * in groups of 4. Doesn't really matter since we are
> + * disabling all at once anyway.
> + */
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pupu_disable>;
> +
> + pupu_disable: pinmux_all_pins {
> + pinctrl-single,bits = <
> + 0x0 0x00000000 0xffffffff
> + >;
> + };
Sigh. This is quite an abuse :)
I know we don't have a good way to configure this in kernel today. And I
am surprised we never had to care about disabling pullups so far. Can
you clarify why you need it? I assume there is some contention you want
to avoid, but on which interface?
I dont think this can be done this way using pinctrl-single. A small
driver to handle pullup/down control for da850 may have to be added to
drivers/pinctrl. It will be better to check with Linus Walleij on his
thoughts using a new thread ccing the pinctrl subsystem list as well.
[...]
> + in1_pins: pinmux_in1_pins {
> + pinctrl-single,bits = <
> + /* GP0[15] */
> + 0x0 0x00000008 0x0000000f
> + /* GP0[2] */
> + 0x4 0x00800000 0x00f00000
> + /* GP2[2] */
> + 0x18 0x00800000 0x00f00000
> + /* GP8[10], GP8[11] */
> + 0x48 0x88000000 0xff000000
> + >;
> + };
I see that this is not really used. Can you add these when you actually
use them. Looks like that applies to some other definitions like this below.
> +&ehrpwm1 {
> + status = "disabled";
Hmm, disabled? Can you add this node when you actually use it?
> + pinctrl-names = "default";
> + /* MBPWM, MAPWM */
> + pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
> +};
> +
> +&ecap1 {
> + status = "disabled";
same here and other places below.
> + pinctrl-names = "default";
> + /* MDPWM */
> + pinctrl-0 = <&ecap1_pins>;
> +};
> +
> +&spi0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
> + dmas = <&edma0 14 0>, <&edma0 15 0>;
> + dma-names = "rx", "tx";
> +
> + spi-flash at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "n25q128a13", "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <50000000>;
> + ti,spi-wdelay = <8>;
> +
> + partition at 0 {
> + label = "U-Boot";
> + reg = <0 0x40000>;
Thats 256KB for U-Boot and MLO (I assume in concatenated AIS image). Is
that sufficient for future too? Moving partitions later is tough ask
because that means users will lose data when they upgrade the kernel
because of partitions moving around. Just a suggestion to keep future
U-Boot bloat in mind and not use a "just fits" number.
> + };
> +
> + partition at 40000 {
> + label = "U-Boot Env";
> + reg = <0x40000 0x10000>;
> + };
> +
> + partition at 50000 {
> + label = "Kernel";
> + reg = <0x50000 0x200000>;
> + };
> +
> + partition at 250000 {
> + label = "Filesystem";
> + reg = <0x250000 0xa50000>;
> + };
> +
> + partition at cb0000 {
> + label = "Storage";
> + reg = <0xcb0000 0x2f0000>;
> + };
> + };
> +
> + /* TODO: ADC goes here */
I would drop this comment.
> +};
> +
> +&spi1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
> +
> + /* TODO: LCD Display goes here */
Add this node when you actually have display working.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dts: novena: Enable PWM1
From: Shawn Guo @ 2016-10-24 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017163449.11990-1-marex@denx.de>
On Mon, Oct 17, 2016 at 06:34:49PM +0200, Marek Vasut wrote:
> Enable PWM1, otherwise the backlight cannot work.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Select the es8328 codec driver
From: Shawn Guo @ 2016-10-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017163433.11938-1-marex@denx.de>
On Mon, Oct 17, 2016 at 06:34:33PM +0200, Marek Vasut wrote:
> Select CONFIG_SND_SOC_ES8328 so that we can have audio functional
> by default on Kosagi Novena boards.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
From: Andy Yan @ 2016-10-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Hi:
On 2016?10?22? 16:43, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 50702c7..df22066 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -694,6 +694,8 @@ static int rk3x_i2c_v0_calc_timings(unsigned long clk_rate,
> t_calc->div_low--;
> t_calc->div_high--;
>
> + /* Give the tuning value 0, that would not update con register */
> + t_calc->tuning = 0;
> /* Maximum divider supported by hw is 0xffff */
> if (t_calc->div_low > 0xffff) {
> t_calc->div_low = 0xffff;
rk3066a based board can't boot up(with endless i2c irq messages print
out) from linux-4.8 without this fix.
Tested-by: Andy Yan <andy.yan@rock-chips.com>
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: Increase CMA size
From: Shawn Guo @ 2016-10-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017163411.11888-1-marex@denx.de>
On Mon, Oct 17, 2016 at 06:34:11PM +0200, Marek Vasut wrote:
> Increase the CMA size to 64 MiB, otherwise it isn't possible to use
> etnaviv driver on systems with 1920x1080 panel due to insufficient
> memory .
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Punit Agrawal @ 2016-10-24 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150916.0d274e9f@lwn.net>
Jonathan Corbet <corbet@lwn.net> writes:
> On Mon, 17 Oct 2016 16:26:23 +0100
> Punit Agrawal <punit.agrawal@arm.com> wrote:
>
>> The dma mapping api howto gives the impression that using the
>> dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
>> to check all the components in the path from the device to memory for
>> addressing restrictions. In systems with address translations between
>> the device and memory (e.g., when using IOMMU), this implies that a
>> successful call to set set dma mask has checked the addressing
>> constraints of the intermediaries as well.
>>
>> For the IOMMU drivers in the tree, the check is actually performed while
>> allocating the DMA buffer rather than when the DMA mask is
>> configured. For MMUs that do not support the full device addressing
>> capability, the allocations are made from a reduced address space.
>>
>> Update the documentation to clarify that even though the call to
>> dma_set_mask_and_coherent succeeds, it may not be possible to use the
>> full addressing capability of the device.
>
> OK, so I guess I can buy this. But...
>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Jonathan Corbet <corbet@lwn.net>
>> ---
>> Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++----------------
>> 1 file changed, 23 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
>> index 979228b..240d1ee 100644
>> --- a/Documentation/DMA-API-HOWTO.txt
>> +++ b/Documentation/DMA-API-HOWTO.txt
>> @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. And at least
>> one platform (SGI SN2) requires 64-bit consistent allocations to
>> operate correctly when the IO bus is in PCI-X mode.
>>
>> -For correct operation, you must interrogate the kernel in your device
>> -probe routine to see if the DMA controller on the machine can properly
>> -support the DMA addressing limitation your device has. It is good
>> +For correct operation, you must inform the kernel in your device probe
>> +routine to see if the DMA controller on the machine can properly
>> +support the DMA addressing capabilities your device has. It is good
>
> Here it's still saying "to see if the DMA controller on the machine can
> properly support the DMA addressing capabilities your device has". So
> you've not really changed the sense of this sentence here.
You're right - the changes don't go far enough.
How about dropping the bit so that it now reads -
"For correct operation, in your device probe routine, you must inform
the DMA addressing capabilities of your device to the kernel."
>
> If I understand things correctly, the calls in question are storing the
> device's limitations; they will only fail if the kernel is entirely
> unable to work within the indicated range, right? I don't think there's
> ever been any guarantee that the system as a whole could use the entire
> range that is addressable by the device.
That matches my understanding as well. I was just trying to make it more
explicit with this patch.
> I have no objection to making
> that more clear, but let's actually make it more clear by saying what the
> functions are actually doing.
>
> Make sense, or am I missing something here?
Let me know if the change I suggest is an improvement and I'll send out
a v2.
Thanks,
Punit
>
> Thanks,
>
> jon
^ permalink raw reply
* [PATCH 3/4] mtk_mdp_m2m: remove an unused struct
From: Minghsiu Tsai @ 2016-10-24 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <624b0ea4550b90318ec2293d80b1caa5bafd2a35.1477058332.git.mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:48:33: warning: ?mtk_mdp_size_align? defined but not used [-Wunused-variable]
> static struct mtk_mdp_pix_align mtk_mdp_size_align = {
> ^~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 065502757133..33124a6c9951 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -45,13 +45,6 @@ struct mtk_mdp_pix_limit {
> u16 target_rot_en_h;
> };
>
> -static struct mtk_mdp_pix_align mtk_mdp_size_align = {
> - .org_w = 16,
> - .org_h = 16,
> - .target_w = 2,
> - .target_h = 2,
> -};
> -
Hi Mauro,
The structure is used for the format V4L2_PIX_FMT_MT21C which is added
in the later patch.
"[media] media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C"
I just know checkpatch should be run patch by patch, so this warning
message will be generated without the MT21C patch.
I found all mtk-mdp patches have been merged in media tree, so is this
patch still needed?
If yes, remove 'mtk_mdp_size_align' in this patch, and re-added it in
the MT21C patch.
minghsiu
> static const struct mtk_mdp_fmt mtk_mdp_formats[] = {
> {
> .pixelformat = V4L2_PIX_FMT_NV12M,
^ permalink raw reply
* [SPAM][PATCH 3/4] mtk_mdp_m2m: remove an unused struct
From: Minghsiu Tsai @ 2016-10-24 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <624b0ea4550b90318ec2293d80b1caa5bafd2a35.1477058332.git.mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:48:33: warning: ?mtk_mdp_size_align? defined but not used [-Wunused-variable]
> static struct mtk_mdp_pix_align mtk_mdp_size_align = {
> ^~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 065502757133..33124a6c9951 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -45,13 +45,6 @@ struct mtk_mdp_pix_limit {
> u16 target_rot_en_h;
> };
>
> -static struct mtk_mdp_pix_align mtk_mdp_size_align = {
> - .org_w = 16,
> - .org_h = 16,
> - .target_w = 2,
> - .target_h = 2,
> -};
> -
Hi Mauro,
The structure is used for the format V4L2_PIX_FMT_MT21C which is added
in the later patch.
"[media] media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C"
I just know checkpatch should be run patch by patch, so this warning
message will be generated without the MT21C patch.
I found all mtk-mdp patches have been merged in media tree, so is this
patch still needed?
If yes, remove 'mtk_mdp_size_align' in this patch, and re-added it in
the MT21C patch.
minghsiu
> static const struct mtk_mdp_fmt mtk_mdp_formats[] = {
> {
> .pixelformat = V4L2_PIX_FMT_NV12M,
^ permalink raw reply
* [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Marek Vasut @ 2016-10-24 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919213800.9498-1-marex@denx.de>
On 09/19/2016 11:38 PM, Marek Vasut wrote:
> Add vendor prefix for Aries Embedded GmbH
> http://www.aries-embedded.de/
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Rob Herring <robh@kernel.org>
Hi, bump ?
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 69caf14..522dd65 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -27,6 +27,7 @@ analogix Analogix Semiconductor, Inc.
> apm Applied Micro Circuits Corporation (APM)
> aptina Aptina Imaging
> arasan Arasan Chip Systems
> +aries Aries Embedded GmbH
> arm ARM Ltd.
> armadeus ARMadeus Systems SARL
> arrow Arrow Electronics
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Punit Agrawal @ 2016-10-24 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024110819.GO3541@8bytes.org>
Joerg Roedel <joro@8bytes.org> writes:
> On Fri, Oct 21, 2016 at 03:09:16PM -0600, Jonathan Corbet wrote:
>> On Mon, 17 Oct 2016 16:26:23 +0100
>> Punit Agrawal <punit.agrawal@arm.com> wrote:
>>
>> > The dma mapping api howto gives the impression that using the
>> > dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
>> > to check all the components in the path from the device to memory for
>> > addressing restrictions. In systems with address translations between
>> > the device and memory (e.g., when using IOMMU), this implies that a
>> > successful call to set set dma mask has checked the addressing
>> > constraints of the intermediaries as well.
>
> This is basically true when you have DMA controllers in the path from
> device to memory. But it is not true for IOMMUs, because IOMMU drivers
> are consumers of the dma-masks, they don't really restrict them. An
> IOMMU driver knows the limitations of IOMMU hardware and counts that in
> when allocating an address for a dma-buffer.
Yes, that's what I'd found looking at the IOMMU drivers in the tree.
>
> So long story short: Any IOMMU restrictions in address space size don't
> need to be represented in the dma-mask for a device.
That was another rabbit hole I'd spend some time in - whether IOMMU
restrictions need to be factored into the dma_mask for devices.
As size(dma_mask) > size(iommu supported address size) still works, I
came to the conclusion that the documentation can maybe help clarify
this.
This patch is an attempt to update the documentation to inform the user
that even if the dma_set_mask call succeeds, the system may still not
use the entire device address space.
Thanks for clarifying a few of my doubts.
Punit
>
>
>
> Joerg
^ permalink raw reply
* [PATCH 2/5] ARM: davinci: Don't append git rev to local version
From: Sekhar Nori @ 2016-10-24 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-3-git-send-email-david@lechnology.com>
On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> In the davinci default configuration, don't append the git revision to
> the local kernel version by. This seems like the more desirable default
> value.
Why? To the contrary I actually quite like the fact that the git commit
is appended to version string. Makes it easy for me to cross-check that
I am booting the right image.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/3] arm64: arch_timer: Work around QorIQ Erratum Hisilicon-161x01
From: Ding Tianhong @ 2016-10-24 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae996e5d-a27d-52eb-8969-3113ec553a1b@arm.com>
See below comments.
On 2016/10/24 18:13, Marc Zyngier wrote:
> On 23/10/16 04:21, Ding Tianhong wrote:
>> 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|
>
> Please keep the columns aligned. If the affected component doesn't fit
> in the allocated space, use multiple lines, or write it in a condensed
> way (Hip0{5,6,7} for example). Also, please use spaces instead of tabs
> to match the rest of the file.
>
Miss this, Sorry.
>> 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;
>
> You seem to be doing two things in this patch:
> - Introducing a more generic erratum handling mechanism
> - Adding a workaround for your particular erratum
>
> Please make this two patches.
>
OK.
>>
>> /*
>> * 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; \
>
> How has this number of retries been determined?
>
Just a empirical data to avoid dead loop, mostly it should not loop so many times, advice from chip developer.
>> + \
>> + do { \
>> + _old = read_sysreg(reg); \
>> + _new = read_sysreg(reg); \
>> + _retries--; \
>> + } while (unlikely((_new - _old) >> 5) && _retries); \
>
> Please document why ignoring the bottom 5 bits is a reasonable thing to do.
>
OK.
>> + \
>> + 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.
>
> Please pick a side. This is either called 161X01 or 161201.
>
Sorry.
>>
>> 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;
>> +
>
> I don't think you need this indirection. You should be able to set the
> erratum_workaround pointer, and test that only to enable the OOL access.
>
>> 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);
>
> Since you're now going to through a pointer indirection
> (erratum_workaround), why do you need this export? Why aren't all these
> function static? How does it work with modules that need to access
> cntvct_el0 (hint: it probably doesn't...)?
>
>> +#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);
>
> I don't think we need any of this.
Agree.
>
>> #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);
>
> Same issue.
>
>> +#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,
>> +} };
>
> Since the two erratum are allowed to be selected independently, you
> shouldn't lump them together here.
>
OK.
>> +#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");
>
> Get rid of arch_timer_uses_erratum, of the erratum identifier in the
> structure, and put a static string in there. That should do everything
> you need.
>
OK.
Thanks.
Ding
>> }
>> #endif
>>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6sx: Add UDOO Neo support
From: Shawn Guo @ 2016-10-24 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476629064-10634-1-git-send-email-afaerber@suse.de>
On Sun, Oct 16, 2016 at 04:44:23PM +0200, Andreas F?rber wrote:
> Add initial device trees for UDOO Neo Basic, Extended and Full boards:
> * Serial console is enabled, other serial ports are prepared.
> * I2C based PMIC is enabled.
> * Ethernet is enabled for Basic and Full.
> * SDHC is enabled, with the SDIO_PWR GPIO modeled as a regulator.
> * Both user LEDs are enabled, with the orange one reserved for the M4
> and with the SD card as default trigger for the red LED.
>
> The decision on a board compatible string is deferred to later.
>
> Cc: Ettore Chimenti <ettore.chimenti@udoo.org>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
<snip>
> +/ {
> + compatible = "fsl,imx6sx";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + red {
> + label = "udoo-neo:red:mmc";
> + gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> +
> + orange {
> + label = "udoo-neo:orange:user";
> + gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
> + default-state = "keep";
> + };
> + };
> +
> + sdio_pwr_reg: sd-gpio-regulator {
We do have a recommended naming schema for fixed regulator. I updated
it a bit as below, and applied the patch.
Shawn
> + compatible = "regulator-fixed";
> + gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-name = "SDIO_PWR";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + };
> +};
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
index 314d25b15641..2b65d26f4396 100644
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -66,7 +66,7 @@
};
};
- sdio_pwr_reg: sd-gpio-regulator {
+ reg_sdio_pwr: regulator-sdio-pwr {
compatible = "regulator-fixed";
gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
enable-active-high;
@@ -283,7 +283,7 @@
&usdhc2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2>;
- vmmc-supply = <&sdio_pwr_reg>;
+ vmmc-supply = <®_sdio_pwr>;
bus-width = <4>;
cd-gpios = <&gpio6 2 GPIO_ACTIVE_LOW>;
no-1-8-v;
^ permalink raw reply related
* [PATCH] kernel: irq: fix build failure
From: Stephen Rothwell @ 2016-10-24 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024102215.GN14477@dell>
Hi Lee,
On Mon, 24 Oct 2016 11:22:15 +0100 Lee Jones <lee.jones@linaro.org> wrote:
>
> On Fri, 21 Oct 2016, Thomas Gleixner wrote:
>
> > On Fri, 21 Oct 2016, Stephen Rothwell wrote:
> > > On Thu, 20 Oct 2016 14:55:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> > > > I know. This is under discussion with the driver folks as we are not going
> > > > to blindly export stuff just because someone slapped a irq_set_parent()
> > > > into the code w/o knowing why.
> > >
> > > Do we have any idea if a resolution is close. This was first reported
> > > in linux-next in September 14/15. :-(
> >
> > Grr. Yes. As much as I hate it, I'll go and export it for now. Should be
> > able to get it into rc2.
>
> Did this get in? I still have people complaining about it.
It is in -rc2. Commit 3118dac501bc.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Mark Rutland @ 2016-10-24 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cbf196b83cd9d175634e7056744dc649ae87f63.1477253239.git.joe@perches.com>
On Sun, Oct 23, 2016 at 01:40:49PM -0700, Joe Perches wrote:
> commit db4b0710fae9 ("arm64: fix show_regs fallout from KERN_CONT changes")
> corrected the KERN_CONT fallout from commit 4bcc595ccd80
> ("printk: reinstate KERN_CONT for printing continuation lines"), but
> the code still has unnecessary KERN_CONT uses. Remove them.
Why are these unnecessary KERN_CONTs a larger problem than duplicating
the format string for a third time? Having to duplicate it at all was
annoying enough.
Overall, to avoid messing with the KERN_CONT mess it'd be nicer to
format this all into a buffer (with the format string only existing the
once) and subsequently print it with one printk call.
> Miscellanea:
>
> o Remove unnecessary trailing blank from the output too.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/arm64/kernel/process.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 01753cd7d3f0..2278e7197a8e 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -190,18 +190,16 @@ void __show_regs(struct pt_regs *regs)
>
> i = top_reg;
>
> - while (i >= 0) {
> - printk("x%-2d: %016llx ", i, regs->regs[i]);
> + if (i >= 0 && !(i % 2)) {
This is difficult to read. Given we know that in either case i >= 0, and
to retain the style of existing code, this would be better as:
if (i % 2 == 0) {
> + printk("x%-2d: %016llx\n", i, regs->regs[i]);
> i--;
> -
> - if (i % 2 == 0) {
> - pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
> - i--;
> - }
> -
> - pr_cont("\n");
> }
> - printk("\n");
This should be retained. It's meant to be there *in addition* to the
newline on the final reg line.
> + while (i > 0) {
> + printk("x%-2d: %016llx x%-2d: %016llx\n",
> + i, regs->regs[i],
> + i - 1, regs->regs[i - 1]);
> + i -= 2;
> + }
> }
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Robin Murphy @ 2016-10-24 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477112061-12868-1-git-send-email-gakula@caviumnetworks.com>
[+Thomas, Jason, Marc]
On 22/10/16 05:54, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrupt controller before older PCI-inbound memory stores
> are committed.
> Doing a sync on SMMU will make sure all prior transactions are
> completed.
>
> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
> ---
> arch/arm64/Kconfig | 11 +++++++++++
> drivers/iommu/arm-smmu.c | 38 ++++++++++++++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-common.h | 1 +
> drivers/irqchip/irq-gic-v3-its.c | 22 ++++++++++++++++++++++
> kernel/irq/chip.c | 4 ++++
The irqchip maintainers should absolutely be CC'ed on this. Please use
get_maintainer.pl to check.
> 5 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 30398db..57f5c9b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -474,6 +474,17 @@ config CAVIUM_ERRATUM_27456
>
> If unsure, say Y.
>
> +config CAVIUM_ERRATUM_28168
> + bool "Cavium erratum 28168: Make sure ITS and SMMU TLB are in sync"
> + default y
> + help
> + Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + controller are delivered to the interrupt controller before older
> + PCI-inbound memory stores are committed. Doing a sync on SMMU
> + will make sure all prior transactions are completed.
Ouch! Is there definitely no other possible workaround, like overriding
transaction attributes, disabling hit-under-miss handling, or somesuch?
Does it have to be a global sync, or is syncing the relevant context
bank sufficient? (I have some half-finished patches to split up the TLB
maintenance ops, including finer-grained syncs wherever possible, which
I can resurrect).
> +
> + If unsure, say Y.
> +
> endmenu
>
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9740846..20a61c6 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -378,6 +378,7 @@ struct arm_smmu_device {
> unsigned int *irqs;
>
> u32 cavium_id_base; /* Specific to Cavium */
> + spinlock_t tlb_lock;
> };
>
> enum arm_smmu_context_fmt {
> @@ -576,9 +577,39 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
> static void arm_smmu_tlb_sync(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> + struct arm_smmu_device *smmu = smmu_domain->smmu;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
So *every* unmap operation on any SMMU ever now has to poll some slow
hardware for up to a second with IRQs disabled unconditionally? I don't
think that's acceptable for the general case.
> __arm_smmu_tlb_sync(smmu_domain->smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> }
>
> +/*
> + * Cavium ThunderX erratum 28168
> + *
> + * Due to erratum #28168 PCI-inbound MSI-X store to the interrupt
> + * controller are delivered to the interrupt controller before older
> + * PCI-inbound memory stores are committed. Doing a sync on SMMU
> + * will make sure all prior transactions are completed.
> + *
> + */
> +void cavium_smmu_tlb_sync(struct device *dev)
> +{
> + struct arm_smmu_device *smmu;
> + struct arm_smmu_master_cfg *cfg;
> + unsigned long flags;
> +
> + smmu = find_smmu_for_device(dev);
Won't compile - that function no longer exists.
> + if (!smmu)
> + return;
> +
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
> + __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> +}
> +EXPORT_SYMBOL(cavium_smmu_tlb_sync);
> +
> static void arm_smmu_tlb_inv_context(void *cookie)
> {
> struct arm_smmu_domain *smmu_domain = cookie;
> @@ -586,6 +617,7 @@ static void arm_smmu_tlb_inv_context(void *cookie)
> struct arm_smmu_device *smmu = smmu_domain->smmu;
> bool stage1 = cfg->cbar != CBAR_TYPE_S2_TRANS;
> void __iomem *base;
> + unsigned long flags;
>
> if (stage1) {
> base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> @@ -597,7 +629,9 @@ static void arm_smmu_tlb_inv_context(void *cookie)
> base + ARM_SMMU_GR0_TLBIVMID);
> }
>
> + spin_lock_irqsave(&smmu->tlb_lock, flags);
> __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
> }
>
> static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> @@ -1562,6 +1596,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
> void __iomem *cb_base;
> int i;
> + unsigned long flags;
> u32 reg, major;
>
> /* clear global FSR */
> @@ -1633,7 +1668,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
> reg |= sCR0_VMID16EN;
>
> /* Push the button */
> + spin_lock_irqsave(&smmu->tlb_lock, flags)
> __arm_smmu_tlb_sync(smmu);
> + spin_unlock_irqrestore(&smmu->tlb_lock, flags)
After the fourth identical wrapping of the same function call, does it
not start to seem a better idea to implement a workaround *inside*
__arm_smmu_tlb_sync()?
> writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
> }
>
> @@ -2001,6 +2038,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> }
>
> + spin_lock_init(&smmu->tlb_lock);
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> platform_set_drvdata(pdev, smmu);
> arm_smmu_device_reset(smmu);
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index 205e5fd..0228ba0 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -38,4 +38,5 @@ void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>
> void gic_set_kvm_info(const struct gic_kvm_info *info);
>
> +void cavium_smmu_tlb_sync(void *iommu);
> #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 003495d..88e9958 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -112,6 +112,7 @@ struct its_device {
> struct its_node *its;
> struct event_lpi_map event_map;
> void *itt;
> + struct device *dev;
> u32 nr_ites;
> u32 device_id;
> };
> @@ -664,10 +665,29 @@ static void its_irq_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
> iommu_dma_map_msi_msg(d->irq, msg);
> }
>
> +/**
> + * Due to erratum in ThunderX,
> + * we need to make sure SMMU is in sync with ITS translations.
> + **/
> +static void its_ack_irq(struct irq_data *d)
> +{
> + struct its_device *its_dev = irq_data_get_irq_chip_data(d);
> + struct pci_dev *pdev;
> +
> + if (!dev_is_pci(its_dev->dev))
> + return;
> +
> + pdev = to_pci_dev(its_dev->dev);
> + if (pdev->vendor != 0x177d)
> + cavium_smmu_tlb_sync(its_dev->dev);
I'm pretty sure that makes any kernel built without CONFIG_ARM_SMMU fail
to link.
Robin.
> +
> +}
> +
> static struct irq_chip its_irq_chip = {
> .name = "ITS",
> .irq_mask = its_mask_irq,
> .irq_unmask = its_unmask_irq,
> + .irq_ack = its_ack_irq,
> .irq_eoi = irq_chip_eoi_parent,
> .irq_set_affinity = its_set_affinity,
> .irq_compose_msi_msg = its_irq_compose_msi_msg,
> @@ -1422,6 +1442,8 @@ static int its_msi_prepare(struct irq_domain *domain, struct device *dev,
> if (!its_dev)
> return -ENOMEM;
>
> + its_dev->dev = dev;
> +
> pr_debug("ITT %d entries, %d bits\n", nvec, ilog2(nvec));
> out:
> info->scratchpad[0].ptr = its_dev;
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index be3c34e..6add8da 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -585,6 +585,10 @@ void handle_fasteoi_irq(struct irq_desc *desc)
> goto out;
> }
>
> +#ifdef CONFIG_CAVIUM_ERRATUM_28168
> + if (chip->irq_ack)
> + chip->irq_ack(&desc->irq_data);
> +#endif
> kstat_incr_irqs_this_cpu(desc);
> if (desc->istate & IRQS_ONESHOT)
> mask_irq(desc);
>
^ permalink raw reply
* [PATCH 4/4] mtk-mdp: fix compilation warnings if !DEBUG
From: Minghsiu Tsai @ 2016-10-24 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a24855fda4d91a58f119c2d70177017e06fc6f0.1477058332.git.mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> The mtk_mdp_dbg() is empty if !DEBUG. This causes the following
> warnings:
>
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function ?mtk_mdp_try_fmt_mplane?:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:231:52: warning: suggest braces around empty body in an ?if? statement [-Wempty-body]
> org_w, org_h, pix_mp->width, pix_mp->height);
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c: In function ?mtk_mdp_m2m_start_streaming?:
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c:414:21: warning: suggest braces around empty body in an ?if? statement [-Wempty-body]
> ctx->id, ret);
> ^
>
> With could actually make the code to do something wrong. So,
> add an empty block to make it be parsed ok.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> index 2e979f97d1df..848569d4ab90 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> @@ -250,7 +250,7 @@ extern int mtk_mdp_dbg_level;
>
> #else
>
> -#define mtk_mdp_dbg(level, fmt, args...)
> +#define mtk_mdp_dbg(level, fmt, args...) {}
>
Acked-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> #define mtk_mdp_err(fmt, args...)
> #define mtk_mdp_dbg_enter()
> #define mtk_mdp_dbg_leave()
^ permalink raw reply
* [PATCH 1/4] mtk_mdp_vpu: fix build with COMPILE_TEST for 32 bits
From: Minghsiu Tsai @ 2016-10-24 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd14afdb178cf490e257368bc899c7a0c690d140.1477058332.git.mchehab@s-opensource.com>
Hi Mauro,
This issue has been fixed by the patch below and merged in media tree,
and also signed by you.
Is it duplicate?
commit 37bf7e34ecc817ce6b8278588aeb22aab5635e1c
Author: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Date: Mon Sep 19 03:34:42 2016 -0300
[media] media: mtk-mdp: fix build warning in arch x86
This patch fix build warning in arch x86
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
On Fri, 2016-10-21 at 11:59 -0200, Mauro Carvalho Chehab wrote:
> When building on i386 in 32 bits, several new warnings appear:
>
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_handle_init_ack':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_ipi_handler':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_send_ap_ipi':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
>
> That's because the driver assumes that it will be built only on
> 64 bits. As we don't want extra warnings when building with 32
> bits, we need to double-cast.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> index fb07bf3dbd8b..b38d29e99f7a 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> @@ -25,7 +25,7 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu)
>
> static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
> {
> - struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> + struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
>
> /* mapping VPU address to kernel virtual address */
> vpu->vsi = (struct mdp_process_vsi *)
> @@ -37,7 +37,7 @@ static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv)
> {
> unsigned int msg_id = *(unsigned int *)data;
> struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
> - struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> + struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)(long)msg->ap_inst;
> struct mtk_mdp_ctx *ctx;
>
> vpu->failure = msg->status;
> @@ -108,7 +108,7 @@ static int mtk_mdp_vpu_send_ap_ipi(struct mtk_mdp_vpu *vpu, uint32_t msg_id)
> msg.msg_id = msg_id;
> msg.ipi_id = IPI_MDP;
> msg.vpu_inst_addr = vpu->inst_addr;
> - msg.ap_inst = (uint64_t)vpu;
> + msg.ap_inst = (uint64_t)(long)vpu;
> err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
> if (!err && vpu->failure)
> err = -EINVAL;
> @@ -126,7 +126,7 @@ int mtk_mdp_vpu_init(struct mtk_mdp_vpu *vpu)
>
> msg.msg_id = AP_MDP_INIT;
> msg.ipi_id = IPI_MDP;
> - msg.ap_inst = (uint64_t)vpu;
> + msg.ap_inst = (uint64_t)(long)vpu;
> err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
> if (!err && vpu->failure)
> err = -EINVAL;
^ permalink raw reply
* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Mark Rutland @ 2016-10-24 11:16 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:
> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
> + QorIQ erratum 161201, which says that reading the counter is
> + 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.
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard? Please
use the *exact* erratum number, even if that means we have to list
several.
Is "161x01" an *erratum* number, or the *part* number of affected
devices?
Thanks,
Mark.
^ permalink raw reply
* Question about arm64 earlycon
From: Mark Rutland @ 2016-10-24 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f1eeb4a-925a-9fac-d442-fbee503deb0a@arm.com>
On Mon, Oct 24, 2016 at 11:17:36AM +0100, Marc Zyngier wrote:
> On 24/10/16 11:06, Arnd Bergmann wrote:
> > On Sunday, October 23, 2016 12:26:59 AM CEST Duc Dang wrote:
> >> 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:
What exactly are you passing on the command line?
> >> <some garbage characters here>01c020000.serial: ttyS0 at MMIO
> >> 0x1c020000 (irq = 108, base_baud = 3125000) is a U6_16550A
> >> console [ttyS0] enabled, bootconsole disabled
Was the UART already configured by FW? Had the firmware output anything
at this point?
Did the firmware's UART rate match that of the kernel? If not, the issue
might just be that the rate doesn't match; earlycon/earlyprintk won't
configure that, while the real console will.
Or perhaps we race with some clock configuration...
> >> 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.
> >
> > I don't think we every supported earlyprintk on arm64, and
> > earlycon support may have been added later.
>
> We did support some form of earlyprintk for a while (though not in the
> same way as 32bit ARM does), until Rob introduced earlycon.
Our earlyprintk up until that point was effectively a less general
earlycon (coming up at a similar time). In fact, in v3.12 we were
already using earlycon structures in arch/arm64/kernel/early_printk.c.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent
From: Joerg Roedel @ 2016-10-24 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150916.0d274e9f@lwn.net>
On Fri, Oct 21, 2016 at 03:09:16PM -0600, Jonathan Corbet wrote:
> On Mon, 17 Oct 2016 16:26:23 +0100
> Punit Agrawal <punit.agrawal@arm.com> wrote:
>
> > The dma mapping api howto gives the impression that using the
> > dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel
> > to check all the components in the path from the device to memory for
> > addressing restrictions. In systems with address translations between
> > the device and memory (e.g., when using IOMMU), this implies that a
> > successful call to set set dma mask has checked the addressing
> > constraints of the intermediaries as well.
This is basically true when you have DMA controllers in the path from
device to memory. But it is not true for IOMMUs, because IOMMU drivers
are consumers of the dma-masks, they don't really restrict them. An
IOMMU driver knows the limitations of IOMMU hardware and counts that in
when allocating an address for a dma-buffer.
So long story short: Any IOMMU restrictions in address space size don't
need to be represented in the dma-mask for a device.
Joerg
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: okaya at codeaurora.org @ 2016-10-24 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VettN=-S+iqKQbqixRe2BM=AiS26VGM+8yLophbkc+Z8g@mail.gmail.com>
On 2016-10-24 03:30, Andy Shevchenko wrote:
> On Mon, Oct 24, 2016 at 5:55 AM, Sinan Kaya <okaya@codeaurora.org>
> wrote:
>> On 10/21/2016 12:11 PM, Andy Shevchenko wrote:
>>>> +static void hidma_free_msis(struct hidma_dev *dmadev)
>>>> > +{
>>>> > +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
>>> Perhaps one #ifdef and two definitions of functions?
>>
>> I don't think it will make a difference. I'll have to move
>> #ifdef around the caller of hidma_free_msis instead which
>> I think is uglier.
>>
>> The hidma_write_msi_msg function gets called only when
>> CONFIG_GENERIC_MSI_IRQ_DOMAIN is defined. If I don't put
>> this around the function definition, I get unused function
>> warning from the compiler. This is the reason why preprocessor
>> definition is outside of the function definition.
>
> I am talking about something like below:
>
> #ifdef UGLY_DEFINE
> myfunc_a()
> {
> }
>
> myfunc_b()
> {
> }
> #else
> static inline myfunc_a() {}
> static inline myfunc_b() {}
> #endif
>
>
> There is another way as well, namely use of IS_ENABLED(), IS_BUILTIN()
> macros (I don't remember how exactly second one is spelt).
This was my initial approach. I was asked to remove the stub functions.
So, I did it.
^ 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