* [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: devicetree, linux-actions, linux-arm-kernel, cristian.ciocaltea
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 3/9] clk: actions: Add MMC clock-register reset bits
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam, sboyd
Cc: linux-actions, linux-arm-kernel, cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
This commit adds reset bits needed for MMC clock registers present
on Actions S700 SoC.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes from RFC:
* No change.
---
drivers/clk/actions/owl-s700.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
index a2f34d13fb54..cd60eca7727d 100644
--- a/drivers/clk/actions/owl-s700.c
+++ b/drivers/clk/actions/owl-s700.c
@@ -577,6 +577,9 @@ static const struct owl_reset_map s700_resets[] = {
[RESET_DSI] = { CMU_DEVRST0, BIT(2) },
[RESET_CSI] = { CMU_DEVRST0, BIT(13) },
[RESET_SI] = { CMU_DEVRST0, BIT(14) },
+ [RESET_SD0] = { CMU_DEVRST0, BIT(22) },
+ [RESET_SD1] = { CMU_DEVRST0, BIT(23) },
+ [RESET_SD2] = { CMU_DEVRST0, BIT(24) },
[RESET_I2C0] = { CMU_DEVRST1, BIT(0) },
[RESET_I2C1] = { CMU_DEVRST1, BIT(1) },
[RESET_I2C2] = { CMU_DEVRST1, BIT(2) },
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 2/9] dmaengine: Actions: Add support for S700 DMA engine
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, vkoul, afaerber, manivannan.sadhasivam
Cc: dmaengine, dan.j.williams, linux-actions, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
DMA controller present on S700 SoC is compatible with the one on S900
(as most of registers are same), but it has different DMA descriptor
structure where registers "fcnt" and "ctrlb" uses different encoding.
For instance, on S900 "fcnt" starts at offset 0x0c and uses upper 12
bits whereas on S700, it starts at offset 0x1c and uses lower 12 bits.
This commit adds support for DMA controller present on S700.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* Added accessor function to get the frame lenght.
* Removed the SoC specific check in IRQ routine.
---
drivers/dma/owl-dma.c | 50 +++++++++++++++++++++++++++++++++++++-------------
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index b0d80a2fa383..afa6c6f43d26 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -134,6 +134,11 @@ enum owl_dmadesc_offsets {
OWL_DMADESC_SIZE
};
+enum owl_dma_id {
+ S900_DMA,
+ S700_DMA,
+};
+
/**
* struct owl_dma_lli - Link list for dma transfer
* @hw: hardware link list
@@ -200,6 +205,7 @@ struct owl_dma_vchan {
* @pchans: array of data for the physical channels
* @nr_vchans: the number of physical channels
* @vchans: array of data for the physical channels
+ * @devid: device id based on OWL SoC
*/
struct owl_dma {
struct dma_device dma;
@@ -214,6 +220,7 @@ struct owl_dma {
unsigned int nr_vchans;
struct owl_dma_vchan *vchans;
+ enum owl_dma_id devid;
};
static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
@@ -308,6 +315,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
return ctl;
}
+static inline u32 llc_hw_flen(struct owl_dma_lli *lli)
+{
+ return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
+}
+
static void owl_dma_free_lli(struct owl_dma *od,
struct owl_dma_lli *lli)
{
@@ -354,6 +366,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
+ struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -409,8 +422,14 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
lli->hw[OWL_DMADESC_DADDR] = dst;
lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
- lli->hw[OWL_DMADESC_FLEN] = len | 1 << 20;
- lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+
+ if (od->devid == S700_DMA) {
+ lli->hw[OWL_DMADESC_FLEN] = len;
+ lli->hw[OWL_DMADESC_CTRLB] = 1 | ctrlb;
+ } else {
+ lli->hw[OWL_DMADESC_FLEN] = len | 1 << 20;
+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+ }
return 0;
}
@@ -572,7 +591,7 @@ static irqreturn_t owl_dma_interrupt(int irq, void *dev_id)
global_irq_pending = dma_readl(od, OWL_DMA_IRQ_PD0);
- if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
+ if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
dev_dbg(od->dma.dev,
"global and channel IRQ pending match err\n");
@@ -741,9 +760,9 @@ static u32 owl_dma_getbytes_chan(struct owl_dma_vchan *vchan)
list_for_each_entry(lli, &txd->lli_list, node) {
/* Start from the next active node */
if (lli->phys == next_lli_phy) {
- list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw[OWL_DMADESC_FLEN] &
- GENMASK(19, 0);
+ list_for_each_entry(lli, &txd->lli_list,
+ node)
+ bytes += llc_hw_flen(lli);
break;
}
}
@@ -774,7 +793,7 @@ static enum dma_status owl_dma_tx_status(struct dma_chan *chan,
if (vd) {
txd = to_owl_txd(&vd->tx);
list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
+ bytes += llc_hw_flen(lli);
} else {
bytes = owl_dma_getbytes_chan(vchan);
}
@@ -1031,11 +1050,20 @@ static struct dma_chan *owl_dma_of_xlate(struct of_phandle_args *dma_spec,
return chan;
}
+static const struct of_device_id owl_dma_match[] = {
+ { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
+ { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, owl_dma_match);
+
static int owl_dma_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct owl_dma *od;
int ret, i, nr_channels, nr_requests;
+ const struct of_device_id *of_id =
+ of_match_device(owl_dma_match, &pdev->dev);
od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
if (!od)
@@ -1060,6 +1088,8 @@ static int owl_dma_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
nr_channels, nr_requests);
+ od->devid = (enum owl_dma_id)of_id->data;
+
od->nr_pchans = nr_channels;
od->nr_vchans = nr_requests;
@@ -1192,12 +1222,6 @@ static int owl_dma_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id owl_dma_match[] = {
- { .compatible = "actions,s900-dma", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, owl_dma_match);
-
static struct platform_driver owl_dma_driver = {
.probe = owl_dma_probe,
.remove = owl_dma_remove,
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 1/9] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, vkoul, afaerber, manivannan.sadhasivam
Cc: dmaengine, dan.j.williams, linux-actions, linux-arm-kernel,
cristian.ciocaltea
In-Reply-To: <1589472657-3930-1-git-send-email-amittomer25@gmail.com>
At the moment, Driver uses bit fields to describe registers of the DMA
descriptor structure that makes it less portable and maintainable, and
Andre suugested(and even sketched important bits for it) to make use of
array to describe this DMA descriptors instead. It gives the flexibility
while extending support for other platform such as Actions S700.
This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
uses array to describe DMA descriptor.
Suggested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
---
Changes since RFC:
* No change from RFC.
---
drivers/dma/owl-dma.c | 77 ++++++++++++++++++++++-----------------------------
1 file changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index c683051257fd..b0d80a2fa383 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -120,30 +120,18 @@
#define BIT_FIELD(val, width, shift, newshift) \
((((val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
-/**
- * struct owl_dma_lli_hw - Hardware link list for dma transfer
- * @next_lli: physical address of the next link list
- * @saddr: source physical address
- * @daddr: destination physical address
- * @flen: frame length
- * @fcnt: frame count
- * @src_stride: source stride
- * @dst_stride: destination stride
- * @ctrla: dma_mode and linklist ctrl config
- * @ctrlb: interrupt config
- * @const_num: data for constant fill
- */
-struct owl_dma_lli_hw {
- u32 next_lli;
- u32 saddr;
- u32 daddr;
- u32 flen:20;
- u32 fcnt:12;
- u32 src_stride;
- u32 dst_stride;
- u32 ctrla;
- u32 ctrlb;
- u32 const_num;
+/* Describe DMA descriptor, hardware link list for dma transfer */
+enum owl_dmadesc_offsets {
+ OWL_DMADESC_NEXT_LLI = 0,
+ OWL_DMADESC_SADDR,
+ OWL_DMADESC_DADDR,
+ OWL_DMADESC_FLEN,
+ OWL_DMADESC_SRC_STRIDE,
+ OWL_DMADESC_DST_STRIDE,
+ OWL_DMADESC_CTRLA,
+ OWL_DMADESC_CTRLB,
+ OWL_DMADESC_CONST_NUM,
+ OWL_DMADESC_SIZE
};
/**
@@ -153,7 +141,7 @@ struct owl_dma_lli_hw {
* @node: node for txd's lli_list
*/
struct owl_dma_lli {
- struct owl_dma_lli_hw hw;
+ u32 hw[OWL_DMADESC_SIZE];
dma_addr_t phys;
struct list_head node;
};
@@ -351,8 +339,9 @@ static struct owl_dma_lli *owl_dma_add_lli(struct owl_dma_txd *txd,
list_add_tail(&next->node, &txd->lli_list);
if (prev) {
- prev->hw.next_lli = next->phys;
- prev->hw.ctrla |= llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
+ prev->hw[OWL_DMADESC_NEXT_LLI] = next->phys;
+ prev->hw[OWL_DMADESC_CTRLA] |=
+ llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
}
return next;
@@ -365,8 +354,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
- struct owl_dma_lli_hw *hw = &lli->hw;
- u32 mode;
+ u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -407,22 +395,22 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
return -EINVAL;
}
- hw->next_lli = 0; /* One link list by default */
- hw->saddr = src;
- hw->daddr = dst;
-
- hw->fcnt = 1; /* Frame count fixed as 1 */
- hw->flen = len; /* Max frame length is 1MB */
- hw->src_stride = 0;
- hw->dst_stride = 0;
- hw->ctrla = llc_hw_ctrla(mode,
- OWL_DMA_LLC_SAV_LOAD_NEXT |
- OWL_DMA_LLC_DAV_LOAD_NEXT);
+ lli->hw[OWL_DMADESC_CTRLA] = llc_hw_ctrla(mode,
+ OWL_DMA_LLC_SAV_LOAD_NEXT |
+ OWL_DMA_LLC_DAV_LOAD_NEXT);
if (is_cyclic)
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
else
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+
+ lli->hw[OWL_DMADESC_NEXT_LLI] = 0;
+ lli->hw[OWL_DMADESC_SADDR] = src;
+ lli->hw[OWL_DMADESC_DADDR] = dst;
+ lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
+ lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
+ lli->hw[OWL_DMADESC_FLEN] = len | 1 << 20;
+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
return 0;
}
@@ -754,7 +742,8 @@ static u32 owl_dma_getbytes_chan(struct owl_dma_vchan *vchan)
/* Start from the next active node */
if (lli->phys == next_lli_phy) {
list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw.flen;
+ bytes += lli->hw[OWL_DMADESC_FLEN] &
+ GENMASK(19, 0);
break;
}
}
@@ -785,7 +774,7 @@ static enum dma_status owl_dma_tx_status(struct dma_chan *chan,
if (vd) {
txd = to_owl_txd(&vd->tx);
list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw.flen;
+ bytes += lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
} else {
bytes = owl_dma_getbytes_chan(vchan);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 0/9] Add MMC and DMA support for Actions S700
From: Amit Singh Tomar @ 2020-05-14 16:10 UTC (permalink / raw)
To: andre.przywara, afaerber, manivannan.sadhasivam
Cc: linux-actions, linux-arm-kernel, cristian.ciocaltea
This series(v1) have following changes from the previous series.
New patch(5/8) has been introduced that converts dma dt-binding
for Actions OWL SoC from text format to yaml file.
For patch(2/8) new accessor function is added to get the frame
lenght which is common to both S900 and S700. Apart from it
SoC check is removed from irq routine as it is not needed.
Patch(4/8) which is an hack to prove our DMA and MMC works
for S700 is now sent as *do not merge* patch.
DMA is tested using dmatest with follwoing result:
root@ubuntu:~# echo dma0chan1 > /sys/module/dmatest/parameters/channel
root@ubuntu:~# echo 2000 > /sys/module/dmatest/parameters/timeout
root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/iterations
root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/run
root@ubuntu:~# dmesg | tail
[ 303.362586] dmatest: Added 1 threads using dma0chan1
[ 317.258658] dmatest: Started 1 threads using dma0chan1
[ 317.259397] dmatest: dma0chan1-copy0: summary 1 tests, 0 failures 16129.03 iops 32258 KB/s (0)
----------------------------------------------------------------
The intention of previous series(RFC) is to enable uSD and DMA support for
Cubieboard7 based on Actions S700 SoC, and on the way we found that
it requires changes in dmaengine present on S700 as its different
from what is present on S900.
Patch(1/8) does provide a new way to describe DMA descriptor, idea is
to remove the bit-fields as its less maintainable. It is only build
tested and it would be great if this can be tested on S900 based
hardware.
Patch(2/8) adds S700 DMA engine support, there is new compatible
string added for it, which means a changed bindings needed to submitted
for this. I would plan to send it later the converted "owl-dma.yaml".
Patch(4/8) disables the sps node as its memory range is conflicting
pinctrl node and results in pinctrl proble failure.
Rest of patches in the series adds DMA/MMC nodes for S700
alone with binding constants and enables the uSD for Cubieboard7.
This whole series is tested, by building/compiling Kernel on
Cubieboard7-lite which was *almost* successful (OOM kicked in,
while Linking due to less RAM present on hardware).
Following is the mmc speed :
ubuntu@ubuntu:~$ sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 1310 MB in 2.00 seconds = 655.15 MB/sec
Timing buffered disk reads: 62 MB in 3.05 seconds = 20.30 MB/sec
Amit Singh Tomar (9):
dmaengine: Actions: get rid of bit fields from dma descriptor
dmaengine: Actions: Add support for S700 DMA engine
clk: actions: Add MMC clock-register reset bits
arm64: dts: actions: do not merge disable sps node from S700
dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
arm64: dts: actions: Add DMA Controller for S700
dt-bindings: reset: s700: Add binding constants for mmc
arm64: dts: actions: Add MMC controller support for S700
arm64: dts: actions: Add uSD support for Cubieboard7
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 ---------
Documentation/devicetree/bindings/dma/owl-dma.yaml | 84 +++++++++++++++
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 48 +++++++++
drivers/clk/actions/owl-s700.c | 3 +
drivers/dma/owl-dma.c | 117 ++++++++++++---------
include/dt-bindings/reset/actions,s700-reset.h | 3 +
7 files changed, 244 insertions(+), 99 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* 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: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre TORGUE, Dave Airlie, Michael Turquette,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-clk, Stephen Boyd, Rob Herring, thierry.reding@gmail.com,
Maxime Coquelin, Daniel Vetter, Sam Ravnborg, linux-stm32,
Linux ARM
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v5.8 #1
From: Alexandre Torgue @ 2020-05-14 16:07 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, Kevin Hilman, SoC Team, arm-soc,
linux-arm-kernel@lists.infradead.org
Cc: Alexandre TORGUE, Maxime Coquelin
Hi Arnd, Olof and Kevin,
Please consider this first round of STM32 DT updates for v5.8.
Main changes concern stm32mp15 MPU soc including 3 new boards: lxa-mc1,
Stinger96 and IoT Box board and a major rework of Avenger96 board to
support the new revision board based on DHCOR SOM.
Google doc has been updated.
Regards
Alex
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
tags/stm32-dt-for-v5.8-1
for you to fetch changes up to 7e76f82acd9e12fe7765d5d8c200b37787c994e4:
ARM: dts: stm32: Split Avenger96 into DHCOR SoM and Avenger96 board
(2020-05-14 16:24:54 +0200)
----------------------------------------------------------------
STM32 DT updates for v5.8, round 1
Highlights:
----------
MCU part:
-fix a typo for DAC io-channel-cells on f429 and h743
MPU part:
-Generic:
-Bump tp PSCI 1.0
-Fix a typo for DAC io-channel-cells
-Add M4 pdds for deep sleep mode
-Add I2C fatmode plus support
-Add new Octavio lxa-mc1 board based on OSDMP15x SiP
-Add new Stinger96 board support. It is a 96Boards IoT Extended board
based on stm32mp157a SoC. Some figures: 256MB DDR, 125MB and flash,
Onboard BG96 modem...
-Add IoT Box board support based on stinger96 board + Wifi/BT, CCS811
VOC sensor, 2 digitals microphones ...
-DH:
-Adapt dhcom-som and dhcom-pdk2 dts(i) files to STM32MP15 SoC diversity
-Add GPIO led and GPIO keys support on PDK2 board
-AV96:
-Major rework to support official avenger96 board based on DHCOR SOM.
-Prototype board is no more supported
----------------------------------------------------------------
Ahmad Fatoum (8):
ARM: dts: stm32: enable stm32mp157's &gpu by default
ARM: dts: stm32: preset stm32mp15x video #address- and #size-cells
ARM: dts: stm32: remove now redundant STM32MP15x video cell sizes
ARM: dts: stm32: use uniform label names for sleep pinctrl phandles
ARM: dts: stm32: use uniform node names for sleep pinctrl groups
dt-bindings: add vendor prefix for Linux Automation GmbH
ARM: dts: stm32: add STM32MP1-based Linux Automation MC-1 board
dt-bindings: arm: stm32: document lxa,stm32mp157c-mc1 compatible
Alain Volmat (2):
ARM: dts: stm32: use st,stm32mp15-i2c compatible for stm32mp151
ARM: dts: stm32: add Fast Mode Plus info in I2C nodes of stm32mp151
Arnaud Pouliquen (1):
ARM: dts: stm32: add cortex-M4 pdds management in Cortex-M4 node
Etienne Carriere (1):
ARM: dts: stm32: bump PSCI to version 1.0 on stm32mp15x
Fabrice Gasnier (3):
ARM: dts: stm32: fix a typo for DAC io-channel-cells on stm32f429
ARM: dts: stm32: fix a typo for DAC io-channel-cells on stm32h743
ARM: dts: stm32: fix a typo for DAC io-channel-cells on stm32mp15
Manivannan Sadhasivam (6):
dt-bindings: Add vendor prefix for Shiratech Solutions
ARM: dts: stm32: Add missing pinctrl entries for STM32MP15
dt-bindings: arm: stm32: Document Stinger96 compatible
ARM: dts: stm32: Add Stinger96 board support
dt-bindings: arm: stm32: Document IoT Box compatible
ARM: dts: stm32: Add IoT Box board support
Marek Vasut (35):
ARM: dts: stm32: Enable I2C2 on DHCOM PDK2 carrier board
ARM: dts: stm32: Repair PMIC configuration on AV96
ARM: dts: stm32: Repair PMIC interrupt on AV96
ARM: dts: stm32: Add alternate pinmux for ethernet RGMII on stm32mp15
ARM: dts: stm32: Repair ethernet operation on AV96
ARM: dts: stm32: Add missing ethernet PHY reset on AV96
ARM: dts: stm32: Add missing ethernet PHY skews on AV96
ARM: dts: stm32: Add alternate pinmux for SDMMC pins on stm32mp15
ARM: dts: stm32: Repair SDMMC1 operation on AV96
ARM: dts: stm32: Add eMMC attached to SDMMC2 on AV96
ARM: dts: stm32: Add QSPI NOR on AV96
ARM: dts: stm32: Add configuration EEPROM on AV96
ARM: dts: stm32: Enable WiFi on AV96
ARM: dts: stm32: Add alternate pinmux for USART2 pins on stm32mp15
ARM: dts: stm32: Enable Bluetooth on AV96
ARM: dts: stm32: Add alternate pinmux for LTDC pins on stm32mp15
ARM: dts: stm32: Add bindings for HDMI video on AV96
ARM: dts: stm32: Add alternate pinmux for SAI2 pins on stm32mp15
ARM: dts: stm32: Add bindings for audio on AV96
ARM: dts: stm32: Add bindings for USB on AV96
ARM: dts: stm32: Rename LEDs to match silkscreen on AV96
ARM: dts: stm32: Add alternate pinmux for I2C2 pins
ARM: dts: stm32: Repair I2C2 operation on AV96
ARM: dts: stm32: Add alternate pinmux for FDCAN1 pins
ARM: dts: stm32: Add bindings for FDCAN1 on AV96
ARM: dts: stm32: Add alternate pinmux for FDCAN2 pins
ARM: dts: stm32: Add bindings for FDCAN2 on AV96
ARM: dts: stm32: Add alternate pinmux for ADC pins
ARM: dts: stm32: Add bindings for ADC on AV96
ARM: dts: stm32: Add alternate pinmux for SPI2 pins
ARM: dts: stm32: Add bindings for SPI2 on AV96
ARM: dts: stm32: Add GPIO keys for STM32MP1 DHCOM PDK2
ARM: dts: stm32: Add GPIO LEDs for STM32MP1 DHCOM PDK2
ARM: dts: stm32: Split SoC-independent parts of DHCOM SOM and PDK2
ARM: dts: stm32: Split Avenger96 into DHCOR SoM and Avenger96 board
Pascal Paillet (1):
ARM: dts: stm32: Enable thermal sensor support on stm32mp15xx-dkx
Yann Gautier (1):
ARM: dts: stm32: add sd-uhs properties in SD-card node for
stm32mp157c-ed1
.../devicetree/bindings/arm/stm32/stm32.yaml | 3 +
.../devicetree/bindings/vendor-prefixes.yaml | 4 +
arch/arm/boot/dts/Makefile | 6 +-
arch/arm/boot/dts/stm32f429.dtsi | 4 +-
arch/arm/boot/dts/stm32h743.dtsi | 4 +-
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 666
++++++++++++++++++++-
arch/arm/boot/dts/stm32mp151.dtsi | 37 +-
arch/arm/boot/dts/stm32mp157.dtsi | 8 +-
arch/arm/boot/dts/stm32mp157a-avenger96.dts | 314 +---------
arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dts | 38 ++
arch/arm/boot/dts/stm32mp157a-iot-box.dts | 68 +++
arch/arm/boot/dts/stm32mp157a-stinger96.dts | 12 +
arch/arm/boot/dts/stm32mp157a-stinger96.dtsi | 342 +++++++++++
arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts | 265 +-------
arch/arm/boot/dts/stm32mp157c-dk2.dts | 8 -
arch/arm/boot/dts/stm32mp157c-ed1.dts | 7 +-
arch/arm/boot/dts/stm32mp157c-ev1.dts | 14 +-
arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts | 252 ++++++++
arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi | 337 +++++++++++
...c-dhcom-som.dtsi => stm32mp15xx-dhcom-som.dtsi} | 9 +-
arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 401 +++++++++++++
arch/arm/boot/dts/stm32mp15xx-dhcor-io1v8.dtsi | 23 +
arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi | 209 +++++++
arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 20 +-
arch/arm/boot/dts/stm32mp15xx-osd32.dtsi | 230 +++++++
25 files changed, 2634 insertions(+), 647 deletions(-)
create mode 100644 arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dts
create mode 100644 arch/arm/boot/dts/stm32mp157a-iot-box.dts
create mode 100644 arch/arm/boot/dts/stm32mp157a-stinger96.dts
create mode 100644 arch/arm/boot/dts/stm32mp157a-stinger96.dtsi
create mode 100644 arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
rename arch/arm/boot/dts/{stm32mp157c-dhcom-som.dtsi =>
stm32mp15xx-dhcom-som.dtsi} (98%)
create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-io1v8.dtsi
create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi
create mode 100644 arch/arm/boot/dts/stm32mp15xx-osd32.dtsi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Three network phy fixes for am57xx and am437x
From: Tony Lindgren @ 2020-05-14 16:02 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 738b150ecefbffb6e55cfa8a3b66a844f777d8fb:
ARM: dts: omap4-droid4: Fix occasional lost wakeirq for uart1 (2020-05-05 10:19:39 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.7/cpsw-fixes-signed
for you to fetch changes up to fb6823a6f9801dbe86b6551103f477dd3c5d115a:
ARM: dts: Fix wrong mdio clock for dm814x (2020-05-12 13:54:23 -0700)
----------------------------------------------------------------
Few cpsw related dts fixes for omaps
Recent cpsw driver changes exposed few regressions in the cpsw related
dts configuration that would be good to fix:
- Few more boards still need to be updated to use rgmii-rxid phy caused
by the fallout from commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode
support for the KSZ9031 PHY" as the rx delay is now disabled unless we
use rgmii-rxid.
- On dm814x we have been using a wrong clock for mdio that now can produce
external abort on some boards
----------------------------------------------------------------
Grygorii Strashko (2):
ARM: dts: am57xx: fix networking on boards with ksz9031 phy
ARM: dts: am437x: fix networking on boards with ksz9031 phy
Tony Lindgren (1):
ARM: dts: Fix wrong mdio clock for dm814x
arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++--
arch/arm/boot/dts/am571x-idk.dts | 4 ++--
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 4 ++--
arch/arm/boot/dts/am57xx-idk-common.dtsi | 4 ++--
arch/arm/boot/dts/dm814x.dtsi | 2 +-
7 files changed, 11 insertions(+), 11 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [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: devicetree, linux-kernel, 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: devicetree, linux-kernel, 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] media: cedrus: Propagate OUTPUT resolution to CAPTURE
From: Nicolas Dufresne @ 2020-05-14 15:43 UTC (permalink / raw)
To: Nicolas Dufresne
Cc: devel, kernel, Greg Kroah-Hartman, linux-kernel, Maxime Ripard,
Paul Kocialkowski, Chen-Yu Tsai, stable, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <20200514153903.341287-1-nicolas.dufresne@collabora.com>
Le jeudi 14 mai 2020 à 11:39 -0400, Nicolas Dufresne a écrit :
> As per spec, the CAPTURE resolution should be automatically set based on
> the OTUPUT resolution. This patch properly propagate width/height to the
> capture when the OUTPUT format is set and override the user provided
> width/height with configured OUTPUT resolution when the CAPTURE fmt is
> updated.
>
> This also prevents userspace from selecting a CAPTURE resolution that is
> too small, avoiding unwanted page faults.
Side note, this patch is based on top of "Samuel Holland <samuel@sholland.org>"
patches:
[PATCH v3 1/2] media: cedrus: Program output format during each run
[PATCH v3 2/2] media: cedrus: Implement runtime PM
As the patchset also fixes concurrent decoding issues. This was tested using
GStreamer implementation, which strictly follow the Stateless CODEC spec and
expect OUTPUT to CAPTURE width/height propagation.
>
> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index 16d82309e7b6..a6d6b15adc2e 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -247,6 +247,8 @@ static int cedrus_try_fmt_vid_cap(struct file *file, void
> *priv,
> return -EINVAL;
>
> pix_fmt->pixelformat = fmt->pixelformat;
> + pix_fmt->width = ctx->src_fmt.width;
> + pix_fmt->height = ctx->src_fmt.height;
> cedrus_prepare_format(pix_fmt);
>
> return 0;
> @@ -319,11 +321,14 @@ static int cedrus_s_fmt_vid_out(struct file *file, void
> *priv,
> break;
> }
>
> - /* Propagate colorspace information to capture. */
> + /* Propagate format information to capture. */
> ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
> ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
> ctx->dst_fmt.ycbcr_enc = f->fmt.pix.ycbcr_enc;
> ctx->dst_fmt.quantization = f->fmt.pix.quantization;
> + ctx->dst_fmt.width = ctx->src_fmt.width;
> + ctx->dst_fmt.height = ctx->src_fmt.height;
> + cedrus_prepare_format(&ctx->dst_fmt);
>
> return 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
From: Enric Balletbo i Serra @ 2020-05-14 15:42 UTC (permalink / raw)
To: Chun-Kuang Hu, Enric Balletbo Serra
Cc: Nicolas Boichat, Daniel Vetter, David Airlie, linux-kernel,
dri-devel, moderated list:ARM/Mediatek SoC support,
Laurent Pinchart, Philipp Zabel, Hsin-Yi Wang, Matthias Brugger,
Collabora Kernel ML, Sam Ravnborg, Linux ARM
In-Reply-To: <CAAOTY_-pOUuM7LQ1jm6gqpg8acMqDWOHxGucY5XOjq0ctGUkzA@mail.gmail.com>
Hi Chun-Kuang,
On 14/5/20 16:28, Chun-Kuang Hu wrote:
> Hi, Enric:
>
> Enric Balletbo Serra <eballetbo@gmail.com> 於 2020年5月14日 週四 上午12:41寫道：
>>
>> Hi Chun-Kuang,
>>
>> Missatge de Enric Balletbo i Serra <enric.balletbo@collabora.com> del
>> dia dv., 1 de maig 2020 a les 17:25:
>>>
>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>> that use drm_bridge. This allows splitting connector operations across
>>> multiple bridges when necessary, instead of having the last bridge in
>>> the chain creating the connector and handling all connector operations
>>> internally.
>>>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>
>> A gentle ping on this, I think that this one is the only one that
>> still needs a review in the series.
>
> This is what I reply in patch v3:
>
Sorry for missing this.
> I think the panel is wrapped into next_bridge here,
>
Yes, you can have for example:
1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge
(edp panel)
or a
2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
The _first_ one is my use case
> if (panel) {
This handles the second case, where you attach a dsi panel.
> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
>
> so the next_bridge is a panel_bridge, in its attach function
> panel_bridge_attach(),
> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> it would create connector and attach connector to panel.
>
> I'm not sure this flag would exist or not, but for both case, it's strange.
> If exist, you create connector in this patch but no where to attach
> connector to panel.
Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init()
will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for
dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
graphic controller driver should create connectors and CRTCs, as example you can
take a look at drivers/gpu/drm/omapdrm/omap_drv.c
> If not exist, the next_brige would create one connector and this brige
> would create another connector.
>
> I think in your case, mtk_dsi does not directly connect to a panel, so
Exactly
> I need a exact explain. Or someone could test this on a
> directly-connect-panel platform.
I don't think I am breaking this use case but AFAICS there is no users in
mainline that directly connect a panel using the mediatek driver. As I said my
use case is the other so I can't really test. Do you know anyone that can test this?
Thanks,
Enric
>
> Regards,
> Chun-Kuang.
>
>>
>> Thanks,
>> Enric
>>
>>> ---
>>>
>>> Changes in v4: None
>>> Changes in v3:
>>> - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart)
>>>
>>> Changes in v2: None
>>>
>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++-
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> index 4f3bd095c1ee..471fcafdf348 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> @@ -17,6 +17,7 @@
>>>
>>> #include <drm/drm_atomic_helper.h>
>>> #include <drm/drm_bridge.h>
>>> +#include <drm/drm_bridge_connector.h>
>>> #include <drm/drm_mipi_dsi.h>
>>> #include <drm/drm_of.h>
>>> #include <drm/drm_panel.h>
>>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>>> struct drm_encoder encoder;
>>> struct drm_bridge bridge;
>>> struct drm_bridge *next_bridge;
>>> + struct drm_connector *connector;
>>> struct phy *phy;
>>>
>>> void __iomem *regs;
>>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>>> */
>>> dsi->encoder.possible_crtcs = 1;
>>>
>>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
>>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
>>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>> if (ret)
>>> goto err_cleanup_encoder;
>>>
>>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
>>> + if (IS_ERR(dsi->connector)) {
>>> + DRM_ERROR("Unable to create bridge connector\n");
>>> + ret = PTR_ERR(dsi->connector);
>>> + goto err_cleanup_encoder;
>>> + }
>>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>>> +
>>> return 0;
>>>
>>> err_cleanup_encoder:
>>> --
>>> 2.26.2
>>>
>>>
>>> _______________________________________________
>>> Linux-mediatek mailing list
>>> Linux-mediatek@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Ulf Hansson @ 2020-05-14 15:41 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Benjamin Gaignard, Linux PM, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Linux ARM
In-Reply-To: <20200514142015.GA23401@bogus>
On Thu, 14 May 2020 at 16:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Mon, May 11, 2020 at 03:33:46PM +0200, Ulf Hansson wrote:
> > Moving forward, platforms are going to need to execute specific "last-man"
> > operations before a domain idle state can be entered.
>
> I need to dig the thread details, but I remember commenting on one of
> the similar discussion. It was something to do with voting which wasn't
> necessary at all. I am interested in the details here.
>
> > In one way or the other, these operations needs to be triggered while
> > walking the hierarchical topology via runtime PM and genpd, as it's at that
> > point the last-man becomes known.
> >
> > Moreover, executing last-man operations needs to be done after the CPU PM
> > notifications are sent through cpu_pm_enter(), as otherwise it's likely
> > that some notifications would fail. Therefore, let's re-order the sequence
> > in psci_enter_domain_idle_state(), so cpu_pm_enter() gets called prior
> > pm_runtime_put_sync().
> >
>
> More details on why notifications fail ?
Well, at this moment this is more of a hypothetical issue as there is
no last-man notification sent/used yet.
However, typically we would call cpu_cluster_pm_enter() in the path as
when the psci_pd_power_off() is called (for psci PM domains), when a
valid domain state has been found.
This means, we would violate the cpu_cluster_pm_enter() API, as it's
clearly stated in its corresponding function header, that
cpu_pm_enter() needs to be called first (and that's also how others
are currently using it).
Note that, I am currently exploring whether we shall call
cpu_cluster_pm_enter|exit() at all, or whether we can use some other
new genpd mechanism to accomplish the similar thing.
>
> > Fixes: ce85aef570df ("cpuidle: psci: Manage runtime PM in the idle path")
> > Reported-by: Lina Iyer <ilina@codeaurora.org>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/cpuidle/cpuidle-psci.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
> > index bae9140a65a5..d0fb585073c6 100644
> > --- a/drivers/cpuidle/cpuidle-psci.c
> > +++ b/drivers/cpuidle/cpuidle-psci.c
> > @@ -58,6 +58,10 @@ static int psci_enter_domain_idle_state(struct cpuidle_device *dev,
> > u32 state;
> > int ret;
> >
> > + ret = cpu_pm_enter();
> > + if (ret)
> > + return -1;
> > +
>
> This change is ignoring the retention case psci_enter_state handles and
> this may affect performance by doing unnecessary save/restore.
This was already the case before. CPU_PM_CPU_IDLE_ENTER_PARAM() ends
up always setting "is_retention" to 0, when __CPU_PM_CPU_IDLE_ENTER()
is called.
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: cedrus: Propagate OUTPUT resolution to CAPTURE
From: Nicolas Dufresne @ 2020-05-14 15:39 UTC (permalink / raw)
Cc: devel, kernel, Greg Kroah-Hartman, linux-kernel, Maxime Ripard,
Paul Kocialkowski, Chen-Yu Tsai, stable, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
As per spec, the CAPTURE resolution should be automatically set based on
the OTUPUT resolution. This patch properly propagate width/height to the
capture when the OUTPUT format is set and override the user provided
width/height with configured OUTPUT resolution when the CAPTURE fmt is
updated.
This also prevents userspace from selecting a CAPTURE resolution that is
too small, avoiding unwanted page faults.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 16d82309e7b6..a6d6b15adc2e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -247,6 +247,8 @@ static int cedrus_try_fmt_vid_cap(struct file *file, void *priv,
return -EINVAL;
pix_fmt->pixelformat = fmt->pixelformat;
+ pix_fmt->width = ctx->src_fmt.width;
+ pix_fmt->height = ctx->src_fmt.height;
cedrus_prepare_format(pix_fmt);
return 0;
@@ -319,11 +321,14 @@ static int cedrus_s_fmt_vid_out(struct file *file, void *priv,
break;
}
- /* Propagate colorspace information to capture. */
+ /* Propagate format information to capture. */
ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
ctx->dst_fmt.ycbcr_enc = f->fmt.pix.ycbcr_enc;
ctx->dst_fmt.quantization = f->fmt.pix.quantization;
+ ctx->dst_fmt.width = ctx->src_fmt.width;
+ ctx->dst_fmt.height = ctx->src_fmt.height;
+ cedrus_prepare_format(&ctx->dst_fmt);
return 0;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL] Qualcomm ARM64 DT fixes for v5.7
From: Arnd Bergmann @ 2020-05-14 15:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, Andy Gross, SoC Team, arm-soc, Srinivas Kandagatla,
Kevin Hilman, Olof Johansson, LAKML
In-Reply-To: <CAOCOHw4GmTYiXrd3z9B-YHq3wcwLYXg4y=nkJWhLCDw9G08KqQ@mail.gmail.com>
On Thu, May 14, 2020 at 4:02 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> Arnd, Olof?
>
I finally pulled it in last night, sorry for the delay. I think my git
push came too late
for today's linux-next, but the branch was successfully build tested
along with the
other fixes we got for v5.7, so I plan to forward it all tomorrow.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: static kernel in vmalloc space
From: Arnd Bergmann @ 2020-05-14 15:32 UTC (permalink / raw)
To: afzal mohammed; +Cc: Russell King, Linux ARM, linux-kernel@vger.kernel.org
In-Reply-To: <20200514133545.GA5020@afzalpc>
On Thu, May 14, 2020 at 3:35 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> > On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > > 4. for user space to/from copy
> > > a. pin user pages
> > > b. kmap user page (can't corresponding lowmem be used instead ?)
>
> > - In the long run, there is no need for kmap()/kmap_atomic() after
> > highmem gets removed from the kernel, but for the next few years
> > we should still assume that highmem can be used, in order to support
> > systems like the 8GB highbank, armadaxp, keystone2 or virtual
> > machines. For lowmem pages (i.e. all pages when highmem is
> > disabled), kmap_atomic() falls back to page_address() anyway,
> > so there is no much overhead.
>
> Here i have some confusion - iiuc, VMSPLIT_4G_4G is meant to help
> platforms having RAM > 768M and <= 4GB disable high memory and still
> be able to access full RAM, so high memory shouldn't come into picture,
> right ?. And for the above platforms it can continue current VMPSLIT
> option (the default 3G/1G), no ?, as VMSPLIT_4G_4G can't help complete
> 8G to be accessible from lowmem.
>
> So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of
> caveat in Kconfig help that this is meant for platforms w/ <=4GB), then
> we can do copy_{from,to}_user the same way currently do, and no need to
> do the user page pinning & kmap, right ?
No, that doesn't work: the current copy_from_user() relies on the user
address space being a subset of the kernel address space, so it doesn't
have to walk the page tables but just access the pointer and use
the .text.fixup/__ex_table trick to trap any accesses to pages with the
wrong permission or no backing.
> ...
> i think user page pinning is still required, but kmap can be avoided
> by using lowmem corresponding to that page, right ?, or am i
> completely wrong ?
As long as one does not actually use highmem on a particular
machine, kmap_atomic() is much cheaper than the get_user_pages()
that is needed anyway:
static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
{
preempt_disable();
pagefault_disable();
if (!PageHighMem(page))
return page_address(page);
return kmap_atomic_high_prot(page, prot);
}
#define kmap_atomic(page) kmap_atomic_prot(page, kmap_prot)
The preempt_disable()/pagefault_disable() are just adding to
variables that are usually on the local L1 cache, and the
page_address() is another multiply+add that you need in any
case. In kernels that disable highmem, the expensive code path
(kmap_atomic_high_prot) goes away entirely.
As a micro-optimization, one could use page_address() directly
instead of kmap_atomic() when highmem is disabled, but
I doubt it makes much of a difference.
> Only problem i see is Kernel compiled w/ VMSPLIT_4G_4G not suitable
> for >4GB machines, but anyway iiuc, it is was not meant for those
> machines. And it is not going to affect our current multiplatform
> setup as LPAE is not defined in multi_v7.
That was what I original thought as well, but I'd now prefer to
allow highmem to coexist with vmsplit-4g-4g:
Typical distros currently offer two kernels, with and without LPAE,
and they probably don't want to add a third one for LPAE with
either highmem or vmsplit-4g-4g. Having extra user address
space and more lowmem is both going to help users that
still have 8GB configurations.
If we want to limit the number of combinations, I'd prefer making
vmsplit-4g-4g mandatory for all LPAE kernels and it is stable
enough.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64
From: Catalin Marinas @ 2020-05-14 15:28 UTC (permalink / raw)
To: Zhenyu Ye
Cc: linux-arch, suzuki.poulose, maz, linux-kernel, xiexiangyou,
steven.price, zhangshaokun, linux-mm, arm, prime.zeng, guohanjun,
olof, kuhn.chenqun, will, linux-arm-kernel
In-Reply-To: <20200414112835.1121-3-yezhenyu2@huawei.com>
Hi Zhenyu,
On Tue, Apr 14, 2020 at 07:28:35PM +0800, Zhenyu Ye wrote:
> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
> index b76df828e6b7..3a1816770bd1 100644
> --- a/arch/arm64/include/asm/tlb.h
> +++ b/arch/arm64/include/asm/tlb.h
> @@ -38,7 +38,12 @@ static inline void tlb_flush(struct mmu_gather *tlb)
> return;
> }
>
> - __flush_tlb_range(&vma, tlb->start, tlb->end, stride, last_level);
> + if (cpus_have_const_cap(ARM64_HAS_TLBI_RANGE))
> + __flush_tlb_range_directly(&vma, tlb->start, tlb->end,
> + stride, last_level);
> + else
> + __flush_tlb_range(&vma, tlb->start, tlb->end,
> + stride, last_level);
I think you could move such check in __flush_tlb_range() and avoid
cpus_have_const_cap() in two places. More on this below.
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index bc3949064725..a482188ea563 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -59,6 +59,44 @@
> __ta; \
> })
>
> +/*
> + * This macro creates a properly formatted VA operand for the TLBI RANGE.
> + * The value bit assignments are:
> + *
> + * +----------+------+-------+-------+-------+----------------------+
> + * | ASID | TG | SCALE | NUM | TTL | BADDR |
> + * +-----------------+-------+-------+-------+----------------------+
> + * |63 48|47 46|45 44|43 39|38 37|36 0|
> + *
> + * The address range is determined by below formula:
> + * [BADDR, BADDR + (NUM + 1) * 2^(5*SCALE + 1) * PAGESIZE)
> + *
> + */
> +#define __TLBI_VADDR_RANGE(addr, asid, tg, scale, num, ttl) \
> + ({ \
> + unsigned long __ta = (addr) >> PAGE_SHIFT; \
> + __ta &= GENMASK_ULL(36, 0); \
> + __ta |= (unsigned long)(ttl) << 37; \
> + __ta |= (unsigned long)(num) << 39; \
> + __ta |= (unsigned long)(scale) << 44; \
> + __ta |= (unsigned long)(tg) << 46; \
> + __ta |= (unsigned long)(asid) << 48; \
> + __ta; \
> + })
> +
> +#define TLB_RANGE_MASK_SHIFT 5
> +#define TLB_RANGE_MASK GENMASK_ULL(TLB_RANGE_MASK_SHIFT - 1, 0)
> +
> +/*
> + * __TG defines translation granule of the system, which is defined by
> + * PAGE_SHIFT. Used by TTL.
> + * - 4KB : 1
> + * - 16KB : 2
> + * - 64KB : 3
> + */
> +#define __TG ((PAGE_SHIFT - 12) / 2 + 1)
I don't think we need __TLBI_VADDR_RANGE to take a tg argument since
it's always the same.
> +
> +
> /*
> * TLB Invalidation
> * ================
> @@ -171,12 +209,83 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
> dsb(ish);
> }
>
> +/* The maximum range size of one TLBI-RANGE instruction */
> +#define MAX_TLBI_RANGE_SIZE (1UL << 21)
Nitpick: call this MAX_TLBI_RANGE_PAGES as that's not an address range.
It may be useful to have a macro for the range here, something like:
#define __TLBI_PAGES(num, scale) ((num + 1) << (5 * scale + 1))
and define MAX_TLBI_RANGE_PAGES in terms of this macro as
__TLBI_PAGES(31, 3).
> +
> +/*
> + * This interface uses the *rvale1is* instruction to flush TLBs
> + * in [start, end) directly.
> + * This instruction is supported from ARM v8.4.
> + */
> +static inline void __flush_tlb_range_directly(struct vm_area_struct *vma,
> + unsigned long start, unsigned long end,
> + unsigned long stride, bool last_level)
> +{
> + int num = 0;
> + int scale = 0;
> + unsigned long asid = ASID(vma->vm_mm);
> + unsigned long addr = 0;
> + unsigned long range_size;
> +
> + start = round_down(start, stride);
> + end = round_up(end, stride);
> + range_size = (end - start) >> PAGE_SHIFT;
> +
> + if (range_size > MAX_TLBI_RANGE_SIZE) {
> + flush_tlb_mm(vma->vm_mm);
> + return;
> + }
> +
> + dsb(ishst);
> +
> + /*
> + * The minimum size of TLB RANGE is 2 PAGE;
> + * Use normal TLB instruction to handle odd PAGEs
Nitpick: no need to capitalise PAGE.
> + */
> + if (range_size % 2 == 1) {
> + addr = __TLBI_VADDR(start, asid);
> + if (last_level) {
> + __tlbi(vale1is, addr);
> + __tlbi_user(vale1is, addr);
> + } else {
> + __tlbi(vae1is, addr);
> + __tlbi_user(vae1is, addr);
> + }
> + start += 1 << PAGE_SHIFT;
> + range_size -= 1;
> + }
> +
> + range_size >>= 1;
> + while (range_size > 0) {
> + num = (range_size & TLB_RANGE_MASK) - 1;
> + if (num >= 0) {
> + addr = __TLBI_VADDR_RANGE(start, asid, __TG,
> + scale, num, 0);
> + if (last_level) {
> + __tlbi(rvale1is, addr);
> + __tlbi_user(rvale1is, addr);
> + } else {
> + __tlbi(rvae1is, addr);
> + __tlbi_user(rvae1is, addr);
> + }
> + start += (num + 1) << (5 * scale + 1) << PAGE_SHIFT;
You could use the __TLBI_PAGES macro I proposed above.
> + }
> + scale++;
> + range_size >>= TLB_RANGE_MASK_SHIFT;
> + }
So, you start from scale 0 and increment it until you reach the maximum.
I think (haven't done the maths on paper) you could also start from the
top with something like scale = ilog2(range_size) / 5. Not sure it's
significantly better though, maybe avoiding the loop 3 times if your
range is 2MB (which happens with huge pages).
Anyway, I think it would be more efficient if we combine the
__flush_tlb_range() and the _directly one into the same function with a
single loop for both. For example, if the stride is 2MB already, we can
handle this with a single classic TLBI without all the calculations for
the range operation. The hardware may also handle this better since the
software already told it there can be only one entry in that 2MB range.
So each loop iteration could figure which operation to use based on
cpucaps, TLBI range ops, stride and reduce range_size accordingly.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* 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, talel, linux-arm-kernel, jonnyc,
ronenk, hanochu, dwmw
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: devicetree, geert+renesas, xuwei5, robh+dt, kernel,
linux-arm-kernel
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: Rob Herring, linux-omap, devicetree, linux-kernel,
Andrew F . Davis, Santosh Shilimkar, Suman Anna, linux-arm-kernel
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hua Dillon, Maxime Coquelin, linux-kernel, Rob Herring, linux-spi,
Mark Brown, p.zabel, linux-stm32, Linux ARM
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";
>>> + };
>>> +};
>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend
From: Stanley Chu @ 2020-05-14 15:01 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb,
asutoshd
Cc: bvanassche, andy.teng, chun-hung.wu, kuohong.wang, linux-kernel,
cang, linux-mediatek, peter.wang, matthias.bgg, Stanley Chu,
linux-arm-kernel, beanhuo
In-Reply-To: <20200514150122.32110-1-stanley.chu@mediatek.com>
Currently UFS host driver promises VCC supply if UFS device
needs to do WriteBooster flush during runtime suspend.
However the UFS specification mentions,
"While the flushing operation is in progress, the device is
in Active power mode."
Therefore UFS host driver needs to promise more: Keep UFS
device as "Active power mode", otherwise UFS device shall not
do any flush if device enters Sleep or PowerDown power mode.
Fix this by not changing device power mode if WriteBooster
flush is required in ufshcd_suspend().
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/ufs/ufs.h | 1 -
drivers/scsi/ufs/ufshcd.c | 42 ++++++++++++++++++++-------------------
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index b3135344ab3f..9e4bc2e97ada 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -577,7 +577,6 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
- bool keep_vcc_on;
u8 b_presrv_uspc_en;
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 169a3379e468..b9f7744ca2b4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ufshcd_setup_vreg(hba, false);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
- if (!hba->dev_info.keep_vcc_on)
- ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
+ ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
if (!ufshcd_is_link_active(hba)) {
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
@@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+ bool keep_curr_dev_pwr_mode = false;
hba->pm_op_in_progress = 1;
if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8227,27 +8227,29 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufshcd_disable_auto_bkops(hba);
}
/*
- * With wb enabled, if the bkops is enabled or if the
- * configured WB type is 70% full, keep vcc ON
- * for the device to flush the wb buffer
+ * If device needs to do BKOP or WB buffer flush during
+ * Hibern8, keep device power mode as "active power mode"
+ * and VCC supply.
*/
- if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
- ufshcd_wb_keep_vcc_on(hba))
- hba->dev_info.keep_vcc_on = true;
- else
- hba->dev_info.keep_vcc_on = false;
- } else {
- hba->dev_info.keep_vcc_on = false;
+ keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+ (((req_link_state == UIC_LINK_HIBERN8_STATE) ||
+ ((req_link_state == UIC_LINK_ACTIVE_STATE) &&
+ ufshcd_is_auto_hibern8_enabled(hba))) &&
+ ufshcd_wb_keep_vcc_on(hba));
}
- if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&
- ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
- !ufshcd_is_runtime_pm(pm_op))) {
- /* ensure that bkops is disabled */
- ufshcd_disable_auto_bkops(hba);
- ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
- if (ret)
- goto enable_gating;
+ if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
+ if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
+ !ufshcd_is_runtime_pm(pm_op)) {
+ /* ensure that bkops is disabled */
+ ufshcd_disable_auto_bkops(hba);
+ }
+
+ if (!keep_curr_dev_pwr_mode) {
+ ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
+ if (ret)
+ goto enable_gating;
+ }
}
flush_work(&hba->eeh_work);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* 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: devicetree, linux-omap, Rob Herring, linux-kernel,
Andrew F . Davis, Santosh Shilimkar, Suman Anna, linux-arm-kernel
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: devicetree, andre.przywara, linux-actions, cristian.ciocaltea,
robh+dt, manivannan.sadhasivam, afaerber, linux-arm-kernel
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>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hua Dillon, Maxime Coquelin, linux-kernel, Rob Herring, linux-spi,
Mark Brown, p.zabel, linux-stm32, Linux ARM
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";
> > + };
> > +};
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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