* [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 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 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 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 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 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 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] 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
* 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 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
* [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 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 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] 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
* 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 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
* [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 3/3] ARM: dts: r8a7745: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2017-12-19 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513618743-4773-4-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 6:39 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add CMT[01] 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 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2017-12-19 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513618743-4773-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Mon, Dec 18, 2017 at 6:39 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add CMT[01] 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/8] media: v4l2-async: simplify v4l2_async_subdev structure
From: Mauro Carvalho Chehab @ 2017-12-19 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513682135.git.mchehab@s-opensource.com>
The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
match criteria requires just a device name.
So, it doesn't make sense to enclose those into structs,
as the criteria can go directly into the union.
That makes easier to document it, as we don't need to document
weird senseless structs.
At drivers, this makes even clearer about the match criteria.
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/platform/am437x/am437x-vpfe.c | 6 +++---
drivers/media/platform/atmel/atmel-isc.c | 2 +-
drivers/media/platform/atmel/atmel-isi.c | 2 +-
drivers/media/platform/davinci/vpif_capture.c | 4 ++--
drivers/media/platform/exynos4-is/media-dev.c | 4 ++--
drivers/media/platform/pxa_camera.c | 2 +-
drivers/media/platform/qcom/camss-8x16/camss.c | 2 +-
drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
drivers/media/platform/rcar_drif.c | 4 ++--
drivers/media/platform/soc_camera/soc_camera.c | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 2 +-
drivers/media/platform/ti-vpe/cal.c | 2 +-
drivers/media/platform/xilinx/xilinx-vipp.c | 2 +-
drivers/media/v4l2-core/v4l2-async.c | 16 ++++++++--------
drivers/media/v4l2-core/v4l2-fwnode.c | 10 +++++-----
drivers/staging/media/imx/imx-media-dev.c | 4 ++--
include/media/v4l2-async.h | 8 ++------
17 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/drivers/media/platform/am437x/am437x-vpfe.c b/drivers/media/platform/am437x/am437x-vpfe.c
index 0997c640191d..601ae6487617 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
- if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
- asd[i].match.fwnode.fwnode) {
+ if (vpfe->cfg->asd[i]->match.fwnode ==
+ asd[i].match.fwnode) {
sdinfo = &vpfe->cfg->sub_devs[i];
vpfe->sd[i] = subdev;
vpfe->sd[i]->grp_id = sdinfo->grp_id;
@@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
}
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
- pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
+ pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
of_node_put(rem);
}
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index 0c2635647f69..34676409ca08 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
- subdev_entity->asd->match.fwnode.fwnode =
+ subdev_entity->asd->match.fwnode =
of_fwnode_handle(rem);
list_add_tail(&subdev_entity->list, &isc->subdev_entities);
}
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index e900995143a3..9958918e2449 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi, struct device_node *node)
/* Remote node to connect */
isi->entity.node = remote;
isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
- isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
}
}
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index e45916f69def..e1c273c8b9a6 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1390,7 +1390,7 @@ static int vpif_async_bound(struct v4l2_async_notifier *notifier,
for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
- const struct fwnode_handle *fwnode = _asd->match.fwnode.fwnode;
+ const struct fwnode_handle *fwnode = _asd->match.fwnode;
if (fwnode == subdev->fwnode) {
vpif_obj.sd[i] = subdev;
@@ -1595,7 +1595,7 @@ vpif_capture_get_pdata(struct platform_device *pdev)
}
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
- pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
+ pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
of_node_put(rem);
}
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 0ef583cfc424..78b48a1fa26c 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -456,7 +456,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
}
fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
- fmd->sensor[index].asd.match.fwnode.fwnode = of_fwnode_handle(rem);
+ fmd->sensor[index].asd.match.fwnode = of_fwnode_handle(rem);
fmd->async_subdevs[index] = &fmd->sensor[index].asd;
fmd->num_sensors++;
@@ -1364,7 +1364,7 @@ static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
/* Find platform data for this sensor subdev */
for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
- if (fmd->sensor[i].asd.match.fwnode.fwnode ==
+ if (fmd->sensor[i].asd.match.fwnode ==
of_fwnode_handle(subdev->dev->of_node))
si = &fmd->sensor[i];
diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
index 305cf1cac210..f028084f0775 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2335,7 +2335,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
remote = of_graph_get_remote_port(np);
if (remote) {
- asd->match.fwnode.fwnode = of_fwnode_handle(remote);
+ asd->match.fwnode = of_fwnode_handle(remote);
of_node_put(remote);
} else {
dev_notice(dev, "no remote for %pOF\n", np);
diff --git a/drivers/media/platform/qcom/camss-8x16/camss.c b/drivers/media/platform/qcom/camss-8x16/camss.c
index 390a42c17b66..05f06c98aa64 100644
--- a/drivers/media/platform/qcom/camss-8x16/camss.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss.c
@@ -341,7 +341,7 @@ static int camss_of_parse_ports(struct device *dev,
}
csd->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
- csd->asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ csd->asd.match.fwnode = of_fwnode_handle(remote);
}
return notifier->num_subdevs;
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index 108d776f3265..f1fc7978d6d1 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -187,7 +187,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
return -ENODEV;
vin_dbg(vin, "Found digital subdevice %pOF\n",
- to_of_node(vin->digital->asd.match.fwnode.fwnode));
+ to_of_node(vin->digital->asd.match.fwnode));
vin->notifier.ops = &rvin_digital_notify_ops;
ret = v4l2_async_notifier_register(&vin->v4l2_dev, &vin->notifier);
diff --git a/drivers/media/platform/rcar_drif.c b/drivers/media/platform/rcar_drif.c
index 63c94f4028a7..b2e080ef5391 100644
--- a/drivers/media/platform/rcar_drif.c
+++ b/drivers/media/platform/rcar_drif.c
@@ -1107,7 +1107,7 @@ static int rcar_drif_notify_bound(struct v4l2_async_notifier *notifier,
struct rcar_drif_sdr *sdr =
container_of(notifier, struct rcar_drif_sdr, notifier);
- if (sdr->ep.asd.match.fwnode.fwnode !=
+ if (sdr->ep.asd.match.fwnode !=
of_fwnode_handle(subdev->dev->of_node)) {
rdrif_err(sdr, "subdev %s cannot bind\n", subdev->name);
return -EINVAL;
@@ -1235,7 +1235,7 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr *sdr)
return -EINVAL;
}
- sdr->ep.asd.match.fwnode.fwnode = fwnode;
+ sdr->ep.asd.match.fwnode = fwnode;
sdr->ep.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
notifier->num_subdevs++;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
index 916ff68b73d4..d13e2c5fb06f 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1517,7 +1517,7 @@ static int soc_of_bind(struct soc_camera_host *ici,
if (!info)
return -ENOMEM;
- info->sasd.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ info->sasd.asd.match.fwnode = of_fwnode_handle(remote);
info->sasd.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
info->subdev = &info->sasd.asd;
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index ac4c450a6c7d..9460b3080dca 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -1520,7 +1520,7 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
/* Remote node to connect */
dcmi->entity.node = remote;
dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
- dcmi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
}
}
diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c
index 719ed1d79957..d1febe5baa6d 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1702,7 +1702,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst)
goto cleanup_exit;
}
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
- asd->match.fwnode.fwnode = of_fwnode_handle(sensor_node);
+ asd->match.fwnode = of_fwnode_handle(sensor_node);
remote_ep = of_graph_get_remote_endpoint(ep_node);
if (!remote_ep) {
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c b/drivers/media/platform/xilinx/xilinx-vipp.c
index f4c3e48ed2c0..6bb28cd49dae 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.c
+++ b/drivers/media/platform/xilinx/xilinx-vipp.c
@@ -387,7 +387,7 @@ static int xvip_graph_parse_one(struct xvip_composite_device *xdev,
entity->node = remote;
entity->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
- entity->asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ entity->asd.match.fwnode = of_fwnode_handle(remote);
list_add_tail(&entity->list, &xdev->entities);
xdev->num_subdevs++;
}
diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index e5acfab470a5..2b08d03b251d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -68,12 +68,12 @@ static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
static bool match_devname(struct v4l2_subdev *sd,
struct v4l2_async_subdev *asd)
{
- return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
+ return !strcmp(asd->match.device_name, dev_name(sd->dev));
}
static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return sd->fwnode == asd->match.fwnode.fwnode;
+ return sd->fwnode == asd->match.fwnode;
}
static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
@@ -319,7 +319,7 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(
if (asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
continue;
- if (asd->match.fwnode.fwnode == fwnode)
+ if (asd->match.fwnode == fwnode)
return true;
}
@@ -330,7 +330,7 @@ static bool __v4l2_async_notifier_fwnode_has_async_subdev(
if (sd->asd->match_type != V4L2_ASYNC_MATCH_FWNODE)
continue;
- if (sd->asd->match.fwnode.fwnode == fwnode)
+ if (sd->asd->match.fwnode == fwnode)
return true;
}
@@ -355,8 +355,8 @@ static bool v4l2_async_notifier_fwnode_has_async_subdev(
struct v4l2_async_subdev *other_asd = notifier->subdevs[j];
if (other_asd->match_type == V4L2_ASYNC_MATCH_FWNODE &&
- asd->match.fwnode.fwnode ==
- other_asd->match.fwnode.fwnode)
+ asd->match.fwnode ==
+ other_asd->match.fwnode)
return true;
}
@@ -395,7 +395,7 @@ static int __v4l2_async_notifier_register(struct v4l2_async_notifier *notifier)
break;
case V4L2_ASYNC_MATCH_FWNODE:
if (v4l2_async_notifier_fwnode_has_async_subdev(
- notifier, asd->match.fwnode.fwnode, i)) {
+ notifier, asd->match.fwnode, i)) {
dev_err(dev,
"fwnode has already been registered or in notifier's subdev list\n");
ret = -EEXIST;
@@ -510,7 +510,7 @@ void v4l2_async_notifier_cleanup(struct v4l2_async_notifier *notifier)
switch (asd->match_type) {
case V4L2_ASYNC_MATCH_FWNODE:
- fwnode_handle_put(asd->match.fwnode.fwnode);
+ fwnode_handle_put(asd->match.fwnode);
break;
default:
WARN_ON_ONCE(true);
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
index fb72c7ac04d4..d630640642ee 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -359,9 +359,9 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
return -ENOMEM;
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
- asd->match.fwnode.fwnode =
+ asd->match.fwnode =
fwnode_graph_get_remote_port_parent(endpoint);
- if (!asd->match.fwnode.fwnode) {
+ if (!asd->match.fwnode) {
dev_warn(dev, "bad remote port parent\n");
ret = -EINVAL;
goto out_err;
@@ -393,7 +393,7 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
return 0;
out_err:
- fwnode_handle_put(asd->match.fwnode.fwnode);
+ fwnode_handle_put(asd->match.fwnode);
kfree(asd);
return ret == -ENOTCONN ? 0 : ret;
@@ -566,7 +566,7 @@ static int v4l2_fwnode_reference_parse(
}
notifier->subdevs[notifier->num_subdevs] = asd;
- asd->match.fwnode.fwnode = args.fwnode;
+ asd->match.fwnode = args.fwnode;
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
notifier->num_subdevs++;
}
@@ -853,7 +853,7 @@ static int v4l2_fwnode_reference_parse_int_props(
}
notifier->subdevs[notifier->num_subdevs] = asd;
- asd->match.fwnode.fwnode = fwnode;
+ asd->match.fwnode = fwnode;
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
notifier->num_subdevs++;
}
diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
index 2800700482d6..f7ed5f506fa9 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -48,7 +48,7 @@ find_async_subdev(struct imx_media_dev *imxmd,
asd = &imxasd->asd;
switch (asd->match_type) {
case V4L2_ASYNC_MATCH_FWNODE:
- if (fwnode && asd->match.fwnode.fwnode == fwnode)
+ if (fwnode && asd->match.fwnode == fwnode)
return asd;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
@@ -104,7 +104,7 @@ int imx_media_add_async_subdev(struct imx_media_dev *imxmd,
if (fwnode) {
asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
- asd->match.fwnode.fwnode = fwnode;
+ asd->match.fwnode = fwnode;
} else {
asd->match_type = V4L2_ASYNC_MATCH_DEVNAME;
asd->match.device_name.name = devname;
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index 6152434cbe82..a010af5134b2 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -58,12 +58,8 @@ enum v4l2_async_match_type {
struct v4l2_async_subdev {
enum v4l2_async_match_type match_type;
union {
- struct {
- struct fwnode_handle *fwnode;
- } fwnode;
- struct {
- const char *name;
- } device_name;
+ struct fwnode_handle *fwnode;
+ const char *device_name;
struct {
int adapter_id;
unsigned short address;
--
2.14.3
^ permalink raw reply related
* [PATCH v4 3/3] dts: arm64: Add mailbox binding for hi3660
From: Kaihua Zhong @ 2017-12-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513682145-19892-1-git-send-email-zhongkaihua@huawei.com>
Add DT binding for mailbox driver.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Ruyi Wang <wangruyi@huawei.com>
Signed-off-by: Kaihua Zhong <zhongkaihua@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 22570c3..1ef7b94 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -286,6 +286,14 @@
#reset-cells = <2>;
};
+ mailbox: mailbox at e896b000 {
+ compatible = "hisilicon,hi3660-mbox";
+ reg = <0x0 0xe896b000 0x0 0x1000>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <3>;
+ };
+
stub_clock: stub_clock at e896b500 {
compatible = "hisilicon,hi3660-stub-clk";
reg = <0x0 0xe896b500 0x0 0x0100>;
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/3] mailbox: Add support for Hi3660 mailbox
From: Kaihua Zhong @ 2017-12-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513682145-19892-1-git-send-email-zhongkaihua@huawei.com>
Hi3660 mailbox controller is used to send message within multiple
processors, MCU, HIFI, etc. It supports 32 mailbox channels and every
channel can only be used for single transferring direction. Once the
channel is enabled, it needs to specify the destination interrupt and
acknowledge interrupt, these two interrupt vectors are used to create
the connection between the mailbox and interrupt controllers.
The data transferring supports two modes, one is named as "automatic
acknowledge" mode so after send message the kernel doesn't need to wait
for acknowledge from remote and directly return; there have another mode
is to rely on handling interrupt for acknowledge.
This commit is for initial version driver, which only supports
"automatic acknowledge" mode to support CPU clock, which is the only
one consumer to use mailbox and has been verified. Later may enhance
this driver for interrupt mode (e.g. for supporting HIFI).
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Ruyi Wang <wangruyi@huawei.com>
Signed-off-by: Kaihua Zhong <zhongkaihua@huawei.com>
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hi3660-mailbox.c | 319 +++++++++++++++++++++++++++++++++++++++
3 files changed, 329 insertions(+)
create mode 100644 drivers/mailbox/hi3660-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..de8390d4 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -108,6 +108,14 @@ config TI_MESSAGE_MANAGER
multiple processors within the SoC. Select this driver if your
platform has support for the hardware block.
+config HI3660_MBOX
+ tristate "Hi3660 Mailbox"
+ depends on ARCH_HISI && OF
+ help
+ An implementation of the hi3660 mailbox. It is used to send message
+ between application processors and other processors/MCU/DSP. Select
+ Y here if you want to use Hi3660 mailbox controller.
+
config HI6220_MBOX
tristate "Hi6220 Mailbox"
depends on ARCH_HISI
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..cc23c3a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o
obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
+obj-$(CONFIG_HI3660_MBOX) += hi3660-mailbox.o
+
obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c
new file mode 100644
index 0000000..3ceca40
--- /dev/null
+++ b/drivers/mailbox/hi3660-mailbox.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017 Hisilicon Limited.
+// Copyright (c) 2017 Linaro Limited.
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "mailbox.h"
+
+#define MBOX_CHAN_MAX 32
+
+#define MBOX_RX 0x0
+#define MBOX_TX 0x1
+
+#define MBOX_BASE(mbox, ch) ((mbox)->base + ((ch) * 0x40))
+#define MBOX_SRC_REG 0x00
+#define MBOX_DST_REG 0x04
+#define MBOX_DCLR_REG 0x08
+#define MBOX_DSTAT_REG 0x0c
+#define MBOX_MODE_REG 0x10
+#define MBOX_IMASK_REG 0x14
+#define MBOX_ICLR_REG 0x18
+#define MBOX_SEND_REG 0x1c
+#define MBOX_DATA_REG 0x20
+
+#define MBOX_IPC_LOCK_REG 0xa00
+#define MBOX_IPC_UNLOCK 0x1acce551
+
+#define MBOX_AUTOMATIC_ACK 1
+
+#define MBOX_STATE_IDLE BIT(4)
+#define MBOX_STATE_ACK BIT(7)
+
+#define MBOX_MSG_LEN 8
+
+/**
+ * Hi3660 mailbox channel information
+ *
+ * A channel can be used for TX or RX, it can trigger remote
+ * processor interrupt to notify remote processor and can receive
+ * interrupt if has incoming message.
+ *
+ * @dst_irq: Interrupt vector for remote processor
+ * @ack_irq: Interrupt vector for local processor
+ */
+struct hi3660_chan_info {
+ unsigned int dst_irq;
+ unsigned int ack_irq;
+};
+
+/**
+ * Hi3660 mailbox controller data
+ *
+ * Mailbox controller includes 32 channels and can allocate
+ * channel for message transferring.
+ *
+ * @dev: Device to which it is attached
+ * @base: Base address of the register mapping region
+ * @chan: Representation of channels in mailbox controller
+ * @mchan: Representation of channel info
+ * @controller: Representation of a communication channel controller
+ */
+struct hi3660_mbox {
+ struct device *dev;
+ void __iomem *base;
+ struct mbox_chan chan[MBOX_CHAN_MAX];
+ struct hi3660_chan_info mchan[MBOX_CHAN_MAX];
+ struct mbox_controller controller;
+};
+
+static inline struct hi3660_mbox *to_hi3660_mbox(struct mbox_controller *mbox)
+{
+ return container_of(mbox, struct hi3660_mbox, controller);
+}
+
+static int hi3660_mbox_check_state(struct mbox_chan *chan)
+{
+ unsigned long ch = (unsigned long)chan->con_priv;
+ struct hi3660_mbox *mbox = to_hi3660_mbox(chan->mbox);
+ struct hi3660_chan_info *mchan = &mbox->mchan[ch];
+ void __iomem *base = MBOX_BASE(mbox, ch);
+ unsigned long val;
+ unsigned int state, ret;
+
+ /* Mailbox is idle so directly bail out */
+ state = readl_relaxed(base + MBOX_MODE_REG);
+ if (state & MBOX_STATE_IDLE)
+ return 0;
+
+ /* Wait for acknowledge from remote */
+ ret = readx_poll_timeout_atomic(readl_relaxed, base + MBOX_MODE_REG,
+ val, (val & MBOX_STATE_ACK), 1000, 300000);
+ if (ret) {
+ dev_err(mbox->dev, "%s: timeout for receiving ack\n", __func__);
+ return ret;
+ }
+
+ /* Ensure channel is released */
+ writel_relaxed(0xffffffff, base + MBOX_IMASK_REG);
+ writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+ return 0;
+}
+
+static int hi3660_mbox_unlock(struct mbox_chan *chan)
+{
+ struct hi3660_mbox *mbox = to_hi3660_mbox(chan->mbox);
+ unsigned int val, retry = 3;
+
+ do {
+ writel_relaxed(MBOX_IPC_UNLOCK, mbox->base + MBOX_IPC_LOCK_REG);
+
+ val = readl_relaxed(mbox->base + MBOX_IPC_LOCK_REG);
+ if (!val)
+ break;
+
+ udelay(10);
+ } while (retry--);
+
+ if (val)
+ dev_err(mbox->dev, "%s: failed to unlock mailbox\n", __func__);
+
+ return (!val) ? 0 : -ETIMEDOUT;
+}
+
+static int hi3660_mbox_acquire_channel(struct mbox_chan *chan)
+{
+ unsigned long ch = (unsigned long)chan->con_priv;
+ struct hi3660_mbox *mbox = to_hi3660_mbox(chan->mbox);
+ struct hi3660_chan_info *mchan = &mbox->mchan[ch];
+ void __iomem *base = MBOX_BASE(mbox, ch);
+ unsigned int val, retry;
+
+ for (retry = 10; retry; retry--) {
+
+ /* Check if channel is in idle state */
+ if (readl_relaxed(base + MBOX_MODE_REG) & MBOX_STATE_IDLE) {
+
+ val = BIT(mchan->ack_irq);
+ writel_relaxed(val, base + MBOX_SRC_REG);
+ val = readl_relaxed(base + MBOX_SRC_REG);
+
+ /* Check ack bit has been set successfully */
+ if (val & BIT(mchan->ack_irq))
+ break;
+ }
+ }
+
+ if (!retry)
+ dev_err(mbox->dev, "%s: failed to acquire channel\n", __func__);
+
+ return retry ? 0 : -ETIMEDOUT;
+}
+
+static int hi3660_mbox_send(struct mbox_chan *chan, u32 *msg)
+{
+ unsigned long ch = (unsigned long)chan->con_priv;
+ struct hi3660_mbox *mbox = to_hi3660_mbox(chan->mbox);
+ struct hi3660_chan_info *mchan = &mbox->mchan[ch];
+ void __iomem *base = MBOX_BASE(mbox, ch);
+ unsigned int i;
+
+ /* Ensure channel is released */
+ writel_relaxed(0xffffffff, base + MBOX_IMASK_REG);
+ writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+
+ /* Clear mask for destination interrupt */
+ writel_relaxed(~BIT(mchan->dst_irq), base + MBOX_IMASK_REG);
+
+ /* Config destination for interrupt vector */
+ writel_relaxed(BIT(mchan->dst_irq), base + MBOX_DST_REG);
+
+ /* Automatic acknowledge mode */
+ writel_relaxed(MBOX_AUTOMATIC_ACK, base + MBOX_MODE_REG);
+
+ /* Fill message data */
+ for (i = 0; i < MBOX_MSG_LEN; i++)
+ writel_relaxed(msg[i], base + MBOX_DATA_REG + i * 4);
+
+ /* Trigger data transferring */
+ writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SEND_REG);
+ return 0;
+}
+
+static int hi3660_mbox_startup(struct mbox_chan *chan)
+{
+ int ret;
+
+ ret = hi3660_mbox_check_state(chan);
+ if (ret)
+ return ret;
+
+ ret = hi3660_mbox_unlock(chan);
+ if (ret)
+ return ret;
+
+ ret = hi3660_mbox_acquire_channel(chan);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int hi3660_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+ return hi3660_mbox_send(chan, msg);
+}
+
+static struct mbox_chan_ops hi3660_mbox_ops = {
+ .startup = hi3660_mbox_startup,
+ .send_data = hi3660_mbox_send_data,
+};
+
+static struct mbox_chan *hi3660_mbox_xlate(struct mbox_controller *controller,
+ const struct of_phandle_args *spec)
+{
+ struct hi3660_mbox *mbox = to_hi3660_mbox(controller);
+ struct hi3660_chan_info *mchan;
+ unsigned int ch = spec->args[0];
+
+ if (ch >= MBOX_CHAN_MAX) {
+ dev_err(mbox->dev, "Invalid channel idx %d\n", ch);
+ return ERR_PTR(-EINVAL);
+ }
+
+ mchan = &mbox->mchan[ch];
+ mchan->dst_irq = spec->args[1];
+ mchan->ack_irq = spec->args[2];
+
+ return &mbox->chan[ch];
+}
+
+static const struct of_device_id hi3660_mbox_of_match[] = {
+ { .compatible = "hisilicon,hi3660-mbox", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hi3660_mbox_of_match);
+
+static int hi3660_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct hi3660_mbox *mbox;
+ struct mbox_chan *chan;
+ struct resource *res;
+ unsigned long ch;
+ int err;
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mbox->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mbox->base))
+ return PTR_ERR(mbox->base);
+
+ mbox->dev = dev;
+ mbox->controller.dev = dev;
+ mbox->controller.chans = mbox->chan;
+ mbox->controller.num_chans = MBOX_CHAN_MAX;
+ mbox->controller.ops = &hi3660_mbox_ops;
+ mbox->controller.of_xlate = hi3660_mbox_xlate;
+
+ /* Initialize mailbox channel data */
+ chan = mbox->chan;
+ for (ch = 0; ch < MBOX_CHAN_MAX; ch++)
+ chan[ch].con_priv = (void *)ch;
+
+ err = mbox_controller_register(&mbox->controller);
+ if (err) {
+ dev_err(dev, "Failed to register mailbox %d\n", err);
+ return err;
+ }
+
+ platform_set_drvdata(pdev, mbox);
+ dev_info(dev, "Mailbox enabled\n");
+ return 0;
+}
+
+static int hi3660_mbox_remove(struct platform_device *pdev)
+{
+ struct hi3660_mbox *mbox = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(&mbox->controller);
+ return 0;
+}
+
+static struct platform_driver hi3660_mbox_driver = {
+ .probe = hi3660_mbox_probe,
+ .remove = hi3660_mbox_remove,
+ .driver = {
+ .name = "hi3660-mbox",
+ .of_match_table = hi3660_mbox_of_match,
+ },
+};
+
+static int __init hi3660_mbox_init(void)
+{
+ return platform_driver_register(&hi3660_mbox_driver);
+}
+core_initcall(hi3660_mbox_init);
+
+static void __exit hi3660_mbox_exit(void)
+{
+ platform_driver_unregister(&hi3660_mbox_driver);
+}
+module_exit(hi3660_mbox_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon Hi3660 Mailbox Controller");
+MODULE_AUTHOR("Leo Yan <leo.yan@linaro.org>");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: mailbox: Introduce Hi3660 controller binding
From: Kaihua Zhong @ 2017-12-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513682145-19892-1-git-send-email-zhongkaihua@huawei.com>
From: Leo Yan <leo.yan@linaro.org>
Introduce a binding for the Hi3660 mailbox controller, the mailbox is
used within application processor (AP), communication processor (CP),
HIFI and MCU, etc.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
.../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
new file mode 100644
index 0000000..3e5b453
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
@@ -0,0 +1,51 @@
+Hisilicon Hi3660 Mailbox Controller
+
+Hisilicon Hi3660 mailbox controller supports up to 32 channels. Messages
+are passed between processors, including application & communication
+processors, MCU, HIFI, etc. Each channel is unidirectional and accessed
+by using MMIO registers; it supports maximum to 8 words message.
+
+Controller
+----------
+
+Required properties:
+- compatible: : Shall be "hisilicon,hi3660-mbox"
+- reg: : Offset and length of the device's register set
+- #mbox-cells: : Must be 3
+ <&phandle channel dst_irq ack_irq>
+ phandle : Label name of controller
+ channel : Channel number
+ dst_irq : Remote interrupt vector
+ ack_irq : Local interrupt vector
+
+- interrupts: : Contains the two IRQ lines for mailbox.
+
+Example:
+
+mailbox: mailbox at e896b000 {
+ compatible = "hisilicon,hi3660-mbox";
+ reg = <0x0 0xe896b000 0x0 0x1000>;
+ interrupts = <0x0 0xc0 0x4>,
+ <0x0 0xc1 0x4>;
+ #mbox-cells = <3>;
+};
+
+Client
+------
+
+Required properties:
+- compatible : See the client docs
+- mboxes : Standard property to specify a Mailbox (See ./mailbox.txt)
+ Cells must match 'mbox-cells' (See Controller docs above)
+
+Optional properties
+- mbox-names : Name given to channels seen in the 'mboxes' property.
+
+Example:
+
+stub_clock: stub_clock at e896b500 {
+ compatible = "hisilicon,hi3660-stub-clk";
+ reg = <0x0 0xe896b500 0x0 0x0100>;
+ #clock-cells = <1>;
+ mboxes = <&mailbox 13 3 0>;
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/3] Add support for Hi3660 mailbox driver
From: Kaihua Zhong @ 2017-12-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
From: Leo Yan <leo.yan@linaro.org>
Hi3660 mailbox controller is used to send message within multiple
processors, MCU, HIFI, etc. This patch series is to implement an
initial version for Hi3660 mailbox driver with "automatic
acknowledge" mode.
The patch set have been verified with Hi3660 stub clock driver, so
we can send message to MCU to execute CPU frequency scaling. This is
tested on 96boards Hikey960.
Changes from v3:
* According to Jassi suggestion, refined structure name to
"struct hi3660_chan_info";
* According to Jassi suggestion, moved channel 'lock'+'acquire'
operations into .startup();
Changes from v2:
* According to Mark Rutland suggestions, removed sev()/wfe() from
driver, the system has no two masters sharing the same channel for
data transferring so we don't need these instructions;
* Refined DT binding and doc according to Rob suggestions;
* Refined driver according to Julien suggestions;
Changes from v1:
* Added cover letter to track the changelog;
* Added document for DT binding;
* Refactored and simplized mailbox driver with "automatic ack" mode;
* Refined commit logs for patches;
Kaihua Zhong (2):
mailbox: Add support for Hi3660 mailbox
dts: arm64: Add mailbox binding for hi3660
Leo Yan (1):
dt-bindings: mailbox: Introduce Hi3660 controller binding
.../bindings/mailbox/hisilicon,hi3660-mailbox.txt | 51 ++++
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 +
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/hi3660-mailbox.c | 319 +++++++++++++++++++++
5 files changed, 388 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi3660-mailbox.txt
create mode 100644 drivers/mailbox/hi3660-mailbox.c
--
1.9.1
^ permalink raw reply
* [PATCH] dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63
From: Peter Ujfalusi @ 2017-12-19 10:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Vignesh R <vigneshr@ti.com>
Register layout of a typical TPCC_EVT_MUX_M_N register is such that the
lowest numbered event is at the lowest byte address and highest numbered
event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is
different, in that the lowest numbered event is at the highest address
and highest numbered event is at the lowest address. Therefore, modify
ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register
accordingly.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 7df910e7c348..9272b173c746 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -54,7 +54,15 @@ struct ti_am335x_xbar_map {
static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val, iomem + event);
+ /*
+ * TPCC_EVT_MUX_60_63 register layout is different than the
+ * rest, in the sense, that event 63 is mapped to lowest byte
+ * and event 60 is mapped to highest, handle it separately.
+ */
+ if (event >= 60 && event <= 63)
+ writeb_relaxed(val, iomem + (63 - event % 4));
+ else
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox