* [PATCH RFC 8/8] ARM: dts: sk-rzg1m: initial device tree
From: Geert Uytterhoeven @ 2016-09-19 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2097453.1xPZsJcFmC@wasted.cogentembedded.com>
On Fri, Sep 16, 2016 at 3:38 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add the initial device tree for the R8A7743 SoC based SK-RZG1M board.
> The board has one debug serial port (SCIF0); include support for it, so
> that the serial console can work.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
> @@ -0,0 +1,44 @@
> + compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
To be documented in Documentation/devicetree/bindings/arm/shmobile.txt
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] ASoC: samsung: make audio interface/controller explicitly
From: Mark Brown @ 2016-09-19 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207751-9804-2-git-send-email-ayaka@soulik.info>
On Sun, Sep 18, 2016 at 10:09:11PM +0800, Randy Li wrote:
> It is simple sound card time, we could assign different codec
> to a interface without making a specific driver for it.
> config SND_SAMSUNG_AC97
> - tristate
> + tristate "Samsung AC97 controller support"
> select SND_SOC_AC97_BUS
Are you *sure* simple-card works for AC'97?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/3328cc74/attachment-0001.sig>
^ permalink raw reply
* [PATCH] make samsung interface entries explicitly
From: Mark Brown @ 2016-09-19 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207751-9804-1-git-send-email-ayaka@soulik.info>
On Sun, Sep 18, 2016 at 10:09:10PM +0800, Randy Li wrote:
> I found those modules should be selected directly, as I
> only use the simple sound card.
Please don't send cover letters for single patches, if there is anything
that needs saying put it in the changelog of the patch or after the ---
if it's administrative stuff. This reduces mail volume and ensures that
any important information is recorded in the changelog rather than being
lost.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/23df5cd9/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC 7/8] ARM: dts: r8a7743: add [H]SCIF support
From: Geert Uytterhoeven @ 2016-09-19 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2338956.oSVFAsJyhK@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Sep 16, 2016 at 3:37 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe [H]SCIFs in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -154,6 +154,268 @@
> dma-channels = <15>;
> };
>
> + scifa0: serial at e6c40000 {
> + compatible = "renesas,scifa-r8a7743",
To be documented...
> + "renesas,rcar-gen2-scifa", "renesas,scifa";
> + reg = <0 0xe6c40000 0 64>;
> + interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp2_clks R8A7743_CLK_SCIFA0>;
> + clock-names = "fck";
> + dmas = <&dmac0 0x21>, <&dmac0 0x22>,
> + <&dmac1 0x21>, <&dmac1 0x22>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
[...]
> + scifb0: serial at e6c20000 {
> + compatible = "renesas,scifb-r8a7743",
To be documented...
> + "renesas,rcar-gen2-scifb", "renesas,scifb";
> + reg = <0 0xe6c20000 0 64>;
This does not cover the whole register block (aha, also on existing Gen2).
"reg = <0 0xe6c20000 0 256>;"?
> + interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp2_clks R8A7743_CLK_SCIFB0>;
> + clock-names = "fck";
> + dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
> + <&dmac1 0x3d>, <&dmac1 0x3e>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
[...]
> + scif0: serial at e6e60000 {
> + compatible = "renesas,scif-r8a7743",
To be documented...
> + "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6e60000 0 64>;
> + interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp7_clks R8A7743_CLK_SCIF0>, <&zs_clk>,
> + <&scif_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
> + <&dmac1 0x29>, <&dmac1 0x2a>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +
> + scif1: serial at e6e68000 {
> + compatible = "renesas,scif-r8a7743",
> + "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6e68000 0 64>;
> + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp7_clks R8A7743_CLK_SCIF1>, <&zs_clk>,
> + <&scif_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
> + <&dmac1 0x2d>, <&dmac1 0x2e>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
[...]
> + hscif0: serial at e62c0000 {
> + compatible = "renesas,hscif-r8a7743",
To be documented...
> + "renesas,rcar-gen2-hscif", "renesas,hscif";
> + reg = <0 0xe62c0000 0 96>;
> + interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp7_clks R8A7743_CLK_HSCIF0>, <&zs_clk>,
> + <&scif_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
> + <&dmac1 0x39>, <&dmac1 0x3a>;
> + dma-names = "tx", "rx", "tx", "rx";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
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] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant
From: Maxime Ripard @ 2016-09-19 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918080103.ADDBE110E@mail.free-electrons.com>
On Sun, Sep 18, 2016 at 09:59:50AM +0200, Jean-Francois Moine wrote:
> The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
> amount of endpoints and physical channels.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/445ea2c3/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: nomadik: don't default-flag IRQs as falling
From: Linus Walleij @ 2016-09-19 8:22 UTC (permalink / raw)
To: linux-arm-kernel
There is no point in adding any default trigger for these
GPIO interrupts: the device tree should contain all trigger
information and the platforms using the driver boots
exclusively from device tree.
Also the boot log is nagging me to fix this:
[ 0.771057] ------------[ cut here ]------------
[ 0.775695] WARNING: CPU: 0 PID: 1 at
../drivers/gpio/gpiolib.c:1622 _gpiochip_irqchip_add+0x138/0x160
[ 0.785034] /soc/gpio at 8012e000: Ignoring 2 default trigger
(...)
[ 0.942962] gpio 8012e000.gpio: at address e08f8000
(etc ad nauseam)
Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index 205fb399268a..d318ca055489 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -1177,7 +1177,7 @@ static int nmk_gpio_probe(struct platform_device *dev)
irqchip,
0,
handle_edge_irq,
- IRQ_TYPE_EDGE_FALLING);
+ IRQ_TYPE_NONE);
if (ret) {
dev_err(&dev->dev, "could not add irqchip\n");
gpiochip_remove(&nmk_chip->chip);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Geert Uytterhoeven @ 2016-09-19 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1815255.1arMxK7TDL@wasted.cogentembedded.com>
On Fri, Sep 16, 2016 at 3:36 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -90,6 +90,70 @@
> #power-domain-cells = <1>;
> };
>
> + dmac0: dma-controller at e6700000 {
> + compatible = "renesas,dmac-r8a7743",
To be documented.
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 v4 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
From: Maxime Ripard @ 2016-09-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916151642.27907-2-icenowy@aosc.xyz>
On Fri, Sep 16, 2016 at 11:16:42PM +0800, Icenowy Zheng wrote:
> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
> on iNet D978 Rev2 board.
>
> Enable the UART1 to make it possible to use the modified hciattach by
> Realtek to drive the BT part of RTL8723BS.
>
> On the board no r_uart pins are found now (the onboard RX/TX pins are
> wired to PF2/PF4, which is muxed with mmc0), so also disabled it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/3d283f19/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Geert Uytterhoeven @ 2016-09-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1815255.1arMxK7TDL@wasted.cogentembedded.com>
On Fri, Sep 16, 2016 at 3:36 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe SYS-DMAC0/1 in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
(but the clocks properties will have to be changed due to CPG/MSSR)
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 v4 1/2] ARM: dts: sun8i: add pinmux for UART1 at PG
From: Maxime Ripard @ 2016-09-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916151642.27907-1-icenowy@aosc.xyz>
Hi,
On Fri, Sep 16, 2016 at 11:16:41PM +0800, Icenowy Zheng wrote:
> The UART1 at PG (PG6, PG7, PG8, PG9) is, in the Allwinner's reference
> tablet design of A23/33, used to connect to UART Bluetooth cards.
>
> Add the pinmux for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> This patch is splited in v4.
>
> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 7e05e09..c340885 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -361,6 +361,20 @@
> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> };
>
> + uart1_pins_a: uart1 at 0 {
> + allwinner,pins = "PG6", "PG7";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
> + allwinner,pins = "PG8", "PG9";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
It turns out the allwinner,drive and allwinner,pull properties are
optionnal. I removed them, and applied that patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/38cead74/attachment.sig>
^ permalink raw reply
* [PATCH v6 0/8] power: add power sequence library
From: Vaibhav Hiremath @ 2016-09-19 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919074637.GA10289@b29397-desktop>
On Monday 19 September 2016 01:16 PM, Peter Chen wrote:
> On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>>
>> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>>>> Unless Ulf and rob both agree to change.
>>>>>> Why 2 separate approach for same problem ?
>>>>>> And I see this as possible duplication of code/functionality :)
>>>>> How the new kernel compatibles old dts? If we do not need to
>>>>> consider this problem, the mmc can try to use power sequence library
>>>>> too in future.
>>>> I think we should attempt to get both MMC and USB power seq
>>>> come on one agreement, so that it can be reused.
>>> That would be nice. Although, to do that you would have to allow some
>>> DT bindings to be deprecated in the new generic power seq bindings, as
>>> otherwise you would break existing DTBs.
>>>
>>> I guess that is what Rob was objecting to!?
>> yeah, thats right.
>>
>> So lets adopt similar implementation for USB as well instead of
>> library, but keeping MMC untouched as of now.
>>
>> What I am trying to propose here is,
>>
>> Lets have power-sequence framework (similar to V1 of this series),
>> with,
>>
>> pwrseq: Core framework for power sequence.
>> pwrseq_generic/simple: for all generic control, like reset and clock
>> pwrseq_emmc: probably duplication of existing code - the idea
>> here is, all future code should be using this new
>> binding, so that we can deprecate the
>> drivers/mmc/core/pwrseq
>> pwrseq_arche: The usecase which I am dealing with today, which is more
>> complex in nature.
>>
>> Then the respective drivers can add their drivers (if needed) based on
>> complexity.
>>
>> comments ??
> The key point here is DT maintainer (Rob) doesn't agree with adding new node
> for power sequence at dts.
>
Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH RFC 5/8] ARM: dts: r8a7743: initial SoC device tree
From: Geert Uytterhoeven @ 2016-09-19 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1679762.ECpvSkQAyM@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Sep 16, 2016 at 3:35 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
> and the required clock descriptions.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> --- /dev/null/
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -0,0 +1,210 @@
> +/ {
> + soc {
=
> + /* Special CPG clocks */
> + cpg_clocks: cpg_clocks at e6150000 {
> + compatible = "renesas,r8a7743-cpg-clocks",
> + "renesas,rcar-gen2-cpg-clocks";
For a new SoC family, I would strongly suggest using a renesas,cpg-mssr
based binding instead:
- No more mstp*_clocks nodes with array triplets to keep in sync,
- Support for MSSR reset can be added later,
- No need to add all those fixed-factor clocks to DT,
- Less DT churn when adding support for new devices.
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: dts: Add power button support for igepv5
From: Pau Pajuel @ 2016-09-19 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31409234-3185-5348-2d37-effb7769c92a@osg.samsung.com>
Hello Tony,
2016-09-14 3:26 GMT+02:00 Javier Martinez Canillas <javier@osg.samsung.com>:
> Hello Tony,
>
> On 09/09/2016 05:07 PM, Tony Lindgren wrote:
>> Add power button support for igepv5.
>>
>> Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
>> Cc: Enric Balletbo Serra <eballetbo@gmail.com>
>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>> Cc: Pau Pajuel <ppajuel@gmail.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>
> I don't have a schematics for this board, but the patch looks good to me.
Patch has an errata. Power button is GPIO_ACTIVE_LOW instead GPIO_ACTIVE_HIGH.
>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
Best regards
^ permalink raw reply
* [PATCH soc/next] ARM: BCM53573: Add custom init_time with arch timer workaroud
From: Marc Zyngier @ 2016-09-19 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918193238.21339-1-zajec5@gmail.com>
Rafa?,
On 18/09/16 20:32, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> BCM53573 uses ARM architected timer but CFE (bootloader) is bugged and
> doesn't setup hardware properly. As the architecture requirement clock
> should be enabled and CNTFRQ should be set before starting Linux.
>
> Unfortunately it's impossible to have CFE fixed and updated on all
> released devices. There are plenty of them on the market and updating
> bootloader isn't a standard procedure. We also don't have CFE sources
> for BCM53573 devices and no replacement bootloader.
>
> We can't modify arch timer to simply accept specifying clock. Quoting
> Mark: "The clock-frequency property is at best a dodgy workaround, and
> this is even worse.". Marc also noted that other subsystems may rely on
> CNTFRQ as well.
>
> The only sane workaround seems to be fixing this CFE bug in BCM53573
> arch code. It doesn't require modifying other drivers and should allow
> all subsystems to work correctly.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> MAINTAINERS | 1 +
> arch/arm/mach-bcm/Makefile | 3 +++
> arch/arm/mach-bcm/bcm_53573.c | 62 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 66 insertions(+)
> create mode 100644 arch/arm/mach-bcm/bcm_53573.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a91bca7..0bb0c4b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2568,6 +2568,7 @@ BROADCOM BCM53573 ARM ARCHITECTURE
> M: Rafa? Mi?ecki <rafal@milecki.pl>
> L: linux-arm-kernel at lists.infradead.org
> S: Maintained
> +F: arch/arm/mach-bcm/bcm_53573.c
> F: arch/arm/boot/dts/bcm53573*
> F: arch/arm/boot/dts/bcm47189*
>
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 980f585..0d64778 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -50,6 +50,9 @@ ifeq ($(CONFIG_ARCH_BCM_5301X),y)
> obj-$(CONFIG_SMP) += platsmp.o
> endif
>
> +# BCM53573
> +obj-$(CONFIG_ARCH_BCM_53573) += bcm_53573.o
> +
> # BCM63XXx
> ifeq ($(CONFIG_ARCH_BCM_63XX),y)
> obj-y += bcm63xx.o
> diff --git a/arch/arm/mach-bcm/bcm_53573.c b/arch/arm/mach-bcm/bcm_53573.c
> new file mode 100644
> index 0000000..540a247
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm_53573.c
> @@ -0,0 +1,62 @@
> +/*
> + * Copyright (C) 2016 Rafa? Mi?ecki <rafal@milecki.pl>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <asm/mach/arch.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/clk.h>
> +
> +static inline void arch_timer_set_cntfrq(u32 cntfrq)
> +{
> + asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (cntfrq));
> +}
This is wrong for a number of reasons: This register only writeable from
the secure side. Boot this kernel in non-secure mode, and the kernel
will explode. Also, you're only setting it from the boot CPU, while it
should be set on all of them.
So in effect, this is not any better than advertising the timer
frequency in the device tree.
> +
> +/*
> + * CFE bootloader doesn't meet arch requirements. It doesn't enable ILP clock
> + * which is required for arch timer and doesn't set CNTFRQ.
> + * Fix is up here.
> + */
> +static void __init bcm_53573_setup_arch_timer(void)
> +{
> + struct of_phandle_args out_args = { };
> + struct clk *clk;
> +
> + out_args.np = of_find_compatible_node(NULL, NULL, "brcm,bcm53573-ilp");
> + if (!out_args.np) {
> + pr_warn("Failed to find ILP node\n");
> + return;
> + }
> +
> + clk = of_clk_get_from_provider(&out_args);
> + if (!IS_ERR(clk)) {
> + if (!clk_prepare_enable(clk))
> + arch_timer_set_cntfrq(clk_get_rate(clk));
> + }
> +
> + of_node_put(out_args.np);
> +}
> +
> +/* A copy of ARM's time_init with workaround inserted */
> +static void __init bcm_53573_init_time(void)
> +{
> +#ifdef CONFIG_COMMON_CLK
> + of_clk_init(NULL);
> +#endif
> + bcm_53573_setup_arch_timer();
> + clocksource_probe();
> +}
> +
> +static const char *const bcm_53573_dt_compat[] __initconst = {
> + "brcm,bcm53573",
> + NULL,
> +};
> +
> +DT_MACHINE_START(BCM5301X, "BCM53573")
> + .init_time = bcm_53573_init_time,
> + .dt_compat = bcm_53573_dt_compat,
> +MACHINE_END
>
My advise would be to move this to a shim outside of the kernel, which
could configure the clocks and set CNTFRQ on all CPUs. As it stands,
this patch doesn't really improve the situation.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-19 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <08e9b30f-6c35-8418-a8b0-0b63639dd36d@acm.org>
On 09/16/2016 09:41 PM, Corey Minyard wrote:
> On 09/16/2016 05:39 AM, C?dric Le Goater wrote:
>> From: Alistair Popple <alistair@popple.id.au>
>>
>> This patch adds a simple device driver to expose the iBT interface on
>> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
>> commonly used as BMCs (BaseBoard Management Controllers) and this
>> driver implements the BMC side of the BT interface.
>>
>> The BT (Block Transfer) interface is used to perform in-band IPMI
>> communication between a host and its BMC. Entire messages are buffered
>> before sending a notification to the other end, host or BMC, that
>> there is data to be read. Usually, the host emits requests and the BMC
>> responses but the specification provides a mean for the BMC to send
>> SMS Attention (BMC-to-Host attention or System Management Software
>> attention) messages.
>>
>> For this purpose, the driver introduces a specific ioctl on the
>> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
>> on the BMC to signal the host of such an event.
>>
>> The device name defaults to '/dev/ipmi-bt-host'
>
> Others have reviewed this for style and such, and I have looked
> at it from a protocol point of view. it looks to be sound for the
> most part. I have some higher level concerns:
>
> There appears to be no handling for multiple simultaneous users.
> This interface can only be used by one task at a time, so you should
> probably only allow one opener. Well, I guess the BMC could be split
> into a reader and a writer task, so I'm not really sure about that, but
> I would think in most situations having more than one opener is a
> bug. You do call clr_b_busy() on open, for instance, which might be
> an issue for multiple openers. Maybe a module parameter for
> maximum number of openers? Just want to make sure this was
> thought about, at least.
yes but not implemented ... The open_count in the bt_bmc structure
is unused. In v3, I will replace it with a global atomic_t tracked
in the open and release operations.
> There is also no mutex protecting reading or writing. If multiple
> threads call read or write at the same time, it probably wouldn't
> work correctly. I think you need a read and a write mutex on the
> interface to protect against this.
yes. I will add a mutex also in v3.
> The spec says:
>
> The BMC must not return a given response once the corresponding
> Request-to-Response interval has passed. The BMC can ensure this
> by maintaining its own internal list of outstanding requests through
> the interface. The BMC could age and expire the entries in the list
> by expiring the entries at an interval that is somewhat shorter than
> the specified Request-to-Response interval....
This is clearly not handled in the driver.
For this purpose, we could maintain a request expiry list using the seq
field of the BT message. Update the list in the read and write operations
and arm a timer to garbage collect any left overs. As for the errno in
the write when a response had timeout'ed, may be ETIMEDOUT ?
For configuration of the maximum response time, a sysfs file would do
I think.
Do you want that in v3 also ? I have some experimental patches for it,
that I can send as follow ups.
Thanks,
C.
> On the write side, though, there doesn't seem to be a way to handle a
> situation where the host side doesn't respond for a while and the
> pending message would need to be discarded.
>
> The spec doesn't mention much about error recovery on this interface,
> but the way this is written should be fine, I think.
>
> I'm copying Rocky Craig, who wrote the host side driver for Linux, in
> case he wants to comment on this.
>
> This is easy to read and understand, so I think v3 should be good.
>
> Thanks,
>
> -corey
>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [clg: - checkpatch fixes
>> - added a devicetree binding documentation
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>> ]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>>
>> Changes since v1:
>>
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>> drivers/Makefile | 2 +-
>> drivers/char/ipmi/Kconfig | 7 +
>> drivers/char/ipmi/Makefile | 1 +
>> drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/bt-bmc.h | 18 +
>> 7 files changed, 537 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> create mode 100644 drivers/char/ipmi/bt-bmc.c
>> create mode 100644 include/uapi/linux/bt-bmc.h
>>
>> diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> new file mode 100644
>> index 000000000000..fbbacd958240
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> @@ -0,0 +1,23 @@
>> +* Aspeed BT (Block Transfer) IPMI interface
>> +
>> +The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
>> +(BaseBoard Management Controllers) and the BT interface can be used to
>> +perform in-band IPMI communication with their host.
>> +
>> +Required properties:
>> +
>> +- compatible : should be "aspeed,ast2400-bt-bmc"
>> +- reg: physical address and size of the registers
>> +
>> +Optional properties:
>> +
>> +- interrupts: interrupt generated by the BT interface. without an
>> + interrupt, the driver will operate in poll mode.
>> +
>> +Example:
>> +
>> + ibt at 1e789140 {
>> + compatible = "aspeed,ast2400-bt-bmc";
>> + reg = <0x1e789140 0x18>;
>> + interrupts = <8>;
>> + };
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 53abb4a5f736..5a9e7b6b7928 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -21,7 +21,7 @@ obj-y += video/
>> obj-y += idle/
>> # IPMI must come before ACPI in order to provide IPMI opregion support
>> -obj-$(CONFIG_IPMI_HANDLER) += char/ipmi/
>> +obj-y += char/ipmi/
>> obj-$(CONFIG_ACPI) += acpi/
>> obj-$(CONFIG_SFI) += sfi/
>> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
>> index 5a9350b1069a..2c234e3e7513 100644
>> --- a/drivers/char/ipmi/Kconfig
>> +++ b/drivers/char/ipmi/Kconfig
>> @@ -76,3 +76,10 @@ config IPMI_POWEROFF
>> the IPMI management controller is capable of this.
>> endif # IPMI_HANDLER
>> +
>> +config ASPEED_BT_IPMI_BMC
>> + tristate "BT IPMI bmc driver"
>> + help
>> + Provides a driver for the BT (Block Transfer) IPMI interface
>> + found on Aspeed SOCs (AST2400 and AST2500). The driver
>> + implements the BMC side of the BT interface.
>> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>> index f3ffde1f5f1f..0d98cd91def1 100644
>> --- a/drivers/char/ipmi/Makefile
>> +++ b/drivers/char/ipmi/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
>> obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
>> obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
>> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
>> +obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> new file mode 100644
>> index 000000000000..b96cb421e1c2
>> --- /dev/null
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -0,0 +1,486 @@
>> +/*
>> + * Copyright (c) 2015-2016, IBM Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/errno.h>
>> +#include <linux/poll.h>
>> +#include <linux/sched.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/slab.h>
>> +#include <linux/init.h>
>> +#include <linux/device.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/io.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/delay.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/timer.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/bt-bmc.h>
>> +
>> +/*
>> + * This is a BMC device used to communicate to the host
>> + */
>> +#define DEVICE_NAME "ipmi-bt-host"
>> +
>> +#define BT_IO_BASE 0xe4
>> +#define BT_IRQ 10
>> +
>> +#define BT_CR0 0x0
>> +#define BT_CR0_IO_BASE 16
>> +#define BT_CR0_IRQ 12
>> +#define BT_CR0_EN_CLR_SLV_RDP 0x8
>> +#define BT_CR0_EN_CLR_SLV_WRP 0x4
>> +#define BT_CR0_ENABLE_IBT 0x1
>> +#define BT_CR1 0x4
>> +#define BT_CR1_IRQ_H2B 0x01
>> +#define BT_CR1_IRQ_HBUSY 0x40
>> +#define BT_CR2 0x8
>> +#define BT_CR2_IRQ_H2B 0x01
>> +#define BT_CR2_IRQ_HBUSY 0x40
>> +#define BT_CR3 0xc
>> +#define BT_CTRL 0x10
>> +#define BT_CTRL_B_BUSY 0x80
>> +#define BT_CTRL_H_BUSY 0x40
>> +#define BT_CTRL_OEM0 0x20
>> +#define BT_CTRL_SMS_ATN 0x10
>> +#define BT_CTRL_B2H_ATN 0x08
>> +#define BT_CTRL_H2B_ATN 0x04
>> +#define BT_CTRL_CLR_RD_PTR 0x02
>> +#define BT_CTRL_CLR_WR_PTR 0x01
>> +#define BT_BMC2HOST 0x14
>> +#define BT_INTMASK 0x18
>> +#define BT_INTMASK_B2H_IRQEN 0x01
>> +#define BT_INTMASK_B2H_IRQ 0x02
>> +#define BT_INTMASK_BMC_HWRST 0x80
>> +
>> +struct bt_bmc {
>> + struct device dev;
>> + struct miscdevice miscdev;
>> + void __iomem *base;
>> + int open_count;
>> + int irq;
>> + wait_queue_head_t queue;
>> + struct timer_list poll_timer;
>> +};
>> +
>> +static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> +{
>> + return ioread8(bt_bmc->base + reg);
>> +}
>> +
>> +static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg)
>> +{
>> + iowrite8(data, bt_bmc->base + reg);
>> +}
>> +
>> +static void clr_rd_ptr(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_CLR_RD_PTR, BT_CTRL);
>> +}
>> +
>> +static void clr_wr_ptr(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_CLR_WR_PTR, BT_CTRL);
>> +}
>> +
>> +static void clr_h2b_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_H2B_ATN, BT_CTRL);
>> +}
>> +
>> +static void set_b_busy(struct bt_bmc *bt_bmc)
>> +{
>> + if (!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY))
>> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
>> +}
>> +
>> +static void clr_b_busy(struct bt_bmc *bt_bmc)
>> +{
>> + if (bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY)
>> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
>> +}
>> +
>> +static void set_b2h_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_B2H_ATN, BT_CTRL);
>> +}
>> +
>> +static u8 bt_read(struct bt_bmc *bt_bmc)
>> +{
>> + return bt_inb(bt_bmc, BT_BMC2HOST);
>> +}
>> +
>> +static ssize_t bt_readn(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < n; i++)
>> + buf[i] = bt_read(bt_bmc);
>> + return n;
>> +}
>> +
>> +static void bt_write(struct bt_bmc *bt_bmc, u8 c)
>> +{
>> + bt_outb(bt_bmc, c, BT_BMC2HOST);
>> +}
>> +
>> +static ssize_t bt_writen(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < n; i++)
>> + bt_write(bt_bmc, buf[i]);
>> + return n;
>> +}
>> +
>> +static void set_sms_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_SMS_ATN, BT_CTRL);
>> +}
>> +
>> +static struct bt_bmc *file_bt_bmc(struct file *file)
>> +{
>> + return container_of(file->private_data, struct bt_bmc, miscdev);
>> +}
>> +
>> +static int bt_bmc_open(struct inode *inode, struct file *file)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return 0;
>> +}
>> +
>> +#define BT_BMC_BUFFER_SIZE 256
>> +
>> +/*
>> + * The BT (Block Transfer) interface means that entire messages are
>> + * buffered by the host before a notification is sent to the BMC that
>> + * there is data to be read. The first byte is the length and the
>> + * message data follows. The read operation just tries to capture the
>> + * whole before returning it to userspace.
>> + */
>> +static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + u8 len;
>> + int len_byte = 1;
>> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
>> + ssize_t ret = 0;
>> + ssize_t nread;
>> +
>> + if (!access_ok(VERIFY_WRITE, buf, count))
>> + return -EFAULT;
>> +
>> + WARN_ON(*ppos);
>> +
>> + if (wait_event_interruptible(bt_bmc->queue,
>> + bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
>> + return -ERESTARTSYS;
>> +
>> + set_b_busy(bt_bmc);
>> + clr_h2b_atn(bt_bmc);
>> + clr_rd_ptr(bt_bmc);
>> +
>> + /*
>> + * The BT frames start with the message length, which does not
>> + * include the length byte.
>> + */
>> + kbuffer[0] = bt_read(bt_bmc);
>> + len = kbuffer[0];
>> +
>> + /* We pass the length back to userspace as well */
>> + if (len + 1 > count)
>> + len = count - 1;
>> +
>> + while (len) {
>> + nread = min_t(ssize_t, len, sizeof(kbuffer) - len_byte);
>> +
>> + bt_readn(bt_bmc, kbuffer + len_byte, nread);
>> +
>> + if (copy_to_user(buf, kbuffer, nread + len_byte)) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> + len -= nread;
>> + buf += nread + len_byte;
>> + ret += nread + len_byte;
>> + len_byte = 0;
>> + }
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
>> + ssize_t ret = 0;
>> + ssize_t nwritten;
>> +
>> + if (!access_ok(VERIFY_READ, buf, count))
>> + return -EFAULT;
>> +
>> + WARN_ON(*ppos);
>> +
>> + /* There's no interrupt for clearing bmc busy so we have to
>> + * poll
>> + */
>> + if (wait_event_interruptible(bt_bmc->queue,
>> + !(bt_inb(bt_bmc, BT_CTRL) &
>> + (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
>> + return -ERESTARTSYS;
>> +
>> + clr_wr_ptr(bt_bmc);
>> +
>> + while (count) {
>> + nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> + if (copy_from_user(&kbuffer, buf, nwritten)) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> +
>> + bt_writen(bt_bmc, kbuffer, nwritten);
>> +
>> + count -= nwritten;
>> + buf += nwritten;
>> + ret += nwritten;
>> + }
>> +
>> + set_b2h_atn(bt_bmc);
>> +
>> + return ret;
>> +}
>> +
>> +static long bt_bmc_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long param)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + switch (cmd) {
>> + case BT_BMC_IOCTL_SMS_ATN:
>> + set_sms_atn(bt_bmc);
>> + return 0;
>> + }
>> + return -EINVAL;
>> +}
>> +
>> +static int bt_bmc_release(struct inode *inode, struct file *file)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + set_b_busy(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static unsigned int bt_bmc_poll(struct file *file, poll_table *wait)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + unsigned int mask = 0;
>> + uint8_t ctrl;
>> +
>> + poll_wait(file, &bt_bmc->queue, wait);
>> +
>> + ctrl = bt_inb(bt_bmc, BT_CTRL);
>> +
>> + if (ctrl & BT_CTRL_H2B_ATN)
>> + mask |= POLLIN;
>> +
>> + if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
>> + mask |= POLLOUT;
>> +
>> + return mask;
>> +}
>> +
>> +static const struct file_operations bt_bmc_fops = {
>> + .owner = THIS_MODULE,
>> + .open = bt_bmc_open,
>> + .read = bt_bmc_read,
>> + .write = bt_bmc_write,
>> + .release = bt_bmc_release,
>> + .poll = bt_bmc_poll,
>> + .unlocked_ioctl = bt_bmc_ioctl,
>> +};
>> +
>> +static void poll_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + bt_bmc->poll_timer.expires += msecs_to_jiffies(500);
>> + wake_up(&bt_bmc->queue);
>> + add_timer(&bt_bmc->poll_timer);
>> +}
>> +
>> +static irqreturn_t bt_bmc_irq(int irq, void *arg)
>> +{
>> + struct bt_bmc *bt_bmc = arg;
>> + uint32_t reg;
>> +
>> + reg = ioread32(bt_bmc->base + BT_CR2);
>> + reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
>> + if (!reg)
>> + return IRQ_NONE;
>> +
>> + /* ack pending IRQs */
>> + iowrite32(reg, bt_bmc->base + BT_CR2);
>> +
>> + wake_up(&bt_bmc->queue);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
>> + struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + uint32_t reg;
>> + int rc;
>> +
>> + bt_bmc->irq = platform_get_irq(pdev, 0);
>> + if (!bt_bmc->irq)
>> + return -ENODEV;
>> +
>> + rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
>> + DEVICE_NAME, bt_bmc);
>> + if (rc < 0) {
>> + dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
>> + bt_bmc->irq = 0;
>> + return rc;
>> + }
>> +
>> + /* Configure IRQs on the bmc clearing the H2B and HBUSY bits;
>> + * H2B will be asserted when the bmc has data for us; HBUSY
>> + * will be cleared (along with B2H) when we can write the next
>> + * message to the BT buffer
>> + */
>> + reg = ioread32(bt_bmc->base + BT_CR1);
>> + reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
>> + iowrite32(reg, bt_bmc->base + BT_CR1);
>> +
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_probe(struct platform_device *pdev)
>> +{
>> + struct bt_bmc *bt_bmc;
>> + struct device *dev;
>> + struct resource *res;
>> + int rc;
>> +
>> + if (!pdev || !pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + dev = &pdev->dev;
>> + dev_info(dev, "Found bt bmc device\n");
>> +
>> + bt_bmc = devm_kzalloc(dev, sizeof(*bt_bmc), GFP_KERNEL);
>> + if (!bt_bmc)
>> + return -ENOMEM;
>> +
>> + dev_set_drvdata(&pdev->dev, bt_bmc);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(dev, "Unable to find resources\n");
>> + rc = -ENXIO;
>> + goto out_free;
>> + }
>> +
>> + bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (!bt_bmc->base) {
>> + rc = -ENOMEM;
>> + goto out_free;
>> + }
>> +
>> + init_waitqueue_head(&bt_bmc->queue);
>> +
>> + bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> + bt_bmc->miscdev.name = DEVICE_NAME,
>> + bt_bmc->miscdev.fops = &bt_bmc_fops,
>> + bt_bmc->miscdev.parent = dev;
>> + rc = misc_register(&bt_bmc->miscdev);
>> + if (rc) {
>> + dev_err(dev, "Unable to register device\n");
>> + goto out_unmap;
>> + }
>> +
>> + bt_bmc_config_irq(bt_bmc, pdev);
>> +
>> + if (bt_bmc->irq) {
>> + dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> + } else {
>> + dev_info(dev, "No IRQ; using timer\n");
>> + setup_timer(&bt_bmc->poll_timer, poll_timer,
>> + (unsigned long)bt_bmc);
>> + bt_bmc->poll_timer.expires = jiffies + msecs_to_jiffies(10);
>> + add_timer(&bt_bmc->poll_timer);
>> + }
>> +
>> + iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
>> + (BT_IRQ << BT_CR0_IRQ) |
>> + BT_CR0_EN_CLR_SLV_RDP |
>> + BT_CR0_EN_CLR_SLV_WRP |
>> + BT_CR0_ENABLE_IBT,
>> + bt_bmc->base + BT_CR0);
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return 0;
>> +
>> +out_unmap:
>> + devm_iounmap(&pdev->dev, bt_bmc->base);
>> +
>> +out_free:
>> + devm_kfree(dev, bt_bmc);
>> + return rc;
>> +
>> +}
>> +
>> +static int bt_bmc_remove(struct platform_device *pdev)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> +
>> + misc_deregister(&bt_bmc->miscdev);
>> + if (!bt_bmc->irq)
>> + del_timer_sync(&bt_bmc->poll_timer);
>> + devm_iounmap(&pdev->dev, bt_bmc->base);
>> + devm_kfree(&pdev->dev, bt_bmc);
>> + bt_bmc = NULL;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id bt_bmc_match[] = {
>> + { .compatible = "aspeed,ast2400-bt-bmc" },
>> + { },
>> +};
>> +
>> +static struct platform_driver bt_bmc_driver = {
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .of_match_table = bt_bmc_match,
>> + },
>> + .probe = bt_bmc_probe,
>> + .remove = bt_bmc_remove,
>> +};
>> +
>> +module_platform_driver(bt_bmc_driver);
>> +
>> +MODULE_DEVICE_TABLE(of, bt_bmc_match);
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Alistair Popple <alistair@popple.id.au>");
>> +MODULE_DESCRIPTION("Linux device interface to the BT interface");
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index 185f8ea2702f..17b12942c67d 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -74,6 +74,7 @@ header-y += bpf_common.h
>> header-y += bpf.h
>> header-y += bpqether.h
>> header-y += bsg.h
>> +header-y += bt-bmc.h
>> header-y += btrfs.h
>> header-y += can.h
>> header-y += capability.h
>> diff --git a/include/uapi/linux/bt-bmc.h b/include/uapi/linux/bt-bmc.h
>> new file mode 100644
>> index 000000000000..d9ec766a63d0
>> --- /dev/null
>> +++ b/include/uapi/linux/bt-bmc.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Copyright (c) 2015-2016, IBM Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>> +
>> +#ifndef _UAPI_LINUX_BT_BMC_H
>> +#define _UAPI_LINUX_BT_BMC_H
>> +
>> +#include <linux/ioctl.h>
>> +
>> +#define __BT_BMC_IOCTL_MAGIC 0xb1
>> +#define BT_BMC_IOCTL_SMS_ATN _IO(__BT_BMC_IOCTL_MAGIC, 0x00)
>> +
>> +#endif /* _UAPI_LINUX_BT_BMC_H */
>
>
^ permalink raw reply
* [PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support
From: Geert Uytterhoeven @ 2016-09-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7093322.WFIWVqz40g@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Sep 16, 2016 at 3:33 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add minimal support for the RZ/G1M (R8A7743) SoC.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7743.c
> @@ -0,0 +1,34 @@
> +static const char * const r8a7743_boards_compat_dt[] __initconst = {
> + "renesas,r8a7743",
To be documented in
Documentation/devicetree/bindings/arm/shmobile.txt.
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 v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Andrew Jones @ 2016-09-19 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B88B95A5-3631-4AEF-80DC-7762C415A811@suse.de>
On Fri, Sep 16, 2016 at 09:36:42PM +0200, Alexander Graf wrote:
>
>
> > Am 16.09.2016 um 15:46 schrieb Andrew Jones <drjones@redhat.com>:
> >
> >> On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
> >>> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 16/09/2016 14:30, Christoffer Dall wrote:
> >>>>>>> This patch set allows user space to receive vtimer events as well as mask
> >>>>>>> them, so that we can handle all vtimer related interrupt injection from user
> >>>>>>> space, enabling us to use architected timer with user space gic emulation.
> >>>>>>
> >>>>>> I have already voiced my concerns in the past, including face to face,
> >>>>>> and I'm going to repeat it: I not keen at all on adding a new userspace
> >>>>>> interface that is going to bitrot extremely quickly.
> >>>>>
> >>>>> You don't have automated tests set up? It's not going to bitrot if you
> >>>>> test it, either with kvm-unit-tests or just by smoke-testing Linux.
> >>>>> It's _for_ the raspi, but it's not limited to it.
> >>>>
> >>>> Our automated testing situation is not great, no. Something we're
> >>>> looking at, but have resource problems with.
> >>>
> >>> But it's not a good reason to hold back a feature...
> >>
> >> I didn't say that exactly, but choosing not to merge something we cannot
> >> maintain and which we're not paid to look after and where there's a
> >> minimal interest, is not entirely unreasonable.
> >>
> >> That being said, I'm not categorically against these patches, but I
> >> share Marc's view that we've already seen that non-vgic support had been
> >> broken for multiple versions without anyone complaining, and without
> >> automated testing or substantial interest in the work, the patches
> >> really are likely to bit-rot.
> >>
> >> But I haven't even looked at the patches in detail, I was just replying
> >> to the comment about testing.
> >
> > This may be a great time to start encouraging feature writers to submit
> > kvm-unit-tests patches at the same time as the feature (Hi Alex :-)
>
> I actually started off implementing this with the help of kvm-unit-tests. It's awesome!
>
> I'm lacking actual irq support to make the test reasonable though and wanted to get the kernel bits out first :). But I'll sit down on that again soon I hope.
I'm glad it looks like a good base for you. I need to get this series
https://github.com/rhdrjones/kvm-unit-tests/commits/arm/gic refreshed and
merged, and also it's time to start looking into adding interrupt
injection to chr-testdev. With those in place I hope it'll be an even
better base for you.
Thanks,
drew
^ permalink raw reply
* [RESEND PATCH v7 2/2] sdhci-of-arasan: Set controller to test mode when xlnx,fails-without-test-cd is present
From: Adrian Hunter @ 2016-09-19 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474038102-20937-2-git-send-email-zach.brown@ni.com>
On 16/09/16 18:01, Zach Brown wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> When the device has the property xlnx,fails-without-test-cd the driver
> changes the controller to test mode and sets test inserted to true to
> make the controller function.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 27 ++++++++++++++++++++++++++-
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 33601a8..da8e40a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -26,6 +26,7 @@
> #include <linux/phy/phy.h>
> #include <linux/regmap.h>
> #include "sdhci-pltfm.h"
> +#include <linux/of.h>
>
> #define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> @@ -98,6 +99,10 @@ struct sdhci_arasan_data {
>
> struct regmap *soc_ctl_base;
> const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> + unsigned int quirks; /* Arasan deviations from spec */
> +
> +/* Controller does not have CD wired and will not function normally without */
> +#define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -245,12 +250,27 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> +void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +{
> + u8 ctrl;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_reset(host, mask);
> +
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl |= SDHCI_CTRL_CDTEST_INS | SDHCI_CTRL_CDTEST_EN;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
> +}
> +
> static struct sdhci_ops sdhci_arasan_ops = {
> .set_clock = sdhci_arasan_set_clock,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .get_timeout_clock = sdhci_arasan_get_timeout_clock,
> .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> + .reset = sdhci_arasan_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> @@ -545,6 +565,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_arasan_data *sdhci_arasan;
> + struct device_node *np = pdev->dev.of_node;
>
> host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
> sizeof(*sdhci_arasan));
> @@ -599,6 +620,10 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> }
>
> sdhci_get_of_property(pdev);
> +
> + if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index a2bc9e1..c722cd2 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -84,6 +84,8 @@
> #define SDHCI_CTRL_ADMA32 0x10
> #define SDHCI_CTRL_ADMA64 0x18
> #define SDHCI_CTRL_8BITBUS 0x20
> +#define SDHCI_CTRL_CDTEST_INS 0x40
> +#define SDHCI_CTRL_CDTEST_EN 0x80
>
> #define SDHCI_POWER_CONTROL 0x29
> #define SDHCI_POWER_ON 0x01
>
^ permalink raw reply
* [PATCH 11/11] ARM: DT: STM32: add dma for usart1 on F429
From: Alexandre Torgue @ 2016-09-19 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+TqcYuXnzokoR=vAsOofBkyA1WhuXvCc6HrekAovW2VejMQ@mail.gmail.com>
Hi Bruno,
On 09/19/2016 03:28 AM, Bruno Herrera wrote:
>> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> I just tested your patch with success in two scenarios:
>
> 1) STM32F469IDISCO board
> 2) Custom board running STM32F439NI
>
> Tested-by: Bruno Herrera <bruherrera@gmail.com>
>
> One last comment I have bellow:
>
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index 35df462..227376b 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -161,6 +161,9 @@
>> interrupts = <37>;
>> clocks = <&rcc 0 164>;
>> status = "disabled";
>> + dmas = <&dma2 2 4 0x414 0x0>,
>> + <&dma2 7 4 0x414 0x0>;
>
> According to stm32-dma.txt documentation in the third parameter (32bit
> mask) only the following bits can be set : 9,10,15,16,17 and 0x414 is
> setting bits 2 and 4. It make sense if you look in the register itself
> (DMA_SxCR) but as far I could see from the DMA driver code this bits
> are set internally. The correct value should be 0x400.
Thanks for you careful review: the dma issue you noticed is due to the
fact that this bit field binding changed between kernel 4.2 and 4.8.
Front of kernel 4.2, 0x414 was fine... but now it is no more, you are
right.
I will fix it in my next pull request.
Thanks
Alex
>
>> + dma-names = "rx", "tx";
>> };
>>
>> usart6: serial at 40011400 {
.
^ permalink raw reply
* [PATCH v6 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-19 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecbc3c0d-4ce7-758d-7f7d-4b3f3003c1ac@linaro.org>
On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>
>
> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> >[...]
> >
> >>>>>We had an agreement that keep mmc's pwrseq framework unchanging.
> >>>>>Unless Ulf and rob both agree to change.
> >>>>Why 2 separate approach for same problem ?
> >>>>And I see this as possible duplication of code/functionality :)
> >>>How the new kernel compatibles old dts? If we do not need to
> >>>consider this problem, the mmc can try to use power sequence library
> >>>too in future.
> >>
> >>I think we should attempt to get both MMC and USB power seq
> >>come on one agreement, so that it can be reused.
> >That would be nice. Although, to do that you would have to allow some
> >DT bindings to be deprecated in the new generic power seq bindings, as
> >otherwise you would break existing DTBs.
> >
> >I guess that is what Rob was objecting to!?
>
> yeah, thats right.
>
> So lets adopt similar implementation for USB as well instead of
> library, but keeping MMC untouched as of now.
>
> What I am trying to propose here is,
>
> Lets have power-sequence framework (similar to V1 of this series),
> with,
>
> pwrseq: Core framework for power sequence.
> pwrseq_generic/simple: for all generic control, like reset and clock
> pwrseq_emmc: probably duplication of existing code - the idea
> here is, all future code should be using this new
> binding, so that we can deprecate the
> drivers/mmc/core/pwrseq
> pwrseq_arche: The usecase which I am dealing with today, which is more
> complex in nature.
>
> Then the respective drivers can add their drivers (if needed) based on
> complexity.
>
> comments ??
The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Arnd Bergmann @ 2016-09-19 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474259324.15220.5.camel@buserror.net>
On Sunday, September 18, 2016 11:28:44 PM CEST Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > >
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > >
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> >
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
>
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did. There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd. I did CC Shawn Guo who has been handling the
> device tree patches for these chips.
That is the right way to do it. If the DT change is a bugfix that should
get merged along with the rest, Shawn can also provide an Ack to have it
merged through the arm64 tree, ideally warning us if there might be any
conflicts with stuff that gets sent for arm-soc.
Arnd
^ permalink raw reply
* [PATCH v6 0/8] power: add power sequence library
From: Vaibhav Hiremath @ 2016-09-19 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFp0w0mBGNgu6uk7UevUka_ha6MvaVyOzXjCg3S8kdF7tg@mail.gmail.com>
On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> [...]
>
>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>> Unless Ulf and rob both agree to change.
>>>> Why 2 separate approach for same problem ?
>>>> And I see this as possible duplication of code/functionality :)
>>> How the new kernel compatibles old dts? If we do not need to
>>> consider this problem, the mmc can try to use power sequence library
>>> too in future.
>>
>> I think we should attempt to get both MMC and USB power seq
>> come on one agreement, so that it can be reused.
> That would be nice. Although, to do that you would have to allow some
> DT bindings to be deprecated in the new generic power seq bindings, as
> otherwise you would break existing DTBs.
>
> I guess that is what Rob was objecting to!?
yeah, thats right.
So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.
What I am trying to propose here is,
Lets have power-sequence framework (similar to V1 of this series),
with,
pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
here is, all future code should be using this new
binding, so that we can deprecate the
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
complex in nature.
Then the respective drivers can add their drivers (if needed) based on
complexity.
comments ??
>> MMC Power Seq :
>> It is based on platform_device/platform_driver approach,
> We recently converted MMC to this. It's has a clear benefit as you can
> rely on the behaviour from the driver core and PM core. So, it simply
> avoids duplication of code.
Agreed.
>> USB Power seq :
>> We are trying to propose library approach, with compatible string match.
>>
>> We should try to have one approach.
>>>
>>>>>> - Lets also add suspend/resume callback to struct pwrseq
>>>>>>
>>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>> Nope...
>>>> The pwrseq library would have taken ownership of resources, so
>>>> related driver cannot suspend the device. Again it is architecture
>>>> specific, but we should have provision to handle this.
>>>>
>>>> The system I am dealing with today, does need suspend/resume
>>>> callback. To be precise, suspend is close to off state for some devices
>>>> or
>>>> they could enter standby or different low power state, but to do that,
>>>> we need same resource as used for ON/OFF functionality.
>>>>
>>> Ok, I will have API for suspend/resume. You can implement it at your own
>>> library or generic one.
> As stated, using a platform device + driver would simplify this, as
> you wouldn't need an API but only a driver. I guess.
Exactly.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Arnd Bergmann @ 2016-09-19 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DF70AF.4050002@ti.com>
On Monday, September 19, 2016 10:29:27 AM CEST Kishon Vijay Abraham I wrote:
> On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> > On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >> This way the driver will be probed only once (the reset can be done during
> >> probe). The phy driver should scan the dt node and for every sub-node it
> >> invokes phy_create?
> > I'll recap what we have discussed so far (so you don't have to re-read
> > the whole thread):
> > The reference driver treats both USB PHYs as separate devices (the
> > datasheet has no information about the PHYs though). The only
> > "special" thing is the shared reset line -> together with Philipp
> > Zabel (the reset framework maintainer) we decided to make
> > reset_control_reset work for shared reset lines.
> >
> > That means we can keep the two PHYs as separate devices inside the
> > .dts, while keeping everything else separate (just like the reference
> > driver)
> > Is this fine for you and Arnd?
>
> yeah.. I'm fine with that.
>
Agreed, if we don't need to have a device modeled around both
instance, that's ideal.
Arnd
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-19 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917123756.0a05a904@arm.com>
Hi Marc , Peter
On Sat, Sep 17, 2016 at 5:07 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Sat, 17 Sep 2016 11:58:48 +0530
> Vijay Kilari <vijay.kilari@gmail.com> wrote:
>
>> On Fri, Sep 16, 2016 at 10:37 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> > On 16/09/16 17:57, Vijay Kilari wrote:
>> >> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> >>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>> >>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>>>
>> >>>> VGICv3 CPU interface registers are accessed using
>> >>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >>>> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >>>> is used to identify the cpu for registers access.
>> >>>>
>> >>>> The version of VGIC v3 specification is define here
>> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >>>>
>> >>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>>> ---
>> >>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >>>> arch/arm64/kvm/Makefile | 1 +
>> >>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>> >>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>> >>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>> >>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>> >>>> virt/kvm/arm/vgic/vgic.h | 10 ++
>> >>>> 7 files changed, 385 insertions(+)
>> >
>> > [...]
>> >
>> >>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >>>> new file mode 100644
>> >>>> index 0000000..8e4f403
>> >>>> --- /dev/null
>> >>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >>>> @@ -0,0 +1,296 @@
>> >>>> +#include <linux/irqchip/arm-gic-v3.h>
>> >>>> +#include <linux/kvm.h>
>> >>>> +#include <linux/kvm_host.h>
>> >>>> +#include <kvm/iodev.h>
>> >>>> +#include <kvm/arm_vgic.h>
>> >>>> +#include <asm/kvm_emulate.h>
>> >>>> +#include <asm/kvm_arm.h>
>> >>>> +#include <asm/kvm_mmu.h>
>> >>>> +
>> >>>> +#include "vgic.h"
>> >>>> +#include "vgic-mmio.h"
>> >>>> +#include "sys_regs.h"
>> >>>> +
>> >>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >>>> + const struct sys_reg_desc *r)
>> >>>> +{
>> >>>> + struct vgic_vmcr vmcr;
>> >>>> + u64 val;
>> >>>> + u32 ich_vtr;
>> >>>> +
>> >>>> + vgic_get_vmcr(vcpu, &vmcr);
>> >>>> + if (p->is_write) {
>> >>>> + val = p->regval;
>> >>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>> >>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>> >>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>> >>>> + vgic_set_vmcr(vcpu, &vmcr);
>> >>>
>> >>> You've ignored my comments again: "What if userspace writes something
>> >>> that is incompatible with the current configuration? Wrong number of ID
>> >>> bits, or number of priorities?"
>> >>
>> >> IMO, In case of incompatibility,
>> >> If ID bits and PRI bits are less than HW supported, it is ok.
>> >
>> > Yes. But you also need to track of what the guest has programmed in
>> > order to be able to migrate it back to its original configuration.
>>
>> You mean the vgic has to track/store the ID and PRI bits that guest
>> has programmed
>> and return the same when guest reads back instead of
>> returning HW supported value for ICC_CTLR_EL1 reg access?.
>
> If you have two hosts (A and B), A having 5 bits of priority and B
> having 7 bits, you should be able to migrate from A to B, and then from
> B to A. Which means you have to preserve what the guest knows to be its
> configuration, even if you run on a more capable system. Otherwise,
> you're a bit stuck.
>
> You probably won't be able to hide the discrepancy from inside the
> guest though (the guest will be able to observe the change), but this
> is better than nothing.
In order to track the PRI and ID bits written by guest,
VGIC needs to store these values when ICC_CTRL_EL1 is updated.
However, QEMU is reseting VGIC by writing 0's to all the
registers after VGIC initialization and hence the back up values are
always reset to 0 and hence when guest read back, VGIC returns wrong value.
One option is to drop VGIC reset from QEMU which is not doing much.
^ permalink raw reply
* [PATCH 1/1] ARM: imx5: Add clocks configuration
From: Fabien Lahoudere @ 2016-09-19 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918002451.GE15478@tiger>
Hi,
On 18/09/16 02:24, Shawn Guo wrote:
> On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
>> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
>>>> ???????, 15 ???????? 2016, 13:13 +03:00 ?? Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>:
>>>>
>>>> From: Kalle Kankare < kalle.kankare@vincit.fi >
>>>>
>>>> Add clocks configuration for CSI, FIRI and IEEE1588.
>>>>
>>>> Signed-off-by: Fabien Lahoudere < fabien.lahoudere@collabora.co.uk >
>>>> ---
>>>> drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
>>>> include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
>>>> 2 files changed, 34 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
>>>> index 29d4c44..1e3c9ea 100644
>>>> --- a/drivers/clk/imx/clk-imx51-imx53.c
>>>> +++ b/drivers/clk/imx/clk-imx51-imx53.c
>>>> @@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
>>>> static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
>>>> static const char *step_sels[] = { "lp_apm", };
>>>> static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
>>>> +static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
>>>>
>>>> static struct clk *clk[IMX5_CLK_END];
>>>> static struct clk_onecell_data clk_data;
>>>> @@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
>>> ...
>>>
>>> 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
>>> I would ask to change the subject to i.MX53 if it possible.
>>
>> Yes. Actually, since clock driver is not moved to drivers/clk, we
>
> s/not/now
>
>> shouldn't prefix it with "ARM: " any longer.
Ok is "clk: imx53: Add clocks configuration" ok?
>
> Shawn
>
Thanks
Fabien
^ 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