* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Herbert Xu @ 2016-12-08 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207125127.GB28218@Red>
On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
>
> So I must expose it as a crypto_rng ?
If it is to be exposed at all then algif_rng would be the best
place.
> Could you explain why PRNG must not be used as hw_random ?
The hwrng interface was always meant to be an interface for real
hardware random number generators. People rely on that so we
should not provide bogus entropy sources through this interface.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] drm: hdlcd: Work properly in big-endian mode
From: Daniel Vetter @ 2016-12-08 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKb7UvhNx_OPqXS4wKj59ReRaQ4jkY7YJ4KfvVKj0DUniFjrGw@mail.gmail.com>
On Wed, Dec 07, 2016 at 07:16:30PM -0500, Ilia Mirkin wrote:
> On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> > By comparison, the same use-cases (fbcon and fb-test) under the same
> > big-endian kernel do *not* show the same problem with nouveau driving a
> > PCIe 7600GT card, which led me to believe it was HDLCD-specific.
>
> Just to randomly insert info here... NV11+ cards have a "big endian"
> mode, where you can do 32-bit mmio from a big-endian cpu, and the card
> will auto-swap those. There are similar additional bits that make
> operating and accelerating off a big-endian CPU tolerable. Some care
> has gone into the kernel to make sure that all that stuff works. (One
> of those bits is that data gets byteswapped on upload to VRAM by
> virtue of being uploaded by sticking data into a pushbuf, as I
> recall.)
But on the kms side nouveau.ko doesn't inform userspace that it's taking
big-endian buffers? That seems to be the crux here - should we auto-endian
gpus to the cpu's endianess (might not work everywhere, but probably
bigger chance that it works on gpus which do have endian control). Or
should we start enforcing the explicit DRM_FORMAT_BIG_ENDIAN flag?
If we opt for the former I really think we should nuke the endianess
indicator. Atm it seems entirely unused (at least in drivers), so that's
probably the right choice.
Plus updating docs ofc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation
From: Ryder Lee @ 2016-12-08 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b0df417-825f-65c6-4c02-85fe1c20ce50@gmail.com>
Hello,
On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote:
>
> On 05/12/16 08:01, Ryder Lee wrote:
> > Add DT bindings documentation for the crypto driver
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
> > 1 file changed, 32 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> > new file mode 100644
> > index 0000000..8b1db08
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
> > @@ -0,0 +1,32 @@
> > +MediaTek cryptographic accelerators
> > +
> > +Required properties:
> > +- compatible: Should be "mediatek,mt7623-crypto"
>
> Do you know how big the difference is between the crypto engine for
> mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
> Do this SoCs have a crypot engine? If so and they are quite similar, we
> might think of adding a mtk-crypto binding and add soc specific bindings.
This engine is just available in mt7623/mt2701/mt8521p series SoCs and
they have no difference.
But there are still other crypto IPs in MTK, i think maybe we could use
"mediatek,{IP name}-crypto? to distinguish them ?
> Regards,
> Matthias
>
> > +- reg: Address and length of the register set for the device
> > +- interrupts: Should contain the five crypto engines interrupts in numeric
> > + order. These are global system and four descriptor rings.
> > +- clocks: the clock used by the core
> > +- clock-names: the names of the clock listed in the clocks property. These are
> > + "ethif", "cryp"
> > +- power-domains: Must contain a reference to the PM domain.
> > +
> > +
> > +Optional properties:
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > + that services interrupts for this device
> > +
> > +
> > +Example:
> > + crypto: crypto at 1b240000 {
> > + compatible = "mediatek,mt7623-crypto";
> > + reg = <0 0x1b240000 0 0x20000>;
> > + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>,
> > + <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
> > + <ðsys CLK_ETHSYS_CRYPTO>;
> > + clock-names = "ethif","cryp";
> > + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
> > + };
> >
^ permalink raw reply
* [PATCH 0/5] arm64: dts: ls1012a: add the DTS node for QSPI/DSPI support
From: Yuan Yao @ 2016-12-08 9:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Yuan Yao <yao.yuan@nxp.com>
LS1012A also support QSPI and DSPI.
This patch set is used to add the QSPI/DSPI node for LS1012A.
This patch set is depend on the patch for add LS1012A platform dts support:
arm64: Add DTS support for FSL's LS1012A SoC
The patchwork link:
https://patchwork.kernel.org/patch/9462399/
Yuan Yao (5):
arm64: dts: ls1012a: add the DTS node for DSPI support
Documentation: fsl: dspi: Add fsl,ls1012a-dspi compatible string
Documentation: dt: mtd: add chip support for "jedec, spi-nor"
arm64: dts: ls1012a: add the DTS node for QSPI support
Documentation: fsl-quadspi: Add fsl,ls1012a-qspi compatible string
.../devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
.../devicetree/bindings/mtd/jedec,spi-nor.txt | 2 +
.../devicetree/bindings/spi/spi-fsl-dspi.txt | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 14 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 48 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 15 +++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 28 +++++++++++++
7 files changed, 109 insertions(+)
--
2.1.0.27.g96db324
^ permalink raw reply
* [PATCH 1/5] arm64: dts: ls1012a: add the DTS node for DSPI support
From: Yuan Yao @ 2016-12-08 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188984-43683-1-git-send-email-yao.yuan@freescale.com>
From: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 33 +++++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 13 +++++++++
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index b841251..3d32c76 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -93,6 +93,39 @@
};
};
+&dspi {
+ bus-num = <0>;
+ status = "okay";
+
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a11", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+
+ flash at 1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "sst25wf040b", "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <1>;
+ spi-max-frequency = <10000000>;
+ };
+
+ flash at 2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "en25s64", "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <2>;
+ spi-max-frequency = <10000000>;
+ };
+};
+
&duart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 92e64f3..c917a87 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -148,6 +148,19 @@
status = "disabled";
};
+ dspi: dspi at 2100000 {
+ compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2100000 0x0 0x10000>;
+ interrupts = <0 64 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "dspi";
+ clocks = <&clockgen 4 0>;
+ spi-num-chipselects = <5>;
+ big-endian;
+ status = "disabled";
+ };
+
duart0: serial at 21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x00 0x21c0500 0x0 0x100>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 2/5] Documentation: fsl: dspi: Add fsl, ls1012a-dspi compatible string
From: Yuan Yao @ 2016-12-08 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188984-43683-1-git-send-email-yao.yuan@freescale.com>
From: Yuan Yao <yao.yuan@nxp.com>
new compatible string: "fsl,ls1012a-dspi".
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index ff5893d..800c483 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -5,6 +5,7 @@ Required properties:
"fsl,ls2085a-dspi"
or
"fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
+ "fsl,ls1012a-dspi" followed by "fsl,ls1021a-v1.0-dspi"
- reg : Offset and length of the register set for the device
- interrupts : Should contain SPI controller interrupt
- clocks: from common clock binding: handle to dspi clock.
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 3/5] Documentation: dt: mtd: add chip support for "jedec, spi-nor"
From: Yuan Yao @ 2016-12-08 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188984-43683-1-git-send-email-yao.yuan@freescale.com>
From: Yuan Yao <yao.yuan@nxp.com>
"sst25wf040b" and "en25s64" are also chip compatible with SPI NOR flash.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
index 2c91c03..86614ee 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
@@ -13,6 +13,7 @@ Required properties:
at25df321a
at25df641
at26df081a
+ en25s64
mr25h256
mx25l4005a
mx25l1606e
@@ -29,6 +30,7 @@ Required properties:
s25fl008k
s25fl064k
sst25vf040b
+ sst25wf040b
m25p40
m25p80
m25p16
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ls1012a: add the DTS node for QSPI support
From: Yuan Yao @ 2016-12-08 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188984-43683-1-git-send-email-yao.yuan@freescale.com>
From: Yuan Yao <yao.yuan@nxp.com>
There is a s25fs512s qspi flash on QDS, RDB and FRDM board.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 14 ++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 15 +++++++++++++++
4 files changed, 59 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
index 81bd689..34f9e76 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
@@ -110,6 +110,20 @@
};
};
+&qspi {
+ num-cs = <2>;
+ bus-num = <0>;
+ status = "okay";
+
+ qflash0: s25fs512s at 0 {
+ compatible = "spansion,m25p80";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
&sai2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index 3d32c76..0e5befa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -156,6 +156,21 @@
};
};
+&qspi {
+ num-cs = <2>;
+ bus-num = <0>;
+ status = "okay";
+
+ qflash0: s25fs512s at 0 {
+ compatible = "spansion,m25p80";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ m25p,fast-read;
+ reg = <0>;
+ };
+};
+
&sai2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 62c5c71..c20bfd3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -57,3 +57,18 @@
&i2c0 {
status = "okay";
};
+
+&qspi {
+ num-cs = <2>;
+ bus-num = <0>;
+ status = "okay";
+
+ qflash0: s25fs512s at 0 {
+ compatible = "spansion,m25p80";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ m25p,fast-read;
+ reg = <0>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index c917a87..72e61c5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -195,6 +195,21 @@
#interrupt-cells = <2>;
};
+ qspi: quadspi at 1550000 {
+ compatible = "fsl,ls1012a-qspi", "fsl,ls1021a-qspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x1550000 0x0 0x10000>,
+ <0x0 0x40000000 0x0 0x10000000>;
+ reg-names = "QuadSPI", "QuadSPI-memory";
+ interrupts = <0 99 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "qspi_en", "qspi";
+ clocks = <&clockgen 4 0>, <&clockgen 4 0>;
+ big-endian;
+ fsl,qspi-has-second-chip;
+ status = "disabled";
+ };
+
wdog0: wdog at 2ad0000 {
compatible = "fsl,ls1012a-wdt",
"fsl,imx21-wdt";
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string
From: Yuan Yao @ 2016-12-08 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188984-43683-1-git-send-email-yao.yuan@freescale.com>
From: Yuan Yao <yao.yuan@nxp.com>
new compatible string: "fsl,ls1012a-qspi".
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index c34aa6f..a2ed621 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -7,6 +7,7 @@ Required properties:
or
"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
"fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
+ "fsl,ls1012a-qspi" followed by "fsl,ls1021a-qspi"
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-12-08 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208090618.GB22932@gondor.apana.org.au>
On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> >
> > So I must expose it as a crypto_rng ?
>
> If it is to be exposed at all then algif_rng would be the best
> place.
>
I have badly said my question.
So I need to use the HW PRNG in a crypto_rng "provider" that could be thereafter used from user space via algif_rng. right ?
> > Could you explain why PRNG must not be used as hw_random ?
>
> The hwrng interface was always meant to be an interface for real
> hardware random number generators. People rely on that so we
> should not provide bogus entropy sources through this interface.
>
Why not adding a KCONFIG HW_RANDOM_ACCEPT_ALSO_PRNG with big warning ?
Or a HW_PRNG Kconfig which do the same than hwrandom with /dev/prng ?
With that it will be much easier to convert in-tree PRNG that you want to remove.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH 1/2] dt-bindings: zx296718-clk: add compatible for audio clock controller
From: Shawn Guo @ 2016-12-08 9:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Shawn Guo <shawn.guo@linaro.org>
It adds the compatible string for zx296718 audio clock controller.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Documentation/devicetree/bindings/clock/zx296718-clk.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/zx296718-clk.txt b/Documentation/devicetree/bindings/clock/zx296718-clk.txt
index 8c18b7b237bf..4ad703808407 100644
--- a/Documentation/devicetree/bindings/clock/zx296718-clk.txt
+++ b/Documentation/devicetree/bindings/clock/zx296718-clk.txt
@@ -13,6 +13,9 @@ Required properties:
"zte,zx296718-lsp1crm":
zx296718 device level clock selection and gating
+ "zte,zx296718-audiocrm":
+ zx296718 audio clock selection, divider and gating
+
- reg: Address and length of the register set
The clock consumer should specify the desired clock by having the clock
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] clk: zte: add audio clocks for zx296718
From: Shawn Guo @ 2016-12-08 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481189157-8995-1-git-send-email-shawnguo@kernel.org>
From: Jun Nie <jun.nie@linaro.org>
The audio related clock support is missing from the existing zx296718
clock driver. Let's add it, so that the upstream ZX SPDIF driver can
work for HDMI audio support.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/clk/zte/clk-zx296718.c | 150 +++++++++++++++++++++++++++++++++++++++++
drivers/clk/zte/clk.c | 149 ++++++++++++++++++++++++++++++++++++++++
drivers/clk/zte/clk.h | 28 ++++++++
3 files changed, 327 insertions(+)
diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index 707d62956e9b..eed8581b1b25 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -888,10 +888,160 @@ static int __init lsp1_clocks_init(struct device_node *np)
return 0;
}
+PNAME(audio_wclk_common_p) = {
+ "audio_99m",
+ "audio_24m",
+};
+
+PNAME(audio_timer_p) = {
+ "audio_24m",
+ "audio_32k",
+};
+
+static struct zx_clk_mux audio_mux_clk[] = {
+ MUX(0, "i2s0_wclk_mux", audio_wclk_common_p, AUDIO_I2S0_CLK, 0, 1),
+ MUX(0, "i2s1_wclk_mux", audio_wclk_common_p, AUDIO_I2S1_CLK, 0, 1),
+ MUX(0, "i2s2_wclk_mux", audio_wclk_common_p, AUDIO_I2S2_CLK, 0, 1),
+ MUX(0, "i2s3_wclk_mux", audio_wclk_common_p, AUDIO_I2S3_CLK, 0, 1),
+ MUX(0, "i2c0_wclk_mux", audio_wclk_common_p, AUDIO_I2C0_CLK, 0, 1),
+ MUX(0, "spdif0_wclk_mux", audio_wclk_common_p, AUDIO_SPDIF0_CLK, 0, 1),
+ MUX(0, "spdif1_wclk_mux", audio_wclk_common_p, AUDIO_SPDIF1_CLK, 0, 1),
+ MUX(0, "timer_wclk_mux", audio_timer_p, AUDIO_TIMER_CLK, 0, 1),
+};
+
+struct zx_clk_audio_div_table i2s_wclk_div_table[] = {
+ {2048000, 0x3000030, 0xffff5700},
+ {4096000, 0x3000018, 0xffff2b80},
+ {2822400, 0x3000011, 0xffff89cb},
+ {3072000, 0x3000010, 0xffff1d00},
+ {4096000, 0x300000c, 0xffff15c0},
+ {5644800, 0x3000008, 0xffffc4e5},
+ {6144000, 0x3000008, 0xffff0e80},
+ {11289600, 0x3000004, 0xffff6273},
+ {12288000, 0x3000004, 0xffff0740},
+ {22579200, 0x3000002, 0xffff3139},
+ {24576000, 0x3000002, 0xffff03a0},
+};
+
+struct zx_clk_audio_div_table spdif_wclk_div_table[] = {
+ {2822400, 0x00023, 0xffff1397},
+ {3072000, 0x00020, 0xffff3a00},
+ {4096000, 0x00018, 0xffff2b80},
+ {5644800, 0x00011, 0xffff89cb},
+ {6144000, 0x00010, 0xffff1d00},
+ {11289600, 0x00008, 0xffffc4e5},
+ {12288000, 0x00008, 0xffff0e80},
+ {22579200, 0x00004, 0xffff6273},
+ {24576000, 0x00004, 0xffff0740},
+};
+
+struct clk_zx_audio_divider audio_adiv_clk[] = {
+ AUDIO_DIV(0, "i2s0_wclk_div", "i2s0_wclk_mux", AUDIO_I2S0_DIV_CFG1, i2s_wclk_div_table),
+ AUDIO_DIV(0, "i2s1_wclk_div", "i2s1_wclk_mux", AUDIO_I2S1_DIV_CFG1, i2s_wclk_div_table),
+ AUDIO_DIV(0, "i2s2_wclk_div", "i2s2_wclk_mux", AUDIO_I2S2_DIV_CFG1, i2s_wclk_div_table),
+ AUDIO_DIV(0, "i2s3_wclk_div", "i2s3_wclk_mux", AUDIO_I2S3_DIV_CFG1, i2s_wclk_div_table),
+ AUDIO_DIV(0, "spdif0_wclk_div", "spdif0_wclk_mux", AUDIO_SPDIF0_DIV_CFG1, spdif_wclk_div_table),
+ AUDIO_DIV(0, "spdif1_wclk_div", "spdif1_wclk_mux", AUDIO_SPDIF1_DIV_CFG1, spdif_wclk_div_table),
+};
+
+struct zx_clk_div audio_div_clk[] = {
+ DIV_T(0, "tdm_wclk_div", "audio_16m384", AUDIO_TDM_CLK, 8, 4, 0, common_div_table),
+};
+
+struct zx_clk_gate audio_gate_clk[] = {
+ GATE(AUDIO_I2S0_WCLK, "i2s0_wclk", "i2s0_wclk_div", AUDIO_I2S0_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_I2S1_WCLK, "i2s1_wclk", "i2s1_wclk_div", AUDIO_I2S1_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_I2S2_WCLK, "i2s2_wclk", "i2s2_wclk_div", AUDIO_I2S2_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_I2S3_WCLK, "i2s3_wclk", "i2s3_wclk_div", AUDIO_I2S3_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_I2C0_WCLK, "i2c0_wclk", "i2c0_wclk_mux", AUDIO_I2C0_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_SPDIF0_WCLK, "spdif0_wclk", "spdif0_wclk_div", AUDIO_SPDIF0_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_SPDIF1_WCLK, "spdif1_wclk", "spdif1_wclk_div", AUDIO_SPDIF1_CLK, 9, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_TDM_WCLK, "tdm_wclk", "tdm_wclk_div", AUDIO_TDM_CLK, 17, CLK_SET_RATE_PARENT, 0),
+ GATE(AUDIO_TS_PCLK, "tempsensor_pclk", "clk49m5", AUDIO_TS_CLK, 1, 0, 0),
+};
+
+static struct clk_hw_onecell_data audio_hw_onecell_data = {
+ .num = AUDIO_NR_CLKS,
+ .hws = {
+ [AUDIO_NR_CLKS - 1] = NULL,
+ },
+};
+
+static int __init audio_clocks_init(struct device_node *np)
+{
+ void __iomem *reg_base;
+ int i, ret;
+
+ reg_base = of_iomap(np, 0);
+ if (!reg_base) {
+ pr_err("%s: Unable to map audio clk base\n", __func__);
+ return -ENXIO;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(audio_mux_clk); i++) {
+ if (audio_mux_clk[i].id)
+ audio_hw_onecell_data.hws[audio_mux_clk[i].id] =
+ &audio_mux_clk[i].mux.hw;
+
+ audio_mux_clk[i].mux.reg += (u64)reg_base;
+ ret = clk_hw_register(NULL, &audio_mux_clk[i].mux.hw);
+ if (ret) {
+ pr_warn("audio clk %s init error!\n",
+ audio_mux_clk[i].mux.hw.init->name);
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(audio_adiv_clk); i++) {
+ if (audio_adiv_clk[i].id)
+ audio_hw_onecell_data.hws[audio_adiv_clk[i].id] =
+ &audio_adiv_clk[i].hw;
+
+ audio_adiv_clk[i].reg_base += (u64)reg_base;
+ ret = clk_hw_register(NULL, &audio_adiv_clk[i].hw);
+ if (ret) {
+ pr_warn("audio clk %s init error!\n",
+ audio_adiv_clk[i].hw.init->name);
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(audio_div_clk); i++) {
+ if (audio_div_clk[i].id)
+ audio_hw_onecell_data.hws[audio_div_clk[i].id] =
+ &audio_div_clk[i].div.hw;
+
+ audio_div_clk[i].div.reg += (u64)reg_base;
+ ret = clk_hw_register(NULL, &audio_div_clk[i].div.hw);
+ if (ret) {
+ pr_warn("audio clk %s init error!\n",
+ audio_div_clk[i].div.hw.init->name);
+ }
+ }
+
+ for (i = 0; i < ARRAY_SIZE(audio_gate_clk); i++) {
+ if (audio_gate_clk[i].id)
+ audio_hw_onecell_data.hws[audio_gate_clk[i].id] =
+ &audio_gate_clk[i].gate.hw;
+
+ audio_gate_clk[i].gate.reg += (u64)reg_base;
+ ret = clk_hw_register(NULL, &audio_gate_clk[i].gate.hw);
+ if (ret) {
+ pr_warn("audio clk %s init error!\n",
+ audio_gate_clk[i].gate.hw.init->name);
+ }
+ }
+
+ if (of_clk_add_hw_provider(np, of_clk_hw_onecell_get, &audio_hw_onecell_data))
+ panic("could not register clk provider\n");
+ pr_info("audio-clk init over, nr:%d\n", AUDIO_NR_CLKS);
+
+ return 0;
+}
+
static const struct of_device_id zx_clkc_match_table[] = {
{ .compatible = "zte,zx296718-topcrm", .data = &top_clocks_init },
{ .compatible = "zte,zx296718-lsp0crm", .data = &lsp0_clocks_init },
{ .compatible = "zte,zx296718-lsp1crm", .data = &lsp1_clocks_init },
+ { .compatible = "zte,zx296718-audiocrm", .data = &audio_clocks_init },
{ }
};
diff --git a/drivers/clk/zte/clk.c b/drivers/clk/zte/clk.c
index c4c1251bc1e7..ea97024b37aa 100644
--- a/drivers/clk/zte/clk.c
+++ b/drivers/clk/zte/clk.c
@@ -9,6 +9,7 @@
#include <linux/clk-provider.h>
#include <linux/err.h>
+#include <linux/gcd.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/slab.h>
@@ -310,3 +311,151 @@ struct clk *clk_register_zx_audio(const char *name,
return clk;
}
+
+#define CLK_AUDIO_DIV_FRAC BIT(0)
+#define CLK_AUDIO_DIV_INT BIT(1)
+#define CLK_AUDIO_DIV_UNCOMMON BIT(1)
+
+#define CLK_AUDIO_DIV_FRAC_NSHIFT 16
+#define CLK_AUDIO_DIV_INT_FRAC_RE BIT(16)
+#define CLK_AUDIO_DIV_INT_FRAC_MAX (0xffff)
+#define CLK_AUDIO_DIV_INT_FRAC_MIN (0x2)
+#define CLK_AUDIO_DIV_INT_INT_SHIFT 24
+#define CLK_AUDIO_DIV_INT_INT_WIDTH 4
+
+#define to_clk_zx_audio_div(_hw) container_of(_hw, struct clk_zx_audio_divider, hw)
+
+static unsigned long audio_calc_rate(struct clk_zx_audio_divider *audio_div,
+ u32 reg_frac, u32 reg_int,
+ unsigned long parent_rate)
+{
+ unsigned long rate, m, n;
+
+ if (audio_div->table) {
+ const struct zx_clk_audio_div_table *divt = audio_div->table;
+
+ for (; divt->rate; divt++) {
+ if ((divt->int_reg == reg_int) && (divt->frac_reg == reg_frac))
+ return divt->rate;
+ }
+ }
+ if (audio_div->table)
+ pr_warn("cannot found the config(int_reg:0x%x, frac_reg:0x%x) in table, we will caculate it\n",
+ reg_int, reg_frac);
+
+ m = reg_frac & 0xffff;
+ n = (reg_frac >> 16) & 0xffff;
+
+ m = (reg_int & 0xffff) * n + m;
+ rate = (parent_rate * n) / m;
+
+ return rate;
+}
+
+static void audio_calc_reg(struct clk_zx_audio_divider *audio_div,
+ struct zx_clk_audio_div_table *div_table,
+ unsigned long rate, unsigned long parent_rate)
+{
+ unsigned int reg_int, reg_frac;
+ unsigned long m, n, div;
+
+ if (audio_div->table) {
+ const struct zx_clk_audio_div_table *divt = audio_div->table;
+
+ for (; divt->rate; divt++) {
+ if (divt->rate == rate) {
+ div_table->rate = divt->rate;
+ div_table->int_reg = divt->int_reg;
+ div_table->frac_reg = divt->frac_reg;
+ return;
+ }
+ }
+ }
+ if (audio_div->table)
+ pr_warn("cannot found the rate(%ld) in table, we will caculate the config\n",
+ rate);
+
+ reg_int = parent_rate / rate;
+
+ if (reg_int > CLK_AUDIO_DIV_INT_FRAC_MAX)
+ reg_int = CLK_AUDIO_DIV_INT_FRAC_MAX;
+ else if (reg_int < CLK_AUDIO_DIV_INT_FRAC_MIN)
+ reg_int = 0;
+ m = parent_rate - rate * reg_int;
+ n = rate;
+
+ div = gcd(m, n);
+ m = m / div;
+ n = n / div;
+
+ if ((m >> 16) || (n >> 16)) {
+ if (m > n) {
+ n = n * 0xffff / m;
+ m = 0xffff;
+ } else {
+ m = m * 0xffff / n;
+ n = 0xffff;
+ }
+ }
+ reg_frac = m | (n << 16);
+
+ div_table->rate = (ulong)(parent_rate * n) / ((ulong)reg_int * n + m);
+ div_table->int_reg = reg_int;
+ div_table->frac_reg = reg_frac;
+}
+
+static unsigned long zx_audio_div_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_zx_audio_divider *zx_audio_div = to_clk_zx_audio_div(hw);
+ u32 reg_frac, reg_int;
+
+ reg_frac = readl_relaxed(zx_audio_div->reg_base);
+ reg_int = readl_relaxed(zx_audio_div->reg_base + 0x4);
+
+ return audio_calc_rate(zx_audio_div, reg_frac, reg_int, parent_rate);
+}
+
+static long zx_audio_div_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_zx_audio_divider *zx_audio_div = to_clk_zx_audio_div(hw);
+ struct zx_clk_audio_div_table divt;
+
+ audio_calc_reg(zx_audio_div, &divt, rate, *prate);
+
+ return audio_calc_rate(zx_audio_div, divt.frac_reg, divt.int_reg, *prate);
+}
+
+static int zx_audio_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_zx_audio_divider *zx_audio_div = to_clk_zx_audio_div(hw);
+ struct zx_clk_audio_div_table divt;
+ unsigned int val;
+
+ audio_calc_reg(zx_audio_div, &divt, rate, parent_rate);
+ if (divt.rate != rate)
+ pr_info("the real rate is:%ld", divt.rate);
+
+ writel_relaxed(divt.frac_reg, zx_audio_div->reg_base);
+
+ val = readl_relaxed(zx_audio_div->reg_base + 0x4);
+ val &= ~0xffff;
+ val |= divt.int_reg | CLK_AUDIO_DIV_INT_FRAC_RE;
+ writel_relaxed(val, zx_audio_div->reg_base + 0x4);
+
+ mdelay(1);
+
+ val = readl_relaxed(zx_audio_div->reg_base + 0x4);
+ val &= ~CLK_AUDIO_DIV_INT_FRAC_RE;
+ writel_relaxed(val, zx_audio_div->reg_base + 0x4);
+
+ return 0;
+}
+
+const struct clk_ops zx_audio_div_ops = {
+ .recalc_rate = zx_audio_div_recalc_rate,
+ .round_rate = zx_audio_div_round_rate,
+ .set_rate = zx_audio_div_set_rate,
+};
diff --git a/drivers/clk/zte/clk.h b/drivers/clk/zte/clk.h
index 0df3474b2cf3..6e7ccb752c24 100644
--- a/drivers/clk/zte/clk.h
+++ b/drivers/clk/zte/clk.h
@@ -153,6 +153,32 @@ struct zx_clk_div {
.id = _id, \
}
+struct zx_clk_audio_div_table {
+ unsigned long rate;
+ unsigned int int_reg;
+ unsigned int frac_reg;
+};
+
+struct clk_zx_audio_divider {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+ const struct zx_clk_audio_div_table *table;
+ unsigned int rate_count;
+ spinlock_t *lock;
+ u16 id;
+};
+
+#define AUDIO_DIV(_id, _name, _parent, _reg, _table) \
+{ \
+ .reg_base = (void __iomem *) _reg, \
+ .lock = &clk_lock, \
+ .hw.init = CLK_HW_INIT(_name, \
+ _parent, \
+ &zx_audio_div_ops, \
+ 0), \
+ .id = _id, \
+}
+
struct clk *clk_register_zx_pll(const char *name, const char *parent_name,
unsigned long flags, void __iomem *reg_base,
const struct zx_pll_config *lookup_table, int count, spinlock_t *lock);
@@ -167,4 +193,6 @@ struct clk *clk_register_zx_audio(const char *name,
unsigned long flags, void __iomem *reg_base);
extern const struct clk_ops zx_pll_ops;
+extern const struct clk_ops zx_audio_div_ops;
+
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Huang Shijie @ 2016-12-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207150237.GC31797@dhcp22.suse.cz>
On Wed, Dec 07, 2016 at 11:02:38PM +0800, Michal Hocko wrote:
> On Tue 06-12-16 18:03:59, Huang Shijie wrote:
> > On Mon, Dec 05, 2016 at 05:31:01PM +0800, Michal Hocko wrote:
> > > On Mon 05-12-16 17:17:07, Huang Shijie wrote:
> > > [...]
> > > > The failure is caused by:
> > > > 1) kernel fails to allocate a gigantic page for the surplus case.
> > > > And the gather_surplus_pages() will return NULL in the end.
> > > >
> > > > 2) The condition checks for some functions are wrong:
> > > > return_unused_surplus_pages()
> > > > nr_overcommit_hugepages_store()
> > > > hugetlb_overcommit_handler()
>add the > >
> > > OK, so how is this any different from gigantic (1G) hugetlb pages on
> > I think there is no different from gigantic (1G) hugetlb pages on
> > x86_64. Do anyone ever tested the 1G hugetlb pages in x86_64 with the "counter.sh"
> > before?
>
> I suspect nobody has because the gigantic page support is still somehow
> coarse and from a quick look into the code we only support pre-allocated
Yes, the x86_64 even does not support the gigantic page.
The default x86_64_defconfig does not enable the CONFIG_CMA.
I enabled the CONFIG_CMA, and did the test for gigantic page in x86_64.
(I appended "hugepagesz=1G hugepages=4" in the kernel cmdline.)
The result is got with my 16G x86_64 desktop:
-------------------------------------------------
counters.sh (1024M: 32): FAIL mmap failed: Cannot allocate memory
counters.sh (1024M: 64): PASS
********** TEST SUMMARY
* 1024M
* 32-bit 64-bit
* Total testcases: 1 1
* Skipped: 0 0
* PASS: 0 1
* FAIL: 1 0
* Killed by signal: 0 0
* Bad configuration: 0 0
* Expected FAIL: 0 0
* Unexpected PASS: 0 0
* Test not present: 0 0
* Strange test result: 0 0
**********
-------------------------------------------------
The test passes for 64bit, but fails for 32bit (but I think it's okay,
since 1G hugetlb page is too large for the 32bit).
> giga pages. In other words surplus pages and their accounting is not
> supported at all.
Yes.
>
> I haven't yet checked your patchset but I can tell you one thing.
Could you please review the patch set when you have time? Thanks a lot.
> Surplus and subpool pages code is tricky as hell. And it is not just a
Agree.
Do we really need so many accountings? such as reserve/ovorcommit/surplus.
> matter of teaching the huge page allocation code to do the right thing.
> There are subtle details all over the place. E.g. we currently
> do not free giga pages AFAICS. In fact I believe that the giga pages are
Please correct me if I am wrong. :)
I think the free-giga-pages can work well.
Please see the code in update_and_free_page().
Could you please list all the subtle details you think the code is wrong?
I can check them one by one.
> kind of implanted to the existing code without any higher level
> consistency. This should change long term. But I am worried it is much
What's type of the "higher level consistency" we should care about?
Thanks
Huang Shijie
> more work.
>
> Now I might be wrong because I might misremember things which might have
> been changed recently but please make sure you describe the current
> state and changes of giga pages when touching this area much better if
> you want to pursue this route...
>
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2016-12-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479215363-2898-1-git-send-email-eric.auger@redhat.com>
Hi,
On 15/11/2016 14:09, Eric Auger wrote:
> Following LPC discussions, we now report reserved regions through
> iommu-group sysfs reserved_regions attribute file.
While I am respinning this series into v4, here is a tentative summary
of technical topics for which no consensus was reached at this point.
1) Shall we report the usable IOVA range instead of reserved IOVA
ranges. Not discussed at/after LPC.
x I currently report reserved regions. Alex expressed the need to
report the full usable IOVA range instead (x86 min-max range
minus MSI APIC window). I think this is meaningful for ARM
too where arm-smmu might not support the full 64b range.
x Any objection we report the usable IOVA regions instead?
2) Shall the kernel check collision with MSI window* when userspace
calls VFIO_IOMMU_MAP_DMA?
Joerg/Will No; Alex yes
*for IOVA regions consumed downstream to the IOMMU: everyone says NO
3) RMRR reporting in the iommu group sysfs? Joerg: yes; Don: no
My current series does not expose them in iommu group sysfs.
I understand we can expose the RMRR regions in the iomm group sysfs
without necessarily supporting RMRR requiring device assignment.
We can also add this support later.
Thanks
Eric
>
> Reserved regions are populated through the IOMMU get_resv_region callback
> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
> arm-smmu.
>
> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
> IOMMU_RESV_NOMAP reserved region.
>
> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
> 1MB large) and the PCI host bridge windows.
>
> The series integrates a not officially posted patch from Robin:
> "iommu/dma: Allow MSI-only cookies".
>
> This series currently does not address IRQ safety assessment.
>
> Best Regards
>
> Eric
>
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>
> History:
> RFC v2 -> v3:
> - switch to an iommu-group sysfs API
> - use new dummy allocator provided by Robin
> - dummy allocator initialized by vfio-iommu-type1 after enumerating
> the reserved regions
> - at the moment ARM MSI base address/size is left unchanged compared
> to v2
> - we currently report reserved regions and not usable IOVA regions as
> requested by Alex
>
> RFC v1 -> v2:
> - fix intel_add_reserved_regions
> - add mutex lock/unlock in vfio_iommu_type1
>
>
> Eric Auger (10):
> iommu/dma: Allow MSI-only cookies
> iommu: Rename iommu_dm_regions into iommu_resv_regions
> iommu: Add new reserved IOMMU attributes
> iommu: iommu_alloc_resv_region
> iommu: Do not map reserved regions
> iommu: iommu_get_group_resv_regions
> iommu: Implement reserved_regions iommu-group sysfs file
> iommu/vt-d: Implement reserved region get/put callbacks
> iommu/arm-smmu: Implement reserved region get/put callbacks
> vfio/type1: Get MSI cookie
>
> drivers/iommu/amd_iommu.c | 20 +++---
> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
> drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++++-------
> drivers/iommu/intel-iommu.c | 50 ++++++++++----
> drivers/iommu/iommu.c | 141 ++++++++++++++++++++++++++++++++++++----
> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
> include/linux/dma-iommu.h | 7 ++
> include/linux/iommu.h | 49 ++++++++++----
> 8 files changed, 391 insertions(+), 70 deletions(-)
>
^ permalink raw reply
* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Michal Hocko @ 2016-12-08 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208093623.GA4551@sha-win-210.asiapac.arm.com>
On Thu 08-12-16 17:36:24, Huang Shijie wrote:
> On Wed, Dec 07, 2016 at 11:02:38PM +0800, Michal Hocko wrote:
[...]
> > I haven't yet checked your patchset but I can tell you one thing.
>
> Could you please review the patch set when you have time? Thanks a lot.
>From a quick glance you do not handle the reservation code at all. You
just make sure that the allocation doesn't fail unconditionally. I might
be wrong here and Naoya resp. Mike will know much better but this seems
far from enough to me.
>
> > Surplus and subpool pages code is tricky as hell. And it is not just a
> Agree.
>
> Do we really need so many accountings? such as reserve/ovorcommit/surplus.
If we want to make giga page the first class citizen then the whole
reservation/surplus code has to independent on the page size.
> > matter of teaching the huge page allocation code to do the right thing.
> > There are subtle details all over the place. E.g. we currently
> > do not free giga pages AFAICS. In fact I believe that the giga pages are
> Please correct me if I am wrong. :)
>
> I think the free-giga-pages can work well.
> Please see the code in update_and_free_page().
Hmm, I have missed that part. I guess you are right but I would have to
look much closer. Hugetlb code tends to be full of surprises.
> Could you please list all the subtle details you think the code is wrong?
> I can check them one by one.
Well, this would take me quite some time and basically restudy the whole
hugetlb code again. What you are trying to achieve is not a simple "fix
a test case" thing. You are trying to implement full featured giga pages
suport. And as I've said this requires a deeper understanding of the
current code and clean it up considerably wrt. giga pages. This is
definitely desirable plan longterm and I would like to encourage you for
that but it is not a simple project at the same time.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Nicolas Ferre @ 2016-12-08 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193908.GA13062@netboy>
Le 07/12/2016 ? 20:39, Richard Cochran a ?crit :
> On Wed, Dec 07, 2016 at 08:21:51PM +0200, Andrei Pistirica wrote:
>> +#ifdef CONFIG_MACB_USE_HWSTAMP
>> +void gem_ptp_init(struct net_device *ndev);
>> +void gem_ptp_remove(struct net_device *ndev);
>> +
>> +void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb);
>> +void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb);
>
> These are in the hot path, and so you should do the test before
> calling the global function, something like this:
>
> void gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb);
>
> static void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb)
> {
> if (!bp->hwts_tx_en)
> return;
> gem_ptp_txstamp(bp, skb);
> }
>
> Ditto for Rx.
Hi Richard,
So you mean that as the "global" function won't be "inlined" by the
compiler as the function is not "static" neither in the same file and
that the jump will be implemented anyway. And this even if the function
is only called at a single location...
This way, if we add a kind or accessors function like the one that you
propose, with the test in it, the branch prediction can play his role
without breaking the processor pipeline as the accessors function will
be inlined by the compiler: Am I right?
So, yes, makes sense. Thanks for the hint.
Regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/1] arm64: mm: add config options for page table configuration
From: Catalin Marinas @ 2016-12-08 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481139600-24455-2-git-send-email-scott.branden@broadcom.com>
On Wed, Dec 07, 2016 at 11:40:00AM -0800, Scott Branden wrote:
> Make MAX_PHYSMEM_BITS and SECTIONS_SIZE_BITS configurable by adding
> config options.
> Default to current settings currently defined in sparesmem.h.
> For systems wishing to save memory the config options can be overridden.
> Example, changing MAX_PHYSMEM_BITS from 48 to 36 at the same time as
> changing SECTION_SIZE_BITS from 30 to 26 frees 13MB of memory.
I'm not keen on such change, it's a big departure from the single Image
aims. I would rather reduce SECTION_SIZE_BITS permanently where
feasible, like in this patch:
http://lkml.kernel.org/r/1465821119-3384-1-git-send-email-jszhang at marvell.com
--
Catalin
^ permalink raw reply
* [PATCH 2/3] arm64: Work around Falkor erratum 1003
From: Catalin Marinas @ 2016-12-08 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207200028.4420-2-cov@codeaurora.org>
On Wed, Dec 07, 2016 at 03:00:26PM -0500, Christopher Covington wrote:
> From: Shanker Donthineni <shankerd@codeaurora.org>
>
> On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
> allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
> updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
> separately using a reserved ASID will ensure that there are no TLB entries
> with incorrect ASID after changing the the ASID.
>
> Pseudo code:
> write TTBRx_EL1[ASID] to a reserved value
> ISB
> write TTBRx_EL1[BADDR] to a desired value
> ISB
> write TTBRx_EL1[ASID] to a desired value
> ISB
While the new ASID probably won't have incorrect TLB entries, the
reserved ASID will have random entries from all over the place. That's
because in step 1 you change the ASID to the reserved one while leaving
the old BADDR in place. There is a brief time before changing the ASID
when speculative page table walks will populate the TLB with entries
tagged with the reserved ASID. Such entries are never removed during TLB
shoot-down for the real ASID, so, depending on how this CPU implements
the walk cache, you could end up with intermediate level entries still
active and pointing to freed/reused pages. It will eventually hit an
entry that looks global with weird consequences.
We've been bitten by this in the past on arm32: 52af9c6cd863 ("ARM:
6943/1: mm: use TTBR1 instead of reserved context ID").
--
Catalin
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-08 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xvauv1yew.fsf@unicorn.mansr.com>
On Wed, Dec 07, 2016 at 04:44:55PM +0000, M?ns Rullg?rd wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
> >>
> >> What you're proposing, Vinod, is to make a channel exclusive
> >> to a driver, as long as the driver has not explicitly released
> >> the channel, via dma_release_channel(), right?
> >
> > Precisely, but yes the downside of that is concurrent access are
> > limited, but am not sure if driver implements virtual channels and
> > allows that..
>
> My driver implements virtual channels. The problem is that the physical
> dma channels signal completion slightly too soon, at least with
> mem-to-device transfers. Apparently we need to keep the sbox routing
> until the peripheral indicates that it has actually received all the
> data.
So do we need concurrent accesses by all clients.
--
~Vinod
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-08 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xr35j1yd5.fsf@unicorn.mansr.com>
On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
>
> > On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
> >>
> >> That's not going to work very well. Device drivers typically request
> >> dma channels in their probe functions or when the device is opened.
> >> This means that reserving one of the few channels there will inevitably
> >> make some other device fail to operate.
> >
> > No that doesnt make sense at all, you should get a channel only when you
> > want to use it and not in probe!
>
> Tell that to just about every single driver ever written.
Not really, few do yes which is wrong but not _all_ do that.
--
~Vinod
^ permalink raw reply
* crypto regression?
From: Cyrille Pitchen @ 2016-12-08 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi Herbert,
Let me report a potential regression I've noticed this morning when testing
linux-next.
I've set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n when compiling both kernel
images.
On 4.9.0-rc2-next-20161028, /proc/crypto displays:
driver : atmel-xts-aes
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
and no output from the test manager in the boot log.
Whereas on 4.9.0-rc8-next-20161208, we get:
driver : atmel-xts-aes
module : kernel
priority : 300
refcnt : 1
selftest : unknown
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
Also I see the following traces during the boot:
alg: skcipher: Chunk test 1 failed on encryption at page 0 for atmel-xts-aes
00000000: 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b
00000010: ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b
00000020: 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44
00000030: 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd
00000040: 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70
00000050: aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0
00000060: c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75
00000070: 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca
00000080: 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d
00000090: e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0
000000a0: b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34
000000b0: f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f
000000c0: 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a
000000d0: 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec
000000e0: 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6
000000f0: dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a
00000100: 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f
00000110: bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1
00000120: 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84
00000130: f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae
00000140: 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b
00000150: 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29
00000160: a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52
00000170: 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac
00000180: 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0
00000190: dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f
000001a0: 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93
000001b0: c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85
000001c0: 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a
000001d0: b5 32 fd 6f 01 77 3d 53 f7 a4 70 83 46 bc 5f c4
000001e0: f3 6f fd a9 fc ea 70 b9 c6 e6 93 e1
The output is a little bit long for test 1, isn't it?
When I look at aes_xts_enc_tv_template[] from crypto/testmgr.h
I see .rlen = 32 .
I didn't bisect to find out exactly since when the regression is there. I
wanted to warn you quickly since we are close to the merge window.
Also if you have already been notified about this issue, please, sorry for
the noise!
Best regards,
Cyrille
^ permalink raw reply
* crypto regression?
From: Herbert Xu @ 2016-12-08 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10260816-d835-746e-d69e-da4cd7b6b88e@atmel.com>
On Thu, Dec 08, 2016 at 11:41:55AM +0100, Cyrille Pitchen wrote:
> Hi Herbert,
>
> Let me report a potential regression I've noticed this morning when testing
> linux-next.
>
> I've set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n when compiling both kernel
> images.
>
>
> On 4.9.0-rc2-next-20161028, /proc/crypto displays:
> driver : atmel-xts-aes
Thanks for the report. This should be fixed once I push this out
https://patchwork.kernel.org/patch/9465979/
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 3/3] clk: keystone: Add sci-clk driver support
From: Tero Kristo @ 2016-12-08 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208001348.GC5423@codeaurora.org>
On 08/12/16 02:13, Stephen Boyd wrote:
> On 10/21, Tero Kristo wrote:
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index 6a8ac04..dce08a7 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -169,6 +169,15 @@ config COMMON_CLK_NXP
>> ---help---
>> Support for clock providers on NXP platforms.
>>
>> +config TI_SCI_CLK
>> + tristate "TI System Control Interface clock drivers"
>> + depends on (TI_SCI_PROTOCOL && COMMON_CLK_KEYSTONE) || COMPILE_TEST
>
> Given that we depend on COMMON_CLK_KEYSTONE (just for the
> Makefile dependency?) this should be moved to right below the
> COMMON_CLK_KEYSTONE config. And we should consider making a
> Kconfig file in drivers/clk/keystone/ to hold both those configs
> instead of having them at the toplevel.
Its a makefile dependency only right now. I'll have a look at how to
handle this properly.
>
>> + default TI_SCI_PROTOCOL
>> + ---help---
>> + This adds the clock driver support over TI System Control Interface.
>> + If you wish to use clock resources from the PMMC firmware, say Y.
>> + Otherwise, say N.
>> +
>> config COMMON_CLK_PALMAS
>> tristate "Clock driver for TI Palmas devices"
>> depends on MFD_PALMAS
>> diff --git a/drivers/clk/keystone/Makefile b/drivers/clk/keystone/Makefile
>> index 0477cf6..0e7993d 100644
>> --- a/drivers/clk/keystone/Makefile
>> +++ b/drivers/clk/keystone/Makefile
>> @@ -1 +1,2 @@
>> obj-y += pll.o gate.o
>> +obj-$(CONFIG_TI_SCI_CLK) += sci-clk.o
>> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
>> new file mode 100644
>> index 0000000..f6af5bd
>> --- /dev/null
>> +++ b/drivers/clk/keystone/sci-clk.c
>> @@ -0,0 +1,589 @@
> [...]
>> +
>> +/**
>> + * sci_clk_recalc_rate - Get clock rate for a TI SCI clock
>> + * @hw: clock to get rate for
>> + * @parent_rate: parent rate provided by common clock framework, not used
>> + *
>> + * Gets the current clock rate of a TI SCI clock. Returns the current
>> + * clock rate, or zero in failure.
>> + */
>> +static unsigned long sci_clk_recalc_rate(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> + struct sci_clk *clk = to_sci_clk(hw);
>> + u64 freq;
>> + int ret;
>> +
>> + ret = clk->provider->ops->get_freq(clk->provider->sci, clk->dev_id,
>> + clk->clk_id, &freq);
>> + if (ret) {
>> + dev_err(clk->provider->dev,
>> + "recalc-rate failed for dev=%d, clk=%d, ret=%d\n",
>> + clk->dev_id, clk->clk_id, ret);
>> + return 0;
>> + }
>> +
>> + return (u32)freq;
>
> Do we need the cast? sizeof(u32) doesn't always equal
> sizeof(unsigned long).
Hmm, not sure where that came from. But yea, can be dropped.
>
>> +
>> +/**
>> + * _sci_clk_get - Gets a handle for an SCI clock
>> + * @provider: Handle to SCI clock provider
>> + * @dev_id: device ID for the clock to register
>> + * @clk_id: clock ID for the clock to register
>> + *
>> + * Gets a handle to an existing TI SCI hw clock, or builds a new clock
>> + * entry and registers it with the common clock framework. Called from
>> + * the common clock framework, when a corresponding of_clk_get call is
>> + * executed, or recursively from itself when parsing parent clocks.
>> + * Returns a pointer to the hw clock struct, or ERR_PTR value in failure.
>> + */
>> +static struct clk_hw *_sci_clk_build(struct sci_clk_provider *provider,
>> + u16 dev_id, u8 clk_id)
>> +{
>> + struct clk_init_data init = { NULL };
>> + struct sci_clk *sci_clk = NULL;
>> + char *name = NULL;
>> + char **parent_names = NULL;
>> + int i;
>> + int ret;
>> +
>> + sci_clk = devm_kzalloc(provider->dev, sizeof(*sci_clk), GFP_KERNEL);
>> + if (!sci_clk)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + sci_clk->dev_id = dev_id;
>> + sci_clk->clk_id = clk_id;
>> + sci_clk->provider = provider;
>> +
>> + ret = provider->ops->get_num_parents(provider->sci, dev_id,
>> + clk_id,
>> + &init.num_parents);
>> + if (ret)
>> + goto err;
>> +
>> + name = kasprintf(GFP_KERNEL, "%s:%d:%d", dev_name(provider->dev),
>> + sci_clk->dev_id, sci_clk->clk_id);
>> +
>> + init.name = name;
>> +
>> + if (init.num_parents < 2)
>> + init.num_parents = 0;
>
> This deserves a comment. Why is num_parents == 1 the same as
> num_parents == 0?
I'll add a comment on this. Basically some clocks can be root clocks
which don't have parents, and we only want to have parent control for
clocks that can switch their parent. This is kind of a quirk of the
firmware.
>
>> +
>> + if (init.num_parents) {
>> + parent_names = devm_kcalloc(provider->dev, init.num_parents,
>> + sizeof(char *), GFP_KERNEL);
>> +
>> + if (!parent_names) {
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + for (i = 0; i < init.num_parents; i++) {
>> + char *parent_name;
>> +
>> + parent_name = kasprintf(GFP_KERNEL, "%s:%d:%d",
>> + dev_name(provider->dev),
>> + sci_clk->dev_id,
>> + sci_clk->clk_id + 1 + i);
>> + if (!parent_name) {
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> + parent_names[i] = parent_name;
>> + }
>> + init.parent_names = (const char * const *)parent_names;
>
> Does that really need a cast?
Doesn't seem like so... I think without this it was generating some
checkpatch issue sometime back, but doesn't seem to be the case anymore.
>
>> + }
>> +
>> + init.ops = &sci_clk_ops;
>> + sci_clk->hw.init = &init;
>> +
>> + ret = devm_clk_hw_register(provider->dev, &sci_clk->hw);
>> + if (ret) {
>> + dev_err(provider->dev, "failed clk register with %d\n", ret);
>> + goto err;
>> + }
>> + kfree(name);
>> +
>> + return &sci_clk->hw;
>> +
>> +err:
>> + if (parent_names) {
>> + for (i = 0; i < init.num_parents; i++)
>> + devm_kfree(provider->dev, parent_names[i]);
>> +
>> + devm_kfree(provider->dev, parent_names);
>
> Shouldn't we be freeing the parent names all the time? It should
> be deep copied in the framework.
I'll check this.
>
>> + }
>> +
>> + devm_kfree(provider->dev, sci_clk);
>> +
>> + kfree(name);
>> +
>> + return ERR_PTR(ret);
>> +}
> [..]
>> +
>> +static int ti_sci_init_clocks(struct sci_clk_provider *p)
>> +{
>> + struct sci_clk_data *data = p->clocks;
>> + struct clk_hw *hw;
>> + int i;
>> +
>> + while (data->num_clks) {
>> + data->clocks = devm_kcalloc(p->dev, data->num_clks,
>> + sizeof(struct sci_clk),
>> + GFP_KERNEL);
>> + if (!data->clocks)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < data->num_clks; i++) {
>> + hw = _sci_clk_build(p, data->dev, i);
>> + if (!IS_ERR(hw)) {
>> + data->clocks[i] = hw;
>> + continue;
>> + }
>> +
>> + /* Skip any holes in the clock lists */
>> + if (PTR_ERR(hw) == -ENODEV)
>
> Does this happen? I don't see where _sci_clk_build() returns
> -ENODEV.
Yes, it can and will happen. get_num_parents() called by sci_clk_build
will return ENODEV for device/clock pairs that don't exist.
>
>> + continue;
>> +
>> + return PTR_ERR(hw);
>> + }
>> + data++;
>> + }
>> +
>> + return 0;
>> +}
>> +
>
>> +
>> +/**
>> + * ti_sci_clk_probe - Probe function for the TI SCI clock driver
>> + * @pdev: platform device pointer to be probed
>> + *
>> + * Probes the TI SCI clock device. Allocates a new clock provider
>> + * and registers this to the common clock framework. Also applies
>> + * any required flags to the identified clocks via clock lists
>> + * supplied from DT. Returns 0 for success, negative error value
>> + * for failure.
>> + */
>> +static int ti_sci_clk_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + struct sci_clk_provider *provider;
>> + const struct ti_sci_handle *handle;
>> + struct sci_clk_data *data;
>> + int ret;
>> +
>> + data = (struct sci_clk_data *)
>> + of_match_node(ti_sci_clk_of_match, np)->data;
>
> Just use of_device_get_match_data() instead.
All righty.
>
>> +
>> + handle = devm_ti_sci_get_handle(dev);
>> + if (IS_ERR(handle))
>> + return PTR_ERR(handle);
>> +
>> + provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
>> + if (!provider)
>> + return -ENOMEM;
>> +
>> + provider->clocks = data;
>> +
>> + provider->sci = handle;
>> + provider->ops = &handle->ops.clk_ops;
>> + provider->dev = dev;
>> +
>> + ti_sci_init_clocks(provider);
>
> And if this fails?
Yea this is kind of controversial. ti_sci_init_clocks() can fail if any
of the clocks registered will fail. I decided to have it this way so
that at least some clocks might work in failure cause, and you might
have a booting device instead of total lock-up.
Obviously it could be done so that if any clock fails, we would
de-register all clocks at that point, but personally I think this is a
worse option.
ti_sci_init_clocks could probably be modified to continue registering
clocks when a single clock fails though. Currently it aborts at first
failure.
Thoughts on that?
>
>> +
>> + ret = of_clk_add_hw_provider(np, sci_clk_get, provider);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>
> Just "return of_clk_add_hw_provider()" please.
True that, will fix.
-Tero
^ permalink raw reply
* [PATCH v5 2/5] i2c: Add STM32F4 I2C driver
From: kbuild test robot @ 2016-12-08 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-3-git-send-email-cedric.madianga@gmail.com>
Hi M'boumba,
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.9-rc8 next-20161208]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/M-boumba-Cedric-Madianga/Add-support-for-the-STM32F4-I2C/20161208-173240
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/clk.h:16:0,
from drivers/i2c/busses/i2c-stm32f4.c:12:
drivers/i2c/busses/i2c-stm32f4.c: In function 'stm32f4_i2c_set_periph_clk_freq':
include/linux/kernel.h:749:16: warning: comparison of distinct pointer types lacks a cast
(void) (&max1 == &max2); \
^
include/linux/kernel.h:737:2: note: in definition of macro '__min'
t1 min1 = (x); \
^~
include/linux/kernel.h:778:28: note: in expansion of macro 'min'
#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
^~~
>> include/linux/kernel.h:752:2: note: in expansion of macro '__max'
__max(typeof(x), typeof(y), \
^~~~~
>> include/linux/kernel.h:778:45: note: in expansion of macro 'max'
#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
^~~
>> drivers/i2c/busses/i2c-stm32f4.c:201:9: note: in expansion of macro 'clamp'
freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
^~~~~
include/linux/kernel.h:749:16: warning: comparison of distinct pointer types lacks a cast
(void) (&max1 == &max2); \
^
include/linux/kernel.h:737:13: note: in definition of macro '__min'
t1 min1 = (x); \
^
include/linux/kernel.h:778:28: note: in expansion of macro 'min'
#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
^~~
>> include/linux/kernel.h:752:2: note: in expansion of macro '__max'
__max(typeof(x), typeof(y), \
^~~~~
>> include/linux/kernel.h:778:45: note: in expansion of macro 'max'
#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
^~~
>> drivers/i2c/busses/i2c-stm32f4.c:201:9: note: in expansion of macro 'clamp'
freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
^~~~~
include/linux/kernel.h:739:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:742:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
include/linux/kernel.h:778:28: note: in expansion of macro 'min'
#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
^~~
>> drivers/i2c/busses/i2c-stm32f4.c:201:9: note: in expansion of macro 'clamp'
freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
^~~~~
vim +/clamp +201 drivers/i2c/busses/i2c-stm32f4.c
185
186 static void stm32f4_i2c_disable_it(struct stm32f4_i2c_dev *i2c_dev)
187 {
188 void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
189
190 stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_IRQ_MASK);
191 }
192
193 static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
194 {
195 u32 clk_rate, cr2, freq;
196
197 cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
198 cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
199 clk_rate = clk_get_rate(i2c_dev->clk);
200 freq = clk_rate / MHZ_TO_HZ;
> 201 freq = clamp(freq, STM32F4_I2C_MIN_FREQ, STM32F4_I2C_MAX_FREQ);
202 cr2 |= STM32F4_I2C_CR2_FREQ(freq);
203 writel_relaxed(cr2, i2c_dev->base + STM32F4_I2C_CR2);
204 }
205
206 static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
207 {
208 u32 trise, freq, cr2, val;
209
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 56838 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161208/776da99e/attachment-0001.gz>
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Mason @ 2016-12-08 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208103921.GC6408@localhost>
On 08/12/2016 11:39, Vinod Koul wrote:
> On Wed, Dec 07, 2016 at 04:45:58PM +0000, M?ns Rullg?rd wrote:
>
>> Vinod Koul <vinod.koul@intel.com> writes:
>>
>>> On Tue, Dec 06, 2016 at 01:14:20PM +0000, M?ns Rullg?rd wrote:
>>>>
>>>> That's not going to work very well. Device drivers typically request
>>>> dma channels in their probe functions or when the device is opened.
>>>> This means that reserving one of the few channels there will inevitably
>>>> make some other device fail to operate.
>>>
>>> No that doesn't make sense at all, you should get a channel only when you
>>> want to use it and not in probe!
>>
>> Tell that to just about every single driver ever written.
>
> Not really, few do yes which is wrong but not _all_ do that.
Vinod,
Could you explain something to me in layman's terms?
I have a NAND Flash Controller driver that depends on the
DMA driver under discussion.
Suppose I move the dma_request_chan() call from the driver's
probe function, to the actual DMA transfer function.
I would want dma_request_chan() to put the calling thread
to sleep until a channel becomes available (possibly with
a timeout value).
But Maxime told me dma_request_chan() will just return
-EBUSY if no channels are available.
Am I supposed to busy wait in my driver's DMA function
until a channel becomes available?
I don't understand how the multiplexing of few memory
channels to many clients is supposed to happen efficiently?
Regards.
^ 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