* [PATCH net v2 0/4] net: ethernet: fec: move GPR reigster offset and bit into DT
From: fugang.duan @ 2020-05-25 7:09 UTC (permalink / raw)
To: andrew, martin.fuzzey, davem
Cc: netdev, robh+dt, shawnguo, devicetree, kuba, fugang.duan
From: Fugang Duan <fugang.duan@nxp.com>
The commit da722186f654 (net: fec: set GPR bit on suspend by DT configuration) set the GPR reigster offset and bit in driver for wol feature.
It bring trouble to enable wol feature on imx6sx/imx6ul/imx7d platforms that have multiple ethernet instances with different GPR bit for stop mode control. So the patch set is to move GPR reigster offset and bit define into DT, and enable imx6q/imx6dl/imx6sx/imx6ul/imx7d stop mode support.
Currently, below NXP i.MX boards support wol:
- imx6q/imx6dl sabresd
- imx6sx sabreauto
- imx7d sdb
imx6q/imx6dl sarebsd board dts file miss the property "fsl,magic-packet;", so patch#4 is to add the property for stop mode support.
v1 -> v2:
- driver: switch back to store the quirks bitmask in driver_data
- dt-bindings: rename 'gpr' property string to 'fsl,stop-mode'
- imx6/7 dtsi: add imx6sx/imx6ul/imx7d ethernet stop mode property
Thanks Martin and Andrew for the review.
Fugang Duan (4):
net: ethernet: fec: move GPR register offset and bit into DT
dt-bindings: fec: update the gpr property
ARM: dts: imx: add ethernet stop mode property
ARM: dts: imx6qdl-sabresd: enable fec wake-on-lan
Documentation/devicetree/bindings/net/fsl-fec.txt | 7 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 +
arch/arm/boot/dts/imx6ul.dtsi | 2 +
arch/arm/boot/dts/imx7d.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
drivers/net/ethernet/freescale/fec_main.c | 103 +++++++---------------
8 files changed, 47 insertions(+), 72 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net v2 1/4] net: ethernet: fec: move GPR register offset and bit into DT
From: fugang.duan @ 2020-05-25 7:09 UTC (permalink / raw)
To: andrew, martin.fuzzey, davem
Cc: netdev, robh+dt, shawnguo, devicetree, kuba, fugang.duan
In-Reply-To: <1590390569-4394-1-git-send-email-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
The commit da722186f654 (net: fec: set GPR bit on suspend by DT
configuration) set the GPR reigster offset and bit in driver for
wake on lan feature.
But it introduces two issues here:
- one SOC has two instances, they have different bit
- different SOCs may have different offset and bit
So to support wake-on-lan feature on other i.MX platforms, it should
configure the GPR reigster offset and bit from DT.
So the patch is to improve the commit da722186f654 (net: fec: set GPR
bit on suspend by DT configuration) to support multiple ethernet
instances on i.MX series.
v2:
* switch back to store the quirks bitmask in driver_data
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/net/ethernet/freescale/fec_main.c | 103 ++++++++++--------------------
1 file changed, 34 insertions(+), 69 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 2e20914..4f55d30 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -86,56 +86,6 @@ static void fec_enet_itr_coal_init(struct net_device *ndev);
#define FEC_ENET_OPD_V 0xFFF0
#define FEC_MDIO_PM_TIMEOUT 100 /* ms */
-struct fec_devinfo {
- u32 quirks;
- u8 stop_gpr_reg;
- u8 stop_gpr_bit;
-};
-
-static const struct fec_devinfo fec_imx25_info = {
- .quirks = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR |
- FEC_QUIRK_HAS_FRREG,
-};
-
-static const struct fec_devinfo fec_imx27_info = {
- .quirks = FEC_QUIRK_MIB_CLEAR | FEC_QUIRK_HAS_FRREG,
-};
-
-static const struct fec_devinfo fec_imx28_info = {
- .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME |
- FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC |
- FEC_QUIRK_HAS_FRREG,
-};
-
-static const struct fec_devinfo fec_imx6q_info = {
- .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR006358 |
- FEC_QUIRK_HAS_RACC,
- .stop_gpr_reg = 0x34,
- .stop_gpr_bit = 27,
-};
-
-static const struct fec_devinfo fec_mvf600_info = {
- .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_RACC,
-};
-
-static const struct fec_devinfo fec_imx6x_info = {
- .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_HAS_AVB |
- FEC_QUIRK_ERR007885 | FEC_QUIRK_BUG_CAPTURE |
- FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE,
-};
-
-static const struct fec_devinfo fec_imx6ul_info = {
- .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR007885 |
- FEC_QUIRK_BUG_CAPTURE | FEC_QUIRK_HAS_RACC |
- FEC_QUIRK_HAS_COALESCE,
-};
-
static struct platform_device_id fec_devtype[] = {
{
/* keep it for coldfire */
@@ -143,25 +93,39 @@ static struct platform_device_id fec_devtype[] = {
.driver_data = 0,
}, {
.name = "imx25-fec",
- .driver_data = (kernel_ulong_t)&fec_imx25_info,
+ .driver_data = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR |
+ FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx27-fec",
- .driver_data = (kernel_ulong_t)&fec_imx27_info,
+ .driver_data = FEC_QUIRK_MIB_CLEAR | FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx28-fec",
- .driver_data = (kernel_ulong_t)&fec_imx28_info,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME |
+ FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC |
+ FEC_QUIRK_HAS_FRREG,
}, {
.name = "imx6q-fec",
- .driver_data = (kernel_ulong_t)&fec_imx6q_info,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
+ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR006358 |
+ FEC_QUIRK_HAS_RACC,
}, {
.name = "mvf600-fec",
- .driver_data = (kernel_ulong_t)&fec_mvf600_info,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_RACC,
}, {
.name = "imx6sx-fec",
- .driver_data = (kernel_ulong_t)&fec_imx6x_info,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
+ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_HAS_AVB |
+ FEC_QUIRK_ERR007885 | FEC_QUIRK_BUG_CAPTURE |
+ FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE,
}, {
.name = "imx6ul-fec",
- .driver_data = (kernel_ulong_t)&fec_imx6ul_info,
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
+ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR007885 |
+ FEC_QUIRK_BUG_CAPTURE | FEC_QUIRK_HAS_RACC |
+ FEC_QUIRK_HAS_COALESCE,
}, {
/* sentinel */
}
@@ -3476,19 +3440,23 @@ static int fec_enet_get_irq_cnt(struct platform_device *pdev)
}
static int fec_enet_init_stop_mode(struct fec_enet_private *fep,
- struct fec_devinfo *dev_info,
struct device_node *np)
{
struct device_node *gpr_np;
+ u32 out_val[3];
int ret = 0;
- if (!dev_info)
- return 0;
-
- gpr_np = of_parse_phandle(np, "gpr", 0);
+ gpr_np = of_parse_phandle(np, "fsl,stop-mode", 0);
if (!gpr_np)
return 0;
+ ret = of_property_read_u32_array(np, "fsl,stop-mode", out_val,
+ ARRAY_SIZE(out_val));
+ if (ret) {
+ dev_dbg(&fep->pdev->dev, "no stop mode property\n");
+ return ret;
+ }
+
fep->stop_gpr.gpr = syscon_node_to_regmap(gpr_np);
if (IS_ERR(fep->stop_gpr.gpr)) {
dev_err(&fep->pdev->dev, "could not find gpr regmap\n");
@@ -3497,8 +3465,8 @@ static int fec_enet_init_stop_mode(struct fec_enet_private *fep,
goto out;
}
- fep->stop_gpr.reg = dev_info->stop_gpr_reg;
- fep->stop_gpr.bit = dev_info->stop_gpr_bit;
+ fep->stop_gpr.reg = out_val[1];
+ fep->stop_gpr.bit = out_val[2];
out:
of_node_put(gpr_np);
@@ -3521,7 +3489,6 @@ fec_probe(struct platform_device *pdev)
int num_rx_qs;
char irq_name[8];
int irq_cnt;
- struct fec_devinfo *dev_info;
fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs);
@@ -3539,9 +3506,7 @@ fec_probe(struct platform_device *pdev)
of_id = of_match_device(fec_dt_ids, &pdev->dev);
if (of_id)
pdev->id_entry = of_id->data;
- dev_info = (struct fec_devinfo *)pdev->id_entry->driver_data;
- if (dev_info)
- fep->quirks = dev_info->quirks;
+ fep->quirks = pdev->id_entry->driver_data;
fep->netdev = ndev;
fep->num_rx_queues = num_rx_qs;
@@ -3575,7 +3540,7 @@ fec_probe(struct platform_device *pdev)
if (of_get_property(np, "fsl,magic-packet", NULL))
fep->wol_flag |= FEC_WOL_HAS_MAGIC_PACKET;
- ret = fec_enet_init_stop_mode(fep, dev_info, np);
+ ret = fec_enet_init_stop_mode(fep, np);
if (ret)
goto failed_stop_mode;
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 2/4] dt-bindings: fec: update the gpr property
From: fugang.duan @ 2020-05-25 7:09 UTC (permalink / raw)
To: andrew, martin.fuzzey, davem
Cc: netdev, robh+dt, shawnguo, devicetree, kuba, fugang.duan
In-Reply-To: <1590390569-4394-1-git-send-email-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
- rename the 'gpr' property string to 'fsl,stop-mode'.
- Update the property to define gpr register offset and
bit in DT, since different instance have different gpr bit.
v2:
* rename 'gpr' property string to 'fsl,stop-mode'.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
Documentation/devicetree/bindings/net/fsl-fec.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index 26c492a..9b54378 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -22,8 +22,11 @@ Optional properties:
- fsl,err006687-workaround-present: If present indicates that the system has
the hardware workaround for ERR006687 applied and does not need a software
workaround.
-- gpr: phandle of SoC general purpose register mode. Required for wake on LAN
- on some SoCs
+- fsl,stop-mode: register bits of stop mode control, the format is
+ <&gpr req_gpr req_bit>.
+ gpr is the phandle to general purpose register node.
+ req_gpr is the gpr register offset for ENET stop request.
+ req_bit is the gpr bit offset for ENET stop request.
-interrupt-names: names of the interrupts listed in interrupts property in
the same order. The defaults if not specified are
__Number of interrupts__ __Default__
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 3/4] ARM: dts: imx: add ethernet stop mode property
From: fugang.duan @ 2020-05-25 7:09 UTC (permalink / raw)
To: andrew, martin.fuzzey, davem
Cc: netdev, robh+dt, shawnguo, devicetree, kuba, fugang.duan
In-Reply-To: <1590390569-4394-1-git-send-email-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
- Update the imx6qdl gpr property to define gpr register
offset and bit in DT.
- Add imx6sx/imx6ul/imx7d ethernet stop mode property.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
arch/arm/boot/dts/imx6sx.dtsi | 2 ++
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
arch/arm/boot/dts/imx7d.dtsi | 1 +
arch/arm/boot/dts/imx7s.dtsi | 1 +
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 98da446..48f5016 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1045,7 +1045,7 @@
<&clks IMX6QDL_CLK_ENET>,
<&clks IMX6QDL_CLK_ENET_REF>;
clock-names = "ipg", "ahb", "ptp";
- gpr = <&gpr>;
+ fsl,stop-mode = <&gpr 0x34 27>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index d6f8317..09f21aa 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -930,6 +930,7 @@
"enet_clk_ref", "enet_out";
fsl,num-tx-queues = <3>;
fsl,num-rx-queues = <3>;
+ fsl,stop-mode = <&gpr 0x10 3>;
status = "disabled";
};
@@ -1039,6 +1040,7 @@
<&clks IMX6SX_CLK_ENET_PTP>;
clock-names = "ipg", "ahb", "ptp",
"enet_clk_ref", "enet_out";
+ fsl,stop-mode = <&gpr 0x10 4>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 2ccf67c..345ae9b 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -520,6 +520,7 @@
"enet_clk_ref", "enet_out";
fsl,num-tx-queues = <1>;
fsl,num-rx-queues = <1>;
+ fsl,stop-mode = <&gpr 0x10 4>;
status = "disabled";
};
@@ -856,6 +857,7 @@
"enet_clk_ref", "enet_out";
fsl,num-tx-queues = <1>;
fsl,num-rx-queues = <1>;
+ fsl,stop-mode = <&gpr 0x10 3>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 4c22828..cff875b 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -153,6 +153,7 @@
"enet_clk_ref", "enet_out";
fsl,num-tx-queues = <3>;
fsl,num-rx-queues = <3>;
+ fsl,stop-mode = <&gpr 0x10 4>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 76e3ffb..5bf0b39 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -1190,6 +1190,7 @@
"enet_clk_ref", "enet_out";
fsl,num-tx-queues = <3>;
fsl,num-rx-queues = <3>;
+ fsl,stop-mode = <&gpr 0x10 3>;
status = "disabled";
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 4/4] ARM: dts: imx6qdl-sabresd: enable fec wake-on-lan
From: fugang.duan @ 2020-05-25 7:09 UTC (permalink / raw)
To: andrew, martin.fuzzey, davem
Cc: netdev, robh+dt, shawnguo, devicetree, kuba, fugang.duan
In-Reply-To: <1590390569-4394-1-git-send-email-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
Enable ethernet wake-on-lan feature for imx6q/dl/qp sabresd
boards since the PHY clock is supplied by exteranl osc.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index fe59dde..28b35cc 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -204,6 +204,7 @@
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ fsl,magic-packet;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/5] dt-bindings: iio: imu: bmi160: convert txt format to yaml
From: Jonathan Albrieux @ 2020-05-25 7:27 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel, ~postmarketos/upstreaming, daniel.baluta,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Rob Herring
In-Reply-To: <20200524124114.7f4e785d@archlinux>
On Sun, May 24, 2020 at 12:41:14PM +0100, Jonathan Cameron wrote:
> On Wed, 20 May 2020 21:46:40 +0200
> Jonathan Albrieux <jonathan.albrieux@gmail.com> wrote:
>
> > Converts documentation from txt format to yaml.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
>
> A reminder on the maintainer bit as that thread crossed with
> this one. Also, drop the spi-max-frequency as we don't need
> to mention it explicitly for this device.
>
> Thanks,
>
> Jonathan
>
Thank you, I'll remove it today.
>
> > ---
> > .../devicetree/bindings/iio/imu/bmi160.txt | 37 ---------
> > .../bindings/iio/imu/bosch,bmi160.yaml | 76 +++++++++++++++++++
> > 2 files changed, 76 insertions(+), 37 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/imu/bmi160.txt b/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> > deleted file mode 100644
> > index 900c169de00f..000000000000
> > --- a/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> > +++ /dev/null
> > @@ -1,37 +0,0 @@
> > -Bosch BMI160 - Inertial Measurement Unit with Accelerometer, Gyroscope
> > -and externally connectable Magnetometer
> > -
> > -https://www.bosch-sensortec.com/bst/products/all_products/bmi160
> > -
> > -Required properties:
> > - - compatible : should be "bosch,bmi160"
> > - - reg : the I2C address or SPI chip select number of the sensor
> > - - spi-max-frequency : set maximum clock frequency (only for SPI)
> > -
> > -Optional properties:
> > - - interrupts : interrupt mapping for IRQ
> > - - interrupt-names : set to "INT1" if INT1 pin should be used as interrupt
> > - input, set to "INT2" if INT2 pin should be used instead
> > - - drive-open-drain : set if the specified interrupt pin should be configured as
> > - open drain. If not set, defaults to push-pull.
> > -
> > -Examples:
> > -
> > -bmi160@68 {
> > - compatible = "bosch,bmi160";
> > - reg = <0x68>;
> > -
> > - interrupt-parent = <&gpio4>;
> > - interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> > - interrupt-names = "INT1";
> > -};
> > -
> > -bmi160@0 {
> > - compatible = "bosch,bmi160";
> > - reg = <0>;
> > - spi-max-frequency = <10000000>;
> > -
> > - interrupt-parent = <&gpio2>;
> > - interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
> > - interrupt-names = "INT2";
> > -};
> > diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > new file mode 100644
> > index 000000000000..46cb4fde1165
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > @@ -0,0 +1,76 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/imu/bosch,bmi160.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Bosch BMI160
> > +
> > +maintainers:
> > + - Daniel Baluta <daniel.baluta@nxp.com> (?)
>
> Daniel's reply crossed with this. Given he's moved on to other things
> he's not happy to be listed as maintainer here.
>
> Given other threads, either put yourself here if you are happy to maintain
> the binding, or fall back to me but use my kernel.org address.
>
> Jonathan Cameron <jic23@kernel.org>
>
> I don't mind either way.
>
Thank you, I'll add you then for this binding.
Thank for your help,
Best regards,
Jonathan Albrieux
>
> > +
> > +description: |
> > + Inertial Measurement Unit with Accelerometer, Gyroscope and externally
> > + connectable Magnetometer
> > + https://www.bosch-sensortec.com/bst/products/all_products/bmi160
> > +
> > +properties:
> > + compatible:
> > + const: bosch,bmi160
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + spi-max-frequency:
> > + maxItems: 1
>
> spi-max-frequency doesn't need to be here at all. We aren't trying to list
> all of the properties that might be present - but rather those that
> are either required or that are part of the description of the device.
> This one is a generic spi binding that may or may not be present.
>
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + interrupt-names:
> > + enum:
> > + - INT1
> > + - INT2
> > + description: |
> > + set to "INT1" if INT1 pin should be used as interrupt input, set
> > + to "INT2" if INT2 pin should be used instead
> > +
> > + drive-open-drain:
> > + description: |
> > + set if the specified interrupt pin should be configured as
> > + open drain. If not set, defaults to push-pull.
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + - |
> > + // Example for I2C
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + bmi160@68 {
> > + compatible = "bosch,bmi160";
> > + reg = <0x68>;
> > + interrupt-parent = <&gpio4>;
> > + interrupts = <12 1>;
> > + interrupt-names = "INT1";
> > + };
> > + };
> > + - |
> > + // Example for SPI
> > + spi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + bmi160@0 {
> > + compatible = "bosch,bmi160";
> > + reg = <0>;
> > + spi-max-frequency = <10000000>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <12 1>;
> > + interrupt-names = "INT2";
> > + };
> > + };
>
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Ricardo Cañuelo @ 2020-05-25 7:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt,
xuwei5
In-Reply-To: <20200514152239.GG5955@pendragon.ideasonboard.com>
Hi Laurent,
On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > If we want to be more strict and require the definition of all the
> > supplies, there will be many more DTs changes in the series, and I'm not
> > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > at them and it's not always clear which regulators to use or if they are
> > even defined.
>
> We can decouple the two though (I think). The bindings should reflect
> what we consider right, and the dts files could be fixed on top.
Do you have a suggestion on how to do this? If we decouple the two
tasks most of the work would be searching for DTs to fix and finding a
way to fix each one of them, and unless I do this _before_ the binding
conversion I'll get a lot of dtbs_check errors.
The binding conversion itself is done, if we go this route the only
additional change would be to make the supplies required.
Cheers,
Ricardo
^ permalink raw reply
* Re: [PATCHv8 0/6] n_gsm serdev support and GNSS driver for droid4
From: Johan Hovold @ 2020-05-25 7:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tony Lindgren, Johan Hovold, Rob Herring, Alan Cox, Lee Jones,
Jiri Slaby, Merlijn Wajer, Pavel Machek, Peter Hurley,
Sebastian Reichel, linux-serial, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20200522091731.GA1203588@kroah.com>
On Fri, May 22, 2020 at 11:17:31AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 12, 2020 at 02:47:07PM -0700, Tony Lindgren wrote:
> > Hi all,
> >
> > Here's the updated set of these patches fixed up for Johan's and
> > Pavel's earlier comments.
> >
> > This series does the following:
> >
> > 1. Adds functions to n_gsm.c for serdev-ngsm.c driver to use
> >
> > 2. Adds a generic serdev-ngsm.c driver that brings up the TS 27.010
> > TTY ports configured in devicetree with help of n_gsm.c
> >
> > 3. Allows the use of standard Linux device drivers for dedicated
> > TS 27.010 channels for devices like GNSS and ALSA found on some
> > modems for example
> >
> > 4. Adds a gnss-motmdm consumer driver for the GNSS device found on
> > the Motorola Mapphone MDM6600 modem on devices like droid4
> >
> > I've placed the serdev-ngsm.c under drivers/tty/serdev as it still
> > seems to make most sense with no better places available. It's no
> > longer an MFD driver as it really does not need to care what channel
> > specific consumer drivers might be configured for the generic driver.
> > Now serdev-ngsm just uses of_platform_populate() to probe whatever
> > child nodes it might find.
> >
> > I'm not attached having the driver in drivers/tty/serdev. I just
> > don't have any better locations in mind. So using Johan's earlier
> > i2c example, the drivers/tty/serdev/serdev-ngsm.c driver is now a
> > generic protocol and bus driver, so it's getting closer to the
> > the drivers/i2c/busses analogy maybe :) Please do suggest better
> > locations other than MFD and misc if you have better ideas.
> >
> > Now without the chardev support, the /dev/gsmtty* using apps need
> > to use "U1234AT+CFUN?" format for the packets. The advantage is
> > less kernel code, and we keep the existing /dev/gsmtty* interface.
> >
> > If we still really need the custom chardev support, that can now
> > be added as needed with the channel specific consumer driver(s),
> > but looks like this won't be needed based on Pavel's ofono work.
>
> Johan and Rob, any objection/review of this series?
Yeah, sorry I haven't had time to review this yet. I should be able to
look at it today.
Johan
^ permalink raw reply
* [PATCH] arm64: dts: ls1028a: add one more thermal zone support
From: Yuantian Tang @ 2020-05-25 7:38 UTC (permalink / raw)
To: shawnguo, robh+dt, mark.rutland, catalin.marinas, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, Yuantian Tang
There are 2 thermal zones in ls1028a soc. Current dts only
includes one. This patch adds the other thermal zone node
in dts to enable it.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22 ++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 055f114cf848..bc6f0c0f85da 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -129,11 +129,31 @@
};
thermal-zones {
- core-cluster {
+ ddr-controller {
polling-delay-passive = <1000>;
polling-delay = <5000>;
thermal-sensors = <&tmu 0>;
+ trips {
+ ddr-ctrler-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ ddr-ctrler-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ core-cluster {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&tmu 1>;
+
trips {
core_cluster_alert: core-cluster-alert {
temperature = <85000>;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 1/4] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
From: Jonathan Albrieux @ 2020-05-25 8:00 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Rob Herring
In-Reply-To: <20200524155745.3b9320db@archlinux>
On Sun, May 24, 2020 at 03:57:45PM +0100, Jonathan Cameron wrote:
> On Wed, 20 May 2020 18:34:06 +0200
> Jonathan Albrieux <jonathan.albrieux@gmail.com> wrote:
>
> > Converts documentation from txt format to yaml.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
>
> An additional request inline. Doesn't effect this patch 'as such'.
>
> Also the file name thing just below here.
>
> > ---
> > .../bindings/iio/magnetometer/ak8975.txt | 30 --------
> > .../bindings/iio/magnetometer/ak8975.yaml | 71 +++++++++++++++++++
> File naming should match the compatible.
>
> ashahi-kasei,ak8975.yaml
>
Ok, I'll take this as general rule then :-)
> > 2 files changed, 71 insertions(+), 30 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > deleted file mode 100644
> > index aa67ceb0d4e0..000000000000
> > --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -* AsahiKASEI AK8975 magnetometer sensor
> > -
> > -Required properties:
> > -
> > - - compatible : should be "asahi-kasei,ak8975"
> > - - reg : the I2C address of the magnetometer
> > -
> > -Optional properties:
> > -
> > - - gpios : should be device tree identifier of the magnetometer DRDY pin
> > - - vdd-supply: an optional regulator that needs to be on to provide VDD
> > - - mount-matrix: an optional 3x3 mounting rotation matrix
> > -
> > -Example:
> > -
> > -ak8975@c {
> > - compatible = "asahi-kasei,ak8975";
> > - reg = <0x0c>;
> > - gpios = <&gpj0 7 0>;
> > - vdd-supply = <&ldo_3v3_gnss>;
> > - mount-matrix = "-0.984807753012208", /* x0 */
> > - "0", /* y0 */
> > - "-0.173648177666930", /* z0 */
> > - "0", /* x1 */
> > - "-1", /* y1 */
> > - "0", /* z1 */
> > - "-0.173648177666930", /* x2 */
> > - "0", /* y2 */
> > - "0.984807753012208"; /* z2 */
> > -};
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > new file mode 100644
> > index 000000000000..8bde423a2ffa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: AsahiKASEI AK8975 magnetometer sensor
> > +
> > +maintainers:
> > + - Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - const: asahi-kasei,ak8975
> > + - const: asahi-kasei,ak8963
> > + - const: asahi-kasei,ak09911
> > + - const: asahi-kasei,ak09912
> > + - const: ak8975
> > + deprecated: true
> > + - const: ak8963
> > + deprecated: true
> > + - const: ak09911
> > + deprecated: true
> > + - const: ak09912
> > + deprecated: true
> > +
> > + reg:
> > + maxItems: 1
> > + description: the I2C address of the magnetometer
> > +
> > + gpios:
> > + description: should be device tree identifier of the magnetometer DRDY pin
>
> Nothing to do with your patch obviously but this is horrible...
> + the driver will quite happily take an interrupt instead.
>
> Do you mind documenting the interrupt here as well?
>
> Should be a separate patch though. So a follow up one to
> this one. The
> arch/arm/boot/dts/motorola-mapphone-common.dtsi
> does it that way, unlike the samsung s3 which uses the gpio
> binding (I think it's the only one against quite a few
> using interrupts).
>
> Also switch the example to an interrupts one so we don't
> encourage anyone to go the gpios route.
>
> Note can be a follow up if this series is otherwise ready to go.
>
Oh ok, will add a new patch for that in this series if you don't
mind. It may even be better to split this series in two given
the amount of changes to the documentation outnumbered the changes
related to the driver itself, the first one regarding just the
conversion to yaml and clean-up-related changes to documentation
and the second one, depending on the first one, with the
reset-related changes.
Do you have advices on which of the two should be the best strategy?
I'll prepare both the versions today in order to choose the right
one once the path to follow has been decided,
Thank you,
Best regards,
Jonathan Albrieux
>
> > +
> > + vdd-supply:
> > + maxItems: 1
> > + description: |
> > + an optional regulator that needs to be on to provide VDD power to
> > + the sensor.
> > +
> > + mount-matrix:
> > + description: an optional 3x3 mounting rotation matrix
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + i2c@78b7000 {
> > + reg = <0x78b6000 0x600>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + magnetometer@c {
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0c>;
> > + gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> > + vdd-supply = <&ldo_3v3_gnss>;
> > + mount-matrix = "-0.984807753012208", /* x0 */
> > + "0", /* y0 */
> > + "-0.173648177666930", /* z0 */
> > + "0", /* x1 */
> > + "-1", /* y1 */
> > + "0", /* z1 */
> > + "-0.173648177666930", /* x2 */
> > + "0", /* y2 */
> > + "0.984807753012208"; /* z2 */
> > + };
> > + };
>
^ permalink raw reply
* Re: [PATCH 03/17] ARM: dts: r8a7742: Add I2C and IIC support
From: Geert Uytterhoeven @ 2020-05-25 8:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Lad, Prabhakar, Lad Prabhakar, Jens Axboe, Rob Herring,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux I2C, Linux MMC List, netdev, Linux-Renesas,
Linux Watchdog Mailing List
In-Reply-To: <20200522201727.GA21376@ninjato>
Hi Wolfram,
On Fri, May 22, 2020 at 10:17 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > According to the Hardware User's Manual Rev. 1.00, the registers do exist
> > > on all RZ/G1, except for RZ/G1E (see below).
> > >
> > > "(automatic transmission can be used as a hardware function, but this is
> > > not meaningful for actual use cases)."
> > >
> > > (whatever that comment may mean?)
>
> Strange comment, in deed. Given the paragraph before, I would guess Gen1
> maybe had a "fitting" PMIC where SoC/PMIC handled DVFS kind of magically
> with this automatic transfer feature? And Gen2 has not.
>
> > > On R-Car E3 and RZ/G2E, which have a single IIC instance, we
> > > handled that by:
> > >
> > > The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E)
> > > controllers are not considered compatible with
> > > "renesas,rcar-gen3-iic" or "renesas,rmobile-iic"
> > > due to the absence of automatic transmission registers.
>
> From a "describe the HW" point of view, this still makes sense to me.
> Although, it is unlikely we will add support for the automatic
> transmission feature (maybe famous last words).
;-)
> > > On R-Car E2 and RZ/G1E, we forgot, and used both SoC-specific and
> > > family-specific compatible values.
>
> Okay, but we can fix DTs when they have bugs, or?
We can. But we also have to consider DT backwards compatibility: i.e.
using an old DTB with a future kernel implementing the automatic
transmission feature.
Fortunately R-Car E2 and RZ/G1E have SoC-specific compatible values,
so we can easily blacklist it in the driver based on that.
Blacklisting the last instance on the other SoCs is uglier, as it needs a
quirk that checks both the SoC-compatible value and the absence of the
generic compatible value. But it can still be done.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: apq8016-sbc-d3: Add Qualcomm APQ8016 SBC + D3Camera mezzanine
From: Robert Foss @ 2020-05-25 8:35 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, Vinod Koul, Rob Herring, linux-arm-msm,
devicetree, linux-kernel, Nicolas Dechesne
In-Reply-To: <20200519232442.GE2165@builder.lan>
Hi Bjorn,
Thanks for the review. I'll incorporate the changes if we decide to
that this DT should live upstream.
On Wed, 20 May 2020 at 01:26, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Tue 19 May 03:22 PDT 2020, Manivannan Sadhasivam wrote:
>
> > Hi Robert,
> >
> > On Mon, May 18, 2020 at 10:21:29AM +0200, Robert Foss wrote:
> > > Add device treee support for the Qualcomm APQ8016 SBC, otherwise known as
> > > the Dragonboard 410c with the D3Camera mezzanine expansion board.
> > >
> > > The D3Camera mezzanine ships in a kit with a OmniVision 5640 sensor module,
> > > which is what this DT targets.
> > >
> >
> > What is the motivation behind adding this new dts? We have been using the
> > userspace tool [1] for applying this as an overlay for some time. But if we
> > start adding dts for mezzanines then for sure we'll end up with some good
> > numbers which will flood arch/{..}/qcom directory.
> >
> > I could understand that one of the motivation is to provide nice user experience
> > to users but that's also taken care by the dt-update tool IMO.
> >
>
> The motivation for posting this was to provoke a response like yours.
>
> I knew about [1], but not that it included the overlays. I'm okay with
> using overlays and the dt-update tool. But I would have preferred that
> the dts files didn't live out of tree, given that this approach breaks
> if I change the name of a node you depend on upstream.
I wasn't aware of the dt-update tool, and it seems pretty neat.
However, a thought I had is that using it to enable a dt-node or a
board variant is not very different from applying a patch the the
upstream tree. The work it takes to do it is about the same, and the
maintenance burden of using a patch is about the same as using
dt-tool.
> > [1] https://github.com/96boards/dt-update
^ permalink raw reply
* Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function
From: Matthias Brugger @ 2020-05-25 8:38 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter, devicetree,
wsd_upstream, linux-kernel, DRI Development, HS Liao,
moderated list:ARM/Mediatek SoC support, Houlong Wei, Linux ARM
In-Reply-To: <CAAOTY___HNcRPr8Jq-wNPO_G9pLVjf2D7ezbpPcGbXVNYy1_nA@mail.gmail.com>
On 25/05/2020 02:23, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
>>
>>
>>
>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>> Export finalize function to client which helps append eoc and jump
>>> command to pkt. Let client decide call finalize or not.
>>>
>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>> ---
>>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
>>> include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
>>> 3 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> index 0dfcd1787e65..7daaabc26eb1 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
>>> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
>>> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
>>> mtk_crtc_ddp_config(crtc, cmdq_handle);
>>> + cmdq_pkt_finalize(cmdq_handle);
>>> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>>> }
>>> #endif
>>
>> This should be a independent patch.
>> Other then that patch looks good.
>
> Apply only drm part or only cmdq helpr part, it would be abnormal.
Right it would break DRM driver (if only applied to cmdq) or compilation if only
applied to DRM.
> Shall we seperate this patch?
After thinking twice, I think we can leave it as it is. If you provide your
Acked-by I can take it thorugh my tree, if that's OK for you.
Regards,
Matthias
> Or seperate it but make sure these two patches be in the same tree?
>
> Regards,
> Chun-Kuang.
>
>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index a9ebbabb7439..59bc1164b411 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
>>> }
>>> EXPORT_SYMBOL(cmdq_pkt_assign);
>>>
>>> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> {
>>> struct cmdq_instruction inst = { {0} };
>>> int err;
>>> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>>
>>> return err;
>>> }
>>> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>>>
>>> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
>>> {
>>> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
>>> unsigned long flags = 0;
>>> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>>>
>>> - err = cmdq_pkt_finalize(pkt);
>>> - if (err < 0)
>>> - return err;
>>> -
>>> pkt->cb.cb = cb;
>>> pkt->cb.data = data;
>>> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index fec292aac83c..99e77155f967 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>>> */
>>> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>>>
>>> +/**
>>> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
>>> + * @pkt: the CMDQ packet
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + */
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
>>> +
>>> /**
>>> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>>> * packet and call back at the end of done packet
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/4] pinctrl: sunxi: add support for the Allwinner A100 pin controller
From: Maxime Ripard @ 2020-05-22 15:28 UTC (permalink / raw)
To: Frank Lee
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
huangshuosheng, tiny.windzz, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522030743.10204-3-frank@allwinnertech.com>
[-- Attachment #1: Type: text/plain, Size: 35314 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:41AM +0800, Frank Lee wrote:
> This commit introduces support for the pin controller on A100.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
> ---
> drivers/pinctrl/sunxi/Kconfig | 10 +
> drivers/pinctrl/sunxi/Makefile | 2 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 +++
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 710 ++++++++++++++++++
This will need a DT binding too, and please make sure to run checkpatch with
--strict, you have a bunch of misaligned parenthesis.
> 4 files changed, 827 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f7aae200ee15..593293584ecc 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -94,6 +94,16 @@ config PINCTRL_SUN50I_A64_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_A100
> + bool "Support for the Allwinner A100 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> +config PINCTRL_SUN50I_A100_R
> + bool "Support for the Allwinner A100 R-PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> config PINCTRL_SUN50I_H5
> bool "Support for the Allwinner H5 PIO"
> default ARM64 && ARCH_SUNXI
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index fafcdae8134f..8b7ff0dc3bdf 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -13,6 +13,8 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100) += pinctrl-sun50i-a100.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100_R) += pinctrl-sun50i-a100-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> new file mode 100644
> index 000000000000..d38d8770c9da
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_pwm"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x3, "s_cir"), /* IN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),
> +};
> +
> +static const struct sunxi_pinctrl_desc a100_r_pinctrl_data = {
> + .pins = a100_r_pins,
> + .npins = ARRAY_SIZE(a100_r_pins),
> + .pin_base = PL_BASE,
> + .irq_banks = 1,
> +};
> +
> +static int a100_r_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev, &a100_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id a100_r_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-a100-r-pinctrl", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, a100_r_pinctrl_match);
> +
> +static struct platform_driver a100_r_pinctrl_driver = {
> + .probe = a100_r_pinctrl_probe,
> + .driver = {
> + .name = "sun50iw10p1-r-pinctrl",
> + .of_match_table = a100_r_pinctrl_match,
> + },
> +};
> +module_platform_driver(a100_r_pinctrl_driver);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> new file mode 100644
> index 000000000000..b9591009f0a4
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> @@ -0,0 +1,710 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* MCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* BCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s0"), /* LRCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DIN */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DIN1 */
I guess the second one would be i2s1?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DOUT */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* TX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* RX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x4, "pwm1"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE0 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D4 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ5 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ4 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D5 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ3 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ2 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D6 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ1 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D2 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* WP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D7 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* HOLD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 16)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D4 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D5 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D7 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKM */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D10 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKP */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D11 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKN */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D12 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D13 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D14 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D15 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D18 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D19 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D20 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D21 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D22 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D23 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* CLK */
> + SUNXI_FUNCTION(0x4, "uart4"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* DE */
> + SUNXI_FUNCTION(0x4, "uart4"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 19)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* HSYNC */
> + SUNXI_FUNCTION(0x3, "pwm2"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 20)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* VSYNC */
> + SUNXI_FUNCTION(0x3, "pwm3"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 21)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm1"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 22)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm0"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 23)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION(0x3, "pll"), /* LOCK_DBG */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "ledc"), /* LEDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT0 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SM_VS */
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT1 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "tcon0"), /* TRIG */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT2 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT3 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 9)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* MS1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
We should use another name here, since the code will just pick the first one and
ignore the second. What about jtag-gpu?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D0 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DI1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CMD */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* CK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 6)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */
> + SUNXI_FUNCTION(0x3, "i2s1"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* LRCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DIN1 */
This is suspicious too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DOUT1 */
Here too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 13)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "cpu"), /* CUR_W */
What is "cpu" supposed to be?
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* CLKIN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CS */
> + SUNXI_FUNCTION(0x4, "cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CLK */
> + SUNXI_FUNCTION(0x4, "ledc"),
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MOSI */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MISO */
> + SUNXI_FUNCTION(0x4, "spdif"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* CLK */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN2 */
Same issue than previously
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA0 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA1 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDIO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA2 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN1 */
Here as well
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA3 */
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* EPHY */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN1 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT1 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN0 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT2 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN2 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* IN */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT3 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN3 */
Ditto
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] arm64: allwinner: A100: add support for Allwinner Perf1 board
From: Maxime Ripard @ 2020-05-22 15:31 UTC (permalink / raw)
To: Frank Lee
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
huangshuosheng, tiny.windzz, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522030743.10204-5-frank@allwinnertech.com>
[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:43AM +0800, Frank Lee wrote:
> A100 perf1 is an Allwinner A100-based SBC, with the following features:
>
> - 1GiB DDR3 DRAM
> - AXP803 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - on-board Nand flash
> - ···
>
> Adds initial support for it, including the UART.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
Which bootloader have you used to test this?
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 27 +++++++++++++++++++
> 2 files changed, 28 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index e4d3cd0ac5bb..ab780dbdd17b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-emlid-neutis-n5-devboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> new file mode 100644
> index 000000000000..32c9986920ed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +
> +/{
> + model = "A100 perf1";
Having the same casing and the "brand" would be great here, so something like
"Allwinner A100 Perf1", or just Perf1 if that name is only ever going to be used
on the A100
> + compatible = "allwinner,a100-perf1", "allwinner,sun50i-a100";
This binding needs to be documented
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
From: Matthias Brugger @ 2020-05-25 8:39 UTC (permalink / raw)
To: Dennis-YC Hsieh
Cc: Rob Herring, Mark Rutland, Jassi Brar, Philipp Zabel,
David Airlie, Daniel Vetter, linux-kernel, linux-mediatek,
devicetree, wsd_upstream, dri-devel, Bibby Hsieh, CK Hu,
Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <1590373621.31522.7.camel@mtkswgap22>
On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
>
> On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
>>
>> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> Thanks for your comment.
>>>
>>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
>>>>
>>>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>>>> add write_s function in cmdq helper functions which
>>>>> writes a constant value to address with large dma
>>>>> access support.
>>>>>
>>>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>>>> ---
>>>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
>>>>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
>>>>> 2 files changed, 40 insertions(+)
>>>>>
>>>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> index 03c129230cd7..a9ebbabb7439 100644
>>>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> }
>>>>> EXPORT_SYMBOL(cmdq_pkt_write_s);
>>>>>
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask)
>>>>> +{
>>>>> + struct cmdq_instruction inst = { {0} };
>>>>> + int err;
>>>>> +
>>>>> + if (mask != U32_MAX) {
>>>>> + inst.op = CMDQ_CODE_MASK;
>>>>> + inst.mask = ~mask;
>>>>> + err = cmdq_pkt_append_command(pkt, inst);
>>>>> + if (err < 0)
>>>>> + return err;
>>>>> +
>>>>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
>>>>> + } else {
>>>>> + inst.op = CMDQ_CODE_WRITE_S;
>>>>> + }
>>>>> +
>>>>> + inst.sop = high_addr_reg_idx;
>>>>
>>>> Writing u16 value in a 5 bit wide variable?
>>>
>>> We need only 5 bits in this case. I'll change high_addr_reg_idx
>>> parameter to u8.
>>>
>>
>> Ok, please make sure to mask the value, so that it's explicit in the code that
>> we only use the lowest 5 bits of high_addr_reg_idx.
>
> Is it necessary to mask the value?
> Since sop already defined as "u8 sop:5;", I thought it is explicit that
> only use 5 bits and compiler should do the rest jobs.
Yes but it makes the code more explicit if we have a
inst.sop = high_addr_reg_idx & 0x1f;
What do you think?
Regards,
Matthias
>
>
> Regards,
> Dennis
>
>>
>> Regards,
>> Matthias
>>
>>>>
>>>>> + inst.offset = addr_low;
>>>>> + inst.value = value;
>>>>> +
>>>>> + return cmdq_pkt_append_command(pkt, inst);
>>>>> +}
>>>>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
>>>>> +
>>>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>>>>> {
>>>>> struct cmdq_instruction inst = { {0} };
>>>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> index 01b4184af310..fec292aac83c 100644
>>>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
>>>>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> u16 addr_low, u16 src_reg_idx, u32 mask);
>>>>>
>>>>> +/**
>>>>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
>>>>> + * packet which write value to a physical address
>>>>> + * @pkt: the CMDQ packet
>>>>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
>>>>
>>>> register
>>>
>>> will fix
>>>
>>>
>>> Regards,
>>> Dennis
>>>
>>>>
>>>>> + * @addr_low: low address of pa
>>>>> + * @value: the specified target value
>>>>> + * @mask: the specified target mask
>>>>> + *
>>>>> + * Return: 0 for success; else the error code is returned
>>>>> + */
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask);
>>>>> +
>>>>> /**
>>>>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>>>>> * @pkt: the CMDQ packet
>>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Linus Walleij @ 2020-05-25 8:43 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel@vger.kernel.org, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, open list:IIO SUBSYSTEM AND DRIVERS,
Peter Meerwald-Stadler, Steve Winslow, Thomas Gleixner,
Jonathan Cameron, Rob Herring
In-Reply-To: <20200518133645.19127-3-jonathan.albrieux@gmail.com>
On Mon, May 18, 2020 at 3:37 PM Jonathan Albrieux
<jonathan.albrieux@gmail.com> wrote:
> + reset-gpio:
> + description: an optional pin needed for AK09911 to set the reset state
This kind of properties should always be plural, so
reset-gpios please.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-25 8:47 UTC (permalink / raw)
To: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
On 14.05.20 17:57, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
> 2 files changed, 1175 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>
hi,
I highly appreciate it in case you can take time to review. It's not the
smallest board, but this "base" support isn't huge either. For
devicetree people this is certainly easy to read and I'll be happy for
any opinions, objections or Acks you might have.
thanks,
martin
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc,ocelot-sgpio
From: Linus Walleij @ 2020-05-25 8:50 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
Alexandre Belloni
In-Reply-To: <87pnb1nf2j.fsf@soft-dev15.microsemi.net>
On Mon, May 18, 2020 at 10:50 PM Lars Povlsen
<lars.povlsen@microchip.com> wrote:
> Linus Walleij writes:
>
> > On Wed, May 13, 2020 at 4:11 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> >
> >> This adds DT bindings for the Microsemi SGPIO controller, bindings
> >> mscc,ocelot-sgpio and mscc,luton-sgpio.
> >>
> >> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> >
> >> + microchip,sgpio-ports:
> >> + description: This is a 32-bit bitmask, configuring whether a
> >> + particular port in the controller is enabled or not. This allows
> >> + unused ports to be removed from the bitstream and reduce latency.
> >> + $ref: "/schemas/types.yaml#/definitions/uint32"
> >
> > I don't know about this.
> >
> > You are saying this pin controller can have up to 32 GPIO "ports"
> > (also known as banks).
> >
> > Why can't you just represent each such port as a separate GPIO
> > node:
> >
> > pinctrl@nnn {
> > gpio@0 {
> > ....
> > };
> > gpio@1 {
> > ....
> > };
> > ....
> > gpio@31 {
> > ....
> > };
> > };
> >
> > Then if some of them are unused just set it to status = "disabled";
> >
> > This also makes your Linux driver simpler because each GPIO port
> > just becomes a set of 32bit registers and you can use
> > select GPIO_GENERIC and bgpio_init() and save a whole
> > slew of standard stock code.
> >
>
> Linus, thank you for your input.
>
> The controller handles an array of 32*n signals, where n >= 1 && n <=
> 4.
>
> The problem with the above approach is that the ports are disabled
> *port*-wise - so they remove all (upto) 4 bits. That would be across the
> banks.
>
> You could of course have the "implied" semantics that a disabled port at
> any bit position disabled all (bit positions for the same port).
I don't understand this, you would have to elaborate...
In any case microchip,sgpio-ports is probably not the right thing,
use ngpios which is documented and just divide by 32 to get the
number of ports I think? But that is just in case they get
enabled strictly in sequence, otherwise you'd need a custom
property.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
From: Bartosz Golaszewski @ 2020-05-25 9:05 UTC (permalink / raw)
To: Michael Walle
Cc: Andy Shevchenko, linux-gpio, linux-devicetree, LKML, linux-hwmon,
linux-pwm, LINUXWATCHDOG, arm-soc, Linus Walleij, Rob Herring,
Jean Delvare, Guenter Roeck, Lee Jones, Thierry Reding,
Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Brown,
Greg Kroah-Hartman
In-Reply-To: <75bff2917be1badd36af9f980cf59d2c@walle.cc>
wt., 12 maj 2020 o 16:41 Michael Walle <michael@walle.cc> napisał(a):
>
> >> +
> >> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> >> +MODULE_DESCRIPTION("GPIO generic regmap driver core");
> >> +MODULE_LICENSE("GPL");
> >> diff --git a/include/linux/gpio-regmap.h b/include/linux/gpio-regmap.h
> >> new file mode 100644
> >> index 000000000000..a868cbcde6e9
> >> --- /dev/null
> >> +++ b/include/linux/gpio-regmap.h
> >> @@ -0,0 +1,69 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +
> >> +#ifndef _LINUX_GPIO_REGMAP_H
> >> +#define _LINUX_GPIO_REGMAP_H
> >> +
> >> +struct gpio_regmap;
> >> +
> >> +#define GPIO_REGMAP_ADDR_ZERO ((unsigned long)(-1))
> >> +#define GPIO_REGMAP_ADDR(addr) ((addr) ? : GPIO_REGMAP_ADDR_ZERO)
> >> +
> >
> > What if the addr is actually 0?
>
> Then the driver has to set GPIO_REGMAP_ADDR_ZERO or use the convenience
> macro GPIO_REGMAP_ADDR.
>
> So you can have
>
> struct gpio_regmap_config config = { 0 };
> config.reg_dat_base = 0x10;
> config.reg_dir_out_base = 0x20;
>
> or
>
> config.reg_dat_base = GPIO_REGMAP_ADDR_ZERO;
>
> or if you can't be sure if the RHS value might be zero:
>
> config.reg_dat_base = GPIO_REGMAP_ADDR(reg);
>
>
> > Maybe drop GPIO_REGMAP_ADDR and require users to set unused registers
> > to GPIO_REGMAP_ADDR_ZERO?
>
> Thats bad because:
> * you'd have to set plenty of unused base registers for a simple driver
> * if there will be additional properties in the future, you have to
> touch
> all other drivers, because they are initialized as 0 (ie. valid reg
> 0).
>
> >> +/**
> >> + * struct gpio_regmap_config - Description of a generic regmap
> >> gpio_chip.
> >> + *
> >> + * @parent: The parent device
> >> + * @regmap: The regmap used to access the registers
> >> + * given, the name of the device is used
> >> + * @label: (Optional) Descriptive name for GPIO
> >> controller.
> >> + * If not given, the name of the device is used.
> >> + * @ngpio: Number of GPIOs
> >> + * @reg_dat_base: (Optional) (in) register base address
> >> + * @reg_set_base: (Optional) set register base address
> >> + * @reg_clr_base: (Optional) clear register base address
> >> + * @reg_dir_in_base: (Optional) out setting register base address
> >> + * @reg_dir_out_base: (Optional) in setting register base address
> >
> > The two above are inverted I think?
> good catch.
>
> > Also: why the limitation of only supporting one at a time?
>
> they should be exclusive, either you have a register where you set the
> output bits to one, or the input bits. Maybe this need a bit more
> context
> above. in gpio-mmio.c you can set both and both are used in
> set_direction(), but only one is read in get_direction().
>
> That being said, I have no strong opinion wether they should be
> exclusive
> or not, besides the symmetry of set_/get_direction().
>
> -michael
>
Sorry for the late response, your comments make sense to me. Are you
going to submit a v4 before the v5.8 merge window?
Bart
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Pavel Machek @ 2020-05-25 9:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Martin Blumenstingl, robh+dt, andrew, linux-amlogic, devicetree,
jianxin.pan, davem, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <d3f596d7-fb7f-5da7-4406-b5c0e9e9dc3f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
Hi!
> > On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> >> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> >> delay. Add a property with the known supported values so it can be
> >> configured according to the board layout.
> >>
> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >> ---
> >> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> index ae91aa9d8616..66074314e57a 100644
> >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> @@ -67,6 +67,19 @@ allOf:
> >> PHY and MAC are adding a delay).
> >> Any configuration is ignored when the phy-mode is set to "rmii".
> >>
> >> + amlogic,rx-delay-ns:
> >> + enum:
> >
> > Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
> > prefix?
>
> Yes, there are several MAC bindings that already define a delay property:
>
> Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
> allwinner,rx-delay-ps:
> Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
> allwinner,rx-delay-ps:
> Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- rx-delay:
> Delay value for RGMII bridge RX clock.
> Documentation/devicetree/bindings/net/apm-xgene-enet.txt: rx-delay
> = <2>;
> Documentation/devicetree/bindings/net/cavium-pip.txt:- rx-delay: Delay
> value for RGMII receive clock. Optional. Disabled if 0.
> Documentation/devicetree/bindings/net/mediatek-dwmac.txt:-
> mediatek,rx-delay-ps: RX clock delay macro value. Default is 0.
> Documentation/devicetree/bindings/net/mediatek-dwmac.txt:
> mediatek,rx-delay-ps = <1530>;
>
> standardizing on rx-delay-ps and tx-delay-ps would make sense since that
> is the lowest resolution and the property would be correctly named with
> an unit in the name.
Seems like similar patch is already being reviewed from Dan Murphy (?)
from TI.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Add renesas,em-gio bindings
From: Linus Walleij @ 2020-05-25 9:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Rob Herring, Magnus Damm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux-Renesas
In-Reply-To: <20200519081157.29095-1-geert+renesas@glider.be>
On Tue, May 19, 2020 at 10:11 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile General
> Purpose I/O Interface.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Pretty uncontroversial patch and you know what you're doing so
patch applied with Niklas' review tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] arm: dts: am33xx-bone-common: add gpio-line-names
From: Linus Walleij @ 2020-05-25 9:23 UTC (permalink / raw)
To: Drew Fustini
Cc: Grygorii Strashko, Benoît Cousson, Tony Lindgren,
Rob Herring, Linux-OMAP,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jason Kridner, Robert Nelson
In-Reply-To: <20200520220203.GA363398@x1>
On Thu, May 21, 2020 at 12:02 AM Drew Fustini <drew@beagleboard.org> wrote:
> I've posted a v2 which I hope improves the intent of the line names. [0]
>
> I'm happy to integrate any feedback and create a v3 - especially if it
> is prefered for me to list the specific peripherial signals instead of
> an abstract term like "[ethernet]" or "[emmc]". This is for lines that
> can not be used because they are not routed to the expansion headers.
>
> [0] https://lore.kernel.org/linux-omap/20200520214757.GA362547@x1/T/#u
This looks good to me. FWIW
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 9:37 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, devicetree-owner
In-Reply-To: <20200524023815.21789-2-jonathan@marek.ca>
Hi Jonathan,
On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8150. Note that adding the iommus field
> for
> UFS is required because initializing the iommu removes the bypass
> mapping
> that created by the bootloader.
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index a36512d1f6a1..acb839427b12 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
> resets = <&gcc GCC_UFS_PHY_BCR>;
> reset-names = "rst";
>
> + iommus = <&apps_smmu 0x300 0>;
> +
> clock-names =
> "core_clk",
> "bus_aggr_clk",
> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
> compatible = "snps,dwc3";
> reg = <0 0x0a600000 0 0xcd00>;
> interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&apps_smmu 0x140 0>;
> snps,dis_u2_susphy_quirk;
> snps,dis_enblslpm_quirk;
> phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
> cell-index = <0>;
> };
>
> + apps_smmu: iommu@15000000 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
This should be qcom,sm8150-smmu-500 and also you need to update the
arm-smmu
binding with this compatible in a separate patch.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 9:42 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <20200524023815.21789-3-jonathan@marek.ca>
Hi Jonathan,
On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8250. Note that adding the iommus field
> for
> UFS is required because initializing the iommu removes the bypass
> mapping
> that created by the bootloader.
>
This statement doesn't seem right, you can just say since the bypass is
disabled
by default now, we need to add this property to enable translation and
avoid global faults.
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 2f99c350c287..43c5e48c15e2 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>
> power-domains = <&gcc UFS_PHY_GDSC>;
>
> + iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
> +
> clock-names =
> "core_clk",
> "bus_aggr_clk",
> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
> wakeup-parent = <&pdc>;
> };
>
> + apps_smmu: iommu@15000000 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
This should be qcom,sm8250-smmu-500 and also you need to update the
arm-smmu
binding with this compatible in a separate patch.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox