* [PATCH v2 1/3] dmaengine: imx-sdma: fix buffer ownership
From: Philipp Puschmann @ 2019-09-19 10:23 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
In-Reply-To: <20190919102319.23368-1-philipp.puschmann@emlix.com>
BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the
buffer, when 0 ARM owns it. When processing the buffers in
sdma_update_channel_loop the ownership of the currently processed
buffer was set to SDMA again before running the callback function of
the buffer and while the sdma script may be running in parallel. So
there was the possibility to get the buffer overwritten by SDMA before
it has been processed by kernel leading to kind of random errors in the
upper layers, e.g. bluetooth.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
Changelog v2:
- add dma_wb()
drivers/dma/imx-sdma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 9ba74ab7e912..e029a2443cfc 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
*/
desc->chn_real_count = bd->mode.count;
- bd->mode.status |= BD_DONE;
bd->mode.count = desc->period_len;
desc->buf_ptail = desc->buf_tail;
desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
@@ -817,6 +816,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
spin_lock(&sdmac->vc.lock);
+ dma_wb();
+ bd->mode.status |= BD_DONE;
+
if (error)
sdmac->status = old_status;
}
--
2.23.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
* [PATCH v2 0/3] Fix UART DMA freezes for i.MX SOCs
From: Philipp Puschmann @ 2019-09-19 10:23 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
For some years and since many kernel versions there are reports that
RX UART DMA channel stops working at one point. So far the usual
workaround was to disable RX DMA. This patches fix the underlying
problem.
When a running sdma script does not find any usable destination buffer
to put its data into it just leads to stopping the channel being
scheduled again. As solution we manually retrigger the sdma script for
this channel and by this dissolve the freeze.
While this seems to work fine so far, it may come to buffer overruns
when the channel - even temporary - is stopped. This case has to be
addressed by device drivers by increasing the number of DMA periods.
This patch series was tested with the current kernel and backported to
kernel 4.15 with a special use case using a WL1837MOD via UART and
provoking the hanging of UART RX DMA within seconds after starting a
test application. It resulted in well known
"Bluetooth: hci0: command 0x0408 tx timeout"
errors and complete stop of UART data reception. Our Bluetooth traffic
consists of many independent small packets, mostly only a few bytes,
causing high usage of periods.
Changelog v2:
- adapt title (this patches are not only for i.MX6)
- improve some comments and patch descriptions
- add a dma_wb() around BD_DONE flag
- add Reviewed-by tags
- split off "serial: imx: adapt rx buffer and dma periods"
Philipp Puschmann (3):
dmaengine: imx-sdma: fix buffer ownership
dmaengine: imx-sdma: fix dma freezes
dmaengine: imx-sdma: drop redundant variable
drivers/dma/imx-sdma.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net] net: stmmac: selftests: Flow Control test can also run with ASYM Pause
From: Jose Abreu @ 2019-09-19 10:09 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
The Flow Control selftest is also available with ASYM Pause. Lets add
this check to the test and fix eventual false positive failures.
Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index c56e89e1ae56..4b4b03245f6e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -670,7 +670,7 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
unsigned int pkt_count;
int i, ret = 0;
- if (!phydev || !phydev->pause)
+ if (!phydev || (!phydev->pause && !phydev->asym_pause))
return -EOPNOTSUPP;
tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
--
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
* Re: [PATCH 2/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk
From: Schrempf Frieder @ 2019-09-19 10:04 UTC (permalink / raw)
To: Anson Huang, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Leonard Crestez,
daniel.lezcano@linaro.org, Jacky Bai, Daniel Baluta, Jun Li,
l.stach@pengutronix.de, Abel Vesa, andrew.smirnov@gmail.com,
angus@akkea.ca, ccaione@baylibre.com, agx@sigxcpu.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB3916B0DE9EBC0B0F6664CE34F5890@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Hi Anson,
On 19.09.19 11:31, Anson Huang wrote:
> Hi, Schrempf
>
>> Hi Anson,
>>
>> I have a question, that is not directly related to this patch.
>> I see that for the usdhc1 and usdhc3 nodes, there is an 'assigned-clock'
>> and 'assigned-clock-rates' property but not for usdhc2. The same applies to
>> the mx8mq and mx8mn dtsi file.
>>
>> Is there any reason for this? If not can you fix it?
>
> This patch series is NOT related to 'assigned-clock' or 'assigned-clock-rates'
> property,
That's exactly what I'm saying. To not cause more confusion, I have sent
a message in a new thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-September/681426.html
> it is just for correcting clock source according to reference manual,
> the 'ipg' clock is from system's IPG_ROOT clock according to reference manual CCM
> chapter, using DUMMY clock is NOT a good option, the 'ipg' clock is supposed
> to be the clock for accessing register, and it should NOT be DUMMY if we know
> what exactly the clock source is used.
That's probably right and I didn't mean to question the patch at all.
Thanks,
Frieder
_______________________________________________
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] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Uwe Kleine-König @ 2019-09-19 10:03 UTC (permalink / raw)
To: Kamel Bouhara
Cc: linux-pwm, Alexandre Belloni, Gregory Clement, linux-kernel,
Ludovic Desroches, Thierry Reding, Thomas Petazzoni,
Claudiu Beznea, linux-arm-kernel
In-Reply-To: <20190918145716.32022-1-kamel.bouhara@bootlin.com>
On Wed, Sep 18, 2019 at 04:57:16PM +0200, Kamel Bouhara wrote:
> Since commit 26202873bb51 ("avr32: remove support for AVR32
> architecture") there is no more user of platform_device_id and we
> should only use dt bindings
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: Missing 'assigned-clocks' in usdhc node of i.MX8MQ/MM/MN dtsi?
From: Anson Huang @ 2019-09-19 10:01 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, Fabio Estevam,
Leonard Crestez, daniel.lezcano@linaro.org, Jacky Bai,
Daniel Baluta, Jun Li, l.stach@pengutronix.de, Abel Vesa,
andrew.smirnov@gmail.com, angus@akkea.ca, ccaione@baylibre.com,
agx@sigxcpu.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx
In-Reply-To: <e6ce599e-597a-6f67-d5d1-5487f50c7d0d@kontron.de>
Hi, Schrempf
> Hi,
>
> I wonder why imx8mq.dtsi, imx8mm.dtsi and imx8mn.dtsi have 'assigned-
> clocks' and 'assigned-clock-rates' set for all usdhc nodes, except for usdhc2.
>
> Is this on purpose? Is it a flaw?
I don't think it is on purpose, it should be a flaw, I will double check with our usdhc owner,
if it is indeed a flaw, we will summit a patch to fix it, thanks for reminder.
Thanks,
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Missing 'assigned-clocks' in usdhc node of i.MX8MQ/MM/MN dtsi?
From: Schrempf Frieder @ 2019-09-19 9:56 UTC (permalink / raw)
To: Anson Huang, Rob Herring, Mark Rutland, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, Fabio Estevam,
leonard.crestez@nxp.com, daniel.lezcano@linaro.org,
ping.bai@nxp.com, daniel.baluta@nxp.com, jun.li@nxp.com,
l.stach@pengutronix.de, abel.vesa@nxp.com,
andrew.smirnov@gmail.com, angus@akkea.ca, ccaione@baylibre.com,
agx@sigxcpu.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, NXP Linux Team
Hi,
I wonder why imx8mq.dtsi, imx8mm.dtsi and imx8mn.dtsi have
'assigned-clocks' and 'assigned-clock-rates' set for all usdhc nodes,
except for usdhc2.
Is this on purpose? Is it a flaw?
Thanks,
Frieder
Extract from imx8mm.dtsi:
usdhc1: mmc@30b40000 {
[...]
assigned-clocks = <&clk IMX8MM_CLK_USDHC1>;
assigned-clock-rates = <400000000>;
[...]
};
usdhc2: mmc@30b50000 {
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b50000 0x10000>;
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_DUMMY>,
<&clk IMX8MM_CLK_NAND_USDHC_BUS>,
<&clk IMX8MM_CLK_USDHC2_ROOT>;
clock-names = "ipg", "ahb", "per";
fsl,tuning-start-tap = <20>;
fsl,tuning-step= <2>;
bus-width = <4>;
status = "disabled";
};
usdhc3: mmc@30b60000 {
[...]
assigned-clocks = <&clk IMX8MM_CLK_USDHC3_ROOT>;
assigned-clock-rates = <400000000>;
[...]
};
_______________________________________________
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] arm64: dts: imx8mm-evk: Enable pca6416 on i2c3 bus
From: Anson Huang @ 2019-09-19 9:46 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.baluta, ping.bai, jun.li, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1568886408-18168-1-git-send-email-Anson.Huang@nxp.com>
Enable pca6416 on i.MX8MM EVK board's i2c3 bus.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 7758c1c..c3189f2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -311,6 +311,13 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
+
+ pca6416: gpio@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
&iomuxc {
--
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/2] arm64: dts: imx8mm-evk: Add i2c3 support
From: Anson Huang @ 2019-09-19 9:46 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
leonard.crestez, daniel.baluta, ping.bai, jun.li, devicetree,
linux-arm-kernel, linux-kernel
Cc: Linux-imx
Enable i2c3 for i.MX8MM EVK board.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index f7a15f3..7758c1c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -306,6 +306,13 @@
};
};
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
&iomuxc {
pinctrl-names = "default";
@@ -355,6 +362,13 @@
>;
};
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3
+ >;
+ };
+
pinctrl_pmic: pmicirq {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
--
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
* Re: [PATCH] arm64: dts: meson: Add capacity-dmips-mhz attributes to G12B
From: Neil Armstrong @ 2019-09-19 9:47 UTC (permalink / raw)
To: Christian Hewitt, Rob Herring, Mark Rutland, Kevin Hilman,
devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Frank Hartung
In-Reply-To: <1568429380-3231-1-git-send-email-christianshewitt@gmail.com>
On 14/09/2019 04:49, Christian Hewitt wrote:
> From: Frank Hartung <supervisedthinking@gmail.com>
>
> From: Frank Hartung <supervisedthinking@gmail.com>
>
> Meson G12B SoCs (S922X and A311D) are a big-little design where not all CPUs
> are equal; the A53s cores are weaker than the A72s.
>
> Include capacity-dmips-mhz properties to tell the OS there is a difference
> in processing capacity. The dmips values are based on similar submissions for
> other A53/A72 SoCs: HiSilicon 3660 [1] and Rockchip RK3399 [2].
>
> This change is particularly beneficial for use-cases like retro gaming where
> emulators often run on a single core. The OS now chooses an A72 core instead
> of an A53 core.
>
> [1] https://lore.kernel.org/patchwork/patch/862742/
> [2] https://patchwork.kernel.org/patch/10836577/
>
> Signed-off-by: Frank Hartung <supervisedthinking@gmail.com>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> index 5628ccd..7f78d88 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> @@ -49,6 +49,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + capacity-dmips-mhz = <592>;
> next-level-cache = <&l2>;
> };
>
> @@ -57,6 +58,7 @@
> compatible = "arm,cortex-a53";
> reg = <0x0 0x1>;
> enable-method = "psci";
> + capacity-dmips-mhz = <592>;
> next-level-cache = <&l2>;
> };
>
> @@ -65,6 +67,7 @@
> compatible = "arm,cortex-a73";
> reg = <0x0 0x100>;
> enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <&l2>;
> };
>
> @@ -73,6 +76,7 @@
> compatible = "arm,cortex-a73";
> reg = <0x0 0x101>;
> enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <&l2>;
> };
>
> @@ -81,6 +85,7 @@
> compatible = "arm,cortex-a73";
> reg = <0x0 0x102>;
> enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <&l2>;
> };
>
> @@ -89,6 +94,7 @@
> compatible = "arm,cortex-a73";
> reg = <0x0 0x103>;
> enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> next-level-cache = <&l2>;
> };
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.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: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Jianyong Wu (Arm Technology China) @ 2019-09-19 9:46 UTC (permalink / raw)
To: Paolo Bonzini, netdev@vger.kernel.org, yangbo.lu@nxp.com,
john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: Justin He (Arm Technology China), kvm@vger.kernel.org,
Steve Capper, linux-kernel@vger.kernel.org,
Kaly Xin (Arm Technology China), nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <629538ea-13fb-e666-8df6-8ad23f114755@redhat.com>
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, September 18, 2019 6:24 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>; Will
> Deacon <Will.Deacon@arm.com>; Suzuki Poulose
> <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
> > Hi Paolo,
> >
> >> On 18/09/19 10:07, Jianyong Wu wrote:
> >>> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> >>> + getnstimeofday(ts);
> >>
> >> This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and
> >> split the 64-bit seconds value between val[0] and val[1].
> >>
> > As far as I know, y2038-safe will only affect signed 32-bit integer,
> > how does it affect 64-bit integer?
> > And why split 64-bit number into two blocks is necessary?
>
> val is an u32, not an u64. (And val[0], where you store the seconds, is best
> treated as signed, since val[0] == -1 is returned for
> SMCCC_RET_NOT_SUPPORTED).
>
Yeah, need consider twice.
Val[] should be long not u32 I think, so in arm64 I can avoid that Y2038_safe, but
also need rewrite for arm32.
> >> However, it seems to me that the new function is not needed and you
> >> can just use ktime_get_snapshot. You'll get the time in
> >> systime_snapshot->real and the cycles value in systime_snapshot->cycles.
> >
> > See patch 5/6, I need both counter cycle and clocksource,
> ktime_get_snapshot seems only offer cycles.
>
> No, patch 5/6 only needs the current clock (ptp_sc.cycles is never accessed).
> So you could just use READ_ONCE(tk->tkr_mono.clock).
>
Yeah, patch 5/6 just need clocksource, but I think tk->tkr_mono.clock can't read in external like module,
So I need an API to expose clocksource.
> However, even then I don't think it is correct to use ptp_sc.cs blindly in patch
> 5. I think there is a misunderstanding on the meaning of
> system_counterval.cs as passed to get_device_system_crosststamp.
> system_counterval.cs is not the active clocksource; it's the clocksource on
> which system_counterval.cycles is based.
>
I think we can use system_counterval_t as pass current clocksource to system_counterval_t.cs and its
corresponding cycles to system_counterval_t.cycles. is it a big problem?
> Hypothetically, the clocksource could be one for which ptp_sc.cycles is _not_
> a cycle value. If you set system_counterval.cs to the system clocksource,
> get_device_system_crosststamp will return a bogus value.
Yeah, but in patch 3/6, we have a corresponding pair of clock source and cycle value. So I think there will be no
that problem in this patch set.
In the implementation of get_device_system_crosststamp:
"
...
if (tk->tkr_mono.clock != system_counterval.cs)
return -ENODEV;
...
"
We need tk->tkr_mono.clock passed to get_device_system_crosststamp, just like patch 3/6 do, otherwise will return error.
> So system_counterval.cs should be set to something like
> &clocksource_counter (from drivers/clocksource/arm_arch_timer.c).
> Perhaps the right place to define kvm_arch_ptp_get_clock_fn is in that file?
>
I have checked that ptp_sc.cs is arch_sys_counter.
Also move the module API to arm_arch_timer.c will looks a little ugly and it's not easy to be accept by arm side I think.
> >>> + get_current_counterval(&sc);
> >>> + val[0] = ts->tv_sec;
> >>> + val[1] = ts->tv_nsec;
> >>> + val[2] = sc.cycles;
> >>> + val[3] = 0;
> >>> + break;
> >>
> >> This should return a guest-cycles value. If the cycles values always
> >> the same between the host and the guest on ARM, then okay. If not,
> >> you have to apply whatever offset exists.
> >>
> > In my opinion, when use ptp_kvm as clock sources to sync time between
> > host and guest, user should promise the guest and host has no clock
> > offset.
>
> What would be the adverse effect of having a fixed offset between guest
> and host? If there were one, you'd have to check that and fail the hypercall if
> there is an offset. But again, I think it's enough to subtract
> vcpu_vtimer(vcpu)->cntvoff or something like that.
>
Sure, counter offset should be considered.
> You also have to check here that the clocksource is based on the ARM
> architectural timer. Again, maybe you could place the implementation in
> drivers/clocksource/arm_arch_timer.c, and make it return -ENODEV if the
> active clocksource is not clocksource_counter. Then KVM can look for errors
> and return SMCCC_RET_NOT_SUPPORTED in that case.
I have checked it. The clock source is arch_sys_counter which is arm arch timer.
I can try to do that but I'm not sure arm side will be happy for that change.
Thanks
Jianyong Wu
>
> Thanks,
>
> Paolo
>
> > So we can be sure that the cycle between guest and host should be keep
> > consistent. But I need check it.
> > I think host cycle should be returned to guest as we should promise we
> > get clock and counter in the same time.
_______________________________________________
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 4/5] platform: mtk-isp: Add Mediatek DIP driver
From: Tomasz Figa @ 2019-09-19 9:44 UTC (permalink / raw)
To: Frederic Chen
Cc: Shik Chen, devicetree, Sean Cheng (鄭昇弘),
Laurent Pinchart, Rynn Wu (吳育恩),
Christie Yu (游雅惠), srv_heupstream,
Allan Yang (楊智鈞),
Holmes Chiou (邱挺), suleiman, Jerry-ch Chen,
Jungo Lin (林明俊), Sj Huang, yuzhao,
Hans Verkuil, zwisler, Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1568886066.19171.16.camel@mtksdccf07>
On Thu, Sep 19, 2019 at 6:41 PM Frederic Chen
<frederic.chen@mediatek.com> wrote:
>
> Dear Tomasz,
>
>
> On Thu, 2019-09-12 at 14:58 +0900, Tomasz Figa wrote:
> > On Thu, Sep 12, 2019 at 2:41 AM Frederic Chen
> > <frederic.chen@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > I appreciate your helpful comments.
> > >
> > >
> > > On Tue, 2019-09-10 at 13:04 +0900, Tomasz Figa wrote:
> > > > Hi Frederic,
> > > >
> > > > On Tue, Sep 10, 2019 at 4:23 AM <frederic.chen@mediatek.com> wrote:
> > > > >
> > > > > From: Frederic Chen <frederic.chen@mediatek.com>
> > > > >
> > > > > This patch adds the driver of Digital Image Processing (DIP)
> > > > > unit in Mediatek ISP system, providing image format
> > > > > conversion, resizing, and rotation features.
> > > > >
> > > > > The mtk-isp directory will contain drivers for multiple IP
> > > > > blocks found in Mediatek ISP system. It will include ISP
> > > > > Pass 1 driver(CAM), sensor interface driver, DIP driver and
> > > > > face detection driver.
> > > > >
> > > > > Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
> > > > > ---
> > > > > drivers/media/platform/mtk-isp/Makefile | 7 +
> > > > > .../media/platform/mtk-isp/isp_50/Makefile | 7 +
> > > > > .../platform/mtk-isp/isp_50/dip/Makefile | 18 +
> > > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.c | 650 +++++
> > > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.h | 566 +++++
> > > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-hw.h | 156 ++
> > > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-sys.c | 521 ++++
> > > > > .../mtk-isp/isp_50/dip/mtk_dip-v4l2.c | 2255 +++++++++++++++++
> > > > > 8 files changed, 4180 insertions(+)
> > > > > create mode 100644 drivers/media/platform/mtk-isp/Makefile
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/Makefile
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/Makefile
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.c
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.h
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-hw.h
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c
> > > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-v4l2.c
> > > > >
> > > >
> > > > Thanks for sending v3!
> > > >
> > > > I'm going to do a full review a bit later, but please check one
> > > > comment about power handling below.
> > > >
> > > > Other than that one comment, from a quick look, I think we only have a
> > > > number of style issues left. Thanks for the hard work!
> > > >
> > > > [snip]
> > > > > +static void dip_runner_func(struct work_struct *work)
> > > > > +{
> > > > > + struct mtk_dip_request *req = mtk_dip_hw_mdp_work_to_req(work);
> > > > > + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> > > > > + struct img_config *config_data =
> > > > > + (struct img_config *)req->working_buf->config_data.vaddr;
> > > > > +
> > > > > + /*
> > > > > + * Call MDP/GCE API to do HW excecution
> > > > > + * Pass the framejob to MDP driver
> > > > > + */
> > > > > + pm_runtime_get_sync(dip_dev->dev);
> > > > > + mdp_cmdq_sendtask(dip_dev->mdp_pdev, config_data,
> > > > > + &req->img_fparam.frameparam, NULL, false,
> > > > > + dip_mdp_cb_func, req);
> > > > > +}
> > > > [snip]
> > > > > +static void dip_composer_workfunc(struct work_struct *work)
> > > > > +{
> > > > > + struct mtk_dip_request *req = mtk_dip_hw_fw_work_to_req(work);
> > > > > + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> > > > > + struct img_ipi_param ipi_param;
> > > > > + struct mtk_dip_hw_subframe *buf;
> > > > > + int ret;
> > > > > +
> > > > > + down(&dip_dev->sem);
> > > > > +
> > > > > + buf = mtk_dip_hw_working_buf_alloc(req->dip_pipe->dip_dev);
> > > > > + if (!buf) {
> > > > > + dev_err(req->dip_pipe->dip_dev->dev,
> > > > > + "%s:%s:req(%p): no free working buffer available\n",
> > > > > + __func__, req->dip_pipe->desc->name, req);
> > > > > + }
> > > > > +
> > > > > + req->working_buf = buf;
> > > > > + mtk_dip_wbuf_to_ipi_img_addr(&req->img_fparam.frameparam.subfrm_data,
> > > > > + &buf->buffer);
> > > > > + memset(buf->buffer.vaddr, 0, DIP_SUB_FRM_SZ);
> > > > > + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.config_data,
> > > > > + &buf->config_data);
> > > > > + memset(buf->config_data.vaddr, 0, DIP_COMP_SZ);
> > > > > +
> > > > > + if (!req->img_fparam.frameparam.tuning_data.present) {
> > > > > + /*
> > > > > + * When user enqueued without tuning buffer,
> > > > > + * it would use driver internal buffer.
> > > > > + */
> > > > > + dev_dbg(dip_dev->dev,
> > > > > + "%s: frame_no(%d) has no tuning_data\n",
> > > > > + __func__, req->img_fparam.frameparam.frame_no);
> > > > > +
> > > > > + mtk_dip_wbuf_to_ipi_tuning_addr
> > > > > + (&req->img_fparam.frameparam.tuning_data,
> > > > > + &buf->tuning_buf);
> > > > > + memset(buf->tuning_buf.vaddr, 0, DIP_TUNING_SZ);
> > > > > + }
> > > > > +
> > > > > + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.self_data,
> > > > > + &buf->frameparam);
> > > > > + memcpy(buf->frameparam.vaddr, &req->img_fparam.frameparam,
> > > > > + sizeof(req->img_fparam.frameparam));
> > > > > + ipi_param.usage = IMG_IPI_FRAME;
> > > > > + ipi_param.frm_param.handle = req->id;
> > > > > + ipi_param.frm_param.scp_addr = (u32)buf->frameparam.scp_daddr;
> > > > > +
> > > > > + mutex_lock(&dip_dev->hw_op_lock);
> > > > > + atomic_inc(&dip_dev->num_composing);
> > > > > + ret = scp_ipi_send(dip_dev->scp_pdev, SCP_IPI_DIP, &ipi_param,
> > > > > + sizeof(ipi_param), 0);
> > > >
> > > > We're not holding the pm_runtime enable count here
> > > > (pm_runtime_get_sync() wasn't called), so rproc_shutdown() might have
> > > > been called. Wouldn't that affect the ability for this IPI to run?
> > > >
> > > > We had a related discussion with Jerry on the FD series and I think
> > > > the conclusion is:
> > > > a) if there is any state that needs to be preserved between jobs, that
> > > > would be cleared by rproc_shutdown() then we need to call
> > > > rproc_boot/shutdown() when we start/stop streaming.
> > > > b) it there is no such state, we can keep them inside runtime PM
> > > > callbacks, but we need to call pm_runtime_get_sync() before sending an
> > > > IPI and pm_runtime_mark_last_busy() + pm_runtime_put_autosuspend()
> > > > after the SCP signals completion. In this case the runtime PM
> > > > autosuspend delay should be set to around 2-3 times the delay needed
> > > > for rproc_shutdown() + rproc_boot() to complete.
> > >
> > > Since each IMG_IPI_FRAME command is stateless, I would like to
> > > use pm_runtime_get_sync()/ pm_runtime_mark_last_busy()/
> > > pm_runtime_put_autosuspend() to fix this issue (solution b).
> >
> > What does IMG_IPI_INIT do then? Do we need it at all?
> >
> > I'm worried about the fact that we call rproc_boot(), IMG_IPI_INIT and
> > then rproc_shutdown(). The latter can completely shutdown the SCP and
> > clear any state there. How would the effects of IMG_IPI_INIT be
> > preserved until IMG_IPI_FRAME is called?
> >
>
> The command IMG_IPI_INIT is to initialize the DIP hardware. Although the
> DIP hardware status is not cleared when SCP is powered off, it can still
> be cleared after mtk_dip_runtime_suspend() is called (it means that DIP
> is going to be powered off).
Great, that's exactly what I wanted to confirm. Thanks. :)
>
> I would like to re-initialize the DIP with IMG_IPI_INIT in
> mtk_dip_runtime_resume() to handle this case. Is is OK?
>
Makes sense.
Best regards,
Tomasz
_______________________________________________
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 4/5] platform: mtk-isp: Add Mediatek DIP driver
From: Frederic Chen @ 2019-09-19 9:41 UTC (permalink / raw)
To: Tomasz Figa
Cc: Shik Chen, devicetree, Sean Cheng (鄭昇弘),
Laurent Pinchart, Rynn Wu (吳育恩),
Christie Yu (游雅惠), srv_heupstream,
Allan Yang (楊智鈞),
Holmes Chiou (邱挺), suleiman, Jerry-ch Chen,
Jungo Lin (林明俊), Sj Huang, yuzhao,
Hans Verkuil, zwisler, Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Linux Media Mailing List
In-Reply-To: <CAAFQd5Cd2-dyQnMEy0LBwaajn7UfzEbHiJp7AkDy=T8Zy6t_=A@mail.gmail.com>
Dear Tomasz,
On Thu, 2019-09-12 at 14:58 +0900, Tomasz Figa wrote:
> On Thu, Sep 12, 2019 at 2:41 AM Frederic Chen
> <frederic.chen@mediatek.com> wrote:
> >
> > Hi Tomasz,
> >
> > I appreciate your helpful comments.
> >
> >
> > On Tue, 2019-09-10 at 13:04 +0900, Tomasz Figa wrote:
> > > Hi Frederic,
> > >
> > > On Tue, Sep 10, 2019 at 4:23 AM <frederic.chen@mediatek.com> wrote:
> > > >
> > > > From: Frederic Chen <frederic.chen@mediatek.com>
> > > >
> > > > This patch adds the driver of Digital Image Processing (DIP)
> > > > unit in Mediatek ISP system, providing image format
> > > > conversion, resizing, and rotation features.
> > > >
> > > > The mtk-isp directory will contain drivers for multiple IP
> > > > blocks found in Mediatek ISP system. It will include ISP
> > > > Pass 1 driver(CAM), sensor interface driver, DIP driver and
> > > > face detection driver.
> > > >
> > > > Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
> > > > ---
> > > > drivers/media/platform/mtk-isp/Makefile | 7 +
> > > > .../media/platform/mtk-isp/isp_50/Makefile | 7 +
> > > > .../platform/mtk-isp/isp_50/dip/Makefile | 18 +
> > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.c | 650 +++++
> > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-dev.h | 566 +++++
> > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-hw.h | 156 ++
> > > > .../platform/mtk-isp/isp_50/dip/mtk_dip-sys.c | 521 ++++
> > > > .../mtk-isp/isp_50/dip/mtk_dip-v4l2.c | 2255 +++++++++++++++++
> > > > 8 files changed, 4180 insertions(+)
> > > > create mode 100644 drivers/media/platform/mtk-isp/Makefile
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/Makefile
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/Makefile
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.c
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-dev.h
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-hw.h
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c
> > > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-v4l2.c
> > > >
> > >
> > > Thanks for sending v3!
> > >
> > > I'm going to do a full review a bit later, but please check one
> > > comment about power handling below.
> > >
> > > Other than that one comment, from a quick look, I think we only have a
> > > number of style issues left. Thanks for the hard work!
> > >
> > > [snip]
> > > > +static void dip_runner_func(struct work_struct *work)
> > > > +{
> > > > + struct mtk_dip_request *req = mtk_dip_hw_mdp_work_to_req(work);
> > > > + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> > > > + struct img_config *config_data =
> > > > + (struct img_config *)req->working_buf->config_data.vaddr;
> > > > +
> > > > + /*
> > > > + * Call MDP/GCE API to do HW excecution
> > > > + * Pass the framejob to MDP driver
> > > > + */
> > > > + pm_runtime_get_sync(dip_dev->dev);
> > > > + mdp_cmdq_sendtask(dip_dev->mdp_pdev, config_data,
> > > > + &req->img_fparam.frameparam, NULL, false,
> > > > + dip_mdp_cb_func, req);
> > > > +}
> > > [snip]
> > > > +static void dip_composer_workfunc(struct work_struct *work)
> > > > +{
> > > > + struct mtk_dip_request *req = mtk_dip_hw_fw_work_to_req(work);
> > > > + struct mtk_dip_dev *dip_dev = req->dip_pipe->dip_dev;
> > > > + struct img_ipi_param ipi_param;
> > > > + struct mtk_dip_hw_subframe *buf;
> > > > + int ret;
> > > > +
> > > > + down(&dip_dev->sem);
> > > > +
> > > > + buf = mtk_dip_hw_working_buf_alloc(req->dip_pipe->dip_dev);
> > > > + if (!buf) {
> > > > + dev_err(req->dip_pipe->dip_dev->dev,
> > > > + "%s:%s:req(%p): no free working buffer available\n",
> > > > + __func__, req->dip_pipe->desc->name, req);
> > > > + }
> > > > +
> > > > + req->working_buf = buf;
> > > > + mtk_dip_wbuf_to_ipi_img_addr(&req->img_fparam.frameparam.subfrm_data,
> > > > + &buf->buffer);
> > > > + memset(buf->buffer.vaddr, 0, DIP_SUB_FRM_SZ);
> > > > + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.config_data,
> > > > + &buf->config_data);
> > > > + memset(buf->config_data.vaddr, 0, DIP_COMP_SZ);
> > > > +
> > > > + if (!req->img_fparam.frameparam.tuning_data.present) {
> > > > + /*
> > > > + * When user enqueued without tuning buffer,
> > > > + * it would use driver internal buffer.
> > > > + */
> > > > + dev_dbg(dip_dev->dev,
> > > > + "%s: frame_no(%d) has no tuning_data\n",
> > > > + __func__, req->img_fparam.frameparam.frame_no);
> > > > +
> > > > + mtk_dip_wbuf_to_ipi_tuning_addr
> > > > + (&req->img_fparam.frameparam.tuning_data,
> > > > + &buf->tuning_buf);
> > > > + memset(buf->tuning_buf.vaddr, 0, DIP_TUNING_SZ);
> > > > + }
> > > > +
> > > > + mtk_dip_wbuf_to_ipi_img_sw_addr(&req->img_fparam.frameparam.self_data,
> > > > + &buf->frameparam);
> > > > + memcpy(buf->frameparam.vaddr, &req->img_fparam.frameparam,
> > > > + sizeof(req->img_fparam.frameparam));
> > > > + ipi_param.usage = IMG_IPI_FRAME;
> > > > + ipi_param.frm_param.handle = req->id;
> > > > + ipi_param.frm_param.scp_addr = (u32)buf->frameparam.scp_daddr;
> > > > +
> > > > + mutex_lock(&dip_dev->hw_op_lock);
> > > > + atomic_inc(&dip_dev->num_composing);
> > > > + ret = scp_ipi_send(dip_dev->scp_pdev, SCP_IPI_DIP, &ipi_param,
> > > > + sizeof(ipi_param), 0);
> > >
> > > We're not holding the pm_runtime enable count here
> > > (pm_runtime_get_sync() wasn't called), so rproc_shutdown() might have
> > > been called. Wouldn't that affect the ability for this IPI to run?
> > >
> > > We had a related discussion with Jerry on the FD series and I think
> > > the conclusion is:
> > > a) if there is any state that needs to be preserved between jobs, that
> > > would be cleared by rproc_shutdown() then we need to call
> > > rproc_boot/shutdown() when we start/stop streaming.
> > > b) it there is no such state, we can keep them inside runtime PM
> > > callbacks, but we need to call pm_runtime_get_sync() before sending an
> > > IPI and pm_runtime_mark_last_busy() + pm_runtime_put_autosuspend()
> > > after the SCP signals completion. In this case the runtime PM
> > > autosuspend delay should be set to around 2-3 times the delay needed
> > > for rproc_shutdown() + rproc_boot() to complete.
> >
> > Since each IMG_IPI_FRAME command is stateless, I would like to
> > use pm_runtime_get_sync()/ pm_runtime_mark_last_busy()/
> > pm_runtime_put_autosuspend() to fix this issue (solution b).
>
> What does IMG_IPI_INIT do then? Do we need it at all?
>
> I'm worried about the fact that we call rproc_boot(), IMG_IPI_INIT and
> then rproc_shutdown(). The latter can completely shutdown the SCP and
> clear any state there. How would the effects of IMG_IPI_INIT be
> preserved until IMG_IPI_FRAME is called?
>
The command IMG_IPI_INIT is to initialize the DIP hardware. Although the
DIP hardware status is not cleared when SCP is powered off, it can still
be cleared after mtk_dip_runtime_suspend() is called (it means that DIP
is going to be powered off).
I would like to re-initialize the DIP with IMG_IPI_INIT in
mtk_dip_runtime_resume() to handle this case. Is is OK?
> Best regards,
> Tomasz
Sincerely,
Frederic Chen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] clk: meson: clk-pll: always enable a critical PLL when setting the rate
From: Neil Armstrong @ 2019-09-19 9:38 UTC (permalink / raw)
To: jbrunet
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190919093627.21245-1-narmstrong@baylibre.com>
Make sure we always enable a PLL on a set_rate() when the PLL is
flagged as critical.
This fixes the case when the Amlogic G12A SYS_PLL gets disabled by the
PSCI firmware when resuming from suspend-to-memory, in the case
where the CPU was not clocked by the SYS_PLL, but by the fixed PLL
fixed divisors.
In this particular case, when changing the PLL rate, CCF doesn't handle
the fact the PLL could have been disabled in the meantime and set_rate()
only changes the rate and never enables it again.
Fixes: d6e81845b7d9 ("clk: meson: clk-pll: check if the clock is already enabled')
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/meson/clk-pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index ddb1e5634739..8c5adccb7959 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -379,7 +379,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
}
/* If the pll is stopped, bail out now */
- if (!enabled)
+ if (!(hw->init->flags & CLK_IS_CRITICAL) && !enabled)
return 0;
if (meson_clk_pll_enable(hw)) {
--
2.22.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
* [PATCH 2/3] clk: meson: g12a: set CLK_MUX_ROUND_CLOSEST on the cpu clock muxes
From: Neil Armstrong @ 2019-09-19 9:36 UTC (permalink / raw)
To: jbrunet
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190919093627.21245-1-narmstrong@baylibre.com>
When setting the 100MHz, 500MHz, 666MHz and 1GHz rate for CPU clocks,
CCF will use the SYS_PLL to handle these frequencies, but:
- using FIXED_PLL derived FCLK_DIV2/DIV3 clocks is more precise
- the Amlogic G12A/G12B/SM1 Suspend handling in firmware doesn't
handle entering suspend using SYS_PLL for these frequencies
Adding CLK_MUX_ROUND_CLOSEST on all the muxes of the non-SYS_PLL
cpu clock tree helps CCF always selecting the FCLK_DIV2/DIV3 as source
for these frequencies.
Fixes: ffae8475b90c ("clk: meson: g12a: add notifiers to handle cpu clock change")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/meson/g12a.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 33c7e04b4a82..b3af61cc6fb9 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -343,6 +343,7 @@ static struct clk_regmap g12a_cpu_clk_premux0 = {
.offset = HHI_SYS_CPU_CLK_CNTL0,
.mask = 0x3,
.shift = 0,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpu_clk_dyn0_sel",
@@ -409,6 +410,7 @@ static struct clk_regmap g12a_cpu_clk_postmux0 = {
.offset = HHI_SYS_CPU_CLK_CNTL0,
.mask = 0x1,
.shift = 2,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpu_clk_dyn0",
@@ -465,6 +467,7 @@ static struct clk_regmap g12a_cpu_clk_dyn = {
.offset = HHI_SYS_CPU_CLK_CNTL0,
.mask = 0x1,
.shift = 10,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpu_clk_dyn",
@@ -484,6 +487,7 @@ static struct clk_regmap g12a_cpu_clk = {
.offset = HHI_SYS_CPU_CLK_CNTL0,
.mask = 0x1,
.shift = 11,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpu_clk",
@@ -503,6 +507,7 @@ static struct clk_regmap g12b_cpu_clk = {
.offset = HHI_SYS_CPU_CLK_CNTL0,
.mask = 0x1,
.shift = 11,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpu_clk",
@@ -522,6 +527,7 @@ static struct clk_regmap g12b_cpub_clk_premux0 = {
.offset = HHI_SYS_CPUB_CLK_CNTL,
.mask = 0x3,
.shift = 0,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpub_clk_dyn0_sel",
@@ -567,6 +573,7 @@ static struct clk_regmap g12b_cpub_clk_postmux0 = {
.offset = HHI_SYS_CPUB_CLK_CNTL,
.mask = 0x1,
.shift = 2,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpub_clk_dyn0",
@@ -644,6 +651,7 @@ static struct clk_regmap g12b_cpub_clk_dyn = {
.offset = HHI_SYS_CPUB_CLK_CNTL,
.mask = 0x1,
.shift = 10,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpub_clk_dyn",
@@ -663,6 +671,7 @@ static struct clk_regmap g12b_cpub_clk = {
.offset = HHI_SYS_CPUB_CLK_CNTL,
.mask = 0x1,
.shift = 11,
+ .flags = CLK_MUX_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "cpub_clk",
--
2.22.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
* [PATCH 0/3] clk: meson: g12a: fixes for DVFS
From: Neil Armstrong @ 2019-09-19 9:36 UTC (permalink / raw)
To: jbrunet
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
This is the first serie of fixes for DVFS support on G12a:
- Patch 1 fixes a rebase issue where a CLK_SET_RATE_NO_REPARENT
appeared on the wrong clock and a SET_RATE_PARENT went missing
- Patch 2 helps CCF use the right clock tree for the sub 1GHz clock range
- Patch 3 fixes an issue when we enter suspend with a non-SYS_PLL CPU clock,
leading to a SYS_PLL never enabled again
Neil Armstrong (3):
clk: meson: g12a: fix cpu clock rate setting
clk: meson: g12a: set CLK_MUX_ROUND_CLOSEST on the cpu clock muxes
clk: meson: clk-pll: always enable a critical PLL when setting the
rate
drivers/clk/meson/clk-pll.c | 2 +-
drivers/clk/meson/g12a.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] clk: meson: g12a: fix cpu clock rate setting
From: Neil Armstrong @ 2019-09-19 9:36 UTC (permalink / raw)
To: jbrunet
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190919093627.21245-1-narmstrong@baylibre.com>
CLK_SET_RATE_NO_REPARENT is wrongly set on the g12a cpu premux0 clocks
flags, and CLK_SET_RATE_PARENT is required for the g12a cpu premux0 clock
and the g12b cpub premux0 clock, otherwise CCF always selects the SYS_PLL
clock to feed the cpu cluster.
Fixes: ffae8475b90c ("clk: meson: g12a: add notifiers to handle cpu clock change")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/clk/meson/g12a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index ea4c791f106d..33c7e04b4a82 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -353,8 +353,7 @@ static struct clk_regmap g12a_cpu_clk_premux0 = {
{ .hw = &g12a_fclk_div3.hw },
},
.num_parents = 3,
- /* This sub-tree is used a parking clock */
- .flags = CLK_SET_RATE_NO_REPARENT,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -533,6 +532,7 @@ static struct clk_regmap g12b_cpub_clk_premux0 = {
{ .hw = &g12a_fclk_div3.hw },
},
.num_parents = 3,
+ .flags = CLK_SET_RATE_PARENT,
},
};
--
2.22.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 v3 1/2] memory: samsung: exynos5422-dmc: Fix kfree() of devm-allocated memory and missing static
From: Dan Carpenter @ 2019-09-19 9:32 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, willy.mh.wolff.ml, linux-samsung-soc,
cw00.choi, b.zolnierkie, linux-pm, linux-kernel, krzk, robh+dt,
kyungmin.park, kgene, myungjoo.ham, s.nawrocki, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190919092641.4407-2-l.luba@partner.samsung.com>
Thanks! Looks good.
regards,
dan carpenter
_______________________________________________
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/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk
From: Anson Huang @ 2019-09-19 9:31 UTC (permalink / raw)
To: Schrempf Frieder, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, Leonard Crestez,
daniel.lezcano@linaro.org, Jacky Bai, Daniel Baluta, Jun Li,
l.stach@pengutronix.de, Abel Vesa, andrew.smirnov@gmail.com,
angus@akkea.ca, ccaione@baylibre.com, agx@sigxcpu.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <c680d114-1c14-6bf8-226c-2fdd98350158@kontron.de>
Hi, Schrempf
> Hi Anson,
>
> I have a question, that is not directly related to this patch.
> I see that for the usdhc1 and usdhc3 nodes, there is an 'assigned-clock'
> and 'assigned-clock-rates' property but not for usdhc2. The same applies to
> the mx8mq and mx8mn dtsi file.
>
> Is there any reason for this? If not can you fix it?
This patch series is NOT related to 'assigned-clock' or 'assigned-clock-rates'
property, it is just for correcting clock source according to reference manual,
the 'ipg' clock is from system's IPG_ROOT clock according to reference manual CCM
chapter, using DUMMY clock is NOT a good option, the 'ipg' clock is supposed
to be the clock for accessing register, and it should NOT be DUMMY if we know
what exactly the clock source is used.
Thanks,
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] memory: samsung: exynos5422-dmc: Fix kfree() of devm-allocated memory and missing static
From: Lukasz Luba @ 2019-09-19 9:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-arm-kernel
Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
myungjoo.ham, dan.carpenter, m.szyprowski
In-Reply-To: <20190919092641.4407-1-l.luba@partner.samsung.com>
Fix issues captured by static checkers: used kfree() and missing 'static'
in the private function.
Fixes Smatch warning:
drivers/memory/samsung/exynos5422-dmc.c:272
exynos5_init_freq_table() warn: passing devm_ allocated variable to kfree. 'dmc->opp'
Fixes Sparse warning:
drivers/memory/samsung/exynos5422-dmc.c:736:1:
warning: symbol 'exynos5_dmc_align_init_freq' was not declared.
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
drivers/memory/samsung/exynos5422-dmc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
index 8c2ec29a7d57..1b54fc8c912e 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -258,7 +258,7 @@ static int exynos5_init_freq_table(struct exynos5_dmc *dmc,
opp = dev_pm_opp_find_freq_floor(dmc->dev, &freq);
if (IS_ERR(opp))
- goto err_free_tables;
+ goto err_opp;
dmc->opp[idx - i].freq_hz = freq;
dmc->opp[idx - i].volt_uv = dev_pm_opp_get_voltage(opp);
@@ -268,8 +268,6 @@ static int exynos5_init_freq_table(struct exynos5_dmc *dmc,
return 0;
-err_free_tables:
- kfree(dmc->opp);
err_opp:
dev_pm_opp_of_remove_table(dmc->dev);
@@ -732,7 +730,7 @@ static struct devfreq_dev_profile exynos5_dmc_df_profile = {
* statistics engine which supports only registered values. Thus, some alignment
* must be made.
*/
-unsigned long
+static unsigned long
exynos5_dmc_align_init_freq(struct exynos5_dmc *dmc,
unsigned long bootloader_init_freq)
{
--
2.17.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 v3 0/2] Exynos5 DMC minor fixes
From: Lukasz Luba @ 2019-09-19 9:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-arm-kernel
Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
myungjoo.ham, dan.carpenter, m.szyprowski
In-Reply-To: <CGME20190919092652eucas1p2715611db7a0b0c4cc79956311e01c35a@eucas1p2.samsung.com>
Hi all,
This is a follow up patch set for the Exynos5 Dynamic Memory Controller
driver v13 [1]. The patches are for Krzysztof's branch [2]
for-v5.4-5.5/memory-samsung-dmc
and/or linux-next where Dan Carpenter reported the issue (patch 1/2).
There are a few fixes captured during static analysis and a new
binding for 'samsung,K3QF2F20DB' LPDDR3 memory.
Regards,
Lukasz Luba
[1] https://lkml.org/lkml/2019/8/21/283
[2] https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/log/?h=for-v5.4-5.5/memory-samsung-dmc
Lukasz Luba (2):
memory: samsung: exynos5422-dmc: Fix kfree() of devm-allocated memory
and missing static
dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
Documentation/devicetree/bindings/ddr/lpddr3.txt | 10 +++++++---
drivers/memory/samsung/exynos5422-dmc.c | 6 ++----
2 files changed, 9 insertions(+), 7 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Lukasz Luba @ 2019-09-19 9:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-arm-kernel
Cc: mark.rutland, willy.mh.wolff.ml, b.zolnierkie, krzk, Lukasz Luba,
cw00.choi, kyungmin.park, robh+dt, kgene, s.nawrocki,
myungjoo.ham, dan.carpenter, m.szyprowski
In-Reply-To: <20190919092641.4407-1-l.luba@partner.samsung.com>
Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings.
Suggested to based on at25.txt compatible section.
Introduce minor fixes in the old documentation.
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
Documentation/devicetree/bindings/ddr/lpddr3.txt | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
index 3b2485b84b3f..a0eda35a86ee 100644
--- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
+++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
@@ -1,7 +1,10 @@
* LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C
Required properties:
-- compatible : Should be - "jedec,lpddr3"
+- compatible : Should be "<vendor>,<type>", and generic value "jedec,lpddr3".
+ Example "<vendor>,<type>" values:
+ "samsung,K3QF2F20DB"
+
- density : <u32> representing density in Mb (Mega bits)
- io-width : <u32> representing bus width. Possible values are 8, 16, 32, 64
- #address-cells: Must be set to 1
@@ -43,7 +46,7 @@ Child nodes:
Example:
samsung_K3QF2F20DB: lpddr3 {
- compatible = "Samsung,K3QF2F20DB", "jedec,lpddr3";
+ compatible = "samsung,K3QF2F20DB", "jedec,lpddr3";
density = <16384>;
io-width = <32>;
#address-cells = <1>;
@@ -73,7 +76,8 @@ samsung_K3QF2F20DB: lpddr3 {
timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 {
compatible = "jedec,lpddr3-timings";
- reg = <800000000>; /* workaround: it shows max-freq */
+ /* workaround: 'reg' shows max-freq */
+ reg = <800000000>;
min-freq = <100000000>;
tRFC = <65000>;
tRRD = <6000>;
--
2.17.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: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-19 9:22 UTC (permalink / raw)
To: Y.b. Lu
Cc: dann frazier, linux-mmc, Adrian Hunter, Will Deacon, Leo Li,
Nicolin Chen, Fabio Estevam, Christoph Hellwig, Linux ARM
In-Reply-To: <20190919083803.GG25745@shell.armlinux.org.uk>
On Thu, Sep 19, 2019 at 09:38:04AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
>
> Thanks for the reply.
>
> I see that this bit is marked "reserved" in the LX2160A reference
> manual.
Sorry, I was lookin at bit 5, it's actually bit 6. Rest of my mail is
still relevent.
>
> This brings up some further questions.
>
> The DT property "dma-coherent" is used to tell the OS whether the
> device is DMA coherent or not. If this property is missing, but the
> device is set as DMA coherent, and the OS uses "normal, non-cacheable"
> memory for the ADMA table, then errors can occur if there are stale
> cache lines corresponding to the memory used. The eSDHC controller
> will see the stale cache lines, but the CPU will not.
>
> Adding "dma-coherent" to the DT declarations alone does not seem to
> be the right solution - if we have an OS that does not set the
> ESDHC_DMA_SNOOP bit, then we have a similar issue.
>
> Shouldn't ESDHC_DMA_SNOOP be set depending on whether the device is
> DMA coherent or not?
>
> Note that the device is _not_ marked as "dma-coherent" in either
> mainline nor in the LSDK-19.06-V4.19 branch of
> https://source.codeaurora.org/external/qoriq/qoriq-components/linux
> to avoid ADMA descriptor fetch errors, which leads to this error that
> has now been observed with v5.3 kernels - caused precisely as I
> describe above.
>
> Thanks.
>
> On Thu, Sep 19, 2019 at 08:15:00AM +0000, Y.b. Lu wrote:
> > Hi Russell,
> >
> > The ESDHC_DMA_SNOOP bit is always set in eSDHC driver for DMA.
> >
> > 1b - DMA transactions are snooped by the CPU data cache.
> > 0b - DMA transactions are not snooped by the CPU data cache.
> >
> > Thanks a lot.
> >
> > Best regards,
> > Yangbo Lu
> >
> > > -----Original Message-----
> > > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > Sent: Thursday, September 19, 2019 3:05 PM
> > > To: Y.b. Lu <yangbo.lu@nxp.com>
> > > Cc: Leo Li <leoyang.li@nxp.com>; Fabio Estevam <festevam@gmail.com>;
> > > Adrian Hunter <adrian.hunter@intel.com>; Christoph Hellwig <hch@lst.de>;
> > > Linux ARM <linux-arm-kernel@lists.infradead.org>; Nicolin Chen
> > > <nicoleotsuka@gmail.com>; Will Deacon <will.deacon@arm.com>; dann
> > > frazier <dann.frazier@canonical.com>; linux-mmc
> > > <linux-mmc@vger.kernel.org>
> > > Subject: Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
> > >
> > > Hi,
> > >
> > > This is not the issue, since the problem has been observed with eMMC too,
> > > and is sporadic in nature.
> > >
> > > Please could you answer the question posed: are the eSDHC controllers DMA
> > > coherent or are they not coherent?
> > >
> > > Thanks.
> > >
> > > On Thu, Sep 19, 2019 at 04:13:20AM +0000, Y.b. Lu wrote:
> > > > Sorry. My email was rejected by mailing lists. Let me re-send.
> > > >
> > > > Hi Russell,
> > > >
> > > > I’m not sure what board you were using for LX2160A.
> > > > We had an known issue for eSDHC controller and all NXP Layerscape RDB
> > > boards.
> > > > eSDHC couldn’t provide power-cycle to SD card, and even worse, board
> > > reset couldn’t provide power-cycle to SD card either.
> > > > But for UHS-I SD card, it’s required to have a power-cycle to reset card if it
> > > goes into UHS-I mode. Otherwise, we don’t know what will happen when
> > > kernel initializes SD card after a reboot/reset.
> > > >
> > > > I could reproduce that issue with below steps on latest mainline kernel.
> > > > 1. Power off board, and power on board.
> > > > 2. Start up kernel, the SD card works fine in UHS-I mode.
> > > > 3. Reboot/reset board. (This couldn’t provide power-cycle to SD card)
> > > > 4. Start up kernel, the SD card gets that ADMA error issue.
> > > >
> > > > So could you have a try to power off/power on the board, and then start up
> > > kernel. Don’t use reboot, or board reset button.
> > > > Or you can remove SD card and start up kernel, and insert SD card when
> > > kernel has been started up.
> > > > Thanks a lot.
> > > >
> > > > Best regards,
> > > > Yangbo Lu
> > > >
> > > >
> > > > From: Li Yang <leoyang.li@nxp.com>
> > > > Sent: Wednesday, September 18, 2019 1:48 AM
> > > > To: Fabio Estevam <festevam@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>
> > > > Cc: Adrian Hunter <adrian.hunter@intel.com>; Christoph Hellwig
> > > > <hch@lst.de>; Linux ARM <linux-arm-kernel@lists.infradead.org>;
> > > > Nicolin Chen <nicoleotsuka@gmail.com>; Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk>; Will Deacon <will.deacon@arm.com>; dann
> > > > frazier <dann.frazier@canonical.com>; linux-mmc
> > > > <linux-mmc@vger.kernel.org>
> > > > Subject: Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
> > > >
> > > >
> > > >
> > > > On Tue, Sep 17, 2019 at 6:31 PM Fabio Estevam
> > > <mailto:festevam@gmail.com> wrote:
> > > > [Adding Li Yang]
> > > >
> > > > On Tue, Sep 17, 2019 at 10:52 AM Russell King - ARM Linux admin
> > > > <mailto:linux@armlinux.org.uk> wrote:
> > > >
> > > > > The pressing question seems to be this:
> > > > >
> > > > > Are the eSDHC on the LX2160A DMA coherent or are they not?
> > > > >
> > > > > Any chances of finding out internally what the true answer to that,
> > > > > rather than me poking about trying stuff experimentally? Having a
> > > > > definitive answer for a potentially data-corrupting change would be
> > > > > really good...
> > > >
> > > > Li Yang,
> > > >
> > > > Could you please help to confirm Russell's question?
> > > > Adding Yangbo who is working on SDHC.
> > > >
> > > > Regards,
> > > > Leo
> > >
> > > --
> > > RMK's Patch system:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar
> > > mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cyangbo.l
> > > u%40nxp.com%7C7eca2b9652104c95a52008d73ccfa99a%7C686ea1d3bc2b4
> > > c6fa92cd99c5c301635%7C0%7C0%7C637044734911465102&sdata=QB
> > > SEzA9L2HC99gm65P965E3o%2FhNM18u2SouOZxTEs6s%3D&reserved=0
> > > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps
> > > up According to speedtest.net: 11.9Mbps down 500kbps up
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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 1/4] dmaengine: imx-sdma: fix buffer ownership
From: Philipp Puschmann @ 2019-09-19 9:20 UTC (permalink / raw)
To: Lucas Stach, linux-kernel
Cc: festevam, kernel, gregkh, s.hauer, vkoul, linux-imx, linux-serial,
jslaby, dmaengine, dan.j.williams, shawnguo, linux-arm-kernel
In-Reply-To: <9bcf315369449a025828410396935b679aae14bf.camel@pengutronix.de>
Am 16.09.19 um 16:17 schrieb Lucas Stach:
> On Mi, 2019-09-11 at 16:49 +0200, Philipp Puschmann wrote:
>> BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the buffer,
>> when 0 ARM owns it. When processing the buffers in
>> sdma_update_channel_loop the ownership of the currently processed buffer
>> was set to SDMA again before running the callback function of the the
>> buffer and while the sdma script may be running in parallel. So there was
>> the possibility to get the buffer overwritten by SDMA before it has been
>> processed by kernel leading to kind of random errors in the upper layers,
>> e.g. bluetooth.
>>
>> It may be further a good idea to make the status struct member volatile or
>> access it using writel or similar to rule out that the compiler sets the
>> BD_DONE flag before the callback routine has finished.
>>
>> Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
>> ---
>> drivers/dma/imx-sdma.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
>> index a01f4b5d793c..1abb14ff394d 100644
>> --- a/drivers/dma/imx-sdma.c
>> +++ b/drivers/dma/imx-sdma.c
>> @@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> */
>>
>> desc->chn_real_count = bd->mode.count;
>> - bd->mode.status |= BD_DONE;
>> bd->mode.count = desc->period_len;
>> desc->buf_ptail = desc->buf_tail;
>> desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
>> @@ -817,6 +816,8 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
>> spin_lock(&sdmac->vc.lock);
>
> To address your comment from the second paragraph of the commit message
> there should be a dma_wmb() here before changing the status flag.
>
> Regards,
> Lucas
Hi Lucas,
thanks for your feedback. I will apply the hints to v2 of the patches.
Regards,
Philipp
>
>> + bd->mode.status |= BD_DONE;
>> +
>> if (error)
>> sdmac->status = old_status;
>> }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pwm: rockchip: simplify rockchip_pwm_get_state()
From: Rasmus Villemoes @ 2019-09-19 9:17 UTC (permalink / raw)
To: Thierry Reding, Heiko Stuebner
Cc: linux-pwm, Rasmus Villemoes, linux-kernel, linux-rockchip,
David Wu, linux-arm-kernel
The way state->enabled is computed is rather convoluted and hard to
read - both branches of the if() actually do the exact same thing. So
remove the if(), and further simplify "<boolean condition> ? true :
false" to "<boolean condition>".
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
I stumbled on this while trying to understand how the pwm subsystem
works. This patch is a semantic no-op, but it's also possible that,
say, the first branch simply contains a "double negative" so either
the != should be == or the "false : true" should be "true : false".
drivers/pwm/pwm-rockchip.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 51b96cb7dd25..54c6399e3f00 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -83,12 +83,7 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
val = readl_relaxed(pc->base + pc->data->regs.ctrl);
- if (pc->data->supports_polarity)
- state->enabled = ((val & enable_conf) != enable_conf) ?
- false : true;
- else
- state->enabled = ((val & enable_conf) == enable_conf) ?
- true : false;
+ state->enabled = ((val & enable_conf) == enable_conf);
if (pc->data->supports_polarity) {
if (!(val & PWM_DUTY_POSITIVE))
--
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
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