* Re: [PATCH v4 06/10] dt-bindings: mtd: update STM32 FMC2 NAND controller documentation
From: Christophe Kerello @ 2020-05-14 16:34 UTC (permalink / raw)
To: Rob Herring
Cc: miquel.raynal, richard, vigneshr, mark.rutland, gregkh,
boris.brezillon, linux-mtd, linux-kernel, linux-stm32, devicetree,
marex
In-Reply-To: <20200514150028.GB28489@bogus>
Hi Rob,
On 5/14/20 5:00 PM, Rob Herring wrote:
> On Wed, May 06, 2020 at 11:11:15AM +0200, Christophe Kerello wrote:
>> These bindings can be used on SOCs where the FMC2 NAND controller is
>> in standalone. In case that the FMC2 embeds 2 controllers (an external
>> bus controller and a raw NAND controller), the register base and the
>> clock will be defined in the parent node. It is the reason why the
>> register base address and the clock are now optional.
>>
>> Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
>> ---
>> .../devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml | 19 ++++++++++---------
>> 1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> index b059267..68fac1a 100644
>> --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml
>> @@ -18,13 +18,15 @@ properties:
>>
>> reg:
>> items:
>> - - description: Registers
>> + - description: Registers (optional)
>
> The only thing that can be optional are the last entries. You have to do
> a 'oneOf' with 6 entries and 7 entries.
Ok, so the way to describe the reg property in my case should be:
reg:
oneOf:
- description: FMC2 embeds the NFC controller in standalone.
items:
- description: Registers
- description: Chip select 0 data
- description: Chip select 0 command
- description: Chip select 0 address space
- description: Chip select 1 data
- description: Chip select 1 command
- description: Chip select 1 address space
- description: FMC2 embeds the NFC controller and the EBI
controller.
items:
- description: Chip select 0 data
- description: Chip select 0 command
- description: Chip select 0 address space
- description: Chip select 1 data
- description: Chip select 1 command
- description: Chip select 1 address space
>
> And where's your new compatible string for this different h/w?
From NFC controller point of view, it is the same HW.
In the case that we have 2 controllers embedded, the register base is
shared.
The NFC driver will check at probe time the compatible string of its
parent node.
In case that it is "st,stm32mp1-fmc2-ebi", then the driver will find the
register base in the parent node (EBI node), otherwise it will find it
in the NFC node.
Is it better to have 2 compatible strings (one for each reg description)
than checking the parent's compatible string and have only one
compatible string?
Regards,
Christophe Kerello.
>
>> - description: Chip select 0 data
>> - description: Chip select 0 command
>> - description: Chip select 0 address space
>> - description: Chip select 1 data
>> - description: Chip select 1 command
>> - description: Chip select 1 address space
>> + minItems: 6
>> + maxItems: 7
>>
>> interrupts:
>> maxItems: 1
>> @@ -61,7 +63,6 @@ required:
>> - compatible
>> - reg
>> - interrupts
>> - - clocks
>>
>> examples:
>> - |
>> @@ -77,13 +78,13 @@ examples:
>> <0x81000000 0x1000>,
>> <0x89010000 0x1000>,
>> <0x89020000 0x1000>;
>> - interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> - dmas = <&mdma1 20 0x10 0x12000a02 0x0 0x0>,
>> - <&mdma1 20 0x10 0x12000a08 0x0 0x0>,
>> - <&mdma1 21 0x10 0x12000a0a 0x0 0x0>;
>> - dma-names = "tx", "rx", "ecc";
>> - clocks = <&rcc FMC_K>;
>> - resets = <&rcc FMC_R>;
>> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> + dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
>> + <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
>> + <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
>> + dma-names = "tx", "rx", "ecc";
>> + clocks = <&rcc FMC_K>;
>> + resets = <&rcc FMC_R>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Maxime Ripard @ 2020-05-14 16:22 UTC (permalink / raw)
To: Joerg Roedel
Cc: Chen-Yu Tsai, Mark Rutland, Rob Herring, Frank Rowand, devicetree,
linux-arm-kernel, iommu
In-Reply-To: <20200514131647.GK18353@8bytes.org>
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
Hi,
On Thu, May 14, 2020 at 03:16:47PM +0200, Joerg Roedel wrote:
> On Thu, May 14, 2020 at 03:09:00PM +0200, Maxime Ripard wrote:
> > On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> > > On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > > > Maxime Ripard (5):
> > > > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > > > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > > > iommu: Add Allwinner H6 IOMMU driver
> > > > arm64: dts: allwinner: h6: Add IOMMU
> > > > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
> > >
> > > Applied all to the IOMMU tree, thanks. The code lives in the
> > > arm/allwinner branch.
> >
> > Did you also merge the DTS and DRM patches?
> >
> > Ideally, they should be merged through other trees to avoid the conflicts as
> > much as possible (arm-soc and drm-misc respectively).
> >
> > If it's an option, could you drop all of them but "dt-bindings: iommu: Add
> > Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
>
> Okay, just to be on the safe side, I am going to drop:
>
> dt-bindings: display: sun8i-mixer: Allow for an iommu property
> arm64: dts: allwinner: h6: Add IOMMU
> drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
>
> from the iommu-tree?
Yep, please :)
> I took them because you are also maintaining the DRM driver, which
> counted as an implicit ACK for me :)
I also maintain the DTS patches for that matter, but we have a good number of
patches queued up for those files in those trees usually, so it's easier for
everyone to avoid the conflicts and just merge them into separate trees when we
can.
Thanks!
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 10/15] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-14 16:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Rob Herring, David S . Miller, Matthias Brugger,
John Crispin, Sean Wang, Mark Lee, Jakub Kicinski, Fabien Parent,
Heiner Kallweit, Edwin Peer, DTML, linux-kernel@vger.kernel.org,
Networking, Linux ARM, moderated list:ARM/Mediatek SoC...,
Stephane Le Provost, Pedro Tsai, Andrew Perepech,
Bartosz Golaszewski
In-Reply-To: <20200514075942.10136-11-brgl@bgdev.pl>
On Thu, May 14, 2020 at 10:00 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> family. For now we only support full-duplex.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Looks very nice overall. Just a few things I noticed, and some ideas
that may or may not make sense:
> +/* This is defined to 0 on arm64 in arch/arm64/include/asm/processor.h but
> + * this IP doesn't work without this alignment being equal to 2.
> + */
> +#ifdef NET_IP_ALIGN
> +#undef NET_IP_ALIGN
> +#endif
> +#define NET_IP_ALIGN 2
Maybe you should just define your own macro instead of replacing
the normal one then?
> +static void mtk_mac_lock(struct mtk_mac_priv *priv)
> +{
> + spin_lock_irqsave(&priv->lock, priv->lock_flags);
> +}
> +
> +static void mtk_mac_unlock(struct mtk_mac_priv *priv)
> +{
> + spin_unlock_irqrestore(&priv->lock, priv->lock_flags);
> +}
This looks wrong: you should not have shared 'flags' passed into
spin_lock_irqsave(), and I don't even see a need to use the
irqsave variant of the lock in the first place.
Maybe start by open-coding the lock and remove the wrappers
above.
Then see if you can use a cheaper spin_lock_bh() or plain spin_lock()
instead of irqsave.
Finally, see if this can be done in a lockless way by relying on
appropriate barriers and separating the writers into separate
cache lines. From a brief look at the driver I think it can be done
without too much trouble.
> +static unsigned int mtk_mac_intr_read_and_clear(struct mtk_mac_priv *priv)
> +{
> + unsigned int val;
> +
> + regmap_read(priv->regs, MTK_MAC_REG_INT_STS, &val);
> + regmap_write(priv->regs, MTK_MAC_REG_INT_STS, val);
> +
> + return val;
> +}
Do you actually need to read the register? That is usually a relatively
expensive operation, so if possible try to use clear the bits when
you don't care which bits were set.
> +/* All processing for TX and RX happens in the napi poll callback. */
> +static irqreturn_t mtk_mac_handle_irq(int irq, void *data)
> +{
> + struct mtk_mac_priv *priv;
> + struct net_device *ndev;
> +
> + ndev = data;
> + priv = netdev_priv(ndev);
> +
> + if (netif_running(ndev)) {
> + mtk_mac_intr_mask_all(priv);
> + napi_schedule(&priv->napi);
> + }
> +
> + return IRQ_HANDLED;
> +static int mtk_mac_netdev_start_xmit(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + struct mtk_mac_priv *priv = netdev_priv(ndev);
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct device *dev = mtk_mac_get_dev(priv);
> + struct mtk_mac_ring_desc_data desc_data;
> +
> + desc_data.dma_addr = mtk_mac_dma_map_tx(priv, skb);
> + if (dma_mapping_error(dev, desc_data.dma_addr))
> + goto err_drop_packet;
> +
> + desc_data.skb = skb;
> + desc_data.len = skb->len;
> +
> + mtk_mac_lock(priv);
> + mtk_mac_ring_push_head_tx(ring, &desc_data);
> +
> + if (mtk_mac_ring_full(ring))
> + netif_stop_queue(ndev);
> + mtk_mac_unlock(priv);
> +
> + mtk_mac_dma_resume_tx(priv);
> +
> + return NETDEV_TX_OK;
> +
> +err_drop_packet:
> + dev_kfree_skb(skb);
> + ndev->stats.tx_dropped++;
> + return NETDEV_TX_BUSY;
> +}
I would always add BQL flow control in new drivers, using
netdev_sent_queue here...
> +static int mtk_mac_tx_complete_one(struct mtk_mac_priv *priv)
> +{
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct mtk_mac_ring_desc_data desc_data;
> + int ret;
> +
> + ret = mtk_mac_ring_pop_tail(ring, &desc_data);
> + if (ret)
> + return ret;
> +
> + mtk_mac_dma_unmap_tx(priv, &desc_data);
> + dev_kfree_skb_irq(desc_data.skb);
> +
> + return 0;
> +}
... and netdev_completed_queue() here.
> +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> +{
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct net_device *ndev = priv->ndev;
> + int ret;
> +
> + for (;;) {
> + mtk_mac_lock(priv);
> +
> + if (!mtk_mac_ring_descs_available(ring)) {
> + mtk_mac_unlock(priv);
> + break;
> + }
> +
> + ret = mtk_mac_tx_complete_one(priv);
> + if (ret) {
> + mtk_mac_unlock(priv);
> + break;
> + }
> +
> + if (netif_queue_stopped(ndev))
> + netif_wake_queue(ndev);
> +
> + mtk_mac_unlock(priv);
> + }
> +}
It looks like most of the stuff inside of the loop can be pulled out
and only done once here.
> +static int mtk_mac_poll(struct napi_struct *napi, int budget)
> +{
> + struct mtk_mac_priv *priv;
> + unsigned int status;
> + int received = 0;
> +
> + priv = container_of(napi, struct mtk_mac_priv, napi);
> +
> + status = mtk_mac_intr_read_and_clear(priv);
> +
> + /* Clean up TX */
> + if (status & MTK_MAC_BIT_INT_STS_TNTC)
> + mtk_mac_tx_complete_all(priv);
> +
> + /* Receive up to $budget packets */
> + if (status & MTK_MAC_BIT_INT_STS_FNRC)
> + received = mtk_mac_process_rx(priv, budget);
> +
> + /* One of the counter reached 0x8000000 - update stats and reset all
> + * counters.
> + */
> + if (status & MTK_MAC_REG_INT_STS_MIB_CNT_TH) {
> + mtk_mac_update_stats(priv);
> + mtk_mac_reset_counters(priv);
> + }
> +
> + if (received < budget)
> + napi_complete_done(napi, received);
> +
> + mtk_mac_intr_unmask_all(priv);
> +
> + return received;
> +}
I think you want to leave (at least some of) the interrupts masked
if your budget is exhausted, to avoid generating unnecessary
irqs.
It may also be faster to not mask/unmask at all but just
clear the interrupts that you have finished processing
Arnd
^ permalink raw reply
* Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
From: Doug Anderson @ 2020-05-14 16:17 UTC (permalink / raw)
To: Kalyan Thota
Cc: dri-devel, linux-arm-msm, freedreno,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Rob Clark, Sean Paul, Kristian H. Kristensen, Jeykumar Sankaran,
mkrishn, travitej, nganji
In-Reply-To: <1588339863-1322-1-git-send-email-kalyan_t@codeaurora.org>
Hi,
On Fri, May 1, 2020 at 6:31 AM Kalyan Thota <kalyan_t@codeaurora.org> wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered, PM core adds a refcount on all the
> devices and calls device suspend, since usage count is
> already incremented, runtime suspend was not getting called
> and it kept the clocks on which resulted in target not
> entering into XO shutdown.
>
> Add changes to force suspend on runtime devices during pm sleep.
>
> Changes in v1:
> - Remove unnecessary checks in the function
> _dpu_kms_disable_dpu (Rob Clark).
>
> Changes in v2:
> - Avoid using suspend_late to reset the usagecount
> as suspend_late might not be called during suspend
> call failures (Doug).
>
> Changes in v3:
> - Use force suspend instead of managing device usage_count
> via runtime put and get API's to trigger callbacks (Doug).
>
> Changes in v4:
> - Check the return values of pm_runtime_force_suspend and
> pm_runtime_force_resume API's and pass appropriately (Doug).
>
> Changes in v5:
Can you please put the version number properly in your subject? It's
really hard to tell one version of your patch from another.
> - With v4 patch, test cycle has uncovered issues in device resume.
>
> On bubs: cmd tx failures were seen as SW is sending panel off
> commands when the dsi resources are turned off.
>
> Upon suspend, DRM driver will issue a NULL composition to the
> dpu, followed by turning off all the HW blocks.
>
> v5 changes will serialize the NULL commit and resource unwinding
> by handling them under PM prepare and PM complete phases there by
> ensuring that clks are on when panel off commands are being
> processed.
I'm still most definitely not an expert in how all the DRM pieces all
hook up together, but the solution you have in this patch seems wrong
to me. As far as I can tell the "prepare" state isn't supposed to be
actually doing the suspend work and here that's exactly what you're
doing. I think you should find a different solution to ensure
ordering is correct.
-Doug
^ permalink raw reply
* [PATCH v1 9/9] arm64: dts: actions: Add uSD support for Cubieboard7
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++++++++++++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 = &uart3;
+ mmc0 = &mmc0;
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe0000000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-always-on;
+ };
};
&i2c0 {
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+ "sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
&timer {
@@ -90,3 +116,18 @@
&uart3 {
status = "okay";
};
+
+/* uSD */
+&mmc0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_default>;
+ cd-gpios = <&pinctrl 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <&sd_vcc>;
+ vqmmc-supply = <&sd_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 3f1fc3e48415..8a541dd48f61 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/clock/actions,s700-cmu.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/actions,s700-reset.h>
--
2.7.4
^ permalink raw reply related
* [PATCH v1 8/9] arm64: dts: actions: Add MMC controller support for S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 56f2f84812cb..3f1fc3e48415 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -258,5 +258,38 @@
dma-requests = <44>;
clocks = <&cmu CLK_DMAC>;
};
+
+ mmc0: mmc@e0210000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0210000 0x0 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD0>;
+ resets = <&cmu RESET_SD0>;
+ dmas = <&dma 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD1>;
+ resets = <&cmu RESET_SD1>;
+ dmas = <&dma 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD2>;
+ resets = <&cmu RESET_SD2>;
+ dmas = <&dma 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v1 7/9] dt-bindings: reset: s700: Add binding constants for mmc
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds device tree binding reset constants for mmc controller
present on Actions S700 Soc.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* added Rob's acked-by tag
---
include/dt-bindings/reset/actions,s700-reset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
index 5e3b16b8ef53..a3118de6d7aa 100644
--- a/include/dt-bindings/reset/actions,s700-reset.h
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -30,5 +30,8 @@
#define RESET_UART4 20
#define RESET_UART5 21
#define RESET_UART6 22
+#define RESET_SD0 23
+#define RESET_SD1 24
+#define RESET_SD2 25
#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v1 6/9] arm64: dts: actions: Add DMA Controller for S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds DAM controller present on Actions S700, it differs from
S900 in terms of number of dma channels and requests.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No Change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 0397c5dd3dec..56f2f84812cb 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -245,5 +245,18 @@
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ dma: dma-controller@e0230000 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe0230000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = <&cmu CLK_DMAC>;
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v1 5/9] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
Converts the device tree bindings for the Actions Semi Owl SoCs DMA
Controller over to YAML schemas.
It also adds new compatible string "actions,s700-dma" to match
the driver.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
New patch, was not there in RFC.
---
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 ------------
Documentation/devicetree/bindings/dma/owl-dma.yaml | 84 ++++++++++++++++++++++
2 files changed, 84 insertions(+), 47 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
deleted file mode 100644
index 03e9bb12b75f..000000000000
--- a/Documentation/devicetree/bindings/dma/owl-dma.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Actions Semi Owl SoCs DMA controller
-
-This binding follows the generic DMA bindings defined in dma.txt.
-
-Required properties:
-- compatible: Should be "actions,s900-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain 4 interrupts shared by all channel.
-- #dma-cells: Must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
-- dma-channels: Physical channels supported.
-- dma-requests: Number of DMA request signals supported by the controller.
- Refer to Documentation/devicetree/bindings/dma/dma.txt
-- clocks: Phandle and Specifier of the clock feeding the DMA controller.
-
-Example:
-
-Controller:
- dma: dma-controller@e0260000 {
- compatible = "actions,s900-dma";
- reg = <0x0 0xe0260000 0x0 0x1000>;
- interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <1>;
- dma-channels = <12>;
- dma-requests = <46>;
- clocks = <&clock CLK_DMAC>;
- };
-
-Client:
-
-DMA clients connected to the Actions Semi Owl SoCs DMA controller must
-use the format described in the dma.txt file, using a two-cell specifier
-for each channel.
-
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. The channel id.
-
-uart5: serial@e012a000 {
- ...
- dma-names = "tx", "rx";
- dmas = <&dma 26>, <&dma 27>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
new file mode 100644
index 000000000000..12e68c0ece67
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl SoCs DMA controller
+
+description: |
+ The OWL DMA is a general-purpose direct memory access controller capable of
+ supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
+ respectively.
+ DMA clients connected to the Actions Semi Owl SoCs DMA controller must
+ use the format described in the owl-dma.yaml file, using a two-cell specifier
+ for each channel.
+
+ The two cells in order are:
+ 1. A phandle pointing to the DMA controller.
+ 2. The channel id.
+
+ uart5: serial@e012a000 {
+ ...
+ dma-names = "tx", "rx";
+ dmas = <&dma 26>, <&dma 27>;
+ ...
+ };
+
+maintainers:
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - actions,s900-dma
+ - actions,s700-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 4
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ maxItems: 1
+
+ dma-requests:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - dma-channels
+ - dma-requests
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/actions,s700-cmu.h>
+ dma: dma-controller@e0260000 {
+ compatible = "actions,s900-dma";
+ reg = <0x0 0xe0260000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <12>;
+ dma-requests = <46>;
+ clocks = <&clock CLK_DMAC>;
+ };
+
+...
--
2.7.4
^ permalink raw reply related
* [PATCH v1 4/9] arm64: dts: actions: do not merge disable sps node from S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, robh+dt
Cc: cristian.ciocaltea, linux-arm-kernel, linux-actions, devicetree
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for
Actions Semi S700") following error has been observed while booting
Linux on Cubieboard7-lite(based on S700 SoC).
[ 0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for
resource [mem 0xe01b0000-0xe01b0fff]
[ 0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16
This is due to the fact that memory range for "sps" power domain controller
clashes with pinctrl.
This commit disable "sps" to avoid this conflict and let us test DMA and MMC
related changes.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* kept as do not merge.
---
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 2006ad5424fa..0397c5dd3dec 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -220,6 +220,7 @@
compatible = "actions,s700-sps";
reg = <0x0 0xe01b0100 0x0 0x100>;
#power-domain-cells = <1>;
+ status = "disabled";
};
timer: timer@e024c000 {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 5/5] drm/panel: Add ilitek ili9341 driver
From: dillon min @ 2020-05-14 8:11 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Maxime Coquelin, Alexandre TORGUE,
thierry.reding@gmail.com, Sam Ravnborg, Dave Airlie,
Daniel Vetter, Michael Turquette, Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-stm32, Linux ARM, linux-kernel@vger.kernel.org,
open list:DRM PANEL DRIVERS, linux-clk
In-Reply-To: <CACRpkdbcD7i+kNoJ9YP5XXTtLi12=yzW5OBNzet5oRdwPYz=dA@mail.gmail.com>
Hi Linus,
Linus Walleij <linus.walleij@linaro.org> 于2020年5月14日周四 下午10:08写道：
>
> On Thu, May 14, 2020 at 12:22 PM dillon min <dillon.minfei@gmail.com> wrote:
>
> > > > + /* Gamma */
> > > > + mipi_dbi_command(dbi, ILI9341_3GAMMA_EN, 0x00);
> > > > + mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> > > > + mipi_dbi_command(dbi, ILI9341_PGAMMA,
> > > > + 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
> > > > + 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
> > > > + mipi_dbi_command(dbi, ILI9341_NGAMMA,
> > > > + 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
> > > > + 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
> > >
> > > It seems to be copies of the stuff above, but why is there a different
> > > gamma if you use DBI?
>
> > for dbi interface, currently i just copy the code from tiny/ili9341.c.
> > as so many boards use this driver now, like raspberry pi, etc
> > i'm afraid it's will not work after modification. so, just leave the
> > original code there.
>
> OK if you move it to ili9341_config it will be clear which panels
> need this gamma and which panels need another gamma.
>
> I think there should be one ili9341_config for the new st,*
> variant and one for the old DBI variant.
>
Okay, it's a good idea to setup two different configs. ili9341_dbi_config,
ili9341_dpi_config. first for old dbi variant, second for dpi variant.
> > anther question:
> > is there any panel driver have dbi & dpi or dpi & dsi supported? which
> > i mean support
> > two different panel interface in one driver.
> > thanks
>
> Usually you split the driver in three files becuase a driver can
> only list one initcall, and also it makes it modularized.
>
> There is nothing in-tree but look at my branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=ux500-skomer-v5.7-rc1
>
> You see how I split up the s6e63m0 driver in one SPI part
> and one DSI part:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=6c0e1fb5df5fa8fa857dee65f6c0f54d06d158a7
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=cfbf562cc709b53b62f5fbc7fedf176ffa17b088
>
> The overall idea should work the same with DBI.
>
> Yours,
> Linus Walleij
>
> Yours,
> Linus Walleij
Thanks for share, but i thinks it's not suitable to my case. the difference is
for panel s6e63m0
1 spi only for panel register configuration
2 dpi for rgb video data transfer (drm_panel_init(..., DRM_MODE_CONNECTOR_DPI);)
my case:
1 support ili9341 by drm mipi dbi (only spi bus, "3/4 line serial
interface", pdf chap 7.6.1), Ie, raspberry pi + ili9341 + spi
2 support ili9341 by spi & dpi (spi for register set, dpi for rgb
data, "6/16/18 bit parallel rgb interface", pdf chap 7.6.8)
Ie, stm32f429+ili9341+ltdc+spi
these two communication type has no dependency with each other.
DBI has much more difference than DPI & SPI, or DSI & SPI in drm.
drm_mipi_dbi support both panel register configuration and video
data transfer via spi
with or without dc pins.
also the registration to drm is difference, for dbi is
mipi_dbi_dev_init and drm_fbdev_generic_setup
for panel driver is drm_panel_init and drm_panel_add
at soc's view, we can drive ili9341 to work just by drm mipi dbi
(actually it's dbi -> spi bus) without host's lcd or dsi controller
but for some panel can't transfer video data by spi, and with dpi or
dsi interface, must connect to host's lcd or dsi controller.
so, for ilitek-ili9341 , it's use different dts binding drive to
register different client type (dbi, or dpi & spi) to drm.
actually, there is a driver tiny/ili9341.c support this panel by spi
bus only already. but, from Sam's suggestion, should extend this
driver
to support dpi & spi interface, this is the background of panel-ilitek-ili9341.c
thanks.
best regards.
dillon
^ permalink raw reply
* [PATCH net-next] dt-bindings: dp83867: Convert DP83867 to yaml
From: Dan Murphy @ 2020-05-14 15:59 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem
Cc: robh, netdev, linux-kernel, devicetree, Dan Murphy
Convert the dp83867 binding to yaml.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ti,dp83867.txt | 68 ----------
.../devicetree/bindings/net/ti,dp83867.yaml | 127 ++++++++++++++++++
2 files changed, 127 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/ti,dp83867.txt
create mode 100644 Documentation/devicetree/bindings/net/ti,dp83867.yaml
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
deleted file mode 100644
index 44e2a4fab29e..000000000000
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-* Texas Instruments - dp83867 Giga bit ethernet phy
-
-Required properties:
- - reg - The ID number for the phy, usually a small integer
- - ti,rx-internal-delay - RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values. Required only if interface type is
- PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID
- - ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values. Required only if interface type is
- PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID
-
-Note: If the interface type is PHY_INTERFACE_MODE_RGMII the TX/RX clock delays
- will be left at their default values, as set by the PHY's pin strapping.
- The default strapping will use a delay of 2.00 ns. Thus
- PHY_INTERFACE_MODE_RGMII, by default, does not behave as RGMII with no
- internal delay, but as PHY_INTERFACE_MODE_RGMII_ID. The device tree
- should use "rgmii-id" if internal delays are desired as this may be
- changed in future to cause "rgmii" mode to disable delays.
-
-Optional property:
- - ti,min-output-impedance - MAC Interface Impedance control to set
- the programmable output impedance to
- minimum value (35 ohms).
- - ti,max-output-impedance - MAC Interface Impedance control to set
- the programmable output impedance to
- maximum value (70 ohms).
- - ti,dp83867-rxctrl-strap-quirk - This denotes the fact that the
- board has RX_DV/RX_CTRL pin strapped in
- mode 1 or 2. To ensure PHY operation,
- there are specific actions that
- software needs to take when this pin is
- strapped in these modes. See data manual
- for details.
- - ti,clk-output-sel - Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h
- for applicable values. The CLK_OUT pin can also
- be disabled by this property. When omitted, the
- PHY's default will be left as is.
- - ti,sgmii-ref-clock-output-enable - This denotes which
- SGMII configuration is used (4 or 6-wire modes).
- Some MACs work with differential SGMII clock.
- See data manual for details.
-
- - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
- for applicable values (deprecated)
-
- -tx-fifo-depth - As defined in the ethernet-controller.yaml. Values for
- the depth can be found in dt-bindings/net/ti-dp83867.h
- -rx-fifo-depth - As defined in the ethernet-controller.yaml. Values for
- the depth can be found in dt-bindings/net/ti-dp83867.h
-
-Note: ti,min-output-impedance and ti,max-output-impedance are mutually
- exclusive. When both properties are present ti,max-output-impedance
- takes precedence.
-
-Default child nodes are standard Ethernet PHY device
-nodes as described in Documentation/devicetree/bindings/net/phy.txt
-
-Example:
-
- ethernet-phy@0 {
- reg = <0>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
- tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
- };
-
-Datasheet can be found:
-http://www.ti.com/product/DP83867IR/datasheet
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
new file mode 100644
index 000000000000..554dcd7a40a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
+# Copyright (C) 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/ti,dp83867.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: TI DP83867 ethernet PHY
+
+allOf:
+ - $ref: "ethernet-controller.yaml#"
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ The DP83867 device is a robust, low power, fully featured Physical Layer
+ transceiver with integrated PMD sublayers to support 10BASE-Te, 100BASE-TX
+ and 1000BASE-T Ethernet protocols.
+
+ The DP83867 is designed for easy implementation of 10/100/1000 Mbps Ethernet
+ LANs. It interfaces directly to twisted pair media via an external
+ transformer. This device interfaces directly to the MAC layer through the
+ IEEE 802.3 Standard Media Independent Interface (MII), the IEEE 802.3 Gigabit
+ Media Independent Interface (GMII) or Reduced GMII (RGMII).
+
+ Specifications about the charger can be found at:
+ https://www.ti.com/lit/gpn/dp83867ir
+
+properties:
+ reg:
+ maxItems: 1
+
+ ti,min-output-impedance:
+ type: boolean
+ description: |
+ MAC Interface Impedance control to set the programmable output impedance
+ to a minimum value (35 ohms).
+
+ ti,max-output-impedance:
+ type: boolean
+ description: |
+ MAC Interface Impedance control to set the programmable output impedance
+ to a maximum value (70 ohms).
+ Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
+ tx-fifo-depth:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Transmitt FIFO depth see dt-bindings/net/ti-dp83867.h for values
+
+ rx-fifo-depth:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Receive FIFO depth see dt-bindings/net/ti-dp83867.h for values
+
+ ti,clk-output-sel:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h
+ for applicable values. The CLK_OUT pin can also be disabled by this
+ property. When omitted, the PHY's default will be left as is.
+
+ ti,rx-internal-delay:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID.
+
+ ti,tx-internal-delay:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID.
+
+ Note: If the interface type is PHY_INTERFACE_MODE_RGMII the TX/RX clock
+ delays will be left at their default values, as set by the PHY's pin
+ strapping. The default strapping will use a delay of 2.00 ns. Thus
+ PHY_INTERFACE_MODE_RGMII, by default, does not behave as RGMII with no
+ internal delay, but as PHY_INTERFACE_MODE_RGMII_ID. The device tree
+ should use "rgmii-id" if internal delays are desired as this may be
+ changed in future to cause "rgmii" mode to disable delays.
+
+ ti,dp83867-rxctrl-strap-quirk:
+ type: boolean
+ description: |
+ This denotes the fact that the board has RX_DV/RX_CTRL pin strapped in
+ mode 1 or 2. To ensure PHY operation, there are specific actions that
+ software needs to take when this pin is strapped in these modes.
+ See data manual for details.
+
+ ti,sgmii-ref-clock-output-enable:
+ type: boolean
+ description: |
+ This denotes which SGMII configuration is used (4 or 6-wire modes).
+ Some MACs work with differential SGMII clock. See data manual for details.
+
+ ti,fifo-depth:
+ deprecated: true
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable
+ values.
+
+required:
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/net/ti-dp83867.h>
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ rx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,max-output-impedance;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_RCLK>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH 2/2] MAINTAINERS: Add Purism Librem 5 section to the list
From: Martin Kepplinger @ 2020-05-14 15:57 UTC (permalink / raw)
To: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus
Cc: linux-kernel, devicetree, linux-arm-kernel, Martin Kepplinger
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
Add development information for the devicetree files for hardware
by Purism SPC.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0abba1aff1ae..176efec31010 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13775,6 +13775,14 @@ T: git git://linuxtv.org/media_tree.git
F: Documentation/admin-guide/media/pulse8-cec.rst
F: drivers/media/cec/usb/pulse8/
+PURISM LIBREM 5
+M: Purism Kernel Team <kernel@puri.sm>
+S: Supported
+B: https://source.puri.sm/Librem5/linux-next/issues
+T: https://source.puri.sm/Librem5/linux-next
+F: arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
+F: arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
+
PVRUSB2 VIDEO4LINUX DRIVER
M: Mike Isely <isely@pobox.com>
L: pvrusb2@isely.net (subscribers-only)
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-14 15:57 UTC (permalink / raw)
To: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus
Cc: linux-kernel, devicetree, linux-arm-kernel, Martin Kepplinger
From: "Angus Ainslie (Purism)" <angus@akkea.ca>
Add a devicetree description for the Librem 5 phone. The early batches
that have been sold are supported as well as the mass-produced device
available later this year, see https://puri.sm/products/librem-5/
This boots to a working console with working WWAN modem, wifi usdhc,
IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
2 files changed, 1175 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index cd38d04da5a7..342579121f98 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
new file mode 100644
index 000000000000..95c105b4c120
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
@@ -0,0 +1,1174 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2020 Purism SPC
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/input/input.h"
+#include "dt-bindings/pwm/pwm.h"
+#include "dt-bindings/usb/pd.h"
+#include "imx8mq.dtsi"
+
+/ {
+ model = "Purism Librem 5";
+ compatible = "purism,librem5", "fsl,imx8mq";
+
+ backlight_dsi: backlight-dsi {
+ compatible = "led-backlight";
+ leds = <&led_backlight>;
+ brightness-levels = <255>;
+ default-brightness-level = <100>;
+ };
+
+ bm818_codec: sound-wwan-codec {
+ compatible = "broadmobi,bm818", "option,gtm601";
+ #sound-dai-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_keys>, <&pinctrl_hp>;
+
+ hp-det {
+ label = "HP_DET";
+ gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
+ wakeup-source;
+ linux,code = <KEY_HP>;
+ };
+
+ vol-down {
+ label = "VOL_DOWN";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEDOWN>;
+ };
+
+ vol-up {
+ label = "VOL_UP";
+ gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ pwmleds {
+ compatible = "pwm-leds";
+
+ blue {
+ label = "phone:blue:front";
+ max-brightness = <248>;
+ pwms = <&pwm2 0 50000>;
+ };
+
+ green {
+ label = "phone:green:front";
+ max-brightness = <248>;
+ pwms = <&pwm4 0 50000>;
+ };
+
+ red {
+ label = "phone:red:front";
+ max-brightness = <248>;
+ pwms = <&pwm3 0 50000>;
+ };
+ };
+
+ pmic_osc: clock-pmic {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "pmic_osc";
+ };
+
+ reg_audio_pwr_en: regulator-audio-pwr-en {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audiopwr>;
+ regulator-name = "AUDIO_PWR_EN";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ reg_aud_1v8: regulator-audio-v1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "aud_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <®_audio_pwr_en>;
+ };
+
+ reg_gnss: regulator-gnss {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gnsspwr>;
+ regulator-name = "GNSS";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio3 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_hub: regulator-hub {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hub_pwr>;
+ regulator-name = "HUB";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_lcd_1v8: regulator-lcd-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsien>;
+ vin-supply = <®_vdd_1v8>;
+ enable-active-high;
+ gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_lcd_3v4: regulator-lcd-3v4 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v4";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsibiasen>;
+ vin-supply = <®_vsys_3v4>;
+ enable-active-high;
+ gpio = <&gpio1 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_vdd_sen: regulator-vdd-sen {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_sen";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_vdd_3v3: regulator-vdd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_vdd_1v8: regulator-vdd-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_vsys_3v4: regulator-vsys-3v4 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v4";
+ regulator-min-microvolt = <3400000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-always-on;
+ };
+
+ reg_3v3_wifi: regulator-3v3-wifi {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_wifi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "wm8962";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone",
+ "Microphone", "Headset Mic",
+ "Microphone", "Digital Mic",
+ "Speaker", "Speaker";
+ simple-audio-card,routing =
+ "Headphone", "HPOUTL",
+ "Headphone", "HPOUTR",
+ "Speaker", "SPKOUTL",
+ "Speaker", "SPKOUTR",
+ "Headset Mic", "MICBIAS",
+ "IN3R", "Headset Mic",
+ "DMICDAT", "Digital Mic";
+ simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&codec>;
+ clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
+ frame-master;
+ bitclock-master;
+ };
+ };
+
+ sound-wwan {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "MODEM";
+ simple-audio-card,format = "i2s";
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai6>;
+ frame-inversion;
+ };
+
+ telephony_link_master: simple-audio-card,codec {
+ sound-dai = <&bm818_codec>;
+ frame-master;
+ bitclock-master;
+ };
+ };
+
+ vibrator {
+ compatible = "pwm-vibrator";
+ pwms = <&pwm1 0 1000000000 0>;
+ pwm-names = "enable";
+ vcc-supply = <®_vdd_3v3>;
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&clk {
+ assigned-clocks = <&clk IMX8MQ_AUDIO_PLL1>, <&clk IMX8MQ_AUDIO_PLL2>;
+ assigned-clock-rates = <786432000>, <722534400>;
+};
+
+&ddrc {
+ operating-points-v2 = <&ddrc_opp_table>;
+
+ ddrc_opp_table: ddrc-opp-table {
+ compatible = "operating-points-v2";
+
+ opp-25M {
+ opp-hz = /bits/ 64 <25000000>;
+ };
+ opp-100M {
+ opp-hz = /bits/ 64 <100000000>;
+ };
+ opp-800M {
+ opp-hz = /bits/ 64 <800000000>;
+ };
+ };
+};
+
+&dphy {
+ status = "okay";
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nor_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic_5v>;
+
+ pmic-5v {
+ gpio-hog;
+ gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+ input;
+ };
+};
+
+&iomuxc {
+ pinctrl_audiopwr: audiopwrgrp {
+ fsl,pins = <
+ /* AUDIO_POWER_EN_3V3 */
+ MX8MQ_IOMUXC_GPIO1_IO04_GPIO1_IO4 0x83
+ >;
+ };
+
+ pinctrl_bl: blgrp {
+ fsl,pins = <
+ /* BACKLINGE_EN */
+ MX8MQ_IOMUXC_NAND_DQS_GPIO3_IO14 0x83
+ >;
+ };
+
+ pinctrl_charger_in: chargeringrp {
+ fsl,pins = <
+ /* CHRG_INT */
+ MX8MQ_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x80
+ /* CHG_STATUS_B */
+ MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x80
+ >;
+ };
+
+ pinctrl_dsibiasen: dsibiasengrp {
+ fsl,pins = <
+ /* DSI_BIAS_EN */
+ MX8MQ_IOMUXC_ENET_TD1_GPIO1_IO20 0x83
+ >;
+ };
+
+ pinctrl_dsien: dsiengrp {
+ fsl,pins = <
+ /* DSI_EN_3V3 */
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x83
+ >;
+ };
+
+ pinctrl_ecspi1: spi1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x83
+ MX8MQ_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x83
+ MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19
+ MX8MQ_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x83
+ /* SPI_SS1 */
+ MX8MQ_IOMUXC_UART4_RXD_GPIO5_IO28 0x19
+ >;
+ };
+
+ pinctrl_gauge: gaugegrp {
+ fsl,pins = <
+ /* BAT_LOW */
+ MX8MQ_IOMUXC_SAI5_RXC_GPIO3_IO20 0x80
+ >;
+ };
+
+ pinctrl_gnsspwr: gnsspwrgrp {
+ fsl,pins = <
+ /* GPS3V3_EN */
+ MX8MQ_IOMUXC_NAND_DATA06_GPIO3_IO12 0x83
+ >;
+ };
+
+ pinctrl_haptic: hapticgrp {
+ fsl,pins = <
+ /* MOTO */
+ MX8MQ_IOMUXC_SPDIF_EXT_CLK_PWM1_OUT 0x83
+ >;
+ };
+
+ pinctrl_hp: hpgrp {
+ fsl,pins = <
+ /* HEADPHONE_DET_1V8 */
+ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x180
+ >;
+ };
+
+ pinctrl_hub_pwr: hubpwrgrp {
+ fsl,pins = <
+ /* HUB_PWR_3V3_EN */
+ MX8MQ_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x83
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x40000026
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x40000026
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x40000026
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x40000026
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x40000026
+ MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x40000026
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C4_SCL_I2C4_SCL 0x40000026
+ MX8MQ_IOMUXC_I2C4_SDA_I2C4_SDA 0x40000026
+ >;
+ };
+
+ pinctrl_keys: keysgrp {
+ fsl,pins = <
+ /* 4G_WAKE */
+ MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x80
+ /* PWR_KEY */
+ MX8MQ_IOMUXC_NAND_CLE_GPIO3_IO5 0x01C0
+ /* VOL- */
+ MX8MQ_IOMUXC_ENET_MDIO_GPIO1_IO17 0x01C0
+ /* VOL+ */
+ MX8MQ_IOMUXC_ENET_MDC_GPIO1_IO16 0x01C0
+ >;
+ };
+
+ pinctrl_led_b: ledbgrp {
+ fsl,pins = <
+ /* LED_B */
+ MX8MQ_IOMUXC_GPIO1_IO13_PWM2_OUT 0x06
+ >;
+ };
+
+ pinctrl_led_g: ledggrp {
+ fsl,pins = <
+ /* LED_G */
+ MX8MQ_IOMUXC_SAI3_MCLK_PWM4_OUT 0x06
+ >;
+ };
+
+ pinctrl_led_r: ledrgrp {
+ fsl,pins = <
+ /* LED_R */
+ MX8MQ_IOMUXC_SPDIF_TX_PWM3_OUT 0x06
+ >;
+ };
+
+ pinctrl_mag: maggrp {
+ fsl,pins = <
+ /* INT_MAG */
+ MX8MQ_IOMUXC_SAI5_RXD1_GPIO3_IO22 0x80
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ /* PMIC_NINT */
+ MX8MQ_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x80
+ >;
+ };
+
+ pinctrl_pmic_5v: pmic5vgrp {
+ fsl,pins = <
+ /* PMIC_5V */
+ MX8MQ_IOMUXC_GPIO1_IO01_GPIO1_IO1 0x80
+ >;
+ };
+
+ pinctrl_prox: proxgrp {
+ fsl,pins = <
+ /* INT_LIGHT */
+ MX8MQ_IOMUXC_NAND_DATA01_GPIO3_IO7 0x80
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ /* RTC_INT */
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x80
+ >;
+ };
+
+ pinctrl_sai2: sai2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0xd6
+ MX8MQ_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0xd6
+ MX8MQ_IOMUXC_SAI2_MCLK_SAI2_MCLK 0xd6
+ MX8MQ_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0xd6
+ MX8MQ_IOMUXC_SAI2_TXC_SAI2_TX_BCLK 0xd6
+ >;
+ };
+
+ pinctrl_sai6: sai6grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SAI1_RXD5_SAI6_RX_DATA0 0xd6
+ MX8MQ_IOMUXC_SAI1_RXD6_SAI6_RX_SYNC 0xd6
+ MX8MQ_IOMUXC_SAI1_TXD4_SAI6_RX_BCLK 0xd6
+ MX8MQ_IOMUXC_SAI1_TXD5_SAI6_TX_DATA0 0xd6
+ >;
+ };
+
+ pinctrl_tcpc: tcpcgrp {
+ fsl,pins = <
+ /* TCPC_INT */
+ MX8MQ_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x01C0
+ >;
+ };
+
+ pinctrl_typec: typecgrp {
+ fsl,pins = <
+ /* TYPEC_MUX_EN */
+ MX8MQ_IOMUXC_GPIO1_IO11_GPIO1_IO11 0x83
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x49
+ MX8MQ_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x49
+ MX8MQ_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x49
+ MX8MQ_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x49
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
+ MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
+ MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x80
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcf
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcf
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcf
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcf
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcf
+ MX8MQ_IOMUXC_SD2_RESET_B_USDHC2_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ /* nWDOG */
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0x1f
+ >;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <387000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ typec_pd: usb-pd@3f {
+ compatible = "ti,tps6598x";
+ reg = <0x3f>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec>, <&pinctrl_tcpc>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+
+ connector {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_con_hs: endpoint {
+ remote-endpoint = <&typec_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_con_ss: endpoint {
+ remote-endpoint = <&typec_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ pmic: pmic@4b {
+ compatible = "rohm,bd71837";
+ reg = <0x4b>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ clocks = <&pmic_osc>;
+ clock-names = "osc";
+ clock-output-names = "pmic_clk";
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 GPIO_ACTIVE_LOW>;
+ interrupt-names = "irq";
+ rohm,reset-snvs-powered;
+
+ regulators {
+ buck1_reg: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <900000>;
+ rohm,dvs-idle-voltage = <850000>;
+ rohm,dvs-suspend-voltage = <800000>;
+ regulator-always-on;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <1000000>;
+ rohm,dvs-idle-voltage = <900000>;
+ regulator-always-on;
+ };
+
+ buck3_reg: BUCK3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ rohm,dvs-run-voltage = <900000>;
+ regulator-always-on;
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = "buck4";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ rohm,dvs-run-voltage = <1000000>;
+ };
+
+ buck5_reg: BUCK5 {
+ regulator-name = "buck5";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ };
+
+ buck6_reg: BUCK6 {
+ regulator-name = "buck6";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ buck7_reg: BUCK7 {
+ regulator-name = "buck7";
+ regulator-min-microvolt = <1605000>;
+ regulator-max-microvolt = <1995000>;
+ regulator-always-on;
+ };
+
+ buck8_reg: BUCK8 {
+ regulator-name = "buck8";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ };
+
+ ldo1_reg: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ /* leave on for snvs power button */
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ /* leave on for snvs power button */
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ /* VDD_PHY_0V9 - MIPI and HDMI domains */
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ /* VDD_PHY_0V9 - MIPI, HDMI and USB domains */
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo7_reg: LDO7 {
+ /* VDD_PHY_3V3 - USB domain */
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "microcrystal,rv4162";
+ reg = <0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <387000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ magnetometer@1e {
+ compatible = "st,lsm9ds1-magn";
+ reg = <0x1e>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mag>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ vdd-supply = <®_vdd_sen>;
+ vddio-supply = <®_vdd_1v8>;
+ };
+
+ regulator@3e {
+ compatible = "tps65132";
+ reg = <0x3e>;
+ reg_lcd_avdd: outp {
+ regulator-name = "lcd_avdd";
+ vin-supply = <®_lcd_3v4>;
+ };
+
+ reg_lcd_avee: outn {
+ regulator-name = "lcd_avee";
+ vin-supply = <®_lcd_3v4>;
+ };
+ };
+
+ flash@53 {
+ compatible = "lm3560";
+ reg = <0x53>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ flash@0 {
+ reg = <0x0>;
+ flash-timeout-us = <150000>;
+ flash-max-microamp = <320000>;
+ led-max-microamp = <60000>;
+ label = "lm3560:flash";
+ };
+
+ torch@1 {
+ reg = <0x1>;
+ led-max-microamp = <10000>;
+ label = "lm3560:torch";
+ };
+
+ };
+
+ prox@60 {
+ compatible = "vishay,vcnl4040";
+ reg = <0x60>;
+ pinctrl-0 = <&pinctrl_prox>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ accel-gyro@6a {
+ compatible = "st,lsm9ds1-imu";
+ reg = <0x6a>;
+ vdd-supply = <®_vdd_sen>;
+ vddio-supply = <®_vdd_1v8>;
+ mount-matrix = "1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+ };
+};
+
+&i2c3 {
+ clock-frequency = <387000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ codec: wm8962@1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>; // 0x4a is the test address
+ clocks = <&clk IMX8MQ_CLK_SAI2_ROOT>;
+ assigned-clocks = <&clk IMX8MQ_CLK_SAI2>;
+ assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ #sound-dai-cells = <0>;
+ mic-cfg = <0x200>;
+ DCVDD-supply = <®_aud_1v8>;
+ DBVDD-supply = <®_aud_1v8>;
+ AVDD-supply = <®_aud_1v8>;
+ CPVDD-supply = <®_aud_1v8>;
+ MICVDD-supply = <®_aud_1v8>;
+ PLLVDD-supply = <®_aud_1v8>;
+ SPKVDD1-supply = <®_vsys_3v4>;
+ SPKVDD2-supply = <®_vsys_3v4>;
+ gpio-cfg = <
+ 0x0000 /* n/c */
+ 0x0001 /* gpio2, 1: default */
+ 0x0013 /* gpio3, 2: dmicclk */
+ 0x0000 /* n/c, 3: default */
+ 0x8014 /* gpio5, 4: dmic_dat */
+ 0x0000 /* gpio6, 5: default */
+ >;
+ status = "okay";
+ };
+
+ backlight@36 {
+ compatible = "ti,lm36922";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_bl>;
+ reg = <0x36>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enable-gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ vled-supply = <®_vsys_3v4>;
+ ti,ovp-microvolt = <25000000>;
+
+ led_backlight: led@0 {
+ reg = <0>;
+ label = "white:backlight_cluster";
+ linux,default-trigger = "backlight";
+ led-max-microamp = <20000>;
+ };
+ };
+
+ touchscreen@38 {
+ compatible = "edt,edt-ft5506";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ irq-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+ touchscreen-size-x = <720>;
+ touchscreen-size-y = <1440>;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <387000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ bat: fuel-gauge@36 {
+ compatible = "maxim,max17055";
+ interrupt-parent = <&gpio3>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gauge>;
+ reg = <0x36>;
+ maxim,over-heat-temp = <700>;
+ maxim,over-volt = <4500>;
+ maxim,rsns-microohm = <5000>;
+ };
+
+ charger@6a { /* bq25895 */
+ compatible = "ti,bq25890";
+ reg = <0x6a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_charger_in>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ phys = <&usb3_phy0>;
+ ti,battery-regulation-voltage = <4192000>; /* 4.192V */
+ ti,charge-current = <1600000>; /* 1.6A */
+ ti,termination-current = <66000>; /* 66mA */
+ ti,precharge-current = <130000>; /* 130mA */
+ ti,minimum-sys-voltage = <3700000>; /* 3.7V */
+ ti,boost-voltage = <5000000>; /* 5V */
+ ti,boost-max-current = <50000>; /* 50mA */
+ ti,use-vinmin-threshold = <1>; /* enable VINDPM */
+ ti,vinmin-threshold = <3900000>; /* 3.9V */
+ monitored-battery = <&bat>;
+ };
+};
+
+&pgc_gpu {
+ power-supply = <&buck3_reg>;
+};
+
+&pgc_mipi {
+ power-supply = <&ldo5_reg>;
+};
+
+&pgc_vpu {
+ power-supply = <&buck4_reg>;
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_haptic>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led_b>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led_g>;
+ status = "okay";
+};
+
+&pwm4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led_r>;
+ status = "okay";
+};
+
+&sai2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_SAI2>;
+ assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ status = "okay";
+};
+
+&sai6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai6>;
+ assigned-clocks = <&clk IMX8MQ_CLK_SAI6>;
+ assigned-clock-parents = <&clk IMX8MQ_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ fsl,sai-synchronous-rx;
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&snvs_rtc {
+ status = "disabled";
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 { /* TPS - GPS - DEBUG */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+
+ gnss {
+ compatible = "globaltop,pa6h";
+ vcc-supply = <®_gnss>;
+ current-speed = <9600>;
+ };
+};
+
+&uart3 { /* SMC */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&uart4 { /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ vbus-supply = <®_hub>;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dr_mode = "otg";
+ snps,dis_u3_susphy_quirk;
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ typec_hs: endpoint {
+ remote-endpoint = <&usb_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_ss: endpoint {
+ remote-endpoint = <&usb_con_ss>;
+ };
+ };
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ snps,dis_u2_susphy_quirk;
+ snps,dis_u3_susphy_quirk;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ vmmc-supply = <®_vdd_3v3>;
+ power-supply = <®_vdd_1v8>;
+ non-removable;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ bus-width = <4>;
+ vmmc-supply = <®_3v3_wifi>;
+ broken-cd;
+ disable-wp;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v5 0/6] Amazon's Annapurna Labs Alpine v3 device-tree
From: Antoine Tenart @ 2020-05-14 15:22 UTC (permalink / raw)
To: hhhawa, robh+dt, tsahee, arm
Cc: devicetree, benh, linux-kernel, hanochu, dwmw, jonnyc, ronenk,
talel, linux-arm-kernel
In-Reply-To: <20200324104918.29578-1-hhhawa@amazon.com>
[Adding arm-soc]
Hi Hanna,
Sorry for the delay, the series was buried in my mails...
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Arnd, Olof, could you take this series directly as this will be the only
Alpine patches for this release (and for a long time)?
Thanks!
Antoine
Quoting Hanna Hawa (2020-03-24 11:49:12)
> This series organize the Amazon's Annapurna Labs Alpine device tree
> bindings, device tree folder and adds new device tree for Alpine v3.
>
> Changes since v4:
> -----------------
> - Re-order nodes in increasing order.
> - Add disable to UART nodes.
> - Add missing UART nodes (1,2,3)
> - Add comments for GIC/UART
> - Add io-fabric bus, and move uart nodes into it.
> - Fix MSIx range according Alpine function spec
>
> Changes since v3:
> -----------------
> - rebased and retested for tag Linux 5.6-rc2
>
> Changes since v2:
> -----------------
> - Move up a level for DT node without mmio regs.
> - Drop device_type from serial@fd883000 node.
> - Minor change name of PCIe node to: pcie@fbd00000
>
> Changes since v1:
> -----------------
> - Rename al,alpine DT binding to amazon,alpine
> - Rename al folder to be amazon
> - Update maintainers of amazon,alpine DT
> - Add missing alpine-v2 DT binding
> - Fix yaml schemas for alpine-v3-evp.dts:
> - #size-cells:0:0: 0 is not one of [1, 2]
> - arch-timer: interrupts: [[1, 13, 8, 1, 14, 8, 1, 11, 8, 1, 10,
> 8]] is too short
> - Change compatible string of alpine-v3-evp to amazon,al
>
> Hanna Hawa (5):
> dt-bindings: arm: amazon: rename al,alpine DT binding to amazon,al
> arm64: dts: amazon: rename al folder to be amazon
> dt-bindings: arm: amazon: update maintainers of amazon,al DT bindings
> dt-bindings: arm: amazon: add missing alpine-v2 DT binding
> dt-bindings: arm: amazon: add Amazon Annapurna Labs Alpine V3
>
> Ronen Krupnik (1):
> arm64: dts: amazon: add Amazon's Annapurna Labs Alpine v3 support
>
> .../devicetree/bindings/arm/al,alpine.yaml | 21 -
> .../devicetree/bindings/arm/amazon,al.yaml | 33 ++
> MAINTAINERS | 2 +-
> arch/arm64/boot/dts/Makefile | 2 +-
> arch/arm64/boot/dts/{al => amazon}/Makefile | 1 +
> .../boot/dts/{al => amazon}/alpine-v2-evp.dts | 0
> .../boot/dts/{al => amazon}/alpine-v2.dtsi | 0
> arch/arm64/boot/dts/amazon/alpine-v3-evp.dts | 24 ++
> arch/arm64/boot/dts/amazon/alpine-v3.dtsi | 408 ++++++++++++++++++
> 9 files changed, 468 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/al,alpine.yaml
> create mode 100644 Documentation/devicetree/bindings/arm/amazon,al.yaml
> rename arch/arm64/boot/dts/{al => amazon}/Makefile (64%)
> rename arch/arm64/boot/dts/{al => amazon}/alpine-v2-evp.dts (100%)
> rename arch/arm64/boot/dts/{al => amazon}/alpine-v2.dtsi (100%)
> create mode 100644 arch/arm64/boot/dts/amazon/alpine-v3-evp.dts
> create mode 100644 arch/arm64/boot/dts/amazon/alpine-v3.dtsi
>
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-14 15:22 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt,
xuwei5
In-Reply-To: <20200514093617.dwhmqaasc3z5ixy6@rcn-XPS-13-9360>
Hi Ricardo,
On Thu, May 14, 2020 at 11:36:17AM +0200, Ricardo Cañuelo wrote:
> Hi Laurent, thanks for the thorough review. Some comments below:
>
> On jue 14-05-2020 04:54:12, Laurent Pinchart wrote:
> > > +description: |
> > > + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> > > + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> > > + space conversion, S/PDIF, CEC and HDCP. They support RGB input
> > > + interface.
> >
> > I would write the last sentence as "The transmitter input is parallel
> > RGB or YUV data." as YUV is also supported.
>
> Ok.
>
> > > + adi,input-colorspace:
> > > + description: Input color space.
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/string
> > > + - enum: [ rgb, yuv422, yuv444 ]
> >
> > Isn't string implied ? Can't you write
> >
> > adi,input-colorspace:
> > description: Input color space.
> > enum: [ rgb, yuv422, yuv444 ]
>
> example-schema.yaml says that
>
> Vendor specific properties have slightly different schema
> requirements than common properties. They must have at least a type
> definition and 'description'.
>
> However, dt_binding_check doesn't seem to enforce this rule for string
> properties, and I saw a couple of vendor-specific string properties in
> other bindings that don't define the type either, so I'm going to follow
> your suggestion but only for string properties, the rest need a type
> definition.
I'll defer to Rob to tell the law here :-)
> I noticed I can remove the "allOf" keywords from these too.
>
> > > + adi,embedded-sync:
> > > + description:
> > > + The input uses synchronization signals embedded in the data
> > > + stream (similar to BT.656). Defaults to 0 (separate H/V
> > > + synchronization signals).
> > > + allOf:
> > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > + - enum: [ 0, 1 ]
> > > + - default: 0
> >
> > This be a boolean property (it is read as a bool by the driver, the
> > property being absent means false, the property being present means
> > true).
>
> You're completely right.
>
> > > + ports:
> > > + description:
> > > + The ADV7511(W)/13 has two video ports and one audio port. This node
> > > + models their connections as documented in
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > > + Documentation/devicetree/bindings/graph.txt
> > > + type: object
> > > + properties:
> > > + port@0:
> > > + description: Video port for the RGB, YUV or DSI input.
> >
> > s/RGB, YUV or DSI/RGB or YUV/
>
> Ok.
>
> > > +if:
> > > + not:
> > > + properties:
> > > + adi,input-colorspace:
> > > + contains:
> > > + enum: [ rgb, yuv444 ]
> > > + adi,input-clock:
> > > + contains:
> > > + const: 1x
> >
> > As both properties take a single value, I think you can omit
> > "contains:".
>
> I think it's required here, removing it makes the test fail.
I thought the following could work:
if:
not:
properties:
adi,input-colorspace:
enum: [ rgb, yuv444 ]
adi,input-clock:
items:
- const: 1x
But no big deal, contains: is ok too.
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - ports
> > > + - adi,input-depth
> > > + - adi,input-colorspace
> > > + - adi,input-clock
> >
> > Shouldn't the power supplies be required ?
>
> Good question. The original binding is not completely clear on
> this. There's a "Required properties" section at the top that doesn't
> include the supplies, the supplies block for the ADV7511/11w/13 looks
> like a gray area in that regard, while the same block for ADV7533/35 is
> more explicit in that they are required, and they are not listed in the
> "Optional properties" section.
>
> However, most of the DTs that use this binding don't define any
> supplies. And AFAICT from looking at the code, regulator_get() will use
> a dummy regulator and show a warning for every expected regulator that's
> not defined in the DT.
>
> If we want to be more strict and require the definition of all the
> supplies, there will be many more DTs changes in the series, and I'm not
> sure I'll be able to do that in a reasonable amount of time. I'm looking
> at them and it's not always clear which regulators to use or if they are
> even defined.
We can decouple the two though (I think). The bindings should reflect
what we consider right, and the dts files could be fixed on top.
> > > +description: |
> > > + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> > > + compatible with HDMI 1.4 and DVI 1.0. They support color space
> > > + conversion, S/PDIF, CEC and HDCP. They support DSI for input pixels.
> >
> > I would write the last sentence as "The transmitter input is MIPI DSI.".
> >
> > ...
> >
> > > + Disables the interal timing generator. The chip will rely on the
> >
> > s/interal/internal/
> >
> > > + sync signals in the DSI data lanes, rather than generate its own
> >
> > s/generate/generating/
> >
> > ...
> >
> > > + properties:
> > > + port@0:
> > > + description:
> > > + Video port for the RGB, YUV or DSI input. The remote endpoint
> >
> > s/RGB, YUV or //
>
> Ok.
>
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@0 {
> > > + reg = <0>;
> > > + adv7511w_in: endpoint {
> > > + remote-endpoint = <&dpi_out>;
> > > + };
> > > + };
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + adv7511_out: endpoint {
> > > + remote-endpoint = <&hdmi_connector_in>;
> > > + };
> > > + };
> >
> > The name of the two endpoints doesn't match the adv7533. The remote
> > endpoint phandle for port 0 should have dsi in its name.
>
> Oops, thanks for catching these.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/6] soc: ti: omap-prm: Add basic power domain support
From: Tony Lindgren @ 2020-05-14 15:18 UTC (permalink / raw)
To: Tero Kristo
Cc: linux-omap, Andrew F . Davis, Santosh Shilimkar, Suman Anna,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <acb3960a-fbbb-f764-9ee2-191aac2f8323@ti.com>
* Tero Kristo <t-kristo@ti.com> [200514 08:05]:
> On 12/05/2020 23:38, Tony Lindgren wrote:
> > +struct omap_prm_domain {
> > + struct device *dev;
> > + struct omap_prm *prm;
> > + struct generic_pm_domain pd;
> > + void __iomem *pwrstctrl;
> > + void __iomem *pwrstst;
>
> I think the pwrstst is not really used as of now, it is just part of couple
> of dev_dbg prints.
Yes to me it seems the pwrstst only changes later on.
> > +static int omap_prm_domain_power_on(struct generic_pm_domain *domain)
> > +{
> > + struct omap_prm_domain *prmd;
> > + u32 v;
> > +
> > + prmd = genpd_to_prm_domain(domain);
> > + if (!prmd->cap)
> > + return 0;
> > +
> > + dev_dbg(prmd->dev, "%s: %s: old state: pwrstctrl: %08x pwrstst: %08x\n",
> > + __func__, prmd->pd.name, readl_relaxed(prmd->pwrstctrl),
> > + readl_relaxed(prmd->pwrstst));
> > +
> > + if (prmd->pwrstctrl_saved)
> > + v = prmd->pwrstctrl_saved;
> > + else
> > + v = readl_relaxed(prmd->pwrstctrl);
> > +
> > + writel_relaxed(v | OMAP_PRMD_ON_ACTIVE, prmd->pwrstctrl);
> > + dev_dbg(prmd->dev, "%s: %s: new state pwrstctrl: %08x\n",
> > + __func__, prmd->pd.name, readl_relaxed(prmd->pwrstctrl));
>
> Should we wait for the transition to complete here?
Good idea :)
> > + v &= ~PRM_POWERSTATE_MASK;
> > + v |= omap_prm_domain_find_lowest(prmd);
> > +
> > + if (prmd->cap->statechange)
> > + v |= PRM_LOWPOWERSTATECHANGE;
> > + if (prmd->cap->logicretstate)
> > + v &= ~PRM_LOGICRETSTATE;
> > + else
> > + v |= PRM_LOGICRETSTATE;
> > +
> > + writel_relaxed(v, prmd->pwrstctrl);
>
> Should we wait for the transition to complete here?
Would be nice yeah.
> Is any of the following clock handling needed, and if yes, whats its
> purpose?
>
> It looks like this is only used for ABE clkctrl handling on omap4/omap5 (at
> least for now), but afaik, ABE clkctrl is read only so this code would
> effectively do nothing (and potentially just even fail.)
Yeah this seems unnecessary, let's plan on leaving it out. I think the
clocks in the l4_abe dst changes are actually handled by simple-pm-bus,
not this driver, I was just confused :)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v1.1 4/4] dt-bindings: display: bridge: renesas,lvds: Convert binding to YAML
From: Laurent Pinchart @ 2020-05-14 15:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-Renesas, Rob Herring, DRI Development
In-Reply-To: <CAMuHMdXRiP3topBOeLdLhJ9wMBAMFEnLYJPPpdmmdK7TKN4X6g@mail.gmail.com>
Hi Geert,
On Thu, May 14, 2020 at 09:31:53AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 14, 2020 at 1:29 AM Laurent Pinchart wrote:
> > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Acked-by: Maxime Ripard <mripard@kernel.org>
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
>
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> > + #include <dt-bindings/power/r8a7795-sysc.h>
> > +
> > + lvds@feb90000 {
> > + compatible = "renesas,r8a7795-lvds";
> > + reg = <0 0xfeb90000 0 0x14>;
>
> #{address,size}-cells = <1> for examples.
> Applies to all nodes below, too.
Why ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: stm32: enable l3gd20 on stm32429-disco board
From: Alexandre Torgue @ 2020-05-14 15:14 UTC (permalink / raw)
To: dillon min
Cc: Rob Herring, Maxime Coquelin, Mark Brown, p.zabel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel, linux-spi, linux-stm32, Hua Dillon
In-Reply-To: <CAL9mu0KJ0j6Rxf7YjKxVWKz_d+B6vrwqqxJM-fmzG=NonLeDYQ@mail.gmail.com>
On 5/14/20 9:07 AM, dillon min wrote:
> Hi Alexandre,
>
> Alexandre Torgue <alexandre.torgue@st.com> 于2020年5月14日周四 下午10:10写道：
>>
>> Hi Dillon
>>
>> On 5/12/20 9:36 AM, dillon.minfei@gmail.com wrote:
>>> From: dillon min <dillon.minfei@gmail.com>
>>>
>>> L3gd20, st mems motion sensor, 3-axis digital output gyroscope,
>>> connect to stm32f429 via spi5
>>>
>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>>> ---
>>>
>>> Hi Alexandre,
>>>
>>> V2:
>>> 1, insert blank line at stm32f420-disco.dts line 143
>>> 2, add more description about l3gd20 in commit message
>>>
>>> V1:
>>> enable l3gd20 dts binding on stm32f429-disco
>>>
>>> thanks.
>>>
>>> dillon,
>>>
>>> arch/arm/boot/dts/stm32f429-disco.dts | 25 +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
>>> index 30c0f67..1bfb903 100644
>>> --- a/arch/arm/boot/dts/stm32f429-disco.dts
>>> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
>>> @@ -49,6 +49,8 @@
>>> #include "stm32f429.dtsi"
>>> #include "stm32f429-pinctrl.dtsi"
>>> #include <dt-bindings/input/input.h>
>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>> +#include <dt-bindings/gpio/gpio.h>
>>>
>>> / {
>>> model = "STMicroelectronics STM32F429i-DISCO board";
>>> @@ -127,3 +129,26 @@
>>> pinctrl-names = "default";
>>> status = "okay";
>>> };
>>> +
>>> +&spi5 {
>>> + status = "okay";
>>> + pinctrl-0 = <&spi5_pins>;
>>> + pinctrl-names = "default";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + cs-gpios = <&gpioc 1 GPIO_ACTIVE_LOW>;
>>> + dmas = <&dma2 3 2 0x400 0x0>,
>>> + <&dma2 4 2 0x400 0x0>;
>>> + dma-names = "rx", "tx";
>>> +
>>
>> You added this spi5 node in this patch but also in the display series. I
>> will have issue to merge. Even if I could fix it easily, as you are
>> going to resend, the good practice could be to have several patches in
>> one series: one patch for spi5 controller, another for gyro and another
>> for display.
>>
>> And also same remark than Linus did in display series move DMA to soc
>> dtsi file please.
>
> Sure, how about this patch sequence:
> 1 add spi5 dma to soc (stm32f429.dtsi)
> 2 add pin map for spi5 (stm32f4-pinctrl.dtsi)
> 3 add spi5 controller with gyro (stm32f429-disco.dts)
> 4 add spi modification to support gyro (spi-stm32.c)
>
> 5 add ltdc pin map for stm32f429-disco board (stm32f4-pinctrl.dtsi)
> 6 add ilitek-ili9341 dts bindings for disco (stm32f429-disco.dts,
> depends on above step 3)
> 7 add yaml document about ilitek-ili9341 (ilitek,ili9341.yaml)
> 8 add clk changes to support ltdc driver (clk-stm32f4.c)
>
> so, i will combine gyro and display two patches to one patchset next
> time. right ?
>
looks good
> thanks.
>>
>>
>>> + l3gd20: l3gd20@0 {
>>> + compatible = "st,l3gd20-gyro";
>>> + spi-max-frequency = <10000000>;
>>> + st,drdy-int-pin = <2>;
>>> + interrupt-parent = <&gpioa>;
>>> + interrupts = <1 IRQ_TYPE_EDGE_RISING>,
>>> + <2 IRQ_TYPE_EDGE_RISING>;
>>> + reg = <0>;
>>> + status = "okay";
>>> + };
>>> +};
>>>
^ permalink raw reply
* Re: [PATCH v2 02/20] dt-bindings: bus: Add MIPS CDMM controller
From: Rob Herring @ 2020-05-14 15:09 UTC (permalink / raw)
To: Sergey.Semin
Cc: Paul Burton, Thomas Bogendoerfer, linux-kernel, Arnd Bergmann,
Rob Herring, linux-pm, Ralf Baechle, devicetree, Alexey Malahov,
Serge Semin, linux-mips
In-Reply-To: <20200506174238.15385-3-Sergey.Semin@baikalelectronics.ru>
On Wed, 6 May 2020 20:42:20 +0300, wrote:
> From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> It's a Common Device Memory Map controller embedded into the MIPS IP
> cores, which dts node is supposed to have compatible and reg properties.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Lowercase the example hex'es.
> ---
> .../bindings/bus/mti,mips-cdmm.yaml | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Tony Lindgren @ 2020-05-14 15:09 UTC (permalink / raw)
To: Tero Kristo
Cc: linux-omap, Andrew F . Davis, Santosh Shilimkar, Suman Anna,
linux-kernel, linux-arm-kernel, devicetree, Rob Herring
In-Reply-To: <352b8c4d-1233-e208-63ce-c116632546a9@ti.com>
* Tero Kristo <t-kristo@ti.com> [200514 07:40]:
> On 12/05/2020 23:38, Tony Lindgren wrote:
> > The PRM (Power and Reset Module) has registers to enable and disable
> > power domains, so let's update the binding for that.
> >
> > Cc: devicetree@vger.kernel.org
> > Cc: Rob Herring <robh@kernel.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> > --- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> > +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> > @@ -18,12 +18,16 @@ Required properties:
> > (base address and length)
> > Optional properties:
> > +- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
> > - #reset-cells: Should be 1 if the PRM instance in question supports resets.
> > +- clocks: Functional and interface clocks managed by the power domain
> > +- clock-names: Names for the clocks using "fck" and "ick" naming
>
> Whats the purpose of the clocks for PRM? It looks like you are using this
> with ABE domain on omap4/omap5, but why is this needed?
Hmm good point, seems to be just confusion at my end on what should
handle the clocks for the interconnect instances. We can just leave
out the clocks here probably.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 01/20] dt-bindings: power: Convert mti,mips-cpc to DT schema
From: Rob Herring @ 2020-05-14 15:09 UTC (permalink / raw)
To: Sergey.Semin
Cc: devicetree, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
linux-kernel, Paul Burton, linux-mips, Arnd Bergmann, Rob Herring,
linux-pm, Ralf Baechle
In-Reply-To: <20200506174238.15385-2-Sergey.Semin@baikalelectronics.ru>
On Wed, 6 May 2020 20:42:19 +0300, wrote:
> From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> It's a Cluster Power Controller embedded into the MIPS IP cores.
> Currently the corresponding dts node is supposed to have compatible
> and reg properties.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-pm@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Reword the changelog summary - use shorter version.
> - Lowercase the example hex'es.
> ---
> .../bindings/power/mti,mips-cpc.txt | 8 -----
> .../bindings/power/mti,mips-cpc.yaml | 35 +++++++++++++++++++
> 2 files changed, 35 insertions(+), 8 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.txt
> create mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 6/8] dt-bindings: reset: s700: Add binding constants for mmc
From: Rob Herring @ 2020-05-14 15:08 UTC (permalink / raw)
To: Amit Singh Tomar
Cc: manivannan.sadhasivam, devicetree, andre.przywara, linux-actions,
robh+dt, cristian.ciocaltea, linux-arm-kernel, afaerber
In-Reply-To: <1588761371-9078-7-git-send-email-amittomer25@gmail.com>
On Wed, 6 May 2020 16:06:08 +0530, Amit Singh Tomar wrote:
> This commit adds device tree binding reset constants for mmc controller
> present on Actions S700 Soc.
>
> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
> ---
> include/dt-bindings/reset/actions,s700-reset.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: stm32: enable l3gd20 on stm32429-disco board
From: dillon min @ 2020-05-14 7:07 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Rob Herring, Maxime Coquelin, Mark Brown, p.zabel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel, linux-spi, linux-stm32, Hua Dillon
In-Reply-To: <da9fbb80-571d-1217-4028-e413a0c7db84@st.com>
Hi Alexandre,
Alexandre Torgue <alexandre.torgue@st.com> 于2020年5月14日周四 下午10:10写道：
>
> Hi Dillon
>
> On 5/12/20 9:36 AM, dillon.minfei@gmail.com wrote:
> > From: dillon min <dillon.minfei@gmail.com>
> >
> > L3gd20, st mems motion sensor, 3-axis digital output gyroscope,
> > connect to stm32f429 via spi5
> >
> > Signed-off-by: dillon min <dillon.minfei@gmail.com>
> > ---
> >
> > Hi Alexandre,
> >
> > V2:
> > 1, insert blank line at stm32f420-disco.dts line 143
> > 2, add more description about l3gd20 in commit message
> >
> > V1:
> > enable l3gd20 dts binding on stm32f429-disco
> >
> > thanks.
> >
> > dillon,
> >
> > arch/arm/boot/dts/stm32f429-disco.dts | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
> > index 30c0f67..1bfb903 100644
> > --- a/arch/arm/boot/dts/stm32f429-disco.dts
> > +++ b/arch/arm/boot/dts/stm32f429-disco.dts
> > @@ -49,6 +49,8 @@
> > #include "stm32f429.dtsi"
> > #include "stm32f429-pinctrl.dtsi"
> > #include <dt-bindings/input/input.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +#include <dt-bindings/gpio/gpio.h>
> >
> > / {
> > model = "STMicroelectronics STM32F429i-DISCO board";
> > @@ -127,3 +129,26 @@
> > pinctrl-names = "default";
> > status = "okay";
> > };
> > +
> > +&spi5 {
> > + status = "okay";
> > + pinctrl-0 = <&spi5_pins>;
> > + pinctrl-names = "default";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cs-gpios = <&gpioc 1 GPIO_ACTIVE_LOW>;
> > + dmas = <&dma2 3 2 0x400 0x0>,
> > + <&dma2 4 2 0x400 0x0>;
> > + dma-names = "rx", "tx";
> > +
>
> You added this spi5 node in this patch but also in the display series. I
> will have issue to merge. Even if I could fix it easily, as you are
> going to resend, the good practice could be to have several patches in
> one series: one patch for spi5 controller, another for gyro and another
> for display.
>
> And also same remark than Linus did in display series move DMA to soc
> dtsi file please.
Sure, how about this patch sequence:
1 add spi5 dma to soc (stm32f429.dtsi)
2 add pin map for spi5 (stm32f4-pinctrl.dtsi)
3 add spi5 controller with gyro (stm32f429-disco.dts)
4 add spi modification to support gyro (spi-stm32.c)
5 add ltdc pin map for stm32f429-disco board (stm32f4-pinctrl.dtsi)
6 add ilitek-ili9341 dts bindings for disco (stm32f429-disco.dts,
depends on above step 3)
7 add yaml document about ilitek-ili9341 (ilitek,ili9341.yaml)
8 add clk changes to support ltdc driver (clk-stm32f4.c)
so, i will combine gyro and display two patches to one patchset next
time. right ?
thanks.
>
>
> > + l3gd20: l3gd20@0 {
> > + compatible = "st,l3gd20-gyro";
> > + spi-max-frequency = <10000000>;
> > + st,drdy-int-pin = <2>;
> > + interrupt-parent = <&gpioa>;
> > + interrupts = <1 IRQ_TYPE_EDGE_RISING>,
> > + <2 IRQ_TYPE_EDGE_RISING>;
> > + reg = <0>;
> > + status = "okay";
> > + };
> > +};
> >
^ permalink raw reply
* Re: [PATCH v4 07/10] dt-bindings: memory-controller: add STM32 FMC2 EBI controller documentation
From: Rob Herring @ 2020-05-14 15:07 UTC (permalink / raw)
To: Christophe Kerello
Cc: miquel.raynal, richard, vigneshr, mark.rutland, gregkh,
boris.brezillon, linux-mtd, linux-kernel, linux-stm32, devicetree,
marex
In-Reply-To: <1588756279-17289-8-git-send-email-christophe.kerello@st.com>
On Wed, May 06, 2020 at 11:11:16AM +0200, Christophe Kerello wrote:
> This patch adds the documentation of the device tree bindings for the STM32
> FMC2 EBI controller.
>
> Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
> ---
> Changes in v4:
> - fix filename: st,stm32-fmc2-ebi.yaml
>
> Changes in v3:
> - pattern name has been modified
> - vendor properties have been modified
> - s/_/-/
> - add unit suffix (-ns) on timing properties
>
> .../memory-controllers/st,stm32-fmc2-ebi.yaml | 261 +++++++++++++++++++++
> 1 file changed, 261 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
> new file mode 100644
> index 0000000..bf130c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
> @@ -0,0 +1,261 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings
> +
> +description: |
> + The FMC2 functional block makes the interface with: synchronous and
> + asynchronous static devices (such as PSNOR, PSRAM or other memory-mapped
> + peripherals) and NAND flash memories.
> + Its main purposes are:
> + - to translate AXI transactions into the appropriate external device
> + protocol
> + - to meet the access time requirements of the external devices
> + All external devices share the addresses, data and control signals with the
> + controller. Each external device is accessed by means of a unique Chip
> + Select. The FMC2 performs only one access at a time to an external device.
> +
> +maintainers:
> + - Christophe Kerello <christophe.kerello@st.com>
> +
> +properties:
> + compatible:
> + const: st,stm32mp1-fmc2-ebi
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 1
> +
> + ranges:
> + description: |
> + Reflects the memory layout with four integer values per bank. Format:
> + <bank-number> 0 <address of the bank> <size>
> +
> +patternProperties:
> + "^.*@[0-4],[a-f0-9]+$":
> + type: object
> +
> + properties:
> + reg:
> + description: Bank number, base address and size of the device.
> +
> + st,fmc2-ebi-cs-transaction-type:
> + description: |
> + Select one of the transactions type supported
Indent should be 2 more than 'description'.
> + 0: Asynchronous mode 1 SRAM/FRAM.
> + 1: Asynchronous mode 1 PSRAM.
> + 2: Asynchronous mode A SRAM/FRAM.
> + 3: Asynchronous mode A PSRAM.
> + 4: Asynchronous mode 2 NOR.
> + 5: Asynchronous mode B NOR.
> + 6: Asynchronous mode C NOR.
> + 7: Asynchronous mode D NOR.
> + 8: Synchronous read synchronous write PSRAM.
> + 9: Synchronous read asynchronous write PSRAM.
> + 10: Synchronous read synchronous write NOR.
> + 11: Synchronous read asynchronous write NOR.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 11
> +
> + st,fmc2-ebi-cs-cclk-enable:
> + description: Continuous clock enable (first bank must be configured
> + in synchronous mode). The FMC_CLK is generated continuously
> + during asynchronous and synchronous access. By default, the
> + FMC_CLK is only generated during synchronous access.
Indent 2 more than 'description'. You can run this through yaml-format
in dtschema repo and it will re-flow everything for you.
With these fixed,
Reviewed-by: Rob Herring <robh@kernel.org>
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-mux-enable:
> + description: Address/Data multiplexed on databus (valid only with
> + NOR and PSRAM transactions type). By default, Address/Data
> + are not multiplexed.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-buswidth:
> + description: Data bus width
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 8, 16 ]
> + default: 16
> +
> + st,fmc2-ebi-cs-waitpol-high:
> + description: Wait signal polarity (NWAIT signal active high).
> + By default, NWAIT is active low.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-waitcfg-enable:
> + description: The NWAIT signal indicates wheither the data from the
> + device are valid or if a wait state must be inserted when
> + accessing the device in synchronous mode. By default, the
> + NWAIT signal is active one data cycle before wait state.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-wait-enable:
> + description: The NWAIT signal is enabled (its level is taken into
> + account after the programmed latency period to insert wait
> + states if asserted). By default, the NWAIT signal is
> + disabled.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-asyncwait-enable:
> + description: The NWAIT signal is taken into account during asynchronous
> + transactions. By default, the NWAIT signal is not taken
> + into account during asynchronous transactions.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + st,fmc2-ebi-cs-cpsize:
> + description: CRAM page size. The controller splits the burst access
> + when the memory page is reached. By default, no burst
> + split when crossing page boundary.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 128, 256, 512, 1024 ]
> + default: 0
> +
> + st,fmc2-ebi-cs-byte-lane-setup-ns:
> + description: This property configures the byte lane setup timing
> + defined in nanoseconds from NBLx low to Chip Select NEx
> + low.
> +
> + st,fmc2-ebi-cs-address-setup-ns:
> + description: This property defines the duration of the address setup
> + phase in nanoseconds used for asynchronous read/write
> + transactions.
> +
> + st,fmc2-ebi-cs-address-hold-ns:
> + description: This property defines the duration of the address hold
> + phase in nanoseconds used for asynchronous multiplexed
> + read/write transactions.
> +
> + st,fmc2-ebi-cs-data-setup-ns:
> + description: This property defines the duration of the data setup phase
> + in nanoseconds used for asynchronous read/write
> + transactions.
> +
> + st,fmc2-ebi-cs-bus-turnaround-ns:
> + description: This property defines the delay in nanoseconds between the
> + end of current read/write transaction and the next
> + transaction.
> +
> + st,fmc2-ebi-cs-data-hold-ns:
> + description: This property defines the duration of the data hold phase
> + in nanoseconds used for asynchronous read/write
> + transactions.
> +
> + st,fmc2-ebi-cs-clk-period-ns:
> + description: This property defines the FMC_CLK output signal period in
> + nanoseconds.
> +
> + st,fmc2-ebi-cs-data-latency-ns:
> + description: This property defines the data latency before reading or
> + writing the first data in nanoseconds.
> +
> + st,fmc2_ebi-cs-write-address-setup-ns:
> + description: This property defines the duration of the address setup
> + phase in nanoseconds used for asynchronous write
> + transactions.
> +
> + st,fmc2-ebi-cs-write-address-hold-ns:
> + description: This property defines the duration of the address hold
> + phase in nanoseconds used for asynchronous multiplexed
> + write transactions.
> +
> + st,fmc2-ebi-cs-write-data-setup-ns:
> + description: This property defines the duration of the data setup
> + phase in nanoseconds used for asynchronous write
> + transactions.
> +
> + st,fmc2-ebi-cs-write-bus-turnaround-ns:
> + description: This property defines the delay between the end of current
> + write transaction and the next transaction in nanoseconds.
> +
> + st,fmc2-ebi-cs-write-data-hold-ns:
> + description: This property defines the duration of the data hold phase
> + in nanoseconds used for asynchronous write transactions.
> +
> + st,fmc2-ebi-cs-max-low-pulse-ns:
> + description: This property defines the maximum chip select low pulse
> + duration in nanoseconds for synchronous transactions. When
> + this timing reaches 0, the controller splits the current
> + access, toggles NE to allow device refresh and restarts a
> + new access.
> +
> + required:
> + - reg
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - clocks
> + - ranges
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/stm32mp1-clks.h>
> + #include <dt-bindings/reset/stm32mp1-resets.h>
> + memory-controller@58002000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "st,stm32mp1-fmc2-ebi";
> + reg = <0x58002000 0x1000>;
> + clocks = <&rcc FMC_K>;
> + resets = <&rcc FMC_R>;
> +
> + ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */
> + <1 0 0x64000000 0x04000000>, /* EBI CS 2 */
> + <2 0 0x68000000 0x04000000>, /* EBI CS 3 */
> + <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */
> + <4 0 0x80000000 0x10000000>; /* NAND */
> +
> + psram@0,0 {
> + compatible = "mtd-ram";
> + reg = <0 0x00000000 0x100000>;
> + bank-width = <2>;
> +
> + st,fmc2-ebi-cs-transaction-type = <1>;
> + st,fmc2-ebi-cs-address-setup-ns = <60>;
> + st,fmc2-ebi-cs-data-setup-ns = <30>;
> + st,fmc2-ebi-cs-bus-turnaround-ns = <5>;
> + };
> +
> + nand-controller@4,0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32mp15-fmc2";
> + reg = <4 0x00000000 0x1000>,
> + <4 0x08010000 0x1000>,
> + <4 0x08020000 0x1000>,
> + <4 0x01000000 0x1000>,
> + <4 0x09010000 0x1000>,
> + <4 0x09020000 0x1000>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>,
> + <&mdma1 20 0x2 0x12000a08 0x0 0x0>,
> + <&mdma1 21 0x2 0x12000a0a 0x0 0x0>;
> + dma-names = "tx", "rx", "ecc";
> +
> + nand@0 {
> + reg = <0>;
> + nand-on-flash-bbt;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> + };
> +
> +...
> --
> 1.9.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox