* [PATCH 5/5] ARM: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Mark Rutland, Li Yang
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Schrempf Frieder, linux-spi@vger.kernel.org,
boris.brezillon@bootlin.com, broonie@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
We will move the FSL QSPI driver to the SPI framework soon. To
prepare and to make sure the full buswidth is used (as it is with
the current driver), let's add the right properties.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 4 ++++
arch/arm/boot/dts/imx6sx-sdb.dts | 4 ++++
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 2 ++
4 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index 344abc2..9997156 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -132,6 +132,8 @@
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
flash1: s25fl128s@2 {
@@ -140,5 +142,7 @@
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
};
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 5a39703..9acfda8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -117,6 +117,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
@@ -125,6 +127,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <2>;
};
};
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 32a0723..c2c9a2a 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -176,6 +176,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index 6bb7ce0..6a83f30 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -211,6 +211,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
partitions@0 {
--
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 4/5] arm64: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Li Yang
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Rob Herring,
linux-spi@vger.kernel.org, boris.brezillon@bootlin.com,
broonie@kernel.org, linux-mtd@lists.infradead.org,
Schrempf Frieder, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
We will move the FSL QSPI driver to the SPI framework soon. To
prepare and to make sure the full buswidth is used (as it is with
the current driver), let's add the right properties.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 2 ++
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 ++
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
4 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index d2c06ad4..8a50094 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -142,6 +142,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 6ec1adb..2f220ec 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -170,6 +170,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 17f1298..07c665c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -106,6 +106,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
@@ -114,6 +116,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <1>;
};
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index c11f52e..10d2fe0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -134,6 +134,8 @@
#size-cells = <1>;
compatible = "st,m25p80";
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
flash2: s25fl256s1@2 {
@@ -141,6 +143,8 @@
#size-cells = <1>;
compatible = "st,m25p80";
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <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 1/5] arm64: dts: Remove unused properties from FSL QSPI driver nodes
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Li Yang
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Rob Herring,
linux-spi@vger.kernel.org, boris.brezillon@bootlin.com,
broonie@kernel.org, linux-mtd@lists.infradead.org,
Schrempf Frieder, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The properties 'num-cs' and 'bus-num' were never read by the driver
and can be removed.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 1 -
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 2 --
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 2 --
3 files changed, 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index dff3d64..d2c06ad4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -135,7 +135,6 @@
};
&qspi {
- bus-num = <0>;
status = "okay";
qflash0: s25fl128s@0 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index e58a8ca..6ec1adb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -163,8 +163,6 @@
};
&qspi {
- num-cs = <2>;
- bus-num = <0>;
status = "okay";
qflash0: s25fl128s@0 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index a59b482..17f1298 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -99,8 +99,6 @@
};
&qspi {
- num-cs = <2>;
- bus-num = <0>;
status = "okay";
qflash0: s25fs512s@0 {
--
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 2/5] ARM: dts: Remove unused properties from FSL QSPI driver nodes
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Schrempf Frieder, linux-spi@vger.kernel.org,
boris.brezillon@bootlin.com, broonie@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The properties 'bus-num', 'fsl,spi-num-chipselects' and
'fsl,spi-flash-chipselects' were never read by the driver
and can be removed.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index d01f64b..6bb7ce0 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,9 +203,6 @@
};
&qspi {
- bus-num = <0>;
- fsl,spi-num-chipselects = <2>;
- fsl,spi-flash-chipselects = <0>;
fsl,qspi-has-second-chip;
status = "okay";
--
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 0/5] Prepare devicetrees for the new FSL QSPI driver
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Schrempf Frieder,
linux-spi@vger.kernel.org, boris.brezillon@bootlin.com,
broonie@kernel.org, linux-mtd@lists.infradead.org
From: Frieder Schrempf <frieder.schrempf@kontron.de>
We have prepared a new driver for the FSL QSPI controller that works under
the SPI framework. The current devicetrees are broken because they use an
inconsistent scheme for assigning the reg properties.
As, in contrast to the current driver, the new driver will use the reg
properties to select the correct chip, we need to fix them.
We also add spi-[tx/rx]-bus-width to make sure the full buswidth will be used
and while at it clean up and remove some unused properties.
Frieder Schrempf (5):
arm64: dts: Remove unused properties from FSL QSPI driver nodes
ARM: dts: Remove unused properties from FSL QSPI driver nodes
ARM: dts: imx6sx-sdb: Fix the reg properties for the FSL QSPI nodes
arm64: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
ARM: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 ++++++--
arch/arm/boot/dts/imx6sx-sdb.dts | 8 ++++++--
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 3 ++-
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 4 ++--
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 ++++--
arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
8 files changed, 28 insertions(+), 12 deletions(-)
--
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
* [PATCH v5 15/17] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Minimum PLL used for MIPI is 500MHz, as per manual, but
lowering the min rate by 300MHz can result proper working
nkms divider with the help of desired dclock rate from
panel driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 181b599dc163..b623c8150b4f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -183,6 +183,7 @@ static struct ccu_nkm pll_mipi_clk = {
.n = _SUNXI_CCU_MULT(8, 4),
.k = _SUNXI_CCU_MULT_MIN(4, 2, 2),
.m = _SUNXI_CCU_DIV(0, 4),
+ .min_rate = 300000000, /* Actual rate is 500MHz */
.common = {
.reg = 0x040,
.hw.init = CLK_HW_INIT("pll-mipi", "pll-video0",
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Will Deacon @ 2018-12-10 16:18 UTC (permalink / raw)
To: Steve Capper
Cc: ard.biesheuvel@linaro.org, Catalin Marinas, Suzuki Poulose,
linux-mm@kvack.org, jcm@redhat.com, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210160348.GA4564@capper-debian.cambridge.arm.com>
On Mon, Dec 10, 2018 at 04:04:02PM +0000, Steve Capper wrote:
> On Mon, Dec 10, 2018 at 01:36:40PM +0000, Will Deacon wrote:
> > On Fri, Dec 07, 2018 at 05:28:58PM +0000, Suzuki K Poulose wrote:
> > > On 07/12/2018 15:26, Will Deacon wrote:
> > > > On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
> > > > > On 12/06/2018 10:50 PM, Steve Capper wrote:
> > > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > > > > index f60081be9a1b..58fcc1edd852 100644
> > > > > > --- a/arch/arm64/kernel/head.S
> > > > > > +++ b/arch/arm64/kernel/head.S
> > > > > > @@ -707,6 +707,7 @@ secondary_startup:
> > > > > > /*
> > > > > > * Common entry point for secondary CPUs.
> > > > > > */
> > > > > > + bl __cpu_secondary_check52bitva
> > > > > > bl __cpu_setup // initialise processor
> > > > > > adrp x1, swapper_pg_dir
> > > > > > bl __enable_mmu
> > > > > > @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
> > > > > > ret
> > > > > > ENDPROC(__enable_mmu)
> > > > > > +ENTRY(__cpu_secondary_check52bitva)
> > > > > > +#ifdef CONFIG_ARM64_52BIT_VA
> > > > > > + ldr_l x0, vabits_user
> > > > > > + cmp x0, #52
> > > > > > + b.ne 2f > +
> > > > > > + mrs_s x0, SYS_ID_AA64MMFR2_EL1
> > > > > > + and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> > > > > > + cbnz x0, 2f
> > > > > > +
> > > > > > + adr_l x0, va52mismatch
> > > > > > + mov w1, #1
> > > > > > + strb w1, [x0]
> > > > > > + dmb sy
> > > > > > + dc ivac, x0 // Invalidate potentially stale cache line
> > > > >
> > > > > You may have to clear this variable before a CPU is brought up to avoid
> > > > > raising a false error message when another secondary CPU doesn't boot
> > > > > for some other reason (say granule support) after a CPU failed with lack
> > > > > of 52bitva. It is really a crazy corner case.
> > > >
> > > > Can't we just follow the example set by the EL2 setup in the way that is
> > > > uses __boot_cpu_mode? In that case, we only need one variable and you can
> > > > detect a problem by comparing the two halves.
> > >
> > > The only difference here is, the support is bolted at boot CPU time and hence
> > > we need to verify each and every CPU, unlike the __boot_cpu_mode where we
> > > check for mismatch after the SMP CPUs are brought up. If we decide to make
> > > the choice later, something like that could work. The only caveat is the 52bit
> > > kernel VA will have to do something like the above.
> >
> > So looking at this a bit more, I think we're better off repurposing the
> > upper bits of the early boot status word to contain a reason code, rather
> > than introducing new variables for every possible mismatch.
> >
> > Does the untested diff below look remotely sane to you?
> >
> > Will
> >
>
> Thanks Will,
> This looks good to me, I will test now and fold this into a patch.
Cheers, Steve. Testing would be handy, but don't worry about respinning the
patches as I'm already on top of this and hope to push this out later today.
Will
_______________________________________________
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] cpuidle: big.LITTLE: add of_node_put()
From: Frank Lee @ 2018-12-10 16:27 UTC (permalink / raw)
To: Daniel Lezcano
Cc: lorenzo.pieralisi, rjw, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <ed0c146f-0a47-ef56-f919-4887d6a69001@linaro.org>
On Mon, Dec 10, 2018 at 7:59 PM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
>
> Hi Yangtao,
>
>
> On 20/11/2018 17:14, Yangtao Li wrote:
> > of_find_node_by_path() acquires a reference to the node
> > returned by it and that reference needs to be dropped by its caller.
> > bl_idle_init() doesn't do that, so fix it.
> >
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> > Changes in v3:
> > -update changelog
> > ---
> > drivers/cpuidle/cpuidle-big_little.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
> > index db2ede565f1a..650f063ef809 100644
> > --- a/drivers/cpuidle/cpuidle-big_little.c
> > +++ b/drivers/cpuidle/cpuidle-big_little.c
> > @@ -174,8 +174,12 @@ static int __init bl_idle_init(void)
> > /*
> > * Initialize the driver just for a compliant set of machines
> > */
> > - if (!of_match_node(compatible_machine_match, root))
> > + if (!of_match_node(compatible_machine_match, root)){
> > + of_node_put(root);
> > return -ENODEV;
> > + }
> > +
> > + of_node_put(root);
>
> Don't duplicate the of_node_put.
>
> I suggest:
>
> const struct of_device_id *match_id;
>
> [ ... ]
>
>
> match_id = of_match_node(compatible_machine_match, root);
>
> of_node_put(root);
>
> if (!match_id)
> return -ENODEV;
>
>
Thank you for your suggestion, the new one has been sent.
Yours,
Yangtao
> > if (!mcpm_is_available())
> > return -EUNATCH;
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] cpuidle: big.LITTLE: fix refcount leak
From: Yangtao Li @ 2018-12-10 16:26 UTC (permalink / raw)
To: lorenzo.pieralisi, daniel.lezcano, rjw
Cc: Yangtao Li, linux-kernel, linux-arm-kernel, linux-pm
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
bl_idle_init() doesn't do that, so fix it.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
---
changes in v4:
-update tile
-refactor code,suggested by Daniel
---
drivers/cpuidle/cpuidle-big_little.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
index db2ede565f1a..b44476a1b7ad 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -167,6 +167,7 @@ static int __init bl_idle_init(void)
{
int ret;
struct device_node *root = of_find_node_by_path("/");
+ const struct of_device_id *match_id;
if (!root)
return -ENODEV;
@@ -174,7 +175,11 @@ static int __init bl_idle_init(void)
/*
* Initialize the driver just for a compliant set of machines
*/
- if (!of_match_node(compatible_machine_match, root))
+ match_id = of_match_node(compatible_machine_match, root);
+
+ of_node_put(root);
+
+ if (!match_id)
return -ENODEV;
if (!mcpm_is_available())
--
2.17.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
* [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.21/v5.0
From: Masahiro Yamada @ 2018-12-10 16:24 UTC (permalink / raw)
To: arm-soc, Olof Johansson, Arnd Bergmann
Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Arnd, Olof,
Please pull UniPhier DT updates for the v4.21/v5.0 MW.
Thanks!
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v4.21
for you to fetch changes up to f911160a215c2ee63633d058d673881986568fb1:
ARM: dts: uniphier: add MIO DMAC nodes (2018-12-11 00:58:54 +0900)
----------------------------------------------------------------
UniPhier ARM SoC DT updates for v4.21
- Add bindings for all SoCs/boards of UniPhier platform
- Move binding docs to the socionext directory
- Add all CPUs in cooling maps
- Add MIO DMAC nodes
----------------------------------------------------------------
Masahiro Yamada (3):
dt-bindings: uniphier: add bindings for UniPhier SoC family
dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
ARM: dts: uniphier: add MIO DMAC nodes
Viresh Kumar (1):
ARM: dts: uniphier: Add all CPUs in cooling maps
.../arm/{uniphier => socionext}/cache-uniphier.txt | 0
.../devicetree/bindings/arm/socionext/uniphier.txt | 47 ++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm/boot/dts/uniphier-ld4.dtsi | 14 +++++++
arch/arm/boot/dts/uniphier-pro4.dtsi | 16 ++++++++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 6 ++-
arch/arm/boot/dts/uniphier-sld8.dtsi | 14 +++++++
7 files changed, 96 insertions(+), 2 deletions(-)
rename Documentation/devicetree/bindings/arm/{uniphier =>
socionext}/cache-uniphier.txt (100%)
create mode 100644 Documentation/devicetree/bindings/arm/socionext/uniphier.txt
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: TK1: DRM, Nouveau and VIC
From: Thierry Reding @ 2018-12-10 16:23 UTC (permalink / raw)
To: Marcel Ziswiler
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
mperttunen@nvidia.com, bskeggs@redhat.com,
linux-tegra@vger.kernel.org, jonathanh@nvidia.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <49ea16ae9b500551a68b001ed7ce064b2591fd04.camel@toradex.com>
[-- Attachment #1.1: Type: text/plain, Size: 14361 bytes --]
On Mon, Dec 10, 2018 at 03:20:19PM +0000, Marcel Ziswiler wrote:
> Hi Thierry
>
> On Mon, 2018-12-10 at 12:00 +0100, Thierry Reding wrote:
> > On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> > > On Sat, Dec 08, 2018 at 02:54:45PM +0000, Marcel Ziswiler wrote:
> > > > Hi Thierry et al.
> > > >
> > > > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > > > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> > > > loading the vic firmware:
> > > >
> > > > [ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
> > > > nvidia/tegra124/vic03_ucode.bin failed with error -2
> > > > [ 1.606140] tegra-vic: probe of 54340000.vic failed with error
> > > > -2
> > > >
> > > > Subsequently Tegra HDMI seems to fail completely:
> > > >
> > > > [ 2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL
> > > > regulator
> > > >
> > > > And finally, Nouveau even crashes:
> > > >
> > > > [ 8.241115] nouveau 57000000.gpu: Linked as a consumer to
> > > > regulator.31
> > > > [ 8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
> > > > [ 8.253396] nouveau 57000000.gpu: imem: using IOMMU
> > > > [ 8.270210] Unable to handle kernel NULL pointer dereference
> > > > at
> > > > virtual address 0000006c
> > > > [ 8.278340] pgd = (ptrval)
> > > > [ 8.281250] [0000006c] *pgd=00000000
> > > > [ 8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> > > > [ 8.290260] Modules linked in: nouveau(+) ttm
> > > > [ 8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted
> > > > 4.20.0-
> > > > rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
> > > > [ 8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device
> > > > Tree)
> > > > [ 8.311331] PC is at drm_plane_register_all+0x18/0x50
> > > > [ 8.316373] LR is at drm_modeset_register_all+0xc/0x70
> > > > [ 8.321513] pc : [<c056200c>] lr : [<c0564cc8>] psr:
> > > > a0060013
> > > > [ 8.327768] sp : ed527c70 ip : ecc43ec0 fp : 00000000
> > > > [ 8.332993] r10: 00000016 r9 : ecc43e80 r8 : 00000000
> > > > [ 8.338209] r7 : bf182c80 r6 : 00000000 r5 : ed61b24c r4 :
> > > > fffffffc
> > > > [ 8.344735] r3 : 0002f000 r2 : ffffffff r1 : 2e124000 r0 :
> > > > ed61b000
> > > > [ 8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
> > > > ARM Segment none
> > > > [ 8.358383] Control: 10c5387d Table: ad64c06a DAC: 00000051
> > > > [ 8.364127] Process systemd-udevd (pid: 203, stack limit =
> > > > 0x(ptrval))
> > > > [ 8.370654] Stack: (0xed527c70 to 0xed528000)
> > > > [ 8.375004] 7c60: ed61b000
> > > > ed61b000 00000000 c0564cc8
> > > > [ 8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
> > > > 00000001 ffffffff ffffffff
> > > > [ 8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
> > > > 00000000 bf180c5c bf0dc900
> > > > [ 8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
> > > > bf180c5c 00000000 c05a9328
> > > > [ 8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
> > > > c05a744c ee9f2a10 bf180c5c
> > > > [ 8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
> > > > c05a769c eefd14d0 c05a77a8
> > > > [ 8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
> > > > 00000000 c0f08c48 bf182980
> > > > [ 8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
> > > > c05a5790 00000000 ee88135c
> > > > [ 8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
> > > > c0f71168 00000000 c05a692c
> > > > [ 8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
> > > > ffffe000 bf1aa000 c05a84a0
> > > > [ 8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
> > > > c0f08c48 ffffe000 c0102ed0
> > > > [ 8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
> > > > bf182980 00000040 c02592d0
> > > > [ 8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
> > > > c01b3d98 0000000c c025a8cc
> > > > [ 8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
> > > > 00000002 ed53f4c0 00000002
> > > > [ 8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
> > > > ed527f40 00000002 eceb9fc0
> > > > [ 8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
> > > > c01b2f88 00000000 c01b279c
> > > > [ 8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
> > > > c0d58964 c0ca726c c0ca7278
> > > > [ 8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
> > > > 00000000 ffffe000 bf000000
> > > > [ 8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
> > > > 00000000 6e72656b 00006c65
> > > > [ 8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
> > > > 00000000 00000000 00000000
> > > > [ 8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
> > > > 5dfe844b 7fffffff c0f08c48
> > > > [ 8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
> > > > 0000017b 004a3270 c01b66a4
> > > > [ 8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
> > > > f0ced000 06e8994c 00000000
> > > > [ 8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
> > > > f7b75d34 f63e62dc 0016b000
> > > > [ 8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
> > > > 0000003b 0000003c 00000023
> > > > [ 8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
> > > > 004c0ec0 00000000 00000001
> > > > [ 8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
> > > > b6f761cc 00000000 00020000
> > > > [ 8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > > 00000000 00000000 004a3270
> > > > [ 8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
> > > > 0000000f 00000000 00000000
> > > > [ 8.612096] [<c056200c>] (drm_plane_register_all) from
> > > > [<c0564cc8>]
> > > > (drm_modeset_register_all+0xc/0x70)
> > > > [ 8.621499] [<c0564cc8>] (drm_modeset_register_all) from
> > > > [<c054b5b8>] (drm_dev_register+0x168/0x1c4)
> > > > [ 8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
> > > > (nouveau_platform_probe+0x6c/0x88 [nouveau])
> > > > [ 8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau])
> > > > from
> > > > [<c05a9328>] (platform_drv_probe+0x48/0x98)
> > > > [ 8.650574] [<c05a9328>] (platform_drv_probe) from
> > > > [<c05a744c>]
> > > > (really_probe+0x1e0/0x2cc)
> > > > [ 8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
> > > > (driver_probe_device+0x60/0x16c)
> > > > [ 8.667096] [<c05a769c>] (driver_probe_device) from
> > > > [<c05a7884>]
> > > > (__driver_attach+0xdc/0xe0)
> > > > [ 8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
> > > > (bus_for_each_dev+0x74/0xb4)
> > > > [ 8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
> > > > (bus_add_driver+0x1c0/0x204)
> > > > [ 8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
> > > > (driver_register+0x74/0x108)
> > > > [ 8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
> > > > (nouveau_drm_init+0x170/0x1000 [nouveau])
> > > > [ 8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
> > > > [<c0102ed0>] (do_one_initcall+0x54/0x284)
> > > > [ 8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
> > > > (do_init_module+0x64/0x214)
> > > > [ 8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
> > > > (load_module+0x21b8/0x246c)
> > > > [ 8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
> > > > (sys_finit_module+0xc4/0xdc)
> > > > [ 8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
> > > > (ret_fast_syscall+0x0/0x54)
> > > > [ 8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
> > > > [ 8.756157] 7fa0: 004c0ec0 00000000 0000000f
> > > > b6f761cc 00000000 00020000
> > > > [ 8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
> > > > 00000000 00000000 004a3270
> > > > [ 8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
> > > > [ 8.777556] Code: e5b5424c e1550004 0a00000c e2444004
> > > > (e5943070)
> > > > [ 8.784011] ---[ end trace ad8c21587c118655 ]---
> > > >
> > > > Of course my root file system does include resp. vic firmware:
> > > >
> > > > 7ef01d2e3f507c91ca79584e89edcc64 /lib/firmware/nvidia/tegra124/v
> > > > ic03_u
> > > > code.bin
> > > >
> > > > If I bake that one into the kernel binary, Nouveau still crashes
> > > > like
> > > > above albeit VIC loading and Tegra DRM now at least showing
> > > > something
> > > > on HDMI.
> > >
> > > Yeah, this is a fairly common pitfall. The general rule of thumb is
> > > that
> > > the firmware has to live on the same medium as the module. So if
> > > you've
> > > built Tegra DRM as a loadable kernel module and installed it in the
> > > root
> > > filesystem, then that's where your firmware file also needs to be.
> > > If
> > > the driver is built-in (or a loadable module installed in the
> > > initial
> > > ramdisk), then the firmware needs to be in the initial ramdisk (or
> > > built
> > > into the kernel image itself). That's somewhat annoying, but it is
> > > what
> > > it is. At least it's logical.
> > >
> > > > Just reverting above mentioned commit still leaves Nouveau
> > > > crashing.
> > > >
> > > > This has been observed using latest next-20181207.
> > > >
> > > > Does anybody know what exactly is going on and how exactly one
> > > > may get
> > > > graphics working again as before?
> > >
> > > So this is something that should be fixed by this:
> > >
> > > https://patchwork.freedesktop.org/patch/260547/
> > >
> > > And there's another patch that fixes a subsequent crash when you
> > > actually start to use the GPU:
> > >
> > > https://patchwork.freedesktop.org/patch/263588/
> > >
> > > It'd be great if you could apply both and verify that they fix the
> > > crash
> > > for you. If so, can you provide a Tested-by? Both were Cc'ed to
> > > linux-tegra, so you should have a copy to reply to. If not, let me
> > > know
> > > and I can bounce it.
> > >
> > > Ben, can you pick up the two patches above? They're kind of high-
> > > priority because they fix issues that crept into v4.20-rc1, so
> > > should
> > > ideally be fixed before v4.20 final.
> >
> > Actually, it looks as if only the last patch is needed, since it
> > superseeds the first. The second one calls drm_mode_config_init() via
> > nouveau_display_create() and nouveau_drm_device_init(), making the
> > first patch obsolete.
> >
> > There's more confirmation here:
> >
> >
> > https://lists.freedesktop.org/archives/nouveau/2018-December/031636.html
> >
> > So Ben, correction, please only apply:
> >
> > https://patchwork.freedesktop.org/patch/263587/
>
> Yes, that fixes it and I sent my tested-by. Thanks!
Excellent, thanks!
>
> > Preferably in time for v4.20 final.
>
> BTW: During testing I was also brave enough to try rmmodding nouveau
> which unfortunately also seems to fail:
>
> root@apalis-tk1-mainline:~# rmmod nouveau
> [ 3044.432527] [TTM] Finalizing pool allocator
> [ 3044.440007] [TTM] Zone kernel: Used memory at exit: 0 kiB
> [ 3044.445631] [TTM] Zone highmem: Used memory at exit: 0 kiB
> [ 3044.452841] Unable to handle kernel NULL pointer dereference at
> virtual address 0000038a
> [ 3044.461167] pgd = 537c0ac4
> [ 3044.463891] [0000038a] *pgd=fb95b835
> [ 3044.467487] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [ 3044.472901] Modules linked in: nouveau(-) btusb btrtl btbcm btintel
> tegra_drm xhci_tegra host1x iova ttm
> [ 3044.482415] CPU: 3 PID: 616 Comm: rmmod Not tainted 4.20.0-rc6-next-
> 20181210-00001-gd70a977fd0d5-dirty #115
> [ 3044.492176] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> [ 3044.498455] PC is at pci_disable_device+0x8/0xd4
> [ 3044.503165] LR is at nouveau_drm_device_remove+0x50/0x7c [nouveau]
> [ 3044.509350] pc : [<c048d05c>] lr : [<bf254820>] psr: 60000113
> [ 3044.515638] sp : ee3abedc ip : ed625000 fp : 00000001
> [ 3044.520879] r10: 00000081 r9 : ee3aa000 r8 : ee9eb834
> [ 3044.526107] r7 : ed624000 r6 : 00000000 r5 : c0f08c48 r4 :
> 00000000
> [ 3044.532649] r3 : 5dfe844b r2 : 5dfe844b r1 : 2e135000 r0 :
> 00000000
> [ 3044.539181] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA
> ARM Segment none
> [ 3044.546333] Control: 10c5387d Table: acbc006a DAC: 00000051
> [ 3044.552098] Process rmmod (pid: 616, stack limit = 0xfc4e79a2)
> [ 3044.557934] Stack: (0xee3abedc to 0xee3ac000)
> [ 3044.562304]
> bec0: ed
> 62d400
> [ 3044.570503] bee0: c0f08c48 bf254820 eda76808 5dfe844b ee9f1c8c
> ee9f1c10 ee9f1c10 bf2f9c5c
> [ 3044.578701] bf00: ee9eb800 bf255914 ee9f1c10 c056aba8 ee9f1c10
> ee9f1c44 bf2f9c5c c05693bc
> [ 3044.587298] bf20: ee9f1c10 bf2f9c5c 0001f10c 00000800 c0101204
> c05694cc bf2f9c5c bf2fb980
> [ 3044.596316] bf40: 0001f10c c056829c c0f08c48 c01b3c34 76756f6e
> 00756165 00000000 00000000
> [ 3044.605356] bf60: c0f08c48 ec415000 00000002 5dfe844b 00000001
> c0141c10 ec415000 ec415000
> [ 3044.614431] bf80: ed67c100 5dfe844b 00000000 5dfe844b 00000000
> 00000002 bebb5ba8 00000000
> [ 3044.623529] bfa0: 00000081 c0101000 00000002 bebb5ba8 0001f10c
> 00000800 0000000a 00000000
> [ 3044.632631] bfc0: 00000002 bebb5ba8 00000000 00000081 bebb5e9b
> 0001f0d0 bebb5d8c 00000001
> [ 3044.641739] bfe0: b6e74730 bebb5b64 00012bdf b6e7473c 600d0010
> 0001f10c 00000000 00000000
> [ 3044.650884] [<c048d05c>] (pci_disable_device) from [<ee9f1c8c>]
> (0xee9f1c8c)
> [ 3044.658410] Code: eafffff0 ebf25973 e92d4030 e1a04000 (e5d0338a)
> [ 3044.665141] ---[ end trace 810af3dad648a902 ]---
> Segmentation fault
>
> Looks like with pci_disable_device() it may take a rather strange
> path...
Yikes... it has no business at all calling pci_disable_device() on
Tegra. Unless if you happen to have a GPU plugged into the PCIe slot.
I'm assuming that's not what you're doing?
I'll see if I can reproduce (and fix) that crash on unload. Admittedly
it's not something that I regularly test. Perhaps that's something that
I should change...
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 09/17] drm/sun4i: sun6i_mipi_dsi: Fix DSI hblk timing calculation
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
hblk is adding line with all porch timing values, or timings
values from htotal without sync time.
Current driver is subtracting htotal with hsa, but the hsa
is bounded with packet overhead. For real hblk calculation
needed by subtracting htotal with back and front porch values
and BSP code BPI-M64-bsp is eventually following the same.
BPI-M64-bsp is computing hbp as (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2);
=> (timmings->hor_total_time - timmings->hor_sync_time)
=> (mode->htotal - (mode->hsync_end - mode->hsync_start))
So, update the DSI hblk timing accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 81151d7633f9..4c95b3384ed9 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -495,7 +495,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
/*
* hblk seems to be the line + porches length.
*/
- hblk = mode->htotal * Bpp - hsa;
+ hblk = (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp;
/*
* And I'm not entirely sure what vblk is about. The driver in
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 17/17] arm64: dts: allwinner: a64: Add DSI pipeline
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
The A64 has a MIPI-DSI block which is similar to A31
without mod clock.
So, add dsi node with A64 compatible, dphy node with
A31 compatible and finally connect dsi to tcon0 to
make proper DSI pipeline.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index dd5740bc3fc9..dd5c7ad55149 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -344,6 +344,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ tcon0_out_dsi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dsi_in_tcon0>;
+ allwinner,tcon-channel = <1>;
+ };
};
};
};
@@ -910,6 +916,45 @@
status = "disabled";
};
+ dsi: dsi@1ca0000 {
+ compatible = "allwinner,sun50i-a64-mipi-dsi";
+ reg = <0x01ca0000 0x1000>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_MIPI_DSI>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_MIPI_DSI>;
+ phys = <&dphy>;
+ phy-names = "dphy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dsi_in_tcon0: endpoint {
+ remote-endpoint = <&tcon0_out_dsi>;
+ };
+ };
+ };
+ };
+
+ dphy: d-phy@1ca1000 {
+ compatible = "allwinner,sun50i-a64-mipi-dphy",
+ "allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01ca1000 0x1000>;
+ clocks = <&ccu CLK_BUS_MIPI_DSI>,
+ <&ccu CLK_DSI_DPHY>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_MIPI_DSI>;
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
csi: csi@1cb0000 {
compatible = "allwinner,sun50i-a64-csi";
reg = <0x01cb0000 0x1000>;
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 16/17] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
The MIPI DSI PHY HDMI controller on Allwinner A64 is similar
on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index adc7cdf129dd..08f1f57abff5 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -40,6 +40,7 @@ D-PHY
Required properties:
- compatible: value must be one of:
* allwinner,sun6i-a31-mipi-dphy
+ * "allwinner,sun50i-a64-mipi-dphy", "allwinner,sun6i-a31-mipi-dphy"
- reg: base address and size of memory-mapped region
- clocks: phandles to the clocks feeding the DSI encoder
* bus: the DSI interface clock
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 13/17] drm/sun4i: sun6i_mipi_dsi: Add support for VCC-DSI voltage regulator
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Some boards have VCC-DSI pin connected to voltage regulator which may
not be turned on by default.
Add support for such boards by adding voltage regulator handling code to
MIPI DSI driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++++++++++++++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index cbcef7bf7681..a87b65fff0e0 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1023,6 +1023,12 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
+ dsi->regulator = devm_regulator_get(dev, "vcc-dsi");
+ if (IS_ERR(dsi->regulator)) {
+ dev_err(dev, "Couldn't get VCC-DSI supply\n");
+ return PTR_ERR(dsi->regulator);
+ }
+
dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base,
&sun6i_dsi_regmap_config);
if (IS_ERR(dsi->regs)) {
@@ -1104,6 +1110,13 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev)
{
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
+ int err;
+
+ err = regulator_enable(dsi->regulator);
+ if (err) {
+ dev_err(dsi->dev, "failed to enable VCC-DSI supply: %d\n", err);
+ return err;
+ }
reset_control_deassert(dsi->reset);
if (dsi->variant->has_mod_clk)
@@ -1138,6 +1151,7 @@ static int __maybe_unused sun6i_dsi_runtime_suspend(struct device *dev)
if (dsi->variant->has_mod_clk)
clk_disable_unprepare(dsi->mod_clk);
reset_control_assert(dsi->reset);
+ regulator_disable(dsi->regulator);
return 0;
}
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index 597b62227019..0df60f84bab3 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -13,6 +13,8 @@
#include <drm/drm_encoder.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/regulator/consumer.h>
+
struct sun6i_dphy {
struct clk *bus_clk;
struct clk *mod_clk;
@@ -32,6 +34,7 @@ struct sun6i_dsi {
struct clk *bus_clk;
struct clk *mod_clk;
struct regmap *regs;
+ struct regulator *regulator;
struct reset_control *reset;
struct sun6i_dphy *dphy;
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 12/17] drm/sun4i: sun6i_mipi_dsi: Set proper vblk timing calculation
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Unlike hblk, the vblk timings should follow an equation to compute
the desired value for lane 4 devices and rest of devices it would be 0.
BSP code from BPI-M64-bsp is computing vblk as for 4-lane devices
(from linux-sunxi
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
tmp = (ht*dsi_pixel_bits[format]/8)*vt-(4+dsi_hblk+2);
dsi_vblk = (lane-tmp%lane);
So, update the vblk timing calculation accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 29 +++++++++++++++++++-------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index d8947be92f9d..cbcef7bf7681 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -355,6 +355,27 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
SUN6I_DSI_INST_JUMP_CFG_NUM(1));
};
+static u16 sun6i_dsi_get_timings_vblk(struct sun6i_dsi *dsi,
+ struct drm_display_mode *mode, u16 hblk)
+{
+ struct mipi_dsi_device *device = dsi->device;
+ unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
+ int tmp;
+
+ if (device->lanes != 4)
+ return 0;
+
+ /*
+ * The vertical blank is set using a blanking packet (4 bytes +
+ * payload + 2 bytes). Its minimal size is therefore 6 bytes
+ */
+#define VBLK_PACKET_OVERHEAD 6
+ tmp = (mode->htotal * Bpp) * mode->vtotal -
+ (hblk + VBLK_PACKET_OVERHEAD);
+
+ return (device->lanes - tmp % device->lanes);
+}
+
static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
@@ -503,13 +524,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
(mode->htotal - (mode->hsync_end - mode->hsync_start)) *
Bpp - HBLK_PACKET_OVERHEAD);
- /*
- * And I'm not entirely sure what vblk is about. The driver in
- * Allwinner BSP is using a rather convoluted calculation
- * there only for 4 lanes. However, using 0 (the !4 lanes
- * case) even with a 4 lanes screen seems to work...
- */
- vblk = 0;
+ vblk = sun6i_dsi_get_timings_vblk(dsi, mode, hblk);
/* How many bytes do we need to send all payloads? */
bytes = max_t(size_t, max(max(hfp, hblk), max(hsa, hbp)), vblk);
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 14/17] dt-bindings: sun6i-dsi: Add VCC-DSI supply property
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Most of the Allwinner MIPI DSI controllers are supply with
VCC-DSI pin. which need to supply for some of the boards to
trigger the power.
So, document the supply property so-that the required board
can eable it via device tree.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index 9fa6e7a758ad..adc7cdf129dd 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -28,6 +28,9 @@ Required properties:
first port should be the input endpoint, usually coming from the
associated TCON.
+Optional properties:
+ - vcc-dsi-supply: the VCC-DSI power supply of the DSI encoder
+
Any MIPI-DSI device attached to this should be described according to
the bindings defined in ../mipi-dsi-bus.txt
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 08/17] drm/sun4i: sun6i_mipi_dsi: Fix DSI hbp timing value
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Current driver is calculating hbp maximum value by subtracting
hsync_start with hdisplay which is front porch value, but the
hbp refers to back porch.
Back porch value is calculating by subtracting htotal with
hsync_end as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually following the same.
BPI-M64-bsp is computing hbp as
(in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2);
=> (panel->lcd_hbp - timmings->hor_sync_time)
=> (timmings->hor_back_porch + timmings->hor_sync_time -
timmings->hor_sync_time)
=> timmings->hor_back_porch
=> mode->htotal - mode->hsync_end
So, update the MIPI-DSI hbp value accordingly.
Tested on 2-lane, 4-lane DSI LCD panels.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index cb41fea4f3ee..81151d7633f9 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -482,7 +482,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
*/
#define HBP_PACKET_OVERHEAD 6
hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
- (mode->hsync_start - mode->hdisplay) * Bpp - HBP_PACKET_OVERHEAD);
+ (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD);
/*
* The frontporch is set using a blanking packet (4 bytes +
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 11/17] drm/sun4i: sun6i_mipi_dsi: Fix DSI hfp timing value
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Current driver is calculating hfp maximum value by subtracting
htotal with hsync_end which is front back value, but the
hpp refers to front porch.
Front porch value is calculating by subtracting hsync_start with
hdisplay as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually following the same.
BPI-M64-bsp is computing hfp as (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hbp = (hbp-hspw)*dsi_pixel_bits[format]/8 - (4+2);
dsi_hact = x * dsi_pixel_bits[format]/8;
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2);
dsi_hfp = dsi_hblk - (4+dsi_hact+2) - (4+dsi_hbp+2);
Example,
u32 fmt = dsi_pixel_bits[format]/8;
=> ((ht-hspw)*fmt - 10) - (6 + x * fmt) - (6 + (hbp-hspw)*fmt - 6)
=> (ht - hspw - x - (hbp - hspw)) * fmt - 16
=> (ht - x - hbp) * fmt - 16
=> (ht - x - (timmings->hor_total_time - timmings->hor_front_porch - x)
* fmt - 16
=> (timmings->hor_total_time - x - timmings->hor_total_time +
timmings->hor_front_porch + x) * fmt - 16
=> timmings->hor_front_porch * fmt - 16
So, update the DSI hfp timing accordingly.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 07eba9ec469b..d8947be92f9d 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -490,7 +490,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
*/
#define HFP_PACKET_OVERHEAD 6
hfp = max((unsigned int)HFP_PACKET_OVERHEAD,
- (mode->htotal - mode->hsync_end) * Bpp - HFP_PACKET_OVERHEAD);
+ (mode->hsync_start - mode->hdisplay) * Bpp -
+ HFP_PACKET_OVERHEAD);
/*
* hblk seems to be the line + porches length.
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Video start delay can be computed by subtracting total vertical
timing with front porch timing and with adding 1 delay line for TCON.
BSP code form BPI-M64-bsp is computing video start delay as
(from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
=> (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
=> (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
- panel->lcd_y - (panel->lcd_vbp)
=> timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
- panel->lcd_y - panel->lcd_vbp
=> timmings->ver_front_porch
So, update the start delay computation accordingly.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index c9b0222ebcd4..cb41fea4f3ee 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -358,7 +358,17 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
struct drm_display_mode *mode)
{
- return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
+ u32 vfp = mode->vsync_start - mode->vdisplay;
+ u32 start_delay;
+
+ start_delay = mode->vtotal - vfp + 1;
+ if (start_delay > mode->vtotal)
+ start_delay -= mode->vtotal;
+
+ if (!start_delay)
+ start_delay = 1;
+
+ return start_delay;
}
static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 10/17] drm/sun4i: sun6i_mipi_dsi: Add DSI hblk packet overhead
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Add 10 bytes packet overhead for hblk where blank is set using
a blanking packet like (4 bytes + 4 bytes + payload + 2 bytes)
This is according to BSP code from BPI-M64-bsp (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
dsi_hblk = (ht-hspw)*dsi_pixel_bits[format]/8-(4+4+2);
So, add 10 bytes packet overhead for DSI hblk.
Tested on 2-lane, 4-lane MIPI-DSI LCD panels.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 4c95b3384ed9..07eba9ec469b 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -494,8 +494,13 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
/*
* hblk seems to be the line + porches length.
+ * The blank is set using a blanking packet (4 bytes + 4 bytes +
+ * payload + 2 bytes). So minimal size is 10 bytes
*/
- hblk = (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp;
+#define HBLK_PACKET_OVERHEAD 10
+ hblk = max((unsigned int)HBLK_PACKET_OVERHEAD,
+ (mode->htotal - (mode->hsync_end - mode->hsync_start)) *
+ Bpp - HBLK_PACKET_OVERHEAD);
/*
* And I'm not entirely sure what vblk is about. The driver in
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 06/17] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
TCON DRQ set bits for non-burst DSI mode can computed via
horizontal front porch instead of front porch + sync timings.
BSP code form BPI-M64-bsp is computing TCON DRQ set bits
for non-burts as (from linux-sunxi/
drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
=> panel->lcd_ht - panel->lcd_x - panel->lcd_hbp
=> (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
- panel->lcd_x - panel->hbp
=> timmings->hor_front_porch
=> mode->hsync_start - mode->hdisplay
So, update the DRQ set bits accordingly.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index cdd44a1307b3..c9b0222ebcd4 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -367,9 +367,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
struct mipi_dsi_device *device = dsi->device;
u32 val = 0;
- if ((mode->hsync_end - mode->hdisplay) > 20) {
+ if ((mode->hsync_start - mode->hdisplay) > 20) {
/* Maaaaaagic */
- u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
+ u16 drq = (mode->hsync_start - mode->hdisplay) - 20;
drq *= mipi_dsi_pixel_format_to_bpp(device->format);
drq /= 32;
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 04/17] dt-bindings: sun6i-dsi: Add compatible for A64 MIPI DSI
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
The MIPI DSI controller on Allwinner A64 is similar to
Allwinner A31 without support of DSI mod clock.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
index 6a6cf5de08b0..9fa6e7a758ad 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
@@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's.
Required properties:
- compatible: value must be one of:
* allwinner,sun6i-a31-mipi-dsi
+ * allwinner,sun50i-a64-mipi-dsi
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the DSI encoder
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 05/17] drm/sun4i: sun6i_mipi_dsi: Add DSI Generic short write 2 param transfer
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Short transfer write support for DCS and Generic transfer types
share similar way to process command sequence in DSI block so
add generic write 2 param transfer type macro so-that the panels
which are requesting similar transfer type may process properly.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 50f535ae57e9..cdd44a1307b3 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -871,6 +871,7 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host *host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
ret = sun6i_dsi_dcs_write_short(dsi, msg);
break;
--
2.18.0.321.gffc6fa0e3
_______________________________________________
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 v5 02/17] drm/sun4i: sun6i_mipi_dsi: Add has_mod_clk quirk
From: Jagan Teki @ 2018-12-10 16:17 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Turquette, Stephen Boyd
Cc: linux-kernel, dri-devel, linux-sunxi, Jagan Teki,
Michael Trimarchi, linux-amarula, linux-clk, linux-arm-kernel
In-Reply-To: <20181210161729.29720-1-jagan@amarulasolutions.com>
Mod clock is not mandatory for all Allwinner MIPI DSI
controllers, it is connected as CLK_DSI_SCLK for A31
and not available in A64.
So add has_mod_clk quirk and process the clk accordingly.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 39 ++++++++++++++++++--------
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 5 ++++
2 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index e3b34a345546..561de393ea23 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -10,6 +10,7 @@
#include <linux/component.h>
#include <linux/crc-ccitt.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
@@ -981,6 +982,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
dsi->host.ops = &sun6i_dsi_host_ops;
dsi->host.dev = dev;
+ dsi->variant = of_device_get_match_data(dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base)) {
@@ -1001,17 +1004,20 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->reset);
}
- dsi->mod_clk = devm_clk_get(dev, "mod");
- if (IS_ERR(dsi->mod_clk)) {
- dev_err(dev, "Couldn't get the DSI mod clock\n");
- return PTR_ERR(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk) {
+ dsi->mod_clk = devm_clk_get(dev, "mod");
+ if (IS_ERR(dsi->mod_clk)) {
+ dev_err(dev, "Couldn't get the DSI mod clock\n");
+ return PTR_ERR(dsi->mod_clk);
+ }
}
/*
* In order to operate properly, that clock seems to be always
* set to 297MHz.
*/
- clk_set_rate_exclusive(dsi->mod_clk, 297000000);
+ if (dsi->variant->has_mod_clk)
+ clk_set_rate_exclusive(dsi->mod_clk, 297000000);
dphy_node = of_parse_phandle(dev->of_node, "phys", 0);
ret = sun6i_dphy_probe(dsi, dphy_node);
@@ -1043,7 +1049,8 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
pm_runtime_disable(dev);
sun6i_dphy_remove(dsi);
err_unprotect_clk:
- clk_rate_exclusive_put(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_rate_exclusive_put(dsi->mod_clk);
return ret;
}
@@ -1056,7 +1063,8 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
mipi_dsi_host_unregister(&dsi->host);
pm_runtime_disable(dev);
sun6i_dphy_remove(dsi);
- clk_rate_exclusive_put(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_rate_exclusive_put(dsi->mod_clk);
return 0;
}
@@ -1066,7 +1074,8 @@ static int __maybe_unused sun6i_dsi_runtime_resume(struct device *dev)
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
reset_control_deassert(dsi->reset);
- clk_prepare_enable(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_prepare_enable(dsi->mod_clk);
/*
* Enable the DSI block.
@@ -1094,7 +1103,8 @@ static int __maybe_unused sun6i_dsi_runtime_suspend(struct device *dev)
{
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
- clk_disable_unprepare(dsi->mod_clk);
+ if (dsi->variant->has_mod_clk)
+ clk_disable_unprepare(dsi->mod_clk);
reset_control_assert(dsi->reset);
return 0;
@@ -1106,9 +1116,16 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
NULL)
};
+static const struct sun6i_dsi_variant sun6i_a31_dsi = {
+ .has_mod_clk = true,
+};
+
static const struct of_device_id sun6i_dsi_of_table[] = {
- { .compatible = "allwinner,sun6i-a31-mipi-dsi" },
- { }
+ {
+ .compatible = "allwinner,sun6i-a31-mipi-dsi",
+ .data = &sun6i_a31_dsi,
+ },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
index dbbc5b3ecbda..597b62227019 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
@@ -20,6 +20,10 @@ struct sun6i_dphy {
struct reset_control *reset;
};
+struct sun6i_dsi_variant {
+ bool has_mod_clk;
+};
+
struct sun6i_dsi {
struct drm_connector connector;
struct drm_encoder encoder;
@@ -35,6 +39,7 @@ struct sun6i_dsi {
struct sun4i_drv *drv;
struct mipi_dsi_device *device;
struct drm_panel *panel;
+ const struct sun6i_dsi_variant *variant;
};
static inline struct sun6i_dsi *host_to_sun6i_dsi(struct mipi_dsi_host *host)
--
2.18.0.321.gffc6fa0e3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox