* Re: [PATCH v4 0/4] Add drivers for auo, kd101n80-45na and boe, tv101wum-nl6 panels
From: Sam Ravnborg @ 2019-08-11 21:11 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
Ajay Kumar, Vincent Palatin, cawa.cheng, yingjoe.chen,
Thierry Reding, Sean Paul, linux-pwm, Pawel Moll, Ian Campbell,
Rob Herring, linux-mediatek, Russell King, Matthias Brugger,
eddie.huang, linux-arm-kernel, Rahul Sharma, srv_heupstream,
linux-kernel, Sascha Hauer, Andy Yan
In-Reply-To: <20190811091001.49555-1-jitao.shi@mediatek.com>
Hi Jitao.
> .../display/panel/auo,kd101n80-45na.txt | 34 +
> .../display/panel/boe,tv101wum-nl6.txt | 34 +
panel bindings are in the process of being migrated to the new
meta-schema format.
Therefore new bindings should preferably also follow the new format.
Can you please look into this.
In upstream and drm-misc-next there is already some examples.
Note: It is not a hard rule that new bindings shall be in
the new meta-schema format (.yaml extension), but as this is
best practice now it is preferred.
Same goes for display bindings btw.
Sam
_______________________________________________
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 07/18] clk: bcm2835: Introduce SoC specific clock registration
From: Stefan Wahren @ 2019-08-11 20:43 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Nicolas Saenz Julienne, Matthias Brugger,
Rob Herring, Mark Rutland, Linus Walleij, Michael Turquette,
Stephen Boyd, Ulf Hansson, Adrian Hunter
Cc: linux-gpio, linux-mmc, linux-rpi-kernel, linux-arm-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1563774880-8061-8-git-send-email-wahrenst@gmx.net>
Hi,
Am 22.07.19 um 07:54 schrieb Stefan Wahren:
> In order to support SoC specific clocks (e.g. emmc2 for BCM2711), we
> extend the description with a SoC support flag. This approach avoids long
> and mostly redundant lists of clock IDs.
>
> Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> drivers/clk/bcm/clk-bcm2835.c | 103 +++++++++++++++++++++++++++++++++++-------
> 1 file changed, 86 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 867ae3c..3231b76 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -31,7 +31,7 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/module.h>
> -#include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> #include <dt-bindings/clock/bcm2835.h>
> @@ -289,6 +289,9 @@
> #define LOCK_TIMEOUT_NS 100000000
> #define BCM2835_MAX_FB_RATE 1750000000u
>
> +#define SOC_BCM2835 BIT(0)
> +#define SOC_ALL (SOC_BCM2835)
> +
...
> .cm_reg = CM_PLLD,
> @@ -1775,6 +1805,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> * It is in the HDMI power domain.
> */
> [BCM2835_PLLH] = REGISTER_PLL(
> + SOC_ALL,
> "pllh",
> .cm_ctrl_reg = CM_PLLH,
> .a2w_ctrl_reg = A2W_PLLH_CTRL,
> @@ -1789,6 +1820,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .max_rate = 3000000000u,
> .max_fb_rate = BCM2835_MAX_FB_RATE),
> [BCM2835_PLLH_RCAL] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_rcal",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
> @@ -1798,6 +1830,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .fixed_divider = 10,
> .flags = CLK_SET_RATE_PARENT),
> [BCM2835_PLLH_AUX] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_aux",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
> @@ -1807,6 +1840,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .fixed_divider = 1,
> .flags = CLK_SET_RATE_PARENT),
> [BCM2835_PLLH_PIX] = REGISTER_PLL_DIV(
> + SOC_ALL,
> .name = "pllh_pix",
> .source_pll = "pllh",
> .cm_reg = CM_PLLH,
i was informed that at least all PLLH related clocks are BCM2835
specific. So please don't apply this patch. I will send a fixed version
soon.
_______________________________________________
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 3/3] arm64: defconfig: Enable Sun4i SPDIF module
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
Allwinner A64 and H6 use the Sun4i SPDIF driver.
Enable this to allow a proper support.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..b0638849c14c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -558,6 +558,7 @@ CONFIG_SND_SOC_ROCKCHIP_RT5645=m
CONFIG_SND_SOC_RK3399_GRU_SOUND=m
CONFIG_SND_SOC_SAMSUNG=y
CONFIG_SND_SOC_RCAR=m
+CONFIG_SND_SUN4I_SPDIF=m
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_ES7134=m
CONFIG_SND_SOC_ES7241=m
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/3] arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
Beelink GS1 board has a SPDIF out connector, so enable it in
the device-tree.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd60..76a95ad33dc5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -243,6 +243,10 @@
vcc-pm-supply = <®_aldo1>;
};
+&spdif {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_ph_pins>;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/3] Allwinner H6 SPDIF support
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
Allwinner H6 SoC has a SPDIF controller called One Wire Audio (OWA) which
is different from the previous H3 generation and not compatible.
Difference are an increase of fifo sizes, some memory mapping are different
and there is now the possibility to output the master clock on a pin.
Actually all these features are unused and only a bit for flushing the TX
fifo is required.
Changes since v4:
- rename audio card name to sun50i-h6-spdif
- drop patches already merged
Changes since v3:
- rename reg_fctl_ftx to val_fctl_ftx
- rebase this series on sound-next
- fix dt-bindings due to change in sound-next
- change node name sound_spdif to sound-spdif
Changes since v2:
- Split quirks and H6 support patch
- Add specific section for quirks comment
Changes since v1:
- Remove H3 compatible
- Add TX fifo bit flush quirks
- Add H6 bindings in SPDIF driver
Clément Péron (3):
arm64: dts: allwinner: Add SPDIF node for Allwinner H6
arm64: dts: allwinner: h6: Enable SPDIF for Beelink GS1
arm64: defconfig: Enable Sun4i SPDIF module
.../dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 +++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
3 files changed, 43 insertions(+)
--
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
* [PATCH v5 1/3] arm64: dts: allwinner: Add SPDIF node for Allwinner H6
From: Clément Péron @ 2019-08-11 20:31 UTC (permalink / raw)
To: Maxime Ripard, Rob Herring
Cc: devicetree, linux-sunxi, Clément Péron, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190811203144.5999-1-peron.clem@gmail.com>
The Allwinner H6 has a SPDIF controller called OWA (One Wire Audio).
Only one pinmuxing is available so set it as default.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 38 ++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 7628a7c83096..677eb374678d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -83,6 +83,24 @@
method = "smc";
};
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-h6-spdif";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13
@@ -282,6 +300,11 @@
bias-pull-up;
};
+ spdif_tx_pin: spdif-tx-pin {
+ pins = "PH7";
+ function = "spdif";
+ };
+
uart0_ph_pins: uart0-ph-pins {
pins = "PH0", "PH1";
function = "uart0";
@@ -411,6 +434,21 @@
};
};
+ spdif: spdif@5093000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun50i-h6-spdif";
+ reg = <0x05093000 0x400>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>;
+ clock-names = "apb", "spdif";
+ resets = <&ccu RST_BUS_SPDIF>;
+ dmas = <&dma 2>;
+ dma-names = "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_tx_pin>;
+ status = "disabled";
+ };
+
usb2otg: usb@5100000 {
compatible = "allwinner,sun50i-h6-musb",
"allwinner,sun8i-a33-musb";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 12/18] pinctrl: bcm2835: Add support for BCM2711 pull-up functionality
From: Stefan Wahren @ 2019-08-11 20:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, Ulf Hansson, Matthias Brugger, Scott Branden,
open list:GPIO SUBSYSTEM, Stephen Boyd, Ray Jui,
Michael Turquette, linux-mmc, Adrian Hunter, Rob Herring,
Eric Anholt, Florian Fainelli, bcm-kernel-feedback-list,
Linux ARM, Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <CACRpkdabfiDbGmAQciAUSThY-KfTsVq3tHz0bBszs2j_ej18Nw@mail.gmail.com>
Am 05.08.19 um 11:38 schrieb Linus Walleij:
> On Mon, Jul 22, 2019 at 8:24 AM Stefan Wahren <wahrenst@gmx.net> wrote:
>
>> The BCM2711 has a new way of selecting the pull-up/pull-down setting
>> for a GPIO pin. The registers used for the BCM2835, GP_PUD and
>> GP_PUDCLKn0, are no longer connected. A new set of registers,
>> GP_GPIO_PUP_PDN_CNTRL_REGx must be used. This commit will add
>> a new compatible string "brcm,bcm2711-gpio" and the kernel
>> driver will use it to select which method is used to select
>> pull-up/pull-down.
>>
>> This patch based on a patch by Al Cooper which was intended for the
>> BCM7211. This is a bugfixed and improved version.
>>
>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Patch applied.
Thanks
>
> I think I complained about some other version of this patch, this one
> looks entirely acceptable.
>
> Can we get rid of custom pull settings etc from the upstream device
> trees so we don't set bad examples? I have a strong urge to
> throw in a pr_warn() about any use of it.
Ironically, my pre-RFC version tried to convert all BCM2835 pinmux
settings to generic ones. Unfortunately it seems that i made a mistake,
because it didn't work as expected. Since we stumpled above more and
more other issues (not relevant to pinctrl) during upstream review, i
decided to start with legacy pull-up support, so we can fix this later
in the devicetree for both platforms (currently BCM2711 uses most of the
old BCM2835 pinmuxes including the legacy stuff). So yes my plan is to
fix this soon.
Stefan
>
> Yours,
> Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:44 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev, Florian Fainelli, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
Hi Russell
At the bus level, MDIO cannot fail. The bits get clocked out, and the
bits get clocked in. There is no way for the PHY to stretch the clock
as I2C slaves can. There is nothing like the USB NACK, try again
later.
If something fails, it fails at a higher level, which means it is a
driver issue. In this case, the interrupt got delayed, after the timer
interrupt.
The FEC is also quite unusual in using an interrupt. Most MDIO drivers
poll. And if time gets 'stretched' because the system is too busy,
generally, the right thing happens anyway.
So i don't think it is phylib job to work around this issue.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:31 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: netdev, Florian Fainelli, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
Hi Russell
The timeout is quite short,
#define FEC_MII_TIMEOUT 30000 /* us */
Looking at the Vybrid datasheet, there does not appear to be any way
to determine if the hardware is busy other than waiting for the
interrupt. There is no 'busy' bit which gets cleared on completion.
So about the only option is to make the timeout bigger.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:03 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Florian Fainelli, netdev, Russell King - ARM Linux admin,
Hubert Feurstein, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <CA+h21hqkVoQWRweKKCFdvLLOLyP4gEtXQvJ9CO_J7i+YQW+TWw@mail.gmail.com>
> I think a better question is why is the FEC MDIO controller configured
> to emit interrupts anyway (especially since the API built on top does
> not benefit in any way from this)? Hubert (copied) sent an interesting
> email very recently where he pointed out that this is one of the main
> sources of jitter when reading the PTP clock on a Marvell switch
> attached over MDIO.
Hi Vladimir
One reason is runtime power management.
For a write operation, you could set it going and return
immediately. Many drivers do, and then when the next read/write
operation comes along, they poll in a loop waiting for the device to
go idle, if it was still busy from the last operation.
However, FEC supports runtime PM. When an MDIO read/write call is
made, it calls runtime PM functions to indicate the device is active.
Once it has completed the MDIO transaction, it calls runtime PM
functions to indicate the device is inactive. These transitions can
cause clocks to be enabled/disabled. If we don't wait around for the
operation to complete, the clock could be disabled too early, and bad
things would happen.
You could replace the interrupt with a sleeping poll, but my guess
would be, that has more jitter than using an interrupt.
Andrew
_______________________________________________
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 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Martin Blumenstingl @ 2019-08-11 15:43 UTC (permalink / raw)
To: Guillaume La Roque
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
Neil Armstrong, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190806130506.8753-3-glaroque@baylibre.com>
Hi Guillaume,
[...]
> +struct amlogic_thermal {
> + struct platform_device *pdev;
> + const struct amlogic_thermal_data *data;
> + struct regmap *regmap;
> + struct regmap *sec_ao_map;
> + struct clk *clk;
> + struct thermal_zone_device *tzd;
> + u32 trim_info;
> + void __iomem *base;
nit-pick: this is only used in _probe() so you could make it a local
variable there
[...]
> +static const struct of_device_id of_amlogic_thermal_match[] = {
> + {
> + .compatible = "amlogic,g12-ddr-thermal",
> + .data = &amlogic_thermal_g12_ddr_param,
> + },
> + {
> + .compatible = "amlogic,g12-cpu-thermal",
> + .data = &amlogic_thermal_g12_cpu_param,
> + },
I assume you are using "g12" to indicate that it's valid for both,
G12A and G12B?
meson-g12-common.dtsi currently does not use any other "amlogic,g12-*"
compatible string (there are some meson-axg-*, meson-gx-* and
meson-g12a-* ones, but no g12-*)
I would like to hear Kevin's and Neil's opinion on this one whether we
should introduce that "amlogic,g12-*" prefix or stick to
"amlogic,g12a-*"
[...]
> + ret = amlogic_thermal_enable(pdata);
> + if (ret)
> + clk_disable_unprepare(pdata->clk);
amlogic_thermal_enable only returns an error-code if clk_prepare_enable() fails
in that case the clock is neither prepared nor enabled so we must not
call clk_disable_unprepare
apart from that it looks good to me (as someone who doesn't know the
thermal framework)
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Vladimir Oltean @ 2019-08-11 14:54 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, netdev, Hubert Feurstein,
Fabio Estevam, linux-arm-kernel, Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
Hi Russell, Fabio,
On Sun, 11 Aug 2019 at 16:42, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
>
> From what I can see, the OOM events happened on CPU1, CPU1 was
> allocated the FEC interrupt, and the PHY polling that suffered the
> MDIO timeout was on CPU0.
>
> Given that IEVENT is zero, it seems that CPU1 had read serviced the
> interrupt, but it is not clear how far through processing that it
> was - it may be that fec_enet_interrupt() had been delayed by the
> OOM condition.
>
> This seems rather fragile - as the system slowing down due to OOM
> triggers the network to completely collapse by phylib taking the
> PHY offline, making the system inaccessible except through the
> console.
>
> In my case, even serial console wasn't operational (except for
> magic sysrq). Not sure what agetty was playing at... so the only
> way I could recover any information from the system was to connect
> the HDMI and plug in a USB keyboard.
>
> Any thoughts on how FEC MDIO accesses could be made more robust?
>
I think a better question is why is the FEC MDIO controller configured
to emit interrupts anyway (especially since the API built on top does
not benefit in any way from this)? Hubert (copied) sent an interesting
email very recently where he pointed out that this is one of the main
sources of jitter when reading the PTP clock on a Marvell switch
attached over MDIO.
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
>
> Thanks.
>
> --
> 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
Regards,
-Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Russell King - ARM Linux admin @ 2019-08-11 14:06 UTC (permalink / raw)
To: linux-arm-kernel, Fabio Estevam, netdev, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
>
> From what I can see, the OOM events happened on CPU1, CPU1 was
> allocated the FEC interrupt, and the PHY polling that suffered the
> MDIO timeout was on CPU0.
>
> Given that IEVENT is zero, it seems that CPU1 had read serviced the
> interrupt, but it is not clear how far through processing that it
> was - it may be that fec_enet_interrupt() had been delayed by the
> OOM condition.
>
> This seems rather fragile - as the system slowing down due to OOM
> triggers the network to completely collapse by phylib taking the
> PHY offline, making the system inaccessible except through the
> console.
>
> In my case, even serial console wasn't operational (except for
> magic sysrq). Not sure what agetty was playing at... so the only
> way I could recover any information from the system was to connect
> the HDMI and plug in a USB keyboard.
>
> Any thoughts on how FEC MDIO accesses could be made more robust?
>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
I should also note for the phylib people:
After phylib has received an error, and has entered the HALTED state,
downing the interface produces this warning, which seems rather unfair
as the FEC doesn't know that its PHY suffered an error - it is merely
reversing the phy_start() that happened when the interface was opened.
[4144039.099786] ------------[ cut here ]------------
[4144039.109001] WARNING: CPU: 1 PID: 25842 at drivers/net/phy/phy.c:835 fec_enet_close+0x14/0x148
[4144039.124366] called from state HALTED
[4144039.132626] Modules linked in: 8021q brcmfmac brcmutil imx_thermal
snd_soc_imx_spdif snd_soc_imx_audmux nvmem_imx_ocotp cfg80211
snd_soc_sgtl5000 imx_sdma
virt_dma rc_cec snd_soc_fsl_ssi snd_soc_fsl_spdif coda imx_pcm_dma
v4l2_mem2mem
imx_vdoa etnaviv videobuf2_dma_contig gpu_sched dw_hdmi_cec
dw_hdmi_ahb_audio imx6q_cpufreq caamrng caam_jr caam error ip_tables
x_tables [last unloaded: evbug][4144039.177249] CPU: 1 PID: 25842 Comm:
ip Tainted: G W 5.1.0+ #319
[4144039.189477] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[4144039.201025] [<c00194f0>] (unwind_backtrace) from [<c0014748>] (show_stack+0x10/0x14)
[4144039.213769] [<c0014748>] (show_stack) from [<c082e11c>] (dump_stack+0x9c/0xd4)
[4144039.225959] [<c082e11c>] (dump_stack) from [<c0030f3c>] (__warn+0xf8/0x124)
[4144039.237828] [<c0030f3c>] (__warn) from [<c0031030>] (warn_slowpath_fmt+0x38/0x48)
[4144039.250275] [<c0031030>] (warn_slowpath_fmt) from [<c052cb14>] (fec_enet_close+0x14/0x148)
[4144039.263558] [<c052cb14>] (fec_enet_close) from [<c066b5bc>] (__dev_close_many+0x88/0xf0)
[4144039.276639] [<c066b5bc>] (__dev_close_many) from [<c06740cc>] (__dev_change_flags+0xa4/0x1a0)
[4144039.290130] [<c06740cc>] (__dev_change_flags) from [<c06741e8>] (dev_change_flags+0x18/0x48)
[4144039.303558] [<c06741e8>] (dev_change_flags) from [<c068db80>] (do_setlink+0x29c/0x990)
[4144039.316517] [<c068db80>] (do_setlink) from [<c068eae8>] (__rtnl_newlink+0x4a4/0x72c)
[4144039.329282] [<c068eae8>] (__rtnl_newlink) from [<c068edb0>] (rtnl_newlink+0x40/0x60)
[4144039.342023] [<c068edb0>] (rtnl_newlink) from [<c0689a10>] (rtnetlink_rcv_msg+0x244/0x470)
[4144039.355224] [<c0689a10>] (rtnetlink_rcv_msg) from [<c06d20a0>] (netlink_rcv_skb+0xe0/0xf4)
[4144039.368492] [<c06d20a0>] (netlink_rcv_skb) from [<c06d194c>] (netlink_unicast+0x170/0x1b8)
[4144039.381758] [<c06d194c>] (netlink_unicast) from [<c06d1cdc>] (netlink_sendmsg+0x2b8/0x340)
[4144039.395023] [<c06d1cdc>] (netlink_sendmsg) from [<c064999c>] (sock_sendmsg+0x14/0x24)
[4144039.407825] [<c064999c>] (sock_sendmsg) from [<c064a5a0>] (___sys_sendmsg+0x200/0x214)
[4144039.420714] [<c064a5a0>] (___sys_sendmsg) from [<c064b0c4>] (__sys_sendmsg+0x40/0x6c)
[4144039.433506] [<c064b0c4>] (__sys_sendmsg) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
[4144039.446366] Exception stack(0xe1933fa8 to 0xe1933ff0)
[4144039.456329] 3fa0: bea086f0 bea086bc 00000003 bea086d0 00000000 00000000
[4144039.469464] 3fc0: bea086f0 bea086bc 00000000 00000128 0062a278 bea086d0 5d5011f3 0062a000
[4144039.482590] 3fe0: 00000128 bea08680 b6dfc4cb b6d7d6f6
[4144039.492652] irq event stamp: 0
[4144039.500650] hardirqs last enabled at (0): [<00000000>] (null)
[4144039.511628] hardirqs last disabled at (0): [<c002e55c>] copy_process.part.4+0x30c/0x19e8
[4144039.524691] softirqs last enabled at (0): [<c002e55c>] copy_process.part.4+0x30c/0x19e8
[4144039.537691] softirqs last disabled at (0): [<00000000>] (null)
[4144039.548554] ---[ end trace b5e8d4b0f30ae00b ]---
--
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
* [BUG] fec mdio times out under system stress
From: Russell King - ARM Linux admin @ 2019-08-11 13:37 UTC (permalink / raw)
To: linux-arm-kernel, Fabio Estevam, netdev, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Hi Fabio,
When I woke up this morning, I found that one of the Hummingboards
had gone offline (as in, lost network link) during the night.
Investigating, I find that the system had gone into OOM, and at
that time, triggered an unrelated:
[4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
[4111697.712996] MII_DATA: 0x6006796d
[4111697.729415] MII_SPEED: 0x0000001a
[4111697.745232] IEVENT: 0x00000000
[4111697.745242] IMASK: 0x0a8000aa
[4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
[4111698.009882] fec 2188000.ethernet eth0: Link is Down
This is on a dual-core iMX6.
It looks like the read actually completed (since MII_DATA contains
the register data) but we somehow lost the interrupt (or maybe
received the interrupt after wait_for_completion_timeout() timed
out.)
From what I can see, the OOM events happened on CPU1, CPU1 was
allocated the FEC interrupt, and the PHY polling that suffered the
MDIO timeout was on CPU0.
Given that IEVENT is zero, it seems that CPU1 had read serviced the
interrupt, but it is not clear how far through processing that it
was - it may be that fec_enet_interrupt() had been delayed by the
OOM condition.
This seems rather fragile - as the system slowing down due to OOM
triggers the network to completely collapse by phylib taking the
PHY offline, making the system inaccessible except through the
console.
In my case, even serial console wasn't operational (except for
magic sysrq). Not sure what agetty was playing at... so the only
way I could recover any information from the system was to connect
the HDMI and plug in a USB keyboard.
Any thoughts on how FEC MDIO accesses could be made more robust?
Maybe phylib should retry a number of times - but with read-sensitive
registers, if the read has already completed successfully, and its
just a problem with the FEC MDIO hardware, that could cause issues.
Thanks.
--
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 v4] firmware: imx: Add DSP IPC protocol interface
From: Daniel Baluta @ 2019-08-11 13:21 UTC (permalink / raw)
To: Daniel Baluta
Cc: Aisheng Dong, Anson Huang, Shawn Guo, Sascha Hauer,
Sridharan, Ranjani, Linux Kernel Mailing List,
Pierre-Louis Bossart, Oleksij Rempel, dl-linux-imx,
Pengutronix Kernel Team, Greg Kroah-Hartman, tglx, Fabio Estevam,
linux-arm-kernel, sound-open-firmware
In-Reply-To: <20190801095636.22944-1-daniel.baluta@nxp.com>
Hi Shawn,
Can you please have a look at this when you have some time?
Basically, we need this patch for imx8 SOF Linux driver:
https://github.com/thesofproject/linux/pull/1048
I already got:
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
For an older version of this patch.
thanks,
Daniel.
On Thu, Aug 1, 2019 at 1:02 PM Daniel Baluta <daniel.baluta@nxp.com> wrote:
>
> Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
> the Tensilica HiFi4 DSP for advanced pre- and post-audio
> processing.
>
> The communication between Host CPU and DSP firmware is
> taking place using a shared memory area for message passing
> and a dedicated Messaging Unit for notifications.
>
> DSP IPC protocol offers a doorbell interface using
> imx-mailbox API.
>
> We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
> request-reply protocol.
>
> Connection 0 (txdb0, rxdb0):
> - Host writes messasge to shared memory [SHMEM]
> - Host sends a request [MU]
> - DSP handles request [SHMEM]
> - DSP sends reply [MU]
>
> Connection 1 (txdb1, rxdb1):
> - DSP writes a message to shared memory [SHMEM]
> - DSP sends a request [MU]
> - Host handles request [SHMEM]
> - Host sends reply [MU]
>
> The protocol interface will be used by a Host client to
> communicate with the DSP. First client will be the i.MX8
> part from Sound Open Firmware infrastructure.
>
> The protocol offers the following interface:
>
> On Tx:
> - imx_dsp_ring_doorbell, will be called to notify the DSP
> that it needs to handle a request.
>
> On Rx:
> - clients need to provide two callbacks:
> .handle_reply
> .handle_request
> - the callbacks will be used by the protocol on
> notification arrival from DSP.
>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> Changes since v3:
> - Added remove function
>
> drivers/firmware/imx/Kconfig | 11 +++
> drivers/firmware/imx/Makefile | 1 +
> drivers/firmware/imx/imx-dsp.c | 155 +++++++++++++++++++++++++++++++
> include/linux/firmware/imx/dsp.h | 67 +++++++++++++
> 4 files changed, 234 insertions(+)
> create mode 100644 drivers/firmware/imx/imx-dsp.c
> create mode 100644 include/linux/firmware/imx/dsp.h
>
> diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
> index 42b566f8903f..0dbee32da4c6 100644
> --- a/drivers/firmware/imx/Kconfig
> +++ b/drivers/firmware/imx/Kconfig
> @@ -1,4 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config IMX_DSP
> + bool "IMX DSP Protocol driver"
> + depends on IMX_MBOX
> + help
> + This enables DSP IPC protocol between host AP (Linux)
> + and the firmware running on DSP.
> + DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP).
> +
> + It acts like a doorbell. Client might use shared memory to
> + exchange information with DSP side.
> +
> config IMX_SCU
> bool "IMX SCU Protocol driver"
> depends on IMX_MBOX
> diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
> index 802c4ad8e8f9..08bc9ddfbdfb 100644
> --- a/drivers/firmware/imx/Makefile
> +++ b/drivers/firmware/imx/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
> new file mode 100644
> index 000000000000..a43d2db5cbdb
> --- /dev/null
> +++ b/drivers/firmware/imx/imx-dsp.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + * Author: Daniel Baluta <daniel.baluta@nxp.com>
> + *
> + * Implementation of the DSP IPC interface (host side)
> + */
> +
> +#include <linux/firmware/imx/dsp.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +/*
> + * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP)
> + *
> + * @dsp: DSP IPC handle
> + * @chan_idx: index of the channel where to trigger the interrupt
> + *
> + * Returns non-negative value for success, negative value for error
> + */
> +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx)
> +{
> + int ret;
> + struct imx_dsp_chan *dsp_chan;
> +
> + if (idx >= DSP_MU_CHAN_NUM)
> + return -EINVAL;
> +
> + dsp_chan = &ipc->chans[idx];
> + ret = mbox_send_message(dsp_chan->ch, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(imx_dsp_ring_doorbell);
> +
> +/*
> + * imx_dsp_handle_rx - rx callback used by imx mailbox
> + *
> + * @c: mbox client
> + * @msg: message received
> + *
> + * Users of DSP IPC will need to privde handle_reply and handle_request
> + * callbacks.
> + */
> +static void imx_dsp_handle_rx(struct mbox_client *c, void *msg)
> +{
> + struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl);
> +
> + if (chan->idx == 0) {
> + chan->ipc->ops->handle_reply(chan->ipc);
> + } else {
> + chan->ipc->ops->handle_request(chan->ipc);
> + imx_dsp_ring_doorbell(chan->ipc, 1);
> + }
> +}
> +
> +static int imx_dsp_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct imx_dsp_ipc *dsp_ipc;
> + struct imx_dsp_chan *dsp_chan;
> + struct mbox_client *cl;
> + char *chan_name;
> + int ret;
> + int i, j;
> +
> + device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent);
> +
> + dsp_ipc = devm_kzalloc(dev, sizeof(*dsp_ipc), GFP_KERNEL);
> + if (!dsp_ipc)
> + return -ENOMEM;
> +
> + for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
> + if (i < 2)
> + chan_name = kasprintf(GFP_KERNEL, "txdb%d", i);
> + else
> + chan_name = kasprintf(GFP_KERNEL, "rxdb%d", i - 2);
> +
> + if (!chan_name)
> + return -ENOMEM;
> +
> + dsp_chan = &dsp_ipc->chans[i];
> + cl = &dsp_chan->cl;
> + cl->dev = dev;
> + cl->tx_block = false;
> + cl->knows_txdone = true;
> + cl->rx_callback = imx_dsp_handle_rx;
> +
> + dsp_chan->ipc = dsp_ipc;
> + dsp_chan->idx = i % 2;
> + dsp_chan->ch = mbox_request_channel_byname(cl, chan_name);
> + if (IS_ERR(dsp_chan->ch)) {
> + ret = PTR_ERR(dsp_chan->ch);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to request mbox chan %s ret %d\n",
> + chan_name, ret);
> + goto out;
> + }
> +
> + dev_dbg(dev, "request mbox chan %s\n", chan_name);
> + /* chan_name is not used anymore by framework */
> + kfree(chan_name);
> + }
> +
> + dsp_ipc->dev = dev;
> +
> + dev_set_drvdata(dev, dsp_ipc);
> +
> + dev_info(dev, "NXP i.MX DSP IPC initialized\n");
> +
> + return devm_of_platform_populate(dev);
> +out:
> + kfree(chan_name);
> + for (j = 0; j < i; j++) {
> + dsp_chan = &dsp_ipc->chans[j];
> + mbox_free_channel(dsp_chan->ch);
> + }
> +
> + return ret;
> +}
> +
> +static int imx_dsp_remove(struct platform_device *pdev)
> +{
> + struct imx_dsp_chan *dsp_chan;
> + struct imx_dsp_ipc *dsp_ipc;
> + int i;
> +
> + dsp_ipc = dev_get_drvdata(&pdev->dev);
> +
> + for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
> + dsp_chan = &dsp_ipc->chans[i];
> + mbox_free_channel(dsp_chan->ch);
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver imx_dsp_driver = {
> + .driver = {
> + .name = "imx-dsp",
> + },
> + .probe = imx_dsp_probe,
> + .remove = imx_dsp_remove,
> +};
> +builtin_platform_driver(imx_dsp_driver);
> +
> +MODULE_AUTHOR("Daniel Baluta <daniel.baluta@nxp.com>");
> +MODULE_DESCRIPTION("IMX DSP IPC protocol driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/firmware/imx/dsp.h b/include/linux/firmware/imx/dsp.h
> new file mode 100644
> index 000000000000..7562099c9e46
> --- /dev/null
> +++ b/include/linux/firmware/imx/dsp.h
> @@ -0,0 +1,67 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2019 NXP
> + *
> + * Header file for the DSP IPC implementation
> + */
> +
> +#ifndef _IMX_DSP_IPC_H
> +#define _IMX_DSP_IPC_H
> +
> +#include <linux/device.h>
> +#include <linux/types.h>
> +#include <linux/mailbox_client.h>
> +
> +#define DSP_MU_CHAN_NUM 4
> +
> +struct imx_dsp_chan {
> + struct imx_dsp_ipc *ipc;
> + struct mbox_client cl;
> + struct mbox_chan *ch;
> + char *name;
> + int idx;
> +};
> +
> +struct imx_dsp_ops {
> + void (*handle_reply)(struct imx_dsp_ipc *ipc);
> + void (*handle_request)(struct imx_dsp_ipc *ipc);
> +};
> +
> +struct imx_dsp_ipc {
> + /* Host <-> DSP communication uses 2 txdb and 2 rxdb channels */
> + struct imx_dsp_chan chans[DSP_MU_CHAN_NUM];
> + struct device *dev;
> + struct imx_dsp_ops *ops;
> + void *private_data;
> +};
> +
> +static inline void imx_dsp_set_data(struct imx_dsp_ipc *ipc, void *data)
> +{
> + if (!ipc)
> + return;
> +
> + ipc->private_data = data;
> +}
> +
> +static inline void *imx_dsp_get_data(struct imx_dsp_ipc *ipc)
> +{
> + if (!ipc)
> + return NULL;
> +
> + return ipc->private_data;
> +}
> +
> +#if IS_ENABLED(CONFIG_IMX_DSP)
> +
> +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *dsp, unsigned int chan_idx);
> +
> +#else
> +
> +static inline int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc,
> + unsigned int chan_idx)
> +{
> + return -ENOTSUPP;
> +}
> +
> +#endif
> +#endif /* _IMX_DSP_IPC_H */
> --
> 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 v6 2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different with mt2701
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Config the different CMDQ reg address in driver data.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 52b49daeed9f..ac8e80e379f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,7 +123,6 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
-#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET 2
@@ -148,6 +147,10 @@
struct phy;
+struct mtk_dsi_driver_data {
+ const u32 reg_cmdq_off;
+};
+
struct mtk_dsi {
struct mtk_ddp_comp ddp_comp;
struct device *dev;
@@ -174,6 +177,7 @@ struct mtk_dsi {
bool enabled;
u32 irq_data;
wait_queue_head_t irq_wait_queue;
+ const struct mtk_dsi_driver_data *driver_data;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -936,6 +940,7 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
const char *tx_buf = msg->tx_buf;
u8 config, cmdq_size, cmdq_off, type = msg->type;
u32 reg_val, cmdq_mask, i;
+ u32 reg_cmdq_off = dsi->driver_data->reg_cmdq_off;
if (MTK_DSI_HOST_IS_READ(type))
config = BTA;
@@ -955,9 +960,11 @@ static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
}
for (i = 0; i < msg->tx_len; i++)
- writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+ mtk_dsi_mask(dsi, (reg_cmdq_off + cmdq_off + i) & (~0x3U),
+ (0xffUL << (((i + cmdq_off) & 3U) * 8U)),
+ tx_buf[i] << (((i + cmdq_off) & 3U) * 8U));
- mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, reg_cmdq_off, cmdq_mask, reg_val);
mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
}
@@ -1101,6 +1108,8 @@ static int mtk_dsi_probe(struct platform_device *pdev)
if (ret)
goto err_unregister_host;
+ dsi->driver_data = of_device_get_match_data(dev);
+
dsi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dsi->engine_clk)) {
ret = PTR_ERR(dsi->engine_clk);
@@ -1194,9 +1203,19 @@ static int mtk_dsi_remove(struct platform_device *pdev)
return 0;
}
+static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+};
+
+static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
+ .reg_cmdq_off = 0x180,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
- { .compatible = "mediatek,mt2701-dsi" },
- { .compatible = "mediatek,mt8173-dsi" },
+ { .compatible = "mediatek,mt2701-dsi",
+ .data = &mt2701_dsi_driver_data },
+ { .compatible = "mediatek,mt8173-dsi",
+ .data = &mt8173_dsi_driver_data },
{ },
};
--
2.21.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 v6 5/7] drm/mediatek: add mt8183 dsi driver support
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Add mt8183 dsi driver data. Enable size control and
reg commit control.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 68794edecf96..b3676426aeb5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1227,11 +1227,19 @@ static const struct mtk_dsi_driver_data mt2701_dsi_driver_data = {
.reg_cmdq_off = 0x180,
};
+static const struct mtk_dsi_driver_data mt8183_dsi_driver_data = {
+ .reg_cmdq_off = 0x200,
+ .has_shadow_ctl = true,
+ .has_size_ctl = true,
+};
+
static const struct of_device_id mtk_dsi_of_match[] = {
{ .compatible = "mediatek,mt2701-dsi",
.data = &mt2701_dsi_driver_data },
{ .compatible = "mediatek,mt8173-dsi",
.data = &mt8173_dsi_driver_data },
+ { .compatible = "mediatek,mt8183-dsi",
+ .data = &mt8183_dsi_driver_data },
{ },
};
--
2.21.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 v6 3/7] drm/mediatek: add dsi reg commit disable control
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
New DSI IP has shadow register and working reg. The register
values are writen to shadow register. And then trigger with
commit reg, the register values will be moved working register.
This fucntion is defualt on. But this driver doesn't use this
function. So add the disable control.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ac8e80e379f7..314bfb1c827b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -123,6 +123,10 @@
#define VM_CMD_EN BIT(0)
#define TS_VFP_EN BIT(5)
+#define DSI_SHADOW_DEBUG 0x190U
+#define FORCE_COMMIT BIT(0)
+#define BYPASS_SHADOW BIT(1)
+
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
#define LONG_PACKET 2
@@ -149,6 +153,7 @@ struct phy;
struct mtk_dsi_driver_data {
const u32 reg_cmdq_off;
+ bool has_shadow_ctl;
};
struct mtk_dsi {
@@ -586,6 +591,11 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
+
+ if (dsi->driver_data->has_shadow_ctl)
+ writel(FORCE_COMMIT | BYPASS_SHADOW,
+ dsi->regs + DSI_SHADOW_DEBUG);
+
mtk_dsi_reset_engine(dsi);
mtk_dsi_phy_timconfig(dsi);
--
2.21.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 v6 7/7] drm: mediatek: adjust dsi and mipi_tx probe sequence
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
mtk_mipi_tx is the phy of mtk_dsi.
mtk_dsi get the phy(mtk_mipi_tx) in probe().
So, mtk_mipi_tx init should be ahead of mtk_dsi. Or mtk_dsi will
defer to wait mtk_mipi_tx probe done.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 95fdbd0fbcac..a762fd9111ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -630,8 +630,8 @@ static struct platform_driver * const mtk_drm_drivers[] = {
&mtk_disp_rdma_driver,
&mtk_dpi_driver,
&mtk_drm_platform_driver,
- &mtk_dsi_driver,
&mtk_mipi_tx_driver,
+ &mtk_dsi_driver,
};
static int __init mtk_drm_init(void)
--
2.21.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 v6 6/7] drm/mediatek: change the dsi phytiming calculate method
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Ryan Case, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Change the method of frame rate calc which can get more accurate
frame rate.
data rate = pixel_clock * bit_per_pixel / lanes
Adjust hfp_wc to adapt the additional phy_data
if MIPI_DSI_MODE_VIDEO_BURST
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
else
hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
Note:
//(2: 1 for sync, 1 for phy idle)
data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
bpp: bit per pixel
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Tested-by: Ryan Case <ryandcase@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 118 ++++++++++++++++++++---------
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b3676426aeb5..4d98ea08635a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -136,12 +136,6 @@
#define DATA_0 (0xff << 16)
#define DATA_1 (0xff << 24)
-#define T_LPX 5
-#define T_HS_PREP 6
-#define T_HS_TRAIL 8
-#define T_HS_EXIT 7
-#define T_HS_ZERO 10
-
#define NS_TO_CYCLE(n, c) ((n) / (c) + (((n) % (c)) ? 1 : 0))
#define MTK_DSI_HOST_IS_READ(type) \
@@ -150,6 +144,25 @@
(type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
(type == MIPI_DSI_DCS_READ))
+struct mtk_phy_timing {
+ u32 lpx;
+ u32 da_hs_prepare;
+ u32 da_hs_zero;
+ u32 da_hs_trail;
+
+ u32 ta_go;
+ u32 ta_sure;
+ u32 ta_get;
+ u32 da_hs_exit;
+
+ u32 clk_hs_zero;
+ u32 clk_hs_trail;
+
+ u32 clk_hs_prepare;
+ u32 clk_hs_post;
+ u32 clk_hs_exit;
+};
+
struct phy;
struct mtk_dsi_driver_data {
@@ -180,6 +193,7 @@ struct mtk_dsi {
enum mipi_dsi_pixel_format format;
unsigned int lanes;
struct videomode vm;
+ struct mtk_phy_timing phy_timing;
int refcount;
bool enabled;
u32 irq_data;
@@ -213,17 +227,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
+
+ ui = DIV_ROUND_UP(1000000000, dsi->data_rate);
+ cycle_time = div_u64(8000000000ULL, dsi->data_rate);
+
+ timing->lpx = NS_TO_CYCLE(60, cycle_time);
+ timing->da_hs_prepare = NS_TO_CYCLE(50 + 5 * ui, cycle_time);
+ timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
+ timing->da_hs_trail = NS_TO_CYCLE(90 + 4 * ui, cycle_time);
- ui = 1000 / dsi->data_rate + 0x01;
- cycle_time = 8000 / dsi->data_rate + 0x01;
+ timing->ta_go = 4 * timing->lpx;
+ timing->ta_sure = 3 * timing->lpx / 2;
+ timing->ta_get = 5 * timing->lpx;
+ timing->da_hs_exit = 2 * timing->lpx;
- timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
- timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
- T_HS_EXIT << 24;
- timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
- NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
+ timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
+ timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
+
+ timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
+ timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
+ timing->clk_hs_exit = 2 * timing->lpx;
+
+ timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
+ timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
+ timcon1 = timing->ta_go | timing->ta_sure << 8 |
+ timing->ta_get << 16 | timing->da_hs_exit << 24;
+ timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
+ timing->clk_hs_trail << 24;
+ timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
+ timing->clk_hs_exit << 16;
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -410,7 +443,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
- u32 dsi_tmp_buf_bpp;
+ u32 dsi_tmp_buf_bpp, data_phy_cycles;
+ struct mtk_phy_timing *timing = &dsi->phy_timing;
struct videomode *vm = &dsi->vm;
@@ -437,7 +471,34 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
dsi_tmp_buf_bpp - 10);
- horizontal_frontporch_byte = (vm->hfront_porch * dsi_tmp_buf_bpp - 12);
+ data_phy_cycles = timing->lpx + timing->da_hs_prepare +
+ timing->da_hs_zero + timing->da_hs_exit + 2;
+
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
+ if (vm->hfront_porch * dsi_tmp_buf_bpp >
+ data_phy_cycles * dsi->lanes + 18) {
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp -
+ data_phy_cycles *
+ dsi->lanes - 18;
+ } else {
+ DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp;
+ }
+ } else {
+ if (vm->hfront_porch * dsi_tmp_buf_bpp >
+ data_phy_cycles * dsi->lanes + 12) {
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp -
+ data_phy_cycles *
+ dsi->lanes - 12;
+ } else {
+ DRM_WARN("HFP less than d-phy, FPS will under 60Hz\n");
+ horizontal_frontporch_byte = vm->hfront_porch *
+ dsi_tmp_buf_bpp;
+ }
+ }
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
@@ -537,8 +598,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->host.dev;
int ret;
- u64 pixel_clock, total_bits;
- u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+ u32 bit_per_pixel;
if (++dsi->refcount != 1)
return 0;
@@ -557,24 +617,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
break;
}
- /**
- * htotal_time = htotal * byte_per_pixel / num_lanes
- * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
- * mipi_ratio = (htotal_time + overhead_time) / htotal_time
- * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
- */
- pixel_clock = dsi->vm.pixelclock;
- htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
- dsi->vm.hsync_len;
- htotal_bits = htotal * bit_per_pixel;
-
- overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
- T_HS_EXIT;
- overhead_bits = overhead_cycles * dsi->lanes * 8;
- total_bits = htotal_bits + overhead_bits;
-
- dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
- htotal * dsi->lanes);
+ dsi->data_rate = DIV_ROUND_UP_ULL(dsi->vm.pixelclock * bit_per_pixel,
+ dsi->lanes);
ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
--
2.21.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 v6 4/7] drm/mediatek: add frame size control
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Our new DSI chip has frame size control.
So add the driver data to control for different chips.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 314bfb1c827b..68794edecf96 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -70,6 +70,7 @@
#define DSI_VBP_NL 0x24
#define DSI_VFP_NL 0x28
#define DSI_VACT_NL 0x2C
+#define DSI_SIZE_CON 0x38
#define DSI_HSA_WC 0x50
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
@@ -154,6 +155,7 @@ struct phy;
struct mtk_dsi_driver_data {
const u32 reg_cmdq_off;
bool has_shadow_ctl;
+ bool has_size_ctl;
};
struct mtk_dsi {
@@ -422,6 +424,10 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
writel(vm->vfront_porch, dsi->regs + DSI_VFP_NL);
writel(vm->vactive, dsi->regs + DSI_VACT_NL);
+ if (dsi->driver_data->has_size_ctl)
+ writel(vm->vactive << 16 | vm->hactive,
+ dsi->regs + DSI_SIZE_CON);
+
horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp - 10);
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
--
2.21.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 v6 1/7] drm/mediatek: move mipi_dsi_host_register to probe
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
DSI panel driver need attach function which is inculde in
mipi_dsi_host_ops.
If mipi_dsi_host_register is not in probe, dsi panel will
probe more delay.
So move the mipi_dsi_host_register to probe from bind.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 53 +++++++++++++++++-------------
1 file changed, 31 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index b91c4616644a..52b49daeed9f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -520,7 +520,7 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
- struct device *dev = dsi->dev;
+ struct device *dev = dsi->host.dev;
int ret;
u64 pixel_clock, total_bits;
u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
@@ -1047,12 +1047,6 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
return ret;
}
- ret = mipi_dsi_host_register(&dsi->host);
- if (ret < 0) {
- dev_err(dev, "failed to register DSI host: %d\n", ret);
- goto err_ddp_comp_unregister;
- }
-
ret = mtk_dsi_create_conn_enc(drm, dsi);
if (ret) {
DRM_ERROR("Encoder create failed with %d\n", ret);
@@ -1062,8 +1056,6 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
return 0;
err_unregister:
- mipi_dsi_host_unregister(&dsi->host);
-err_ddp_comp_unregister:
mtk_ddp_comp_unregister(drm, &dsi->ddp_comp);
return ret;
}
@@ -1075,7 +1067,6 @@ static void mtk_dsi_unbind(struct device *dev, struct device *master,
struct mtk_dsi *dsi = dev_get_drvdata(dev);
mtk_dsi_destroy_conn_enc(dsi);
- mipi_dsi_host_unregister(&dsi->host);
mtk_ddp_comp_unregister(drm, &dsi->ddp_comp);
}
@@ -1099,31 +1090,36 @@ static int mtk_dsi_probe(struct platform_device *pdev)
dsi->host.ops = &mtk_dsi_ops;
dsi->host.dev = dev;
+ ret = mipi_dsi_host_register(&dsi->host);
+ if (ret < 0) {
+ dev_err(dev, "failed to register DSI host: %d\n", ret);
+ return ret;
+ }
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
&dsi->panel, &dsi->bridge);
if (ret)
- return ret;
+ goto err_unregister_host;
dsi->engine_clk = devm_clk_get(dev, "engine");
if (IS_ERR(dsi->engine_clk)) {
ret = PTR_ERR(dsi->engine_clk);
dev_err(dev, "Failed to get engine clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->digital_clk = devm_clk_get(dev, "digital");
if (IS_ERR(dsi->digital_clk)) {
ret = PTR_ERR(dsi->digital_clk);
dev_err(dev, "Failed to get digital clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->hs_clk = devm_clk_get(dev, "hs");
if (IS_ERR(dsi->hs_clk)) {
ret = PTR_ERR(dsi->hs_clk);
dev_err(dev, "Failed to get hs clock: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1131,33 +1127,35 @@ static int mtk_dsi_probe(struct platform_device *pdev)
if (IS_ERR(dsi->regs)) {
ret = PTR_ERR(dsi->regs);
dev_err(dev, "Failed to ioremap memory: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
dsi->phy = devm_phy_get(dev, "dphy");
if (IS_ERR(dsi->phy)) {
ret = PTR_ERR(dsi->phy);
dev_err(dev, "Failed to get MIPI-DPHY: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DSI);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
- return comp_id;
+ ret = comp_id;
+ goto err_unregister_host;
}
ret = mtk_ddp_comp_init(dev, dev->of_node, &dsi->ddp_comp, comp_id,
&mtk_dsi_funcs);
if (ret) {
dev_err(dev, "Failed to initialize component: %d\n", ret);
- return ret;
+ goto err_unregister_host;
}
irq_num = platform_get_irq(pdev, 0);
if (irq_num < 0) {
- dev_err(&pdev->dev, "failed to request dsi irq resource\n");
- return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "failed to get dsi irq_num: %d\n", irq_num);
+ ret = irq_num;
+ goto err_unregister_host;
}
irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
@@ -1165,14 +1163,24 @@ static int mtk_dsi_probe(struct platform_device *pdev)
IRQF_TRIGGER_LOW, dev_name(&pdev->dev), dsi);
if (ret) {
dev_err(&pdev->dev, "failed to request mediatek dsi irq\n");
- return -EPROBE_DEFER;
+ goto err_unregister_host;
}
init_waitqueue_head(&dsi->irq_wait_queue);
platform_set_drvdata(pdev, dsi);
- return component_add(&pdev->dev, &mtk_dsi_component_ops);
+ ret = component_add(&pdev->dev, &mtk_dsi_component_ops);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to add component: %d\n", ret);
+ goto err_unregister_host;
+ }
+
+ return 0;
+
+err_unregister_host:
+ mipi_dsi_host_unregister(&dsi->host);
+ return ret;
}
static int mtk_dsi_remove(struct platform_device *pdev)
@@ -1181,6 +1189,7 @@ static int mtk_dsi_remove(struct platform_device *pdev)
mtk_output_dsi_disable(dsi);
component_del(&pdev->dev, &mtk_dsi_component_ops);
+ mipi_dsi_host_unregister(&dsi->host);
return 0;
}
--
2.21.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 v6 0/7] Support dsi for mt8183
From: Jitao Shi @ 2019-08-11 10:40 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
Change since v5:
- fine tune dphy timing.
Change since v4:
- move mipi_dsi_host_unregiter() to .remove()
- fine tune add frame size control coding style
- change the data type of data_rate as u32, and add DIV_ROUND_UP_ULL
- use div_u64 when 8000000000ULL / dsi->data_rate.
Changes since v3
- add one more 'tab' for bitwise define.
- add Tested-by: Ryan Case <ryandcase@chromium.org>
and Reviewed-by: CK Hu <ck.hu@mediatek.com>.
- remove compare da_hs_zero to da_hs_prepare.
Changes since v2:
- change the video timing calc method
- fine the dsi and mipitx init sequence
- fine tune commit msg
Changes since v1:
- separate frame size and reg commit control independent patches.
- fix some return values in probe
- remove DSI_CMDW0 in "CMDQ reg address of mt8173 is different with mt2701"
Jitao Shi (7):
drm/mediatek: move mipi_dsi_host_register to probe
drm/mediatek: fixes CMDQ reg address of mt8173 is different with
mt2701
drm/mediatek: add dsi reg commit disable control
drm/mediatek: add frame size control
drm/mediatek: add mt8183 dsi driver support
drm/mediatek: change the dsi phytiming calculate method
drm: mediatek: adjust dsi and mipi_tx probe sequence
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 224 ++++++++++++++++++-------
2 files changed, 161 insertions(+), 65 deletions(-)
--
2.21.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 wn 3/4] dt-bindings: display: panel: add auo kd101n80-45na panel bindings
From: Jitao Shi @ 2019-08-11 9:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Sam Ravnborg, Ajay Kumar,
Vincent Palatin, cawa.cheng, bibby.hsieh, ck.hu, Russell King,
Thierry Reding, devicetree, Jitao Shi, Philipp Zabel, Inki Dae,
linux-mediatek, yingjoe.chen, eddie.huang, linux-arm-kernel,
Rahul Sharma, srv_heupstream, linux-kernel, Sascha Hauer,
Sean Paul
In-Reply-To: <20190811091001.49555-1-jitao.shi@mediatek.com>
Add documentation for auo kd101n80-45na panel.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
---
.../display/panel/auo,kd101n80-45na.txt | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
diff --git a/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
new file mode 100644
index 000000000000..994c2a13f942
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.txt
@@ -0,0 +1,34 @@
+AUO Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,kd101n80-45na"
+- reg: the virtual channel number of a DSI peripheral
+- enable-gpios: a GPIO spec for the enable pin
+- pp1800-supply: core voltage supply
+- avdd-supply: phandle of the regulator that provides positive voltage
+- avee-supply: phandle of the regulator that provides negative voltage
+- backlight: phandle of the backlight device attached to the panel
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+&dsi {
+ ...
+ panel@0 {
+ compatible = "auo,kd101n80-45na";
+ reg = <0>;
+ enable-gpios = <&pio 45 0>;
+ avdd-supply = <&ppvarn_lcd>;
+ avee-supply = <&ppvarp_lcd>;
+ pp1800-supply = <&pp1800_lcd>;
+ backlight = <&backlight_lcd0>;
+ status = "okay";
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
--
2.21.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 wn 4/4] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel
From: Jitao Shi @ 2019-08-11 9:10 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190811091001.49555-1-jitao.shi@mediatek.com>
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/panel/Kconfig | 6 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c | 76 ++++++++++++++++---
2 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index afcadb3585fb..0e887c978796 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -19,13 +19,13 @@ config DRM_PANEL_ARM_VERSATILE
in the Versatile family syscon registers.
config DRM_PANEL_BOE_TV101WUM_NL6
- tristate "BOE TV101WUM 1200x1920 panel"
+ tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index c0e27f0b2713..aef4f8034c5b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -35,6 +35,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+ bool discharge_on_disable;
};
struct boe_panel {
@@ -372,6 +373,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0x11),
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0x29),
+ _INIT_DELAY_CMD(120),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -449,20 +459,30 @@ static int boe_panel_unprepare(struct drm_panel *panel)
if (!boe->prepared)
return 0;
- ret = boe_panel_off(boe);
- if (ret < 0) {
- dev_err(panel->dev, "failed to set panel off: %d\n", ret);
- return ret;
+ if (boe->desc->discharge_on_disable) {
+ msleep(150);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ } else {
+ ret = boe_panel_off(boe);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to set panel off: %d\n",
+ ret);
+ return ret;
+ }
+ msleep(150);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(500, 1000);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
}
- msleep(150);
- gpiod_set_value(boe->enable_gpio, 0);
- usleep_range(500, 1000);
- regulator_disable(boe->avee);
- regulator_disable(boe->avdd);
- usleep_range(5000, 7000);
- regulator_disable(boe->pp1800);
-
boe->prepared = false;
return 0;
@@ -564,6 +584,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+ .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_default_mode = {
+ .clock = 157000,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 + 80 + 24,
+ .htotal = 1200 + 80 + 24 + 36,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 16,
+ .vsync_end = 1920 + 16 + 4,
+ .vtotal = 1920 + 16 + 4 + 16,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_kd101n80_45na_desc = {
+ .modes = &auo_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_init_cmd,
+ .discharge_on_disable = true,
};
static int boe_panel_get_modes(struct drm_panel *panel)
@@ -689,6 +738,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-nl6",
.data = &boe_tv101wum_nl6_desc
},
+ { .compatible = "auo,kd101n80-45na",
+ .data = &auo_kd101n80_45na_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.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
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