* [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
From: Geert Uytterhoeven @ 2017-12-19 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513619528-12060-4-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 6:52 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add the definitions for pwm[0123456] to the SoC .dtsi.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r8a7743.dtsi
> +++ b/arch/arm/boot/dts/r8a7743.dtsi
> @@ -1082,6 +1082,83 @@
> status = "disabled";
> };
>
> + pwm0: pwm at e6e30000 {
> + compatible = "renesas,pwm-r8a7743",
> + "renesas,pwm-rcar";
I think the above can fit in one line.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: r8a7745: Add PWM SoC support
From: Geert Uytterhoeven @ 2017-12-19 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513620411-17478-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 7:06 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add the definitions for pwm[0123456] to the SoC .dtsi.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r8a7745.dtsi
> +++ b/arch/arm/boot/dts/r8a7745.dtsi
> @@ -968,6 +968,83 @@
> status = "disabled";
> };
>
> + pwm0: pwm at e6e30000 {
> + compatible = "renesas,pwm-r8a7745",
> + "renesas,pwm-rcar";
I think this can fit on one line.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Linux Kernel handling AXI DECERR/SLVERR
From: Bharat Kumar Gogada @ 2017-12-19 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219104500.5otagp7m7dqretd2@lakrids.cambridge.arm.com>
Hi,
> When Linux is booted on ARM64 platform and an access to peripheral
> returns DECERR or SLVERR on AXI.
>
> In the above error cases how would Linux kernel handle these faults ?
> Will it hang/recover ?
I believe that on contemporary CPUs these will result in an SError. As SErrors are asynchronous, and (in the absence of RAS extensions) their cause cannot be determined, these are treated as fatal, and the kernel will panic().
Thanks, Mark.
In our case the peripheral returns SLVERR first time and we see the following print but kernel do not hang.
[ 231.484186] Unhandled fault: synchronous external abort (0x92000210) at 0x0000007f9241f880
Bus error
And from simulation we know that subsequent access to peripheral returns OKAY response, however we
see subsequent access fail with same above bus error when we boot Linux.
Is there a way to handle these synchronous abort gracefully in Linux or are these fatal ?
Regards,
Bharat
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-19 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513679029-5915-1-git-send-email-vladimir.murzin@arm.com>
Hi,
On Tue, Dec 19, 2017 at 10:23:49AM +0000, Vladimir Murzin wrote:
> With switch to dynamic exception base address setting, VBAR/Hivecs
> set only for boot CPU, but secondaries stay unaware of that. That
> might lead to weird effects when trying up to bring up secondaries.
>
> Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
Sorry, it was my incompetence not seeing the secondary CPU's case.
Was the issue observed on Cortex-R ?, and was it occuring with
CONFIG_CPU_HIGH_VECTOR enabled or disabled ?
Instead of,
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> +#ifndef CONFIG_MMU
> +extern unsigned long setup_vectors_base(void);
> +#else
> +static inline unsigned long setup_vectors_base(void)
> +{
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> + setup_vectors_base();
how about,
if (!IS_ENABLED(CONFIG_MMU))
setup_vectors_base();
That would avoid #ifdef's. Also as w/ MMU, vector base is not setup
(always Hivecs), this would make clear that setup_vectors_base() is
non-existent on MMU on.
Thanks for the fix.
afzal
^ permalink raw reply
* [PATCH v2 6/6] ARM: dts: r8a7743: Add TPU support
From: Geert Uytterhoeven @ 2017-12-19 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513619528-12060-7-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 6:52 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add TPU support to SoC DT.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: r8a7745: Add TPU support
From: Geert Uytterhoeven @ 2017-12-19 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513620411-17478-5-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 7:06 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add TPU support to SoC DT.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
From: Fabrizio Castro @ 2017-12-19 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVEgBq+eZqAeas3kf3ARHegSQK9xyVrTDHRyctyTK87QQ@mail.gmail.com>
Hello Geert,
> Subject: Re: [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
>
> On Mon, Dec 18, 2017 at 6:52 PM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Add the definitions for pwm[0123456] to the SoC .dtsi.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> > @@ -1082,6 +1082,83 @@
> > status = "disabled";
> > };
> >
> > + pwm0: pwm at e6e30000 {
> > + compatible = "renesas,pwm-r8a7743",
> > + "renesas,pwm-rcar";
>
> I think the above can fit in one line.
do you think this deserves a v3?
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: r8a7745: Add PWM SoC support
From: Fabrizio Castro @ 2017-12-19 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUi953N1J+vfJWJo0GMKO4tBZV9HnX7haG0fvyNHfOvOA@mail.gmail.com>
Hello Geert,
> Subject: Re: [PATCH v2 2/4] ARM: dts: r8a7745: Add PWM SoC support
>
> On Mon, Dec 18, 2017 at 7:06 PM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > Add the definitions for pwm[0123456] to the SoC .dtsi.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > --- a/arch/arm/boot/dts/r8a7745.dtsi
> > +++ b/arch/arm/boot/dts/r8a7745.dtsi
> > @@ -968,6 +968,83 @@
> > status = "disabled";
> > };
> >
> > + pwm0: pwm at e6e30000 {
> > + compatible = "renesas,pwm-r8a7745",
> > + "renesas,pwm-rcar";
>
> I think this can fit on one line.
do you think this deserves a v3?
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Linux Kernel handling AXI DECERR/SLVERR
From: Mark Rutland @ 2017-12-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BLUPR0201MB150517EAFAF3A46B8A19489CA50F0@BLUPR0201MB1505.namprd02.prod.outlook.com>
On Tue, Dec 19, 2017 at 11:28:49AM +0000, Bharat Kumar Gogada wrote:
> In our case the peripheral returns SLVERR first time and we see the following print but kernel do not hang.
> [ 231.484186] Unhandled fault: synchronous external abort (0x92000210) at 0x0000007f9241f880
> Bus error
>
> And from simulation we know that subsequent access to peripheral
> returns OKAY response, however we see subsequent access fail with same
> above bus error when we boot Linux.
>
> Is there a way to handle these synchronous abort gracefully in Linux
> or are these fatal ?
We don't currently have any mechanism to handle these, though it might
be possible for synchronous aborts.
Do you know why the device is returning SLVERR in this case?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it
From: Marc Zyngier @ 2017-12-19 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5842af4d-8dc0-d7bf-8eef-991656b71f49@samsung.com>
On 19/12/17 07:55, Andrzej Hajda wrote:
> On 18.12.2017 12:28, Marc Zyngier wrote:
>> Stopping the X display manager on a kevin platform results in the
>> following crash:
>>
>> [ 674.833536] Synchronous External Abort: synchronous external abort (0x96000010) at 0xffff00000c970640
>> [ 674.843886] Internal error: : 96000010 [#1] PREEMPT SMP
>> [ 674.849744] Modules linked in:
>> [ 674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
>> [ 674.849760] detected fb_set_par error, error code: -16
>> [ 674.849761] Hardware name: Google Kevin (DT)
>> [ 674.849773] Workqueue: events analogix_dp_psr_work
>> [ 674.849778] pstate: 60000005 (nZCv daif -PAN -UAO)
>> [ 674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
>> [ 674.849788] lr : analogix_dp_enable_psr+0x54/0x60
>> [ 674.849789] sp : ffff000009b2bd60
>> [ 674.849790] x29: ffff000009b2bd60 x28: 0000000000000000
>> [ 674.849794] x27: ffff000009913d20 x26: ffff00000900fbf0
>> [ 674.849797] x25: ffff8000f1b30000 x24: ffff8000f0c21d98
>> [ 674.849800] x23: 0000000000000000 x22: ffff8000f7d3aa00
>> [ 674.849803] x21: ffff8000f7d36980 x20: ffff8000f0c21c18
>> [ 674.849806] x19: ffff8000f0c21db8 x18: 0000000000000001
>> [ 674.849809] x17: 0000ffff89f2ed58 x16: ffff000008222908
>> [ 674.849812] x15: 0000000000000000 x14: 0000000000000400
>> [ 674.849815] x13: 0000000000000400 x12: 0000000000000000
>> [ 674.849817] x11: 0000000000001414 x10: 0000000000000a00
>> [ 674.849820] x9 : ffff000009b2bbb0 x8 : ffff8000f1b30a60
>> [ 674.849823] x7 : 0000000000080000 x6 : 0000000000000001
>> [ 674.849826] x5 : 0000000000000010 x4 : 0000000000000007
>> [ 674.849829] x3 : 0000000000000002 x2 : ffff00000c970640
>> [ 674.849832] x1 : ffff000009b2bd78 x0 : ffff8000f1624018
>> [ 674.849836] Process kworker/1:1 (pid: 86, stack limit = 0x0000000083e5f7c3)
>> [ 674.849838] Call trace:
>> [ 674.849842] analogix_dp_send_psr_spd+0x8/0x168
>> [ 674.849844] analogix_dp_psr_work+0x9c/0xa0
>> [ 674.849849] process_one_work+0x1cc/0x328
>> [ 674.849852] worker_thread+0x50/0x450
>> [ 674.849856] kthread+0xf8/0x128
>> [ 674.849860] ret_from_fork+0x10/0x18
>> [ 674.849864] Code: b9000001 d65f03c0 f9445802 91190042 (b9400042)
>>
>> Further investigation show that this happens because the the workqueue
>> races with the analogix_dp_bridge_disable() call from the core DRM code,
>> and end up trying to write to the DP bridge that has already been powered
>> down. This result is a very black screen, and a hard reset.
>>
>> Instead of counting on luck to keep the bridge alive, let's use the
>> pm_runtime framework and take a reference on the device when we're about
>> to poke it. That is a fairly big hammer, but one that allows the system
>> to stay alive across dozens of X start/stop sequences.
>
> Wouldn't be better to cancel the work in analogix_dp_bridge_disable, it
> looks safer.
Not sure. That would only cancel a single work that would be in flight
right when we hit disable, but won't prevent the work from being queued
right after the cancel.
In summary, I think you're trading a race between pm_runtime_put_sync
and analogix_dp_send_psr_spd for another between cancel_work_sync and
analogix_dp_send_psr_spd. Also, I seem to remember that the disable can
occur in its own work queue:
commit_tail -> drm_atomic_helper_commit_modeset_disables ->
disable_outputs -> drm_bridge_disable -> analogix_dp_bridge_disable
making it racy by nature. But I'm no DRM expert (as you can probably tell).
My approach is to guarantee that analogix_dp_send_psr_spd cannot fault
due to the IP being powered off, which feels a bit more bullet proof.
Please shoot me down if I got it wrong!
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI
From: Sakari Ailus @ 2017-12-19 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1501131697-1359-4-git-send-email-yong.deng@magewell.com>
On Thu, Jul 27, 2017 at 01:01:37PM +0800, Yong Deng wrote:
> Signed-off-by: Yong Deng <yong.deng@magewell.com>
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9826a91..b91fa27 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3686,6 +3686,14 @@ M: Jaya Kumar <jayakumar.alsa@gmail.com>
> S: Maintained
> F: sound/pci/cs5535audio/
>
> +CSI DRIVERS FOR ALLWINNER V3s
> +M: Yong Deng <yong.deng@magewell.com>
> +L: linux-media at vger.kernel.org
> +T: git git://linuxtv.org/media_tree.git
> +S: Maintained
> +F: drivers/media/platform/sun6i-csi/
> +F: Documentation/devicetree/bindings/media/sun6i-csi.txt
> +
> CW1200 WLAN driver
> M: Solomon Peachy <pizza@shaftnet.org>
> S: Maintained
Please squash to the driver patch. Thanks.
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
From: Geert Uytterhoeven @ 2017-12-19 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB089542724CCC3530DD4677F5C00F0@TY1PR06MB0895.apcprd06.prod.outlook.com>
Hi Fabrizio,
On Tue, Dec 19, 2017 at 12:37 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
>> Subject: Re: [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
>>
>> On Mon, Dec 18, 2017 at 6:52 PM, Fabrizio Castro
>> <fabrizio.castro@bp.renesas.com> wrote:
>> > Add the definitions for pwm[0123456] to the SoC .dtsi.
>> >
>> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
>> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> > --- a/arch/arm/boot/dts/r8a7743.dtsi
>> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
>> > @@ -1082,6 +1082,83 @@
>> > status = "disabled";
>> > };
>> >
>> > + pwm0: pwm at e6e30000 {
>> > + compatible = "renesas,pwm-r8a7743",
>> > + "renesas,pwm-rcar";
>>
>> I think the above can fit in one line.
>
> do you think this deserves a v3?
That depends on the fuzziness-acceptance level of Simon...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Sakari Ailus @ 2017-12-19 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1501131697-1359-3-git-send-email-yong.deng@magewell.com>
Hi Yong,
On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
>
> Signed-off-by: Yong Deng <yong.deng@magewell.com>
DT bindings should precede the driver.
> ---
> .../devicetree/bindings/media/sun6i-csi.txt | 49 ++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> new file mode 100644
> index 0000000..f8d83f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> @@ -0,0 +1,49 @@
> +Allwinner V3s Camera Sensor Interface
> +------------------------------
> +
> +Required properties:
> + - compatible: value must be "allwinner,sun8i-v3s-csi"
What are sun6i and sun8i? Is this device first present in sun6i SoCs,
whereas you have only defined bindings for sun8i?
> + - reg: base address and size of the memory-mapped region.
> + - interrupts: interrupt associated to this IP
> + - clocks: phandles to the clocks feeding the CSI
> + * ahb: the CSI interface clock
> + * mod: the CSI module clock
> + * ram: the CSI DRAM clock
> + - clock-names: the clock names mentioned above
> + - resets: phandles to the reset line driving the CSI
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
Please document mandatory and optional endpoint properties relevant for the
hardware.
> +
> +Example:
> +
> + csi1: csi at 01cb4000 {
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb4000 0x1000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI1_SCLK>,
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "ahb", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Parallel bus endpoint */
> + csi1_ep: endpoint {
> + remote-endpoint = <&adv7611_ep>;
> + bus-width = <16>;
> + data-shift = <0>;
> +
> + /* If hsync-active/vsync-active are missing,
> + embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>; /* Active high */
> + pclk-sample = <1>; /* Rising */
> + };
> + };
> + };
> +
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Wenyou.Yang at microchip.com @ 2017-12-19 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219092246.3usg5mdyi27ivqlq@valkosipuli.retiisi.org.uk>
Hi Sakari,
> -----Original Message-----
> From: Sakari Ailus [mailto:sakari.ailus at iki.fi]
> Sent: 2017?12?19? 17:23
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; linux-
> kernel at vger.kernel.org; Nicolas Ferre - M43238 <Nicolas.Ferre@microchip.com>;
> devicetree at vger.kernel.org; Jonathan Corbet <corbet@lwn.net>; Hans Verkuil
> <hverkuil@xs4all.nl>; linux-arm-kernel at lists.infradead.org; Linux Media Mailing List
> <linux-media@vger.kernel.org>; Songjun Wu <songjun.wu@microchip.com>
> Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
>
> On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> > The ov7740 (color) image sensor is a high performance VGA CMOS image
> > snesor, which supports for output formats: RAW RGB and YUV and image
> > sizes: VGA, and QVGA, CIF and any size smaller.
> >
> > Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> > Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
>
> Applied with this diff:
Thank you very much.
>
> diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c index
> 0308ba437bbb..041a77039d70 100644
> --- a/drivers/media/i2c/ov7740.c
> +++ b/drivers/media/i2c/ov7740.c
> @@ -1,5 +1,7 @@
> -// SPDX-License-Identifier: GPL-2.0
> -// Copyright (c) 2017 Microchip Corporation.
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2017 Microchip Corporation.
> + */
>
> #include <linux/clk.h>
> #include <linux/delay.h>
>
> --
> Sakari Ailus
> e-mail: sakari.ailus at iki.fi
Best Regards,
Wenyou Yang
^ permalink raw reply
* [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
From: Fabrizio Castro @ 2017-12-19 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVb6jpF_HbJMapFTJs285_GOdXVPsACHBasy5Cy5ZZ18g@mail.gmail.com>
Hello Geert,
> Subject: Re: [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
>
> Hi Fabrizio,
>
> On Tue, Dec 19, 2017 at 12:37 PM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> >> Subject: Re: [PATCH v2 3/6] ARM: dts: r8a7743: Add PWM SoC support
> >>
> >> On Mon, Dec 18, 2017 at 6:52 PM, Fabrizio Castro
> >> <fabrizio.castro@bp.renesas.com> wrote:
> >> > Add the definitions for pwm[0123456] to the SoC .dtsi.
> >> >
> >> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> >> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >>
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>
> >> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> >> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> >> > @@ -1082,6 +1082,83 @@
> >> > status = "disabled";
> >> > };
> >> >
> >> > + pwm0: pwm at e6e30000 {
> >> > + compatible = "renesas,pwm-r8a7743",
> >> > + "renesas,pwm-rcar";
> >>
> >> I think the above can fit in one line.
> >
> > do you think this deserves a v3?
>
> That depends on the fuzziness-acceptance level of Simon...
I'll send a v3 then.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Marc Zyngier @ 2017-12-19 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219065524.GB13415@virtx40>
On 19/12/17 06:55, Linu Cherian wrote:
> Hi Marc,
>
> On Mon Dec 18, 2017 at 03:39:22PM +0000, Marc Zyngier wrote:
>> Thanks for putting me in the loop Robin.
>>
>> On 18/12/17 14:48, Robin Murphy wrote:
>>> On 10/12/17 02:35, Linu Cherian wrote:
>>>> Hi,
>>>>
>>>>
>>>> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
>>>>> This adds a driver for the SMMUv3 PMU into the perf framework.
>>>>> It includes an IORT update to support PM Counter Groups.
>>>>>
>>>>
>>>> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
>>>> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
>>>> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
>>>> are managed by two independent drivers.
>>>>
>>>> The problem arises when we want to alloc/free MSIs for these devices
>>>> using the APIs, platform_msi_domain_alloc/free_irqs.
>>>> Platform bus id being same for these two hardware blocks, they end up sharing the same
>>>> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
>>>> of this shared ITT becomes a problem when they are managed by two independent
>>>> drivers.
>>>
>>> What is the problem exactly? IIRC resizing a possibly-live ITT is a
>>> right pain in the bum to do - is it just that?
>>
>> Understatement of the day! ;-) Yes, it is a massive headache, and will
>> either result in a temporary loss of interrupts (at some point you have
>> to unmap the ITT), or with spurious interrupts (you generate interrupts
>> for all the MSIs you've blackholed when unmapping the ITT).
>
> Just sharing a thought.
>
> If the firmware, through device tree/ACPI
> can provide the following input to the ITS driver,
> (For example, as part of msi-parent property in device tree)
>
> 1. flag indicating the ITT (Device ID) is being shared
> 2. the maximum number of vectors that are required to be allocated for this ITT
>
> resizing of ITT and the associated complexities could be avoided.
I'm not sure it is that simple.
First, this is a change of the spec, and we need to support the current
states of ACPI and DT. In any case, this would need to affect all nodes.
Then, MSIs are very dynamic, and there may be decision that SW makes at
runtime that would change the parameters of the ITT allocation
(platform_msi_domain_alloc_irqs does take an nvec parameter that could
override firmware data -- what if all the drivers do that?).
Finally, and assuming we still want to go in that direction, I'd rather
have each node describing its maximum MSI allocation and let the ITS
driver sum it up, much like we do it on PCI.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513680330.7000.167.camel@linux.intel.com>
On 12/19/2017 5:45 AM, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 00:37 -0500, Sinan Kaya wrote:
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>>
>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>> pci_get_domain_bus_and_slot().
>>
>
> Where this idea come from?
There are systems out (mostly ARM) there with non-zero segment numbers. The
pci_get_bus_and_slot() API is restrictive and unnecessarily forces 0 segment
numbers for some generic device drivers. Obtaining the segment number is as
easy as calling pci_domain_nr().
The problems with pci_get_bus_and_slot() are:
1. we don't know if the device driver intentionally called pci_get_bus_and_slot()
to limit 0 segment number.
2. we don't know if the driver developer just copied an example from another
system and it just happened to work on x86 architecture while broken on other
architectures.
Some device drivers may want to limit the segment number. Than specifying 0
while calling pci_get_domain_bus_and_slot() is a better way to express this.
pci_get_bus_and_slot() is unnecessarily restricting some device drivers. Nvidia
as an example. I remember that somebody came up with a very ugly patch to force
segment 0 into Microsoft hypervisor layer.
This was rejected out right and told to fix the Nvidia driver instead. This patch
essentially fixes some of these flaws while removing the limiting API from the
kernel altogether so that same mistakes are not made.
>
> pci_get_bus_and_slot() still might be useful for the wired devices in
> SoC where we know for sure that domain == 0.
>
Then hard code the domain number as 0 while calling pci_get_domain_bus_and_slot()
if you know for sure that this device will never work on a non-zero domain.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 02/26] powerpc/PCI: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fu879fki.fsf@concordia.ellerman.id.au>
On 12/19/2017 5:29 AM, Michael Ellerman wrote:
> Sinan Kaya <okaya@codeaurora.org> writes:
>
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>>
>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>> pci_get_domain_bus_and_slot().
>>
>> Use pci_get_domain_bus_and_slot() with a domain number of 0 as the code
>> is not ready to consume multiple domains and existing code used domain
>> number 0.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> arch/powerpc/kernel/pci_32.c | 3 ++-
>> arch/powerpc/platforms/powermac/feature.c | 2 +-
>> arch/powerpc/sysdev/mv64x60_pci.c | 4 ++--
>> 3 files changed, 5 insertions(+), 4 deletions(-)
>
> Looks to do what it says. I don't know if any of these call sites could
> be improved to provide the domain, but that's not really your problem.
>
I tried to fix the places where I can at the rest of the series. I even took
a stab at fixing powerpc. There were places where the domain information was
not available and I couldn't locate where to extract it. I decided to leave it
as it is and hope that someone someday may expand the powerpc PCI adaptation.
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
>
> cheers
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Fabio Estevam @ 2017-12-19 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219092246.3usg5mdyi27ivqlq@valkosipuli.retiisi.org.uk>
Hi Sakari,
On Tue, Dec 19, 2017 at 7:22 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
>> The ov7740 (color) image sensor is a high performance VGA CMOS
>> image snesor, which supports for output formats: RAW RGB and YUV
>> and image sizes: VGA, and QVGA, CIF and any size smaller.
>>
>> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
>> Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
>
> Applied with this diff:
>
> diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
> index 0308ba437bbb..041a77039d70 100644
> --- a/drivers/media/i2c/ov7740.c
> +++ b/drivers/media/i2c/ov7740.c
> @@ -1,5 +1,7 @@
> -// SPDX-License-Identifier: GPL-2.0
> -// Copyright (c) 2017 Microchip Corporation.
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2017 Microchip Corporation.
> + */
The original version is the recommended format for the SPDX identifier.
^ permalink raw reply
* [PATCH v3 05/19] arm64: alternatives: Add dynamic patching feature
From: Steve Capper @ 2017-12-19 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-6-marc.zyngier@arm.com>
Hi Marc,
On Mon, Dec 18, 2017 at 05:39:12PM +0000, Marc Zyngier wrote:
> We've so far relied on a patching infrastructure that only gave us
> a single alternative, without any way to finely control what gets
> patched. For a single feature, this is an all or nothing thing.
>
> It would be interesting to have a more fine grained way of patching
> the kernel though, where we could dynamically tune the code that gets
> injected.
>
> In order to achive this, let's introduce a new form of alternative
> that is associated with a callback. This callback gets the instruction
> sequence number and the old instruction as a parameter, and returns
> the new instruction. This callback is always called, as the patching
> decision is now done at runtime (not patching is equivalent to returning
> the same instruction).
>
> Patching with a callback is declared with the new ALTERNATIVE_CB
> and alternative_cb directives:
>
> asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
> : "r" (v));
> or
> alternative_cb callback
> mov x0, #0
> alternative_cb_end
>
> where callback is the C function computing the alternative.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/alternative.h | 36 ++++++++++++++++++++++++++----
> arch/arm64/include/asm/alternative_types.h | 3 +++
> arch/arm64/kernel/alternative.c | 21 +++++++++++++----
> 3 files changed, 52 insertions(+), 8 deletions(-)
>
[...]
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index 6dd0a3a3e5c9..cd299af96c95 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -110,25 +110,38 @@ static void __apply_alternatives(void *alt_region, bool use_linear_alias)
> struct alt_instr *alt;
> struct alt_region *region = alt_region;
> __le32 *origptr, *replptr, *updptr;
> + alternative_cb_t alt_cb;
>
> for (alt = region->begin; alt < region->end; alt++) {
> u32 insn;
> int i, nr_inst;
>
> - if (!cpus_have_cap(alt->cpufeature))
> + /* Use ARM64_NCAPS as an unconditional patch */
> + if (alt->cpufeature < ARM64_NCAPS &&
> + !cpus_have_cap(alt->cpufeature))
> continue;
>
> - BUG_ON(alt->alt_len != alt->orig_len);
> + if (alt->cpufeature == ARM64_NCAPS)
> + BUG_ON(alt->alt_len != 0);
> + else
> + BUG_ON(alt->alt_len != alt->orig_len);
>
> pr_info_once("patching kernel code\n");
>
> origptr = ALT_ORIG_PTR(alt);
> replptr = ALT_REPL_PTR(alt);
> + alt_cb = ALT_REPL_PTR(alt);
> updptr = use_linear_alias ? lm_alias(origptr) : origptr;
> - nr_inst = alt->alt_len / sizeof(insn);
> + nr_inst = alt->orig_len / sizeof(insn);
>
> for (i = 0; i < nr_inst; i++) {
> - insn = get_alt_insn(alt, origptr + i, replptr + i);
> + if (alt->cpufeature == ARM64_NCAPS) {
> + insn = le32_to_cpu(updptr[i]);
> + insn = alt_cb(alt, i, insn);
> + } else {
> + insn = get_alt_insn(alt, origptr + i,
> + replptr + i);
> + }
> updptr[i] = cpu_to_le32(insn);
> }
Is it possible to call the callback only once per entry (rather than
once per instruction)? That would allow one to retain some more
execution state in the callback, which may be handy if things get more
elaborate.
Cheers,
--
Steve
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Sakari Ailus @ 2017-12-19 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BHSJv01SwZ2YNtGZTjMtOuOktET43qriK2fQ+jhE2TDA@mail.gmail.com>
On Tue, Dec 19, 2017 at 10:50:44AM -0200, Fabio Estevam wrote:
> Hi Sakari,
>
> On Tue, Dec 19, 2017 at 7:22 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> > On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> >> The ov7740 (color) image sensor is a high performance VGA CMOS
> >> image snesor, which supports for output formats: RAW RGB and YUV
> >> and image sizes: VGA, and QVGA, CIF and any size smaller.
> >>
> >> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> >> Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
> >
> > Applied with this diff:
> >
> > diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
> > index 0308ba437bbb..041a77039d70 100644
> > --- a/drivers/media/i2c/ov7740.c
> > +++ b/drivers/media/i2c/ov7740.c
> > @@ -1,5 +1,7 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -// Copyright (c) 2017 Microchip Corporation.
> > +/*
> > + * SPDX-License-Identifier: GPL-2.0
> > + * Copyright (c) 2017 Microchip Corporation.
> > + */
>
> The original version is the recommended format for the SPDX identifier.
I guess it depends on who do you ask and when. Looking at what has been
recently merged to media tree master, the latter is preferred.
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Ard Biesheuvel @ 2017-12-19 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219060927.GH28046@linaro.org>
On 19 December 2017 at 07:09, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
>> > > <takahiro.akashi@linaro.org> wrote:
>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
>> > > >> <takahiro.akashi@linaro.org> wrote:
>> > > >> > Bhupesh, Ard,
>> > > >> >
>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>> > > >> >> Hi Ard, Akashi
>> > > >> >>
>> > > >> > (snip)
>> > > >> >
>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>> > > >> >> identify its own usable memory and exclude, at its boot time, any
>> > > >> >> other memory areas that are part of the panicked kernel's memory.
>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>> > > >> >> , for details)
>> > > >> >
>> > > >> > Right.
>> > > >> >
>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>> > > >> >> with the crashkernel memory range:
>> > > >> >>
>> > > >> >> /* add linux,usable-memory-range */
>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>> > > >> >> address_cells, size_cells);
>> > > >> >>
>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>> > > >> >> , for details)
>> > > >> >>
>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>> > > >> >> they are marked as System RAM or as RESERVED. As,
>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>> > > >> >>
>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
>> > > >> >> ACPI memory and crashes while trying to access the same:
>> > > >> >>
>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>> > > >> >> -r`.img --reuse-cmdline -d
>> > > >> >>
>> > > >> >> [snip..]
>> > > >> >>
>> > > >> >> Reserved memory range
>> > > >> >> 000000000e800000-000000002e7fffff (0)
>> > > >> >>
>> > > >> >> Coredump memory ranges
>> > > >> >> 0000000000000000-000000000e7fffff (0)
>> > > >> >> 000000002e800000-000000003961ffff (0)
>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
>> > > >> >> 000000003ed60000-000000003fbfffff (0)
>> > > >> >> 0000001040000000-0000001ffbffffff (0)
>> > > >> >> 0000002000000000-0000002ffbffffff (0)
>> > > >> >> 0000009000000000-0000009ffbffffff (0)
>> > > >> >> 000000a000000000-000000affbffffff (0)
>> > > >> >>
>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>> > > >> >> memory cap'ing passed to the crash kernel inside
>> > > >> >> 'arch/arm64/mm/init.c' (see below):
>> > > >> >>
>> > > >> >> static void __init fdt_enforce_memory_region(void)
>> > > >> >> {
>> > > >> >> struct memblock_region reg = {
>> > > >> >> .size = 0,
>> > > >> >> };
>> > > >> >>
>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> > > >> >>
>> > > >> >> if (reg.size)
>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>> > > >> >> comment this out */
>> > > >> >> }
>> > > >> >
>> > > >> > Please just don't do that. It can cause a fatal damage on
>> > > >> > memory contents of the *crashed* kernel.
>> > > >> >
>> > > >> >> 5). Both the above temporary solutions fix the problem.
>> > > >> >>
>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>> > > >> >> fail.
>> > > >> >>
>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>> > > >> >> dt node 'linux,usable-memory-range'
>> > > >> >
>> > > >> > I still don't understand why we need to carry over the information
>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>> > > >> > such regions are free to be reused by the kernel after some point of
>> > > >> > initialization. Why does crash dump kernel need to know about them?
>> > > >> >
>> > > >>
>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
>> > > >> kernel, those regions needs to be preserved, which is why they are
>> > > >> memblock_reserve()'d now.
>> > > >
>> > > > For my better understandings, who is actually accessing such regions
>> > > > during boot time, uefi itself or efistub?
>> > > >
>> > >
>> > > No, only the kernel. This is where the ACPI tables are stored. For
>> > > instance, on QEMU we have
>> > >
>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>> > > 01000013)
>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>> > > BXPC 00000001)
>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>> > > BXPC 00000001)
>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>> > > BXPC 00000001)
>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>> > > BXPC 00000001)
>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>> > > BXPC 00000001)
>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>> > > BXPC 00000001)
>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>> > > BXPC 00000001)
>> > >
>> > > covered by
>> > >
>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>> > > ...
>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>> >
>> > OK. I mistakenly understood those regions could be freed after exiting
>> > UEFI boot services.
>> >
>> > >
>> > > >> So it seems that kexec does not honour the memblock_reserve() table
>> > > >> when booting the next kernel.
>> > > >
>> > > > not really.
>> > > >
>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
>> > > >> > on crash dump kernel?)
>> > > >> >
>> > > >>
>> > > >> I don't think so. And the change to the handling of ACPI reclaim
>> > > >> regions only revealed the bug, not created it (given that other
>> > > >> memblock_reserve regions may be affected as well)
>> > > >
>> > > > As whether we should honor such reserved regions over kexec'ing
>> > > > depends on each one's specific nature, we will have to take care one-by-one.
>> > > > As a matter of fact, no information about "reserved" memblocks is
>> > > > exposed to user space (via proc/iomem).
>> > > >
>> > >
>> > > That is why I suggested (somewhere in this thread?) to not expose them
>> > > as 'System RAM'. Do you think that could solve this?
>> >
>> > Memblock-reserv'ing them is necessary to prevent their corruption and
>> > marking them under another name in /proc/iomem would also be good in order
>> > not to allocate them as part of crash kernel's memory.
>> >
>> > But I'm not still convinced that we should export them in useable-
>> > memory-range to crash dump kernel. They will be accessed through
>> > acpi_os_map_memory() and so won't be required to be part of system ram
>> > (or memblocks), I guess.
>> > -> Bhupesh?
>>
>> I forgot how arm64 kernel retrieve the memory ranges and initialize
>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
>> the memory according to the efi memmap? For kdump kernel anything other
>> than usable memory (which is from the dt node instead) should be
>> reinitialized according to efi passed info, no?
>
> All the regions exported in efi memmap will be added to memblock.memory
> in (u)efi_init() and then trimmed down to the exact range specified as
> usable-memory-range by fdt_enforce_memory_region().
>
> Now I noticed that the current fdt_enforce_memory_region() may not work well
> with multiple entries in usable-memory-range.
>
In any case, the root of the problem is that memory regions lose their
'memory' annotation due to the way the memory map is mangled before
being supplied to the kexec kernel.
Would it be possible to classify all memory that we want to hide from
the kexec kernel as NOMAP instead? That way, it will not be mapped
implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
so this seems to be the most appropriate way to deal with the host
kernel's memory contents.
>> >
>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> > via a kernel command line parameter, "memmap=".
>>
>> memmap= is only used in old kexec-tools, now we are passing them via
>> e820 table.
>
> Thanks. I remember that you have explained it before.
>
> -Takahiro AKASHI
>
>> [snip]
>>
>> Thanks
>> Dave
^ permalink raw reply
* [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Fabio Estevam @ 2017-12-19 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219130537.2viv4wjcp4i3mdkj@valkosipuli.retiisi.org.uk>
Hi Sakari,
On Tue, Dec 19, 2017 at 11:05 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> I guess it depends on who do you ask and when. Looking at what has been
> recently merged to media tree master, the latter is preferred.
Just did 'git grep SPDX drivers/media'
and it consistently shows // SPDX style for C files.
^ permalink raw reply
* [PATCH] soc: xilinx: Create folder structure for soc specific drivers
From: Michal Simek @ 2017-12-19 13:23 UTC (permalink / raw)
To: linux-arm-kernel
Create directory structure with Makefile/Kconfig for adding xilinx soc
specific drivers.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
This patch is done based on discussion ended here
https://lkml.org/lkml/2017/12/18/565
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/xilinx/Kconfig | 4 ++++
drivers/soc/xilinx/Makefile | 1 +
4 files changed, 7 insertions(+)
create mode 100644 drivers/soc/xilinx/Kconfig
create mode 100644 drivers/soc/xilinx/Makefile
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index fc9e98047421..c07b4a85253f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -16,6 +16,7 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/xilinx/Kconfig"
source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index deecb16e7256..61c584d9d619 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-y += xilinx/
obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
new file mode 100644
index 000000000000..ffaaa2f42c7e
--- /dev/null
+++ b/drivers/soc/xilinx/Kconfig
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+menu "Xilinx SoC drivers"
+
+endmenu
diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
new file mode 100644
index 000000000000..f66554cd5c45
--- /dev/null
+++ b/drivers/soc/xilinx/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
--
1.9.1
^ permalink raw reply related
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Andy Shevchenko @ 2017-12-19 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef7d09ce-06af-ad3e-1048-3b413cc32e9b@codeaurora.org>
On Tue, 2017-12-19 at 07:17 -0500, Sinan Kaya wrote:
> On 12/19/2017 5:45 AM, Andy Shevchenko wrote:
> > On Tue, 2017-12-19 at 00:37 -0500, Sinan Kaya wrote:
> > >
> > pci_get_bus_and_slot() still might be useful for the wired devices
> > in
> > SoC where we know for sure that domain == 0.
> >
>
> Then hard code the domain number as 0 while calling
> pci_get_domain_bus_and_slot()
> if you know for sure that this device will never work on a non-zero
> domain.
Thanks for so detailed explanation.
Okay, I suppose you did estimate the amount of drivers / modules that
may look better with pci_get_bus_and_slot() and the result is comparable
small.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ 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