* [PATCH v5 5/5] ARM: configs: Add I2C support for STM32 defconfig
From: M'boumba Cedric Madianga @ 2016-12-08 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-1-git-send-email-cedric.madianga@gmail.com>
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
arch/arm/configs/stm32_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index e7b56d4..9494eaf 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_STM32F4=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_NEW_LEDS=y
--
1.9.1
^ permalink raw reply related
* [PATCH v5 5/5] ARM: configs: Add I2C support for STM32 defconfig
From: Alexandre Torgue @ 2016-12-08 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-6-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> ---
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
Can you change the commit header by ARM: configs: stm32: Add I2C support
Thx
alex
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index e7b56d4..9494eaf 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_STM32F4=y
> # CONFIG_HWMON is not set
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
>
^ permalink raw reply
* [PATCH v5 4/5] ARM: dts: Add I2C1 support for STM32429 eval board
From: Alexandre Torgue @ 2016-12-08 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481185563-8735-5-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> ---
> arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Can you change the commit header by: ARM: dts: stm32: Add I2C1 support
for STM32429 eval board
thx
Alex
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index afb90bc..74e0045 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -141,3 +141,9 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&i2c1 {
> + pinctrl-0 = <&i2c1_pins_b>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
^ permalink raw reply
* [PATCH 1/2] ASoC: zte: spdif and i2s drivers are not zx296702 specific
From: Shawn Guo @ 2016-12-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Shawn Guo <shawn.guo@linaro.org>
ZTE ZX SPDIF and I2S drivers can work on not only ZX296702 but also
other ZTE ZX family SoCs like ZX296718, which is an arm64 platform.
Let's make a few renaming and tweak the Kconfig a bit to get the drivers
available for other ZTE ZX platforms.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
sound/soc/zte/Kconfig | 16 ++++++++--------
sound/soc/zte/Makefile | 4 ++--
sound/soc/zte/{zx296702-i2s.c => zx-i2s.c} | 0
sound/soc/zte/{zx296702-spdif.c => zx-spdif.c} | 0
4 files changed, 10 insertions(+), 10 deletions(-)
rename sound/soc/zte/{zx296702-i2s.c => zx-i2s.c} (100%)
rename sound/soc/zte/{zx296702-spdif.c => zx-spdif.c} (100%)
diff --git a/sound/soc/zte/Kconfig b/sound/soc/zte/Kconfig
index c47eb25e441f..6d8a90d36315 100644
--- a/sound/soc/zte/Kconfig
+++ b/sound/soc/zte/Kconfig
@@ -1,17 +1,17 @@
-config ZX296702_SPDIF
- tristate "ZX296702 spdif"
- depends on SOC_ZX296702 || COMPILE_TEST
+config ZX_SPDIF
+ tristate "ZTE ZX SPDIF Driver Support"
+ depends on ARCH_ZX || COMPILE_TEST
depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
help
Say Y or M if you want to add support for codecs attached to the
- zx296702 spdif interface
+ ZTE ZX SPDIF interface
-config ZX296702_I2S
- tristate "ZX296702 i2s"
- depends on SOC_ZX296702 || COMPILE_TEST
+config ZX_I2S
+ tristate "ZTE ZX I2S Driver Support"
+ depends on ARCH_ZX || COMPILE_TEST
depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
help
Say Y or M if you want to add support for codecs attached to the
- zx296702 i2s interface
+ ZTE ZX I2S interface
diff --git a/sound/soc/zte/Makefile b/sound/soc/zte/Makefile
index 254ed2c8c1a0..77768f5fd10c 100644
--- a/sound/soc/zte/Makefile
+++ b/sound/soc/zte/Makefile
@@ -1,2 +1,2 @@
-obj-$(CONFIG_ZX296702_SPDIF) += zx296702-spdif.o
-obj-$(CONFIG_ZX296702_I2S) += zx296702-i2s.o
+obj-$(CONFIG_ZX_SPDIF) += zx-spdif.o
+obj-$(CONFIG_ZX_I2S) += zx-i2s.o
diff --git a/sound/soc/zte/zx296702-i2s.c b/sound/soc/zte/zx-i2s.c
similarity index 100%
rename from sound/soc/zte/zx296702-i2s.c
rename to sound/soc/zte/zx-i2s.c
diff --git a/sound/soc/zte/zx296702-spdif.c b/sound/soc/zte/zx-spdif.c
similarity index 100%
rename from sound/soc/zte/zx296702-spdif.c
rename to sound/soc/zte/zx-spdif.c
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ASoC: zte: spdif: correct ZX_SPDIF_CLK_RAT define
From: Shawn Guo @ 2016-12-08 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481186655-8213-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
The macro ZX_SPDIF_CLK_RAT should be 2 instead of 4. With this
fix, we can get correct audio output on HDMI through SPDIF interface.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
sound/soc/zte/zx-spdif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/zte/zx-spdif.c b/sound/soc/zte/zx-spdif.c
index 26265ce4caca..9fa6463ce5d7 100644
--- a/sound/soc/zte/zx-spdif.c
+++ b/sound/soc/zte/zx-spdif.c
@@ -71,7 +71,7 @@
#define ZX_VALID_RIGHT_TRACK (2 << 0)
#define ZX_VALID_TRACK_MASK (3 << 0)
-#define ZX_SPDIF_CLK_RAT (4 * 32)
+#define ZX_SPDIF_CLK_RAT (2 * 32)
struct zx_spdif_info {
struct snd_dmaengine_dai_dma_data dma_data;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 5/5] ARM: configs: Add I2C support for STM32 defconfig
From: M'boumba Cedric Madianga @ 2016-12-08 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daf6b0b4-9bd1-d3eb-a759-ed64eee990f2@st.com>
Hi Alex,
2016-12-08 9:38 GMT+01:00 Alexandre Torgue <alexandre.torgue@st.com>:
> Hi Cedric,
>
> On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> arch/arm/configs/stm32_defconfig | 3 +++
>> 1 file changed, 3 insertions(+)
>>
> Can you change the commit header by ARM: configs: stm32: Add I2C support
Ok, I will use this typo in the next version
>
> Thx
> alex
>
>
>
>
>
>> diff --git a/arch/arm/configs/stm32_defconfig
>> b/arch/arm/configs/stm32_defconfig
>> index e7b56d4..9494eaf 100644
>> --- a/arch/arm/configs/stm32_defconfig
>> +++ b/arch/arm/configs/stm32_defconfig
>> @@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
>> CONFIG_SERIAL_STM32=y
>> CONFIG_SERIAL_STM32_CONSOLE=y
>> # CONFIG_HW_RANDOM is not set
>> +CONFIG_I2C=y
>> +CONFIG_I2C_CHARDEV=y
>> +CONFIG_I2C_STM32F4=y
>> # CONFIG_HWMON is not set
>> # CONFIG_USB_SUPPORT is not set
>> CONFIG_NEW_LEDS=y
>>
>
^ permalink raw reply
* [PATCH v5 4/5] ARM: dts: Add I2C1 support for STM32429 eval board
From: M'boumba Cedric Madianga @ 2016-12-08 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e61ae4d6-a65a-5cfa-6845-27351ac43af6@st.com>
Hi Alex,
2016-12-08 9:39 GMT+01:00 Alexandre Torgue <alexandre.torgue@st.com>:
> Hi Cedric,
>
> On 12/08/2016 09:26 AM, M'boumba Cedric Madianga wrote:
>>
>> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
>> ---
>> arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
> Can you change the commit header by: ARM: dts: stm32: Add I2C1 support for
> STM32429 eval board
Ok, I will use this typo in the next version
>
> thx
> Alex
>
>
>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> index afb90bc..74e0045 100644
>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> @@ -141,3 +141,9 @@
>> pinctrl-names = "default";
>> status = "okay";
>> };
>> +
>> +&i2c1 {
>> + pinctrl-0 = <&i2c1_pins_b>;
>> + pinctrl-names = "default";
>> + status = "okay";
>> +};
>>
>
^ permalink raw reply
* [PATCH v1 1/2] Add crypto driver support for some MediaTek chips
From: Ryder Lee @ 2016-12-08 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205085220.GA333@Red>
Hello,
On Mon, 2016-12-05 at 09:52 +0100, Corentin Labbe wrote:
> Hello
>
> I have two minor comment.
>
> On Mon, Dec 05, 2016 at 03:01:23PM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
>
> There is a typo for algorithms.
>
> [...]
> > +/**
> > + * struct mtk_desc - DMA descriptor
> > + * @hdr: the descriptor control header
> > + * @buf: DMA address of input buffer segment
> > + * @ct: DMA address of command token that control operation flow
> > + * @ct_hdr: the command token control header
> > + * @tag: the user-defined field
> > + * @tfm: DMA address of transform state
> > + * @bound: align descriptors offset boundary
> > + *
> > + * Structure passed to the crypto engine to describe where source
> > + * data needs to be fetched and how it needs to be processed.
> > + */
> > +struct mtk_desc {
> > + u32 hdr;
> > + u32 buf;
> > + u32 ct;
> > + u32 ct_hdr;
> > + u32 tag;
> > + u32 tfm;
> > + u32 bound[2];
> > +};
>
> Do you have tested this descriptor with BE/LE kernel ?
I did not test it with BE kernel, because both CPU and accelerator in
our SoC just run on LE system.
Thanks for reminding me, i will use byteorder conversion macros and type
identifiers.
> Regards
> Corentin Labbe
^ permalink raw reply
* [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
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