* Re: [PATCH v6 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles
From: Krzysztof Kozlowski @ 2019-08-22 13:45 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+YZ9KdCCT1grtpf7Z1o=-mFuq3O=o7iVGSAhJYO1-=Ww@mail.gmail.com>
On Thu, 22 Aug 2019 at 14:52, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Aug 21, 2019 at 12:55 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Tue, Aug 20, 2019 at 03:27:39PM -0500, Rob Herring wrote:
> > > > I see. If I understand the schema correctly, this should look like:
> > >
> > > Looks correct, but a couple of comments.
> > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > index 7294ac36f4c0..eb263d1ccf13 100644
> > > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > > @@ -161,6 +161,22 @@ properties:
> > > > items:
> > > > - enum:
> > > > - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> > > > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> > >
> > > Is the SOM ever used alone? If not, then no point in listing this here.
> >
> > SoM alone: no, because it requires some type of base board. However it
> > will be used by some customer designs with some amount of
> > changes/addons.
> >
> > Looking at other aproaches, usually SoMs have their own compatible. In
> > such case - I should document it somewhere.
>
> I wasn't suggesting not having the compatible for it, but you don't
> need it in this list because that is not valid. You have to list it
> with the base board compatibles.
The diff against v7 would be like this then:
---
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 1f440817fc03..7219c15f6185 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,7 +161,6 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- - kontron,imx6ul-n6310-som # Kontron N6310 SOM
- const: fsl,imx6ul
- description: Kontron N6310 S Board
---
This passes the dtbs_check.
I'll send v8
_______________________________________________
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: [RESEND PATCH] KVM: arm: VGIC: properly initialise private IRQ affinity
From: Andre Przywara @ 2019-08-22 13:42 UTC (permalink / raw)
To: Zenghui Yu
Cc: Marc Zyngier, Christoffer Dall, kvmarm, Julien Grall, Dave Martin,
linux-arm-kernel
In-Reply-To: <6d2ff99a-a97b-bb4d-3df1-8e22e804aa6a@huawei.com>
On Thu, 22 Aug 2019 01:13:32 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
Hi,
> On 2019/8/22 1:00, Andre Przywara wrote:
> > At the moment we initialise the target *mask* of a virtual IRQ to the
> > VCPU it belongs to, even though this mask is only defined for GICv2 and
> > quickly runs out of bits for many GICv3 guests.
> > This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
> > ------
> > [ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
> > [ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
> > ------
> > Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
> > dump is wrong, due to this very same problem.
> >
> > Fix both issues by only initialising vgic_irq->targets for a vGICv2 guest,
> > and by initialising vgic_irq->mpdir for vGICv3 guests instead. We can't
> > use the actual MPIDR for that, as the VCPU's system register is not
> > initialised at this point yet. This is not really an issue, as ->mpidr
> > is just used for the debugfs output and the IROUTER MMIO register, which
> > does not exist in redistributors (dealing with SGIs and PPIs).
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > Reported-by: Dave Martin <dave.martin@arm.com>
> > ---
> > Hi,
> >
> > this came up here again, I think it fell through the cracks back in
> > March:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637209.html
> >
> > Cheers,
> > Andre.
> >
> > virt/kvm/arm/vgic/vgic-init.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
> > index 80127ca9269f..8bce2f75e0c1 100644
> > --- a/virt/kvm/arm/vgic/vgic-init.c
> > +++ b/virt/kvm/arm/vgic/vgic-init.c
> > @@ -210,7 +210,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
> > irq->intid = i;
> > irq->vcpu = NULL;
> > irq->target_vcpu = vcpu;
> > - irq->targets = 1U << vcpu->vcpu_id;
> > kref_init(&irq->refcount);
> > if (vgic_irq_is_sgi(i)) {
> > /* SGIs */
> > @@ -221,10 +220,14 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
> > irq->config = VGIC_CONFIG_LEVEL;
> > }
> >
> > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
> > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
>
> I still think that if user-space create VCPUs before vGIC (like what
> Qemu does), the actual vGIC model will be unknown here. The UBSAN
> warning will still show up when booting a vGIC-v3 guest (with Qemu).
Yes, you are right. I vaguely remembered this issue, but couldn't find anything on the list about it. So thanks for the heads up!
So I think I have a solution, where we drop the initialisation part here altogether, instead initialise mpdir/targets together with the group in vgic_init(). Unless there is some code which needs irq->group before that point?
Will send a patch shortly.
Cheers,
Andre.
> > irq->group = 1;
> > - else
> > + /* The actual MPIDR is not initialised at this point. */
> > + irq->mpidr = 0;
> > + } else {
> > irq->group = 0;
> > + irq->targets = 1U << vcpu->vcpu_id;
> > + }
> > }
> >
> > if (!irqchip_in_kernel(vcpu->kvm))
> >
>
_______________________________________________
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 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
From: Ulf Hansson @ 2019-08-22 13:38 UTC (permalink / raw)
To: Manish Narani
Cc: mark.rutland@arm.com, kernel@esmil.dk, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, Jolly Shah, tony.xie@rock-chips.com,
philipp.tomsich@theobroma-systems.com, heiko@sntech.de,
Rob Herring, linux-rockchip@lists.infradead.org, Rajan Vaja,
Michal Simek, devicetree@vger.kernel.org, Nava kishore Manne,
scott.branden@broadcom.com, ayaka@soulik.info, mdf@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
adrian.hunter@intel.com, olof@lixom.net,
christoph.muellner@theobroma-systems.com
In-Reply-To: <MN2PR02MB60299EB8B83C4EA68A0F2B33C1A80@MN2PR02MB6029.namprd02.prod.outlook.com>
[...]
> > > > > ---
> > > > > Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15
> > ++++++++++-
> > > > ----
> > > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > index 1edbb04..15c6397 100644
> > > > > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > > @@ -23,6 +23,10 @@ Required Properties:
> > > > > - reg: From mmc bindings: Register location and length.
> > > > > - clocks: From clock bindings: Handles to clock inputs.
> > > > > - clock-names: From clock bindings: Tuple including "clk_xin" and
> > "clk_ahb"
> > > > > + Apart from these two there is one more optional clock which
> > > > > + is "clk_sdcard". This clock represents output clock from
> > > > > + controller and card. This must be specified when #clock-cells
> > > > > + is specified.
> > > > > - interrupts: Interrupt specifier
> > > > >
> > > > > Required Properties for "arasan,sdhci-5.1":
> > > > > @@ -36,9 +40,10 @@ Optional Properties:
> > > > > - clock-output-names: If specified, this will be the name of the card
> > clock
> > > > > which will be exposed by this device. Required if #clock-cells is
> > > > > specified.
> > > > > - - #clock-cells: If specified this should be the value <0>. With this
> > property
> > > > > - in place we will export a clock representing the Card Clock. This clock
> > > > > - is expected to be consumed by our PHY. You must also specify
> > > > > + - #clock-cells: If specified this should be the value <0>. With this
> > > > > + property in place we will export one clock representing the Card
> > > > > + Clock. This clock is expected to be consumed by our PHY. You must
> > also
> > > > > + specify
> > > >
> > > > specify what?
> > > I think this line was already there, I missed to correct it, Will update in v3.
> > >
> > > >
> > > > The 3rd clock input I assume? This statement means any existing users
> > > > with 2 clock inputs and #clock-cells are in error now. Is that correct?
> > > Yes, this is correct. So far there was only one vendor using '#clock-cells'
> > which is Rockchip. I have sent DT patch (02/11) for that also.
> > > Here this is needed as earlier implementation isn't correct as suggested by
> > Uffe. (https://lkml.org/lkml/2019/6/20/486) .
> >
> > I am not sure how big of a problem the backwards compatible thingy
> > with DT is, in general we must not break it. What do you say Manish?
>
> Though I agree with Uffe on this, there is no other way from my understanding. Please suggest.
>
> >
> > As a workaround, would it be possible to use
> > of_clk_get_from_provider() somehow to address the compatibility issue?
>
> For this to be used we have to parse 'clkspec' from the DT node and pass the same as an argument to this function. In this case also the DT node needs to be updated, which is same as we have done in this series.
Alright. I guess breaking DTBs for Rockchip platforms isn't
acceptable, especially if those are already widely deployed, which I
have no idea of....
And having support for both options in the driver seems not a great
option either, so it looks like you need to convert back into the old
v1 approach. Huh, sorry.
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Alexandre Belloni @ 2019-08-22 13:36 UTC (permalink / raw)
To: Ran Bi
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <1566480361.12318.50.camel@mhfsdcap03>
On 22/08/2019 21:26:01+0800, Ran Bi wrote:
> On Thu, 2019-08-22 at 14:46 +0200, Alexandre Belloni wrote:
> > On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> > > >
> > > > This should be written when setting the time after power was lost.
> > > >
> > >
> > > I suppose we can move this into mt2712_rtc_read_time function's "if
> > > (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> > > which will be added at next patch. We need additional flag to mark this
> > > condition or another if condition in mt2712_rtc_set_time fucntion if we
> > > put these code in mt2712_rtc_set_time function.
> > >
> >
> > It is fine to test both in read_time and in set_time.
> >
>
> Do you mean that we can test powerkey and then set powerkey both in
> read_time and in set_time?
>
I mean that can test in read_time and test and set in set_time
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-22 13:26 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190822124628.GS27031@piout.net>
On Thu, 2019-08-22 at 14:46 +0200, Alexandre Belloni wrote:
> On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> > >
> > > This should be written when setting the time after power was lost.
> > >
> >
> > I suppose we can move this into mt2712_rtc_read_time function's "if
> > (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> > which will be added at next patch. We need additional flag to mark this
> > condition or another if condition in mt2712_rtc_set_time fucntion if we
> > put these code in mt2712_rtc_set_time function.
> >
>
> It is fine to test both in read_time and in set_time.
>
Do you mean that we can test powerkey and then set powerkey both in
read_time and in set_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: [PATCH] arm64: dts: mt8183: add I2C nodes
From: Matthias Brugger @ 2019-08-22 13:21 UTC (permalink / raw)
To: qii.wang, robh+dt
Cc: mark.rutland, devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-arm-kernel
In-Reply-To: <1566477316-13245-1-git-send-email-qii.wang@mediatek.com>
On 22/08/2019 14:35, qii.wang@mediatek.com wrote:
> From: Qii Wang <qii.wang@mediatek.com>
>
> Add i2c nodes to mt8183 and mt8183-evb.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Applied, thanks
> ---
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 96 ++++++++++++++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 189 ++++++++++++++++++++++++++++
> 2 files changed, 285 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index d8e555c..1fb195c 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -30,7 +30,103 @@
> status = "okay";
> };
>
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_0>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_1>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_2>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_3>;
> + status = "okay";
> + clock-frequency = <100000>;
> +};
> +
> +&i2c4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_4>;
> + status = "okay";
> + clock-frequency = <1000000>;
> +};
> +
> +&i2c5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c_pins_5>;
> + status = "okay";
> + clock-frequency = <1000000>;
> +};
> +
> &pio {
> + i2c_pins_0: i2c0{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO82__FUNC_SDA0>,
> + <PINMUX_GPIO83__FUNC_SCL0>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_1: i2c1{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO81__FUNC_SDA1>,
> + <PINMUX_GPIO84__FUNC_SCL1>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_2: i2c2{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO103__FUNC_SCL2>,
> + <PINMUX_GPIO104__FUNC_SDA2>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_3: i2c3{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
> + <PINMUX_GPIO51__FUNC_SDA3>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_4: i2c4{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO105__FUNC_SCL4>,
> + <PINMUX_GPIO106__FUNC_SDA4>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> + i2c_pins_5: i2c5{
> + pins_i2c{
> + pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
> + <PINMUX_GPIO49__FUNC_SDA5>;
> + mediatek,pull-up-adv = <3>;
> + mediatek,drive-strength-adv = <00>;
> + };
> + };
> +
> spi_pins_0: spi0{
> pins_spi{
> pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>,
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4..ab71291 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -16,6 +16,21 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
> + i2c5 = &i2c5;
> + i2c6 = &i2c6;
> + i2c7 = &i2c7;
> + i2c8 = &i2c8;
> + i2c9 = &i2c9;
> + i2c10 = &i2c10;
> + i2c11 = &i2c11;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -294,6 +309,64 @@
> status = "disabled";
> };
>
> + i2c6: i2c@11005000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11005000 0 0x1000>,
> + <0 0x11000600 0 0x80>;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C6>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c@11007000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11007000 0 0x1000>,
> + <0 0x11000080 0 0x80>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C0>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c@11008000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11008000 0 0x1000>,
> + <0 0x11000100 0 0x80>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C1>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C1_ARBITER>;
> + clock-names = "main", "dma","arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@11009000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11009000 0 0x1000>,
> + <0 0x11000280 0 0x80>;
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C2>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C2_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi0: spi@1100a000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -307,6 +380,20 @@
> status = "disabled";
> };
>
> + i2c3: i2c@1100f000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1100f000 0 0x1000>,
> + <0 0x11000400 0 0x80>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C3>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi1: spi@11010000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -320,6 +407,20 @@
> status = "disabled";
> };
>
> + i2c1: i2c@11011000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11011000 0 0x1000>,
> + <0 0x11000480 0 0x80>;
> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C4>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi2: spi@11012000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -346,6 +447,66 @@
> status = "disabled";
> };
>
> + i2c9: i2c@11014000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11014000 0 0x1000>,
> + <0 0x11000180 0 0x80>;
> + interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C1_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C1_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c10: i2c@11015000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11015000 0 0x1000>,
> + <0 0x11000300 0 0x80>;
> + interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C2_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C2_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c5: i2c@11016000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11016000 0 0x1000>,
> + <0 0x11000500 0 0x80>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C5>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C5_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c11: i2c@11017000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x11017000 0 0x1000>,
> + <0 0x11000580 0 0x80>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C5_IMM>,
> + <&infracfg CLK_INFRA_AP_DMA>,
> + <&infracfg CLK_INFRA_I2C5_ARBITER>;
> + clock-names = "main", "dma", "arb";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> spi4: spi@11018000 {
> compatible = "mediatek,mt8183-spi";
> #address-cells = <1>;
> @@ -372,6 +533,34 @@
> status = "disabled";
> };
>
> + i2c7: i2c@1101a000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1101a000 0 0x1000>,
> + <0 0x11000680 0 0x80>;
> + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C7>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c8: i2c@1101b000 {
> + compatible = "mediatek,mt8183-i2c";
> + reg = <0 0x1101b000 0 0x1000>,
> + <0 0x11000700 0 0x80>;
> + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_I2C8>,
> + <&infracfg CLK_INFRA_AP_DMA>;
> + clock-names = "main", "dma";
> + clock-div = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> audiosys: syscon@11220000 {
> compatible = "mediatek,mt8183-audiosys", "syscon";
> reg = <0 0x11220000 0 0x1000>;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
From: Kamil Konieczny @ 2019-08-22 13:18 UTC (permalink / raw)
To: MyungJoo Ham
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, Rob Herring,
Bartlomiej Zolnierkiewicz, Stephen Boyd, Viresh Kumar, linux-pm,
linux-kernel, Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park,
Kukjin Kim, linux-arm-kernel, devicetree, Marek Szyprowski
In-Reply-To: <20190808090234.12577-1-k.konieczny@partner.samsung.com>
Dear MyungJoo,
On 08.08.2019 11:02, Kamil Konieczny wrote:
> Hi,
>
> The main purpose of this patch series is to add coupled regulators for
> Exynos5422/5800 to keep constrain on voltage difference between vdd_arm
> and vdd_int to be at most 300mV. In exynos-bus instead of using
> regulator_set_voltage_tol() with default voltage tolerance it should be
> used regulator_set_voltage_triplet() with volatege range, and this is
> already present in opp/core.c code, so it can be reused. While at this,
> move setting regulators into opp/core.
>
> This patchset was tested on Odroid XU3.
>
> The DTS coupled regulators patch depends on previous patches.
>
> Changes:
> v5:
> - squashed last patch "remove exynos_bus_passive_target()" into second
> - added Acked-by to patch "correct clock enable sequence"
Could you please merge patches 1/4 and 2/4 for v5.4
(they were already Ack-ed by Chanwoo Choi)?
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
> v4:
> - removed "opp: core: add regulators enable and disable" from patchset
> as it was applied by Viresh Kumar and changed cover letter
> - fix patch "devfreq: exynos-bus: correct clock enable sequence" to
> correct order of enable/disable
> - removed unrelated changes in "devfreq: exynos-bus: convert to use
> dev_pm_opp_set_rate()"
> - added new patch "devfreq: exynos-bus: remove exynos_bus_passive_target()"
> as suggested by Chanwoo Choi
> v3:
> - added new exynos-bus patch to correct clock and regulator enabling
> and disabling sequence as suggested by Chanwoo Choi
> - corrected error path in enable and improved commit message in opp/core
> - improve comment in devfreq/exynos-bus.c before devfreq_recommended_opp()
> - change cover letter as there is new patch
> - added note before Signed-off-by in 4th patch
> v2:
> - improve regulators enable/disable code in opp/core as suggested by
> Viresh Kumar
> - add new patch for remove unused dt-bindings as suggested by Krzysztof
> Kozlowski
>
> Kamil Konieczny (3):
> devfreq: exynos-bus: correct clock enable sequence
> devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
> dt-bindings: devfreq: exynos-bus: remove unused property
>
> Marek Szyprowski (1):
> ARM: dts: exynos: add initial data for coupled regulators for
> Exynos5422/5800
>
> .../bindings/devfreq/exynos-bus.txt | 2 -
> arch/arm/boot/dts/exynos5420.dtsi | 34 ++--
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 +
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +
> arch/arm/boot/dts/exynos5800.dtsi | 32 ++--
> drivers/devfreq/exynos-bus.c | 153 +++++-------------
> 6 files changed, 78 insertions(+), 151 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] [PATCH v3 2/2] drm/bridge: Add NWL MIPI DSI host controller support
From: Robert Chiras @ 2019-08-22 13:18 UTC (permalink / raw)
To: dl-linux-imx, narmstrong@baylibre.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org, lee.jones@linaro.org,
devicetree@vger.kernel.org, agx@sigxcpu.org, festevam@gmail.com,
jernej.skrabec@siol.net, daniel@ffwll.ch, mark.rutland@arm.com,
a.hajda@samsung.com, dri-devel@lists.freedesktop.org,
jonas@kwiboo.se, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org, sam@ravnborg.org,
airlied@linux.ie, Laurent.pinchart@ideasonboard.com,
kernel@pengutronix.de, arnd@arndb.de, s.hauer@pengutronix.de
In-Reply-To: <ae518de22f7f0033c607e10ed8ef5330c7b2dff4.1566470526.git.agx@sigxcpu.org>
Hi Guido,
I added my signed-off, plus some comments inline.
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> It has been tested on the Librem 5 devkit using mxsfb.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> Co-developed-by: Robert Chiras <robert.chiras@nxp.com>
> ---
> drivers/gpu/drm/bridge/Kconfig | 2 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501 ++++++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> +++++++++++++++++++++++
> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 ++++
> 8 files changed, 1401 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig
> b/drivers/gpu/drm/bridge/Kconfig
> index 1cc9f502c1f2..7980b5c2156f 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>
> +source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
> +
> source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..d9f6c0f77592 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> new file mode 100644
> index 000000000000..3b157a9f2229
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> @@ -0,0 +1,16 @@
> +config DRM_NWL_MIPI_DSI
> + tristate "Support for Northwest Logic MIPI DSI Host
> controller"
> + depends on DRM
> + depends on COMMON_CLK
> + depends on OF && HAS_IOMEM
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> + select MFD_SYSCON
> + select MULTIPLEXER
> + select REGMAP_MMIO
> + help
> + This enables the Northwest Logic MIPI DSI Host controller
> as
> + for example found on NXP's i.MX8 Processors.
> +
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> new file mode 100644
> index 000000000000..804baf2f1916
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
> +header-test-y += nwl-drv.h nwl-dsi.h
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> new file mode 100644
> index 000000000000..e457438738c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> @@ -0,0 +1,501 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX8 NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/irq.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/mux/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/phy/phy.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/sys_soc.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
> +
> +#define DRV_NAME "nwl-dsi"
> +
> +/* Possible platform specific clocks */
> +#define NWL_DSI_CLK_CORE "core"
> +
> +static const struct regmap_config nwl_dsi_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = NWL_DSI_IRQ_MASK2,
> + .name = DRV_NAME,
> +};
> +
> +struct nwl_dsi_platform_data {
> + int (*poweron)(struct nwl_dsi *dsi);
> + int (*poweroff)(struct nwl_dsi *dsi);
> + int (*select_input)(struct nwl_dsi *dsi);
> + int (*deselect_input)(struct nwl_dsi *dsi);
> + struct nwl_dsi_plat_clk_config
> clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
> +};
> +
> +static inline struct nwl_dsi *bridge_to_dsi(struct drm_bridge
> *bridge)
> +{
> + return container_of(bridge, struct nwl_dsi, bridge);
> +}
> +
> +static int nwl_dsi_set_platform_clocks(struct nwl_dsi *dsi, bool
> enable)
> +{
> + struct device *dev = dsi->dev;
> + const char *id;
> + struct clk *clk;
> + size_t i;
> + unsigned long rate;
> + int ret, result = 0;
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "%s platform clocks\n",
> + enable ? "enabling" : "disabling");
> + for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
> + if (!dsi->clk_config[i].present)
> + continue;
> + id = dsi->clk_config[i].id;
> + clk = dsi->clk_config[i].clk;
> +
> + if (enable) {
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev,
> + "Failed to enable %s
> clk: %d\n",
> + id, ret);
> + result = result ?: ret;
> + }
> + rate = clk_get_rate(clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "Enabled %s clk
> @%lu Hz\n",
> + id, rate);
> + } else {
> + clk_disable_unprepare(clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "Disabled %s
> clk\n", id);
> + }
> + }
> +
> + return result;
> +}
> +
> +static int nwl_dsi_plat_enable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> + int ret;
> +
> + if (dsi->pdata->select_input)
> + dsi->pdata->select_input(dsi);
> +
> + ret = nwl_dsi_set_platform_clocks(dsi, true);
> + if (ret < 0)
> + return ret;
> +
> + ret = dsi->pdata->poweron(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "Failed to power on DSI: %d\n",
> ret);
> + return ret;
> +}
> +
> +static void nwl_dsi_plat_disable(struct nwl_dsi *dsi)
> +{
> + dsi->pdata->poweroff(dsi);
> + nwl_dsi_set_platform_clocks(dsi, false);
> + if (dsi->pdata->deselect_input)
> + dsi->pdata->deselect_input(dsi);
> +}
> +
> +static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + nwl_dsi_disable(dsi);
> + nwl_dsi_plat_disable(dsi);
> + pm_runtime_put(dsi->dev);
> +}
> +
> +static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
> + const struct drm_display_mode
> *mode,
> + union phy_configure_opts
> *phy_opts)
> +{
> + unsigned long rate;
> + int ret;
> +
> + if (dsi->lanes < 1 || dsi->lanes > 4)
> + return -EINVAL;
> +
> + /*
> + * So far the DPHY spec minimal timings work for both mixel
> + * dphy and nwl dsi host
> + */
> + ret = phy_mipi_dphy_get_default_config(
> + mode->crtc_clock * 1000,
> + mipi_dsi_pixel_format_to_bpp(dsi->format), dsi-
> >lanes,
> + &phy_opts->mipi_dphy);
> + if (ret < 0)
> + return ret;
> +
> + rate = clk_get_rate(dsi->tx_esc_clk);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "LP clk is @%lu Hz\n", rate);
> + phy_opts->mipi_dphy.lp_clk_rate = rate;
> +
> + return 0;
> +}
> +
> +static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode
> *mode,
> + struct drm_display_mode
> *adjusted_mode)
> +{
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> +
> + return true;
> +}
> +
> +static enum drm_mode_status
> +nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + if (mode->clock * bpp > 15000000)
> + return MODE_CLOCK_HIGH;
> +
> + if (mode->clock * bpp < 80000)
> + return MODE_CLOCK_LOW;
These limits (80MBPS min and 1500MBPS max) are per lane, so you should
involve the numbers of lanes here, too. According to this formula, you
limit the maximum DSI throughput to 1.5Gbps, while the maximum is 6Gbps
(1.5 * 4 lanes)
> +
> + return MODE_OK;
> +}
> +
> +static void
> +nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> + struct device *dev = dsi->dev;
> + union phy_configure_opts new_cfg;
> + unsigned long phy_ref_rate;
> + int ret;
> +
> + ret = nwl_dsi_get_dphy_params(dsi, adjusted_mode, &new_cfg);
> + if (ret < 0)
> + return;
> +
> + /*
> + * If hs clock is unchanged, we're all good - all parameters
> are
> + * derived from it atm.
> + */
> + if (new_cfg.mipi_dphy.hs_clk_rate == dsi-
> >phy_cfg.mipi_dphy.hs_clk_rate)
> + return;
> +
> + phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n",
> phy_ref_rate);
> + /* Save the new desired phy config */
> + memcpy(&dsi->phy_cfg, &new_cfg, sizeof(new_cfg));
> +
> + memcpy(&dsi->mode, adjusted_mode, sizeof(dsi->mode));
> + drm_mode_debug_printmodeline(adjusted_mode);
> +}
> +
> +static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> +
> + pm_runtime_get_sync(dsi->dev);
> + nwl_dsi_plat_enable(dsi);
> + nwl_dsi_enable(dsi);
> +}
> +
> +static int nwl_dsi_bridge_attach(struct drm_bridge *bridge)
> +{
> + struct nwl_dsi *dsi = bridge->driver_private;
> +
> + return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
> bridge);
> +}
> +
> +static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
> + .pre_enable = nwl_dsi_bridge_pre_enable,
> + .disable = nwl_dsi_bridge_disable,
> + .mode_fixup = nwl_dsi_bridge_mode_fixup,
> + .mode_set = nwl_dsi_bridge_mode_set,
> + .mode_valid = nwl_dsi_bridge_mode_valid,
> + .attach = nwl_dsi_bridge_attach,
> +};
> +
> +static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> +{
> + struct platform_device *pdev = to_platform_device(dsi->dev);
> + struct clk *clk;
> + const char *clk_id;
> + void __iomem *base;
> + int i, ret;
> +
> + dsi->phy = devm_phy_get(dsi->dev, "dphy");
> + if (IS_ERR(dsi->phy)) {
> + ret = PTR_ERR(dsi->phy);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dsi->dev, "Could not get PHY:
> %d\n", ret);
> + return ret;
> + }
> +
> + /* Platform dependent clocks */
> + memcpy(dsi->clk_config, dsi->pdata->clk_config,
> + sizeof(dsi->pdata->clk_config));
> +
> + for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
> + if (!dsi->clk_config[i].present)
> + continue;
> +
> + clk_id = dsi->clk_config[i].id;
> + clk = devm_clk_get(dsi->dev, clk_id);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get %s
> clock: %d\n",
> + clk_id, ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Setup clk %s (rate:
> %lu)\n",
> + clk_id, clk_get_rate(clk));
> + dsi->clk_config[i].clk = clk;
> + }
> +
> + /* DSI clocks */
> + clk = devm_clk_get(dsi->dev, "phy_ref");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get phy_ref clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->phy_ref_clk = clk;
> +
> + clk = devm_clk_get(dsi->dev, "rx_esc");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get rx_esc clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->rx_esc_clk = clk;
> +
> + clk = devm_clk_get(dsi->dev, "tx_esc");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + DRM_DEV_ERROR(dsi->dev, "Failed to get tx_esc clock:
> %d\n",
> + ret);
> + return ret;
> + }
> + dsi->tx_esc_clk = clk;
> +
> + dsi->mux = devm_mux_control_get(dsi->dev, NULL);
> + if (IS_ERR(dsi->mux)) {
> + ret = PTR_ERR(dsi->mux);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dsi->dev, "Failed to get mux:
> %d\n", ret);
> + return ret;
> + }
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + dsi->regmap =
> + devm_regmap_init_mmio(dsi->dev, base,
> &nwl_dsi_regmap_config);
> + if (IS_ERR(dsi->regmap)) {
> + ret = PTR_ERR(dsi->regmap);
> + DRM_DEV_ERROR(dsi->dev, "Failed to create NWL DSI
> regmap: %d\n",
> + ret);
> + return ret;
> + }
> +
> + dsi->irq = platform_get_irq(pdev, 0);
> + if (dsi->irq < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to get device IRQ:
> %d\n",
> + dsi->irq);
> + return dsi->irq;
> + }
> +
> + dsi->rstc = devm_reset_control_array_get(dsi->dev, false,
> true);
> + if (IS_ERR(dsi->rstc)) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to get resets:
> %ld\n",
> + PTR_ERR(dsi->rstc));
> + return PTR_ERR(dsi->rstc);
> + }
> +
> + return 0;
> +}
> +
> +static int imx8mq_dsi_select_input(struct nwl_dsi *dsi)
> +{
> + struct device_node *remote;
> + u32 use_dcss = 1;
> + int ret;
> +
> + remote = of_graph_get_remote_node(dsi->dev->of_node, 0, 0);
> + if (strcmp(remote->name, "lcdif") == 0)
> + use_dcss = 0;
> +
> + DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
> + (use_dcss) ? "DCSS" : "LCDIF");
> +
> + ret = mux_control_try_select(dsi->mux, use_dcss);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to select input:
> %d\n", ret);
> +
> + of_node_put(remote);
> + return ret;
> +}
> +
> +
> +static int imx8mq_dsi_deselect_input(struct nwl_dsi *dsi)
> +{
> + int ret;
> +
> + ret = mux_control_deselect(dsi->mux);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to deselect input:
> %d\n", ret);
> +
> + return ret;
> +}
> +
> +
> +static int imx8mq_dsi_poweron(struct nwl_dsi *dsi)
> +{
> + int ret = 0;
> +
> + /* otherwise the display stays blank */
> + usleep_range(200, 300);
> +
> + if (dsi->rstc)
> + ret = reset_control_deassert(dsi->rstc);
> +
> + return ret;
> +}
> +
> +static int imx8mq_dsi_poweroff(struct nwl_dsi *dsi)
> +{
> + int ret = 0;
> +
> + if (dsi->quirks & SRC_RESET_QUIRK)
> + return 0;
> +
> + if (dsi->rstc)
> + ret = reset_control_assert(dsi->rstc);
> + return ret;
> +}
> +
> +static const struct drm_bridge_timings nwl_dsi_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_DE_LOW,
> +};
> +
> +static const struct nwl_dsi_platform_data imx8mq_dev = {
> + .poweron = &imx8mq_dsi_poweron,
> + .poweroff = &imx8mq_dsi_poweroff,
> + .select_input = &imx8mq_dsi_select_input,
> + .deselect_input = &imx8mq_dsi_deselect_input,
> + .clk_config = {
> + { .id = NWL_DSI_CLK_CORE, .present = true },
> + },
> +};
> +
> +static const struct of_device_id nwl_dsi_dt_ids[] = {
> + { .compatible = "fsl,imx8mq-nwl-dsi", .data = &imx8mq_dev, },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, nwl_dsi_dt_ids);
> +
> +static const struct soc_device_attribute nwl_dsi_quirks_match[] = {
> + { .soc_id = "i.MX8MQ", .revision = "2.0",
> + .data = (void *)(E11418_HS_MODE_QUIRK | SRC_RESET_QUIRK) },
> + { /* sentinel. */ },
> +};
> +
> +static int nwl_dsi_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + const struct of_device_id *of_id =
> of_match_device(nwl_dsi_dt_ids, dev);
> + const struct nwl_dsi_platform_data *pdata = of_id->data;
> + const struct soc_device_attribute *attr;
> + struct nwl_dsi *dsi;
> + int ret;
> +
> + dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> + if (!dsi)
> + return -ENOMEM;
> +
> + dsi->dev = dev;
> + dsi->pdata = pdata;
> +
> + ret = nwl_dsi_parse_dt(dsi);
> + if (ret)
> + return ret;
> +
> + ret = devm_request_irq(dev, dsi->irq, nwl_dsi_irq_handler, 0,
> + dev_name(dev), dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to request IRQ %d: %d\n",
> dsi->irq,
> + ret);
> + return ret;
> + }
> +
> + dsi->dsi_host.ops = &nwl_dsi_host_ops;
> + dsi->dsi_host.dev = dev;
> + ret = mipi_dsi_host_register(&dsi->dsi_host);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "Failed to register MIPI host:
> %d\n", ret);
> + return ret;
> + }
> +
> + attr = soc_device_match(nwl_dsi_quirks_match);
> + if (attr)
> + dsi->quirks = (uintptr_t)attr->data;
> +
> + dsi->bridge.driver_private = dsi;
> + dsi->bridge.funcs = &nwl_dsi_bridge_funcs;
> + dsi->bridge.of_node = dev->of_node;
> + dsi->bridge.timings = &nwl_dsi_timings;
> +
> + drm_bridge_add(&dsi->bridge);
> +
> + dev_set_drvdata(dev, dsi);
> + pm_runtime_enable(dev);
> + return 0;
> +}
> +
> +static int nwl_dsi_remove(struct platform_device *pdev)
> +{
> + struct nwl_dsi *dsi = platform_get_drvdata(pdev);
> +
> + mipi_dsi_host_unregister(&dsi->dsi_host);
> + pm_runtime_disable(&pdev->dev);
> + return 0;
> +}
> +
> +static struct platform_driver nwl_dsi_driver = {
> + .probe = nwl_dsi_probe,
> + .remove = nwl_dsi_remove,
> + .driver = {
> + .of_match_table = nwl_dsi_dt_ids,
> + .name = DRV_NAME,
> + },
> +};
> +
> +module_platform_driver(nwl_dsi_driver);
> +
> +MODULE_AUTHOR("NXP Semiconductor");
> +MODULE_AUTHOR("Purism SPC");
> +MODULE_DESCRIPTION("Northwest Logic MIPI-DSI driver");
> +MODULE_LICENSE("GPL"); /* GPLv2 or later */
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> new file mode 100644
> index 000000000000..1e72a9221401
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#ifndef __NWL_DRV_H__
> +#define __NWL_DRV_H__
> +
> +#include <linux/mux/consumer.h>
> +#include <linux/phy/phy.h>
> +
> +#include <drm/drm_bridge.h>
> +#include <drm/drm_mipi_dsi.h>
> +
> +struct nwl_dsi_platform_data;
> +
> +/* i.MX8 NWL quirks */
> +/* i.MX8MQ errata E11418 */
> +#define E11418_HS_MODE_QUIRK BIT(0)
> +/* Skip DSI bits in SRC on disable to avoid blank display on enable
> */
> +#define SRC_RESET_QUIRK BIT(1)
> +
> +#define NWL_DSI_MAX_PLATFORM_CLOCKS 1
> +struct nwl_dsi_plat_clk_config {
> + const char *id;
> + struct clk *clk;
> + bool present;
> +};
> +
> +struct nwl_dsi {
> + struct drm_bridge bridge;
> + struct mipi_dsi_host dsi_host;
> + struct drm_bridge *panel_bridge;
> + struct device *dev;
> + struct phy *phy;
> + union phy_configure_opts phy_cfg;
> + unsigned int quirks;
> +
> + struct regmap *regmap;
> + int irq;
> + struct reset_control *rstc;
> + struct mux_control *mux;
> +
> + /* DSI clocks */
> + struct clk *phy_ref_clk;
> + struct clk *rx_esc_clk;
> + struct clk *tx_esc_clk;
> + /* Platform dependent clocks */
> + struct nwl_dsi_plat_clk_config
> clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
> +
> + /* dsi lanes */
> + u32 lanes;
> + enum mipi_dsi_pixel_format format;
> + struct drm_display_mode mode;
> + unsigned long dsi_mode_flags;
> +
> + struct nwl_dsi_transfer *xfer;
> +
> + const struct nwl_dsi_platform_data *pdata;
> +};
> +
> +#endif /* __NWL_DRV_H__ */
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> new file mode 100644
> index 000000000000..fd030af55bb4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> @@ -0,0 +1,700 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/irq.h>
> +#include <linux/regmap.h>
> +#include <linux/time64.h>
> +
> +#include <video/mipi_display.h>
> +#include <video/videomode.h>
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_print.h>
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
> +
> +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> +
> +/*
> + * PKT_CONTROL format:
> + * [15: 0] - word count
> + * [17:16] - virtual channel
> + * [23:18] - data type
> + * [24] - LP or HS select (0 - LP, 1 - HS)
> + * [25] - perform BTA after packet is sent
> + * [26] - perform BTA only, no packet tx
> + */
> +#define NWL_DSI_WC(x) FIELD_PREP(GENMASK(15, 0), (x))
> +#define NWL_DSI_TX_VC(x) FIELD_PREP(GENMASK(17, 16), (x))
> +#define NWL_DSI_TX_DT(x) FIELD_PREP(GENMASK(23, 18), (x))
> +#define NWL_DSI_HS_SEL(x) FIELD_PREP(GENMASK(24, 24), (x))
> +#define NWL_DSI_BTA_TX(x) FIELD_PREP(GENMASK(25, 25), (x))
> +#define NWL_DSI_BTA_NO_TX(x) FIELD_PREP(GENMASK(26, 26), (x))
> +
> +/*
> + * RX_PKT_HEADER format:
> + * [15: 0] - word count
> + * [21:16] - data type
> + * [23:22] - virtual channel
> + */
> +#define NWL_DSI_RX_DT(x) FIELD_GET(GENMASK(21, 16), (x))
> +#define NWL_DSI_RX_VC(x) FIELD_GET(GENMASK(23, 22), (x))
> +
> +/* DSI Video mode */
> +#define NWL_DSI_VM_BURST_MODE_WITH_SYNC_PULSES 0
> +#define NWL_DSI_VM_NON_BURST_MODE_WITH_SYNC_EVENTS BIT(0)
> +#define NWL_DSI_VM_BURST_MODE BIT(1)
> +
> +/* * DPI color coding */
> +#define NWL_DSI_DPI_16_BIT_565_PACKED 0
> +#define NWL_DSI_DPI_16_BIT_565_ALIGNED 1
> +#define NWL_DSI_DPI_16_BIT_565_SHIFTED 2
> +#define NWL_DSI_DPI_18_BIT_PACKED 3
> +#define NWL_DSI_DPI_18_BIT_ALIGNED 4
> +#define NWL_DSI_DPI_24_BIT 5
> +
> +/* * DPI Pixel format */
> +#define NWL_DSI_PIXEL_FORMAT_16 0
> +#define NWL_DSI_PIXEL_FORMAT_18 BIT(0)
> +#define NWL_DSI_PIXEL_FORMAT_18L BIT(1)
> +#define NWL_DSI_PIXEL_FORMAT_24 (BIT(0) | BIT(1))
> +
> +enum transfer_direction {
> + DSI_PACKET_SEND,
> + DSI_PACKET_RECEIVE,
> +};
> +
> +struct nwl_dsi_transfer {
> + const struct mipi_dsi_msg *msg;
> + struct mipi_dsi_packet packet;
> + struct completion completed;
> +
> + int status; /* status of transmission */
> + enum transfer_direction direction;
> + bool need_bta;
> + u8 cmd;
> + u16 rx_word_count;
> + size_t tx_len; /* in bytes */
> + size_t rx_len; /* in bytes */
> +};
> +
> +static int nwl_dsi_write(struct nwl_dsi *dsi, unsigned int reg, u32
> val)
> +{
> + int ret;
> +
> + ret = regmap_write(dsi->regmap, reg, val);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev,
> + "Failed to write NWL DSI reg 0x%x:
> %d\n", reg,
> + ret);
> + return ret;
> +}
> +
> +static u32 nwl_dsi_read(struct nwl_dsi *dsi, u32 reg)
> +{
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(dsi->regmap, reg, &val);
> + if (ret < 0)
> + DRM_DEV_ERROR(dsi->dev, "Failed to read NWL DSI reg
> 0x%x: %d\n",
> + reg, ret);
> +
> + return val;
> +}
> +
> +static u32 nwl_dsi_get_dpi_pixel_format(enum mipi_dsi_pixel_format
> format)
> +{
> + switch (format) {
> + case MIPI_DSI_FMT_RGB565:
> + return NWL_DSI_PIXEL_FORMAT_16;
> + case MIPI_DSI_FMT_RGB666:
> + return NWL_DSI_PIXEL_FORMAT_18L;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + return NWL_DSI_PIXEL_FORMAT_18;
> + case MIPI_DSI_FMT_RGB888:
> + return NWL_DSI_PIXEL_FORMAT_24;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +#define PSEC_PER_SEC 1000000000000LL
> +/*
> + * ps2bc - Picoseconds to byte clock cycles
> + */
> +static u32 ps2bc(struct nwl_dsi *dsi, unsigned long long ps)
> +{
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + return DIV_ROUND_UP(ps * dsi->mode.clock * 1000 * bpp,
> + dsi->lanes * 8 * PSEC_PER_SEC);
> +}
> +
> +/*
> + * ui2bc - UI time periods to byte clock cycles
> + */
> +static u32 ui2bc(struct nwl_dsi *dsi, unsigned long long ui)
> +{
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + return DIV_ROUND_UP(ui * dsi->lanes, dsi->mode.clock * 1000 *
> bpp);
> +}
> +
> +/*
> + * us2bc - micro seconds to lp clock cycles
> + */
> +static u32 us2lp(u32 lp_clk_rate, unsigned long us)
> +{
> + return DIV_ROUND_UP(us * lp_clk_rate, USEC_PER_SEC);
> +}
> +
> +static int nwl_dsi_config_host(struct nwl_dsi *dsi)
> +{
> + u32 cycles;
> + struct phy_configure_opts_mipi_dphy *cfg = &dsi-
> >phy_cfg.mipi_dphy;
> +
> + if (dsi->lanes < 1 || dsi->lanes > 4)
> + return -EINVAL;
> +
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "DSI Lanes %d\n", dsi->lanes);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NUM_LANES, dsi->lanes - 1);
> +
> + if (dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK,
> 0x01);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP,
> 0x01);
> + } else {
> + nwl_dsi_write(dsi, NWL_DSI_CFG_NONCONTINUOUS_CLK,
> 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_AUTOINSERT_EOTP,
> 0x00);
> + }
> +
> + /* values in byte clock cycles */
> + cycles = ui2bc(dsi, cfg->clk_pre);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_T_PRE, cycles);
> + cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg-
> >clk_zero);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x\n",
> cycles);
> + cycles += ui2bc(dsi, cfg->clk_pre);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_T_POST, cycles);
> + cycles = ps2bc(dsi, cfg->hs_exit);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x\n", cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_TX_GAP, cycles);
> +
> + nwl_dsi_write(dsi, NWL_DSI_CFG_EXTRA_CMDS_AFTER_EOTP, 0x01);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_HTX_TO_COUNT, 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_LRX_H_TO_COUNT, 0x00);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_BTA_H_TO_COUNT, 0x00);
> + /* In LP clock cycles */
> + cycles = us2lp(cfg->lp_clk_rate, cfg->wakeup);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_twakeup: 0x%x\n",
> cycles);
> + nwl_dsi_write(dsi, NWL_DSI_CFG_TWAKEUP, cycles);
> +
> + return 0;
> +}
> +
> +static int nwl_dsi_config_dpi(struct nwl_dsi *dsi)
> +{
> + u32 color_format, mode;
> + bool burst_mode;
> + int hfront_porch, hback_porch, vfront_porch, vback_porch;
> + int hsync_len, vsync_len;
> +
> + hfront_porch = dsi->mode.hsync_start - dsi->mode.hdisplay;
> + hsync_len = dsi->mode.hsync_end - dsi->mode.hsync_start;
> + hback_porch = dsi->mode.htotal - dsi->mode.hsync_end;
> +
> + vfront_porch = dsi->mode.vsync_start - dsi->mode.vdisplay;
> + vsync_len = dsi->mode.vsync_end - dsi->mode.vsync_start;
> + vback_porch = dsi->mode.vtotal - dsi->mode.vsync_end;
> +
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hfront_porch = %d\n",
> hfront_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hback_porch = %d\n",
> hback_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hsync_len = %d\n",
> hsync_len);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "hdisplay = %d\n", dsi-
> >mode.hdisplay);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vfront_porch = %d\n",
> vfront_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vback_porch = %d\n",
> vback_porch);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vsync_len = %d\n",
> vsync_len);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "vactive = %d\n", dsi-
> >mode.vdisplay);
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "clock = %d kHz\n", dsi-
> >mode.clock);
> +
> + color_format = nwl_dsi_get_dpi_pixel_format(dsi->format);
> + if (color_format < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Invalid color format
> 0x%x\n",
> + dsi->format);
> + return color_format;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "pixel fmt = %d\n", dsi-
> >format);
> +
> + nwl_dsi_write(dsi, NWL_DSI_INTERFACE_COLOR_CODING,
> NWL_DSI_DPI_24_BIT);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FORMAT, color_format);
> + /*
> + * Adjusting input polarity based on the video mode results
> in
> + * a black screen so always pick active low:
> + */
> + nwl_dsi_write(dsi, NWL_DSI_VSYNC_POLARITY,
> + NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW);
> + nwl_dsi_write(dsi, NWL_DSI_HSYNC_POLARITY,
> + NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW);
> +
> + burst_mode = (dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_BURST) &&
> + !(dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE);
> +
> + if (burst_mode) {
> + nwl_dsi_write(dsi, NWL_DSI_VIDEO_MODE,
> NWL_DSI_VM_BURST_MODE);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FIFO_SEND_LEVEL,
> 256);
> + } else {
> + mode = ((dsi->dsi_mode_flags &
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE) ?
> + NWL_DSI_VM_BURST_MODE_WITH_SYNC_PULSE
> S :
> + NWL_DSI_VM_NON_BURST_MODE_WITH_SYNC_E
> VENTS);
> + nwl_dsi_write(dsi, NWL_DSI_VIDEO_MODE, mode);
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_FIFO_SEND_LEVEL,
> + dsi->mode.hdisplay);
> + }
> +
> + nwl_dsi_write(dsi, NWL_DSI_HFP, hfront_porch);
> + nwl_dsi_write(dsi, NWL_DSI_HBP, hback_porch);
> + nwl_dsi_write(dsi, NWL_DSI_HSA, hsync_len);
> +
> + nwl_dsi_write(dsi, NWL_DSI_ENABLE_MULT_PKTS, 0x0);
> + nwl_dsi_write(dsi, NWL_DSI_BLLP_MODE, 0x1);
> + nwl_dsi_write(dsi, NWL_DSI_ENABLE_MULT_PKTS, 0x0);
NWL_DSI_ENABLE_MULT_PKTS is written twice, by mistake, so remove this
line. I did the same mistake on NXP tree, I think you got it from there
:)
> + nwl_dsi_write(dsi, NWL_DSI_USE_NULL_PKT_BLLP, 0x0);
> + nwl_dsi_write(dsi, NWL_DSI_VC, 0x0);
> +
> + nwl_dsi_write(dsi, NWL_DSI_PIXEL_PAYLOAD_SIZE, dsi-
> >mode.hdisplay);
> + nwl_dsi_write(dsi, NWL_DSI_VACTIVE, dsi->mode.vdisplay - 1);
VACTIVE shold contain the number of lines in the vertical area. "-1"
subtraction was actually wrong.
> + nwl_dsi_write(dsi, NWL_DSI_VBP, vback_porch);
> + nwl_dsi_write(dsi, NWL_DSI_VFP, vfront_porch);
> +
> + return 0;
> +}
> +
> +static void nwl_dsi_init_interrupts(struct nwl_dsi *dsi)
> +{
> + u32 irq_enable;
> +
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, 0xffffffff);
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK2, 0x7);
> +
> + irq_enable = ~(u32)(NWL_DSI_TX_PKT_DONE_MASK |
> + NWL_DSI_RX_PKT_HDR_RCVD_MASK |
> + NWL_DSI_TX_FIFO_OVFLW_MASK |
> + NWL_DSI_HS_TX_TIMEOUT_MASK);
> +
> + nwl_dsi_write(dsi, NWL_DSI_IRQ_MASK, irq_enable);
> +}
> +
> +static int nwl_dsi_host_attach(struct mipi_dsi_host *dsi_host,
> + struct mipi_dsi_device *device)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> + struct device *dev = dsi->dev;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> + int ret;
> +
> + DRM_DEV_INFO(dev, "lanes=%u, format=0x%x flags=0x%lx\n",
> device->lanes,
> + device->format, device->mode_flags);
> +
> + if (device->lanes < 1 || device->lanes > 4)
> + return -EINVAL;
> +
> + dsi->lanes = device->lanes;
> + dsi->format = device->format;
> + dsi->dsi_mode_flags = device->mode_flags;
> +
> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
> &panel,
> + &bridge);
> + if (ret)
> + return ret;
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add(panel,
> DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
> + }
> +
> + dsi->panel_bridge = bridge;
> + drm_bridge_add(&dsi->bridge);
> +
> + return 0;
> +}
> +
> +static int nwl_dsi_host_detach(struct mipi_dsi_host *dsi_host,
> + struct mipi_dsi_device *device)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> +
> + drm_of_panel_bridge_remove(dsi->dev->of_node, 1, 0);
> + drm_bridge_remove(&dsi->bridge);
> +
> + return 0;
> +}
> +
> +static bool nwl_dsi_read_packet(struct nwl_dsi *dsi, u32 status)
> +{
> + struct device *dev = dsi->dev;
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + u8 *payload = xfer->msg->rx_buf;
> + u32 val;
> + u16 word_count;
> + u8 channel;
> + u8 data_type;
> +
> + xfer->status = 0;
> +
> + if (xfer->rx_word_count == 0) {
> + if (!(status & NWL_DSI_RX_PKT_HDR_RCVD))
> + return false;
> + /* Get the RX header and parse it */
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PKT_HEADER);
> + word_count = NWL_DSI_WC(val);
> + channel = NWL_DSI_RX_VC(val);
> + data_type = NWL_DSI_RX_DT(val);
> +
> + if (channel != xfer->msg->channel) {
> + DRM_DEV_ERROR(dev,
> + "[%02X] Channel mismatch (%u !=
> %u)\n",
> + xfer->cmd, channel, xfer->msg-
> >channel);
> + return true;
> + }
> +
> + switch (data_type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + /* Fall through */
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + if (xfer->msg->rx_len > 1) {
> + /* read second byte */
> + payload[1] = word_count >> 8;
> + ++xfer->rx_len;
> + }
> + /* Fall through */
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + /* Fall through */
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + if (xfer->msg->rx_len > 0) {
> + /* read first byte */
> + payload[0] = word_count & 0xff;
> + ++xfer->rx_len;
> + }
> + xfer->status = xfer->rx_len;
> + return true;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + word_count &= 0xff;
> + DRM_DEV_ERROR(dev, "[%02X] DSI error report:
> 0x%02x\n",
> + xfer->cmd, word_count);
> + xfer->status = -EPROTO;
> + return true;
> + }
> +
> + if (word_count > xfer->msg->rx_len) {
> + DRM_DEV_ERROR(
> + dev,
> + "[%02X] Receive buffer too small: %lu
> (< %u)\n",
> + xfer->cmd, xfer->msg->rx_len,
> word_count);
> + return true;
> + }
> +
> + xfer->rx_word_count = word_count;
> + } else {
> + /* Set word_count from previous header read */
> + word_count = xfer->rx_word_count;
> + }
> +
> + /* If RX payload is not yet received, wait for it */
> + if (!(status & NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD))
> + return false;
> +
> + /* Read the RX payload */
> + while (word_count >= 4) {
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PAYLOAD);
> + payload[0] = (val >> 0) & 0xff;
> + payload[1] = (val >> 8) & 0xff;
> + payload[2] = (val >> 16) & 0xff;
> + payload[3] = (val >> 24) & 0xff;
> + payload += 4;
> + xfer->rx_len += 4;
> + word_count -= 4;
> + }
> +
> + if (word_count > 0) {
> + val = nwl_dsi_read(dsi, NWL_DSI_RX_PAYLOAD);
> + switch (word_count) {
> + case 3:
> + payload[2] = (val >> 16) & 0xff;
> + ++xfer->rx_len;
> + /* Fall through */
> + case 2:
> + payload[1] = (val >> 8) & 0xff;
> + ++xfer->rx_len;
> + /* Fall through */
> + case 1:
> + payload[0] = (val >> 0) & 0xff;
> + ++xfer->rx_len;
> + break;
> + }
> + }
> +
> + xfer->status = xfer->rx_len;
> +
> + return true;
> +}
> +
> +static void nwl_dsi_finish_transmission(struct nwl_dsi *dsi, u32
> status)
> +{
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + bool end_packet = false;
> +
> + if (!xfer)
> + return;
> +
> + if (status & NWL_DSI_TX_FIFO_OVFLW) {
> + DRM_DEV_ERROR_RATELIMITED(dsi->dev, "tx fifo
> overflow\n");
> + return;
> + }
> +
> + if (status & NWL_DSI_HS_TX_TIMEOUT) {
> + DRM_DEV_ERROR_RATELIMITED(dsi->dev, "HS tx
> timeout\n");
> + return;
> + }
> +
> + if (xfer->direction == DSI_PACKET_SEND &&
> + status & NWL_DSI_TX_PKT_DONE) {
> + xfer->status = xfer->tx_len;
> + end_packet = true;
> + } else if (status & NWL_DSI_DPHY_DIRECTION &&
> + ((status & (NWL_DSI_RX_PKT_HDR_RCVD |
> + NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD)))) {
> + end_packet = nwl_dsi_read_packet(dsi, status);
> + }
> +
> + if (end_packet)
> + complete(&xfer->completed);
> +}
> +
> +static void nwl_dsi_begin_transmission(struct nwl_dsi *dsi)
> +{
> + struct nwl_dsi_transfer *xfer = dsi->xfer;
> + struct mipi_dsi_packet *pkt = &xfer->packet;
> + const u8 *payload;
> + size_t length;
> + u16 word_count;
> + u8 hs_mode;
> + u32 val;
> + u32 hs_workaround = 0;
> +
> + /* Send the payload, if any */
> + length = pkt->payload_length;
> + payload = pkt->payload;
> +
> + while (length >= 4) {
> + val = *(u32 *)payload;
> + hs_workaround |= !(val & 0xFFFF00);
> + nwl_dsi_write(dsi, NWL_DSI_TX_PAYLOAD, val);
> + payload += 4;
> + length -= 4;
> + }
> + /* Send the rest of the payload */
> + val = 0;
> + switch (length) {
> + case 3:
> + val |= payload[2] << 16;
> + /* Fall through */
> + case 2:
> + val |= payload[1] << 8;
> + hs_workaround |= !(val & 0xFFFF00);
> + /* Fall through */
> + case 1:
> + val |= payload[0];
> + nwl_dsi_write(dsi, NWL_DSI_TX_PAYLOAD, val);
> + break;
> + }
> + xfer->tx_len = pkt->payload_length;
> +
> + /*
> + * Send the header
> + * header[0] = Virtual Channel + Data Type
> + * header[1] = Word Count LSB (LP) or first param (SP)
> + * header[2] = Word Count MSB (LP) or second param (SP)
> + */
> + word_count = pkt->header[1] | (pkt->header[2] << 8);
> + if (hs_workaround && (dsi->quirks & E11418_HS_MODE_QUIRK)) {
> + DRM_DEV_DEBUG_DRIVER(dsi->dev,
> + "Using hs mode workaround for
> cmd 0x%x\n",
> + xfer->cmd);
> + hs_mode = 1;
> + } else {
> + hs_mode = (xfer->msg->flags & MIPI_DSI_MSG_USE_LPM) ?
> 0 : 1;
> + }
> + val = NWL_DSI_WC(word_count) | NWL_DSI_TX_VC(xfer->msg-
> >channel) |
> + NWL_DSI_TX_DT(xfer->msg->type) |
> NWL_DSI_HS_SEL(hs_mode) |
> + NWL_DSI_BTA_TX(xfer->need_bta);
> + nwl_dsi_write(dsi, NWL_DSI_PKT_CONTROL, val);
> +
> + /* Send packet command */
> + nwl_dsi_write(dsi, NWL_DSI_SEND_PACKET, 0x1);
> +}
> +
> +static ssize_t nwl_dsi_host_transfer(struct mipi_dsi_host *dsi_host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct nwl_dsi *dsi = container_of(dsi_host, struct nwl_dsi,
> dsi_host);
> + struct nwl_dsi_transfer xfer;
> + ssize_t ret = 0;
> +
> + /* Create packet to be sent */
> + dsi->xfer = &xfer;
> + ret = mipi_dsi_create_packet(&xfer.packet, msg);
> + if (ret < 0) {
> + dsi->xfer = NULL;
> + return ret;
> + }
> +
> + if ((msg->type & MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM ||
> + msg->type & MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM ||
> + msg->type & MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM ||
> + msg->type & MIPI_DSI_DCS_READ) &&
> + msg->rx_len > 0 && msg->rx_buf != NULL)
> + xfer.direction = DSI_PACKET_RECEIVE;
> + else
> + xfer.direction = DSI_PACKET_SEND;
> +
> + xfer.need_bta = (xfer.direction == DSI_PACKET_RECEIVE);
> + xfer.need_bta |= (msg->flags & MIPI_DSI_MSG_REQ_ACK) ? 1 : 0;
> + xfer.msg = msg;
> + xfer.status = -ETIMEDOUT;
> + xfer.rx_word_count = 0;
> + xfer.rx_len = 0;
> + xfer.cmd = 0x00;
> + if (msg->tx_len > 0)
> + xfer.cmd = ((u8 *)(msg->tx_buf))[0];
> + init_completion(&xfer.completed);
> +
> + ret = clk_prepare_enable(dsi->rx_esc_clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable rx_esc clk:
> %zd\n",
> + ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Enabled rx_esc clk @%lu
> Hz\n",
> + clk_get_rate(dsi->rx_esc_clk));
This will be printed every time a DSI command is sent, of course, when
debugging only, but still: are you sure you need this info?
> +
> + /* Initiate the DSI packet transmision */
> + nwl_dsi_begin_transmission(dsi);
> +
> + if (!wait_for_completion_timeout(&xfer.completed,
> + NWL_DSI_MIPI_FIFO_TIMEOUT))
> {
> + DRM_DEV_ERROR(dsi_host->dev, "[%02X] DSI transfer
> timed out\n",
> + xfer.cmd);
> + ret = -ETIMEDOUT;
> + } else {
> + ret = xfer.status;
> + }
> +
> + clk_disable_unprepare(dsi->rx_esc_clk);
> +
> + return ret;
> +}
> +
> +const struct mipi_dsi_host_ops nwl_dsi_host_ops = {
> + .attach = nwl_dsi_host_attach,
> + .detach = nwl_dsi_host_detach,
> + .transfer = nwl_dsi_host_transfer,
> +};
> +
> +irqreturn_t nwl_dsi_irq_handler(int irq, void *data)
> +{
> + u32 irq_status;
> + struct nwl_dsi *dsi = data;
> +
> + irq_status = nwl_dsi_read(dsi, NWL_DSI_IRQ_STATUS);
> +
> + if (irq_status & NWL_DSI_TX_PKT_DONE ||
> + irq_status & NWL_DSI_RX_PKT_HDR_RCVD ||
> + irq_status & NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD)
> + nwl_dsi_finish_transmission(dsi, irq_status);
> +
> + return IRQ_HANDLED;
> +}
> +
> +int nwl_dsi_enable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> + union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
> + int ret;
> +
> + if (!dsi->lanes) {
> + DRM_DEV_ERROR(dev, "Need DSI lanes: %d\n", dsi-
> >lanes);
> + return -EINVAL;
> + }
> +
> + ret = phy_init(dsi->phy);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to init DSI phy: %d\n",
> ret);
> + return ret;
> + }
> +
> + ret = phy_configure(dsi->phy, phy_cfg);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to configure DSI phy:
> %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dsi->tx_esc_clk);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dsi->dev, "Failed to enable tx_esc clk:
> %d\n",
> + ret);
> + return ret;
> + }
> + DRM_DEV_DEBUG_DRIVER(dsi->dev, "Enabled tx_esc clk @%lu
> Hz\n",
> + clk_get_rate(dsi->tx_esc_clk));
> +
> + ret = nwl_dsi_config_host(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set up DSI: %d", ret);
> + return ret;
> + }
> +
> + ret = nwl_dsi_config_dpi(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set up DPI: %d", ret);
> + return ret;
> + }
> +
> + ret = phy_power_on(dsi->phy);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to power on DPHY (%d)\n",
> ret);
> + return ret;
> + }
> +
> + nwl_dsi_init_interrupts(dsi);
> +
> + return 0;
> +}
I see that you do all the initialization from the pre_enable stage. If
you power on the DPHY, the DSI host block will start transmitting pixel
data on the data lanes. We had some customers that complained about
this, so I think is better to hold on the pixel flow until the whole
pixel pipe is completely initialized.
What I recommend here, is to also use the enable stage in the bridge
and move nwl_dsi_config_host in there. Thus, the call flow will be:
1. bridge->pre_enable (DSI is configured, but not streaming since the
host is not yet configured)
2. panel->prepare (panel will use the DSI APB block to send DSI
commands)
3. bridge->enable (DSI host block is configured, DSI starts streamming
pixels)
3. panel->enable (panel is ready to display the pixel flow)
> +
> +int nwl_dsi_disable(struct nwl_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "Disabling clocks and phy\n");
> +
> + phy_power_off(dsi->phy);
> + phy_exit(dsi->phy);
> +
> + /* Disabling the clock before the phy breaks enabling dsi
> again */
> + clk_disable_unprepare(dsi->tx_esc_clk);
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> new file mode 100644
> index 000000000000..579b366de652
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> @@ -0,0 +1,112 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +#ifndef __NWL_DSI_H__
> +#define __NWL_DSI_H__
> +
> +#include <linux/irqreturn.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +
> +#include "nwl-drv.h"
> +
> +/* DSI HOST registers */
> +#define NWL_DSI_CFG_NUM_LANES 0x0
> +#define NWL_DSI_CFG_NONCONTINUOUS_CLK 0x4
> +#define NWL_DSI_CFG_T_PRE 0x8
> +#define NWL_DSI_CFG_T_POST 0xc
> +#define NWL_DSI_CFG_TX_GAP 0x10
> +#define NWL_DSI_CFG_AUTOINSERT_EOTP 0x14
> +#define NWL_DSI_CFG_EXTRA_CMDS_AFTER_EOTP 0x18
> +#define NWL_DSI_CFG_HTX_TO_COUNT 0x1c
> +#define NWL_DSI_CFG_LRX_H_TO_COUNT 0x20
> +#define NWL_DSI_CFG_BTA_H_TO_COUNT 0x24
> +#define NWL_DSI_CFG_TWAKEUP 0x28
> +#define NWL_DSI_CFG_STATUS_OUT 0x2c
> +#define NWL_DSI_RX_ERROR_STATUS 0x30
> +
> +/* DSI DPI registers */
> +#define NWL_DSI_PIXEL_PAYLOAD_SIZE 0x200
> +#define NWL_DSI_PIXEL_FIFO_SEND_LEVEL 0x204
> +#define NWL_DSI_INTERFACE_COLOR_CODING 0x208
> +#define NWL_DSI_PIXEL_FORMAT 0x20c
> +#define NWL_DSI_VSYNC_POLARITY 0x210
> +#define NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW 0
> +#define NWL_DSI_VSYNC_POLARITY_ACTIVE_HIGH BIT(1)
> +
> +#define NWL_DSI_HSYNC_POLARITY 0x214
> +#define NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW 0
> +#define NWL_DSI_HSYNC_POLARITY_ACTIVE_HIGH BIT(1)
> +
> +#define NWL_DSI_VIDEO_MODE 0x218
> +#define NWL_DSI_HFP 0x21c
> +#define NWL_DSI_HBP 0x220
> +#define NWL_DSI_HSA 0x224
> +#define NWL_DSI_ENABLE_MULT_PKTS 0x228
> +#define NWL_DSI_VBP 0x22c
> +#define NWL_DSI_VFP 0x230
> +#define NWL_DSI_BLLP_MODE 0x234
> +#define NWL_DSI_USE_NULL_PKT_BLLP 0x238
> +#define NWL_DSI_VACTIVE 0x23c
> +#define NWL_DSI_VC 0x240
> +
> +/* DSI APB PKT control */
> +#define NWL_DSI_TX_PAYLOAD 0x280
> +#define NWL_DSI_PKT_CONTROL 0x284
> +#define NWL_DSI_SEND_PACKET 0x288
> +#define NWL_DSI_PKT_STATUS 0x28c
> +#define NWL_DSI_PKT_FIFO_WR_LEVEL 0x290
> +#define NWL_DSI_PKT_FIFO_RD_LEVEL 0x294
> +#define NWL_DSI_RX_PAYLOAD 0x298
> +#define NWL_DSI_RX_PKT_HEADER 0x29c
> +
> +/* DSI IRQ handling */
> +#define NWL_DSI_IRQ_STATUS 0x2a0
> +#define NWL_DSI_SM_NOT_IDLE BIT(0)
> +#define NWL_DSI_TX_PKT_DONE BIT(1)
> +#define NWL_DSI_DPHY_DIRECTION BIT(2)
> +#define NWL_DSI_TX_FIFO_OVFLW BIT(3)
> +#define NWL_DSI_TX_FIFO_UDFLW BIT(4)
> +#define NWL_DSI_RX_FIFO_OVFLW BIT(5)
> +#define NWL_DSI_RX_FIFO_UDFLW BIT(6)
> +#define NWL_DSI_RX_PKT_HDR_RCVD BIT(7)
> +#define NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD BIT(8)
> +#define NWL_DSI_BTA_TIMEOUT BIT(29)
> +#define NWL_DSI_LP_RX_TIMEOUT BIT(30)
> +#define NWL_DSI_HS_TX_TIMEOUT BIT(31)
> +
> +#define NWL_DSI_IRQ_STATUS2 0x2a4
> +#define NWL_DSI_SINGLE_BIT_ECC_ERR BIT(0)
> +#define NWL_DSI_MULTI_BIT_ECC_ERR BIT(1)
> +#define NWL_DSI_CRC_ERR BIT(2)
> +
> +#define NWL_DSI_IRQ_MASK 0x2a8
> +#define NWL_DSI_SM_NOT_IDLE_MASK BIT(0)
> +#define NWL_DSI_TX_PKT_DONE_MASK BIT(1)
> +#define NWL_DSI_DPHY_DIRECTION_MASK BIT(2)
> +#define NWL_DSI_TX_FIFO_OVFLW_MASK BIT(3)
> +#define NWL_DSI_TX_FIFO_UDFLW_MASK BIT(4)
> +#define NWL_DSI_RX_FIFO_OVFLW_MASK BIT(5)
> +#define NWL_DSI_RX_FIFO_UDFLW_MASK BIT(6)
> +#define NWL_DSI_RX_PKT_HDR_RCVD_MASK BIT(7)
> +#define NWL_DSI_RX_PKT_PAYLOAD_DATA_RCVD_MASK BIT(8)
> +#define NWL_DSI_BTA_TIMEOUT_MASK BIT(29)
> +#define NWL_DSI_LP_RX_TIMEOUT_MASK BIT(30)
> +#define NWL_DSI_HS_TX_TIMEOUT_MASK BIT(31)
> +
> +#define NWL_DSI_IRQ_MASK2 0x2ac
> +#define NWL_DSI_SINGLE_BIT_ECC_ERR_MASK BIT(0)
> +#define NWL_DSI_MULTI_BIT_ECC_ERR_MASK BIT(1)
> +#define NWL_DSI_CRC_ERR_MASK BIT(2)
> +
> +extern const struct mipi_dsi_host_ops nwl_dsi_host_ops;
> +
> +irqreturn_t nwl_dsi_irq_handler(int irq, void *data);
> +int nwl_dsi_enable(struct nwl_dsi *dsi);
> +int nwl_dsi_disable(struct nwl_dsi *dsi);
> +
> +#endif /* __NWL_DSI_H__ */
> --
> 2.20.1
>
>
Best regards,
Robert
_______________________________________________
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 v6 3/4] dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles
From: Rob Herring @ 2019-08-22 12:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190821175458.GA25168@kozik-lap>
On Wed, Aug 21, 2019 at 12:55 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Aug 20, 2019 at 03:27:39PM -0500, Rob Herring wrote:
> > > I see. If I understand the schema correctly, this should look like:
> >
> > Looks correct, but a couple of comments.
> >
> > > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > index 7294ac36f4c0..eb263d1ccf13 100644
> > > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > > @@ -161,6 +161,22 @@ properties:
> > > items:
> > > - enum:
> > > - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
> > > + - kontron,imx6ul-n6310-som # Kontron N6310 SOM
> >
> > Is the SOM ever used alone? If not, then no point in listing this here.
>
> SoM alone: no, because it requires some type of base board. However it
> will be used by some customer designs with some amount of
> changes/addons.
>
> Looking at other aproaches, usually SoMs have their own compatible. In
> such case - I should document it somewhere.
I wasn't suggesting not having the compatible for it, but you don't
need it in this list because that is not valid. You have to list it
with the base board compatibles.
Rob
_______________________________________________
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,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Jungo Lin @ 2019-08-22 12:48 UTC (permalink / raw)
To: Rob Herring
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190821201758.GB15270@bogus>
Hi, Rob:
On Wed, 2019-08-21 at 15:17 -0500, Rob Herring wrote:
> On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> > This patch adds DT binding document for the Pass 1 (P1) unit
> > in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> > data out from the sensor interface, applies ISP image effects
> > from tuning data and outputs the image data or statistics data to DRAM.
> >
> > Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> > ---
> > .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> > 1 file changed, 73 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > new file mode 100644
> > index 000000000000..fa2713acceca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > @@ -0,0 +1,73 @@
> > +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> > +
> > +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> > +from the sensor interface, applies ISP effects from tuning data and outputs
> > +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> > +the ability to output two different resolutions frames at the same time to
> > +increase the performance of the camera application.
> > +
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> > +- reg: Physical base address of the camera function block register and
> > + length of memory mapped region. Must contain an entry for each entry
> > + in reg-names.
> > +- reg-names: Must include the following entries:
> > + "cam_sys": Camera base function block
> > + "cam_uni": Camera UNI function block
> > + "cam_a": Camera ISP P1 hardware unit A
> > + "cam_b": Camera ISP P1 hardware unit B
> > + "cam_c": Camera ISP P1 hardware unit C
> > +- interrupts: Must contain an entry for each entry in interrupt-names.
> > +- interrupt-names : Must include the following entries:
> > + "cam_uni": Camera UNI interrupt
> > + "cam_a": Camera unit A interrupt
> > + "cam_b": Camera unit B interrupt
> > + "cam_c": Camera unit C interrupt
> > +- iommus: Shall point to the respective IOMMU block with master port
> > + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +- clocks: A list of phandle and clock specifier pairs as listed
> > + in clock-names property, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> > +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> > + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,scp : The node of system control processor (SCP), see
> > + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> > +
> > +Example:
> > +SoC specific DT entry:
> > +
> > + camisp: camisp@1a000000 {
>
> Also, you can remove 2 levels of indentation here.
>
Ok, got it.
We will change to use one level of indentation.
Thanks,
Jungo
> > + compatible = "mediatek,mt8183-camisp", "syscon";
> > + reg = <0 0x1a000000 0 0x1000>,
> > + <0 0x1a003000 0 0x1000>,
> > + <0 0x1a004000 0 0x2000>,
> > + <0 0x1a006000 0 0x2000>,
> > + <0 0x1a008000 0 0x2000>;
> > + reg-names = "cam_sys",
> > + "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> > + clocks = <&camsys CLK_CAM_CAM>,
> > + <&camsys CLK_CAM_CAMTG>;
> > + clock-names = "camsys_cam_cgpdn",
> > + "camsys_camtg_cgpdn";
> > + mediatek,larb = <&larb3>,
> > + <&larb6>;
> > + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> > + mediatek,scp = <&scp>;
> > + };
> > --
> > 2.18.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC,v4,1/4] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Jungo Lin @ 2019-08-22 12:47 UTC (permalink / raw)
To: Rob Herring
Cc: ryan.yu, frankie.chiu, laurent.pinchart, Rynn.Wu, suleiman,
Jerry-ch.Chen, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190821194752.GA15270@bogus>
Hi, Rob:
On Wed, 2019-08-21 at 14:47 -0500, Rob Herring wrote:
> On Wed, Aug 07, 2019 at 08:48:00PM +0800, Jungo Lin wrote:
> > This patch adds DT binding document for the Pass 1 (P1) unit
> > in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> > data out from the sensor interface, applies ISP image effects
> > from tuning data and outputs the image data or statistics data to DRAM.
> >
> > Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> > ---
> > .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> > 1 file changed, 73 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,camisp.txt b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > new file mode 100644
> > index 000000000000..fa2713acceca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,camisp.txt
> > @@ -0,0 +1,73 @@
> > +* Mediatek Image Signal Processor Pass 1 (ISP P1)
> > +
> > +The Pass 1 unit of Mediatek's camera ISP system grabs the sensor data out
> > +from the sensor interface, applies ISP effects from tuning data and outputs
> > +the image data and statistics data to DRAM. Furthermore, Pass 1 unit has
> > +the ability to output two different resolutions frames at the same time to
> > +increase the performance of the camera application.
> > +
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8183-camisp" for MT8183.
> > +- reg: Physical base address of the camera function block register and
> > + length of memory mapped region. Must contain an entry for each entry
> > + in reg-names.
> > +- reg-names: Must include the following entries:
> > + "cam_sys": Camera base function block
> > + "cam_uni": Camera UNI function block
> > + "cam_a": Camera ISP P1 hardware unit A
> > + "cam_b": Camera ISP P1 hardware unit B
> > + "cam_c": Camera ISP P1 hardware unit C
> > +- interrupts: Must contain an entry for each entry in interrupt-names.
> > +- interrupt-names : Must include the following entries:
> > + "cam_uni": Camera UNI interrupt
> > + "cam_a": Camera unit A interrupt
> > + "cam_b": Camera unit B interrupt
> > + "cam_c": Camera unit C interrupt
> > +- iommus: Shall point to the respective IOMMU block with master port
> > + as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +- clocks: A list of phandle and clock specifier pairs as listed
> > + in clock-names property, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: Must be "camsys_cam_cgpdn" and "camsys_camtg_cgpdn".
> > +- mediatek,larb: Must contain the local arbiters in the current SoCs, see
> > + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,scp : The node of system control processor (SCP), see
> > + Documentation/devicetree/bindings/remoteproc/mtk,scp.txt for details.
> > +
> > +Example:
> > +SoC specific DT entry:
> > +
> > + camisp: camisp@1a000000 {
> > + compatible = "mediatek,mt8183-camisp", "syscon";
>
> syscon doesn't seem appropriate nor is it documented.
>
Thanks for your comment.
I will remove "syscon" in next patch.
Best regards,
Jungo
> > + reg = <0 0x1a000000 0 0x1000>,
> > + <0 0x1a003000 0 0x1000>,
> > + <0 0x1a004000 0 0x2000>,
> > + <0 0x1a006000 0 0x2000>,
> > + <0 0x1a008000 0 0x2000>;
> > + reg-names = "cam_sys",
> > + "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + interrupts = <GIC_SPI 253 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 254 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 255 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 256 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-names = "cam_uni",
> > + "cam_a",
> > + "cam_b",
> > + "cam_c";
> > + iommus = <&iommu M4U_PORT_CAM_IMGO>;
> > + clocks = <&camsys CLK_CAM_CAM>,
> > + <&camsys CLK_CAM_CAMTG>;
> > + clock-names = "camsys_cam_cgpdn",
> > + "camsys_camtg_cgpdn";
> > + mediatek,larb = <&larb3>,
> > + <&larb6>;
> > + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> > + mediatek,scp = <&scp>;
> > + };
> > --
> > 2.18.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Alexandre Belloni @ 2019-08-22 12:46 UTC (permalink / raw)
To: Ran Bi
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <1566477254.12318.41.camel@mhfsdcap03>
On 22/08/2019 20:34:14+0800, Ran Bi wrote:
> > > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
> >
> > This should be written when setting the time after power was lost.
> >
>
> I suppose we can move this into mt2712_rtc_read_time function's "if
> (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
> which will be added at next patch. We need additional flag to mark this
> condition or another if condition in mt2712_rtc_set_time fucntion if we
> put these code in mt2712_rtc_set_time function.
>
It is fine to test both in read_time and in set_time.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/19] dt-bindings: arm: mrvl: Document MMP3 compatible string
From: Rob Herring @ 2019-08-22 12:42 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
Marc Zyngier, Michael Turquette, Russell King,
Kishon Vijay Abraham I,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Olof Johansson, Thomas Gleixner, linux-clk,
linux-kernel@vger.kernel.org
In-Reply-To: <c859d12167d18c21dda13b30c2dd3256f407d1d9.camel@v3.sk>
On Thu, Aug 22, 2019 at 3:12 AM Lubomir Rintel <lkundrak@v3.sk> wrote:
>
> On Wed, 2019-08-21 at 16:03 -0500, Rob Herring wrote:
> > On Fri, Aug 09, 2019 at 11:31:41AM +0200, Lubomir Rintel wrote:
> > > Marvel MMP3 is a successor to MMP2, containing similar peripherals with two
> > > PJ4B cores.
> > >
> > > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> > > ---
> > > Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > index 951687528efb0..66e1e1414245b 100644
> > > --- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
> > > @@ -12,3 +12,7 @@ Required root node properties:
> > > MMP2 Brownstone Board
> > > Required root node properties:
> > > - compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
> > > +
> > > +MMP3 SoC
> > > +Required root node properties:
> > > + - compatible = "marvell,mmp3";
> >
> > Please convert this file to DT schema before adding new SoCs.
>
> Is this something that should generally be done for all new or changed
> DT bindings?
Preferred, but not quite yet required everywhere. It depends on the
maintainer/subsystem still. But for board level bindings, you'll
notice most of them are converted. Marvell, Broadcom, and TI are the
main ones left.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: mt8183: add I2C nodes
From: qii.wang @ 2019-08-22 12:35 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, qii.wang, matthias.bgg, linux-arm-kernel
From: Qii Wang <qii.wang@mediatek.com>
Add i2c nodes to mt8183 and mt8183-evb.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 96 ++++++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 189 ++++++++++++++++++++++++++++
2 files changed, 285 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index d8e555c..1fb195c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -30,7 +30,103 @@
status = "okay";
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_0>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_1>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_2>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_3>;
+ status = "okay";
+ clock-frequency = <100000>;
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_4>;
+ status = "okay";
+ clock-frequency = <1000000>;
+};
+
+&i2c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c_pins_5>;
+ status = "okay";
+ clock-frequency = <1000000>;
+};
+
&pio {
+ i2c_pins_0: i2c0{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO82__FUNC_SDA0>,
+ <PINMUX_GPIO83__FUNC_SCL0>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_1: i2c1{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO81__FUNC_SDA1>,
+ <PINMUX_GPIO84__FUNC_SCL1>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_2: i2c2{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO103__FUNC_SCL2>,
+ <PINMUX_GPIO104__FUNC_SDA2>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_3: i2c3{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO50__FUNC_SCL3>,
+ <PINMUX_GPIO51__FUNC_SDA3>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_4: i2c4{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO105__FUNC_SCL4>,
+ <PINMUX_GPIO106__FUNC_SDA4>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
+ i2c_pins_5: i2c5{
+ pins_i2c{
+ pinmux = <PINMUX_GPIO48__FUNC_SCL5>,
+ <PINMUX_GPIO49__FUNC_SDA5>;
+ mediatek,pull-up-adv = <3>;
+ mediatek,drive-strength-adv = <00>;
+ };
+ };
+
spi_pins_0: spi0{
pins_spi{
pinmux = <PINMUX_GPIO85__FUNC_SPI0_MI>,
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c2749c4..ab71291 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -16,6 +16,21 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -294,6 +309,64 @@
status = "disabled";
};
+ i2c6: i2c@11005000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11005000 0 0x1000>,
+ <0 0x11000600 0 0x80>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C6>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@11007000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11007000 0 0x1000>,
+ <0 0x11000080 0 0x80>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C0>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@11008000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11008000 0 0x1000>,
+ <0 0x11000100 0 0x80>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C1>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C1_ARBITER>;
+ clock-names = "main", "dma","arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@11009000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11009000 0 0x1000>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C2>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C2_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi0: spi@1100a000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -307,6 +380,20 @@
status = "disabled";
};
+ i2c3: i2c@1100f000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1100f000 0 0x1000>,
+ <0 0x11000400 0 0x80>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C3>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi1: spi@11010000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -320,6 +407,20 @@
status = "disabled";
};
+ i2c1: i2c@11011000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11011000 0 0x1000>,
+ <0 0x11000480 0 0x80>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C4>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi2: spi@11012000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -346,6 +447,66 @@
status = "disabled";
};
+ i2c9: i2c@11014000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11014000 0 0x1000>,
+ <0 0x11000180 0 0x80>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C1_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C1_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c10: i2c@11015000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11015000 0 0x1000>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C2_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C2_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@11016000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11016000 0 0x1000>,
+ <0 0x11000500 0 0x80>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C5>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C5_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c@11017000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x11017000 0 0x1000>,
+ <0 0x11000580 0 0x80>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C5_IMM>,
+ <&infracfg CLK_INFRA_AP_DMA>,
+ <&infracfg CLK_INFRA_I2C5_ARBITER>;
+ clock-names = "main", "dma", "arb";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
spi4: spi@11018000 {
compatible = "mediatek,mt8183-spi";
#address-cells = <1>;
@@ -372,6 +533,34 @@
status = "disabled";
};
+ i2c7: i2c@1101a000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1101a000 0 0x1000>,
+ <0 0x11000680 0 0x80>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C7>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c8: i2c@1101b000 {
+ compatible = "mediatek,mt8183-i2c";
+ reg = <0 0x1101b000 0 0x1000>,
+ <0 0x11000700 0 0x80>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_I2C8>,
+ <&infracfg CLK_INFRA_AP_DMA>;
+ clock-names = "main", "dma";
+ clock-div = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
audiosys: syscon@11220000 {
compatible = "mediatek,mt8183-audiosys", "syscon";
reg = <0 0x11220000 0 0x1000>;
--
1.9.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 v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-22 12:34 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, YT Shen, Flora Fu, srv_heupstream,
devicetree, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Yingjoe Chen, Eddie Huang,
David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190820201744.GZ3545@piout.net>
Hi,
> > +
> > +#define MTK_RTC_DEV KBUILD_MODNAME
>
> You probably shouldn't do that and have a static string for the driver
> name. I probably doesn't matter much though because DT is used to probe
> the driver.
>
Will change it at next patch.
> > +/* we map HW YEAR 0 to 2000 because 2000 is the leap year */
> > +#define MT2712_MIN_YEAR 2000
> > +#define MT2712_BASE_YEAR 1900
> > +#define MT2712_MIN_YEAR_OFFSET (MT2712_MIN_YEAR - MT2712_BASE_YEAR)
> > +#define MT2712_MAX_YEAR_OFFSET (MT2712_MIN_YEAR_OFFSET + 127)
> > +
>
> All those defines are unecessary, see below.
>
Will change it at next patch.
> > +struct mt2712_rtc {
> > + struct device *dev;
>
> Looking at the code closely, it seems this is only used for debug and
> error messages. Maybe you could use rtc_dev->dev instead.
>
Will change it at next patch.
> > + mutex_lock(&rtc->rtc_dev->ops_lock);
> > +
> > + irqsta = mt2712_readl(rtc, MT2712_IRQ_STA);
>
> Do you have to lock that read? Is the register cleared on read?
>
Yes, this register is read clear register.
> > + do {
> > + __mt2712_rtc_read_time(rtc, tm, &sec);
> > + } while (sec < tm->tm_sec); /* SEC has carried */
>
> Shouldn't that be while (tm->tm_sec < sec)?
>
In __mt2712_rtc_read_time function, we read tm->tm_sec before read sec.
Sometimes we can meet situation like "tm->tm_sec == 59" and "sec == 0".
It means that TC_SEC has carried and we need to reload the tm struct. I
suppose it was correct that using "while (sec < tm->tm_sec)"
> > +
> > + /* HW register use 7 bits to store year data, minus
> > + * MT2712_MIN_YEAR_OFFSET brfore write year data to register, and plus
> > + * MT2712_MIN_YEAR_OFFSET back after read year from register
> > + */
> > + tm->tm_year += MT2712_MIN_YEAR_OFFSET;
>
> Simply add 100 in __mt2712_rtc_read_time
>
Will change it at next patch.
> > +
> > + /* HW register start mon from one, but tm_mon start from zero. */
> > + tm->tm_mon--;
> > +
>
> You can also do that in __mt2712_rtc_read_time.
>
Will change it at next patch.
> > + if (rtc_valid_tm(tm)) {
>
> This check is unnecessary, the validity is always checked by the core.
>
Will remove this at next patch.
> > + if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
> > + dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
> > + 1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
> > + 1900 + MT2712_MAX_YEAR_OFFSET);
> > + return -EINVAL;
> > + }
>
> This check is unnecessary, see below.
>
Will change it at next patch.
> > +
> > + tm->tm_year -= MT2712_MIN_YEAR_OFFSET;
> > + tm->tm_mon++;
>
> You should probably avoid modifying tm, move the substraction and
> addition in the mt2712_writel calls.
>
Will change it at next patch.
> > + if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
> > + dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
> > + 1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
> > + 1900 + MT2712_MAX_YEAR_OFFSET);
> > + return -EINVAL;
> > + }
> > +
>
> Unnecessary check.
>
Will change it at next patch.
> > + p1 = mt2712_readl(rtc, MT2712_POWERKEY1);
> > + p2 = mt2712_readl(rtc, MT2712_POWERKEY2);
> > + if (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)
> > + dev_dbg(rtc->dev, "powerkey not set (lost power)\n");
> > +
>
> This info is valuable, you should check that when reading the time and
> return -EINVAL if power was lost.
>
Will change it at next patch.
>
> > + /* RTC need POWERKEY1/2 match, then goto normal work mode */
> > + mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
> > + mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
>
> This should be written when setting the time after power was lost.
>
I suppose we can move this into mt2712_rtc_read_time function's "if
(p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)" condition
which will be added at next patch. We need additional flag to mark this
condition or another if condition in mt2712_rtc_set_time fucntion if we
put these code in mt2712_rtc_set_time function.
> > +static const struct rtc_class_ops mt2712_rtc_ops = {
> > + .read_time = mt2712_rtc_read_time,
> > + .set_time = mt2712_rtc_set_time,
> > + .read_alarm = mt2712_rtc_read_alarm,
> > + .set_alarm = mt2712_rtc_set_alarm,
>
> For proper operations, you should also provide the .alarm_irq_enable
> callback.
>
Will change it at next patch.
> > + rtc->rtc_dev->ops = &mt2712_rtc_ops;
>
> If you set the range properly here using rtc_dev->range_min and
> rtc_dev->range_max, then the core will be able to do range checking and
> will also take care of the year offset/windowing calculations instead of
> having to hardcode that in the driver.
>
Will change it at next patch.
Best Regards,
Ran
_______________________________________________
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] clk: imx: pll14xx: avoid glitch when set rate
From: Leonard Crestez @ 2019-08-22 12:34 UTC (permalink / raw)
To: Peng Fan, sboyd@kernel.org
Cc: Jacky Bai, Anson Huang, shawnguo@kernel.org,
mturquette@baylibre.com, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, s.hauer@pengutronix.de,
linux-arm-kernel@lists.infradead.org, Abel Vesa
In-Reply-To: <AM0PR04MB44818E133AD735E3EB2789E288A50@AM0PR04MB4481.eurprd04.prod.outlook.com>
On 22.08.2019 12:18, Peng Fan wrote:
>> Subject: Re: [PATCH] clk: imx: pll14xx: avoid glitch when set rate
>>
>> On 20.08.2019 05:17, Peng Fan wrote:
>>> According to PLL1443XA and PLL1416X spec, "When BYPASS is 0 and RESETB
>>> is changed from 0 to 1, FOUT starts to output unstable clock until
>>> lock time passes. PLL1416X/PLL1443XA may generate a glitch at FOUT."
>>>
>>> So set BYPASS when RESETB is changed from 0 to 1 to avoid glitch.
>>> In the end of set rate, BYPASS will be cleared.
>>>
>>> @@ -191,6 +191,10 @@ static int clk_pll1416x_set_rate(struct clk_hw *hw,
>> unsigned long drate,
>>> tmp &= ~RST_MASK;
>>> writel_relaxed(tmp, pll->base);
>>>
>>> + /* Enable BYPASS */
>>> + tmp |= BYPASS_MASK;
>>> + writel(tmp, pll->base);
>>> +
>>
>> Shouldn't BYPASS be set before reset?
>
> No. the glitch happens when RESET changes from 0 to 1, not from 1 to 0.
You're right, sorry.
>> Also, isn't a similar bypass/unbypass dance also needed in
>> clk_pll14xx_prepare? As far as I understand that could also output glitches
>> until the PLL is locked. It could be a separate patch.
>
> Yes, that might also output glitch. Fix in v2.
>
>>
>> It's strange that this BYPASS bit is also handled by muxes like
>> audio_pll1_bypass in clk-imx8mm.c but that's a separate issue not strictly
>> related to the glitches you're trying to fix here.
>
> Yes, need use EXT_BYPASS for the mux usage.
Might make sense to post as a series.
_______________________________________________
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/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Leonard Crestez @ 2019-08-22 12:24 UTC (permalink / raw)
To: Chanwoo Choi, Viresh Kumar
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Krzysztof Kozlowski, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, cpgs (cpgs@samsung.com),
Georgi Djakov, linux-arm-kernel@lists.infradead.org
In-Reply-To: <4bdc0742-42ab-1ab6-4868-409eb9738cd8@samsung.com>
On 22.08.2019 14:06, Chanwoo Choi wrote:
> On 19. 8. 22. 오후 7:58, Leonard Crestez wrote:
>> On 8/22/2019 1:03 PM, Chanwoo Choi wrote:
>>> This patch doesn't check the range of input value
>>> with the supported frequencies of devfreq device.
>>>
>>> For example,
>>> The devfreq0 device has the following available frequencies
>>> 100000000 200000000 300000000
>>>
>>> and then user enters the 500000000 as following:
>>> echo 500000000 > /sys/class/devfreq/devfreq0/min_freq
>>>
>>> In result, get_effective_min_freq() will return the 500000000.
>>> It is wrong value. it show the unsupported frequency through
>>> min_freq sysfs path.
>>
>> Through dev_pm_qos devices can also ask for a freq higher than the
>> maximum OPP and unlike sysfs there is no way to reject such requests,
>> instead PM qos claims it's based on "best effort".
>>
>> There are many requests in the kernel for "PM_QOS_CPU_DMA_LATENCY 0" and
>> I think that DEV_PM_QOS_MIN_FREQUENCY, MAX_S32 is a reasonable way for a
>> device to request "max performance" from devfreq.
>>
>> Rejecting min > max is complicated (what happens to rejected requests
>> when max goes back up?) and I think it's better to just stick with a
>> "max overrides min" policy since it can already deal with conflicts.
>>
>> Do you have a usecase for rejecting out-of-range min_freq from
>> userspace? cpufreq also accepts arbitrary min/max values and handles them.
>
> I don't mean the rejecting when user enter the out-of-range frequency.
> As I commented, user can enter the value they want. But, we should
> check the range of input because devfreq have to show the correct supported
> frequency through sysfs.
We can avoid showing an out-of-range value in min_freq by printing
min(min_freq, max_freq).
The max_freq value from pm_qos can still be between OPPs so maybe print
devfreq_recommended_opp(max_freq, DEVFREQ_FLAG_LEAST_UPPER_BOUND).
>> In theory pm_qos could be extended to differentiate between "soft"
>> requests (current behavior) and "hard" requests which return errors if
>> they can't be guaranteed but this is far out of scope.
>
> I think that you agreed the limitation of dev_pm_qos when entering
> or requesting the unsupported frequency.
Yes, "best effort qos" is acceptable for now.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Ulf Hansson @ 2019-08-22 12:14 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, devicetree, linux-aspeed, Ryan Chen, linux-mmc,
Adrian Hunter, Linux Kernel Mailing List, Rob Herring,
Joel Stanley, Linux ARM
In-Reply-To: <c78d4c45-477b-4078-b269-aec72571c8cd@www.fastmail.com>
On Thu, 22 Aug 2019 at 13:55, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Thu, 22 Aug 2019, at 21:15, Ulf Hansson wrote:
> > On Thu, 15 Aug 2019 at 07:37, Andrew Jeffery <andrew@aj.id.au> wrote:
> > >
> > >
> > >
> > > On Thu, 15 Aug 2019, at 15:06, Joel Stanley wrote:
> > > > On Wed, 7 Aug 2019 at 00:38, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > > >
> > > > > The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
> > > > > SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> > > > > data bus if only a single slot is enabled.
> > > > >
> > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > >
> > > > Reviewed-by: Joel Stanley <joel@jms.id.au>
> > > >
> > > > Two minor comments below.
> > > >
> > > > > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > > > @@ -0,0 +1,105 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > > >
> > > > No "Copyright IBM" ?
> > >
> > > I'm going rogue.
> > >
> > > That reminds me I should chase up where we got to with the binding
> > > licensing.
> > >
> > > >
> > > > > +%YAML 1.2
> > > > > +---
> > > >
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/aspeed-clock.h>
> > > > > + sdc@1e740000 {
> > > > > + compatible = "aspeed,ast2500-sd-controller";
> > > > > + reg = <0x1e740000 0x100>;
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges = <0 0x1e740000 0x10000>;
> > > >
> > > > According to the datasheet this could be 0x20000. It does not matter
> > > > though, as there's nothing in it past 0x300.
> > >
> > > Good catch.
> > >
> >
> > Are you planning on sending a v6 or you want me to apply this and you
> > can post a patch on top?
>
> Yeah, sorry, I wasn't very clear there. I was hoping just to do a follow-up
> patch with the cleanups if you're okay with that?
That's fine. V5 applied for next, thanks!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: fix controller busy issue and add 24bits segment support
From: Ulf Hansson @ 2019-08-22 12:13 UTC (permalink / raw)
To: Chaotian Jing
Cc: srv_heupstream, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, linux-mediatek, Matthias Brugger,
Linux ARM
In-Reply-To: <20190822064741.11196-1-chaotian.jing@mediatek.com>
On Thu, 22 Aug 2019 at 08:47, Chaotian Jing <chaotian.jing@mediatek.com> wrote:
>
> the below 2 patches fix controller busy issue when plug out SD card
> and add 24bits segment size support.
>
> Chaotian Jing (2):
> mmc: mediatek: fix controller busy when plug out SD
> mmc: mediatek: support 24bits segment size
>
> drivers/mmc/host/mtk-sd.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
Applied for next, thanks!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 4/4] mmc: sdhci-of-esdhc: add erratum A011334 support in ls1028a 1.0 SoC
From: Ulf Hansson @ 2019-08-22 12:13 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, Catalin Marinas, Will Deacon, Adrian Hunter,
Catalin Horghidan, linux-mmc@vger.kernel.org, DTML, Rajesh Bhagat,
Alison Wang, Ashish Kumar, Claudiu Manoil, Rob Herring,
Vabhav Sharma, Linux ARM, Amit Jain, Alex Marginean,
Linux Kernel Mailing List, Li Yang, Rajat Srivastava, Yangbo Lu,
Jiafei Pan, linuxppc-dev, Xiaobo Xie
In-Reply-To: <20190814072649.8237-4-yinbo.zhu@nxp.com>
On Wed, 14 Aug 2019 at 09:24, Yinbo Zhu <yinbo.zhu@nxp.com> wrote:
>
> This patch is to add erratum A011334 support in ls1028a 1.0 SoC
>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index b16f7d440f78..eb2b290447fc 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1006,6 +1006,7 @@ static struct soc_device_attribute soc_incorrect_hostver[] = {
> static struct soc_device_attribute soc_fixup_sdhc_clkdivs[] = {
> { .family = "QorIQ LX2160A", .revision = "1.0", },
> { .family = "QorIQ LX2160A", .revision = "2.0", },
> + { .family = "QorIQ LS1028A", .revision = "1.0", },
> { },
> };
>
> --
> 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
* Re: [PATCH 1/2] mmc: sdhci-of-at91: add quirk for broken HS200
From: Ulf Hansson @ 2019-08-22 12:12 UTC (permalink / raw)
To: Eugen.Hristev, Ludovic Desroches
Cc: Alexandre Belloni, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Ulf Hansson, Adrian Hunter, Linux ARM
In-Reply-To: <20190809080842.zl4ytbjyt54bj6ta@M43218.corp.atmel.com>
On Fri, 9 Aug 2019 at 10:09, Ludovic Desroches
<ludovic.desroches@microchip.com> wrote:
>
> On Thu, Aug 08, 2019 at 05:23:00PM +0200, Ulf Hansson wrote:
> > On Thu, 8 Aug 2019 at 10:35, <Eugen.Hristev@microchip.com> wrote:
> > >
> > > From: Eugen Hristev <eugen.hristev@microchip.com>
> > >
> > > HS200 is not implemented in the driver, but the controller claims it
> > > through caps.
> > > Remove it via quirk.
> > > Without this quirk, the mmc core will try to enable hs200, which will fail,
> > > and the eMMC initialization will fail.
> > >
> > > Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >
> > Should this be applied as a fix and possibly tagged for stable?
> >
> > In such case, do you have a specific commit that it fixes?
>
> I think so, I would say:
> Fixes: bb5f8ea4d514 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
> Cc: stable@vger.kernel.org #v4.4 and later
>
> It doesn't apply on 4.4 but resolution is trivial.
>
> Regards
>
> Ludovic
>
[...]
Applied for fixes, by adding the above tags, thanks!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 09/23] iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
From: Yong Wu @ 2019-08-22 12:05 UTC (permalink / raw)
To: Will Deacon, Robin Murphy
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, Tomasz Figa, Joerg Roedel, linux-kernel,
Evan Green, chao.hao, iommu, Rob Herring, linux-mediatek,
Matthias Brugger, ming-fan.chen, anan.sun, Matthias Kaehlcke,
linux-arm-kernel
In-Reply-To: <20190822112836.efodtwu3souq3uwa@willie-the-truck>
Thanks very much for viewing this so quickly.
On Thu, 2019-08-22 at 12:28 +0100, Will Deacon wrote:
> On Thu, Aug 22, 2019 at 11:57:11AM +0100, Robin Murphy wrote:
> > On 2019-08-22 11:17 am, Will Deacon wrote:
> > > On Thu, Aug 22, 2019 at 11:08:58AM +0100, Robin Murphy wrote:
> > > > On 2019-08-22 9:56 am, Yong Wu wrote:
> > > > > On Wed, 2019-08-21 at 16:24 +0100, Will Deacon wrote:
> > > > > > On Wed, Aug 21, 2019 at 09:53:12PM +0800, Yong Wu wrote:
> > > > > > > MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
> > > > > > > the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
> > > > > > > respectively. Meanwhile the iova still is 32bits.
> > > > > > >
> > > > > > > Regarding whether the pagetable address could be over 4GB, the mt8183
> > > > > > > support it while the previous mt8173 don't, thus keep it as is.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > > > > ---
> > > > > > > drivers/iommu/io-pgtable-arm-v7s.c | 32 +++++++++++++++++++++++++-------
> > > > > > > include/linux/io-pgtable.h | 7 +++----
> > > > > > > 2 files changed, 28 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > @@ -731,7 +747,9 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> > > > > > > {
> > > > > > > struct arm_v7s_io_pgtable *data;
> > > > > > > - if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
> > > > > > > + if (cfg->ias > ARM_V7S_ADDR_BITS ||
> > > > > > > + (cfg->oas > ARM_V7S_ADDR_BITS &&
> > > > > > > + !(cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)))
> > > > > >
> > > > > > Please can you instead change arm_v7s_alloc_pgtable() so that it allows an
> > > > > > ias of up to 34 when the IO_PGTABLE_QUIRK_ARM_MTK_EXT is set?
> > > > >
> > > > > Here I only simply skip the oas checking for our case. then which way do
> > > > > your prefer? something like you commented before:?
> > > > >
> > > > >
> > > > > if (cfg->ias > ARM_V7S_ADDR_BITS)
> > > > > return NULL;
> > > > >
> > > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT) {
> > > > > if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
> > > > > cfg->oas = min(cfg->oas, ARM_V7S_ADDR_BITS);
> > > > > else if (cfg->oas > 34)
> > > > > return NULL;
> > > > > } else if (cfg->oas > ARM_V7S_ADDR_BITS) {
> > > > > return NULL;
> > > > > }
> > > >
> > > > All it should take is something like:
> > > >
> > > > if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
> > > > max_oas = 34;
> > > > else
> > > > max_oas = 32;
> > > > if (cfg->oas > max_oas)
> > > > return NULL;
> > > >
> > > > or even just:
> > > >
> > > > if (cfg->oas > 32 ||
> > > > (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT && cfg->oas > 34))
> > > > return NULL;
> > > >
> > > > (and if we prefer the latter style, perhaps we could introduce some kind of
> > > > "is_mtk_4gb()" helper to save on verbosity)
> > >
> > > I wondered the same thing, but another place we'd want the check is in
> > > iopte_to_paddr() which probably needs the PHYS_ADDR_T check to avoid GCC
> > > warnings, although I didn't try it.
> >
> > I'm pretty sure I confirmed that "paddr |= BIT_ULL(32)" doesn't warn when
> > phys_addt_t is 32-bit - it's well-defined unsigned integer truncation after
> > all, and if GCC starts warning about all the valid no-op code it optimises
> > away then it's going to run up against IS_ENABLED() first and foremost ;)
>
> You're quite right, although we live in a world where GCC shouts at us about
> missing comments in switch statements so I think my worry was justified!
>
> > > So if we did:
> > >
> > > static bool cfg_mtk_ext_enabled(struct io_pgtable_cfg *cfg)
> > > {
> > > return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
> > > cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT;
> > > }
> > >
> > > Then I suppose we could do this in _alloc():
> > >
> > > if (cfg->oas > cfg_mtk_ext_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS)
> > > return NULL;
>
> ^^ Apparantly, I left the bracketting here as an exercise to the reader.
>
> > >
> > > and then this in iopte_to_paddr():
> > >
> > > [...]
> > >
> > > paddr = pte & mask;
> > > if (!cfg_mtk_ext_enabled(cfg))
> > > return paddr;
> > >
> > > if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > paddr |= ...
> > >
> > > [...]
> > >
> > > What do you reckon?
> >
> > Yeah, that's the general shape of things I was picturing - I'm not that
> > fussed about the PHYS_ADDR_T_64BIT thing, especially if it's wrapped up in
> > just one place, so if you do want to keep it as belt-and-braces I'll just
> > consider it a slight code size optimisation for 32-bit builds.
>
> Ok, great. Yong Wu -- are you ok respinning with the above + missing
> brackets?
Of course I can.
NearlyAll the interface in this file is prefixed with "arm_v7s_", so
does the new interface also need it?, like arm_v7s_is_mtk_enabled. And
keep the iopte_to_paddr and paddr_to_iopte symmetrical.
Then the final patch would looks like below, is it ok?
+static bool arm_v7s_is_mtk_enabled(struct io_pgtable_cfg *cfg)
+{
+ return IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT);
+}
+
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return pte;
+
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -194,7 +212,15 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte
pte, int lvl,
else
mask = ARM_V7S_LVL_MASK(lvl);
- return pte & mask;
+ paddr = pte & mask;
+ if (!arm_v7s_is_mtk_enabled(cfg))
+ return paddr;
+
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ return paddr;
}
static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
@@ -315,9 +341,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot,
int lvl,
if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
pte |= ARM_V7S_ATTR_NS_SECTION;
- if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
- pte |= ARM_V7S_ATTR_MTK_4GB;
-
return pte;
}
@@ -731,7 +754,10 @@ static struct io_pgtable
*arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
{
struct arm_v7s_io_pgtable *data;
- if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
+ if (cfg->ias > ARM_V7S_ADDR_BITS)
+ return NULL;
+
+ if (cfg->oas > (arm_v7s_is_mtk_enabled(cfg) ? 34 : ARM_V7S_ADDR_BITS))
return NULL;
>
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/59] KVM: arm64: ARMv8.3 Nested Virtualization support
From: Alexandru Elisei @ 2019-08-22 11:57 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: Andre Przywara, Dave P Martin
In-Reply-To: <0d9aa552-fa01-c482-41d7-587acf308259@arm.com>
On 8/9/19 11:01 AM, Alexandru Elisei wrote:
> On 8/2/19 11:11 AM, Alexandru Elisei wrote:
>> Hi,
>>
>> On 6/21/19 10:37 AM, Marc Zyngier wrote:
>> When working on adding support for EL2 to kvm-unit-tests I was able to trigger
>> the following warning:
>>
>> # ./lkvm run -f psci.flat -m 128 -c 8 --console serial --irqchip gicv3 --nested
>> # lkvm run --firmware psci.flat -m 128 -c 8 --name guest-151
>> Info: Placing fdt at 0x80200000 - 0x80210000
>> # Warning: The maximum recommended amount of VCPUs is 4
>> chr_testdev_init: chr-testdev: can't find a virtio-console
>> INFO: PSCI version 1.0
>> PASS: invalid-function
>> PASS: affinity-info-on
>> PASS: affinity-info-off
>> [ 24.381266] WARNING: CPU: 3 PID: 160 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
>> kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.381366] Modules linked in:
>> [ 24.381466] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Not tainted
>> 5.2.0-rc5-00060-g7dbce63bd1c7 #145
>> [ 24.381566] Hardware name: Foundation-v8A (DT)
>> [ 24.381566] pstate: 40400009 (nZcv daif +PAN -UAO)
>> [ 24.381666] pc : kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.381766] lr : timer_emulate+0x24/0x98
>> [ 24.381766] sp : ffff000013d8b780
>> [ 24.381866] x29: ffff000013d8b780 x28: ffff80087a639b80
>> [ 24.381966] x27: ffff000010ba8648 x26: ffff000010b71b40
>> [ 24.382066] x25: ffff80087a63a100 x24: 0000000000000000
>> [ 24.382111] x23: 000080086ca54000 x22: ffff0000100ce260
>> [ 24.382166] x21: ffff800875e7c918 x20: ffff800875e7a800
>> [ 24.382275] x19: ffff800875e7ca08 x18: 0000000000000000
>> [ 24.382366] x17: 0000000000000000 x16: 0000000000000000
>> [ 24.382466] x15: 0000000000000000 x14: 0000000000002118
>> [ 24.382566] x13: 0000000000002190 x12: 0000000000002280
>> [ 24.382566] x11: 0000000000002208 x10: 0000000000000040
>> [ 24.382666] x9 : ffff000012dc3b38 x8 : 0000000000000000
>> [ 24.382766] x7 : 0000000000000000 x6 : ffff80087ac00248
>> [ 24.382866] x5 : 000080086ca54000 x4 : 0000000000002118
>> [ 24.382966] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
>> [ 24.383066] x1 : 0000000000000001 x0 : ffff800875e7ca08
>> [ 24.383066] Call trace:
>> [ 24.383166] kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.383266] kvm_timer_vcpu_load+0x9c/0x1a0
>> [ 24.383366] kvm_arch_vcpu_load+0xb0/0x1f0
>> [ 24.383366] kvm_sched_in+0x1c/0x28
>> [ 24.383466] finish_task_switch+0xd8/0x1d8
>> [ 24.383566] __schedule+0x248/0x4a0
>> [ 24.383666] preempt_schedule_irq+0x60/0x90
>> [ 24.383666] el1_irq+0xd0/0x180
>> [ 24.383766] kvm_handle_guest_abort+0x0/0x3a0
>> [ 24.383866] kvm_arch_vcpu_ioctl_run+0x41c/0x688
>> [ 24.383866] kvm_vcpu_ioctl+0x4c0/0x838
>> [ 24.383966] do_vfs_ioctl+0xb8/0x878
>> [ 24.384077] ksys_ioctl+0x84/0x90
>> [ 24.384166] __arm64_sys_ioctl+0x18/0x28
>> [ 24.384166] el0_svc_common.constprop.0+0xb0/0x168
>> [ 24.384266] el0_svc_handler+0x28/0x78
>> [ 24.384366] el0_svc+0x8/0xc
>> [ 24.384366] ---[ end trace 37a32293e43ac12c ]---
>> [ 24.384666] WARNING: CPU: 3 PID: 160 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
>> kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.384766] Modules linked in:
>> [ 24.384866] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
>> 5.2.0-rc5-00060-g7dbce63bd1c7 #145
>> [ 24.384966] Hardware name: Foundation-v8A (DT)
>> [ 24.384966] pstate: 40400009 (nZcv daif +PAN -UAO)
>> [ 24.385066] pc : kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.385166] lr : timer_emulate+0x24/0x98
>> [ 24.385166] sp : ffff000013d8b780
>> [ 24.385266] x29: ffff000013d8b780 x28: ffff80087a639b80
>> [ 24.385366] x27: ffff000010ba8648 x26: ffff000010b71b40
>> [ 24.385466] x25: ffff80087a63a100 x24: 0000000000000000
>> [ 24.385466] x23: 000080086ca54000 x22: ffff0000100ce260
>> [ 24.385566] x21: ffff800875e7c918 x20: ffff800875e7a800
>> [ 24.385666] x19: ffff800875e7ca80 x18: 0000000000000000
>> [ 24.385766] x17: 0000000000000000 x16: 0000000000000000
>> [ 24.385866] x15: 0000000000000000 x14: 0000000000002118
>> [ 24.385966] x13: 0000000000002190 x12: 0000000000002280
>> [ 24.385966] x11: 0000000000002208 x10: 0000000000000040
>> [ 24.386066] x9 : ffff000012dc3b38 x8 : 0000000000000000
>> [ 24.386166] x7 : 0000000000000000 x6 : ffff80087ac00248
>> [ 24.386266] x5 : 000080086ca54000 x4 : 0000000000002118
>> [ 24.386366] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
>> [ 24.386466] x1 : 0000000000000001 x0 : ffff800875e7ca80
>> [ 24.386466] Call trace:
>> [ 24.386566] kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.386666] kvm_timer_vcpu_load+0xa8/0x1a0
>> [ 24.386666] kvm_arch_vcpu_load+0xb0/0x1f0
>> [ 24.386898] kvm_sched_in+0x1c/0x28
>> [ 24.386966] finish_task_switch+0xd8/0x1d8
>> [ 24.387166] __schedule+0x248/0x4a0
>> [ 24.387354] preempt_schedule_irq+0x60/0x90
>> [ 24.387366] el1_irq+0xd0/0x180
>> [ 24.387466] kvm_handle_guest_abort+0x0/0x3a0
>> [ 24.387566] kvm_arch_vcpu_ioctl_run+0x41c/0x688
>> [ 24.387566] kvm_vcpu_ioctl+0x4c0/0x838
>> [ 24.387666] do_vfs_ioctl+0xb8/0x878
>> [ 24.387766] ksys_ioctl+0x84/0x90
>> [ 24.387866] __arm64_sys_ioctl+0x18/0x28
>> [ 24.387866] el0_svc_common.constprop.0+0xb0/0x168
>> [ 24.387966] el0_svc_handler+0x28/0x78
>> [ 24.388066] el0_svc+0x8/0xc
>> [ 24.388066] ---[ end trace 37a32293e43ac12d ]---
>> PASS: cpu-on
>> SUMMARY: 4 te[ 24.390266] WARNING: CPU: 3 PID: 160 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
>> kvm_timer_irq_can_fire+0xc/0x30
>> s[ 24.390366] Modules linked in:
>> ts[ 24.390366] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
>> 5.2.0-rc5-00060-g7dbce63bd1c7 #145
>> [ 24.390566] Hardware name: Foundation-v8A (DT)
>>
>> [ 24.390795] pstate: 40400009 (nZcv daif +PAN -UAO)
>> [ 24.390866] pc : kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.390966] lr : timer_emulate+0x24/0x98
>> [ 24.391066] sp : ffff000013d8b780
>> [ 24.391066] x29: ffff000013d8b780 x28: ffff80087a639b80
>> [ 24.391166] x27: ffff000010ba8648 x26: ffff000010b71b40
>> [ 24.391266] x25: ffff80087a63a100 x24: 0000000000000000
>> [ 24.391366] x23: 000080086ca54000 x22: 0000000000000003
>> [ 24.391466] x21: ffff800875e7c918 x20: ffff800875e7a800
>> [ 24.391466] x19: ffff800875e7ca08 x18: 0000000000000000
>> [ 24.391566] x17: 0000000000000000 x16: 0000000000000000
>> [ 24.391666] x15: 0000000000000000 x14: 0000000000002118
>> [ 24.391766] x13: 0000000000002190 x12: 0000000000002280
>> [ 24.391866] x11: 0000000000002208 x10: 0000000000000040
>> [ 24.391942] x9 : ffff000012dc3b38 x8 : 0000000000000000
>> [ 24.391966] x7 : 0000000000000000 x6 : ffff80087ac00248
>> [ 24.392066] x5 : 000080086ca54000 x4 : 0000000000002118
>> [ 24.392166] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
>> [ 24.392269] x1 : 0000000000000001 x0 : ffff800875e7ca08
>> [ 24.392366] Call trace:
>> [ 24.392433] kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.392466] kvm_timer_vcpu_load+0x9c/0x1a0
>> [ 24.392597] kvm_arch_vcpu_load+0xb0/0x1f0
>> [ 24.392666] kvm_sched_in+0x1c/0x28
>> [ 24.392766] finish_task_switch+0xd8/0x1d8
>> [ 24.392766] __schedule+0x248/0x4a0
>> [ 24.392866] preempt_schedule_irq+0x60/0x90
>> [ 24.392966] el1_irq+0xd0/0x180
>> [ 24.392966] kvm_handle_guest_abort+0x0/0x3a0
>> [ 24.393066] kvm_arch_vcpu_ioctl_run+0x41c/0x688
>> [ 24.393166] kvm_vcpu_ioctl+0x4c0/0x838
>> [ 24.393266] do_vfs_ioctl+0xb8/0x878
>> [ 24.393266] ksys_ioctl+0x84/0x90
>> [ 24.393366] __arm64_sys_ioctl+0x18/0x28
>> [ 24.393466] el0_svc_common.constprop.0+0xb0/0x168
>> [ 24.393566] el0_svc_handler+0x28/0x78
>> [ 24.393566] el0_svc+0x8/0xc
>> [ 24.393666] ---[ end trace 37a32293e43ac12e ]---
>> [ 24.393866] WARNING: CPU: 3 PID: 160 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:170
>> kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.394066] Modules linked in:
>> [ 24.394266] CPU: 3 PID: 160 Comm: kvm-vcpu-1 Tainted: G W
>> 5.2.0-rc5-00060-g7dbce63bd1c7 #145
>> [ 24.394366] Hardware name: Foundation-v8A (DT)
>> [ 24.394466] pstate: 40400009 (nZcv daif +PAN -UAO)
>> [ 24.394466] pc : kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.394566] lr : timer_emulate+0x24/0x98
>> [ 24.394666] sp : ffff000013d8b780
>> [ 24.394727] x29: ffff000013d8b780 x28: ffff80087a639b80
>> [ 24.394766] x27: ffff000010ba8648 x26: ffff000010b71b40
>> [ 24.394866] x25: ffff80087a63a100 x24: 0000000000000000
>> [ 24.394966] x23: 000080086ca54000 x22: 0000000000000003
>> [ 24.394966] x21: ffff800875e7c918 x20: ffff800875e7a800
>> [ 24.395066] x19: ffff800875e7ca80 x18: 0000000000000000
>> [ 24.395166] x17: 0000000000000000 x16: 0000000000000000
>> [ 24.395266] x15: 0000000000000000 x14: 0000000000002118
>> [ 24.395383] x13: 0000000000002190 x12: 0000000000002280
>> [ 24.395466] x11: 0000000000002208 x10: 0000000000000040
>> [ 24.395547] x9 : ffff000012dc3b38 x8 : 0000000000000000
>> [ 24.395666] x7 : 0000000000000000 x6 : ffff80087ac00248
>> [ 24.395866] x5 : 000080086ca54000 x4 : 0000000000002118
>> [ 24.395966] x3 : eeeeeeeeeeeeeeef x2 : ffff800875e7c918
>> [ 24.396066] x1 : 0000000000000001 x0 : ffff800875e7ca80
>> [ 24.396066] Call trace:
>> [ 24.396166] kvm_timer_irq_can_fire+0xc/0x30
>> [ 24.396266] kvm_timer_vcpu_load+0xa8/0x1a0
>> [ 24.396366] kvm_arch_vcpu_load+0xb0/0x1f0
>> [ 24.396366] kvm_sched_in+0x1c/0x28
>> [ 24.396466] finish_task_switch+0xd8/0x1d8
>> [ 24.396566] __schedule+0x248/0x4a0
>> [ 24.396666] preempt_schedule_irq+0x60/0x90
>> [ 24.396666] el1_irq+0xd0/0x180
>> [ 24.396766] kvm_handle_guest_abort+0x0/0x3a0
>> [ 24.396866] kvm_arch_vcpu_ioctl_run+0x41c/0x688
>> [ 24.396866] kvm_vcpu_ioctl+0x4c0/0x838
>> [ 24.397021] do_vfs_ioctl+0xb8/0x878
>> [ 24.397066] ksys_ioctl+0x84/0x90
>> [ 24.397166] __arm64_sys_ioctl+0x18/0x28
>> [ 24.397348] el0_svc_common.constprop.0+0xb0/0x168
>> [ 24.397366] el0_svc_handler+0x28/0x78
>> [ 24.397566] el0_svc+0x8/0xc
>> [ 24.397676] ---[ end trace 37a32293e43ac12f ]---
>>
>> # KVM compatibility warning.
>> virtio-9p device was not detected.
>> While you have requested a virtio-9p device, the guest kernel did not
>> initialize it.
>> Please make sure that the guest kernel was compiled with
>> CONFIG_NET_9P_VIRTIO=y enabled in .config.
>>
>> # KVM compatibility warning.
>> virtio-net device was not detected.
>> While you have requested a virtio-net device, the guest kernel did not
>> initialize it.
>> Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y
>> enabled in .config.
>>
>> [..]
> Did some investigating and this was caused by a bug in kvm-unit-tests (the fix
> for it will be part of the EL2 patches for kvm-unit-tests). The guest was trying
> to fetch an instruction from address 0x200, which KVM interprets as a prefetch
> abort on an I/O address and ends up calling kvm_inject_pabt. The code from
> arch/arm64/kvm/inject_fault.c doesn't know anything about nested virtualization,
> and it sets the VCPU mode directly to PSR_MODE_EL1h. This makes_hyp_ctxt return
> false, and get_timer_map will return an incorrect mapping.
>
> On next kvm_timer_vcpu_put, the direct timers will be {p,v}timer, and
> h{p,v}timer->loaded will not be set to false. In the corresponding call to
> kvm_timer_vcpu_load, KVM will try to emulate the hptimer and hvtimer, which
> still have loaded = true. And this causes the warning I saw.
I tried to fix it with the following patch, inject_undef64 was similarly broken:
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index fac962b467bd..aee8a9ef36d5 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -53,15 +53,7 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt,
unsigned long addr
{
unsigned long cpsr = *vcpu_cpsr(vcpu);
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
- u32 esr = 0;
-
- vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
- *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
-
- *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
- vcpu_write_spsr(vcpu, cpsr);
-
- vcpu_write_sys_reg(vcpu, addr, FAR_EL1);
+ u32 esr = ESR_ELx_FSC_EXTABT;
/*
* Build an {i,d}abort, depending on the level and the
@@ -82,13 +74,12 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool
is_iabt, unsigned long addr
if (!is_iabt)
esr |= ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT;
- vcpu_write_sys_reg(vcpu, esr | ESR_ELx_FSC_EXTABT, ESR_EL1);
-}
+ if (nested_virt_in_use(vcpu)) {
+ kvm_inject_nested_sync(vcpu, esr);
+ return;
+ }
-static void inject_undef64(struct kvm_vcpu *vcpu)
-{
- unsigned long cpsr = *vcpu_cpsr(vcpu);
- u32 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
+ vcpu_write_sys_reg(vcpu, esr, ESR_EL1);
vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
*vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
@@ -96,6 +87,14 @@ static void inject_undef64(struct kvm_vcpu *vcpu)
*vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
vcpu_write_spsr(vcpu, cpsr);
+ vcpu_write_sys_reg(vcpu, addr, FAR_EL1);
+}
+
+static void inject_undef64(struct kvm_vcpu *vcpu)
+{
+ unsigned long cpsr = *vcpu_cpsr(vcpu);
+ u32 esr = ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT;
+
/*
* Build an unknown exception, depending on the instruction
* set.
@@ -103,7 +102,18 @@ static void inject_undef64(struct kvm_vcpu *vcpu)
if (kvm_vcpu_trap_il_is32bit(vcpu))
esr |= ESR_ELx_IL;
+ if (nested_virt_in_use(vcpu)) {
+ kvm_inject_nested_sync(vcpu, esr);
+ return;
+ }
+
vcpu_write_sys_reg(vcpu, esr, ESR_EL1);
+
+ vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
+ *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
+
+ *vcpu_cpsr(vcpu) = PSTATE_FAULT_BITS_64;
+ vcpu_write_spsr(vcpu, cpsr);
}
/**
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Andrew Jeffery @ 2019-08-22 11:55 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, devicetree, linux-aspeed, Ryan Chen, linux-mmc,
Adrian Hunter, Linux Kernel Mailing List, Rob Herring,
Joel Stanley, Linux ARM
In-Reply-To: <CAPDyKFrDPxFMm710Z25i-euOT2rrgCNXVa4na-fye0xamMXq_A@mail.gmail.com>
On Thu, 22 Aug 2019, at 21:15, Ulf Hansson wrote:
> On Thu, 15 Aug 2019 at 07:37, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> >
> >
> > On Thu, 15 Aug 2019, at 15:06, Joel Stanley wrote:
> > > On Wed, 7 Aug 2019 at 00:38, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > >
> > > > The ASPEED SD/SDIO/MMC controller exposes two slots implementing the
> > > > SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> > > > data bus if only a single slot is enabled.
> > > >
> > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > >
> > > Reviewed-by: Joel Stanley <joel@jms.id.au>
> > >
> > > Two minor comments below.
> > >
> > > > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > > @@ -0,0 +1,105 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > >
> > > No "Copyright IBM" ?
> >
> > I'm going rogue.
> >
> > That reminds me I should chase up where we got to with the binding
> > licensing.
> >
> > >
> > > > +%YAML 1.2
> > > > +---
> > >
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/aspeed-clock.h>
> > > > + sdc@1e740000 {
> > > > + compatible = "aspeed,ast2500-sd-controller";
> > > > + reg = <0x1e740000 0x100>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges = <0 0x1e740000 0x10000>;
> > >
> > > According to the datasheet this could be 0x20000. It does not matter
> > > though, as there's nothing in it past 0x300.
> >
> > Good catch.
> >
>
> Are you planning on sending a v6 or you want me to apply this and you
> can post a patch on top?
Yeah, sorry, I wasn't very clear there. I was hoping just to do a follow-up
patch with the cleanups if you're okay with that?
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 v5] arm64: implement KPROBES_ON_FTRACE
From: Naveen N. Rao @ 2019-08-22 11:52 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Jisheng Zhang, Masami Hiramatsu
Cc: Mark Rutland, linux-doc@vger.kernel.org, Peter Zijlstra,
linux-kernel@vger.kernel.org, Steven Rostedt, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190822191351.3796aca8@xhacker.debian>
Jisheng Zhang wrote:
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Tested on berlin arm64 platform.
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009fe28 k _do_fork+0x0 [DISABLED]
>
> after the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox