* Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Cyrille Pitchen @ 2017-04-12 20:57 UTC (permalink / raw)
To: Guochun Mao, Cyrille Pitchen
Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
linux-kernel, Rob Herring, linux-mtd, Matthias Brugger,
linux-mediatek, David Woodhouse, linux-arm-kernel
In-Reply-To: <1491381462-21893-2-git-send-email-guochun.mao@mediatek.com>
Hi Guochun,
Le 05/04/2017 à 10:37, Guochun Mao a écrit :
> When nor's size larger than 16MByte, nor's address width maybe
> set to 3 or 4, and controller should change address width according
> to nor's setting.
>
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
> drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> index e661877..b637770 100644
> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> @@ -104,6 +104,8 @@
> #define MTK_NOR_MAX_RX_TX_SHIFT 6
> /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
> #define MTK_NOR_MAX_SHIFT 7
> +/* nor controller 4-byte address mode enable bit */
> +#define MTK_NOR_4B_ADDR_EN BIT(4)
>
> /* Helpers for accessing the program data / shift data registers */
> #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
> @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
> 10000);
> }
>
> +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
> +{
> + u8 val;
> + struct spi_nor *nor = &mt8173_nor->nor;
> +
> + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
> +
> + switch (nor->addr_width) {
> + case 3:
> + val &= ~MTK_NOR_4B_ADDR_EN;
> + break;
> + case 4:
> + val |= MTK_NOR_4B_ADDR_EN;
> + break;
> + default:
> + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
> + nor->addr_width);
> + break;
> + }
> +
> + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
> +}
> +
> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> {
> int i;
>
> + mt8173_nor_set_addr_width(mt8173_nor);
> +
> for (i = 0; i < 3; i++) {
Should it be 'i < nor->addr_width' instead of 'i < 3' ?
Does it work when accessing data after 128Mbit ?
Best regards,
Cyrille
> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
> addr >>= 8;
>
^ permalink raw reply
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Florian Fainelli @ 2017-04-12 21:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <6de72d4c-5634-f3d6-5bfd-fcc0acda0b83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/11/2017 04:23 PM, Florian Fainelli wrote:
> On 04/11/2017 04:14 PM, Andrew Lunn wrote:
>>> To give some more background and rational for this change.
>>>
>>> On a platform where we have a parent MDIO bus, backed by the
>>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through
>>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an
>>> assignment of of_node. This slave MII bus is created in order to
>>> intercept reads/writes to problematic addresses (e.g: that clashes with
>>> another piece of hardware).
>>>
>>> This means that the slave DSA MII bus inherits all child nodes from the
>>> originating master MII bus. This also means that when the slave MII bus
>>> is probed via of_mdiobus_register(), we probe the same devices twice:
>>> once through the master, another time through the slave.
>>
>> Ah, O.K. This makes more sense. On the hardware i have, we get three
>> deep in MDIO busses. We have the FEC mdio bus. On top of that we have
>> a gpio-mux-mdio, and on top of that we have the mv88e6xxx mdio
>> bus. And i've never seen issues.
>>
>> So your real problem here is you have two mdio busses using the same
>> device tree properties. I would actually say that is just plain
>> broken.
>
> From a Device Tree/HW representation perspective, we do have the
> external BCM53125 switch physically attached to the 7445/7278
> SWITCH_MDIO bus (backed by mdio-bcm-unimac) so in that regard the
> representation is correct. There is also an integrated Gigabit PHY
> (bcm7xxx) which is attached to that bus.
>
> From a SW perspective though, we want to talk to the integrated Gigabit
> PHY using mdio-bcm-unimac but talk to the external BCM53125 switch using
> the slave MII bus created by the bcm_sf2 driver in order to create an
> isolation. We need to inherit some of the parent (mdio-bcm-unimac) child
> DT nodes (such as the BCM53125), but not the GPHY. The easiest solution
> I found was to use this patch.
>
> Using mdiobus_register() instead of of_mdiobus_register() was
> considered, but then, the child BCM53125 has no more "visbility" into
> the OF world at all, and it matters, because this switch is also driven
> via a DSA switch driver and its Ethernet data-path is connected to one
> port of the bcm_sf2 switch..
>
> Thankfully the HW bug was fixed eventually ;)
In fact, all I need is to flag the internal Gigabit PHY for the slave
MII bus node with something that makes it appear as "disabled" which I
can presumably do with of_update_property() and putting a status =
"disabled" property in there. Let me do something like that and see how
big of a hack this becomes.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Andrew Lunn @ 2017-04-12 22:10 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <417fdaa1-7aba-e646-8a50-043322f1410d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>> To give some more background and rational for this change.
> >>>
> >>> On a platform where we have a parent MDIO bus, backed by the
> >>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through
> >>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an
> >>> assignment of of_node. This slave MII bus is created in order to
> >>> intercept reads/writes to problematic addresses (e.g: that clashes with
> >>> another piece of hardware).
> >>>
> >>> This means that the slave DSA MII bus inherits all child nodes from the
> >>> originating master MII bus. This also means that when the slave MII bus
> >>> is probed via of_mdiobus_register(), we probe the same devices twice:
> >>> once through the master, another time through the slave.
> >>
> >> Ah, O.K. This makes more sense. On the hardware i have, we get three
> >> deep in MDIO busses. We have the FEC mdio bus. On top of that we have
> >> a gpio-mux-mdio, and on top of that we have the mv88e6xxx mdio
> >> bus. And i've never seen issues.
> >>
> >> So your real problem here is you have two mdio busses using the same
> >> device tree properties. I would actually say that is just plain
> >> broken.
> >
> > From a Device Tree/HW representation perspective, we do have the
> > external BCM53125 switch physically attached to the 7445/7278
> > SWITCH_MDIO bus (backed by mdio-bcm-unimac) so in that regard the
> > representation is correct. There is also an integrated Gigabit PHY
> > (bcm7xxx) which is attached to that bus.
This is made harder by you talking about a board which does not appear
to have its DT file in mainline. So i'm having to guess what it looks
like.
So what i think we are talking about is this bit of code:
static int bcm_sf2_mdio_register(struct dsa_switch *ds)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
struct device_node *dn;
static int index;
int err;
/* Find our integrated MDIO bus node */
dn = of_find_compatible_node(NULL, NULL, "brcm,unimac-mdio");
priv->master_mii_bus = of_mdio_find_bus(dn);
if (!priv->master_mii_bus)
return -EPROBE_DEFER;
get_device(&priv->master_mii_bus->dev);
priv->master_mii_dn = dn;
priv->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
if (!priv->slave_mii_bus)
return -ENOMEM;
priv->slave_mii_bus->priv = priv;
priv->slave_mii_bus->name = "sf2 slave mii";
priv->slave_mii_bus->read = bcm_sf2_sw_mdio_read;
priv->slave_mii_bus->write = bcm_sf2_sw_mdio_write;
snprintf(priv->slave_mii_bus->id, MII_BUS_ID_SIZE, "sf2-%d",
index++);
priv->slave_mii_bus->dev.of_node = dn;
If i get you right, your switch is hanging off the MDIO bus
"brcm,unimac-mdio" you find the dn for. You then register another MDIO
bus using the exact same node? How does that make any sense? Isn't it
a physical separate MDIO bus? So it should have its own set of nodes
in the device tree. This is how we do it for the Marvell switches. See
Documentation/devicetree/binding/net/dsa/marvell.txt and
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts. That DT blob uses
phy-handle to link the switch ports to the phys on the mdio bus.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: stm32f7: add stm32f769I & stm32f746 discovery board support
From: Vikas Manocha @ 2017-04-12 23:50 UTC (permalink / raw)
To: alexandre.torgue-qxv4g6HH51o, patrice.chotard-qxv4g6HH51o
Cc: Vikas Manocha,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list, Mark Rutland, Maxime Coquelin,
Rob Herring, Russell King
Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major
specs of the two boards:
stm32f769I discovery board:
- Cortex-M7 core @216MHz
- 2MB mcu internal flash
- 512KB internal sram
- 16MB sdram memory
- 64MB qspi flash memory
- 4 inch wvga LCD-TFT Display
stm32f746 discovery board:
- Cortex-M7 core @216MHz
- 1MB mcu internal flash
- 320KB internal sram
- 8MB sdram memory
- 16MB qspi flash memory
- 4.3 inch 480x272 LCD-TFT display
Signed-off-by: Vikas Manocha <vikas.manocha-qxv4g6HH51o@public.gmane.org>
---
Changed in v2:
- moved pin muxing from board dts file to dtsi file.
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/stm32f746-disco.dts | 74 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/stm32f746.dtsi | 12 ++++++
arch/arm/boot/dts/stm32f769-disco.dts | 74 +++++++++++++++++++++++++++++++++++
4 files changed, 162 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32f746-disco.dts
create mode 100644 arch/arm/boot/dts/stm32f769-disco.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..a119f74 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -763,6 +763,8 @@ dtb-$(CONFIG_ARCH_STI) += \
dtb-$(CONFIG_ARCH_STM32)+= \
stm32f429-disco.dtb \
stm32f469-disco.dtb \
+ stm32f746-disco.dtb \
+ stm32f769-disco.dtb \
stm32429i-eval.dtb \
stm32746g-eval.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/boot/dts/stm32f746-disco.dts b/arch/arm/boot/dts/stm32f746-disco.dts
new file mode 100644
index 0000000..55afae9
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f746-disco.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "STMicroelectronics STM32F746-DISCO board";
+ compatible = "st,stm32f746-disco", "st,stm32f746";
+
+ chosen {
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0xC0000000 0x800000>;
+ };
+
+ aliases {
+ serial0 = &usart1;
+ };
+
+};
+
+&clk_hse {
+ clock-frequency = <25000000>;
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_pa9_pa10>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..1064fb1 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -287,6 +287,18 @@
bias-disable;
};
};
+ usart1_pins_pa9_pa10: usart1@1 {
+ pins1 {
+ pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32F746_PA10_FUNC_USART1_RX>;
+ bias-disable;
+ };
+ };
};
rcc: rcc@40023800 {
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
new file mode 100644
index 0000000..166728a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "STMicroelectronics STM32F769-DISCO board";
+ compatible = "st,stm32f769-disco", "st,stm32f7";
+
+ chosen {
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0xC0000000 0x1000000>;
+ };
+
+ aliases {
+ serial0 = &usart1;
+ };
+
+};
+
+&clk_hse {
+ clock-frequency = <25000000>;
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Florian Fainelli @ 2017-04-12 23:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20170412221016.GA29708-g2DYL2Zd6BY@public.gmane.org>
On 04/12/2017 03:10 PM, Andrew Lunn wrote:
>>>>> To give some more background and rational for this change.
>>>>>
>>>>> On a platform where we have a parent MDIO bus, backed by the
>>>>> mdio-bcm-unimac.c driver, we also register a slave MII bus (through
>>>>> net/dsa/dsa2.c) which is parented to this UniMAC MDIO bus through an
>>>>> assignment of of_node. This slave MII bus is created in order to
>>>>> intercept reads/writes to problematic addresses (e.g: that clashes with
>>>>> another piece of hardware).
>>>>>
>>>>> This means that the slave DSA MII bus inherits all child nodes from the
>>>>> originating master MII bus. This also means that when the slave MII bus
>>>>> is probed via of_mdiobus_register(), we probe the same devices twice:
>>>>> once through the master, another time through the slave.
>>>>
>>>> Ah, O.K. This makes more sense. On the hardware i have, we get three
>>>> deep in MDIO busses. We have the FEC mdio bus. On top of that we have
>>>> a gpio-mux-mdio, and on top of that we have the mv88e6xxx mdio
>>>> bus. And i've never seen issues.
>>>>
>>>> So your real problem here is you have two mdio busses using the same
>>>> device tree properties. I would actually say that is just plain
>>>> broken.
>>>
>>> From a Device Tree/HW representation perspective, we do have the
>>> external BCM53125 switch physically attached to the 7445/7278
>>> SWITCH_MDIO bus (backed by mdio-bcm-unimac) so in that regard the
>>> representation is correct. There is also an integrated Gigabit PHY
>>> (bcm7xxx) which is attached to that bus.
>
> This is made harder by you talking about a board which does not appear
> to have its DT file in mainline. So i'm having to guess what it looks
> like.
The DT binding is in tree and provides an example of how the switch
looks like, below is the example, but I am also adding the MDIO bus and
the PHYs just so you can see how things wind up:
switch_top@f0b00000 {
compatible = "simple-bus";
#size-cells = <1>;
#address-cells = <1>;
ranges = <0 0xf0b00000 0x40804>;
ethernet_switch@0 {
compatible = "brcm,bcm7445-switch-v4.0";
#size-cells = <0>;
#address-cells = <1>;
reg = <0x0 0x40000
0x40000 0x110
0x40340 0x30
0x40380 0x30
0x40400 0x34
0x40600 0x208>;
reg-names = "core", "reg", intrl2_0", "intrl2_1",
"fcb, "acb";
interrupts = <0 0x18 0
0 0x19 0>;
brcm,num-gphy = <1>;
brcm,num-rgmii-ports = <2>;
brcm,fcb-pause-override;
brcm,acb-packets-inflight;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
label = "gphy";
reg = <0>;
phy-handle = <&phy5>;
};
sw0port1: port@1 {
label = "rgmii_1";
reg = <1>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
}
};
};
mdio@403c0 {
reg = <0x403c0 0x8 0x40300 0x18>;
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "brcm,unimac-mdio";
reg-names = "mdio", "mdio_indir_rw";
switch: switch@0 {
broken-turn-around;
reg = <0x0>;
compatible = "brcm,bcm53125";
#address-cells = <1>;
#size-cells = <0>;
ports {
..
port@8 {
ethernet = <&sw0port1>;
};
...
};
};
phy5: ethernet-phy@5 {
reg = <0x5>;
compatible = "ethernet-phy-ieee802.3-c22";
};
};
};
>
> So what i think we are talking about is this bit of code:
>
> static int bcm_sf2_mdio_register(struct dsa_switch *ds)
> {
> struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
> struct device_node *dn;
> static int index;
> int err;
>
> /* Find our integrated MDIO bus node */
> dn = of_find_compatible_node(NULL, NULL, "brcm,unimac-mdio");
> priv->master_mii_bus = of_mdio_find_bus(dn);
> if (!priv->master_mii_bus)
> return -EPROBE_DEFER;
>
> get_device(&priv->master_mii_bus->dev);
> priv->master_mii_dn = dn;
>
> priv->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
> if (!priv->slave_mii_bus)
> return -ENOMEM;
>
> priv->slave_mii_bus->priv = priv;
> priv->slave_mii_bus->name = "sf2 slave mii";
> priv->slave_mii_bus->read = bcm_sf2_sw_mdio_read;
> priv->slave_mii_bus->write = bcm_sf2_sw_mdio_write;
> snprintf(priv->slave_mii_bus->id, MII_BUS_ID_SIZE, "sf2-%d",
> index++);
> priv->slave_mii_bus->dev.of_node = dn;
>
> If i get you right, your switch is hanging off the MDIO bus
> "brcm,unimac-mdio" you find the dn for. You then register another MDIO
> bus using the exact same node? How does that make any sense? Isn't it
> a physical separate MDIO bus?
First, the main switch is memory mapped into the 7445 SoC's register
space. This switch has an external MDIO bus which connects to an
integrated Gigabit PHY at MDIO address 5, but also to a BCM53125 switch
at address 30.
Because of a bug in the D0 revision of the 7445, programming the
BCM53125 switch through MDIO ends-up programming the 7445 memory mapped
switch as well because the integrated 7445 switch has its pseudo-PHY
snooping accesses to the MDIO bus! What was done to work-around this is
to create a slave MII bus through DSA, and divert the reads/writes
from/to the BCM53125 by instead using internal 7445 switch registers
which isolate its pseudo-PHY from the MDIO bus, thus no double
programming anymore.
Since the BCM53125 switch is a) physically attached to the mdio@403c0
node, and b) needs to have visibility in the OF world for DSA to probe
it, this is what I did here.
The slave MII bus is using the same node here because that's the
simplest way to make this bus inherit the devices of interest from the
parent bus.
> So it should have its own set of nodes
> in the device tree. This is how we do it for the Marvell switches. See
> Documentation/devicetree/binding/net/dsa/marvell.txt and
> arch/arm/boot/dts/vf610-zii-dev-rev-b.dts. That DT blob uses
> phy-handle to link the switch ports to the phys on the mdio bus.
>From a pure HW representation, this is not quite correct, because the
switch is physically attached to mdio@403c0, but since we are
pathologically broken, we need something different here...
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support
From: Vikas MANOCHA @ 2017-04-13 0:03 UTC (permalink / raw)
To: Alexandre TORGUE, Patrice CHOTARD
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list, Mark Rutland, Maxime Coquelin,
Rob Herring, Russell King
In-Reply-To: <e6592982-9c24-bfde-469b-770218bf88be-qxv4g6HH51o@public.gmane.org>
Hi Alex,
> -----Original Message-----
> From: Alexandre TORGUE
> Sent: Tuesday, April 11, 2017 12:51 AM
> To: Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>; Patrice CHOTARD <patrice.chotard-qxv4g6HH51o@public.gmane.org>
> Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; moderated list:ARM PORT
> <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Maxime
> Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> Subject: Re: [PATCH] ARM: dts: stm32f7: add STM32f769I & stm32f746 discovery board support
>
> Hi Vikas
>
> On 04/10/2017 08:40 PM, Vikas Manocha wrote:
> > Thanks Alex,
> >
> > On 04/10/2017 12:23 AM, Alexandre Torgue wrote:
> >> Hi
> >>
> >> On 04/08/2017 03:12 AM, Vikas Manocha wrote:
> >>> Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the
> >>> major spces of the two boards:
> >>>
> >>> stm32f769I discovery board:
> >>> - Cortex-M7 core @216MHz
> >>> - 2MB mcu internal flash
> >>> - 512KB internal sram
> >>> - 16MB sdram memory
> >>> - 64MB qspi flash memory
> >>> - 4 inch wvga LCD-TFT Display
> >>>
> >>> stm32f746 discovery board:
> >>> - Cortex-M7 core @216MHz
> >>> - 1MB mcu internal flash
> >>> - 320KB internal sram
> >>> - 8MB sdram memory
> >>> - 16MB qspi flash memory
> >>> - 4.3 inch 480x272 LCD-TFT display
> >>>
> >>> Signed-off-by: Vikas Manocha <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> >>> ---
> >>> arch/arm/boot/dts/Makefile | 2 +
> >>> arch/arm/boot/dts/stm32f746-disco.dts | 101 ++++++++++++++++++++++++++++++++++
> >>> arch/arm/boot/dts/stm32f746.dtsi | 2 +-
> >>> arch/arm/boot/dts/stm32f769-disco.dts | 101
> >>> ++++++++++++++++++++++++++++++++++
> >>> 4 files changed, 205 insertions(+), 1 deletion(-) create mode
> >>> 100644 arch/arm/boot/dts/stm32f746-disco.dts
> >>> create mode 100644 arch/arm/boot/dts/stm32f769-disco.dts
> >>>
> >>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>> index 0118084..a119f74 100644
> >>> --- a/arch/arm/boot/dts/Makefile
> >>> +++ b/arch/arm/boot/dts/Makefile
> >>> @@ -763,6 +763,8 @@ dtb-$(CONFIG_ARCH_STI) += \
> >>> dtb-$(CONFIG_ARCH_STM32)+= \
> >>> stm32f429-disco.dtb \
> >>> stm32f469-disco.dtb \
> >>> + stm32f746-disco.dtb \
> >>> + stm32f769-disco.dtb \
> >>> stm32429i-eval.dtb \
> >>> stm32746g-eval.dtb
> >>> dtb-$(CONFIG_MACH_SUN4I) += \
> >>> diff --git a/arch/arm/boot/dts/stm32f746-disco.dts
> >>> b/arch/arm/boot/dts/stm32f746-disco.dts
> >>> new file mode 100644
> >>> index 0000000..c0e313f
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/stm32f746-disco.dts
> >>> @@ -0,0 +1,101 @@
> >>> +/*
> >>> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> >>> + *
> >>> + * This file is dual-licensed: you can use it either under the
> >>> +terms
> >>> + * of the GPL or the X11 license, at your option. Note that this
> >>> +dual
> >>> + * licensing only applies to this file, and not this project as a
> >>> + * whole.
> >>> + *
> >>> + * a) This file 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.
> >>> + *
> >>> + * This file is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>> + * GNU General Public License for more details.
> >>> + *
> >>> + * Or, alternatively,
> >>> + *
> >>> + * b) Permission is hereby granted, free of charge, to any person
> >>> + * obtaining a copy of this software and associated documentation
> >>> + * files (the "Software"), to deal in the Software without
> >>> + * restriction, including without limitation the rights to use,
> >>> + * copy, modify, merge, publish, distribute, sublicense, and/or
> >>> + * sell copies of the Software, and to permit persons to whom the
> >>> + * Software is furnished to do so, subject to the following
> >>> + * conditions:
> >>> + *
> >>> + * The above copyright notice and this permission notice shall be
> >>> + * included in all copies or substantial portions of the Software.
> >>> + *
> >>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >>> + * OTHER DEALINGS IN THE SOFTWARE.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "stm32f746.dtsi"
> >>> +#include <dt-bindings/input/input.h>
> >>> +
> >>> +/ {
> >>> + model = "STMicroelectronics STM32F746-DISCO board";
> >>> + compatible = "st,stm32f746-disco", "st,stm32f746";
> >>> +
> >>> + chosen {
> >>> + bootargs = "root=/dev/ram";
> >>> + stdout-path = "serial0:115200n8";
> >>> + };
> >>> +
> >>> + memory {
> >>> + reg = <0xC0000000 0x800000>;
> >>> + };
> >>> +
> >>> + aliases {
> >>> + serial0 = &usart1;
> >>> + };
> >>> +
> >>> +};
> >>> +
> >>> +&clk_hse {
> >>> + clock-frequency = <25000000>;
> >>> +};
> >>> +
> >>> +&pinctrl {
> >>
> >>
> >> Pin muxing is not defined in board file. Please move it into SOC dtsi file.
Ok, I will move pin muxing in the stm32f746.dtsi file as per current implementation & send V2.
> >
> > Pin muxing used is different for different boards. e.g. usart1_rx pad is PA10 for stm32f769-disco board while it is PB7 for stm32f746-
> disco board.
> > The other possibilities for same pad (usart1_rx) is PB15. To make situation bit more complex, it is only available in f769 device.
> >
> > Putting in SOC dtsi file means having lot of combinations for different pins in separate groups.
> > e.g. only for one instance of one ip (usart1), following groups might be required at one point of time:
> >
> > usart1_pa10_pa9 {..}
> > usart1_pa10_pb14 {..}
> > usart1_pa10_pb6 {..}
> >
> > usart1_pb7_pa9 {..}
> > usart1_pb7_pb14 {..}
> > usart1_pb7_pb6 {..}
> >
> > usart1_pb15_pa9 {..}
> > usart1_pb15_pb14 {..}
> > usart1_pb15_pb6 {..}
> >
> > In case of boards based on stm32f746 device, all the above mentioned groups with pb14 & pb15 will not be available.
> > One solution (to avoid using not available groups) could be to have separate dtsi (or separate pinmux.dtsi) for different devices of
> same family like one for stm32f746 & other for stm32f769. Still it does not resolve the need to have lot of groups combinations for
> each instance of every peripheral in dtsi as mentioned above.
>
> Yes, it is what I want to have. I did the job on for STM32F4 (F429 / F469). You could have a look on ARM Linux patchwork:
> https://patchwork.kernel.org/patch/9669433/
>
> To sum-up the implementation:
>
> -Pinmuxing is defined in separate files which will be included in board dts file.
>
> -We have a common pinmuxing file + a dedicated pinmuxing file per SOC.
>
> Example for STMF469-disco:
> stm32f4-pinctrl.dtsi --> stm32f469-pinctrl.dtsi --> stm32f469-disco.dts
>
> stm32f4-pinctrl.dtsi contains common pinmuxing bindings between STM32F4 stm32f469-pinctrl.dtsi contains dedicated pinmuxing
> bindings for
> STM32F469 (ex: QSPI pins, gpio-ranges ...)
>
> This implementation is under review.
Sounds good.
Cheers,
Vikas
>
>
> > It seems cleaner solution would be pin muxing in board dts file. Please let me know if there is some drawback of this approach. One
> point which i can think of is : duplication of pinmux groups in different board dts files.
>
> Pinmuxing in board file is currently not my choice. In the board file we only select the group to use.
>
> Regards
> Alex
>
>
> >
> > Cheers,
> > Vikas
> >
> >>> + usart1_pins: usart1@0 {
> >>> + pins1 {
> >>> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> >>> + bias-disable;
> >>> + drive-push-pull;
> >>> + slew-rate = <2>;
> >>> + };
> >>> + pins2 {
> >>> + pinmux = <STM32F746_PB7_FUNC_USART1_RX>;
> >>> + bias-disable;
> >>> + };
> >>> + };
> >>> +
> >>> + qspi_pins: qspi@0 {
> >>> + pins {
> >>> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> >>> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> >>> + <STM32F746_PD11_FUNC_QUADSPI_BK1_IO0>,
> >>> + <STM32F746_PD12_FUNC_QUADSPI_BK1_IO1>,
> >>> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> >>> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> >>> + slew-rate = <2>;
> >>> + };
> >>> + };
> >>> +};
> >>> +
> >>> +&usart1 {
> >>> + pinctrl-0 = <&usart1_pins>;
> >>> + pinctrl-names = "default";
> >>> + status = "okay";
> >>> +};
> >>> diff --git a/arch/arm/boot/dts/stm32f746.dtsi
> >>> b/arch/arm/boot/dts/stm32f746.dtsi
> >>> index f321ffe..826700f 100644
> >>> --- a/arch/arm/boot/dts/stm32f746.dtsi
> >>> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> >>> @@ -178,7 +178,7 @@
> >>> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> >>> };
> >>>
> >>> - pin-controller {
> >>> + pinctrl: pin-controller {
> >>> #address-cells = <1>;
> >>> #size-cells = <1>;
> >>> compatible = "st,stm32f746-pinctrl"; diff --git
> >>> a/arch/arm/boot/dts/stm32f769-disco.dts
> >>> b/arch/arm/boot/dts/stm32f769-disco.dts
> >>> new file mode 100644
> >>> index 0000000..5f8558e
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> >>> @@ -0,0 +1,101 @@
> >>> +/*
> >>> + * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
> >>> + *
> >>> + * This file is dual-licensed: you can use it either under the
> >>> +terms
> >>> + * of the GPL or the X11 license, at your option. Note that this
> >>> +dual
> >>> + * licensing only applies to this file, and not this project as a
> >>> + * whole.
> >>> + *
> >>> + * a) This file 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.
> >>> + *
> >>> + * This file is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>> + * GNU General Public License for more details.
> >>> + *
> >>> + * Or, alternatively,
> >>> + *
> >>> + * b) Permission is hereby granted, free of charge, to any person
> >>> + * obtaining a copy of this software and associated documentation
> >>> + * files (the "Software"), to deal in the Software without
> >>> + * restriction, including without limitation the rights to use,
> >>> + * copy, modify, merge, publish, distribute, sublicense, and/or
> >>> + * sell copies of the Software, and to permit persons to whom the
> >>> + * Software is furnished to do so, subject to the following
> >>> + * conditions:
> >>> + *
> >>> + * The above copyright notice and this permission notice shall be
> >>> + * included in all copies or substantial portions of the Software.
> >>> + *
> >>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >>> + * OTHER DEALINGS IN THE SOFTWARE.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "stm32f746.dtsi"
> >>> +#include <dt-bindings/input/input.h>
> >>> +
> >>> +/ {
> >>> + model = "STMicroelectronics STM32F769-DISCO board";
> >>> + compatible = "st,stm32f769-disco", "st,stm32f7";
> >>> +
> >>> + chosen {
> >>> + bootargs = "root=/dev/ram";
> >>> + stdout-path = "serial0:115200n8";
> >>> + };
> >>> +
> >>> + memory {
> >>> + reg = <0xC0000000 0x1000000>;
> >>> + };
> >>> +
> >>> + aliases {
> >>> + serial0 = &usart1;
> >>> + };
> >>> +
> >>> +};
> >>> +
> >>> +&clk_hse {
> >>> + clock-frequency = <25000000>;
> >>> +};
> >>> +
> >>> +&pinctrl {
> >>
> >> same.
> >>
> >>> + usart1_pins: usart1@0 {
> >>> + pins1 {
> >>> + pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
> >>> + bias-disable;
> >>> + drive-push-pull;
> >>> + slew-rate = <2>;
> >>> + };
> >>> + pins2 {
> >>> + pinmux = <STM32F746_PA10_FUNC_USART1_RX>;
> >>> + bias-disable;
> >>> + };
> >>> + };
> >>> +
> >>> + qspi_pins: qspi@0 {
> >>> + pins {
> >>> + pinmux = <STM32F746_PB2_FUNC_QUADSPI_CLK>,
> >>> + <STM32F746_PB6_FUNC_QUADSPI_BK1_NCS>,
> >>> + <STM32F746_PC9_FUNC_QUADSPI_BK1_IO0>,
> >>> + <STM32F746_PC10_FUNC_QUADSPI_BK1_IO1>,
> >>> + <STM32F746_PD13_FUNC_QUADSPI_BK1_IO3>,
> >>> + <STM32F746_PE2_FUNC_QUADSPI_BK1_IO2>;
> >>> + slew-rate = <2>;
> >>> + };
> >>> + };
> >>> +};
> >>> +
> >>> +&usart1 {
> >>> + pinctrl-0 = <&usart1_pins>;
> >>> + pinctrl-names = "default";
> >>> + status = "okay";
> >>> +};
> >>>
> >> .
> >>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-13 0:26 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Greg Kroah-Hartman, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Rob Herring
In-Reply-To: <C16140C4-0264-411B-9058-0B9013AAC82F-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]
Hi Marcel,
On Wed, Apr 12, 2017 at 10:19:21PM +0200, Marcel Holtmann wrote:
> Hi Sebastian,
>
> >>>>>>>> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >>>>>>>> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >>>>>>>> they were queued by Tony. I also changed the patch order, so that the serdev
> >>>>>>>> patches come first. All of them have Acked-by from Rob, so I think it makes
> >>>>>>>> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >>>>>>>> for the bluetooth subsystem.
> >>>>>>>
> >>>>>>> Greg doesn't read cover letters generally and since the serdev patches
> >>>>>>> are Cc rather than To him, he's probably not planning to pick them up.
> >>>>>>
> >>>>>> I wonder actually if we should merge all of these via bluetooth-next
> >>>>>> tree with proper Ack from Greg. However it would be good to also get
> >>>>>> buy in from Dave for merging this ultimately through net-next.
> >>>>>
> >>>>> I don't really care where it goes. I can take the whole thing in my
> >>>>> tty/serial tree now if no one objects and I get an ack from the relevant
> >>>>> maintainers {hint...}
> >>>>
> >>>> I think it is better if it goes thru BT tree. I have another driver
> >>>> converted that is dependent on this series. There's a couple other
> >>>> serdev changes on the list too, but this shouldn't depend on them.
> >>>
> >>> Is this waiting for something, or could it be queued to
> >>> bluetooth-next then? It would be nice to finally have
> >>> this in 4.12 :)
> >>
> >> I would prefer if we can get an ACK from Greg. Then I merge it through the bluetooth-next tree.
> >
> > Sorry thought this was coming through mine:
> > Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> >
> > Merge away!
>
> so I have applied patches 1-8 to bluetooth-next tree.
>
> The last 2 I left out since they do cause build issues on non-DT
> platforms. We need to be able to build the driver on all platforms
> so that sanity compile checks happen all the time.
>
> CC drivers/bluetooth/hci_nokia.o
> drivers/bluetooth/hci_nokia.c:802:34: error: array type has incomplete element type ‘struct of_device_id’
> static const struct of_device_id nokia_bluetooth_of_match[] = {
> ^~~~~~~~~~~~~~~~~~~~~~~~
> drivers/bluetooth/hci_nokia.c:803:4: error: field name not in record or union initializer
> { .compatible = "nokia,h4p-bluetooth", },
> ^
> drivers/bluetooth/hci_nokia.c:803:4: note: (near initialization for ‘nokia_bluetooth_of_match’)
> drivers/bluetooth/hci_nokia.c:815:21: error: implicit declaration of function ‘of_match_ptr’ [-Werror=implicit-function-declaration]
> .of_match_table = of_match_ptr(nokia_bluetooth_of_match),
> ^~~~~~~~~~~~
> drivers/bluetooth/hci_nokia.c:802:34: warning: ‘nokia_bluetooth_of_match’ defined but not used [-Wunused-variable]
> static const struct of_device_id nokia_bluetooth_of_match[] = {
> ^~~~~~~~~~~~~~~~~~~~~~~~
Building without CONFIG_OF should work already. Note, that its
actually enabled in your build, since nokia_bluetooth_of_match
is guarded by "#ifdef CONFIG_OF". The actual problem is, that
<linux/of.h> is not included in your build. Looks like it was
implicitly included in my configurations, so I didn't notice.
I will send PATCHv4 with the added include and includes sorted
alphabetically.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCHv4 0/2] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-13 0:26 UTC (permalink / raw)
To: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Rob Herring
Cc: Pavel Machek, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi,
Here is the fourth revision of the nokia bluetooth patchset. Compared
to the previous one the following things have changed:
* Drop patch 1-8 (applied by Marcel) and update Cc/To for patchset
* Order includes in the driver alphabetically
* Explicitly include <linux/of.h> in the nokia bluetooth driver
-- Sebastian
Sebastian Reichel (2):
dt-bindings: net: bluetooth: Add nokia-bluetooth
Bluetooth: add nokia driver
.../devicetree/bindings/net/nokia-bluetooth.txt | 51 ++
drivers/bluetooth/Kconfig | 12 +
drivers/bluetooth/Makefile | 2 +
drivers/bluetooth/hci_nokia.c | 820 +++++++++++++++++++++
4 files changed, 885 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/nokia-bluetooth.txt
create mode 100644 drivers/bluetooth/hci_nokia.c
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv4 1/2] dt-bindings: net: bluetooth: Add nokia-bluetooth
From: Sebastian Reichel @ 2017-04-13 0:26 UTC (permalink / raw)
To: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Rob Herring
Cc: Pavel Machek, linux-bluetooth, devicetree, linux-kernel
In-Reply-To: <20170413002659.25821-1-sre@kernel.org>
Add binding document for serial bluetooth chips using
Nokia H4+ protocol.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
---
Changes since PATCHv1:
* change compatible strings
* mention active high/low state for GPIOs
---
.../devicetree/bindings/net/nokia-bluetooth.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/nokia-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/nokia-bluetooth.txt b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
new file mode 100644
index 000000000000..42be7dc9a70b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nokia-bluetooth.txt
@@ -0,0 +1,51 @@
+Nokia Bluetooth Chips
+---------------------
+
+Nokia phones often come with UART connected bluetooth chips from different
+vendors and modified device API. Those devices speak a protocol named H4+
+(also known as h4p) by Nokia, which is similar to the H4 protocol from the
+Bluetooth standard. In addition to the H4 protocol it specifies two more
+UART status lines for wakeup of UART transceivers to improve power management
+and a few new packet types used to negotiate uart speed.
+
+Required properties:
+
+ - compatible: should contain "nokia,h4p-bluetooth" as well as one of the following:
+ * "brcm,bcm2048-nokia"
+ * "ti,wl1271-bluetooth-nokia"
+ - reset-gpios: GPIO specifier, used to reset the BT module (active low)
+ - bluetooth-wakeup-gpios: GPIO specifier, used to wakeup the BT module (active high)
+ - host-wakeup-gpios: GPIO specifier, used to wakeup the host processor (active high)
+ - clock-names: should be "sysclk"
+ - clocks: should contain a clock specifier for every name in clock-names
+
+Optional properties:
+
+ - None
+
+Example:
+
+/ {
+ /* controlled (enabled/disabled) directly by BT module */
+ bluetooth_clk: vctcxo {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+
+ bluetooth {
+ compatible = "ti,wl1271-bluetooth-nokia", "nokia,h4p-bluetooth";
+
+ reset-gpios = <&gpio1 26 GPIO_ACTIVE_LOW>; /* gpio26 */
+ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* gpio101 */
+ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* gpio37 */
+
+ clocks = <&bluetooth_clk>;
+ clock-names = "sysclk";
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCHv4 2/2] Bluetooth: add nokia driver
From: Sebastian Reichel @ 2017-04-13 0:26 UTC (permalink / raw)
To: Sebastian Reichel, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Rob Herring
Cc: Pavel Machek, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170413002659.25821-1-sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
This adds a driver for the Nokia H4+ protocol, which is used
at least on the Nokia N9, N900 & N950.
Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes since PATCHv1:
* replace __u8 and uint8_t with u8
* replace __u16 and uint16_t with u16
* drop BT_BAUDRATE_DIVIDER and use btdev->sysclk_speed * 10 instead
* fix wording of a sentence
* fix error path of negotation & alive package receive functions
* replaced nokia_wait_for_cts with newly introduced serdev function
* use "nokia,h4p-bluetooth" as compatible string
Changes since PATCHv3:
* order includes alphabetically
* explicitly include <linux/of.h>
---
drivers/bluetooth/Kconfig | 12 +
drivers/bluetooth/Makefile | 2 +
drivers/bluetooth/hci_nokia.c | 820 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 834 insertions(+)
create mode 100644 drivers/bluetooth/hci_nokia.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index c2c14a12713b..2e3e4d3547ad 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -86,6 +86,18 @@ config BT_HCIUART_H4
Say Y here to compile support for HCI UART (H4) protocol.
+config BT_HCIUART_NOKIA
+ tristate "UART Nokia H4+ protocol support"
+ depends on BT_HCIUART
+ depends on SERIAL_DEV_BUS
+ depends on PM
+ help
+ Nokia H4+ is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for Bluetooth devices
+ with UART interface in Nokia devices.
+
+ Say Y here to compile support for Nokia's H4+ protocol.
+
config BT_HCIUART_BCSP
bool "BCSP protocol support"
depends on BT_HCIUART
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index fd571689eed6..a7f237320f4b 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -25,6 +25,8 @@ obj-$(CONFIG_BT_BCM) += btbcm.o
obj-$(CONFIG_BT_RTL) += btrtl.o
obj-$(CONFIG_BT_QCA) += btqca.o
+obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
+
btmrvl-y := btmrvl_main.o
btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
diff --git a/drivers/bluetooth/hci_nokia.c b/drivers/bluetooth/hci_nokia.c
new file mode 100644
index 000000000000..4038daf78d24
--- /dev/null
+++ b/drivers/bluetooth/hci_nokia.c
@@ -0,0 +1,820 @@
+/*
+ * Bluetooth HCI UART H4 driver with Nokia Extensions AKA Nokia H4+
+ *
+ * Copyright (C) 2015 Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
+ * Copyright (C) 2015-2017 Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/errno.h>
+#include <linux/firmware.h>
+#include <linux/gpio/consumer.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm_runtime.h>
+#include <linux/serdev.h>
+#include <linux/skbuff.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/unaligned/le_struct.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "hci_uart.h"
+#include "btbcm.h"
+
+#define NOKIA_ID_BCM2048 0x04
+#define NOKIA_ID_TI1271 0x31
+
+#define FIRMWARE_BCM2048 "nokia/bcmfw.bin"
+#define FIRMWARE_TI1271 "nokia/ti1273.bin"
+
+#define HCI_NOKIA_NEG_PKT 0x06
+#define HCI_NOKIA_ALIVE_PKT 0x07
+#define HCI_NOKIA_RADIO_PKT 0x08
+
+#define HCI_NOKIA_NEG_HDR_SIZE 1
+#define HCI_NOKIA_MAX_NEG_SIZE 255
+#define HCI_NOKIA_ALIVE_HDR_SIZE 1
+#define HCI_NOKIA_MAX_ALIVE_SIZE 255
+#define HCI_NOKIA_RADIO_HDR_SIZE 2
+#define HCI_NOKIA_MAX_RADIO_SIZE 255
+
+#define NOKIA_PROTO_PKT 0x44
+#define NOKIA_PROTO_BYTE 0x4c
+
+#define NOKIA_NEG_REQ 0x00
+#define NOKIA_NEG_ACK 0x20
+#define NOKIA_NEG_NAK 0x40
+
+#define H4_TYPE_SIZE 1
+
+#define NOKIA_RECV_ALIVE \
+ .type = HCI_NOKIA_ALIVE_PKT, \
+ .hlen = HCI_NOKIA_ALIVE_HDR_SIZE, \
+ .loff = 0, \
+ .lsize = 1, \
+ .maxlen = HCI_NOKIA_MAX_ALIVE_SIZE \
+
+#define NOKIA_RECV_NEG \
+ .type = HCI_NOKIA_NEG_PKT, \
+ .hlen = HCI_NOKIA_NEG_HDR_SIZE, \
+ .loff = 0, \
+ .lsize = 1, \
+ .maxlen = HCI_NOKIA_MAX_NEG_SIZE \
+
+#define NOKIA_RECV_RADIO \
+ .type = HCI_NOKIA_RADIO_PKT, \
+ .hlen = HCI_NOKIA_RADIO_HDR_SIZE, \
+ .loff = 1, \
+ .lsize = 1, \
+ .maxlen = HCI_NOKIA_MAX_RADIO_SIZE \
+
+struct hci_nokia_neg_hdr {
+ u8 dlen;
+} __packed;
+
+struct hci_nokia_neg_cmd {
+ u8 ack;
+ u16 baud;
+ u16 unused1;
+ u8 proto;
+ u16 sys_clk;
+ u16 unused2;
+} __packed;
+
+#define NOKIA_ALIVE_REQ 0x55
+#define NOKIA_ALIVE_RESP 0xcc
+
+struct hci_nokia_alive_hdr {
+ u8 dlen;
+} __packed;
+
+struct hci_nokia_alive_pkt {
+ u8 mid;
+ u8 unused;
+} __packed;
+
+struct hci_nokia_neg_evt {
+ u8 ack;
+ u16 baud;
+ u16 unused1;
+ u8 proto;
+ u16 sys_clk;
+ u16 unused2;
+ u8 man_id;
+ u8 ver_id;
+} __packed;
+
+#define MAX_BAUD_RATE 3692300
+#define SETUP_BAUD_RATE 921600
+#define INIT_BAUD_RATE 120000
+
+struct hci_nokia_radio_hdr {
+ u8 evt;
+ u8 dlen;
+} __packed;
+
+struct nokia_bt_dev {
+ struct hci_uart hu;
+ struct serdev_device *serdev;
+
+ struct gpio_desc *reset;
+ struct gpio_desc *wakeup_host;
+ struct gpio_desc *wakeup_bt;
+ unsigned long sysclk_speed;
+
+ int wake_irq;
+ struct sk_buff *rx_skb;
+ struct sk_buff_head txq;
+ bdaddr_t bdaddr;
+
+ int init_error;
+ struct completion init_completion;
+
+ u8 man_id;
+ u8 ver_id;
+
+ bool initialized;
+ bool tx_enabled;
+ bool rx_enabled;
+};
+
+static int nokia_enqueue(struct hci_uart *hu, struct sk_buff *skb);
+
+static void nokia_flow_control(struct serdev_device *serdev, bool enable)
+{
+ if (enable) {
+ serdev_device_set_rts(serdev, true);
+ serdev_device_set_flow_control(serdev, true);
+ } else {
+ serdev_device_set_flow_control(serdev, false);
+ serdev_device_set_rts(serdev, false);
+ }
+}
+
+static irqreturn_t wakeup_handler(int irq, void *data)
+{
+ struct nokia_bt_dev *btdev = data;
+ struct device *dev = &btdev->serdev->dev;
+ int wake_state = gpiod_get_value(btdev->wakeup_host);
+
+ if (btdev->rx_enabled == wake_state)
+ return IRQ_HANDLED;
+
+ if (wake_state)
+ pm_runtime_get(dev);
+ else
+ pm_runtime_put(dev);
+
+ btdev->rx_enabled = wake_state;
+
+ return IRQ_HANDLED;
+}
+
+static int nokia_reset(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ int err;
+
+ /* reset routine */
+ gpiod_set_value_cansleep(btdev->reset, 1);
+ gpiod_set_value_cansleep(btdev->wakeup_bt, 1);
+
+ msleep(100);
+
+ /* safety check */
+ err = gpiod_get_value_cansleep(btdev->wakeup_host);
+ if (err == 1) {
+ dev_err(dev, "reset: host wakeup not low!");
+ return -EPROTO;
+ }
+
+ /* flush queue */
+ serdev_device_write_flush(btdev->serdev);
+
+ /* init uart */
+ nokia_flow_control(btdev->serdev, false);
+ serdev_device_set_baudrate(btdev->serdev, INIT_BAUD_RATE);
+
+ gpiod_set_value_cansleep(btdev->reset, 0);
+
+ /* wait for cts */
+ err = serdev_device_wait_for_cts(btdev->serdev, true, 200);
+ if (err < 0) {
+ dev_err(dev, "CTS not received: %d", err);
+ return err;
+ }
+
+ nokia_flow_control(btdev->serdev, true);
+
+ return 0;
+}
+
+static int nokia_send_alive_packet(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ struct hci_nokia_alive_hdr *hdr;
+ struct hci_nokia_alive_pkt *pkt;
+ struct sk_buff *skb;
+ int len;
+
+ init_completion(&btdev->init_completion);
+
+ len = H4_TYPE_SIZE + sizeof(*hdr) + sizeof(*pkt);
+ skb = bt_skb_alloc(len, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ hci_skb_pkt_type(skb) = HCI_NOKIA_ALIVE_PKT;
+ memset(skb->data, 0x00, len);
+
+ hdr = (struct hci_nokia_alive_hdr *)skb_put(skb, sizeof(*hdr));
+ hdr->dlen = sizeof(*pkt);
+ pkt = (struct hci_nokia_alive_pkt *)skb_put(skb, sizeof(*pkt));
+ pkt->mid = NOKIA_ALIVE_REQ;
+
+ nokia_enqueue(hu, skb);
+ hci_uart_tx_wakeup(hu);
+
+ dev_dbg(dev, "Alive sent");
+
+ if (!wait_for_completion_interruptible_timeout(&btdev->init_completion,
+ msecs_to_jiffies(1000))) {
+ return -ETIMEDOUT;
+ }
+
+ if (btdev->init_error < 0)
+ return btdev->init_error;
+
+ return 0;
+}
+
+static int nokia_send_negotiation(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ struct hci_nokia_neg_cmd *neg_cmd;
+ struct hci_nokia_neg_hdr *neg_hdr;
+ struct sk_buff *skb;
+ int len, err;
+ u16 baud = DIV_ROUND_CLOSEST(btdev->sysclk_speed * 10, SETUP_BAUD_RATE);
+ int sysclk = btdev->sysclk_speed / 1000;
+
+ len = H4_TYPE_SIZE + sizeof(*neg_hdr) + sizeof(*neg_cmd);
+ skb = bt_skb_alloc(len, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ hci_skb_pkt_type(skb) = HCI_NOKIA_NEG_PKT;
+
+ neg_hdr = (struct hci_nokia_neg_hdr *)skb_put(skb, sizeof(*neg_hdr));
+ neg_hdr->dlen = sizeof(*neg_cmd);
+
+ neg_cmd = (struct hci_nokia_neg_cmd *)skb_put(skb, sizeof(*neg_cmd));
+ neg_cmd->ack = NOKIA_NEG_REQ;
+ neg_cmd->baud = cpu_to_le16(baud);
+ neg_cmd->unused1 = 0x0000;
+ neg_cmd->proto = NOKIA_PROTO_BYTE;
+ neg_cmd->sys_clk = cpu_to_le16(sysclk);
+ neg_cmd->unused2 = 0x0000;
+
+ btdev->init_error = 0;
+ init_completion(&btdev->init_completion);
+
+ nokia_enqueue(hu, skb);
+ hci_uart_tx_wakeup(hu);
+
+ dev_dbg(dev, "Negotiation sent");
+
+ if (!wait_for_completion_interruptible_timeout(&btdev->init_completion,
+ msecs_to_jiffies(10000))) {
+ return -ETIMEDOUT;
+ }
+
+ if (btdev->init_error < 0)
+ return btdev->init_error;
+
+ /* Change to previously negotiated speed. Flow Control
+ * is disabled until bluetooth adapter is ready to avoid
+ * broken bytes being received.
+ */
+ nokia_flow_control(btdev->serdev, false);
+ serdev_device_set_baudrate(btdev->serdev, SETUP_BAUD_RATE);
+ err = serdev_device_wait_for_cts(btdev->serdev, true, 200);
+ if (err < 0) {
+ dev_err(dev, "CTS not received: %d", err);
+ return err;
+ }
+ nokia_flow_control(btdev->serdev, true);
+
+ dev_dbg(dev, "Negotiation successful");
+
+ return 0;
+}
+
+static int nokia_setup_fw(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ const char *fwname;
+ const struct firmware *fw;
+ const u8 *fw_ptr;
+ size_t fw_size;
+ int err;
+
+ dev_dbg(dev, "setup firmware");
+
+ if (btdev->man_id == NOKIA_ID_BCM2048) {
+ fwname = FIRMWARE_BCM2048;
+ } else if (btdev->man_id == NOKIA_ID_TI1271) {
+ fwname = FIRMWARE_TI1271;
+ } else {
+ dev_err(dev, "Unsupported bluetooth device!");
+ return -ENODEV;
+ }
+
+ err = request_firmware(&fw, fwname, dev);
+ if (err < 0) {
+ dev_err(dev, "%s: Failed to load Nokia firmware file (%d)",
+ hu->hdev->name, err);
+ return err;
+ }
+
+ fw_ptr = fw->data;
+ fw_size = fw->size;
+
+ while (fw_size >= 4) {
+ u16 pkt_size = get_unaligned_le16(fw_ptr);
+ u8 pkt_type = fw_ptr[2];
+ const struct hci_command_hdr *cmd;
+ u16 opcode;
+ struct sk_buff *skb;
+
+ switch (pkt_type) {
+ case HCI_COMMAND_PKT:
+ cmd = (struct hci_command_hdr *)(fw_ptr + 3);
+ opcode = le16_to_cpu(cmd->opcode);
+
+ skb = __hci_cmd_sync(hu->hdev, opcode, cmd->plen,
+ fw_ptr + 3 + HCI_COMMAND_HDR_SIZE,
+ HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ err = PTR_ERR(skb);
+ dev_err(dev, "%s: FW command %04x failed (%d)",
+ hu->hdev->name, opcode, err);
+ goto done;
+ }
+ kfree_skb(skb);
+ break;
+ case HCI_NOKIA_RADIO_PKT:
+ case HCI_NOKIA_NEG_PKT:
+ case HCI_NOKIA_ALIVE_PKT:
+ break;
+ }
+
+ fw_ptr += pkt_size + 2;
+ fw_size -= pkt_size + 2;
+ }
+
+done:
+ release_firmware(fw);
+ return err;
+}
+
+static int nokia_setup(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ int err;
+
+ btdev->initialized = false;
+
+ nokia_flow_control(btdev->serdev, false);
+
+ pm_runtime_get_sync(dev);
+
+ if (btdev->tx_enabled) {
+ gpiod_set_value_cansleep(btdev->wakeup_bt, 0);
+ pm_runtime_put(&btdev->serdev->dev);
+ btdev->tx_enabled = false;
+ }
+
+ dev_dbg(dev, "protocol setup");
+
+ /* 0. reset connection */
+ err = nokia_reset(hu);
+ if (err < 0) {
+ dev_err(dev, "Reset failed: %d", err);
+ goto out;
+ }
+
+ /* 1. negotiate speed etc */
+ err = nokia_send_negotiation(hu);
+ if (err < 0) {
+ dev_err(dev, "Negotiation failed: %d", err);
+ goto out;
+ }
+
+ /* 2. verify correct setup using alive packet */
+ err = nokia_send_alive_packet(hu);
+ if (err < 0) {
+ dev_err(dev, "Alive check failed: %d", err);
+ goto out;
+ }
+
+ /* 3. send firmware */
+ err = nokia_setup_fw(hu);
+ if (err < 0) {
+ dev_err(dev, "Could not setup FW: %d", err);
+ goto out;
+ }
+
+ nokia_flow_control(btdev->serdev, false);
+ serdev_device_set_baudrate(btdev->serdev, MAX_BAUD_RATE);
+ nokia_flow_control(btdev->serdev, true);
+
+ if (btdev->man_id == NOKIA_ID_BCM2048) {
+ hu->hdev->set_bdaddr = btbcm_set_bdaddr;
+ set_bit(HCI_QUIRK_INVALID_BDADDR, &hu->hdev->quirks);
+ dev_dbg(dev, "bcm2048 has invalid bluetooth address!");
+ }
+
+ dev_dbg(dev, "protocol setup done!");
+
+ gpiod_set_value_cansleep(btdev->wakeup_bt, 0);
+ pm_runtime_put(dev);
+ btdev->tx_enabled = false;
+ btdev->initialized = true;
+
+ return 0;
+out:
+ pm_runtime_put(dev);
+
+ return err;
+}
+
+static int nokia_open(struct hci_uart *hu)
+{
+ struct device *dev = &hu->serdev->dev;
+
+ dev_dbg(dev, "protocol open");
+
+ serdev_device_open(hu->serdev);
+
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int nokia_flush(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+
+ dev_dbg(&btdev->serdev->dev, "flush device");
+
+ skb_queue_purge(&btdev->txq);
+
+ return 0;
+}
+
+static int nokia_close(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+
+ dev_dbg(dev, "close device");
+
+ btdev->initialized = false;
+
+ skb_queue_purge(&btdev->txq);
+
+ kfree_skb(btdev->rx_skb);
+
+ /* disable module */
+ gpiod_set_value(btdev->reset, 1);
+ gpiod_set_value(btdev->wakeup_bt, 0);
+
+ pm_runtime_disable(&btdev->serdev->dev);
+ serdev_device_close(btdev->serdev);
+
+ return 0;
+}
+
+/* Enqueue frame for transmittion (padding, crc, etc) */
+static int nokia_enqueue(struct hci_uart *hu, struct sk_buff *skb)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ int err;
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+ /* Packets must be word aligned */
+ if (skb->len % 2) {
+ err = skb_pad(skb, 1);
+ if (err)
+ return err;
+ *skb_put(skb, 1) = 0x00;
+ }
+
+ skb_queue_tail(&btdev->txq, skb);
+
+ return 0;
+}
+
+static int nokia_recv_negotiation_packet(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_uart *hu = hci_get_drvdata(hdev);
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ struct hci_nokia_neg_hdr *hdr;
+ struct hci_nokia_neg_evt *evt;
+ int ret = 0;
+
+ hdr = (struct hci_nokia_neg_hdr *)skb->data;
+ if (hdr->dlen != sizeof(*evt)) {
+ btdev->init_error = -EIO;
+ ret = -EIO;
+ goto finish_neg;
+ }
+
+ evt = (struct hci_nokia_neg_evt *)skb_pull(skb, sizeof(*hdr));
+
+ if (evt->ack != NOKIA_NEG_ACK) {
+ dev_err(dev, "Negotiation received: wrong reply");
+ btdev->init_error = -EINVAL;
+ ret = -EINVAL;
+ goto finish_neg;
+ }
+
+ btdev->man_id = evt->man_id;
+ btdev->ver_id = evt->ver_id;
+
+ dev_dbg(dev, "Negotiation received: baud=%u:clk=%u:manu=%u:vers=%u",
+ evt->baud, evt->sys_clk, evt->man_id, evt->ver_id);
+
+finish_neg:
+ complete(&btdev->init_completion);
+ kfree_skb(skb);
+ return ret;
+}
+
+static int nokia_recv_alive_packet(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_uart *hu = hci_get_drvdata(hdev);
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ struct hci_nokia_alive_hdr *hdr;
+ struct hci_nokia_alive_pkt *pkt;
+ int ret = 0;
+
+ hdr = (struct hci_nokia_alive_hdr *)skb->data;
+ if (hdr->dlen != sizeof(*pkt)) {
+ dev_err(dev, "Corrupted alive message");
+ btdev->init_error = -EIO;
+ ret = -EIO;
+ goto finish_alive;
+ }
+
+ pkt = (struct hci_nokia_alive_pkt *)skb_pull(skb, sizeof(*hdr));
+
+ if (pkt->mid != NOKIA_ALIVE_RESP) {
+ dev_err(dev, "Alive received: invalid response: 0x%02x!",
+ pkt->mid);
+ btdev->init_error = -EINVAL;
+ ret = -EINVAL;
+ goto finish_alive;
+ }
+
+ dev_dbg(dev, "Alive received");
+
+finish_alive:
+ complete(&btdev->init_completion);
+ kfree_skb(skb);
+ return ret;
+}
+
+static int nokia_recv_radio(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ /* Packets received on the dedicated radio channel are
+ * HCI events and so feed them back into the core.
+ */
+ hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
+ return hci_recv_frame(hdev, skb);
+}
+
+/* Recv data */
+static const struct h4_recv_pkt nokia_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = hci_recv_frame },
+ { NOKIA_RECV_ALIVE, .recv = nokia_recv_alive_packet },
+ { NOKIA_RECV_NEG, .recv = nokia_recv_negotiation_packet },
+ { NOKIA_RECV_RADIO, .recv = nokia_recv_radio },
+};
+
+static int nokia_recv(struct hci_uart *hu, const void *data, int count)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ int err;
+
+ if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
+ return -EUNATCH;
+
+ btdev->rx_skb = h4_recv_buf(hu->hdev, btdev->rx_skb, data, count,
+ nokia_recv_pkts, ARRAY_SIZE(nokia_recv_pkts));
+ if (IS_ERR(btdev->rx_skb)) {
+ err = PTR_ERR(btdev->rx_skb);
+ dev_err(dev, "Frame reassembly failed (%d)", err);
+ btdev->rx_skb = NULL;
+ return err;
+ }
+
+ return count;
+}
+
+static struct sk_buff *nokia_dequeue(struct hci_uart *hu)
+{
+ struct nokia_bt_dev *btdev = hu->priv;
+ struct device *dev = &btdev->serdev->dev;
+ struct sk_buff *result = skb_dequeue(&btdev->txq);
+
+ if (!btdev->initialized)
+ return result;
+
+ if (btdev->tx_enabled == !!result)
+ return result;
+
+ if (result) {
+ pm_runtime_get_sync(dev);
+ gpiod_set_value_cansleep(btdev->wakeup_bt, 1);
+ } else {
+ serdev_device_wait_until_sent(btdev->serdev, 0);
+ gpiod_set_value_cansleep(btdev->wakeup_bt, 0);
+ pm_runtime_put(dev);
+ }
+
+ btdev->tx_enabled = !!result;
+
+ return result;
+}
+
+static const struct hci_uart_proto nokia_proto = {
+ .id = HCI_UART_NOKIA,
+ .name = "Nokia",
+ .open = nokia_open,
+ .close = nokia_close,
+ .recv = nokia_recv,
+ .enqueue = nokia_enqueue,
+ .dequeue = nokia_dequeue,
+ .flush = nokia_flush,
+ .setup = nokia_setup,
+ .manufacturer = 1,
+};
+
+static int nokia_bluetooth_serdev_probe(struct serdev_device *serdev)
+{
+ struct device *dev = &serdev->dev;
+ struct nokia_bt_dev *btdev;
+ struct clk *sysclk;
+ int err = 0;
+
+ btdev = devm_kzalloc(dev, sizeof(*btdev), GFP_KERNEL);
+ if (!btdev)
+ return -ENOMEM;
+
+ btdev->hu.serdev = btdev->serdev = serdev;
+ serdev_device_set_drvdata(serdev, btdev);
+
+ btdev->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(btdev->reset)) {
+ err = PTR_ERR(btdev->reset);
+ dev_err(dev, "could not get reset gpio: %d", err);
+ return err;
+ }
+
+ btdev->wakeup_host = devm_gpiod_get(dev, "host-wakeup", GPIOD_IN);
+ if (IS_ERR(btdev->wakeup_host)) {
+ err = PTR_ERR(btdev->wakeup_host);
+ dev_err(dev, "could not get host wakeup gpio: %d", err);
+ return err;
+ }
+
+ btdev->wake_irq = gpiod_to_irq(btdev->wakeup_host);
+
+ err = devm_request_threaded_irq(dev, btdev->wake_irq, NULL,
+ wakeup_handler,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "wakeup", btdev);
+ if (err) {
+ dev_err(dev, "could request wakeup irq: %d", err);
+ return err;
+ }
+
+ btdev->wakeup_bt = devm_gpiod_get(dev, "bluetooth-wakeup",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(btdev->wakeup_bt)) {
+ err = PTR_ERR(btdev->wakeup_bt);
+ dev_err(dev, "could not get BT wakeup gpio: %d", err);
+ return err;
+ }
+
+ sysclk = devm_clk_get(dev, "sysclk");
+ if (IS_ERR(sysclk)) {
+ err = PTR_ERR(sysclk);
+ dev_err(dev, "could not get sysclk: %d", err);
+ return err;
+ }
+
+ clk_prepare_enable(sysclk);
+ btdev->sysclk_speed = clk_get_rate(sysclk);
+ clk_disable_unprepare(sysclk);
+
+ skb_queue_head_init(&btdev->txq);
+
+ btdev->hu.priv = btdev;
+ btdev->hu.alignment = 2; /* Nokia H4+ is word aligned */
+
+ err = hci_uart_register_device(&btdev->hu, &nokia_proto);
+ if (err) {
+ dev_err(dev, "could not register bluetooth uart: %d", err);
+ return err;
+ }
+
+ return 0;
+}
+
+static void nokia_bluetooth_serdev_remove(struct serdev_device *serdev)
+{
+ struct nokia_bt_dev *btdev = serdev_device_get_drvdata(serdev);
+ struct hci_uart *hu = &btdev->hu;
+ struct hci_dev *hdev = hu->hdev;
+
+ cancel_work_sync(&hu->write_work);
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+ hu->proto->close(hu);
+
+ pm_runtime_disable(&btdev->serdev->dev);
+}
+
+static int nokia_bluetooth_runtime_suspend(struct device *dev)
+{
+ struct serdev_device *serdev = to_serdev_device(dev);
+
+ nokia_flow_control(serdev, false);
+ return 0;
+}
+
+static int nokia_bluetooth_runtime_resume(struct device *dev)
+{
+ struct serdev_device *serdev = to_serdev_device(dev);
+
+ nokia_flow_control(serdev, true);
+ return 0;
+}
+
+static const struct dev_pm_ops nokia_bluetooth_pm_ops = {
+ SET_RUNTIME_PM_OPS(nokia_bluetooth_runtime_suspend,
+ nokia_bluetooth_runtime_resume,
+ NULL)
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id nokia_bluetooth_of_match[] = {
+ { .compatible = "nokia,h4p-bluetooth", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, nokia_bluetooth_of_match);
+#endif
+
+static struct serdev_device_driver nokia_bluetooth_serdev_driver = {
+ .probe = nokia_bluetooth_serdev_probe,
+ .remove = nokia_bluetooth_serdev_remove,
+ .driver = {
+ .name = "nokia-bluetooth",
+ .pm = &nokia_bluetooth_pm_ops,
+ .of_match_table = of_match_ptr(nokia_bluetooth_of_match),
+ },
+};
+
+module_serdev_device_driver(nokia_bluetooth_serdev_driver);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3] ARM: dts: stm32f7: add stm32f769I & stm32f746 discovery board support
From: Vikas Manocha @ 2017-04-13 0:27 UTC (permalink / raw)
To: alexandre.torgue-qxv4g6HH51o, patrice.chotard-qxv4g6HH51o
Cc: Vikas Manocha,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list, Mark Rutland, Maxime Coquelin,
Rob Herring, Russell King
Stm32f769I & stm32f746 are MCUs of stm32f7 family. Here are the major
specs of the two boards:
stm32f769I discovery board:
- Cortex-M7 core @216MHz
- 2MB mcu internal flash
- 512KB internal sram
- 16MB sdram memory
- 64MB qspi flash memory
- 4 inch wvga LCD-TFT Display
stm32f746 discovery board:
- Cortex-M7 core @216MHz
- 1MB mcu internal flash
- 320KB internal sram
- 8MB sdram memory
- 16MB qspi flash memory
- 4.3 inch 480x272 LCD-TFT display
Signed-off-by: Vikas Manocha <vikas.manocha-qxv4g6HH51o@public.gmane.org>
---
Changed in v3:
- fixed usart pin muxing for stm32f746 board, correct one is usart1_pins_pa9_pb7.
- Added patch version in the patch title, was missed in v2.
Changed in v2:
- moved pin muxing from board dts file to soc dtsi
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/stm32f746-disco.dts | 74 +++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/stm32f746.dtsi | 12 ++++++
arch/arm/boot/dts/stm32f769-disco.dts | 74 +++++++++++++++++++++++++++++++++++
4 files changed, 162 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32f746-disco.dts
create mode 100644 arch/arm/boot/dts/stm32f769-disco.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..a119f74 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -763,6 +763,8 @@ dtb-$(CONFIG_ARCH_STI) += \
dtb-$(CONFIG_ARCH_STM32)+= \
stm32f429-disco.dtb \
stm32f469-disco.dtb \
+ stm32f746-disco.dtb \
+ stm32f769-disco.dtb \
stm32429i-eval.dtb \
stm32746g-eval.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
diff --git a/arch/arm/boot/dts/stm32f746-disco.dts b/arch/arm/boot/dts/stm32f746-disco.dts
new file mode 100644
index 0000000..52e5834
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f746-disco.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "STMicroelectronics STM32F746-DISCO board";
+ compatible = "st,stm32f746-disco", "st,stm32f746";
+
+ chosen {
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0xC0000000 0x800000>;
+ };
+
+ aliases {
+ serial0 = &usart1;
+ };
+
+};
+
+&clk_hse {
+ clock-frequency = <25000000>;
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_pa9_pb7>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..82becbb 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -287,6 +287,18 @@
bias-disable;
};
};
+ usart1_pins_pa9_pb7: usart1@1 {
+ pins1 {
+ pinmux = <STM32F746_PA9_FUNC_USART1_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32F746_PB7_FUNC_USART1_RX>;
+ bias-disable;
+ };
+ };
};
rcc: rcc@40023800 {
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
new file mode 100644
index 0000000..166728a
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2017 - Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f746.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "STMicroelectronics STM32F769-DISCO board";
+ compatible = "st,stm32f769-disco", "st,stm32f7";
+
+ chosen {
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0xC0000000 0x1000000>;
+ };
+
+ aliases {
+ serial0 = &usart1;
+ };
+
+};
+
+&clk_hse {
+ clock-frequency = <25000000>;
+};
+
+&usart1 {
+ pinctrl-0 = <&usart1_pins_a>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
From: Steve Longerbeam @ 2017-04-13 0:33 UTC (permalink / raw)
To: Philipp Zabel, Russell King - ARM Linux
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, nick-gcszYUEDH4VrovVCs/uTlw,
markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b
In-Reply-To: <1491492354.2392.87.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 04/06/2017 08:25 AM, Philipp Zabel wrote:
> On Thu, 2017-04-06 at 16:10 +0100, Russell King - ARM Linux wrote:
>> On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote:
>>> On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote:
>>>> On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote:
>>>>> +
>>>>> + /* Retain current field setting as default */
>>>>> + if (sdformat->format.field == V4L2_FIELD_ANY)
>>>>> + sdformat->format.field = fmt->field;
>>>>> +
>>>>> + /* Retain current colorspace setting as default */
>>>>> + if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
>>>>> + sdformat->format.colorspace = fmt->colorspace;
>>>>> + if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT)
>>>>> + sdformat->format.xfer_func = fmt->xfer_func;
>>>>> + if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
>>>>> + sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
>>>>> + if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT)
>>>>> + sdformat->format.quantization = fmt->quantization;
>>>>> + } else {
>>>>> + if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT) {
>>>>> + sdformat->format.xfer_func =
>>>>> + V4L2_MAP_XFER_FUNC_DEFAULT(
>>>>> + sdformat->format.colorspace);
>>>>> + }
>>>>> + if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT) {
>>>>> + sdformat->format.ycbcr_enc =
>>>>> + V4L2_MAP_YCBCR_ENC_DEFAULT(
>>>>> + sdformat->format.colorspace);
>>>>> + }
>>>>> + if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT) {
>>>>> + sdformat->format.quantization =
>>>>> + V4L2_MAP_QUANTIZATION_DEFAULT(
>>>>> + cc->cs != IPUV3_COLORSPACE_YUV,
>>>>> + sdformat->format.colorspace,
>>>>> + sdformat->format.ycbcr_enc);
>>>>> + }
>>>>> + }
>>>>
>>>> Would it make sense for this to be a helper function?
>>>
>>> Quite possible, the next subdev that has to set frame_interval on both
>>> pads manually because its upstream source pad doesn't suport
>>> frame_interval might want to do the same.
>>
>> Hmm. I'm not sure I agree with this approach. If a subdev hardware
>> does not support any modification of the colourspace or field, then
>> it should not be modifyable at the source pad - it should retain the
>> propagated settings from the sink pad.
>
> This new code is only relevant for the CSI_SINK_PAD.
>
>> I thought I had already sent a patch doing exactly that.
>
> Yes. Right above the modification there is a call to csi_try_fmt which
> will already fix up sdformat->format for the source pads. So for the
> CSI_SRC_PAD_DIRECT and CSI_SRC_PAD_IDMAC this should amount to a no-op.
>
> If might be better to move this into a separate function and only call
> it if sdformat->pad == CSI_SINK_PAD.
I've done this, I will follow with the new patch. Philipp, let me know
if this looks ok to you and I will add your sign-off.
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Guochun Mao @ 2017-04-13 2:40 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: Cyrille Pitchen, Mark Rutland, devicetree, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, David Woodhouse,
linux-arm-kernel
In-Reply-To: <e9eafca3-41a0-7e88-996b-9d1c51f0c132@wedev4u.fr>
Hi Cyrille,
On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
>
> Le 05/04/2017 à 10:37, Guochun Mao a écrit :
> > When nor's size larger than 16MByte, nor's address width maybe
> > set to 3 or 4, and controller should change address width according
> > to nor's setting.
> >
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>st
> > ---
> > drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..b637770 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -104,6 +104,8 @@
> > #define MTK_NOR_MAX_RX_TX_SHIFT 6
> > /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
> > #define MTK_NOR_MAX_SHIFT 7
> > +/* nor controller 4-byte address mode enable bit */
> > +#define MTK_NOR_4B_ADDR_EN BIT(4)
> >
> > /* Helpers for accessing the program data / shift data registers */
> > #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
> > @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
> > 10000);
> > }
> >
> > +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
> > +{
> > + u8 val;
> > + struct spi_nor *nor = &mt8173_nor->nor;
> > +
> > + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +
> > + switch (nor->addr_width) {
> > + case 3:
> > + val &= ~MTK_NOR_4B_ADDR_EN;
> > + break;
> > + case 4:
> > + val |= MTK_NOR_4B_ADDR_EN;
> > + break;
> > + default:
> > + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
> > + nor->addr_width);
> > + break;
> > + }
> > +
> > + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +}
> > +
> > static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> > {
> > int i;
> >
> > + mt8173_nor_set_addr_width(mt8173_nor);
> > +
> > for (i = 0; i < 3; i++) {
>
> Should it be 'i < nor->addr_width' instead of 'i < 3' ?
> Does it work when accessing data after 128Mbit ?
Yes, it can work.
Let's see the whole function,
static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
{
int i;
mt8173_nor_set_addr_width(mt8173_nor);
for (i = 0; i < 3; i++) {
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG
+ i * 4);
addr >>= 8;
}
/* Last register is non-contiguous */
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
}
The nor controller has 4 registers for address.
This '3' indicates the number of contiguous address' registers
base + MTK_NOR_RADR0_REG(0x10)
base + MTK_NOR_RADR1_REG(0x14)
base + MTK_NOR_RADR2_REG(0x18),
but the last address register is non-contiguous,
it's base + MTK_NOR_RADR3_REG(0xc8)
mt8173_nor_set_addr will set addr into these 4 registers by Byte.
The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18)
or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device.
and, it can access data after 128Mbit when sent 4-byte address.
Best regards,
Guochun
>
> Best regards,
>
> Cyrille
>
> > writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
> > addr >>= 8;
> >
>
^ permalink raw reply
* Re: [PATCH v2 0/3] of: Make of_match_node() an inline stub for CONFIG_OF=n
From: Frank Rowand @ 2017-04-13 3:46 UTC (permalink / raw)
To: Florian Fainelli, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Lee Jones,
Nicolas Ferre, Rob Herring, open list:NETWORKING DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20170412044156.17351-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/11/17 21:41, Florian Fainelli wrote:
> Hi all,
>
> This patch series makes of_match_node() an inline stub for CONFIG_OF=n. kbuild
> reported two build errors which are fixed as preriquisite patches.
>
> This is based on Linus' master, not sure which tree would merge this, Frank's?
It would come in via Rob.
I am not comfortable with patch 3/3 at this moment.
Version 1 of the patch resulted in two errors from the kbuild test robot. This
version results in another error from the kbuild test robot. I know it is a
lot of work, but please look at all of the callers of of_match_node() and
check whether any of the other callers will have the same type of error that
the kbuild test robot is catching.
-Frank
>
> Thanks!
>
> Florian Fainelli (3):
> mfd: max8998: Remove CONFIG_OF around max8998_dt_match
> net: macb: Remove CONFIG_OF around DT match table
> of: Make of_match_node() an inline stub for CONFIG_OF=n
>
> drivers/mfd/max8998.c | 2 --
> drivers/net/ethernet/cadence/macb.c | 2 --
> include/linux/of.h | 6 +++++-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board
From: Kever Yang @ 2017-04-13 4:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jianqun Xu, Liang Chen,
Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andy Yan,
Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Will Deacon, Mark Rutland, Catalin Marinas, Matthias Brugger
In-Reply-To: <1642127.PiTFsmK4zh@phil>
Hi Heiko,
On 04/12/2017 09:29 PM, Heiko Stuebner wrote:
> Hi Kever,
>
> Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:
>> Firefly-rk3399 is a bord from T-Firefly, you can find detail about
>> it here:
>> http://en.t-firefly.com/en/firenow/Firefly_RK3399/
>>
>> This patch add basic node for the board and make it able to bring
>> up.
>>
>> Peripheral works:
>> - usb hub which connect to ehci controller;
>> - UART2 debug
>> - eMMC
>> - PCIe
>>
>> Not work:
>> - USB 3.0 HOST, type-C port
>> - sdio, sd-card
>>
>> Not test for other peripheral:
>> - HDMI
>> - Ethernet
>> - OPTICAL
>> - WiFi/BT
>> - MIPI CSI/DSI
>> - IR
>> - EDP/DP
>>
>> Signed-off-by: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> applied for 4.13, as we're a bit late for 4.12, with the following changes:
Thanks for your help, I'm not familiar with the devices status on upstream
because not working on kernel upstream for a long time.
> - commit subject
> - dropped status from backlight (as there is no disabled common node
> and it's specific to the firefly itself)
> - quite some reordering of properties
> - reordered regulator nodes per their addresses: 0x1b < 0x40
> - dropped obsolete regulator-compatible properties
> - fixed gpio-irq on the mpu6500
> - dropped out-of-tree orientation properties of mpu6500
> --> please provide the optional "mount-matrix" in a follow-up patch
> see bindings/iio/imu/inv_mpu6050.txt
Maybe we can drop this mpu6050 node first? I can't find binding file for it.
> - dropped rockchip,i2s-broken-burst-len;
> That change never made it into the mainline kernel
> - fixed pcie pinctrl indentation
> - dropped wireless-bluetooth uart-gpios pinctrl
> - dropped supports-emmc property
>
> Please try to be a bit more careful when porting stuff from device kernels
> with respect to properties not found in the mainline kernel and please
> also double-check in [0] that I didn't break anything.
I have test this patch on my firefly-rk3399, it works fine with pwm2
regulator
init in U-Boot.
Thanks,
- Kever
>
>
> Thanks
> Heiko
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=495a3c891a696b62465d71b1a125e3424352028b
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Minghsiu Tsai @ 2017-04-13 4:18 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Eddie Huang, Yingjoe Chen,
Wu-Cheng Li, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Minghsiu Tsai
From: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Experiments show that the:
(1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
(2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 13afe48..8ab7ca0 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (mtk_mdp_is_target_compose(s->target))
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (mtk_mdp_is_target_crop(s->target))
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (mtk_mdp_is_target_compose(s->target))
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
int ret;
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (s->target == V4L2_SEL_TGT_COMPOSE)
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (s->target == V4L2_SEL_TGT_CROP)
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (s->target == V4L2_SEL_TGT_COMPOSE)
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
if (ret)
return ret;
- if (mtk_mdp_is_target_crop(s->target))
+ if (mtk_mdp_is_target_compose(s->target))
frame = &ctx->s_frame;
else
frame = &ctx->d_frame;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas
From: Keerthy @ 2017-04-13 4:51 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: j-keerthy-l0cyMroinI0, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, t-kristo-l0cyMroinI0
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4bc4b57..31a9e06 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -204,6 +204,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+ ti,palmas-override-powerhold;
+ ti,system-power-controller;
tps659038_pmic {
compatible = "ti,tps659038-pmic";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-13 5:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, lina.iyer-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0a7146f9-72f1-317c-3aab-770a72462968-5wv7dgnIgG8@public.gmane.org>
On 12-04-17, 17:49, Sudeep Holla wrote:
> On 20/03/17 09:32, Viresh Kumar wrote:
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index 63725498bd20..d0b95c9e1011 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -76,10 +76,9 @@ This describes the OPPs belonging to a device. This node can have following
> > This defines voltage-current-frequency combinations along with other related
> > properties.
> >
> > -Required properties:
> > +Optional properties:
> > - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer.
> >
> > -Optional properties:
> > - opp-microvolt: voltage in micro Volts.
> >
> > A single regulator's voltage is specified with an array of size one or three.
> > @@ -154,6 +153,19 @@ properties.
> >
> > - status: Marks the node enabled/disabled.
> >
> > +- domain-performance-state: A positive integer value representing the minimum
> > + power-domain performance level required by the device for the OPP node. The
>
> So the above definition is when this field in in the device node rather
> than the OPP table entry, right ?
No. We are updating the opp.txt file here and so it is not about the
device node. The OPP node entries will contain this field for two
cases:
- The OPP table belongs to a power domain
- The OPP table belongs to a device whose power domain supports
performance-states.
> For simplicity why not have the
> properties named slightly different or just use phandle to an entry in
> the device node for this purpose.
We really need a value here. For example, in case where the OPP table
defines the states of the power-domain itself, we don't have any
phandles to point to.
> > + The integer value '0' represents the lowest performance level and the higher
> > + values represent higher performance levels.
>
> needs to be changed as OPP table entry.
Not sure I understood what change you are looking for :(
> > When present in the OPP table of a
> > + power-domain, it represents the performance level of the domain. When present
>
> again "performance level of the domain corresponding to that OPP entry"
> on something similar
Ok.
> > + in the OPP table of a normal device, it represents the performance level of
>
> what do you mean by normal device ? needs description as that's
> something new introduced here.
It should be non-power-domain node.
> > + the parent power-domain. The OPP table can contain the
> > + "domain-performance-state" property, only if the device node contains the
> > + "power-domains" or "#power-domain-cells" property.
>
> Why such a restriction ?
Why would we use it for non-power-domain cases? That's not what we
are looking for..
> > The OPP nodes aren't
> > + allowed to contain the "domain-performance-state" property partially, i.e.
> > + Either all OPP nodes in the OPP table have the "domain-performance-state"
> > + property or none of them have it.
> > +
> > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
> >
> > / {
> > @@ -528,3 +540,60 @@ Example 5: opp-supported-hw
> > };
> > };
> > };
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 970000 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 1000000 1085000>;
> > + };
> > + };
> > +
> > + foo_domain: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
>
> How does it scale with power domain providers with multiple power domain ?
Devices can't have multiple power domains today. Will see this when
that support is added.
Note that only the power domains can have multiple parent power
domains today.
> > + }
> > +
> > + cpu0_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp@1000000000 {
> > + opp-hz = /bits/ 64 <1000000000>;
> > + domain-performance-state = <1>;
> > + };
> > + opp@1100000000 {
> > + opp-hz = /bits/ 64 <1100000000>;
> > + domain-performance-state = <2>;
> > + };
> > + opp@1200000000 {
> > + opp-hz = /bits/ 64 <1200000000>;
> > + domain-performance-state = <2>;
> > + };
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> > + compatible = "arm,cortex-a9";
> > + reg = <0>;
> > + clocks = <&clk_controller 0>;
> > + clock-names = "cpu";
> > + operating-points-v2 = <&cpu0_opp_table>;
>
> Do we ignore operating-points-v2 above as this device/cpu node contains
> power domain which has operating-points-v2 property ? In other words
> how do they correlate ?
Devices and their power domains can both have their performance
states. Just that to get the device in a particular state, we may need
to get its power domain to a particular state first.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-13 5:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <468e756b-7112-4006-b31d-9fcf1c32673d@arm.com>
On 12-04-17, 18:05, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> [...]
>
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 970000 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 1000000 1085000>;
> > + };
> > + };
> > +
> > + foo_domain: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
> > + }
> > +
> > + cpu0_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp@1000000000 {
> > + opp-hz = /bits/ 64 <1000000000>;
> > + domain-performance-state = <1>;
> > + };
> > + opp@1100000000 {
> > + opp-hz = /bits/ 64 <1100000000>;
> > + domain-performance-state = <2>;
> > + };
> > + opp@1200000000 {
> > + opp-hz = /bits/ 64 <1200000000>;
> > + domain-performance-state = <2>;
> > + };
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> > + compatible = "arm,cortex-a9";
> > + reg = <0>;
> > + clocks = <&clk_controller 0>;
> > + clock-names = "cpu";
> > + operating-points-v2 = <&cpu0_opp_table>;
> > + power-domains = <&foo_domain>;
> > + };
> > + };
> > +};
>
>
> Thinking more about this above example, I think you need more
> explanation. So in the above case you have cpu with clock controller,
> power-domain and the OPP table info, I can think of few things that need
> to be explicit:
>
> 1. How does the precedence look like ?
Just think of the power-domain as a regulator here. If we are
increasing frequency of the device, power-domain needs to be
programmed first followed by the clock.
> 2. Since power-domains with OPP table control the performance state, do
They control performance state of the domains, not the devices.
> we ignore clock and operating-points-v2 in the above case completely?
No. They are separate.
>
> 3. Will the power-domain drive the OPP ?
power-domain will driver its own state using its own OPP table.
Devices may fine tune within those states.
--
viresh
^ permalink raw reply
* Re: [PATCH V4 2/9] PM / Domains: Use OPP tables for power-domains
From: Viresh Kumar @ 2017-04-13 6:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, Stephen Boyd,
Nishanth Menon, robh+dt, lina.iyer, rnayak, devicetree
In-Reply-To: <6f72cb6e-2d8c-4e68-59cd-67f40e8c3118@arm.com>
On 12-04-17, 17:58, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> > The OPP table bindings contains all the necessary fields to support
> > power-domains now. Update the power-domain bindings to allow
> > "operating-points-v2" to be present within the power-domain node.
> >
> > Also allow consumer devices, that don't use OPP tables, to specify the
> > parent power-domain's performance level using the
> > "domain-performance-state" property.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > .../devicetree/bindings/power/power_domain.txt | 42 ++++++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> > index 723e1ad937da..5db112fa5d7c 100644
> > --- a/Documentation/devicetree/bindings/power/power_domain.txt
> > +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> > @@ -38,6 +38,9 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> > domain's idle states. In the absence of this property, the domain would be
> > considered as capable of being powered-on or powered-off.
> >
> > +- operating-points-v2 : This describes the performance states of a PM domain.
> > + Refer to ../opp/opp.txt for more information.
> > +
> > Example:
> >
> > power: power-controller@12340000 {
> > @@ -118,4 +121,43 @@ The node above defines a typical PM domain consumer device, which is located
> > inside a PM domain with index 0 of a power controller represented by a node
> > with the label "power".
> >
> > +Optional properties:
> > +- domain-performance-state: A positive integer value representing the minimum
> > + power-domain performance level required by the consumer device. The integer
> > + value '0' represents the lowest performance level and the higher values
> > + represent higher performance levels. The value of "domain-performance-state"
> > + field should match the "domain-performance-state" field of one of the OPP
> > + nodes in the parent power-domain's OPP table.
> > +
> > +
> > +
> > +Example:
> > +
> > + domain_opp_table: opp_table {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 970000 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 1000000 1085000>;
> > + };
> > + };
> > +
> > + parent: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
>
> As mentioned in the other email, it would be good to consider
> scalability with multiple power domains in a PM domain provider.
> i.e case of #power-domain-cells = <1> or more
Yeah, but that isn't supported for devices today. So no point
considering that today.
--
viresh
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020
From: Martin Kepplinger @ 2017-04-13 6:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: christian.gmeiner, linux, linux-input, linux-kernel, devicetree
In-Reply-To: <20170412154054.GB6297@dtor-ws>
On 2017-04-12 17:40, Dmitry Torokhov wrote:
> Hi Martin,
>
> On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote:
>> ar1021_i2c simply also supports the ar1020 device we use. This is tested.
>> They also share the same datasheet:
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf
>>
>> We differentiate not only to make it obvious that we support both devices,
>> but also to be able to implement the few model specific things in the
>> future.
>>
>> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
>> ---
>> drivers/input/touchscreen/Kconfig | 4 ++--
>> drivers/input/touchscreen/ar1021_i2c.c | 13 ++++++++++---
>> 2 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>> index 33c62e5..535b91a 100644
>> --- a/drivers/input/touchscreen/Kconfig
>> +++ b/drivers/input/touchscreen/Kconfig
>> @@ -96,8 +96,8 @@ config TOUCHSCREEN_AR1021_I2C
>> tristate "Microchip AR1021 i2c touchscreen"
>> depends on I2C && OF
>> help
>> - Say Y here if you have the Microchip AR1021 touchscreen controller
>> - chip in your system.
>> + Say Y here if you have the Microchip AR1020 or AR1021 touchscreen
>> + controller chip in your system.
>>
>> If unsure, say N.
>>
>> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
>> index 6562b17..1767257 100644
>> --- a/drivers/input/touchscreen/ar1021_i2c.c
>> +++ b/drivers/input/touchscreen/ar1021_i2c.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Microchip AR1021 driver for I2C
>> + * Microchip AR1020 and AR1021 driver for I2C
>> *
>> * Author: Christian Gmeiner <christian.gmeiner@gmail.com>
>> *
>> @@ -24,6 +24,11 @@ struct ar1021_i2c {
>> u8 data[AR1021_TOCUH_PKG_SIZE];
>> };
>>
>> +enum {
>> + ar1021,
>> + ar1020,
>> +};
>> +
>> static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
>> {
>> struct ar1021_i2c *ar1021 = dev_id;
>> @@ -151,13 +156,15 @@ static int __maybe_unused ar1021_i2c_resume(struct device *dev)
>> static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume);
>>
>> static const struct i2c_device_id ar1021_i2c_id[] = {
>> - { "MICROCHIP_AR1021_I2C", 0 },
>> + { "MICROCHIP_AR1021_I2C", ar1021 },
>> + { "MICROCHIP_AR1020_I2C", ar1020 },
>> { },
>> };
>> MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
>>
>> static const struct of_device_id ar1021_i2c_of_match[] = {
>> { .compatible = "microchip,ar1021-i2c", },
>> + { .compatible = "microchip,ar1020-i2c", },
>> { }
>> };
>> MODULE_DEVICE_TABLE(of, ar1021_i2c_of_match);
>> @@ -175,5 +182,5 @@ static struct i2c_driver ar1021_i2c_driver = {
>> module_i2c_driver(ar1021_i2c_driver);
>>
>> MODULE_AUTHOR("Christian Gmeiner <christian.gmeiner@gmail.com>");
>> -MODULE_DESCRIPTION("Microchip AR1021 I2C Driver");
>> +MODULE_DESCRIPTION("Microchip AR1020 and AR1021 I2C Driver");
>> MODULE_LICENSE("GPL");
>> --
>> 2.1.4
>>
>
> I do not see where you handle ar1020 differently from ar1021. If devices
> are compatible, you do not need to add a new compatible to the driver,
> simply use it in the binding:
>
> compatible = "microchip,ar1020-i2c", "microchip,ar1021-i2c";
>
> Thanks.
>
Why would you use "microchip,ar1020-i2c" in the dts if it's not
available? people don't obviously see, by grepping or reading,
that they have a compatible driver. ... or did I get you wrong?
I don't handle anything differently now. Factory reset has to be done
differntly though, as one example. So it'd be nice to have the option
to add data.
thanks
martin
^ permalink raw reply
* Re: [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Wu-Cheng Li (李務誠) @ 2017-04-13 6:50 UTC (permalink / raw)
To: Minghsiu Tsai
Cc: Hans Verkuil, Daniel Thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei,
srv_heupstream, Eddie Huang, Yingjoe Chen, devicetree,
linux-kernel, linux-arm-kernel, linux-media, linux-mediatek
In-Reply-To: <1492057130-1194-1-git-send-email-minghsiu.tsai@mediatek.com>
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
On Thu, Apr 13, 2017 at 12:18 PM, Minghsiu Tsai
<minghsiu.tsai@mediatek.com> wrote:
> From: Daniel Kurtz <djkurtz@chromium.org>
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
>
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 13afe48..8ab7ca0 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (mtk_mdp_is_target_compose(s->target))
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (mtk_mdp_is_target_crop(s->target))
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (mtk_mdp_is_target_compose(s->target))
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> int ret;
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (s->target == V4L2_SEL_TGT_COMPOSE)
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (s->target == V4L2_SEL_TGT_CROP)
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (s->target == V4L2_SEL_TGT_COMPOSE)
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> if (ret)
> return ret;
>
> - if (mtk_mdp_is_target_crop(s->target))
> + if (mtk_mdp_is_target_compose(s->target))
> frame = &ctx->s_frame;
> else
> frame = &ctx->d_frame;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v5 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-13 6:58 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij
Cc: Wolfram Sang, Rob Herring, Mark Rutland,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <ef75918a-3e5d-91d2-bc05-546e1e0f0bb4@axentia.se>
On 12.04.2017 18:53, Peter Rosin wrote:
> On 2017-04-12 10:26, Linus Walleij wrote:
>> On Tue, Apr 11, 2017 at 2:16 PM, <michael.hennerich@analog.com> wrote:
>>
>>> From: Michael Hennerich <michael.hennerich@analog.com>
>>>
>>> This patch adds support for the Analog Devices / Linear Technology
>>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>>> The LTC4306 optionally provides two general purpose input/output pins
>>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>>> push-pull outputs via the generic GPIOLIB framework.
>
> Great, thanks for your contribution Michael! Both patches pushed to the
> for-next branch of the i2c-mux tree.
>
>>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>> (...)
>>> Changes since v4:
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Please go ahead and merge to the i2c tree if you like.
>
> Yup, thanks for the review! (But not merged directly to the i2c tree,
> although they will get there eventually...)
>
> Cheers,
> peda
>
>
Peter and Linus,
Thanks for your precious time - really appreciated!
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* [PATCH 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC
From: sean.wang-NuS5LvNUpcJWk0Htik3J/w @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA
Cc: weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, Sean Wang
From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
This patchset introduces support for Mediatek hardware random generator (RNG)
Currently, the driver is already tested successfully with rng-tools on MT7623
SoC. And it should also be workable on other similar Mediatek SoCs.
SoC that also works on other similar SoCs.
Sean Wang (2):
dt-bindings: hwrng: Add Mediatek hardware random generator bindings
hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 +++
drivers/char/hw_random/Kconfig | 16 +-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 ++++++++++++++++++++++
4 files changed, 208 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
create mode 100644 drivers/char/hw_random/mtk-rng.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: sean.wang @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert, mpm, robh+dt, mark.rutland, clabbe.montjoie,
prasannatsmkumar, romain.perier, shannon.nelson
Cc: weiyongjun1, devicetree, linux-crypto, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 0000000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible : Should be "mediatek,mt7623-rng"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : Should contain "rng" entries;
+- reg : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng@1020f000 {
+ compatible = "mediatek,mt7623-rng";
+ reg = <0 0x1020f000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_TRNG>;
+ clock-names = "rng";
+};
--
1.9.1
^ 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