Re: [PATCH v2 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP
On Tue, Sep 12, 2023 at 06:30:21PM +0300, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> Add the reserve-memory nodes used by DSP when the rpmsg
> feature is enabled.
>
> Signed-off-by: Iuliana Prodan
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index cc406bb338fe..59e672382b07 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -211,6 +211,19 @@
> reg = <0 0x9240 0 0x200>;
> no-map;
> };
> + dsp_vdev0vring0: vdev0vring0@942f {
> + reg = <0 0x942f 0 0x8000>;
> + no-map;
> + };
Please have a newline between nodes.
Shawn
> + dsp_vdev0vring1: vdev0vring1@942f8000 {
> + reg = <0 0x942f8000 0 0x8000>;
> + no-map;
> + };
> + dsp_vdev0buffer: vdev0buffer@9430 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x9430 0 0x10>;
> + no-map;
> + };
> };
>
> pmu {
> --
> 2.17.1
>
[PATCH v3] brcmfmac: support parse country code map from DT
With any regulatory domain requests coming from either user space or
802.11 IE (Information Element), the country is coded in ISO3166
standard. It needs to be translated to firmware country code and
revision with the mapping info in settings->country_codes table.
Support populate country_codes table by parsing the mapping from DT.
The BRCMF_BUSTYPE_SDIO bus_type check gets separated from general DT
validation, so that country code can be handled as general part rather
than SDIO bus specific one.
Signed-off-by: Shawn Guo
Reviewed-by: Arend van Spriel
---
Changes for v3:
- Add missing terminating '\n' in brcmf_dbg(INFO, ...) format string.
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 57 ++-
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index a7554265f95f..2f7bc3a70c65 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -12,12 +12,59 @@
#include "common.h"
#include "of.h"
+static int brcmf_of_get_country_codes(struct device *dev,
+ struct brcmf_mp_device *settings)
+{
+ struct device_node *np = dev->of_node;
+ struct brcmfmac_pd_cc_entry *cce;
+ struct brcmfmac_pd_cc *cc;
+ int count;
+ int i;
+
+ count = of_property_count_strings(np, "brcm,ccode-map");
+ if (count < 0) {
+ /* The property is optional, so return success if it doesn't
+* exist. Otherwise propagate the error code.
+*/
+ return (count == -EINVAL) ? 0 : count;
+ }
+
+ cc = devm_kzalloc(dev, sizeof(*cc) + count * sizeof(*cce), GFP_KERNEL);
+ if (!cc)
+ return -ENOMEM;
+
+ cc->table_size = count;
+
+ for (i = 0; i < count; i++) {
+ const char *map;
+
+ cce = >table[i];
+
+ if (of_property_read_string_index(np, "brcm,ccode-map",
+ i, ))
+ continue;
+
+ /* String format e.g. US-Q2-86 */
+ if (sscanf(map, "%2c-%2c-%d", cce->iso3166, cce->cc,
+ >rev) != 3)
+ brcmf_err("failed to read country map %s\n", map);
+ else
+ brcmf_dbg(INFO, "%s-%s-%d\n", cce->iso3166, cce->cc,
+ cce->rev);
+ }
+
+ settings->country_codes = cc;
+
+ return 0;
+}
+
void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
struct brcmf_mp_device *settings)
{
struct brcmfmac_sdio_pd *sdio = >bus.sdio;
struct device_node *root, *np = dev->of_node;
int irq;
+ int err;
u32 irqf;
u32 val;
@@ -43,8 +90,14 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type
bus_type,
of_node_put(root);
}
- if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
- !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ return;
+
+ err = brcmf_of_get_country_codes(dev, settings);
+ if (err)
+ brcmf_err("failed to get OF country code map (err=%d)\n", err);
+
+ if (bus_type != BRCMF_BUSTYPE_SDIO)
return;
if (of_property_read_u32(np, "brcm,drive-strength", ) == 0)
--
2.17.1
Re: [PATCH v2 2/2] brcmfmac: support parse country code map from DT
On Fri, Apr 16, 2021 at 2:00 PM Arend Van Spriel
wrote:
>
> On 4/15/2021 12:47 PM, Shawn Guo wrote:
> > With any regulatory domain requests coming from either user space or
> > 802.11 IE (Information Element), the country is coded in ISO3166
> > standard. It needs to be translated to firmware country code and
> > revision with the mapping info in settings->country_codes table.
> > Support populate country_codes table by parsing the mapping from DT.
> >
> > The BRCMF_BUSTYPE_SDIO bus_type check gets separated from general DT
> > validation, so that country code can be handled as general part rather
> > than SDIO bus specific one.
>
> Had another look
>
> > Signed-off-by: Shawn Guo
> > Reviewed-by: Arend van Spriel
> > ---
> > .../wireless/broadcom/brcm80211/brcmfmac/of.c | 57 ++-
> > 1 file changed, 55 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > index a7554265f95f..dd99ac3410e3 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > @@ -12,12 +12,59 @@
> > #include "common.h"
> > #include "of.h"
> >
> > +static int brcmf_of_get_country_codes(struct device *dev,
> > + struct brcmf_mp_device *settings)
> > +{
> > + struct device_node *np = dev->of_node;
> > + struct brcmfmac_pd_cc_entry *cce;
> > + struct brcmfmac_pd_cc *cc;
> > + int count;
> > + int i;
> > +
> > + count = of_property_count_strings(np, "brcm,ccode-map");
> > + if (count < 0) {
> > + /* The property is optional, so return success if it doesn't
> > + * exist. Otherwise propagate the error code.
> > + */
> > + return (count == -EINVAL) ? 0 : count;
> > + }
> > +
> > + cc = devm_kzalloc(dev, sizeof(*cc) + count * sizeof(*cce),
> > GFP_KERNEL);
> > + if (!cc)
> > + return -ENOMEM;
> > +
> > + cc->table_size = count;
> > +
> > + for (i = 0; i < count; i++) {
> > + const char *map;
> > +
> > + cce = >table[i];
> > +
> > + if (of_property_read_string_index(np, "brcm,ccode-map",
> > + i, ))
> > + continue;
> > +
> > + /* String format e.g. US-Q2-86 */
> > + if (sscanf(map, "%2c-%2c-%d", cce->iso3166, cce->cc,
> > +>rev) != 3)
> > + brcmf_err("failed to read country map %s\n", map);
> > + else
> > + brcmf_dbg(INFO, "%s-%s-%d", cce->iso3166, cce->cc,
> > + cce->rev);
>
> ... and here you are missing terminating '\n' in format string.
Oops! Will fix it with v3.
Shawn
[PATCH v2 1/2] dt-bindings: bcm4329-fmac: add optional brcm,ccode-map
Add optional brcm,ccode-map property to support translation from ISO3166 country code to brcmfmac firmware country code and revision. The country revision is needed because the RF parameters that provide regulatory compliance are tweaked per platform/customer. So depending on the RF path tight to the chip, certain country revision needs to be specified. As such they could be seen as device specific calibration data which is a good fit into device tree. Signed-off-by: Shawn Guo Reviewed-by: Arend van Spriel --- .../bindings/net/wireless/brcm,bcm4329-fmac.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index b5fcc73ce6be..c11f23b20c4c 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -68,6 +68,13 @@ properties: description: A GPIO line connected to the WL_RST line, if present this shall be flagged as active low. + brcm,ccode-map: +$ref: /schemas/types.yaml#/definitions/string-array +description: Multiple strings for translating ISO3166 country code to + brcmfmac firmware country code and revision. +items: + pattern: '^[A-Z][A-Z]-[A-Z][0-9A-Z]-[0-9]+$' + required: - compatible - reg @@ -97,5 +104,6 @@ examples: interrupts = <24 IRQ_TYPE_EDGE_FALLING>; interrupt-names = "host-wake"; reset-gpios = < 23 GPIO_ACTIVE_LOW>; +brcm,ccode-map = "JP-JP-78", "US-Q2-86"; }; }; -- 2.17.1
[PATCH v2 2/2] brcmfmac: support parse country code map from DT
With any regulatory domain requests coming from either user space or
802.11 IE (Information Element), the country is coded in ISO3166
standard. It needs to be translated to firmware country code and
revision with the mapping info in settings->country_codes table.
Support populate country_codes table by parsing the mapping from DT.
The BRCMF_BUSTYPE_SDIO bus_type check gets separated from general DT
validation, so that country code can be handled as general part rather
than SDIO bus specific one.
Signed-off-by: Shawn Guo
Reviewed-by: Arend van Spriel
---
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 57 ++-
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index a7554265f95f..dd99ac3410e3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -12,12 +12,59 @@
#include "common.h"
#include "of.h"
+static int brcmf_of_get_country_codes(struct device *dev,
+ struct brcmf_mp_device *settings)
+{
+ struct device_node *np = dev->of_node;
+ struct brcmfmac_pd_cc_entry *cce;
+ struct brcmfmac_pd_cc *cc;
+ int count;
+ int i;
+
+ count = of_property_count_strings(np, "brcm,ccode-map");
+ if (count < 0) {
+ /* The property is optional, so return success if it doesn't
+* exist. Otherwise propagate the error code.
+*/
+ return (count == -EINVAL) ? 0 : count;
+ }
+
+ cc = devm_kzalloc(dev, sizeof(*cc) + count * sizeof(*cce), GFP_KERNEL);
+ if (!cc)
+ return -ENOMEM;
+
+ cc->table_size = count;
+
+ for (i = 0; i < count; i++) {
+ const char *map;
+
+ cce = >table[i];
+
+ if (of_property_read_string_index(np, "brcm,ccode-map",
+ i, ))
+ continue;
+
+ /* String format e.g. US-Q2-86 */
+ if (sscanf(map, "%2c-%2c-%d", cce->iso3166, cce->cc,
+ >rev) != 3)
+ brcmf_err("failed to read country map %s\n", map);
+ else
+ brcmf_dbg(INFO, "%s-%s-%d", cce->iso3166, cce->cc,
+ cce->rev);
+ }
+
+ settings->country_codes = cc;
+
+ return 0;
+}
+
void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
struct brcmf_mp_device *settings)
{
struct brcmfmac_sdio_pd *sdio = >bus.sdio;
struct device_node *root, *np = dev->of_node;
int irq;
+ int err;
u32 irqf;
u32 val;
@@ -43,8 +90,14 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type
bus_type,
of_node_put(root);
}
- if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
- !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ return;
+
+ err = brcmf_of_get_country_codes(dev, settings);
+ if (err)
+ brcmf_err("failed to get OF country code map (err=%d)\n", err);
+
+ if (bus_type != BRCMF_BUSTYPE_SDIO)
return;
if (of_property_read_u32(np, "brcm,drive-strength", ) == 0)
--
2.17.1
[PATCH v2 0/2] brcmfmac: support parse country code map from DT
This is a couple of patches adding optional brcm,ccode-map bindings for brcmfmac driver to parse country code map from DT. Changes for v2: - Rebase bindings patch on top of yaml conversion patch [1]. - Improve commit log with Arend's explanation on why this data could be put in device tree. - Use pattern to define mapping string as suggested by Rob. - Use brcmf_err() instead of dev_warn() and print error code. - Use sscanf() to validate mapping string. - Use brcmf_dbg(INFO, ...) to print country code entry. - Separate BRCMF_BUSTYPE_SDIO bus_type check from general DT validation. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20210315105911.138553-1-linus.wall...@linaro.org/ Shawn Guo (2): dt-bindings: bcm4329-fmac: add optional brcm,ccode-map brcmfmac: support parse country code map from DT .../net/wireless/brcm,bcm4329-fmac.yaml | 8 +++ .../wireless/broadcom/brcm80211/brcmfmac/of.c | 57 ++- 2 files changed, 63 insertions(+), 2 deletions(-) -- 2.17.1
Re: [PATCH 2/2] brcmfmac: support parse country code map from DT
On Mon, Apr 12, 2021 at 10:22:47AM +0200, Arend van Spriel wrote:
> On 08-04-2021 13:30, Shawn Guo wrote:
> > With any regulatory domain requests coming from either user space or
> > 802.11 IE (Information Element), the country is coded in ISO3166
> > standard. It needs to be translated to firmware country code and
> > revision with the mapping info in settings->country_codes table.
> > Support populate country_codes table by parsing the mapping from DT.
>
> one more thing though...
>
> > Signed-off-by: Shawn Guo
> > ---
> > .../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++
> > 1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > index a7554265f95f..ea5c7f434c2c 100644
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
> > @@ -12,12 +12,61 @@
> > #include "common.h"
> > #include "of.h"
> > +static int brcmf_of_get_country_codes(struct device *dev,
> > + struct brcmf_mp_device *settings)
> > +{
>
> [...]
>
> > + /* String format e.g. US-Q2-86 */
> > + strncpy(cce->iso3166, map, 2);
> > + strncpy(cce->cc, map + 3, 2);
> > +
> > + ret = kstrtos32(map + 6, 10, >rev);
> > + if (ret < 0)
> > + dev_warn(dev, "failed to read rev of map %s: %d",
> > +cce->iso3166, ret);
>
> Do we need a stronger validation of the string format, eg. use sscanf or
> strstr. Would also be nice to have brcmf_dbg(INFO, ...) here to print the
> entry.
Sounds good to me for both comments.
Shawn
Re: [PATCH 2/2] brcmfmac: support parse country code map from DT
On Mon, Apr 12, 2021 at 10:09:38AM +0200, Arend van Spriel wrote: > On 08-04-2021 13:30, Shawn Guo wrote: > > With any regulatory domain requests coming from either user space or > > 802.11 IE (Information Element), the country is coded in ISO3166 > > standard. It needs to be translated to firmware country code and > > revision with the mapping info in settings->country_codes table. > > Support populate country_codes table by parsing the mapping from DT. > > comment below, but you may add... > > Reviewed-by: Arend van Spriel Thanks for reviewing, Arend. > > Signed-off-by: Shawn Guo > > --- > > .../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++ > > 1 file changed, 53 insertions(+) > > > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c > > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c > > index a7554265f95f..ea5c7f434c2c 100644 > > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c > > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c > > [...] > > > @@ -47,6 +96,10 @@ void brcmf_of_probe(struct device *dev, enum > > brcmf_bus_type bus_type, > > !of_device_is_compatible(np, "brcm,bcm4329-fmac")) > > return; > > + ret = brcmf_of_get_country_codes(dev, settings); > > + if (ret) > > + dev_warn(dev, "failed to get OF country code map\n"); > > First of all I prefer to use brcmf_err and add ret value to the print > message " (err=%d)\n". Okay. > Another thing is that this mapping is not only > applicable for SDIO devices so you may consider doing this for other bus > types as well which requires a bit more rework here. Right. I will take care of it, if we can convince Kalle that having this data in DT is not such a bad idea. Shawn
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Mon, Apr 12, 2021 at 02:54:46PM +0300, Kalle Valo wrote:
> Shawn Guo writes:
>
> > On Sun, Apr 11, 2021 at 10:57:54AM +0300, Kalle Valo wrote:
> >> Shawn Guo writes:
> >>
> >> > Add optional brcm,ccode-map property to support translation from ISO3166
> >> > country code to brcmfmac firmware country code and revision.
> >> >
> >> > Signed-off-by: Shawn Guo
> >> > ---
> >> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> >> > 1 file changed, 7 insertions(+)
> >> >
> >> > diff --git
> >> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> > index cffb2d6876e3..a65ac4384c04 100644
> >> > ---
> >> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> > +++
> >> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> > @@ -15,6 +15,12 @@ Optional properties:
> >> > When not specified the device will use in-band SDIO interrupts.
> >> > - interrupt-names : name of the out-of-band interrupt, which must be
> >> > set
> >> > to "host-wake".
> >> > + - brcm,ccode-map : multiple strings for translating ISO3166 country
> >> > code to
> >> > +brcmfmac firmware country code and revision. Each string must
> >> > be in
> >> > +format "AA-BB-num" where:
> >> > + AA is the ISO3166 country code which must be 2 characters.
> >> > + BB is the firmware country code which must be 2 characters.
> >> > + num is the revision number which must fit into signed integer.
> >> >
> >> > Example:
> >> >
> >> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> >> > interrupt-parent = <>;
> >> > interrupts = <10 8>; /* PH10 / EINT10 */
> >> > interrupt-names = "host-wake";
> >> > +brcm,ccode-map = "JP-JP-78", "US-Q2-86";
> >>
> >> The commit log does not answer "Why?". Why this needs to be in device
> >> tree and, for example, not hard coded in the driver?
> >
> > Thanks for the comment, Kalle. Actually, this is something I need some
> > input from driver maintainers. I can see this country code mapping
> > table is chipset specific, and can be hard coded in driver per chip id
> > and revision. But on the other hand, it makes some sense to have this
> > table in device tree, as the country code that need to be supported
> > could be a device specific configuration.
>
> Could be? Does such a use case exist at the moment or are just guessing
> future needs?
I hope that the patch [1] from Rafał (copied) is one use case. And
also, the device I'm working on only needs to support some of the
countries in the mapping table.
>
> From what I have learned so far I think this kind of data should be in
> the driver, but of course I might be missing something.
I agree with you that such data are chipset specific and should ideally
be in the driver. However, the brcmfmac driver implementation has been
taking the mapping table from platform_data [2][3], which is a logical
equivalent of DT data in case of booting with device tree.
Shawn
[1]
https://gitlab.dai-labor.de/nadim/powquty-coap/-/blob/563b2bd658822375dcfa8e87707304b94de9901c/kernel/mac80211/patches/863-brcmfmac-add-in-driver-tables-with-country-codes.patch
[2]
https://elixir.bootlin.com/linux/v5.12-rc7/source/include/linux/platform_data/brcmfmac.h#L154
[3]
https://elixir.bootlin.com/linux/v5.12-rc7/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c#L433
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Sun, Apr 11, 2021 at 10:57:54AM +0300, Kalle Valo wrote:
> Shawn Guo writes:
>
> > Add optional brcm,ccode-map property to support translation from ISO3166
> > country code to brcmfmac firmware country code and revision.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > index cffb2d6876e3..a65ac4384c04 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > @@ -15,6 +15,12 @@ Optional properties:
> > When not specified the device will use in-band SDIO interrupts.
> > - interrupt-names : name of the out-of-band interrupt, which must be set
> > to "host-wake".
> > + - brcm,ccode-map : multiple strings for translating ISO3166 country code
> > to
> > + brcmfmac firmware country code and revision. Each string must be in
> > + format "AA-BB-num" where:
> > + AA is the ISO3166 country code which must be 2 characters.
> > + BB is the firmware country code which must be 2 characters.
> > + num is the revision number which must fit into signed integer.
> >
> > Example:
> >
> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> > interrupt-parent = <>;
> > interrupts = <10 8>; /* PH10 / EINT10 */
> > interrupt-names = "host-wake";
> > + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
>
> The commit log does not answer "Why?". Why this needs to be in device
> tree and, for example, not hard coded in the driver?
Thanks for the comment, Kalle. Actually, this is something I need some
input from driver maintainers. I can see this country code mapping
table is chipset specific, and can be hard coded in driver per chip id
and revision. But on the other hand, it makes some sense to have this
table in device tree, as the country code that need to be supported
could be a device specific configuration.
Shawn
Re: [PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
On Fri, Apr 09, 2021 at 01:46:06PM -0500, Rob Herring wrote:
> On Thu, Apr 08, 2021 at 07:30:21PM +0800, Shawn Guo wrote:
> > Add optional brcm,ccode-map property to support translation from ISO3166
> > country code to brcmfmac firmware country code and revision.
> >
> > Signed-off-by: Shawn Guo
> > ---
> > .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
> > 1 file changed, 7 insertions(+)
>
> Can you convert this to schema first.
Yes. Will do, after driver maintainers agree with the direction.
>
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > index cffb2d6876e3..a65ac4384c04 100644
> > --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > @@ -15,6 +15,12 @@ Optional properties:
> > When not specified the device will use in-band SDIO interrupts.
> > - interrupt-names : name of the out-of-band interrupt, which must be set
> > to "host-wake".
> > + - brcm,ccode-map : multiple strings for translating ISO3166 country code
> > to
> > + brcmfmac firmware country code and revision. Each string must be in
> > + format "AA-BB-num" where:
> > + AA is the ISO3166 country code which must be 2 characters.
> > + BB is the firmware country code which must be 2 characters.
> > + num is the revision number which must fit into signed integer.
>
> Signed? So "AA-BB--num"?
Hmm, for some reason, kernel driver uses signed integer to hold the
revision. It's just a reflecting of that.
>
> You should be able to do something like:
>
> items:
> pattern: '^[A-Z][A-Z]-[A-Z][A-Z]-[0-9]+$'
Ah, yes, that's much better and distinct. Thanks for the suggestion.
Shawn
>
> >
> > Example:
> >
> > @@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
> > interrupt-parent = <>;
> > interrupts = <10 8>; /* PH10 / EINT10 */
> > interrupt-names = "host-wake";
> > + brcm,ccode-map = "JP-JP-78", "US-Q2-86";
> > };
> > };
> > --
> > 2.17.1
> >
[PATCH 1/2] dt-binding: bcm43xx-fmac: add optional brcm,ccode-map
Add optional brcm,ccode-map property to support translation from ISO3166
country code to brcmfmac firmware country code and revision.
Signed-off-by: Shawn Guo
---
.../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index cffb2d6876e3..a65ac4384c04 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -15,6 +15,12 @@ Optional properties:
When not specified the device will use in-band SDIO interrupts.
- interrupt-names : name of the out-of-band interrupt, which must be set
to "host-wake".
+ - brcm,ccode-map : multiple strings for translating ISO3166 country code to
+ brcmfmac firmware country code and revision. Each string must be in
+ format "AA-BB-num" where:
+ AA is the ISO3166 country code which must be 2 characters.
+ BB is the firmware country code which must be 2 characters.
+ num is the revision number which must fit into signed integer.
Example:
@@ -34,5 +40,6 @@ mmc3: mmc@1c12000 {
interrupt-parent = <>;
interrupts = <10 8>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
+ brcm,ccode-map = "JP-JP-78", "US-Q2-86";
};
};
--
2.17.1
[PATCH 2/2] brcmfmac: support parse country code map from DT
With any regulatory domain requests coming from either user space or
802.11 IE (Information Element), the country is coded in ISO3166
standard. It needs to be translated to firmware country code and
revision with the mapping info in settings->country_codes table.
Support populate country_codes table by parsing the mapping from DT.
Signed-off-by: Shawn Guo
---
.../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index a7554265f95f..ea5c7f434c2c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -12,12 +12,61 @@
#include "common.h"
#include "of.h"
+static int brcmf_of_get_country_codes(struct device *dev,
+ struct brcmf_mp_device *settings)
+{
+ struct device_node *np = dev->of_node;
+ struct brcmfmac_pd_cc_entry *cce;
+ struct brcmfmac_pd_cc *cc;
+ int count;
+ int i;
+
+ count = of_property_count_strings(np, "brcm,ccode-map");
+ if (count < 0) {
+ /* The property is optional, so return success if it doesn't
+* exist. Otherwise propagate the error code.
+*/
+ return (count == -EINVAL) ? 0 : count;
+ }
+
+ cc = devm_kzalloc(dev, sizeof(*cc) + count * sizeof(*cce), GFP_KERNEL);
+ if (!cc)
+ return -ENOMEM;
+
+ cc->table_size = count;
+
+ for (i = 0; i < count; i++) {
+ const char *map;
+ int ret;
+
+ cce = >table[i];
+
+ if (of_property_read_string_index(np, "brcm,ccode-map",
+ i, ))
+ continue;
+
+ /* String format e.g. US-Q2-86 */
+ strncpy(cce->iso3166, map, 2);
+ strncpy(cce->cc, map + 3, 2);
+
+ ret = kstrtos32(map + 6, 10, >rev);
+ if (ret < 0)
+ dev_warn(dev, "failed to read rev of map %s: %d",
+cce->iso3166, ret);
+ }
+
+ settings->country_codes = cc;
+
+ return 0;
+}
+
void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
struct brcmf_mp_device *settings)
{
struct brcmfmac_sdio_pd *sdio = >bus.sdio;
struct device_node *root, *np = dev->of_node;
int irq;
+ int ret;
u32 irqf;
u32 val;
@@ -47,6 +96,10 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type
bus_type,
!of_device_is_compatible(np, "brcm,bcm4329-fmac"))
return;
+ ret = brcmf_of_get_country_codes(dev, settings);
+ if (ret)
+ dev_warn(dev, "failed to get OF country code map\n");
+
if (of_property_read_u32(np, "brcm,drive-strength", ) == 0)
sdio->drive_strength = val;
--
2.17.1
[PATCH 0/2] brcmfmac: support parse country code map from DT
This is a couple of patches adding optional brcm,ccode-map bindings for brcmfmac driver to parse country code map from DT. Shawn Guo (2): dt-binding: bcm43xx-fmac: add optional brcm,ccode-map brcmfmac: support parse country code map from DT .../net/wireless/brcm,bcm43xx-fmac.txt| 7 +++ .../wireless/broadcom/brcm80211/brcmfmac/of.c | 53 +++ 2 files changed, 60 insertions(+) -- 2.17.1
Re: [PATCH v2 1/3] ARM: dts: imx6: pfla02: Fix USB vbus enable pinmuxing
On Mon, Mar 29, 2021 at 03:01:01PM +0200, Stefan Riedmueller wrote: > The pinmuxing for the enable pin of the usbh1 node is wrong. It needs to > be muxed as GPIO. While at it, move the pinctrl to the vbus regulator > since it is actually the regulator enable pin. > > Signed-off-by: Stefan Riedmueller Applied all, thanks.
Re: [PATCH v2] arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0
On Wed, Mar 24, 2021 at 02:28:41PM +0100, Oliver Stäbler wrote: > Fix address of the pad control register > (IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems > to be a typo but it leads to an exception when pinctrl is applied due to > wrong memory address access. > > Signed-off-by: Oliver Stäbler Applied, thanks.
Re: [PATCH 1/2] arm64: dts: ls1028a: move rtc alias to individual boards
On Tue, Mar 23, 2021 at 04:07:56PM +0100, Michael Walle wrote: > The aliases are board-specific and shouldn't be included in the common > SoC dtsi. Move them over to the boards. > > Signed-off-by: Michael Walle Applied both, thanks.
Re: [PATCH v2] arm64: dts: imx8mq-kontron-pitx-imx8m: pass phy reset delays
On Tue, Mar 23, 2021 at 03:00:21PM +0100, Heiko Thiery wrote:
> The TI DP83867 PHY datasheet says:
> T1: Post RESET stabilization time == 195us
> T3: Hardware configuration pins transition to output drivers == 64us
> T4: RESET pulse width == 1us
>
> So with a little overhead set 'reset-assert-us' to 10us (T4) and
> 'reset-deassert-us' to 280us (T1+T3).
>
> Without these reset delays the board will hang during startup when
> bootargs has ip=dhcp set.
>
> Fixes: 1dc7f3d79a1a ("arm64: dts: fsl: add support for Kontron pitx-imx8m
> board")
> Signed-off-by: Heiko Thiery
> ---
> v2:
> - add desciption what issue will be fixed
> - add Fixes tag
My branch is not a stable one, so I just squashed it into the original
commit.
Shawn
Re: [PATCH v6 1/3] dt-bindings: Add vendor prefix for reMarkable
On Mon, Mar 22, 2021 at 09:09:25AM -0400, Alistair Francis wrote: > reMarkable AS produces eInk tablets > > Signed-off-by: Alistair Francis Applied all, thanks.
Re: [PATCH] arm64: configs: enable FlexTimer alarm timer
On Sat, Mar 20, 2021 at 07:34:36PM +0100, Michael Walle wrote: > This driver is used on Layerscape SoCs to wake up the system from > standby. It works in conjunction with the RCPM driver. The latter is > only available as a builtin. > > Signed-off-by: Michael Walle Applied, thanks.
Re: [PATCH 1/1] firmware: imx: scu-pd: add missed ADC1 pd
On Fri, Mar 19, 2021 at 04:23:52PM -0500, Frank Li wrote: > ADC1 is not defined in pd driver on 8QM. > > Signed-off-by: Frank Li > Reviewed-by: Dong Aisheng Applied, thanks.
Re: [PATCH v2 2/2] arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support
On Fri, Mar 19, 2021 at 01:50:41PM -0700, Tim Harvey wrote:
> The Gateworks GW7901 is an ARM based single board computer (SBC)
> featuring:
> - i.MX8M Mini SoC
> - LPDDR4 DRAM
> - eMMC FLASH
> - SPI FRAM
> - Gateworks System Controller (GSC)
> - Atmel ATECC Crypto Authentication
> - USB 2.0
> - Microchip GbE Switch
> - Multiple multi-protocol RS232/RS485/RS422 Serial ports
> - onboard 802.11ac WiFi / BT
> - microSD socket
> - miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
> - Wide range DC power input
> - 802.3at PoE
>
> Signed-off-by: Tim Harvey
> ---
> v2:
> - fixed issues reported by check_dtbs:
>- add missing GSC #address-cells and #size-cells
> - use common node name for SPI FLASH and drop mb85rs4mt compatible
> - add missing pinctrl-names to PMIC
> - add rohm,reset-snvs-powered to PMIC
> - add 32.768 kHz clock to PMIC
>
> Signed-off-by: Tim Harvey
> ---
> arch/arm64/boot/dts/freescale/Makefile|1 +
> .../dts/freescale/imx8mm-venice-gw7901.dts| 1016 +
> 2 files changed, 1017 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile
> b/arch/arm64/boot/dts/freescale/Makefile
> index 6438db3822f8..2a93323a7d3e 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
> new file mode 100644
> index ..d6431b01babc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts
> @@ -0,0 +1,1016 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2020 Gateworks Corporation
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "Gateworks Venice GW7901 i.MX8MM board";
> + compatible = "gw,imx8mm-gw7901", "fsl,imx8mm";
> +
> + aliases {
> + ethernet0 =
> + ethernet1 =
> + ethernet2 =
> + ethernet3 =
> + ethernet4 =
> + usb0 =
> + usb1 =
> + };
> +
> + chosen {
> + stdout-path =
> + };
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0x0 0x4000 0 0x8000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + user-pb {
> + label = "user_pb";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + user-pb1x {
> + label = "user_pb1x";
> + linux,code = ;
> + interrupt-parent = <>;
> + interrupts = <0>;
> + };
> +
> + key-erased {
> + label = "key_erased";
> + linux,code = ;
> + interrupt-parent = <>;
> + interrupts = <1>;
> + };
> +
> + eeprom-wp {
> + label = "eeprom_wp";
> + linux,code = ;
> + interrupt-parent = <>;
> + interrupts = <2>;
> + };
> +
> + tamper {
> + label = "tamper";
> + linux,code = ;
> + interrupt-parent = <>;
> + interrupts = <5>;
> + };
> +
> + switch-hold {
> + label = "switch_hold";
> + linux,code = ;
> + interrupt-parent = <>;
> + interrupts = <7>;
> + };
> + };
> +
> + led-controller {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + label = "led01_red";
> + gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + label = "led01_grn";
> + gpios = <_gpio 1 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + led-2 {
> + function = LED_FUNCTION_STATUS;
> +
Re: [PATCH 1/2] arm64: dts: fsl-ls1028a-kontron-sl28: move MTD partitions
On Thu, Mar 18, 2021 at 06:18:55PM +0100, Michael Walle wrote: > Move the MTD partitions to the partitions subnode. This is the new way > to specify the partitions, see > Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml > > Signed-off-by: Michael Walle Applied, thanks.
Re: [PATCH] firmware: imx: scu-pd: Update comments for single global power domain
On Wed, Mar 17, 2021 at 10:31:17AM +0100, Ulf Hansson wrote: > Since the introduction of the PM domain support for the scu-pd, the genpd > framework has been continuously improved. More preciously, using a single > global power domain can quite easily be deployed for imx platforms. > > To avoid confusions, let's therefore make an update to the comments about > the missing pieces. > > Signed-off-by: Ulf Hansson Applied, thanks.
Re: [PATCH v2 0/7] remove different PHY fixups
On Wed, Mar 24, 2021 at 06:54:24AM +0100, Oleksij Rempel wrote: > Hi Shawn, > > ping, do this patches need some ACK from some one? As this will break existing DTBs, I need more ACKs from people to see the consensus that this is the right thing to do. Shawn > > Regards, > Oleksij > > On Tue, Mar 09, 2021 at 12:26:08PM +0100, Oleksij Rempel wrote: > > changes v2: > > - rebase against latest kernel > > - fix networking on RIoTBoard > > > > This patch series tries to remove most of the imx6 and imx7 board > > specific PHY configuration via fixup, as this breaks the PHYs when > > connected to switch chips or USB Ethernet MACs. > > > > Each patch has the possibility to break boards, but contains a > > recommendation to fix the problem in a more portable and future-proof > > way. > > > > regards, > > Oleksij > > > > Oleksij Rempel (7): > > ARM: imx6q: remove PHY fixup for KSZ9031 > > ARM: imx6q: remove TX clock delay of ar8031_phy_fixup() > > ARM: imx6q: remove hand crafted PHY power up in ar8035_phy_fixup() > > ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035 > > PHYs > > ARM: imx6q: remove Atheros AR8035 SmartEEE fixup > > ARM: imx6sx: remove Atheros AR8031 PHY fixup > > ARM: imx7d: remove Atheros AR8031 PHY fixup > > > > arch/arm/boot/dts/imx6dl-riotboard.dts | 2 + > > arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 2 +- > > arch/arm/mach-imx/mach-imx6q.c | 85 - > > arch/arm/mach-imx/mach-imx6sx.c | 26 > > arch/arm/mach-imx/mach-imx7d.c | 22 --- > > 5 files changed, 3 insertions(+), 134 deletions(-) > > > > -- > > 2.29.2 > > > > > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] arm64: dts: ls1028a: fix optee node
On Mon, Mar 22, 2021 at 06:12:06PM -0500, Li Yang wrote: > On Thu, Mar 18, 2021 at 3:36 AM Michael Walle wrote: > > > > Don't enable the optee node in the SoC include. It is an optional > > component and actually, if enabled, breaks boards which doesn't have it. > > Hi Shawn, > > Shall we make this a general rule? I see quite a few SoC dtsi files > are having the optee node enabled by default. Yeah, we should probably make it a general rule considering the issue reported here. I thought that optee driver is smart enough to stop probing if there is no optee os/firmware support found on given platform. Shawn
[tip: efi/urgent] efivars: respect EFI_UNSUPPORTED return from firmware
The following commit has been merged into the efi/urgent branch of tip: Commit-ID: 483028edacab374060d93955382b4865a9e07cba Gitweb: https://git.kernel.org/tip/483028edacab374060d93955382b4865a9e07cba Author:Shawn Guo AuthorDate:Wed, 17 Mar 2021 14:36:06 +08:00 Committer: Ard Biesheuvel CommitterDate: Wed, 17 Mar 2021 09:40:24 +01:00 efivars: respect EFI_UNSUPPORTED return from firmware As per UEFI spec 2.8B section 8.2, EFI_UNSUPPORTED may be returned by EFI variable runtime services if no variable storage is supported by firmware. In this case, there is no point for kernel to continue efivars initialization. That said, efivar_init() should fail by returning an error code, so that efivarfs will not be mounted on /sys/firmware/efi/efivars at all. Otherwise, user space like efibootmgr will be confused by the EFIVARFS_MAGIC seen there, while EFI variable calls cannot be made successfully. Cc: # v5.10+ Signed-off-by: Shawn Guo Acked-by: Ard Biesheuvel Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/vars.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c index 41c1d00..abdc8a6 100644 --- a/drivers/firmware/efi/vars.c +++ b/drivers/firmware/efi/vars.c @@ -485,6 +485,10 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *), } break; + case EFI_UNSUPPORTED: + err = -EOPNOTSUPP; + status = EFI_NOT_FOUND; + break; case EFI_NOT_FOUND: break; default:
Re: [PATCH V1] arm64: dts: imx8mp: fix FEC can't work when attached to generic phy driver
On Thu, Mar 04, 2021 at 07:40:13PM +0800, Joakim Zhang wrote:
> Some users report that FEC can't work on i.MX8MP EVK board, it brings
> inconvenience. The root cause should be FEC controller attached to
> generic phy driver, as Realtek phy driver is built as module in the
> defconfig file (CONFIG_REALTEK_PHY=m), so it is unavailable. If provide
> "reset-gpios" property, it will reset phy when probed, and no way to
> re-config phy since we use the generic phy dirver, which leads FEC can't
> work.
>
> There are two ways to let FEC work:
>
> 1. If you want to use generic phy dirver, please delete "reset-gpios"
> property, keep power-on strapping pins configurations.
>
> 2. If you want to use Realtek phy driver, please buildin driver
> (CONFIG_REALTEK_PHY=y), and had better add another two reset
> properties:
> reset-assert-us = <2>;
> reset-deassert-us = <15>;
> According to RTL8211 serials PHY datasheet, for a complete PHY reset,
> reset pin must be asserted low for at least 10ms for internal regulator.
> Wait for at least 72ms (for internal circuits settling time) before
> accessing the PHY register.
>
> This patch selects method 1, since users may waste time to find out FEC
> failure, in most cases, they just want to use networking to debug other
> modules.
>
> Fixs: commit 9e847693c6f34 ("arm64: dts: freescale: Add i.MX8MP EVK board
> support")
> Signed-off-by: Joakim Zhang
> ---
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> index 7db4273cc88b..4f5c2fb33eda 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> @@ -97,7 +97,6 @@
> compatible = "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> eee-broken-1000t;
> - reset-gpios = < 2 GPIO_ACTIVE_LOW>;
Hmm, DT is describing hardware. If board schematic says there is
a reset GPIO, we should have it.
Shawn
> };
> };
> };
> --
> 2.17.1
>
Re: [PATCH] arm64: dts: ls1028a: enable optee node
On Mon, Mar 15, 2021 at 12:28:29PM +0800, Shawn Guo wrote: > On Fri, Mar 05, 2021 at 02:03:51PM +0530, Sahil Malhotra wrote: > > From: Sahil Malhotra > > > > optee node was disabled in ls1028a.dtsi, enabling it by default. > > > > Signed-off-by: Sahil Malhotra > > Applied, thanks. Patch dropped, as it causes regression on kontron-kbox-a-230-ls [1]. Shawn [1] https://lore.kernel.org/linux-arm-kernel/38c31f5c-4400-eed7-d561-8f45e261a...@collabora.com/
Re: [PATCH v2] ARM: dts: imx6ull: fix ubi filesystem mount failed
On Wed, Mar 17, 2021 at 11:45:09PM +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> For NAND Ecc layout, there is a dependency from old kernel's nand driver
> setting and current. if old kernel use 4 bit ecc , we should use 4 bit
> in new kernel either. else will run into following error at filesystem
> mounting.
>
> So, enable fsl,use-minimum-ecc from device tree, to fix this mismatch
>
> [9.449265] ubi0: scanning is finished
> [9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read 22528 bytes
>
> Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC")
> Signed-off-by: dillon min
> Reviewed-by: Fabio Estevam
> Signed-off-by: Shawn Guo
Replaced with this version.
Shawn
Re: [PATCH v3] arm64: configs: Enable PCIe support for imx8mq boards
On Wed, Mar 17, 2021 at 01:11:37PM +0100, Heiko Thiery wrote: > Enable PCI_IMX6 to get PCI support for imx8mq boards like imx8mq-evk, > imx8mq-kontron-pitx-imx8m and imx8mq-zii-ultra. > > The driver only has build-in support and cannot be compiled as module. > > Signed-off-by: Heiko Thiery Applied, thanks.
Re: [PATCH] ARM: dts: imx6ull: fix ubi filesystem mount failed
On Tue, Mar 09, 2021 at 02:15:20PM +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> since Micron MT29F2G08ABAEAWP's ecc error management:
>
> |Description | Requirement
> |Minimum required ECC | 4-bit ECC per 528 bytes
> |Minimum ECC with internal ECC enabled | 4-bit ECC per 516 bytes (user data)
> +
> 8bytes (parity data)
>
> to avoid unnecessary overheads related to bigger ecc calculations.
> need choose to use fsl,use-minimum-ecc, else will run into ecc error.
>
> [9.449265] ubi0: scanning is finished
> [9.463968] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.486940] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.509906] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read only 22528 bytes, retry
> [9.532845] ubi0 error: ubi_io_read: error -74 (ECC error) while reading
> 22528 bytes from PEB 513:4096, read 22528 bytes
>
> Fixes: f9ecf10cb88c ("ARM: dts: imx6ull: add MYiR MYS-6ULX SBC")
> Signed-off-by: dillon min
Applied, thanks.
Re: [PATCH v2 0/2] enable flexspi support on imx8mp
On Tue, Mar 16, 2021 at 08:59:26AM +0100, Heiko Schocher wrote: > add compatible entry in nxp_fspi driver for imx8mp > > @Shawn: If this series is accepted, can you apply the DTS patches from > series v2? > http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643292.html > http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/643293.html Sure. I will pick them up after this series gets accepted. Shawn
Re: [PATCH v2] arm64: configs: Enable PCIe support for imx8mq boards
On Thu, Mar 11, 2021 at 08:27:47PM +0100, Heiko Thiery wrote: > Enable PCI_IMX6 to get PCI support for imx8mq boards like imx8mq-evk, > imx8mq-kontron-pitx-imx8m and imx8mq-zii-ultra. > > Signed-off-by: Heiko Thiery > --- > v2: > - slightly modified the commit message (Fabio Estevam) > > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 1f673b00c5f5..522bae6a8f21 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -225,6 +225,7 @@ CONFIG_PCI_HOST_THUNDER_PEM=y > CONFIG_PCI_HOST_THUNDER_ECAM=y > CONFIG_PCIE_ROCKCHIP_HOST=m > CONFIG_PCIE_BRCMSTB=m > +CONFIG_PCI_IMX6=y Do we really want it to be built-in? If so, it would be nice to have some comments about that in commit log. Shawn > CONFIG_PCI_LAYERSCAPE=y > CONFIG_PCIE_LAYERSCAPE_GEN4=y > CONFIG_PCI_HISI=y > -- > 2.30.0 >
Re: [PATCH v2 0/3] Librem 5 phone dts fixes
On Mon, Mar 15, 2021 at 09:35:28AM +0100, Martin Kepplinger wrote: > Two fixes for the Librem 5 phone descriptions and one resend of > https://lore.kernel.org/linux-arm-kernel/20200915141622.14736-1-feste...@gmail.com/ > that enables the hantro vpu staging driver. Feel free to ignore that one > if we want to wait for it to be out of staging. > > revision history > > v2: (thanks Shawn) > * fix commit hash in commit message > > v1: > * > https://lore.kernel.org/phone-devel/20210311120259.3310499-1-martin.kepplin...@puri.sm/T/ > > Fabio Estevam (1): > arm64: defconfig: Enable the Hantro decoder > > Guido Günther (1): > arm64: dts: imx8mq-librem5: Hog the correct gpio > > Sebastian Krzyszkowiak (1): > arm64: dts: imx8mq-librem5-r3: Mark buck3 as always on Applied all, thanks.
Re: [PATCH 2/3] arm64: dts: imx8mq-librem5-r3: Mark buck3 as always on
On Thu, Mar 11, 2021 at 01:02:58PM +0100, Martin Kepplinger wrote:
> From: Sebastian Krzyszkowiak
>
> Commit 66d3f246d79f ("arm64: dts: librem5: Don't mark buck3 as always on")
I cannot find this commit.
Shawn
> removed always-on marking from GPU regulator, which is great for power
> saving - however it introduces additional i2c0 traffic which can be deadly
> for devices from the Dogwood batch.
>
> To workaround the i2c0 shutdown issue on Dogwood, this commit marks
> buck3 as always-on again - but only for Dogwood (r3).
>
> Signed-off-by: Sebastian Krzyszkowiak
> Signed-off-by: Martin Kepplinger
> ---
> arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
> b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
> index 0d38327043f8..cd3c3edd48fa 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
> @@ -28,6 +28,10 @@ {
> ti,termination-current = <144000>; /* uA */
> };
>
> +_reg {
> + regulator-always-on;
> +};
> +
> {
> proximity-near-level = <25>;
> };
> --
> 2.30.1
>
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
On Mon, Mar 15, 2021 at 08:10:37AM +0100, Heiko Schocher wrote:
> Hello Shawn,
>
> On 15.03.21 07:47, Shawn Guo wrote:
> > On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
> >>
> >> This series enables support for the SPI NOR on the
> >> imx8mp based phyboard-pollux-rdk board.
> >>
> >> Patches new in v2:
> >> "spi: fspi: enable fspi driver for on imx8mp"
> >> which adds own compatible entry for imx8mp
> >>
> >> and seperate in own patch the documentation entry in
> >> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> >> controller"
> >> as checkpatch says:
> >>
> >> warning: DT binding docs and includes should be a separate patch. See:
> >> Documentation/devicetree/bindings/submitting-patches.rst
> >>
> >>
> >> Changes in v2:
> >> - work in comments from Marco
> >> add own compatible entry for imx8mp
> >> - work in comments from Marco
> >> - add own compatible entry "nxp,imx8mp-fspi"
> >> - reworked order of properties as Marco mentioned
> >> - work in comments from Marco and Teresa
> >> - rename node into "'som_flash: flash@0 { }"
> >> - compatible is now first entry
> >> - removed #size-cells and #address-cells
> >> as no child node. If bootloader adds them bootloader
> >> can add them too.
> >>
> >> Heiko Schocher (4):
> >> spi: fspi: enable fspi driver for on imx8mp
> >> dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> >> controller
> >> arm64: dts: imx8mp: add flexspi node
> >> arm64: imx8mp: imx8mp-phycore-som enable spi nor
> >
> > Two DTS patch look good. Ping me when driver and bindings changes are
> > accepted.
>
> Thanks!
>
> Hmm.. I have not splitted this series into 2 series... should I do
> this now?
No, you do not need to. I sent the message only because I didn't
receive patch #1 and #2, so I will not be aware of their status.
Shawn
Re: [PATCH 0/2] Resolve NXP flexspi bindings compatibility warnings
On Tue, Mar 09, 2021 at 04:44:23PM +0530, Kuldeep Singh wrote: > This patches series aim is to resolve NXP flexspi bindings compatibility > warnings which were observed after running 'make dtbs_check' with > https://lore.kernel.org/linux-devicetree/20210309103528.3538910-1-kuldeep.si...@nxp.com/ > patch applied. > > Below error was observed: > /opt/samba/nxf51654/spi/arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: > spi@30bb: clock-names:0: 'fspi_en' was expected > From schema: > /opt/samba/nxf51654/spi/Documentation/devicetree/bindings/spi/nxp,spi-nxp-fspi.yaml > /opt/samba/nxf51654/spi/arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: > spi@30bb: clock-names:1: 'fspi' was expected > From schema: > /opt/samba/nxf51654/spi/Documentation/devicetree/bindings/spi/nxp,spi-nxp-fspi.yaml > > Resolving above error may require reordering of flexspi clock-names entry. > > Kuldeep Singh (2): > arm64: dts: imx8mm: Reorder flexspi clock-names entry > arm64: dts: imx8mn: Reorder flexspi clock-names entry Applied both, thanks.
Re: [PATCH v2 0/4] enable flexspi support on imx8mp
On Tue, Mar 09, 2021 at 06:31:12AM +0100, Heiko Schocher wrote:
>
> This series enables support for the SPI NOR on the
> imx8mp based phyboard-pollux-rdk board.
>
> Patches new in v2:
> "spi: fspi: enable fspi driver for on imx8mp"
> which adds own compatible entry for imx8mp
>
> and seperate in own patch the documentation entry in
> patch "dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> controller"
> as checkpatch says:
>
> warning: DT binding docs and includes should be a separate patch. See:
> Documentation/devicetree/bindings/submitting-patches.rst
>
>
> Changes in v2:
> - work in comments from Marco
> add own compatible entry for imx8mp
> - work in comments from Marco
> - add own compatible entry "nxp,imx8mp-fspi"
> - reworked order of properties as Marco mentioned
> - work in comments from Marco and Teresa
> - rename node into "'som_flash: flash@0 { }"
> - compatible is now first entry
> - removed #size-cells and #address-cells
> as no child node. If bootloader adds them bootloader
> can add them too.
>
> Heiko Schocher (4):
> spi: fspi: enable fspi driver for on imx8mp
> dt-bindings: spi: add compatible entry for imx8mp in FlexSPI
> controller
> arm64: dts: imx8mp: add flexspi node
> arm64: imx8mp: imx8mp-phycore-som enable spi nor
Two DTS patch look good. Ping me when driver and bindings changes are
accepted.
Shawn
Re: [PATCHv2 0/4] Bx50v3 DT improvements
On Mon, Mar 08, 2021 at 04:18:25PM +0100, Sebastian Reichel wrote: > Bx50v3 DT improvements > > These are a bunch of small unrelated improvements for the GE Bx50v3 > device tree (and BA16 system on module, which is currently only used > by Bx50v3). > > Changes since PATCHv1 [1]: > * change patch prefix for BA16 patches > * remove extra newline from PATCH 1/4 > * keep 'status' at the end of FEC in PATCH 2/4 > > [1] > https://lore.kernel.org/lkml/20210223183346.138575-1-sebastian.reic...@collabora.com/ > > Thanks for reviewing/merging them, > > -- Sebastian > > Ian Ray (1): > ARM: dts: imx: bx50v3: Define GPIO line names > > Sebastian Reichel (3): > ARM: dts: imx6q-ba16: add USB OTG VBUS enable GPIO > ARM: dts: imx6q-ba16: improve PHY information > ARM: dts: imx: bx50v3: i2c GPIOs are open drain Applied all, thanks.
Re: [PATCH v2 1/1] arm64: dts: imx8mm-nitrogen-r2: add ecspi2 support
On Mon, Mar 08, 2021 at 01:55:18PM +0100, Adrien Grassein wrote: > Add the description for ecspi2 support. > > Signed-off-by: Adrien Grassein > Reviewed-by: Krzysztof Kozlowski > Reviewed-by: Fabio Estevam Applied, thanks.
Re: [PATCH v4] ARM: imx7d-remarkable2.dts: Initial device tree for reMarkable2
On Mon, Mar 08, 2021 at 03:22:27AM -0500, Alistair Francis wrote:
> The reMarkable2 (https://remarkable.com) is an e-ink tablet based on
> the imx7d SoC.
>
> This commit is based on the DTS provide by reMarkable but ported to the
> latest kernel (instead of 4.14). I have removed references to
> non-upstream devices and have changed the UART so that the console can
> be accessed without having to open up the device via the OTG pogo pins.
>
> Currently the kernel boots, but there is no support for the display.
>
> WiFi is untested (no dispaly or UART RX makes it hard to test), but
> should work with the current upstream driver. As it's untested it's not
> included in this commit.
>
> Signed-off-by: Alistair Francis
The patch looks good, but it needs some split-up.
> ---
> .../devicetree/bindings/arm/fsl.yaml | 1 +
This would be patch #2.
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
Patch #1.
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/imx7d-remarkable2.dts | 166 ++
Patch #3.
Shawn
> 4 files changed, 170 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx7d-remarkable2.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 297c87f45db8..d139440c86b6 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -617,6 +617,7 @@ properties:
>- kam,imx7d-flex-concentrator # Kamstrup OMNIA Flex
> Concentrator
>- kam,imx7d-flex-concentrator-mfg # Kamstrup OMNIA Flex
> Concentrator in manufacturing mode
>- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
> + - remarkable,imx7d-remarkable2 # i.MX7D ReMarkable 2 E-Ink
> Tablet
>- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
>- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
>- technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index f6064d84a424..a8e1e8d2ef20 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -932,6 +932,8 @@ patternProperties:
> description: Unisoc Communications, Inc.
>"^realtek,.*":
> description: Realtek Semiconductor Corp.
> + "^remarkable,.*":
> +description: reMarkable AS
>"^renesas,.*":
> description: Renesas Electronics Corporation
>"^rex,.*":
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e75e..dc8e378689af 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -660,6 +660,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-pico-hobbit.dtb \
> imx7d-pico-nymph.dtb \
> imx7d-pico-pi.dtb \
> + imx7d-remarkable2.dtb \
> imx7d-sbc-imx7.dtb \
> imx7d-sdb.dtb \
> imx7d-sdb-reva.dtb \
> diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
> b/arch/arm/boot/dts/imx7d-remarkable2.dts
> new file mode 100644
> index ..86d555bd33c2
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "imx7d.dtsi"
> +
> +/ {
> + model = "reMarkable 2.0";
> + compatible = "remarkable,imx7d-remarkable2", "fsl,imx7d";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + memory {
> + reg = <0x8000 0x4000>;
> + };
> +};
> +
> + {
> + assigned-clocks = < IMX7D_CLKO2_ROOT_SRC>,
> + < IMX7D_CLKO2_ROOT_DIV>;
> + assigned-clock-parents = < IMX7D_CKIL>;
> + assigned-clock-rates = <0>, <32768>;
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> +_apbh {
> + status = "disabled";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_pwrkey {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart1>;
> + assigned-clocks = < IMX7D_UART1_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart6>;
> + assigned-clocks = < IMX7D_UART6_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + srp-disable;
> + hnp-disable;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> + pinctrl-0 = <_usdhc3>;
> + pinctrl-1 = <_usdhc3_100mhz>;
> + pinctrl-2 = <_usdhc3_200mhz>;
> + pinctrl-3 = <_usdhc3>;
> +
Re: [PATCH] ARM: dts: ls1021a: mark crypto engine dma coherent
On Sun, Mar 07, 2021 at 10:56:29PM +0200, Horia Geantă wrote: > Crypto engine (CAAM) on LS1021A platform is configured HW-coherent, > mark accordingly the DT node. > > Signed-off-by: Horia Geantă Applied, thanks.
Re: [PATCH 0/3] arm64: dts: ls: mark crypto engine dma coherent
On Sun, Mar 07, 2021 at 10:47:34PM +0200, Horia Geantă wrote: > This patch set adds "dma-coherent" property to the crypto node > for NXP Layerscape platforms where the IP (CAAM) is configured > HW-coherent. > > Horia Geantă (3): > arm64: dts: ls1046a: mark crypto engine dma coherent > arm64: dts: ls1043a: mark crypto engine dma coherent > arm64: dts: ls1012a: mark crypto engine dma coherent Applied all, thanks.
Re: [PATCH] arm64: dts: ls1028a: enable optee node
On Fri, Mar 05, 2021 at 02:03:51PM +0530, Sahil Malhotra wrote: > From: Sahil Malhotra > > optee node was disabled in ls1028a.dtsi, enabling it by default. > > Signed-off-by: Sahil Malhotra Applied, thanks.
Re: [PATCH v4 00/10] Add peripheral support for imx8mm-nitrogen-r2 board
On Mon, Mar 08, 2021 at 12:54:05PM +0100, Adrien Grassein wrote: > Le lun. 8 mars 2021 à 01:46, Shawn Guo a écrit : > > > > On Tue, Feb 23, 2021 at 08:16:43PM +0100, Adrien Grassein wrote: > > > Adrien Grassein (10): > > > arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip > > > arm64: dts: imx8mm-nitrogen-r2: rework USDHC1 > > > arm64: dts: imx8mm-nitrogen-r2: add USB support > > > arm64: dts: imx8mm-nitrogen-r2: add espi2 support > > > arm64: dts: imx8mm-nitrogen-r2: add UARTs > > > arm64: dts: imx8mm-nitrogen-r2: rework UART 2 > > > arm64: dts: imx8mm-nitrogen-r2: add PWMs > > > arm64: dts: imx8mm-nitrogen-r2: add FlexSPI > > > arm64: dts: imx8mm-nitrogen-r2: add audio > > > arm64: defconfig: Enable wm8960 audio driver. > > > > Applied all, thanks. > > Thanks, > > But I think you missed one (arm64: dts: imx8mm-nitrogen-r2: add espi2 > support) that I don't see on your tree. Hmm, looks like it did not get posted. https://lore.kernel.org/linux-arm-kernel/20210223191652.436397-1-adrien.grass...@gmail.com/ Shawn
Re: [PATCH V2] arm64: dts: imx8mp: add wdog2/3 nodes
On Sun, Mar 07, 2021 at 06:30:03PM +0800, peng@oss.nxp.com wrote: > From: Peng Fan > > There is wdog[2,3] in i.MX8MP, so add them. > > Signed-off-by: Peng Fan Applied, thanks.
Re: [PATCH] ARM: dts: colibri-imx6ull: Change drive strength for usdhc2
On Thu, Mar 04, 2021 at 10:31:39AM +0100, Philippe Schenker wrote: > The current setting reflects about 86 Ohms of source-impedance > on the SDIO signals where the WiFi board is hooked up. PCB traces are > routed with 50 Ohms impedance and there are no serial resistors on > those traces. > > This commit changes the source-impedance to 52 Ohms to better match our > hardware design. > > The impedances given in this commit message refer to 3.3V operation. > > Signed-off-by: Philippe Schenker Applied, thanks.
Re: [PATCH v4 0/2] add Kontron pITX-imx8m board
On Wed, Mar 03, 2021 at 10:10:01PM +0100, Heiko Thiery wrote: > This patch series adds support for the Kontron pITX-imx8m board: > > https://www.kontron.com/products/boards-and-standard-form-factors/single-board-computer/pitx-imx8m.html > > Heiko Thiery (2): > dt-bindings: arm: fsl: add Kontron pITX-imx8m board > arm64: dts: fsl: add support for Kontron pitx-imx8m board Applied both, thanks.
Re: [PATCH v4 0/5] arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini
On Fri, Feb 26, 2021 at 12:53:59AM +0530, Jagan Teki wrote: > Jagan Teki (5): > dt-bindings: arm: fsl: Add Engicam i.Core MX8M Mini C.TOUCH 2.0 > arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini SoM > arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0 > dt-bindings: arm: fsl: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit > arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit Applied all, thanks.
Re: [PATCH V3 0/5] imx esdhc dt/driver update
On Wed, Mar 03, 2021 at 03:00:57AM +, Peng Fan (OSS) wrote: > Hi Shawn, > > > Subject: Re: [PATCH V3 0/5] imx esdhc dt/driver update > > > > On Thu, 25 Feb 2021 at 04:22, wrote: > > > > > > From: Peng Fan > > > > > > V3: > > > Patch 1, drop unneeded pinctrl-0/1/2 > > > Patch 2 is new to avoid break dt bindings check > > > V2: > > > patch 1, 2, 3 is new > > > patch 4 is not changed > > > > > > > > > Peng Fan (5): > > > dt-bindings: mmc: fsl-imx-esdhc: add pinctrl bindings > > > dt-bindings: clock: imx8qxp-lpcg: correct the example clock-names > > > arm64: dts: imx8qxp: correct usdhc clock-names sequence > > > dt-bindings: mmc: fsl-imx-esdhc: add clock bindings > > > mmc: sdhci-esdhc-imx: validate pinctrl before use it > > > > > > .../bindings/clock/imx8qxp-lpcg.yaml | 6 +++--- > > > .../bindings/mmc/fsl-imx-esdhc.yaml | 20 > > +++ > > > arch/arm64/boot/dts/freescale/imx8qxp.dtsi| 18 - > > > drivers/mmc/host/sdhci-esdhc-imx.c| 2 +- > > > 4 files changed, 33 insertions(+), 13 deletions(-) > > > > > > -- > > > 2.30.0 > > > > > > > Applied patch 1, 4 and 5, thanks! > > > Would you pick patch 2,3? Done.
Re: [PATCH v4 00/10] Add peripheral support for imx8mm-nitrogen-r2 board
On Tue, Feb 23, 2021 at 08:16:43PM +0100, Adrien Grassein wrote: > Adrien Grassein (10): > arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip > arm64: dts: imx8mm-nitrogen-r2: rework USDHC1 > arm64: dts: imx8mm-nitrogen-r2: add USB support > arm64: dts: imx8mm-nitrogen-r2: add espi2 support > arm64: dts: imx8mm-nitrogen-r2: add UARTs > arm64: dts: imx8mm-nitrogen-r2: rework UART 2 > arm64: dts: imx8mm-nitrogen-r2: add PWMs > arm64: dts: imx8mm-nitrogen-r2: add FlexSPI > arm64: dts: imx8mm-nitrogen-r2: add audio > arm64: defconfig: Enable wm8960 audio driver. Applied all, thanks.
Re: [PATCHv1 2/4] ARM: dts: imx: ba16: improve PHY information
On Tue, Feb 23, 2021 at 07:33:44PM +0100, Sebastian Reichel wrote:
> Add PHY voltage supply information fixing the following kernel message:
>
> 2188000.ethernet supply phy not found, using dummy regulator
>
> Also add PHY clock information to avoid depending on the bootloader
> programming correct values.
>
> The bootloader also sets some reserved registers in the PHY as
> advised by Qualcomm, which is not supported by the bindings/kernel
> driver, so the reset GPIO has not been added intentionally.
>
> Signed-off-by: Sebastian Reichel
> ---
> arch/arm/boot/dts/imx6q-ba16.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
> b/arch/arm/boot/dts/imx6q-ba16.dtsi
> index 4793ef5171aa..a684d999e605 100644
> --- a/arch/arm/boot/dts/imx6q-ba16.dtsi
> +++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
> @@ -177,6 +177,18 @@ {
> pinctrl-0 = <_enet>;
> phy-mode = "rgmii-id";
> status = "okay";
> + phy-supply = <_3p3v>;
> + phy-handle = <>;
Please keep 'status' at end.
Shawn
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy0: ethernet-phy@4 {
> + reg = <4>;
> + qca,clk-out-frequency = <12500>;
> + };
> + };
> };
>
> {
> --
> 2.30.0
>
Re: [PATCHv1 1/4] ARM: dts: imx: ba16: add USB OTG VBUS enable GPIO
On Tue, Feb 23, 2021 at 07:33:43PM +0100, Sebastian Reichel wrote:
> Add VBUS regulator GPIO information, so that USB OTG port can
> also be used in host mode.
>
> Signed-off-by: Sebastian Reichel
'ARM: dts: imx6q-ba16: ' this style for prefix maybe?
> ---
> arch/arm/boot/dts/imx6q-ba16.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
> b/arch/arm/boot/dts/imx6q-ba16.dtsi
> index e4578ed3371e..4793ef5171aa 100644
> --- a/arch/arm/boot/dts/imx6q-ba16.dtsi
> +++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
> @@ -124,6 +124,10 @@ reg_usb_otg_vbus: regulator-usbotgvbus {
> regulator-name = "usb_otg_vbus";
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> +
This is newline is not necessary.
Shawn
> + pinctrl-0 = <_usbotg_vbus>;
> + gpio = < 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> };
> };
>
> @@ -575,6 +579,12 @@ MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
> >;
> };
>
> + pinctrl_usbotg_vbus: usbotgvbusgrp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x000b0
> + >;
> + };
> +
> pinctrl_usdhc2: usdhc2grp {
> fsl,pins = <
> MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> --
> 2.30.0
>
Re: [PATCH v1] arm64: dts: imx8m: add pmu node
On Tue, Feb 23, 2021 at 11:14:45AM +0800, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Adding pmu node supports to use perf tool to monitor the CPU performance
> of the inmate cell when enabling Jailhouse and running dual Linux OS.
>
> Signed-off-by: Alice Guo
> ---
> arch/arm64/boot/dts/freescale/imx8mm-evk-inmate.dts | 7 +++
Upstream doesn't have this file.
Shawn
> arch/arm64/boot/dts/freescale/imx8mn-evk-inmate.dts | 8
> arch/arm64/boot/dts/freescale/imx8mp-evk-inmate.dts | 8
> arch/arm64/boot/dts/freescale/imx8mq-evk-inmate.dts | 7 +++
> 4 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk-inmate.dts
> b/arch/arm64/boot/dts/freescale/imx8mm-evk-inmate.dts
> index fe9d96131045..6afccc2c140e 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk-inmate.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk-inmate.dts
> @@ -48,6 +48,13 @@
> };
> };
>
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupts = + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-affinity = <_2>, <_3>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk-inmate.dts
> b/arch/arm64/boot/dts/freescale/imx8mn-evk-inmate.dts
> index 584c1fa19f56..f2434ad369dc 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn-evk-inmate.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-evk-inmate.dts
> @@ -48,6 +48,14 @@
> };
> };
>
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupt-parent = <>;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-affinity = <_2>, <_3>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-inmate.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-evk-inmate.dts
> index 277ef70f2903..be538f510340 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-inmate.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-inmate.dts
> @@ -48,6 +48,14 @@
> };
> };
>
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupt-parent = <>;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-affinity = <_2>, <_3>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk-inmate.dts
> b/arch/arm64/boot/dts/freescale/imx8mq-evk-inmate.dts
> index b1db63cdb98c..57e0ab2bf4d3 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-evk-inmate.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk-inmate.dts
> @@ -48,6 +48,13 @@
> };
> };
>
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = ;
> + interrupt-parent = <>;
> + interrupt-affinity = <_2>, <_3>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> --
> 2.17.1
>
Re: [PATCH v1 0/6] arm64: dts: librem5-devkit: Improve audio support
On Sun, Feb 21, 2021 at 12:07:05PM +0100, Guido Günther wrote: > So far only headphone output worked. Thesse patches add support for the > built in speaker and mic, allow a headset microphone to work and wire up jack > detection so audio output can switch to headphones automatically. They also > adjust the card name to match the board not the codec, similar what's done for > the Librem 5. > > Patches are against next-20210210 but also apply against Shawn's imx-dt64-5.12 > > Guido Günther (6): > arm64: dts: librem5-devkit: Use a less generic codec name > arm64: dts: librem5-devkit: Add speaker amplifier > arm64: dts: librem5-devkit: "Drop Line In Jack" > arm64: defconfig: Enable asoc simple mux > arm64: dts: librem5-devkit: Add mux for built-in vs headset mic > arm64: dts: librem5-devkit: Move headphone detection to sound card Applied all, thanks.
Re: [PATCH v3 4/5] arm64: dts: librem5: protect some partitions of the nor-flash
On Fri, Feb 19, 2021 at 11:04:38AM +0100, Martin Kepplinger wrote:
> From: Angus Ainslie
>
> These sections should be read only as they contain important data.
>
> Signed-off-by: Angus Ainslie
> Signed-off-by: Martin Kepplinger
> ---
> .../boot/dts/freescale/imx8mq-librem5.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index c2bbbdeb93e3..d39ae27c8e42 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -258,6 +258,23 @@
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <100>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "protected0";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> + partition@3 {
> + label = "protected1";
> + reg = <0x3 0x1>;
> + read-only;
> + };
Please have a newline between nodes.
I fixed it up when applying.
Shawn
> + partition@4 {
> + label = "rw";
> + reg = <0x4 0x1C>;
> + };
> };
> };
>
> --
> 2.20.1
>
Re: [PATCH v3 0/5] arm64: dts: librem5 phone and devkit dts and config updates
On Fri, Feb 19, 2021 at 11:04:34AM +0100, Martin Kepplinger wrote: > Angus Ainslie (1): > arm64: dts: librem5: protect some partitions of the nor-flash > > Guido Günther (3): > arm64: dts: imx8mq-librem5-devkit: Drop buck3 startup-ramp-delay > arm64: dts: librem5: Drop assigned-clocks from SAI2 > arm64: defconfig: Enable devfreq support for i.MX8MQ > > Martin Kepplinger (1): > arm64: dts: imx8mq-librem5-r2: set nearlevel to 120 Applied all, thanks.
Re: [PATCH v2] clk: imx8mp: Remove the none exist pcie clocks
Copy Abel who is stepping up to maintain i.MX clock drivers.
Shawn
On Thu, Feb 18, 2021 at 04:33:46PM +0800, Richard Zhu wrote:
> In the i.MX8MP PCIe design, the PCIe PHY REF clock comes from external
> OSC or internal system PLL. It is configured in the IOMUX_GPR14 register
> directly, and can't be contolled by CCM at all.
> Remove the PCIE PHY clock from clock driver to clean up codes.
> There is only one PCIe in i.MX8MP, remove the none exist second PCIe
> related clocks.
> Remove the none exsits clocks IDs together.
>
> Signed-off-by: Richard Zhu
> Reviewed-by: Jason Liu
> ---
> drivers/clk/imx/clk-imx8mp.c | 15 ---
> include/dt-bindings/clock/imx8mp-clock.h | 3 ---
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> index 2f4e1d674e1c..afbeb6bf1909 100644
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -152,10 +152,6 @@ static const char * const imx8mp_can2_sels[] =
> {"osc_24m", "sys_pll2_200m", "sys
> "sys_pll1_160m",
> "sys_pll1_800m", "sys_pll3_out",
> "sys_pll2_250m",
> "audio_pll2_out", };
>
> -static const char * const imx8mp_pcie_phy_sels[] = {"osc_24m",
> "sys_pll2_100m", "sys_pll2_500m",
> - "clk_ext1", "clk_ext2",
> "clk_ext3",
> - "clk_ext4",
> "sys_pll1_400m", };
> -
> static const char * const imx8mp_pcie_aux_sels[] = {"osc_24m",
> "sys_pll2_200m", "sys_pll2_50m",
> "sys_pll3_out",
> "sys_pll2_100m", "sys_pll1_80m",
> "sys_pll1_160m",
> "sys_pll1_200m", };
> @@ -380,14 +376,6 @@ static const char * const imx8mp_memrepair_sels[] =
> {"osc_24m", "sys_pll2_100m",
> "sys_pll1_800m",
> "sys_pll2_1000m", "sys_pll3_out",
> "clk_ext3",
> "audio_pll2_out", };
>
> -static const char * const imx8mp_pcie2_ctrl_sels[] = {"osc_24m",
> "sys_pll2_250m", "sys_pll2_200m",
> - "sys_pll1_266m",
> "sys_pll1_800m", "sys_pll2_500m",
> - "sys_pll2_333m",
> "sys_pll3_out", };
> -
> -static const char * const imx8mp_pcie2_phy_sels[] = {"osc_24m",
> "sys_pll2_100m", "sys_pll2_500m",
> - "clk_ext1", "clk_ext2",
> "clk_ext3",
> - "clk_ext4",
> "sys_pll1_400m", };
> -
> static const char * const imx8mp_media_mipi_test_byte_sels[] = {"osc_24m",
> "sys_pll2_200m", "sys_pll2_50m",
> "sys_pll3_out",
> "sys_pll2_100m",
> "sys_pll1_80m",
> "sys_pll1_160m",
> @@ -585,7 +573,6 @@ static int imx8mp_clocks_probe(struct platform_device
> *pdev)
> hws[IMX8MP_CLK_VPU_G2] = imx8m_clk_hw_composite("vpu_g2",
> imx8mp_vpu_g2_sels, ccm_base + 0xa180);
> hws[IMX8MP_CLK_CAN1] = imx8m_clk_hw_composite("can1", imx8mp_can1_sels,
> ccm_base + 0xa200);
> hws[IMX8MP_CLK_CAN2] = imx8m_clk_hw_composite("can2", imx8mp_can2_sels,
> ccm_base + 0xa280);
> - hws[IMX8MP_CLK_PCIE_PHY] = imx8m_clk_hw_composite("pcie_phy",
> imx8mp_pcie_phy_sels, ccm_base + 0xa380);
> hws[IMX8MP_CLK_PCIE_AUX] = imx8m_clk_hw_composite("pcie_aux",
> imx8mp_pcie_aux_sels, ccm_base + 0xa400);
> hws[IMX8MP_CLK_I2C5] = imx8m_clk_hw_composite("i2c5", imx8mp_i2c5_sels,
> ccm_base + 0xa480);
> hws[IMX8MP_CLK_I2C6] = imx8m_clk_hw_composite("i2c6", imx8mp_i2c6_sels,
> ccm_base + 0xa500);
> @@ -643,8 +630,6 @@ static int imx8mp_clocks_probe(struct platform_device
> *pdev)
> hws[IMX8MP_CLK_MEDIA_CAM2_PIX] =
> imx8m_clk_hw_composite("media_cam2_pix", imx8mp_media_cam2_pix_sels, ccm_base
> + 0xbe80);
> hws[IMX8MP_CLK_MEDIA_LDB] = imx8m_clk_hw_composite("media_ldb",
> imx8mp_media_ldb_sels, ccm_base + 0xbf00);
> hws[IMX8MP_CLK_MEMREPAIR] =
> imx8m_clk_hw_composite_critical("mem_repair", imx8mp_memrepair_sels, ccm_base
> + 0xbf80);
> - hws[IMX8MP_CLK_PCIE2_CTRL] = imx8m_clk_hw_composite("pcie2_ctrl",
> imx8mp_pcie2_ctrl_sels, ccm_base + 0xc000);
> - hws[IMX8MP_CLK_PCIE2_PHY] = imx8m_clk_hw_composite("pcie2_phy",
> imx8mp_pcie2_phy_sels, ccm_base + 0xc080);
> hws[IMX8MP_CLK_MEDIA_MIPI_TEST_BYTE] =
> imx8m_clk_hw_composite("media_mipi_test_byte",
> imx8mp_media_mipi_test_byte_sels, ccm_base + 0xc100);
> hws[IMX8MP_CLK_ECSPI3] = imx8m_clk_hw_composite("ecspi3",
> imx8mp_ecspi3_sels, ccm_base + 0xc180);
> hws[IMX8MP_CLK_PDM] = imx8m_clk_hw_composite("pdm", imx8mp_pdm_sels,
> ccm_base + 0xc200);
> diff --git
Re: [PATCH] clk: imx8mq: Correct the pcie aux sels
+ Abel
On Thu, Feb 18, 2021 at 03:29:34PM +0800, Richard Zhu wrote:
> The sys2_pll_50m should be one of the clock sels of PCIE_AUX clock,
> Change the sys2_pll_500m to sys2_pll_50m.
>
> Signed-off-by: Richard Zhu
> ---
> drivers/clk/imx/clk-imx8mq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> index 4dd4ae9d022b..93480d8858be 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -118,7 +118,7 @@ static const char * const imx8mq_pcie1_ctrl_sels[] =
> {"osc_25m", "sys2_pll_250m"
> static const char * const imx8mq_pcie1_phy_sels[] = {"osc_25m",
> "sys2_pll_100m", "sys2_pll_500m", "clk_ext1", "clk_ext2",
> "clk_ext3", "clk_ext4", };
>
> -static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m",
> "sys2_pll_200m", "sys2_pll_500m", "sys3_pll_out",
> +static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m",
> "sys2_pll_200m", "sys2_pll_50m", "sys3_pll_out",
> "sys2_pll_100m", "sys1_pll_80m",
> "sys1_pll_160m", "sys1_pll_200m", };
>
> static const char * const imx8mq_dc_pixel_sels[] = {"osc_25m",
> "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m",
> "sys2_pll_1000m", "sys3_pll_out", "clk_ext4", };
> --
> 2.17.1
>
Re: [PATCH] arm64: dts: imx8mn-beacon: Enable SDR104 on WiFi SDIO interface
On Sun, Feb 14, 2021 at 02:17:42PM -0600, Adam Ford wrote: > Enable 100Mhz and 200MHz pinmux and corrsesponding voltage supplies > to enable SDR104 on usdhc1 connecting the WiFi chip. > > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH v9 1/3] ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
On Sun, Feb 14, 2021 at 02:13:48PM +0100, Oliver Graute wrote:
> This patch adds support for the i.MX6UL variant of the Variscite DART-6UL
> SoM Carrier-Board
>
> Signed-off-by: Oliver Graute
> Cc: Shawn Guo
> Cc: Neil Armstrong
> Cc: Marco Felsch
> Cc: Parthiban Nallathambi
> ---
> .../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 314
> +
Name imx6ul-var-dart-common.dtsi should be okay, as the file includes
imx6ul.dtsi?
> 1 file changed, 314 insertions(+)
>
> Changelog:
>
> v9:
> - added 3V and 5V regulator
> - move phy reset to subnode
> - added pwm-cells
> - fixed pad pin conflict
>
> v8:
> - remove can node
> - remove flexscan pinctrl
> - moved lcd and i2c pinctrl
> - sorted regulators
> - add dedicated pinctrl for dvfs regulator
>
> v7:
> - removed cpu0 node
> - fixed phy problem
>
> v6:
> - renamed touch regulator
> - renamed rmii clock
> - moved some muxing to baseboard
> - added pinctrl for gpio key
> - added bus-width to usdhc1
> - fixed missing subnode on partitions
>
> create mode 100644 arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
>
> diff --git a/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> new file mode 100644
> index ..b95fdc5
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> @@ -0,0 +1,314 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/dts-v1/;
> +
> +#include "imx6ul.dtsi"
Have a newline here.
> +/ {
> + chosen {
> + stdout-path =
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x2000>;
> + };
> +
> + clk_rmii_ref: clock-rmii-ref {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2500>;
> + clock-output-names = "rmii-ref";
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + reg_gpio_dvfs: regulator-gpio {
> + compatible = "regulator-gpio";
> + gpios = < 13 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_dvfs_reg>;
> + regulator-min-microvolt = <130>;
> + regulator-max-microvolt = <140>;
> + regulator-name = "gpio_dvfs";
> + regulator-type = "voltage";
> + enable-active-high;
Move this right after 'gpios'.
> + states = <130 0x1 140 0x0>;
> + };
> +
> + reg_sd1_vmmc: regulator-sd1-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_touch_3v3: regulator-touch-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "touch_3v3_supply";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
Unneeded newline.
> +};
> +
> + {
> + vref-supply = <_touch_3v3>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_enet1>;
> + phy-mode = "rmii";
> + phy-handle = <>;
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + micrel,rmii-reference-clock-select-25-mhz;
> + clocks = <_rmii_ref>;
> + clock-names = "rmii-ref";
> + reset-names = "phy";
> + reset-gpios=< 10 1>;
Use define for polarity.
Shawn
> +
Re: [PATCH] arm64: dts: ls1028a: add interrupt to Root Complex Event Collector
On Tue, Feb 09, 2021 at 01:52:59AM +0100, Michael Walle wrote: > The legacy interrupt INT_A is hardwired to the event collector. RCEC is > bascially supported starting with v5.11. Having a correct interrupt, will > make RCEC at least probe correctly. > > There are still issues with how RCEC is implemented in the RCiEP on the > LS1028A. RCEC will report an error, but it cannot find the correct > subdevice. > > Signed-off-by: Michael Walle Applied, thanks.
Re: [PATCH] arm64: dts: ls1028a: add interrupt to Root Complex Event Collector
On Tue, Feb 09, 2021 at 01:52:59AM +0100, Michael Walle wrote:
> The legacy interrupt INT_A is hardwired to the event collector. RCEC is
> bascially supported starting with v5.11. Having a correct interrupt, will
> make RCEC at least probe correctly.
>
> There are still issues with how RCEC is implemented in the RCiEP on the
> LS1028A. RCEC will report an error, but it cannot find the correct
> subdevice.
>
> Signed-off-by: Michael Walle
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 262fbad8f0ec..c1f2f402ad53 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -1114,6 +1114,12 @@
> full-duplex;
> };
> };
> +
> + rcec@1f,0 {
Just curious how unit-address comes to '1f,0'?
Shawn
> + reg = <0x00f800 0 0 0 0>;
> + /* IEP INT_A */
> + interrupts = ;
> + };
> };
>
> rcpm: power-controller@1e34040 {
> --
> 2.20.1
>
Re: [PATCH v5 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
On Mon, Feb 08, 2021 at 04:51:45PM +0300, Serge Semin wrote: > In accordance with the DWC USB3 bindings the corresponding node > name is suppose to comply with the Generic USB HCD DT schema, which > requires the USB nodes to have the name acceptable by the regexp: > "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly > named. > > Signed-off-by: Serge Semin > Acked-by: Krzysztof Kozlowski > Cc: Shawn Guo Applied, thanks.
Re: [PATCH] arch: arm: mach-imx: Fix a spelling in the file pm-imx5.c
On Fri, Feb 05, 2021 at 02:08:31PM +0530, Bhaskar Chowdhury wrote: > > s/confgiured/configured/ > > > Signed-off-by: Bhaskar Chowdhury Applied, thanks.
Re: [PATCH v3 3/3] ARM: imx_v6_v7_defconfig: Regenerate
On Wed, Feb 03, 2021 at 07:03:16PM -0800, Alistair Francis wrote: > Run make imx_v6_v7_defconfig; make savedefconfig to regenerate the > defconfig. > > Signed-off-by: Alistair Francis We can leave it to future updates on the defconfig. Shawn
Re: [PATCH v3 2/3] ARM: dts: imx7d: remarkable2: Enable the power button
On Wed, Feb 03, 2021 at 07:03:15PM -0800, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> arch/arm/boot/dts/imx7d-remarkable2.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
> b/arch/arm/boot/dts/imx7d-remarkable2.dts
> index 0aae13f5eed6..0978e26f5db5 100644
> --- a/arch/arm/boot/dts/imx7d-remarkable2.dts
> +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> @@ -62,6 +62,10 @@ {
> status = "okay";
> };
>
> +_pwrkey {
> + status = "okay";
> +};
> +
Please merge it into patch #1.
Shawn
> {
> pinctrl-names = "default";
> pinctrl-0 = <_uart1>;
> --
> 2.30.0
>
Re: [PATCH v3 1/3] ARM: imx7d-remarkable2.dts: Initial device tree for reMarkable2
On Wed, Feb 03, 2021 at 07:03:14PM -0800, Alistair Francis wrote:
> The reMarkable2 (https://remarkable.com) is an e-ink tablet based on
> the imx7d SoC.
>
> This commit is based on the DTS provide by reMarkable but ported to the
> latest kernel (instead of 4.14). I have removed references to
> non-upstream devices and have changed the UART so that the console can
> be accessed without having to open up the device via the OTG pogo pins.
Just out of curiosity, this is a DIY cable or something generally
available from vendor?
>
> Currently the kernel boots, but there is no support for the dispaly,
> WiFi or the power controller chips.
There are still some WiFi related devices. Can we drop all those
untested stuff?
>
> Signed-off-by: Alistair Francis
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx7d-remarkable2.dts | 253
> 2 files changed, 254 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx7d-remarkable2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3d1ea0b25168..9608c363b25f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -658,6 +658,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-pico-hobbit.dtb \
> imx7d-pico-nymph.dtb \
> imx7d-pico-pi.dtb \
> + imx7d-remarkable2.dtb \
> imx7d-sbc-imx7.dtb \
> imx7d-sdb.dtb \
> imx7d-sdb-reva.dtb \
> diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts
> b/arch/arm/boot/dts/imx7d-remarkable2.dts
> new file mode 100644
> index ..0aae13f5eed6
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "imx7d.dtsi"
> +
> +/ {
> + model = "reMarkable 2.0";
> + compatible = "fsl,imx7d-remarkable2", "fsl,imx7d";
The new compatible needs to be documented. Also the compatible doesn't
look right, as this is a device from reMarkable rather than FSL.
Shawn
> +
> + chosen {
> + stdout-path =
> + };
> +
> + memory {
> + reg = <0x8000 0x4000>;
> + };
> +
> + reg_brcm: regulator-brcm {
> + compatible = "regulator-fixed";
> + regulator-name = "brcm_reg";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_brcm_reg>;
> + gpio = < 13 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + startup-delay-us = <150>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <_wifi>;
> + reset-gpios = < 9 GPIO_ACTIVE_LOW>;
> + clocks = < IMX7D_CLKO2_ROOT_DIV>;
> + clock-names = "ext_clock";
> + };
> +};
> +
> + {
> + assigned-clocks = < IMX7D_CLKO2_ROOT_SRC>,
> + < IMX7D_CLKO2_ROOT_DIV>;
> + assigned-clock-parents = < IMX7D_CKIL>;
> + assigned-clock-rates = <0>, <32768>;
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> +_apbh {
> + status = "disabled";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart1>;
> + assigned-clocks = < IMX7D_UART1_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart6>;
> + assigned-clocks = < IMX7D_UART6_ROOT_SRC>;
> + assigned-clock-parents = < IMX7D_OSC_24M_CLK>;
> + status = "okay";
> +};
> +
> + {
> + srp-disable;
> + hnp-disable;
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default", "state_100mhz", "sleep";
> + pinctrl-0 = <_usdhc2>;
> + pinctrl-1 = <_usdhc2_100mhz>;
> + pinctrl-2 = <_usdhc2>;
> + mmc-pwrseq = <_pwrseq>;
> + vmmc-supply = <_brcm>;
> + bus-width = <4>;
> + non-removable;
> + keep-power-in-suspend;
> + cap-power-off-card;
> + status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + };
> +};
> +
> + {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> + pinctrl-0 = <_usdhc3>;
> + pinctrl-1 = <_usdhc3_100mhz>;
> + pinctrl-2 = <_usdhc3_200mhz>;
> + pinctrl-3 = <_usdhc3>;
> + assigned-clocks = < IMX7D_USDHC3_ROOT_CLK>;
> + assigned-clock-rates = <4>;
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_wdog>;
> +
Re: [PATCH v3] ARM: imx: avic: Convert to using IRQCHIP_DECLARE
On Thu, Feb 04, 2021 at 05:38:46PM -0800, Saravana Kannan wrote:
> Using IRQCHIP_DECLARE lets fw_devlink know that it should not wait for
> these interrupt controllers to be populated as struct devices. Without
> this change, fw_devlink=on will make the consumers of these interrupt
> controllers wait for the struct device to be added and thereby block the
> consumers' probes forever. Converting to IRQCHIP_DECLARE addresses boot
> issues on imx25 with fw_devlink=on that were reported by Martin.
>
> This also removes a lot of boilerplate code.
>
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Reported-by: Martin Kaiser
> Signed-off-by: Saravana Kannan
> Tested-by: Martin Kaiser
Applied, thanks.
Re: [PATCH] ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for i2c bus recovery
On Sun, Jan 31, 2021 at 06:54:46PM +0300, Dima Azarkin wrote: > The i2c bus on imx6qdl-wandboard has intermittent issues where SDA can freeze > on low level at the end of transaction so the bus can no longer work. This > impacts reading of EDID data leading to incorrect TV resolution and no audio. > > This scenario is improved by adding scl/sda gpios definitions to implement the > i2c bus recovery mechanism. > > Signed-off-by: Dima Azarkin Applied, thanks.
Re: [PATCH 0/2] Add i.MX51/i.MX53 serial number support
On Wed, Jan 27, 2021 at 06:40:22PM +0100, Sebastian Reichel wrote: > Sebastian Reichel (2): > ARM: dts: imx: Mark IIM as syscon on i.MX51/i.MX53 > soc: imx: add i.MX51/i.MX53 unique id support Applied both, thanks.
Re: [PATCH] ARM: dts: imx6sl-tolino-shine2hd: Add Netronix embedded controller
On Mon, Jan 25, 2021 at 08:08:04PM +0100, Andreas Kemnade wrote: > For now, the driver detects an incompatible version, but since > that can be handled by auto-detection, add the controller to the > devicetree now. Only PWM seems to be available, there is no RTC > in that controller. > > Signed-off-by: Andreas Kemnade Applied, thanks.
Re: [PATCH v9 7/7] ARM: dts: imx50-kobo-aura: Add Netronix embedded controller
On Sun, Jan 24, 2021 at 10:41:27PM +0100, Jonathan Neuschäfer wrote: > Enable the Netronix EC on the Kobo Aura ebook reader. > > Several features are still missing: > - Frontlight/backlight. The vendor kernel drives the frontlight LED >using the PWM output of the EC and an additional boost pin that >increases the brightness. > - Battery monitoring > - Interrupts for RTC alarm and low-battery events > > Signed-off-by: Jonathan Neuschäfer Applied, thanks.
[PATCH] cpufreq: qcom-hw: fix dereferencing freed memory 'data'
Commit 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from
init/exit hooks") introduces an issue of dereferencing freed memory
'data'. Fix it.
Fixes: 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from init/exit
hooks")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Shawn Guo
---
Viresh,
The issue was introduced by v2 of "cpufreq: qcom-hw: drop devm_xxx()
calls from init/exit hooks", which misses the conversion of 'data->base'
in error path. Sorry!
Shawn
drivers/cpufreq/qcom-cpufreq-hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d3c23447b892..bee5d67a8227 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -374,7 +374,7 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy
*policy)
error:
kfree(data);
unmap_base:
- iounmap(data->base);
+ iounmap(base);
release_region:
release_mem_region(res->start, resource_size(res));
return ret;
--
2.17.1
Re: drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we previously assumed 'data' could be null (see line 327)
On Sat, Feb 27, 2021 at 12:26:20PM +0300, Dan Carpenter wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 8b83369ddcb3fb9cab5c1088987ce477565bb630 > commit: 67fc209b527d023db4d087c68e44e9790aa089ef cpufreq: qcom-hw: drop > devm_xxx() calls from init/exit hooks > config: arm64-randconfig-m031-20210226 (attached as .config) > compiler: aarch64-linux-gcc (GCC) 9.3.0 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > Reported-by: Dan Carpenter > > smatch warnings: > drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: we > previously assumed 'data' could be null (see line 327) > drivers/cpufreq/qcom-cpufreq-hw.c:377 qcom_cpufreq_hw_cpu_init() error: > dereferencing freed memory 'data' Thanks for the report! I will send a fix for it right away. Shawn
Re: [PATCH] Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
On Sat, Feb 06, 2021 at 09:49:37AM +0100, Ard Biesheuvel wrote: > This reverts commit 32cf1a12cad43358e47dac8014379c2f33dfbed4. > > The 'exisitng buffer' in this case is the firmware provided table, and > we should not modify that in place. This fixes a crash on arm64 with > initrd table overrides, in which case the DSDT is not mapped with > read/write permissions. > > Cc: Robert Moore > Cc: Erik Kaneda > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Reported-by: Shawn Guo > Signed-off-by: Ard Biesheuvel Tested-by: Shawn Guo Thanks for fixing the regression, Ard! Shawn
Re: [PATCH v6 1/3] dt-bindings: arm: imx: add imx8mm nitrogen support
On Thu, Jan 28, 2021 at 08:35:52PM +0100, Adrien Grassein wrote: > The Nitrogen8M Mini is an ARM based single board computer (SBC). > > Signed-off-by: Adrien Grassein > Reviewed-by: Krzysztof Kozlowski Applied all 3, thanks.
Re: [PATCH 20/21] clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible header
On Tue, Jan 26, 2021 at 12:45:39PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/clk/imx/clk-imx6sl.c:156:6: warning: no previous prototype for > ‘imx6sl_set_wait_clk’ [-Wmissing-prototypes] > > Cc: Russell King > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Ahmad Fatoum > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Lee Jones Applied, thanks.
Re: [PATCH] arm64: dts: freescale: fix dcfg address range
On Thu, Jan 21, 2021 at 04:52:37PM +0100, Zyta Szpak wrote:
> Dcfg was overlapping with clockgen address space which resulted
> in failure in memory allocation for dcfg. According regs description
> dcfg size should not be bigger than 4KB.
>
> Signed-off-by: Zyta Szpak
I changed subject prefix to 'arm64: dts: ls1046a: ...', and applied the
patch with Fixes tag below.
Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
Shawn
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index 025e1f587662..565934cbfa28 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -385,7 +385,7 @@
>
> dcfg: dcfg@1ee {
> compatible = "fsl,ls1046a-dcfg", "syscon";
> - reg = <0x0 0x1ee 0x0 0x1>;
> + reg = <0x0 0x1ee 0x0 0x1000>;
> big-endian;
> };
>
> --
> 2.17.1
>
Re: [Patch v2 0/3] Enable flexcan support in LS1028A/LX2160A
On Thu, Jan 21, 2021 at 04:27:36PM +0530, Kuldeep Singh wrote: > This patch set adds device-tree support for LX2160A-RDB/QDS. > > Also, update flexcan entry for LS1028A and enable support further for > LS1028A-RDB/QDS. > > Patch1: Add dtsi and dts properties for LX2160A > Patch2: Update dtsi properties for LS1028A > Patch3: Add dts properties for LS1028A. > > Changes since v1: > -Use clockgen constants instead of numeric numbers > > Kuldeep Singh (3): > arm64: dts: lx2160a: Add flexcan support > arm64: dtsi: ls1028a: Update flexcan properties > arm64: dts: ls1028a: Enable flexcan support for LS1028A-RDB/QDS Applied all, thanks.
Re: [PATCH v2 3/3] arch/arm/configs: Enable VMSPLIT_2G in imx_v6_v7_defconfig
On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote: > The reMarkable2 requires VMSPLIT_2G, so lets set this in the > imx_v6_v7_defconfig. Hmm, why is VMSPLIT_2G required by reMarkable2? Shawn > > Signed-off-by: Alistair Francis > --- > arch/arm/configs/imx_v6_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/imx_v6_v7_defconfig > b/arch/arm/configs/imx_v6_v7_defconfig > index 55674cb1ffce..fa9229616106 100644 > --- a/arch/arm/configs/imx_v6_v7_defconfig > +++ b/arch/arm/configs/imx_v6_v7_defconfig > @@ -29,6 +29,7 @@ CONFIG_SOC_IMX7D=y > CONFIG_SOC_IMX7ULP=y > CONFIG_SOC_VF610=y > CONFIG_SMP=y > +CONFIG_VMSPLIT_2G=y > CONFIG_ARM_PSCI=y > CONFIG_HIGHMEM=y > CONFIG_FORCE_MAX_ZONEORDER=14 > -- > 2.29.2 >
Re: [PATCH] arm64: dts: imx8mq: use_dt_domains for pci node
On Fri, Jan 15, 2021 at 11:26:57AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> We are using Jailhouse Hypervsior which has virtual pci node that
> use dt domains. so also use dt domains for pci node, this will avoid
> conflict with Jailhouse Hypervisor to trigger the following error:
> pr_err("Inconsistent \"linux,pci-domain\" property in DT\n");
>
> Reviewed-by: Richard Zhu
> Signed-off-by: Peng Fan
Applied, thanks.
Re: [PATCH v2] dma: qcom: bam_dma: Manage clocks when controlled_remotely is set
On Tue, Jan 26, 2021 at 04:18:59PM -0500, Thara Gopinath wrote: > When bam dma is "controlled remotely", thus far clocks were not controlled > from the Linux. In this scenario, Linux was disabling runtime pm in bam dma > driver and not doing any clock management in suspend/resume hooks. > > With introduction of crypto engine bam dma, the clock is a rpmh resource > that can be controlled from both Linux and TZ/remote side. Now bam dma > clock is getting enabled during probe even though the bam dma can be > "controlled remotely". But due to clocks not being handled properly, > bam_suspend generates a unbalanced clk_unprepare warning during system > suspend. > > To fix the above issue and to enable proper clock-management, this patch > enables runtim-pm and handles bam dma clocks in suspend/resume hooks if > the clock node is present irrespective of controlled_remotely property. > > Signed-off-by: Thara Gopinath Reviewed-by: Shawn Guo
Re: [PATCH] drivers: dma: qcom: bam_dma: Manage clocks when controlled_remotely is set
On Fri, Jan 22, 2021 at 10:44:09AM -0500, Thara Gopinath wrote: > Hi Shawn, > > Thanks for the review > > On 1/22/21 12:10 AM, Shawn Guo wrote: > > On Thu, Jan 21, 2021 at 09:52:51PM -0500, Thara Gopinath wrote: > > > When bam dma is "controlled remotely", thus far clocks were not controlled > > > from the Linux. In this scenario, Linux was disabling runtime pm in bam > > > dma > > > driver and not doing any clock management in suspend/resume hooks. > > > > > > With introduction of crypto engine bam dma, the clock is a rpmh resource > > > that can be controlled from both Linux and TZ/remote side. Now bam dma > > > clock is getting enabled during probe even though the bam dma can be > > > "controlled remotely". But due to clocks not being handled properly, > > > bam_suspend generates a unbalanced clk_unprepare warning during system > > > suspend. > > > > > > To fix the above issue and to enable proper clock-management, this patch > > > enables runtim-pm and handles bam dma clocks in suspend/resume hooks if > > > the clock node is present irrespective of controlled_remotely property. > > > > Shouldn't the following probe code need some update? Now we have both > > controlled_remotely and clocks handle for cryptobam node. For example, > > if devm_clk_get() returns -EPROBE_DEFER, we do not want to continue with > > bamclk forcing to be NULL, right? > > We still will have to set bdev->bamclk to NULL in certain scenarios. For eg > slimbus bam dma is controlled-remotely and the clocks are handled by the > remote s/w. Linux does not handle the clocks at all and there is no clock > specified in the dt node.This is the norm for the devices that are also > controlled by remote s/w. Crypto bam dma is a special case where the clock > is actually a rpmh resource and hence can be independently handled from both > remote side and Linux by voting. In this case, the dma is controlled > remotely but clock can be turned off and on in Linux. Hence the need for > this patch. So is it correct to say that clock is mandatory for !controlled-remotely BAM, while it's optional for controlled-remotely one. If yes, maybe we can do something like below to make the code a bit easier to read? if (controlled-remotely) bdev->bamclk = devm_clk_get_optional(); else bdev->bamclk = devm_clk_get(); > Yes, the probe code needs updating to handle -EPROBE_DEFER (esp if the clock > driver is built in as a module) I am not sure if the clock framework handles > -EPROBE_DEFER properly either. So that > might need updating too. This is a separate activity and not part of this > patch. As the patch breaks the assumption that for controlled-remotely BAM there is no clock to be managed, the probe code becomes buggy right away. Shawn
Re: [PATCH] drivers: dma: qcom: bam_dma: Manage clocks when controlled_remotely is set
On Thu, Jan 21, 2021 at 09:52:51PM -0500, Thara Gopinath wrote:
> When bam dma is "controlled remotely", thus far clocks were not controlled
> from the Linux. In this scenario, Linux was disabling runtime pm in bam dma
> driver and not doing any clock management in suspend/resume hooks.
>
> With introduction of crypto engine bam dma, the clock is a rpmh resource
> that can be controlled from both Linux and TZ/remote side. Now bam dma
> clock is getting enabled during probe even though the bam dma can be
> "controlled remotely". But due to clocks not being handled properly,
> bam_suspend generates a unbalanced clk_unprepare warning during system
> suspend.
>
> To fix the above issue and to enable proper clock-management, this patch
> enables runtim-pm and handles bam dma clocks in suspend/resume hooks if
> the clock node is present irrespective of controlled_remotely property.
Shouldn't the following probe code need some update? Now we have both
controlled_remotely and clocks handle for cryptobam node. For example,
if devm_clk_get() returns -EPROBE_DEFER, we do not want to continue with
bamclk forcing to be NULL, right?
bdev->bamclk = devm_clk_get(bdev->dev, "bam_clk");
if (IS_ERR(bdev->bamclk)) {
if (!bdev->controlled_remotely)
return PTR_ERR(bdev->bamclk);
bdev->bamclk = NULL;
}
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/dma/qcom/bam_dma.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 88579857ca1d..b3a34be63e99 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1350,7 +1350,7 @@ static int bam_dma_probe(struct platform_device *pdev)
> if (ret)
> goto err_unregister_dma;
>
> - if (bdev->controlled_remotely) {
> + if (!bdev->bamclk) {
> pm_runtime_disable(>dev);
> return 0;
> }
> @@ -1438,10 +1438,10 @@ static int __maybe_unused bam_dma_suspend(struct
> device *dev)
> {
> struct bam_device *bdev = dev_get_drvdata(dev);
>
> - if (!bdev->controlled_remotely)
> + if (bdev->bamclk) {
> pm_runtime_force_suspend(dev);
> -
> - clk_unprepare(bdev->bamclk);
> + clk_unprepare(bdev->bamclk);
> + }
>
> return 0;
> }
> @@ -1451,12 +1451,14 @@ static int __maybe_unused bam_dma_resume(struct
> device *dev)
> struct bam_device *bdev = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare(bdev->bamclk);
> - if (ret)
> - return ret;
> + if (bdev->bamclk) {
> + ret = clk_prepare(bdev->bamclk);
> + if (ret)
> + return ret;
>
> - if (!bdev->controlled_remotely)
> - pm_runtime_force_resume(dev);
> + if (!bdev->controlled_remotely)
Why do we still need controlled_remotely check here?
Shawn
> + pm_runtime_force_resume(dev);
> + }
>
> return 0;
> }
> --
> 2.25.1
>
Re: [PATCH 1/2] arm64: dts: fsl-ls1012a-rdb: add i2c devices
On Mon, Jan 18, 2021 at 11:08:11AM +0100, Paweł Dembicki wrote:
> On 18.01.2021 at 08:36 Shawn Guo wrote:
> >
> > On Fri, Jan 15, 2021 at 11:16:12AM +0100, Pawel Dembicki wrote:
> > > LS1012A-RDB equipped in some i2c devices:
> > > - 3x GPIO Expander: PCAL9555A (NXP)
> > > - Gyro: FXAS21002 (NXP)
> > > - Accelerometer: FXOS8700 (NXP)
> > > - Current & Power Monitor: INA220 (TI)
> > >
> > > This patch add listed devices to dts.
> > >
> > > Signed-off-by: Pawel Dembicki
> > > ---
> > > .../boot/dts/freescale/fsl-ls1012a-rdb.dts| 45 +++
> > > 1 file changed, 45 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > > index d45c17620b98..12117a973eb6 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> > > @@ -7,6 +7,7 @@
> > > */
> > > /dts-v1/;
> > >
> > > +#include
> > > #include "fsl-ls1012a.dtsi"
> > >
> > > / {
> > > @@ -33,6 +34,50 @@ {
> > >
> > > {
> > > status = "okay";
> > > +
> > > + accelerometer@1e {
> > > + compatible = "nxp,fxos8700";
> > > + reg = <0x1e>;
> > > + interrupt-parent = <>;
> > > + interrupts = <13 IRQ_TYPE_EDGE_RISING>;
> > > + interrupt-names = "INT1";
> > > + };
> > > +
> > > + gyroscope@20 {
> >
> > Please sort these device node in unit-address.
> >
> > Shawn
> >
>
> Could You give me more details please? Devices are sorted by
> unit-address ascending.
Oops! I'm sorry. It must be something went wrong with my eyes.
Shawn
Re: [RFC PATCH] ARM: dts: imx6qdl: specify vcc-supply for NOP USB PHYs
On Fri, Nov 13, 2020 at 04:28:55PM +0100, Ahmad Fatoum wrote:
> The SoC dtsi lists a NOP USB PHY for each of the two HSIC-only USB
> controllers. Their device tree node doesn't indicate a vcc-supply
> resulting in:
>
> usb_phy_generic usbphynop1: supply vcc not found, using dummy regulator
> usb_phy_generic usbphynop2: supply vcc not found, using dummy regulator
So the patch is all for removing this kernel message, with introducing
the following potential breakage?
Shawn
>
> warnings on boot up. The USB IP vcc-supply - separate from the vusb - is
> hardwired to LDO_2P5[1], which we already have a device tree node for.
> Reference it for the dummy "phy" as well.
>
> This will lead to breakage (probe deferment) for kernels that:
> - Use a HSIC USB controller
> - Use this new device tree
> - but have CONFIG_REGULATOR_ANATOP disabled
>
> Because while the regulator is always-on, it can't be resolved when
> there is no driver for it.
>
> As there are
>
> - no affected upstream device trees
> - existing device trees are unaffected without recompilation
> - disabling CONFIG_REGULATOR_ANATOP is explicitly a non-recommended
> configuration per symbol help text
>
> this potential breakage is deemed acceptable.
>
> [1]: i.MX 6Dual/6Quad Reference Manual, Rev. C,
> Figure 53-1. Power System Overview
>
> Cc: Frieder Schrempf
> Signed-off-by: Ahmad Fatoum
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 43edbf1156c7..22e4c142de13 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -131,11 +131,13 @@ pmu: pmu {
>
> usbphynop1: usbphynop1 {
> compatible = "usb-nop-xceiv";
> + vcc-supply = <_vdd2p5>;
> #phy-cells = <0>;
> };
>
> usbphynop2: usbphynop2 {
> compatible = "usb-nop-xceiv";
> + vcc-supply = <_vdd2p5>;
> #phy-cells = <0>;
> };
>
> --
> 2.28.0
>
Re: [PATCH] venus: core: Fix platform driver shutdown
On Tue, Jan 19, 2021 at 09:59:41AM +0200, Stanimir Varbanov wrote:
> On 1/19/21 9:40 AM, Shawn Guo wrote:
> > On Mon, Dec 21, 2020 at 11:58:20AM +0200, Stanimir Varbanov wrote:
> >> With TZ system reboot cannot finish successfully. To fix that
> >> enable core clocks by runtime pm before TZ calls and disable
> >> clocks after that.
> >>
> >> Fixes: 7399139be6b2 ("media: venus: core: add shutdown callback for venus")
> >> Signed-off-by: Stanimir Varbanov
> >
> > Hi Mauro,
> >
> > Could you help pick this fix up?
>
> Shawn, it is part of linux-next already.
Ha, sorry, I did not check linux-next. I sent the message because
I see this fix is still missing after I rebase my Yoga C630 branch
to 5.11-rc4. We will get this fix into 5.11, right?
Shawn
Re: [PATCH] venus: core: Fix platform driver shutdown
On Mon, Dec 21, 2020 at 11:58:20AM +0200, Stanimir Varbanov wrote:
> With TZ system reboot cannot finish successfully. To fix that
> enable core clocks by runtime pm before TZ calls and disable
> clocks after that.
>
> Fixes: 7399139be6b2 ("media: venus: core: add shutdown callback for venus")
> Signed-off-by: Stanimir Varbanov
Hi Mauro,
Could you help pick this fix up?
Shawn
> ---
> drivers/media/platform/qcom/venus/core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index bdd293faaad0..7233a7311757 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -349,8 +349,10 @@ static void venus_core_shutdown(struct platform_device
> *pdev)
> {
> struct venus_core *core = platform_get_drvdata(pdev);
>
> + pm_runtime_get_sync(core->dev);
> venus_shutdown(core);
> venus_firmware_deinit(core);
> + pm_runtime_put_sync(core->dev);
> }
>
> static __maybe_unused int venus_runtime_suspend(struct device *dev)
> --
> 2.17.1
>
Re: [PATCH] imx: select SOC_BUS to fix firmware build
On Mon, Jan 18, 2021 at 04:36:55AM +, Aisheng Dong wrote: > > From: Randy Dunlap > > Sent: Saturday, January 16, 2021 11:33 AM > > Subject: [PATCH] imx: select SOC_BUS to fix firmware build > > Patch title probably is better to be: > firmware: imx: x Fixed it up and applied.
Re: [PATCH v4 2/3] arm64: dts: imx: Add i.mx8mm nitrogen8mm basic dts support
On Fri, Jan 15, 2021 at 10:01:23PM +0100, Adrien Grassein wrote:
> Tested with a basic Build Root configuration booting from sdcard.
>
> Signed-off-by: Adrien Grassein
> ---
> arch/arm64/boot/dts/freescale/Makefile| 1 +
> .../dts/freescale/imx8mm-nitrogen8mm_rev2.dts | 415 ++
> 2 files changed, 416 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-nitrogen8mm_rev2.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile
> b/arch/arm64/boot/dts/freescale/Makefile
> index 38559943c15d..398b5cb4f3e2 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -49,6 +49,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-nitrogen8mm_rev2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-thor96.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-nitrogen8mm_rev2.dts
> b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen8mm_rev2.dts
> new file mode 100644
> index ..e89fbf512f9e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen8mm_rev2.dts
> @@ -0,0 +1,415 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree file for Boundary Devices i.MX8MMini Nitrogen8MM Rev2 board.
> + * Adrien Grassein
> + */
> +/dts-v1/;
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "Boundary Devices i.MX8MMini Nitrogen8MM Rev2";
> + compatible = "boundary,imx8mm-nitrogen8mm", "fsl,imx8mm";
> +};
> +
> +_0 {
> + cpu-supply = <_sw3>;
> +};
> +
> +_1 {
> + cpu-supply = <_sw3>;
> +};
> +
> +_2 {
> + cpu-supply = <_sw3>;
> +};
> +
> +_3 {
> + cpu-supply = <_sw3>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_fec1>;
> +
Unnecessary newline.
> + phy-mode = "rgmii-id";
> + phy-handle = <>;
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
Have a newline between properties and child node.
> + ethphy0: ethernet-phy@4 {
> + compatible = "ethernet-phy-id004d.d072",
> + "ethernet-phy-ieee802.3-c22";
> + reg = <4>;
> + interrupts-extended = < 16 IRQ_TYPE_LEVEL_LOW>;
> + };
> + };
> +};
> +
> + {
> + clock-frequency = <40>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <_i2c1>;
> + pinctrl-1 = <_i2c1_1>;
> + scl-gpios = < 14 GPIO_OPEN_DRAIN>;
> + sda-gpios = < 15 GPIO_OPEN_DRAIN>;
> + status = "okay";
> +
> + pmic@8 {
> + compatible = "nxp,pf8121a";
> + reg = <0x8>;
> + status = "okay";
Unnecessary `status`.
> +
> + regulators {
> + reg_ldo1: ldo1 {
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <500>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_ldo2: ldo2 {
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <500>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_ldo3: ldo3 {
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <500>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_ldo4: ldo4 {
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <500>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_buck1: buck1 {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <180>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_buck2: buck2 {
> + regulator-min-microvolt = <40>;
> + regulator-max-microvolt = <180>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + reg_sw3: buck3 {
> +
Re: [PATCH 2/2] arm64: dts: fsl-ls1012a-frdm: add spi-uart device
On Fri, Jan 15, 2021 at 11:16:13AM +0100, Pawel Dembicki wrote:
> This patch adds spi-uart controller to LS1012A-FRDM board dts.
> Device is equipped in SC16IS740 from NXP.
>
> Signed-off-by: Pawel Dembicki
> ---
> .../boot/dts/freescale/fsl-ls1012a-frdm.dts | 21 +++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> index 67702667ed8a..9473d16336a2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> @@ -7,6 +7,7 @@
> */
> /dts-v1/;
>
> +#include
> #include "fsl-ls1012a.dtsi"
>
> / {
> @@ -57,6 +58,26 @@ simple-audio-card,codec {
> };
> };
>
> + {
> + status = "okay";
> + bus-num = <0>;
Let's end property list with `status`.
> +
> + serial@0 {
> + reg = <0>;
> + compatible = "nxp,sc16is740";
Let's start property list with `compatible`.
> + spi-max-frequency = <400>;
> + clocks = <_clk>;
> + interrupt-parent = <>;
> + interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
> +
> + sc16is7xx_clk: sc16is7xx_clk {
clock-sc16is7xx for node name maybe.
Shawn
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2400>;
> + };
> + };
> +};
> +
> {
> status = "okay";
> };
> --
> 2.25.1
>
Re: [PATCH 1/2] arm64: dts: fsl-ls1012a-rdb: add i2c devices
On Fri, Jan 15, 2021 at 11:16:12AM +0100, Pawel Dembicki wrote:
> LS1012A-RDB equipped in some i2c devices:
> - 3x GPIO Expander: PCAL9555A (NXP)
> - Gyro: FXAS21002 (NXP)
> - Accelerometer: FXOS8700 (NXP)
> - Current & Power Monitor: INA220 (TI)
>
> This patch add listed devices to dts.
>
> Signed-off-by: Pawel Dembicki
> ---
> .../boot/dts/freescale/fsl-ls1012a-rdb.dts| 45 +++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> index d45c17620b98..12117a973eb6 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> @@ -7,6 +7,7 @@
> */
> /dts-v1/;
>
> +#include
> #include "fsl-ls1012a.dtsi"
>
> / {
> @@ -33,6 +34,50 @@ {
>
> {
> status = "okay";
> +
> + accelerometer@1e {
> + compatible = "nxp,fxos8700";
> + reg = <0x1e>;
> + interrupt-parent = <>;
> + interrupts = <13 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "INT1";
> + };
> +
> + gyroscope@20 {
Please sort these device node in unit-address.
Shawn
> + compatible = "nxp,fxas21002c";
> + reg = <0x20>;
> + };
> +
> + gpio@24 {
> + compatible = "nxp,pcal9555a";
> + reg = <0x24>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + gpio@25 {
> + compatible = "nxp,pcal9555a";
> + reg = <0x25>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + gpio26: gpio@26 {
> + compatible = "nxp,pcal9555a";
> + reg = <0x26>;
> + interrupt-parent = <>;
> + interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + current-sensor@40 {
> + compatible = "ti,ina220";
> + reg = <0x40>;
> + shunt-resistor = <2000>;
> + };
> };
>
> {
> --
> 2.25.1
>
Re: [PATCH] MAINTAINERS: Add section for NXP i.MX clock drivers
On Wed, Jan 13, 2021 at 02:53:08PM +0200, Abel Vesa wrote: > Add a section for NXP i.MX clock drivers and list myself > as the maintainer. > > Signed-off-by: Abel Vesa Acked-by: Shawn Guo
Re: [PATCH 0/4] ARM: dts: imx: uart improvements for ebookreaders
On Wed, Jan 13, 2021 at 12:15:44AM +0100, Andreas Kemnade wrote: > - add second uart > - correct pinmux for console uart (it was working before because of > setup by uboot) > - document locations on board > > Andreas Kemnade (4): > ARM: dts: imx6sl-tolino-shine2hd: correct console uart pinmux > ARM: dts: imx6sl-tolino-shine2hd: add second uart > ARM: dts: imx6sl-tolino-shine3: correct console uart pinmux > ARM: dts: imx: e60k02: add second uart Applied all, thanks.
Re: [PATCH 6/9] arm64: dts: imx8mq-librem5: enable the LCD panel
On Tue, Jan 12, 2021 at 10:51:48AM +0100, Martin Kepplinger wrote:
> This enables the Librem5's ft8006p based LCD panel driven by the
> imx8mq's Northwest Logic DSI IP core and mxsfb display controller.
>
> Signed-off-by: Martin Kepplinger
> ---
> .../boot/dts/freescale/imx8mq-librem5.dtsi| 51 ++-
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index f77b51d3c132..440931f81c12 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -310,6 +310,17 @@
> >;
> };
>
> + pinctrl_dsirst: dsirstgrp {
> + fsl,pins = <
> + /* DSI_RST */
> + MX8MQ_IOMUXC_ENET_RD3_GPIO1_IO290x83
> + /* DSI_TE */
> + MX8MQ_IOMUXC_ENET_RD2_GPIO1_IO280x83
> + /* TP_RST */
> + MX8MQ_IOMUXC_ENET_RX_CTL_GPIO1_IO24 0x83
> + >;
> + };
> +
> pinctrl_ecspi1: ecspigrp {
> fsl,pins = <
> MX8MQ_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI0x83
> @@ -817,12 +828,12 @@
> compatible = "tps65132";
> reg = <0x3e>;
>
> - outp {
> + reg_lcd_avdd: outp {
> regulator-name = "LCD_AVDD";
> vin-supply = <_lcd_3v4>;
> };
>
> - outn {
> + reg_lcd_avee: outn {
> regulator-name = "LCD_AVEE";
> vin-supply = <_lcd_3v4>;
> };
> @@ -947,6 +958,42 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> +_dsi {
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
Please end property list with `status`.
> +
> + lcd_panel: panel@0 {
> + compatible = "mantix,mlaf057we51-x";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_dsirst>;
> + avdd-supply = <_lcd_avdd>;
> + avee-supply = <_lcd_avee>;
> + vddi-supply = <_lcd_1v8>;
> + backlight = <_dsi>;
> + reset-gpios = < 29 GPIO_ACTIVE_LOW>;
Have a newline between properties and child node.
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + reg = <1>;
Ditto
Shawn
> + mipi_dsi_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
> _gpu {
> power-supply = <_reg>;
> };
> --
> 2.20.1
>
Re: [PATCH 1/1] ARM: imx: build suspend-imx6.S with arm instruction set
On Mon, Jan 11, 2021 at 04:17:04PM +0100, Max Krummenacher wrote: > When the kernel is configured to use the Thumb-2 instruction set > "suspend-to-memory" fails to resume. Observed on a Colibri iMX6ULL > (i.MX 6ULL) and Apalis iMX6 (i.MX 6Q). > > It looks like the CPU resumes unconditionally in ARM instruction mode > and then chokes on the presented Thumb-2 code it should execute. > > Fix this by using the arm instruction set for all code in > suspend-imx6.S. > > Signed-off-by: Max Krummenacher Applied, thanks.
Re: [PATCH] ARM: dts: imx7d-flex-concentrator: fix pcf2127 reset
On Mon, Jan 11, 2021 at 04:15:37PM +0100, Bruno Thomsen wrote:
> RTC pcf2127 device driver has changed default behaviour of the watchdog
> feature in v5.11-rc1. Now you need to explicitly enable it with a
> device tree property, "reset-source", when used in the board design.
It sound that the existing DTBs are broken by this default behaviour
change?
>
> Fixes: 71ac13457d9d ("rtc: pcf2127: only use watchdog when explicitly
> available")
>
> Signed-off-by: Bruno Thomsen
> Cc: Bruno Thomsen
> Cc: Uwe Kleine-König
> Cc: Rasmus Villemoes
> Cc: Alexandre Belloni
Applied, thanks.
Shawn
> ---
> arch/arm/boot/dts/imx7d-flex-concentrator.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
> b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
> index 84b095279e65..bd6b5285aa8d 100644
> --- a/arch/arm/boot/dts/imx7d-flex-concentrator.dts
> +++ b/arch/arm/boot/dts/imx7d-flex-concentrator.dts
> @@ -115,6 +115,7 @@ pcf2127: rtc@0 {
> compatible = "nxp,pcf2127";
> reg = <0>;
> spi-max-frequency = <200>;
> + reset-source;
> };
> };
>
>
> base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
> --
> 2.29.2
>
Re: [PATCH RESEND v3] arm64: dts: ls1028a: fix FlexSPI clock
On Mon, Jan 11, 2021 at 12:45:55PM +0100, Michael Walle wrote: > Now that we have a proper driver for the FlexSPI interface use it. This > will fix SCK frequency switching on Layerscape SoCs. > > This was tested on the Kontron sl28 board. > > Signed-off-by: Michael Walle Applied, thanks.
