* [PATCH] KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion
From: Marc Zyngier @ 2017-12-04 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203230435.22021-1-cdall@kernel.org>
On 03/12/17 23:04, Christoffer Dall wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> We are incorrectly rearranging 32-bit words inside a 64-bit typed value
> for big endian systems, which would result in never marking a virtual
> interrupt as inactive on big endian systems (assuming 32 or fewer LRs on
> the hardware). Fix this by not doing any word order manipulation for
> the typed values.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/hyp/vgic-v2-sr.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/virt/kvm/arm/hyp/vgic-v2-sr.c b/virt/kvm/arm/hyp/vgic-v2-sr.c
> index a3f18d362366..d7fd46fe9efb 100644
> --- a/virt/kvm/arm/hyp/vgic-v2-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v2-sr.c
> @@ -34,11 +34,7 @@ static void __hyp_text save_elrsr(struct kvm_vcpu *vcpu, void __iomem *base)
> else
> elrsr1 = 0;
>
> -#ifdef CONFIG_CPU_BIG_ENDIAN
> - cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
> -#else
> cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
> -#endif
> }
>
> static void __hyp_text save_lrs(struct kvm_vcpu *vcpu, void __iomem *base)
>
Duh!
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 23/37] KVM: arm64: Prepare to handle traps on deferred VM sysregs
From: Andrew Jones @ 2017-12-04 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203195026.GI4218@cbox>
On Sun, Dec 03, 2017 at 08:50:26PM +0100, Christoffer Dall wrote:
> On Mon, Nov 13, 2017 at 06:54:02PM +0100, Andrew Jones wrote:
...
> > > + }
> > > +
> > > + vcpu_sys_reg(vcpu, reg) = val;
> > > +}
> > > +
> > > /*
> > > * Generic accessor for VM registers. Only called as long as HCR_TVM
> > > + *
just noticed this stray blank line added here
> > > * is set. If the guest enables the MMU, we stop trapping the VM
> > > * sys_regs and leave it in complete control of the caches.
> > > */
> > > @@ -132,14 +182,14 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
> > > if (!p->is_aarch32 || !p->is_32bit) {
> > > val = p->regval;
> > > } else {
> > > - val = vcpu_sys_reg(vcpu, reg);
> > > + val = read_deferrable_vm_reg(vcpu, reg);
> > > if (r->reg % 2)
> > > val = (p->regval << 32) | (u64)lower_32_bits(val);
> > > else
> > > val = ((u64)upper_32_bits(val) << 32) |
> > > (u64)lower_32_bits(p->regval);
> > > }
> > > - vcpu_sys_reg(vcpu, reg) = val;
> > > + write_deferrable_vm_reg(vcpu, reg, val);
> > >
> > > kvm_toggle_cache(vcpu, was_enabled);
> > > return true;
> > > --
> > > 2.9.0
> > >
> >
> > I read ahead and see other wrappers that check sysregs_loaded_on_cpu are
> > added, but only write_deferrable_vm_reg() has 'deferrable' in its name.
> > Should it just be named read/write_vm_reg?
> >
>
> I chose this name to avoid implying that this function was universally
> supported for all (current and future) VM registers.
OK
Thanks,
drew
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: r8a77970: use SYSC power domain macros
From: Geert Uytterhoeven @ 2017-12-04 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128202109.031715810@cogentembedded.com>
On Tue, Nov 28, 2017 at 9:15 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Now that the commit 833bdb47c826 ("dt-bindings: power: add R8A77970 SYSC
> power domain definitions") has hit Linus' tree, we can replace the bare
> numbers (we had to use to avoid a cross tree dependency) with these macro
> definitions...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add mipi_dsi1 support for rk3399
From: Heiko Stuebner @ 2017-12-04 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130011127.GB124672@google.com>
Am Mittwoch, 29. November 2017, 17:11:27 CET schrieb Brian Norris:
> From: Nickey Yang <nickey.yang@rock-chips.com>
>
> This patch adds the information for the secondary MIPI DSI controller,
> e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing
> definition for dsi0.
>
> Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
applied for 4.16
Thanks
Heiko
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77970: use CPG core clock macros
From: Geert Uytterhoeven @ 2017-12-04 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128202105.552196002@cogentembedded.com>
On Tue, Nov 28, 2017 at 9:15 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Now that the commit ecadea00f588 ("dt-bindings: clock: Add R8A77970 CPG
> core clock definitions") has hit Linus' tree, we can replace the bare
> numbers (we had to use to avoid a cross tree dependency) with these macro
> definitions...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset
From: Heiko Stuebner @ 2017-12-04 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129233541.51337-1-briannorris@chromium.org>
Am Mittwoch, 29. November 2017, 15:35:41 CET schrieb Brian Norris:
> We've documented this one already, but we didn't add it to the DTSI yet.
>
> Suggested-by: Nickey Yang <nickey.yang@rock-chips.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
applied for 4.16
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Yong @ 2017-12-04 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171125160233.skefdpkjy4peh7et@flea.lan>
Hi Maxime,
I just noticed that you are using the second iteration?
Have you received my third iteration?
On Sat, 25 Nov 2017 17:02:33 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Nov 23, 2017 at 09:14:44AM +0800, Yong wrote:
> > > On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > > > and CSI1 is used for parallel interface. This is not documented in
> > > > > > datasheet but by testing and guess.
> > > > > >
> > > > > > This patch implement a v4l2 framework driver for it.
> > > > > >
> > > > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > > > ISP's support are not included in this patch.
> > > > > >
> > > > > > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> > > > >
> > > > > Thanks again for this driver.
> > > > >
> > > > > It seems like at least this iteration is behaving in a weird way with
> > > > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > > > >
> > > > > Starting a transfer of multiple frames in either of these formats,
> > > > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > > > >
> > > > > The panic seems to be generated with random data going into parts of
> > > > > the kernel memory, the pattern being in my case something like
> > > > > 0x8287868a which is very odd (always around 0x88)
> > > > >
> > > > > It turns out that when you cover the sensor, the values change to
> > > > > around 0x28, so it really seems like it's pixels that have been copied
> > > > > there.
> > > > >
> > > > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > > > me. Do you have the same issue on your side? Have you been able to
> > > > > test those formats using your hardware?
> > > >
> > > > I had tested the following formats with BT1120 input:
> > > > V4L2_PIX_FMT_NV12 -> NV12
> > > > V4L2_PIX_FMT_NV21 -> NV21
> > > > V4L2_PIX_FMT_NV16 -> NV16
> > > > V4L2_PIX_FMT_NV61 -> NV61
> > > > V4L2_PIX_FMT_YUV420 -> YU12
> > > > V4L2_PIX_FMT_YVU420 -> YV12
> > > > V4L2_PIX_FMT_YUV422P -> 422P
> > > > And they all work fine.
> > >
> > > Ok, that's good to know.
> > >
> > > > > Given that they all are planar formats and YUYV and the likes work
> > > > > just fine, maybe we can leave them aside for now?
> > > >
> > > > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > > > is bad? It's really weird.
> > > >
> > > > What's your input bus code format, type and width?
> > >
> > > The sensor is an ov5640, so the MBUS code for the bus is
> > > MEDIA_BUS_FMT_YUYV8_2X8.
> >
> > Did you test on V3s?
>
> No, this is on an H3, but that would be the first difference so far.
>
> > I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.
>
> Ok, it's good to know that at least it works on your end, it's useful
> for us to debug things :)
>
> > The Allwinner CSI's DMA is definitely weird. Ond?ej Jirman thought
> > that CSI has an internal queue (Ond?ej's commit has explained in detail).
> > I think CSI just pick up the buffer address before the frame done
> > interrupt triggered.
> > The patch in attachment can deal with this. You can see if it is
> > useful to solve your problem.
>
> I'll test that on monday, thanks!
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thanks,
Yong
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-04 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094041.25439-1-heiko@sntech.de>
Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william.wu@rock-chips.com>
>
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
>
> Signed-off-by: William Wu <william.wu@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> changes in v2:
> - add Rob's Ack
>
> Ideally usb maintainers would pick up this patch to the binding
> document and I'll take the devicetree changes after that.
>
> But if so desired, I can also pick up the binding change myself
> but would need an Ack for that.
just realized, the last version from august was actually v3, so this
should be v4, not v2 ... sorry about that.
Heiko
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: rockchip: enable usb3 nodes on rk3328-rock64
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094041.25439-1-heiko@sntech.de>
Enable the nodes to make the usb3 port usable on that board.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes in v2:
- new patch
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index d4f80786e7c2..e393c3586c11 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -331,3 +331,12 @@
&usb_host0_ohci {
status = "okay";
};
+
+&usbdrd3 {
+ status = "okay";
+};
+
+&usbdrd_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.14.2
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: rockchip: enable usb3 for RK3328 evaluation board
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094041.25439-1-heiko@sntech.de>
From: William Wu <william.wu@rock-chips.com>
Rockchip's RK3328 evaluation board has one USB 3.0 OTG controller,
we enable it and set it act as static xHCI host controller to
support USB 3.0 HOST on RK3328 evaluation board.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes in v2:
none
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index 3d551e3e6c23..95fba84239a7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -306,3 +306,12 @@
&usb_host0_ohci {
status = "okay";
};
+
+&usbdrd3 {
+ status = "okay";
+};
+
+&usbdrd_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
--
2.14.2
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: rockchip: add usb3 controller node for RK3328 SoCs
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204094041.25439-1-heiko@sntech.de>
From: William Wu <william.wu@rock-chips.com>
RK3328 has one USB 3.0 OTG controller which uses DWC_USB3
core's general architecture. It can act as static xHCI host
controller, static device controller, USB 3.0/2.0 OTG basing
on ID of USB3.0 PHY.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes in v2:
none
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 41d61840fb99..cafc572a68e0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -805,6 +805,33 @@
status = "disabled";
};
+ usbdrd3: usb at ff600000 {
+ compatible = "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG_REF>, <&cru SCLK_USB3OTG_SUSPEND>,
+ <&cru ACLK_USB3OTG>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usbdrd_dwc3: dwc3 at ff600000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xff600000 0x0 0x100000>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_u3_susphy_quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,dis-tx-ipgap-linecheck-quirk;
+ status = "disabled";
+ };
+ };
+
gic: interrupt-controller at ff811000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.14.2
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
From: William Wu <william.wu@rock-chips.com>
Adds the device tree bindings description for RK3328 and
compatible USB DWC3 controller.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes in v2:
- add Rob's Ack
Ideally usb maintainers would pick up this patch to the binding
document and I'll take the devicetree changes after that.
But if so desired, I can also pick up the binding change myself
but would need an Ack for that.
Documentation/devicetree/bindings/usb/rockchip,dwc3.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
index 50a31536e975..2c3f6a467fda 100644
--- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -1,7 +1,9 @@
Rockchip SuperSpeed DWC3 USB SoC controller
Required properties:
-- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC
+- compatible: should be one of the following:
+ - "rockchip,rk3399-dwc3": for rk3399 SoC
+ - "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3": for rk3328 SoC
- clocks: A list of phandle + clock-specifier pairs for the
clocks listed in clock-names
- clock-names: Should contain the following:
--
2.14.2
^ permalink raw reply related
* [PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Jerome Brunet @ 2017-12-04 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379059.2574.17.camel@baylibre.com>
On Mon, 2017-12-04 at 10:17 +0100, Jerome Brunet wrote:
> On Mon, 2017-12-04 at 14:00 +0800, Yixun Lan wrote:
> > From: Jian Hu <jian.hu@amlogic.com>
> >
> > Add PWM DT info for the Amlogic's Meson-Axg SoC.
> >
> > Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> > Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120
> > +++++++++++++++++++++++++++++
> > 1 file changed, 120 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > index 92f65eec3e18..f7f228701df1 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > @@ -177,6 +177,24 @@
> >
>
> [...]
>
> >
> > @@ -435,6 +537,24 @@
> > clock-names = "clk_i2c";
> > };
> >
> > + pwm_AO_ab: pwm at 7000 {
> > + compatible = "amlogic,meson-axg-ao-pwm";
> > + reg = <0x0 0x07000 0x0 0x20>;
> > + #pwm-cells = <3>;
> > + clocks = <&xtal>, <&xtal>;
> > + clock-names = "clkin0", "clkin1";
>
> like gxbb, "amlogic,meson-axg-ao-pwm" does not have such clock bindings,
> Later on, if we want to "correctly" get the clock from DT, it will have to
> gothrough a new compatible, I guess.
Please ignore this comment (monday morning...)
However clock bindings for this should be defined in the board dts, not the soc
one
>
> > + status = "disabled";
> > + };
> > +
> > + pwm_AO_cd: pwm at 2000 {
> > + compatible = "amlogic,axg-ao-pwm";
> > + reg = <0x0 0x02000 0x0 0x20>;
> > + #pwm-cells = <3>;
> > + clocks = <&xtal>, <&xtal>;
> > + clock-names = "clkin0", "clkin1";
> > + status = "disabled";
> > + };
> > +
> > uart_AO: serial at 3000 {
> > compatible = "amlogic,meson-gx-uart",
> > "amlogic,meson-ao-uart";
> > reg = <0x0 0x3000 0x0 0x18>;
>
>
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Sebastian Andrzej Siewior @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201182410.GU22781@e103592.cambridge.arm.com>
On 2017-12-01 18:24:10 [+0000], Dave Martin wrote:
> > diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
> > index 70c517aa4501..2a5f05b5a19a 100644
> > --- a/arch/arm64/crypto/Kconfig
> > +++ b/arch/arm64/crypto/Kconfig
> > @@ -19,19 +19,19 @@ config CRYPTO_SHA512_ARM64
> >
> > config CRYPTO_SHA1_ARM64_CE
> > tristate "SHA-1 digest algorithm (ARMv8 Crypto Extensions)"
> > - depends on KERNEL_MODE_NEON
> > + depends on KERNEL_MODE_NEON && !PREEMPT_RT_BASE
> > select CRYPTO_HASH
> > select CRYPTO_SHA1
>
> Sebastian, can you piont to where sha1 (say) hits this issue?
> I wonder whether this is really a sign that some refactoring is needed.
I disabled all NEON in one go. Looking at this, it shouldn't be a issue
with the block-walk. The only thing that might be a problem is that it
can do multiple blocks in one go.
> Cheers
> ---Dave
Sebastian
^ permalink raw reply
* [RESEND PATCH v5 6/6] ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
This patch adds the missing configs for the DART-MX6 SoM support :
- SERDEV bluetooth driver + SERIAL_DEV_BUS configs
- WL18XX driver
- DEFAULT_ON Led Trigger
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 0d44949..abd06c3 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -80,6 +80,7 @@ CONFIG_CAN=y
CONFIG_CAN_FLEXCAN=y
CONFIG_BT=y
CONFIG_BT_HCIUART=y
+CONFIG_BT_HCIUART_SERDEV=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_LL=y
CONFIG_CFG80211=y
@@ -155,6 +156,7 @@ CONFIG_USB_USBNET=y
CONFIG_USB_NET_CDC_EEM=m
CONFIG_BRCMFMAC=m
CONFIG_WL12XX=m
+CONFIG_WL18XX=m
CONFIG_WLCORE_SDIO=m
# CONFIG_WILINK_PLATFORM_DATA is not set
CONFIG_INPUT_EVDEV=y
@@ -185,6 +187,8 @@ CONFIG_SERIAL_IMX=y
CONFIG_SERIAL_IMX_CONSOLE=y
CONFIG_SERIAL_FSL_LPUART=y
CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
+CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
@@ -248,6 +252,7 @@ CONFIG_VIDEO_OV5640=m
CONFIG_SOC_CAMERA_OV2640=y
CONFIG_IMX_IPUV3_CORE=y
CONFIG_DRM=y
+CONFIG_DRM_PANEL_LVDS=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
CONFIG_DRM_DW_HDMI_CEC=y
@@ -340,6 +345,7 @@ CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 5/6] ARM: dts: imx6q: Add Variscite DART-MX6 Carrier-board support
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
This patch adds support for the i.MX6 Quad variant of the Variscite DART-MX6
SoM Carrier-Board.
This Carrier-Board has the following :
- LVDS interface for the VLCD-CAP-GLD-LVDS 7" LCD 800 x 480 touch display
- HDMI Connector
- USB Host + USB OTG Connector
- 10/100/1000 Mbps Ethernet
- miniPCI-Express slot
- SD Card connector
- Audio Headphone/Line In jack connectors
- On-board DMIC
- CAN bus header
- SPI header
- Camera Interfaces header
- 4xButtons, 2xLeds
- OnBoard RTC with Coin Backup battery socket
- RS232 Header + USB-Serial debug port
Product Page : http://www.variscite.com/products/evaluation-kits/dart-mx6-kits
The board support is done with all on-board and header interfaces enabled.
7" LVDS Touchscreen is enabled by default along HDMI output.
Audio interface is supported with the "simple-card" bindings.
PCIe slot, On-Board DMIC and Camera Interfaces are not handled yet.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-var-dt6customboard.dts | 235 +++++++++++++++++++++++++
2 files changed, 236 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-var-dt6customboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..148ff15 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -470,6 +470,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-tx6q-11x0-mb7.dtb \
imx6q-udoo.dtb \
imx6q-utilite-pro.dtb \
+ imx6q-var-dt6customboard.dtb \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb \
imx6q-wandboard-revd1.dtb \
diff --git a/arch/arm/boot/dts/imx6q-var-dt6customboard.dts b/arch/arm/boot/dts/imx6q-var-dt6customboard.dts
new file mode 100644
index 0000000..e0728d4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-var-dt6customboard.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Support for Variscite DART-MX6 Carrier-board
+ *
+ * Copyright 2017 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-var-dart.dtsi"
+#include <dt-bindings/input/linux-event-codes.h>
+
+/ {
+ model = "Variscite DART-MX6 Carrier-board";
+ compatible = "variscite,dt6customboard", "fsl,imx6q";
+
+ backlight_lvds: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 50000>;
+ brightness-levels = <0 4 8 16 32 64 128 248>;
+ default-brightness-level = <7>;
+ status = "okay";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ back {
+ gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_BACK>;
+ label = "Key Back";
+ linux,input-type = <1>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+
+ home {
+ gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_HOME>;
+ label = "Key Home";
+ linux,input-type = <1>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+
+ menu {
+ gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_MENU>;
+ label = "Key Menu";
+ linux,input-type = <1>;
+ debounce-interval = <100>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led2 {
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ panel1: lvds-panel {
+ compatible = "sgd,gktw70sdae4se", "panel-lvds";
+ backlight = <&backlight_lvds>;
+ width-mm = <153>;
+ height-mm = <86>;
+ label = "gktw70sdae4se";
+ data-mapping = "jeida-18";
+
+ panel-timing {
+ clock-frequency = <32000000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <39>;
+ hfront-porch = <39>;
+ vback-porch = <29>;
+ vfront-porch = <13>;
+ hsync-len = <47>;
+ vsync-len = <2>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+
+ reg_usb_h1_vbus: regulator-usbh1vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_otg_vbus: regulator-usbotgvbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "dt6-customboard-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&sound_codec>;
+ simple-audio-card,frame-master = <&sound_codec>;
+ simple-audio-card,widgets = "Headphone", "Headphone Jack",
+ "Line", "Line In";
+ simple-audio-card,routing = "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+
+ sound_cpu: simple-audio-card,cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ sound_codec: simple-audio-card,codec {
+ sound-dai = <&tlv320aic3106>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ };
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>,
+ <&gpio4 10 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&fec {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ touchscreen at 38 {
+ compatible = "edt,edt-ft5x06";
+ reg = <0x38>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ };
+
+ rtc at 68 {
+ compatible = "isil,isl12057";
+ reg = <0x68>;
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 1 {
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds1_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ dr_mode = "otg";
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ status = "okay";
+};
+
+&usdhc2 {
+ cd-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 4/6] ARM: dts: imx6qdl: Add Variscite DART-MX6 SoM support
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
This patch adds support for the Variscite DART-MX6 SoM with :
- i.MX6 Quad or Dual Lite SoC
- 1Gb/2Gb LPDDR2
- 4-64 GB eMMC
- Camera Interface
- HDMI+CEC interface
- LVDS / DSI / Parallel RGB interfaces
- Ethernet RGMII interface
- On-SoM Wi-Fi/Bluetooth with WiLink wl1835 SDIO Module
- SD/MMC/SDIO interface
- USB Host + USB OTG interface
- I2C interfaces
- SPI interfaces
- PCI-Express 2.0 interface
- on-SoM Audio Codec with HP/Line-In interfaces + DMIC interface
- Digital Audio interface
- S/PDIF interface
Product website : http://www.variscite.com/products/system-on-module-som/cortex-a9/dart-mx6-cpu-freescale-imx6
Support is handled with a SoM-centric dtsi exporting the default interfaces
along the default pinmuxing to be enabled by the board dts file.
Only board-independent devices like WiFi, eMMC or PMIC are enabled in the dtsi.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/imx6qdl-var-dart.dtsi | 503 ++++++++++++++++++++++++++++++++
1 file changed, 503 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-var-dart.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-var-dart.dtsi b/arch/arm/boot/dts/imx6qdl-var-dart.dtsi
new file mode 100644
index 0000000..421d6f5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-var-dart.dtsi
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Support for Variscite DART-MX6 Module
+ *
+ * Copyright 2017 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ memory {
+ reg = <0x10000000 0x40000000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_wl18xx_vmmc: regulator-wl18xx {
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1807";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio7 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <70000>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ ssi2 {
+ fsl,audmux-port = <1>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_SYN |
+ IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) |
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(2))
+ IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ aud3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(1)
+ >;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "disabled";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "disabled";
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "disabled";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii";
+ status = "disabled";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmicec>;
+ ddc-i2c-bus = <&i2c1>;
+ status = "disabled";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "disabled";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pmic at 8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3950000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ tlv320aic3106: codec at 1b {
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ #sound-dai-cells = <0>;
+ DRVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_3p3v>;
+ IOVDD-supply = <®_3p3v>;
+ DVDD-supply = <®_3p3v>;
+ ai3x-ocmv = <0>;
+ gpio-reset = <&gpio5 5 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmux {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ /* Audio Clock */
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
+ >;
+ };
+
+ pinctrl_bt: bt {
+ fsl,pins = <
+ /* Bluetooth enable */
+ MX6QDL_PAD_SD3_DAT6__GPIO6_IO18 0x1b0b1
+ /* Bluetooth Slow Clock */
+ MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT 0x000b0
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK 0x100b1
+ /* SPI1 CS0 */
+ MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
+ /* SPI1 CS1 */
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x100b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x100b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x10030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x10030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x10030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x10030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x10030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x10030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x100b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+ MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmicec: hdmicecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ /* PMIC INT */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT9__PWM2_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_DAT4__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT5__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
+ MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17059
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10059
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+ /* WL_EN */
+ MX6QDL_PAD_SD3_DAT7__GPIO6_IO17 0x17071
+ /* WL_IRQ */
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x17071
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170B9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100B9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170B9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170B9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170B9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170B9
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170F9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100F9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170F9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170F9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170F9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170F9
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ >;
+ };
+};
+
+&pcie {
+ fsl,tx-swing-full = <103>;
+ fsl,tx-swing-low = <103>;
+ reset-gpio = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ status = "disabled";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "disabled";
+};
+
+®_arm {
+ vin-supply = <&sw1a_reg>;
+};
+
+®_pu {
+ vin-supply = <&sw1c_reg>;
+};
+
+®_soc {
+ vin-supply = <&sw1c_reg>;
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&ssi2 {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2 &pinctrl_bt>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "ti,wl1835-st";
+ enable-gpios = <&gpio6 18 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+ status = "disabled";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "disabled";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <4>;
+ vmmc-supply = <®_wl18xx_vmmc>;
+ non-removable;
+ wakeup-source;
+ keep-power-in-suspend;
+ cap-power-off-card;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ wlcore: wlcore at 2 {
+ compatible = "ti,wl1835";
+ reg = <2>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+ ref-clock-frequency = <38400000>;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "disabled";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 3/6] dt-bindings: display: Add bindings for SGD GKTW70SDAE4SE Panel
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
The GKTW70SDAE4SE is an LVDS display panel.
Their bindings are modelled on the the LVDS panel bindings.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/panel/sgd,gktw70sdae4se.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
new file mode 100644
index 0000000..d06644b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
@@ -0,0 +1,41 @@
+Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
+==========================================================
+
+The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+Required properties:
+
+- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
+
+Example
+-------
+
+panel {
+ compatible = "sgd,gktw70sdae4se", "panel-lvds";
+
+ width-mm = <153>;
+ height-mm = <86>;
+
+ data-mapping = "jeida-18";
+
+ panel-timing {
+ clock-frequency = <32000000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <39>;
+ hfront-porch = <39>;
+ vback-porch = <29>;
+ vfront-porch = <13>;
+ hsync-len = <47>;
+ vsync-len = <2>;
+ };
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 2/6] dt-bindings: Add vendor prefix for Solomon Goldentek Display Corporation
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
Solomon Goldentek Display Corporation is a Taiwanese LCD/LCM manufacturer.
Company Site: http://www.goldentek.com.tw
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd..b0d3bef 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -305,6 +305,7 @@ seagate Seagate Technology PLC
semtech Semtech Corporation
sensirion Sensirion AG
sff Small Form Factor Committee
+sgd Solomon Goldentek Display Corporation
sgx SGX Sensortech
sharp Sharp Corporation
shimafuji Shimafuji Electric, Inc.
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 1/6] ARM: dts: imx6qdl-pinfunc: Add missing MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512379270-27436-1-git-send-email-narmstrong@baylibre.com>
Add missing pinmux entry for OSC32K_32K_OUT on pad ENET_RXD0 used by the
Variscite DART-MX6 SoM.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/imx6dl-pinfunc.h | 1 +
arch/arm/boot/dts/imx6q-pinfunc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-pinfunc.h b/arch/arm/boot/dts/imx6dl-pinfunc.h
index 0ead323..37e430a 100644
--- a/arch/arm/boot/dts/imx6dl-pinfunc.h
+++ b/arch/arm/boot/dts/imx6dl-pinfunc.h
@@ -668,6 +668,7 @@
#define MX6QDL_PAD_ENET_RX_ER__SPDIF_IN 0x1f4 0x5c4 0x8f0 0x3 0x1
#define MX6QDL_PAD_ENET_RX_ER__ENET_1588_EVENT2_OUT 0x1f4 0x5c4 0x000 0x4 0x0
#define MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x1f4 0x5c4 0x000 0x5 0x0
+#define MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT 0x1f8 0x5c8 0x000 0x0 0x0
#define MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1f8 0x5c8 0x818 0x1 0x0
#define MX6QDL_PAD_ENET_RXD0__ESAI_TX_HF_CLK 0x1f8 0x5c8 0x838 0x2 0x0
#define MX6QDL_PAD_ENET_RXD0__SPDIF_OUT 0x1f8 0x5c8 0x000 0x3 0x0
diff --git a/arch/arm/boot/dts/imx6q-pinfunc.h b/arch/arm/boot/dts/imx6q-pinfunc.h
index 9fc6120..cfb11d3 100644
--- a/arch/arm/boot/dts/imx6q-pinfunc.h
+++ b/arch/arm/boot/dts/imx6q-pinfunc.h
@@ -551,6 +551,7 @@
#define MX6QDL_PAD_ENET_RXD1__ESAI_TX_FS 0x1e0 0x4f4 0x860 0x2 0x0
#define MX6QDL_PAD_ENET_RXD1__ENET_1588_EVENT3_OUT 0x1e0 0x4f4 0x000 0x4 0x0
#define MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1e0 0x4f4 0x000 0x5 0x0
+#define MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT 0x1e4 0x4f8 0x000 0x0 0x0
#define MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1e4 0x4f8 0x848 0x1 0x1
#define MX6QDL_PAD_ENET_RXD0__ESAI_TX_HF_CLK 0x1e4 0x4f8 0x868 0x2 0x0
#define MX6QDL_PAD_ENET_RXD0__SPDIF_OUT 0x1e4 0x4f8 0x000 0x3 0x0
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH v5 0/6] ARM: Add Variscite DART-MX6 SoM and Carrier-board support
From: Neil Armstrong @ 2017-12-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
This is a resend of [5] with only changes in the SPDX-Licence-Identifier to
the top of the DTS files as required by Linus and explicited at [6].
This patchset adds support for the Variscite DART-MX6 SoM with :
- i.MX6 Quad or Dual Lite SoC
- 1Gb/2Gb LPDDR2
- 4-64 GB eMMC
- Camera Interface
- HDMI+CEC interface
- LVDS / DSI / Parallel RGB interfaces
- Ethernet RGMII interface
- On-SoM Wi-Fi/Bluetooth with WiLink wl1835 SDIO Module
- SD/MMC/SDIO interface
- USB Host + USB OTG interface
- I2C interfaces
- SPI interfaces
- PCI-Express 2.0 interface
- on-SoM Audio Codec with HP/Line-In interfaces + DMIC interface
- Digital Audio interface
- S/PDIF interface
And the Carrier-Board with the following :
- LVDS interface for the VLCD-CAP-GLD-LVDS 7" LCD 800 x 480 touch display
- HDMI Connector
- USB Host + USB OTG Connector
- 10/100/1000 Mbps Ethernet
- miniPCI-Express slot
- SD Card connector
- Audio Headphone/Line In jack connectors
- On-board DMIC
- CAN bus header
- SPI header
- Camera Interfaces header
- 4xButtons, 2xLeds
- OnBoard RTC with Coin Backup battery socket
- RS232 Header + USB-Serial debug port
First patch contains a missing pinmux define used by the SoM.
Last patch contains configs used by the SoM DT like SERDEV or WL18XX support.
PCIe, On-Board DMIC and Camera Interfaces are not handled yet.
Changes since v5 at [5]:
- Moved SPDX-Licence-Identifier to top of dts files
Changes since v4 at [4]:
- Renamed coded label
- Updated gpio wakeup properties
- Removed useless panel blank lines
- Removed leading 0 in pmic node name address
- Changed last patch title to match imx defconfig name
- Fixed dtsi alphabetical ordering
Changes since v3 at [3]:
- minor pcie dt fix
- added tags
Changes since v2 at [2]:
- Added bindings acks
- fixed enable-active-high regulators property
- moved hdmi dd-i2c-bus to son dtsi
- fixed pinmux IOMUX value
- add pcie reset-gpio
Changes since v1 at [1]:
- Add lvds display vendor prefix and bindings
- fix all gpio phandle arguments with correct ACTIVE_XXX define
- drop pcie support
- drop custom operating points
- fix arm/pu/soc vin-supply instead of &cpu node override
- fix can pinmux value
- changed button node name
- add revied-by tags on first and last patches
[1] http://lkml.kernel.org/r/1511281705-30849-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1511348560-28505-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1511785716-23492-1-git-send-email-narmstrong at baylibre.com
[4] http://lkml.kernel.org/r/1511950857-19292-1-git-send-email-narmstrong at baylibre.com
[5] http://lkml.kernel.org/r/1512119024-521-1-git-send-email-narmstrong at baylibre.com
[6] https://marc.info/?l=linux-kernel&m=151051532322831&w=2
Neil Armstrong (6):
ARM: dts: imx6qdl-pinfunc: Add missing
MX6QDL_PAD_ENET_RXD0__OSC32K_32K_OUT
dt-bindings: Add vendor prefix for Solomon Goldentek Display
Corporation
dt-bindings: display: Add bindings for SGD GKTW70SDAE4SE Panel
ARM: dts: imx6qdl: Add Variscite DART-MX6 SoM support
ARM: dts: imx6q: Add Variscite DART-MX6 Carrier-board support
ARM: imx_v6_v7_defconfig: Add missing config for DART-MX6 SoM
.../bindings/display/panel/sgd,gktw70sdae4se.txt | 41 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-pinfunc.h | 1 +
arch/arm/boot/dts/imx6q-pinfunc.h | 1 +
arch/arm/boot/dts/imx6q-var-dt6customboard.dts | 235 ++++++++++
arch/arm/boot/dts/imx6qdl-var-dart.dtsi | 503 +++++++++++++++++++++
arch/arm/configs/imx_v6_v7_defconfig | 6 +
8 files changed, 789 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
create mode 100644 arch/arm/boot/dts/imx6q-var-dt6customboard.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-var-dart.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH 3/6] cpufreq: sort the drivers in ARM part
From: Viresh Kumar @ 2017-12-04 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201112508.14121-4-gregory.clement@free-electrons.com>
On 01-12-17, 12:25, Gregory CLEMENT wrote:
> Keep the driver files alphabetically sorted.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/cpufreq/Makefile | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 812f9e0d01a3..d762e76887e7 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
> obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
>
> obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
> +obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
Shouldn't we add them in ascending order of the whole config name and not just
CPPC_CPUFREQ ?
--
viresh
^ permalink raw reply
* [PATCH 3/3] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Jerome Brunet @ 2017-12-04 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204060018.8856-4-yixun.lan@amlogic.com>
On Mon, 2017-12-04 at 14:00 +0800, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add PWM DT info for the Amlogic's Meson-Axg SoC.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 120
> +++++++++++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 92f65eec3e18..f7f228701df1 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -177,6 +177,24 @@
>
[...]
>
> @@ -435,6 +537,24 @@
> clock-names = "clk_i2c";
> };
>
> + pwm_AO_ab: pwm at 7000 {
> + compatible = "amlogic,meson-axg-ao-pwm";
> + reg = <0x0 0x07000 0x0 0x20>;
> + #pwm-cells = <3>;
> + clocks = <&xtal>, <&xtal>;
> + clock-names = "clkin0", "clkin1";
like gxbb, "amlogic,meson-axg-ao-pwm" does not have such clock bindings,
Later on, if we want to "correctly" get the clock from DT, it will have to gothrough a new compatible, I guess.
> + status = "disabled";
> + };
> +
> + pwm_AO_cd: pwm at 2000 {
> + compatible = "amlogic,axg-ao-pwm";
> + reg = <0x0 0x02000 0x0 0x20>;
> + #pwm-cells = <3>;
> + clocks = <&xtal>, <&xtal>;
> + clock-names = "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> uart_AO: serial at 3000 {
> compatible = "amlogic,meson-gx-uart",
> "amlogic,meson-ao-uart";
> reg = <0x0 0x3000 0x0 0x18>;
^ permalink raw reply
* [PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip
From: Boris Brezillon @ 2017-12-04 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512366470-16772-1-git-send-email-yamada.masahiro@socionext.com>
On Mon, 4 Dec 2017 14:47:50 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> struct nand_buffers is malloc'ed in nand_scan_tail() just for
> containing three pointers. Move the pointers into nand_chip
> and delete struct nand_buffers.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Another possibility is to keep struct nand_buffers,
> but embed it in struct nand_chip.
>
> struct nand_chip {
> ...
>
> struct nand_buffers buffers;
>
> ...
> };
>
> I will follow Boris's opinion, anyway.
Nope, I think it's fine to just drop the nand_buffers struct, but I'd
prefer to have ecc related buffers placed in nand_ecc_ctrl:
struct nand_ecc_ctrl {
...
u8 *code_buf;
u8 *calc_buf;
...
};
or
struct nand_ecc_ctrl {
...
struct {
u8 *code;
u8 *calc;
} bufs;
...
};
And ideally, databuf should be placed next to pagebuf in the
nand_chip struct, since those fields are tightly linked.
>
>
> drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
> drivers/mtd/nand/cafe_nand.c | 15 ++----
> drivers/mtd/nand/denali.c | 2 +-
> drivers/mtd/nand/fsmc_nand.c | 4 +-
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 4 +-
> drivers/mtd/nand/nand_base.c | 91 +++++++++++++++-------------------
> drivers/mtd/nand/nand_bbt.c | 2 +-
> drivers/mtd/nand/omap2.c | 10 ++--
> drivers/mtd/nand/sunxi_nand.c | 6 +--
> include/linux/mtd/rawnand.h | 23 +++------
> 10 files changed, 64 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
> index e0eb51d..6c9f7ec 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1681,7 +1681,7 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
> int ret;
>
> if (!buf) {
> - buf = chip->buffers->databuf;
> + buf = chip->databuf;
> /* Invalidate page cache */
> chip->pagebuf = -1;
> }
> diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
> index bc558c4..1e54196 100644
> --- a/drivers/mtd/nand/cafe_nand.c
> +++ b/drivers/mtd/nand/cafe_nand.c
> @@ -613,7 +613,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
> uint32_t ctrl;
> int err = 0;
> int old_dma;
> - struct nand_buffers *nbuf;
>
> /* Very old versions shared the same PCI ident for all three
> functions on the chip. Verify the class too... */
> @@ -732,14 +731,12 @@ static int cafe_nand_probe(struct pci_dev *pdev,
> goto out_irq;
>
> cafe->dmabuf = dma_alloc_coherent(&cafe->pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> + 2112 + mtd->writesize + mtd->oobsize,
> &cafe->dmaaddr, GFP_KERNEL);
Not directly related to this patch, but cafe_nand is the last user of
NAND_OWN_BUFFERS, and after looking at the code, I think it's actually
not needed, because the driver uses its own bounce buffer to do DMA
transfers. That'd be great if we could get rid of this flag completely
and let the core allocate the buffers for everyone. Could you have a
look?
> if (!cafe->dmabuf) {
> err = -ENOMEM;
> goto out_irq;
> }
> - cafe->nand.buffers = nbuf = (void *)cafe->dmabuf + 2112;
>
> /* Set up DMA address */
> cafe_writel(cafe, cafe->dmaaddr & 0xffffffff, NAND_DMA_ADDR0);
> @@ -753,9 +750,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
> cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
>
> /* this driver does not need the @ecccalc and @ecccode */
> - nbuf->ecccalc = NULL;
> - nbuf->ecccode = NULL;
> - nbuf->databuf = (uint8_t *)(nbuf + 1);
> + cafe->nand.databuf = (void *)cafe->dmabuf + 2112;
>
> /* Restore the DMA flag */
> usedma = old_dma;
> @@ -802,8 +797,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>
> out_free_dma:
> dma_free_coherent(&cafe->pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> + 2112 + mtd->writesize + mtd->oobsize,
> cafe->dmabuf, cafe->dmaaddr);
> out_irq:
> /* Disable NAND IRQ in global IRQ mask register */
> @@ -830,8 +824,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
> free_rs(cafe->rs);
> pci_iounmap(pdev, cafe->mmio);
> dma_free_coherent(&cafe->pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> + 2112 + mtd->writesize + mtd->oobsize,
> cafe->dmabuf, cafe->dmaaddr);
> kfree(cafe);
> }
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 2fc964b..e1f8c6f 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -328,7 +328,7 @@ static int denali_check_erased_page(struct mtd_info *mtd,
> unsigned long uncor_ecc_flags,
> unsigned int max_bitflips)
> {
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_code = chip->ecccode;
> int ecc_steps = chip->ecc.steps;
> int ecc_size = chip->ecc.size;
> int ecc_bytes = chip->ecc.bytes;
> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
> index eac15d9..147ca3d 100644
> --- a/drivers/mtd/nand/fsmc_nand.c
> +++ b/drivers/mtd/nand/fsmc_nand.c
> @@ -684,8 +684,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> uint8_t *p = buf;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> int off, len, group = 0;
> /*
> * ecc_oob is intentionally taken as uint16_t. In 16bit devices, we
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 50f8d4a..3312945 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1712,7 +1712,7 @@ static int mx23_check_transcription_stamp(struct gpmi_nand_data *this)
> unsigned int search_area_size_in_strides;
> unsigned int stride;
> unsigned int page;
> - uint8_t *buffer = chip->buffers->databuf;
> + uint8_t *buffer = chip->databuf;
> int saved_chip_number;
> int found_an_ncb_fingerprint = false;
>
> @@ -1771,7 +1771,7 @@ static int mx23_write_transcription_stamp(struct gpmi_nand_data *this)
> unsigned int block;
> unsigned int stride;
> unsigned int page;
> - uint8_t *buffer = chip->buffers->databuf;
> + uint8_t *buffer = chip->databuf;
> int saved_chip_number;
> int status;
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 6135d00..1f8297c 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -1456,8 +1456,8 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> uint8_t *p = buf;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> unsigned int max_bitflips = 0;
>
> chip->ecc.read_page_raw(mtd, chip, buf, 1, page);
> @@ -1529,7 +1529,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
>
> /* Calculate ECC */
> for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size)
> - chip->ecc.calculate(mtd, p, &chip->buffers->ecccalc[i]);
> + chip->ecc.calculate(mtd, p, &chip->ecccalc[i]);
>
> /*
> * The performance is faster if we position offsets according to
> @@ -1563,7 +1563,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
> }
>
> - ret = mtd_ooblayout_get_eccbytes(mtd, chip->buffers->ecccode,
> + ret = mtd_ooblayout_get_eccbytes(mtd, chip->ecccode,
> chip->oob_poi, index, eccfrag_len);
> if (ret)
> return ret;
> @@ -1572,16 +1572,16 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
> for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size) {
> int stat;
>
> - stat = chip->ecc.correct(mtd, p,
> - &chip->buffers->ecccode[i], &chip->buffers->ecccalc[i]);
> + stat = chip->ecc.correct(mtd, p, &chip->ecccode[i],
> + &chip->ecccalc[i]);
> if (stat == -EBADMSG &&
> (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
> /* check for empty pages with bitflips */
> stat = nand_check_erased_ecc_chunk(p, chip->ecc.size,
> - &chip->buffers->ecccode[i],
> - chip->ecc.bytes,
> - NULL, 0,
> - chip->ecc.strength);
> + &chip->ecccode[i],
> + chip->ecc.bytes,
> + NULL, 0,
> + chip->ecc.strength);
> }
>
> if (stat < 0) {
> @@ -1611,8 +1611,8 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> uint8_t *p = buf;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> unsigned int max_bitflips = 0;
>
> for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
> @@ -1674,8 +1674,8 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> uint8_t *p = buf;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> unsigned int max_bitflips = 0;
>
> /* Read the OOB area first */
> @@ -1894,7 +1894,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
>
> /* Is the current page in the buffer? */
> if (realpage != chip->pagebuf || oob) {
> - bufpoi = use_bufpoi ? chip->buffers->databuf : buf;
> + bufpoi = use_bufpoi ? chip->databuf : buf;
>
> if (use_bufpoi && aligned)
> pr_debug("%s: using read bounce buffer for buf@%p\n",
> @@ -1938,7 +1938,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
> /* Invalidate page cache */
> chip->pagebuf = -1;
> }
> - memcpy(buf, chip->buffers->databuf + col, bytes);
> + memcpy(buf, chip->databuf + col, bytes);
> }
>
> if (unlikely(oob)) {
> @@ -1979,7 +1979,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
> buf += bytes;
> max_bitflips = max_t(unsigned int, max_bitflips, ret);
> } else {
> - memcpy(buf, chip->buffers->databuf + col, bytes);
> + memcpy(buf, chip->databuf + col, bytes);
> buf += bytes;
> max_bitflips = max_t(unsigned int, max_bitflips,
> chip->pagebuf_bitflips);
> @@ -2403,7 +2403,7 @@ static int nand_write_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
> int i, eccsize = chip->ecc.size, ret;
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_calc = chip->ecccalc;
> const uint8_t *p = buf;
>
> /* Software ECC calculation */
> @@ -2433,7 +2433,7 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
> int i, eccsize = chip->ecc.size, ret;
> int eccbytes = chip->ecc.bytes;
> int eccsteps = chip->ecc.steps;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_calc = chip->ecccalc;
> const uint8_t *p = buf;
>
> for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
> @@ -2469,7 +2469,7 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
> int oob_required, int page)
> {
> uint8_t *oob_buf = chip->oob_poi;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_calc = chip->ecccalc;
> int ecc_size = chip->ecc.size;
> int ecc_bytes = chip->ecc.bytes;
> int ecc_steps = chip->ecc.steps;
> @@ -2503,7 +2503,7 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
>
> /* copy calculated ECC for whole page to chip->buffer->oob */
> /* this include masked-value(0xFF) for unwritten subpages */
> - ecc_calc = chip->buffers->ecccalc;
> + ecc_calc = chip->ecccalc;
> ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
> chip->ecc.total);
> if (ret)
> @@ -2737,9 +2737,9 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
> if (part_pagewr)
> bytes = min_t(int, bytes - column, writelen);
> chip->pagebuf = -1;
> - memset(chip->buffers->databuf, 0xff, mtd->writesize);
> - memcpy(&chip->buffers->databuf[column], buf, bytes);
> - wbuf = chip->buffers->databuf;
> + memset(chip->databuf, 0xff, mtd->writesize);
> + memcpy(&chip->databuf[column], buf, bytes);
> + wbuf = chip->databuf;
> }
>
> if (unlikely(oob)) {
> @@ -4632,7 +4632,6 @@ int nand_scan_tail(struct mtd_info *mtd)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> struct nand_ecc_ctrl *ecc = &chip->ecc;
> - struct nand_buffers *nbuf = NULL;
> int ret, i;
>
> /* New bad blocks should be marked in OOB, flash-based BBT, or both */
> @@ -4647,31 +4646,23 @@ int nand_scan_tail(struct mtd_info *mtd)
> }
>
> if (!(chip->options & NAND_OWN_BUFFERS)) {
> - nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
> - if (!nbuf)
> + chip->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> + if (!chip->ecccalc)
> return -ENOMEM;
>
> - nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> - if (!nbuf->ecccalc) {
> + chip->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
> + if (!chip->ecccode) {
> ret = -ENOMEM;
> goto err_free_nbuf;
> }
Hm, again not directly related to this patch, but I wonder if we
couldn't allocate those buffers only when they are really needed. For
example, most NAND controllers do the ECC calculation/correct in HW and
simply don't need those buffers.
Regards,
Boris
>
> - nbuf->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
> - if (!nbuf->ecccode) {
> - ret = -ENOMEM;
> - goto err_free_nbuf;
> - }
> -
> - nbuf->databuf = kmalloc(mtd->writesize + mtd->oobsize,
> + chip->databuf = kmalloc(mtd->writesize + mtd->oobsize,
> GFP_KERNEL);
> - if (!nbuf->databuf) {
> + if (!chip->databuf) {
> ret = -ENOMEM;
> goto err_free_nbuf;
> }
> -
> - chip->buffers = nbuf;
> - } else if (!chip->buffers) {
> + } else if (!chip->databuf) {
> return -ENOMEM;
> }
>
> @@ -4688,7 +4679,7 @@ int nand_scan_tail(struct mtd_info *mtd)
> goto err_free_nbuf;
>
> /* Set the internal oob buffer location, just after the page data */
> - chip->oob_poi = chip->buffers->databuf + mtd->writesize;
> + chip->oob_poi = chip->databuf + mtd->writesize;
>
> /*
> * If no default placement scheme is given, select an appropriate one.
> @@ -4975,12 +4966,9 @@ int nand_scan_tail(struct mtd_info *mtd)
> nand_manufacturer_cleanup(chip);
>
> err_free_nbuf:
> - if (nbuf) {
> - kfree(nbuf->databuf);
> - kfree(nbuf->ecccode);
> - kfree(nbuf->ecccalc);
> - kfree(nbuf);
> - }
> + kfree(chip->databuf);
> + kfree(chip->ecccode);
> + kfree(chip->ecccalc);
>
> return ret;
> }
> @@ -5032,11 +5020,10 @@ void nand_cleanup(struct nand_chip *chip)
>
> /* Free bad block table memory */
> kfree(chip->bbt);
> - if (!(chip->options & NAND_OWN_BUFFERS) && chip->buffers) {
> - kfree(chip->buffers->databuf);
> - kfree(chip->buffers->ecccode);
> - kfree(chip->buffers->ecccalc);
> - kfree(chip->buffers);
> + if (!(chip->options & NAND_OWN_BUFFERS)) {
> + kfree(chip->databuf);
> + kfree(chip->ecccode);
> + kfree(chip->ecccalc);
> }
>
> /* Free bad block descriptor memory */
> diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
> index 2915b67..53acc4a 100644
> --- a/drivers/mtd/nand/nand_bbt.c
> +++ b/drivers/mtd/nand/nand_bbt.c
> @@ -898,7 +898,7 @@ static inline int nand_memory_bbt(struct mtd_info *mtd, struct nand_bbt_descr *b
> {
> struct nand_chip *this = mtd_to_nand(mtd);
>
> - return create_bbt(mtd, this->buffers->databuf, bd, -1);
> + return create_bbt(mtd, this->databuf, bd, -1);
> }
>
> /**
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index dad438c..7870cb1 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1530,7 +1530,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> const uint8_t *buf, int oob_required, int page)
> {
> int ret;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_calc = chip->ecccalc;
>
> /* Enable GPMC ecc engine */
> chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
> @@ -1568,7 +1568,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> u32 data_len, const u8 *buf,
> int oob_required, int page)
> {
> - u8 *ecc_calc = chip->buffers->ecccalc;
> + u8 *ecc_calc = chip->ecccalc;
> int ecc_size = chip->ecc.size;
> int ecc_bytes = chip->ecc.bytes;
> int ecc_steps = chip->ecc.steps;
> @@ -1605,7 +1605,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
>
> /* copy calculated ECC for whole page to chip->buffer->oob */
> /* this include masked-value(0xFF) for unwritten subpages */
> - ecc_calc = chip->buffers->ecccalc;
> + ecc_calc = chip->ecccalc;
> ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
> chip->ecc.total);
> if (ret)
> @@ -1635,8 +1635,8 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> uint8_t *buf, int oob_required, int page)
> {
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> int stat, ret;
> unsigned int max_bitflips = 0;
>
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 82244be..a487be5 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -1544,7 +1544,7 @@ static int sunxi_nfc_hw_common_ecc_read_oob(struct mtd_info *mtd,
>
> chip->pagebuf = -1;
>
> - return chip->ecc.read_page(mtd, chip, chip->buffers->databuf, 1, page);
> + return chip->ecc.read_page(mtd, chip, chip->databuf, 1, page);
> }
>
> static int sunxi_nfc_hw_common_ecc_write_oob(struct mtd_info *mtd,
> @@ -1557,8 +1557,8 @@ static int sunxi_nfc_hw_common_ecc_write_oob(struct mtd_info *mtd,
>
> chip->pagebuf = -1;
>
> - memset(chip->buffers->databuf, 0xff, mtd->writesize);
> - ret = chip->ecc.write_page(mtd, chip, chip->buffers->databuf, 1, page);
> + memset(chip->databuf, 0xff, mtd->writesize);
> + ret = chip->ecc.write_page(mtd, chip, chip->databuf, 1, page);
> if (ret)
> return ret;
>
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 749bb08..75bf28d 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -608,21 +608,6 @@ static inline int nand_standard_page_accessors(struct nand_ecc_ctrl *ecc)
> }
>
> /**
> - * struct nand_buffers - buffer structure for read/write
> - * @ecccalc: buffer pointer for calculated ECC, size is oobsize.
> - * @ecccode: buffer pointer for ECC read from flash, size is oobsize.
> - * @databuf: buffer pointer for data, size is (page size + oobsize).
> - *
> - * Do not change the order of buffers. databuf and oobrbuf must be in
> - * consecutive order.
> - */
> -struct nand_buffers {
> - uint8_t *ecccalc;
> - uint8_t *ecccode;
> - uint8_t *databuf;
> -};
> -
> -/**
> * struct nand_sdr_timings - SDR NAND chip timings
> *
> * This struct defines the timing requirements of a SDR NAND chip.
> @@ -790,7 +775,9 @@ struct nand_manufacturer_ops {
> * @setup_read_retry: [FLASHSPECIFIC] flash (vendor) specific function for
> * setting the read-retry mode. Mostly needed for MLC NAND.
> * @ecc: [BOARDSPECIFIC] ECC control structure
> - * @buffers: buffer structure for read/write
> + * @ecccalc: buffer pointer for calculated ECC, size is oobsize.
> + * @ecccode: buffer pointer for ECC read from flash, size is oobsize.
> + * @databuf: buffer pointer for data, size is (page size + oobsize).
> * @buf_align: minimum buffer alignment required by a platform
> * @hwcontrol: platform-specific hardware control structure
> * @erase: [REPLACEABLE] erase function
> @@ -938,7 +925,9 @@ struct nand_chip {
> struct nand_hw_control *controller;
>
> struct nand_ecc_ctrl ecc;
> - struct nand_buffers *buffers;
> + u8 *ecccalc;
> + u8 *ecccode;
> + u8 *databuf;
> unsigned long buf_align;
> struct nand_hw_control hwcontrol;
>
^ permalink raw reply
* [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls
From: Ard Biesheuvel @ 2017-12-04 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171202135952.GX3326@worktop>
On 2 December 2017 at 13:59, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, Dec 02, 2017 at 11:15:14AM +0000, Ard Biesheuvel wrote:
>> On 2 December 2017 at 09:11, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> > They consume the entire input in a single go, yes. But making it more
>> > granular than that is going to hurt performance, unless we introduce
>> > some kind of kernel_neon_yield(), which does a end+begin but only if
>> > the task is being scheduled out.
>> >
>> > For example, the SHA256 keeps 256 bytes of round constants in NEON
>> > registers, and reloading those from memory for each 64 byte block of
>> > input is going to be noticeable. The same applies to the AES code
>> > (although the numbers are slightly different)
>>
>> Something like below should do the trick I think (apologies for the
>> patch soup). I.e., check TIF_NEED_RESCHED at a point where only very
>> few NEON registers are live, and preserve/restore the live registers
>> across calls to kernel_neon_end + kernel_neon_begin. Would that work
>> for RT?
>
> Probably yes. The important point is that preempt latencies (and thus by
> extension NEON regions) are bounded and preferably small.
>
> Unbounded stuff (like depends on the amount of data fed) are a complete
> no-no for RT since then you cannot make predictions on how long things
> will take.
>
OK, that makes sense. But I do wonder what the parameters should be here.
For instance, the AES instructions on ARMv8 operate at <1 cycle per
byte, and so checking the TIF_NEED_RESCHED flag for every iteration of
the inner loop (i.e., every 64 bytes ~ 64 cycles) is clearly going to
be noticeable, and is probably overkill. The pure NEON version (which
is instantiated from the same block mode wrappers) uses ~25 cycles per
byte, and the bit sliced NEON version runs at ~20 cycles per byte but
can only operate at 8 blocks (128 bytes) at a time.
So rather than simply polling the bit@each iteration of the inner
loop in each algorithm, I'd prefer to aim for a ballpark number of
cycles to execute, in the order 1000 - 2000. Would that be OK or too
coarse?
^ 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