* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-28 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..5624714d2b16 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -46,6 +46,7 @@
#include "meson-gxbb.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/net/mdio.h>
/ {
compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
@@ -98,3 +99,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy at 0 {
+ reg = <0>;
+ eee-broken-modes = <MDIO_EEE_1000T>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Ard Biesheuvel @ 2016-11-28 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9SG5s=zddQaw+444191JGqmXfCh+AKyv3nZNqggmh=Kw@mail.gmail.com>
On 20 November 2016 at 11:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 20 November 2016 at 11:42, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This integrates both the accelerated scalar and the NEON implementations
>> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>>
>> Relative performance compared to the respective generic C versions:
>>
>> | SHA256-scalar | SHA256-NEON* | SHA512 |
>> ------------+-----------------+--------------+----------+
>> Cortex-A53 | 1.63x | 1.63x | 2.34x |
>> Cortex-A57 | 1.43x | 1.59x | 1.95x |
>> Cortex-A73 | 1.26x | 1.56x | ? |
>>
>> The core crypto code was authored by Andy Polyakov of the OpenSSL
>> project, in collaboration with whom the upstream code was adapted so
>> that this module can be built from the same version of sha512-armv8.pl.
>>
>> The version in this patch was taken from OpenSSL commit 32bbb62ea634
>> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>>
>> * The core SHA algorithm is fundamentally sequential, but there is a
>> secondary transformation involved, called the schedule update, which
>> can be performed independently. The NEON version of SHA-224/SHA-256
>> only implements this part of the algorithm using NEON instructions,
>> the sequential part is always done using scalar instructions.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>
> Missing changelog:
>
> v4: fixed the big-endian build; this required an upstream change (even
> though upstream was not actually broken, since it explicitly defines
> __ARMEB__ on AArch64 big-endian builds), so this patch is now based
> on a more recent upstream OpenSSL commit (the __ILP32__ #ifdefs are
> still present but never active)
>
> v3: at Will's request, the generated assembly files are now included
> as .S_shipped files, for which generic build rules are defined
> already.
>
> Note that sizeable patches like this one have caused issues in the past with
> patchwork, so for Herbert's convenience, the patch can be pulled from
> http://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git, branch
> arm64-sha256 (based on today's cryptodev)
Herbert,
Assuming that everyone is happy now (Will?), could we get this one
queued for v4.10? The CRC stuff I sent over the past week can wait for
v4.11 (and I should probably do a v2 roundup with everything
combined), but this patch is good to go IMO
Thanks,
Ard.
^ permalink raw reply
* [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2350540.yAeGFdYPK2@avalon>
Hi Laurent,
On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
>> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
>>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>>
>>>> .../bindings/display/meson/meson-drm.txt | 134 +++++++++++++++
>>>> 1 file changed, 134 insertions(+)
>>>> create mode 100644
>>>>
>>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>>>> mode 100644
>>>> index 0000000..89c1b5f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
[...]
>>>> +
>>>> +VENC CBVS Output
>>>> +----------------------
>>>> +
>>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>>>> +
>>>> +Required properties:
>>>> + - compatible: value must be one of:
>>>> + - compatible: value should be different for each SoC family as :
>>> One of those two lines is redundant.
>>
>> Will fix.
>>
>>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>>>> +
>>>
>>> No registers ? Are the encoders registers part of the VPU register space,
>>> intertwined in a way that they can't be specified separately here ?
>>
>> Exact, all the video registers on the Amlogic SoC are part of a long history
>> of fixup/enhance from very old SoCs, it's quite hard to distinguish a Venc
>> registers array since they are mixed with the multiple encoders
>> registers...
>
> In that case is there really a reason to model the encoders as separate nodes
> in DT ?
Here, it more the encoder-connector couple that is represented as a node, and
the CVBS output is optional.
>
>> The only separate registers are the VDAC and HDMI PHY, I may move them to
>> these separate nodes since they are part of the HHI register space.
>>
>> It is a problem if I move them in the next release ? Next release will
>> certainly have HDMI support, and will have these refactorings.
>
> Given that DT bindings are considered as a stable ABI, I'm afraid it's an
> issue.
OK, I will add the VDAC/HDMI PHY registers as part if these output nodes.
>
>>>> +- ports: A ports node with endpoint definitions as defined in
>>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
>>>> + first port should be the input endpoints, connected ot the VPU node.
>>>> +
>>>> +Example:
>>>> +
>>>> +venc_cvbs: venc-cvbs {
>>>> + compatible = "amlogic,meson-gxbb-venc-cvbs";
>>>> + status = "okay";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + enc_cvbs_in: port at 0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <0>;
>>>> +
>>>> + venc_cvbs_in_vpu: endpoint at 0 {
>>>> + reg = <0>;
>>>> + remote-endpoint = <&vpu_out_venc_cvbs>;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>> +
>>>> +vpu: vpu at d0100000 {
>>>> + compatible = "amlogic,meson-gxbb-vpu";
>>>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>>>> + <0x0 0xc883c000 0x0 0x1000>,
>>>> + <0x0 0xc8838000 0x0 0x1000>;
>>>> + reg-names = "base", "hhi", "dmc";
>>>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + vpu_out: port at 1 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + reg = <1>;
>>>> +
>>>> + vpu_out_venc_cvbs: endpoint at 0 {
>>>> + reg = <0>;
>>>> + remote-endpoint = <&venc_cvbs_in_vpu>;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>
>> Thanks for the review !
>
Neil
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Icenowy Zheng @ 2016-11-28 9:59 UTC (permalink / raw)
To: linux-arm-kernel
As there's currently a fork of U-Boot which provides simplefb support
for H3, a simplefb node can be added to the device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
I'm still not sure which pipeline should I use.
And, it seems that HDMI Slow Clock is not needed?
(seems that it's only for EDID, but simplefb won't use EDID)
arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..cacc8dd 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -50,6 +50,22 @@
/ {
interrupt-parent = <&gic>;
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ simplefb_hdmi: framebuffer at 0 {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "de0-lcd0-hdmi";
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
+ <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
+ <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
+ status = "disabled";
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.10.2
^ permalink raw reply related
* [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-28 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <534f6d99-a579-27b6-fb54-48584cd1c7aa@baylibre.com>
Hi Neil,
On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
> >> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> >>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >>>> ---
> >>>>
> >>>> .../bindings/display/meson/meson-drm.txt | 134
> >>>> +++++++++++++++
> >>>> 1 file changed, 134 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> >>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new
> >>>> file
> >>>> mode 100644
> >>>> index 0000000..89c1b5f
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> [...]
>
> >>>> +
> >>>> +VENC CBVS Output
> >>>> +----------------------
> >>>> +
> >>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible: value must be one of:
> >>>> + - compatible: value should be different for each SoC family as :
> >>> One of those two lines is redundant.
> >>
> >> Will fix.
> >>
> >>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
> >>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
> >>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
> >>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
> >>>> +
> >>>
> >>> No registers ? Are the encoders registers part of the VPU register
> >>> space, intertwined in a way that they can't be specified separately here
> >>> ?
> >>
> >> Exact, all the video registers on the Amlogic SoC are part of a long
> >> history of fixup/enhance from very old SoCs, it's quite hard to
> >> distinguish a Venc registers array since they are mixed with the
> >> multiple encoders registers...
> >
> > In that case is there really a reason to model the encoders as separate
> > nodes in DT ?
>
> Here, it more the encoder-connector couple that is represented as a node,
> and the CVBS output is optional.
You should actually have a DT node for the connector. I would merge the
encoders into the VPU node (especially given that according to your diagram
they are part of the VPU), and document the VPU output ports explicitly. If
the CVBS output is not implemented by some of the SoCs in the family then the
corresponding DT node should just omit that port.
> >> The only separate registers are the VDAC and HDMI PHY, I may move them to
> >> these separate nodes since they are part of the HHI register space.
> >>
> >> It is a problem if I move them in the next release ? Next release will
> >> certainly have HDMI support, and will have these refactorings.
> >
> > Given that DT bindings are considered as a stable ABI, I'm afraid it's an
> > issue.
>
> OK, I will add the VDAC/HDMI PHY registers as part if these output nodes.
Thank you.
> >>>> +- ports: A ports node with endpoint definitions as defined in
> >>>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> >>>> + first port should be the input endpoints, connected ot the VPU node.
> >>>> +
> >>>> +Example:
> >>>> +
> >>>> +venc_cvbs: venc-cvbs {
> >>>> + compatible = "amlogic,meson-gxbb-venc-cvbs";
> >>>> + status = "okay";
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + enc_cvbs_in: port at 0 {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <0>;
> >>>> +
> >>>> + venc_cvbs_in_vpu: endpoint at 0 {
> >>>> + reg = <0>;
> >>>> + remote-endpoint =
<&vpu_out_venc_cvbs>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +};
> >>>> +
> >>>> +vpu: vpu at d0100000 {
> >>>> + compatible = "amlogic,meson-gxbb-vpu";
> >>>> + reg = <0x0 0xd0100000 0x0 0x100000>,
> >>>> + <0x0 0xc883c000 0x0 0x1000>,
> >>>> + <0x0 0xc8838000 0x0 0x1000>;
> >>>> + reg-names = "base", "hhi", "dmc";
> >>>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + vpu_out: port at 1 {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <1>;
> >>>> +
> >>>> + vpu_out_venc_cvbs: endpoint at 0 {
> >>>> + reg = <0>;
> >>>> + remote-endpoint =
<&venc_cvbs_in_vpu>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +};
> >>
> >> Thanks for the review !
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Chen-Yu Tsai @ 2016-11-28 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128095900.27615-1-icenowy@aosc.xyz>
On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
Please add it when its finalized...
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> I'm still not sure which pipeline should I use.
You are supposed to add _all_ the pipelines that are available and
supported by U-boot. U-boot is then supposed to enable and update
the one it set up.
ChenYu
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
>
> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 75a8654..cacc8dd 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -50,6 +50,22 @@
> / {
> interrupt-parent = <&gic>;
>
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + simplefb_hdmi: framebuffer at 0 {
> + compatible = "allwinner,simple-framebuffer",
> + "simple-framebuffer";
> + allwinner,pipeline = "de0-lcd0-hdmi";
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
> + status = "disabled";
> + };
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH v3] clkdev: add devm_of_clk_get()
From: Russell King - ARM Linux @ 2016-11-28 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vav89chw.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Nov 28, 2016 at 09:32:51AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> This patch adds it.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v2 -> v3
>
> - implement in clk-devres.c, and reused existing devm_clk_release()
>
> drivers/clk/clk-devres.c | 21 +++++++++++++++++++++
> include/linux/clk.h | 7 +++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index 8f57154..2449b25 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -53,3 +53,24 @@ void devm_clk_put(struct device *dev, struct clk *clk)
> WARN_ON(ret);
> }
> EXPORT_SYMBOL(devm_clk_put);
> +
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + struct clk **ptr, *clk;
> +
> + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + clk = of_clk_get(np, index);
> + if (!IS_ERR(clk)) {
> + *ptr = clk;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return clk;
> +}
> +EXPORT_SYMBOL(devm_of_clk_get);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 123c027..1b713db 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -506,6 +506,8 @@ static inline void clk_disable_unprepare(struct clk *clk)
>
> #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
> struct clk *of_clk_get(struct device_node *np, int index);
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index);
No need for this to be within the ifdef.
> struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
> struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
> #else
> @@ -513,6 +515,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
> {
> return ERR_PTR(-ENOENT);
> }
> +static inline struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + return ERR_PTR(-ENOENT);
> +}
and so no need for this either. In any case, this will cause !OF ||
!COMMON_CLK builds to fail because this definition will conflict with
that in clk-devres.c
> static inline struct clk *of_clk_get_by_name(struct device_node *np,
> const char *name)
> {
> --
> 1.9.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-28 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <436c6925-cb0d-afe7-e3a2-384eca15ff42@marvell.com>
Hi Ulf,
On 2016/11/24 23:37, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/24 22:33, Ulf Hansson wrote:
<snip>
>>>
>>> As result, our SDHC driver has to implement the functionality to
>>> send commands and check the results, in host layer.
>>> If directly calling mmc_wait_for_cmd() is improper, could you please
>>> give us some suggestions?
>>>
>>> For eMMC, CMD8 is used to test current sampling point set in PHY.
>>
>> Try to use mmc_send_tuning().
>>
>
> Could you please tell me the requirement of "op_code" parameter in
> mmc_send_tuning()?
> According to mmc_send_tuning(),it seems that tuning command(CMD19/CMD21)
> is required. Thus device will not response mmc_send_tuning() if current
> speed mode doesn't support tuning command.
> Please correct me if I am wrong.
>
As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
send commands for testing current sampling point set in our host PHY.
According to my test result, it shows that mmc_send_tuning() can only support
tuning command (CMD21/CMD19).
As a result, we cannot use mmc_send_tuning() when card is in the speed modes
which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
speed modes.
Could you please provide suggestions for the speed mode in which tuning is
not available?
Thank you.
Best regards,
Hu Ziji
>>>
>>>>> +
>>>>> + return err;
>>>>> +}
>>>>> +
>>>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>>>> +{
>>>>> + struct mmc_command cmd = {0};
>>>>> + int err;
>>>>> +
>>>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>>>> +
>>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>>> + if (err)
>>>>> + return err;
>>>>> +
>>>>> + if (cmd.resp[0] & R5_ERROR)
>>>>> + return -EIO;
>>>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>>>> + return -EINVAL;
>>>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>>>> + return -ERANGE;
>>>>> + return 0;
>>>>
>>>> No thanks! MMC/SD/SDIO protocol code belongs in the core.
>>>>
>>> For SDIO, SD_IO_RW_DIRECT command is sent to test current sampling point
>>> in PHY.
>>> Please help provide some suggestion to implement the command transfer.
>>
>> Again, I think mmc_send_tuning() should be possible for you to use.
>>
>> [...]
>>
>>>>> + if (mmc->card)
>>>>> + card = mmc->card;
>>>>> + else
>>>>> + /*
>>>>> + * Only valid during initialization
>>>>> + * before mmc->card is set
>>>>> + */
>>>>> + card = priv->card_candidate;
>>>>> + if (unlikely(!card)) {
>>>>> + dev_warn(mmc_dev(mmc), "card is not present\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>
>>>> That your host need to hold a copy of the card pointer, tells me that
>>>> something is not really correct.
>>>>
>>>> I might be wrong, if this turns out to be a special case, but I doubt
>>>> it. Although, if it *is* a special such case, we shall most likely try
>>>> to extend the the mmc core layer instead of adding all these hacks in
>>>> your host driver.
>>>>
>>> This card pointer copies the temporary structure mmc_card
>>> used in mmc_init_card(), mmc_sd_init_card() and mmc_sdio_init_card().
>>> Since we call mmc_wait_for_cmd() to send test commands, we need a copy
>>> of that temporary mmc_card here in our host driver.
>>
>> I see, thanks for clarifying.
>>
>>>
>>> During PHY setting in card initialization, mmc_host->card is not updated
>>> yet with that temporary mmc_card. Thus we are not able to directly use
>>> mmc_host->card. Instead, this card pointer is introduced to enable
>>> mmc_wait_for_cmd().
>>>
>>> If we can improve our host driver to send test commands without mmc_card,
>>> this card pointer can be removed.
>>> Could you please share your opinion please?
>>
>> The mmc_send_tuning() API takes the mmc_host as parameter. If you
>> convert to that, perhaps you would be able to remove the need to hold
>> the card pointer.
>>
>> BTW, the reason why mmc_send_tuning() doesn't take the card as a
>> parameter, is exactly those you just described above.
>>
> Got it.
> Thanks a lot for the information.
>
> Thank you for the great help.
>
> Best regards,
> Hu Ziji
>
>> [...]
>>
>> Kind regards
>> Uffe
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [kvm-unit-tests PATCH v7 08/11] arm/tlbflush-data: Add TLB flush during data writes test
From: Andrew Jones @ 2016-11-28 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-9-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:30PM +0000, Alex Benn?e wrote:
> This test is the cousin of the tlbflush-code test. Instead of flushing
> running code it re-maps virtual addresses while a buffer is being filled
> up. It then audits the results checking for writes that have ended up in
> the wrong place.
>
> While tlbflush-code exercises QEMU's translation invalidation logic this
> test stresses the SoftMMU cputlb code and ensures it is semantically
> correct.
>
> The test optionally takes two parameters for debugging:
>
> cycles - change the default number of test iterations
> page - flush pages individually instead of all
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> ---
> arm/Makefile.common | 2 +
> arm/tlbflush-data.c | 401 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> arm/unittests.cfg | 12 ++
> 3 files changed, 415 insertions(+)
> create mode 100644 arm/tlbflush-data.c
>
> diff --git a/arm/Makefile.common b/arm/Makefile.common
> index de99a6e..528166d 100644
> --- a/arm/Makefile.common
> +++ b/arm/Makefile.common
> @@ -14,6 +14,7 @@ tests-common += $(TEST_DIR)/spinlock-test.flat
> tests-common += $(TEST_DIR)/pci-test.flat
> tests-common += $(TEST_DIR)/gic.flat
> tests-common += $(TEST_DIR)/tlbflush-code.flat
> +tests-common += $(TEST_DIR)/tlbflush-data.flat
>
> all: test_cases
>
> @@ -83,3 +84,4 @@ test_cases: $(generated_files) $(tests-common) $(tests)
>
> $(TEST_DIR)/selftest.o $(cstart.o): $(asm-offsets)
> $(TEST_DIR)/tlbflush-code.elf: $(cstart.o) $(TEST_DIR)/tlbflush-code.o
> +$(TEST_DIR)/tlbflush-data.elf: $(cstart.o) $(TEST_DIR)/tlbflush-data.o
This isn't necessary
> diff --git a/arm/tlbflush-data.c b/arm/tlbflush-data.c
> new file mode 100644
> index 0000000..7920179
> --- /dev/null
> +++ b/arm/tlbflush-data.c
> @@ -0,0 +1,401 @@
> +/*
> + * TLB Flush Race Tests
> + *
> + * These tests are designed to test for incorrect TLB flush semantics
> + * under emulation. The initial CPU will set all the others working on
> + * a writing to a set of pages. It will then re-map one of the pages
> + * back and forth while recording the timestamps of when each page was
> + * active. The test fails if a write was detected on a page after the
> + * tlbflush switching to a new page should have completed.
> + *
> + * Copyright (C) 2016, Linaro, Alex Benn?e <alex.bennee@linaro.org>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +
> +#include <libcflat.h>
> +#include <asm/smp.h>
> +#include <asm/cpumask.h>
> +#include <asm/barrier.h>
> +#include <asm/mmu.h>
> +
> +#define NR_TIMESTAMPS ((PAGE_SIZE/sizeof(u64)) << 2)
> +#define NR_AUDIT_RECORDS 16384
> +#define NR_DYNAMIC_PAGES 3
> +#define MAX_CPUS 8
> +
> +#define MIN(a, b) ((a) < (b) ? (a) : (b))
Peter Xu is bringing MIN to libcflat with his edu series.
> +
> +typedef struct {
> + u64 timestamps[NR_TIMESTAMPS];
> +} write_buffer;
> +
> +typedef struct {
> + write_buffer *newbuf;
> + u64 time_before_flush;
> + u64 time_after_flush;
> +} audit_rec_t;
> +
> +typedef struct {
> + audit_rec_t records[NR_AUDIT_RECORDS];
> +} audit_buffer;
> +
> +typedef struct {
> + write_buffer *stable_pages;
> + write_buffer *dynamic_pages[NR_DYNAMIC_PAGES];
> + audit_buffer *audit;
> + unsigned int flush_count;
> +} test_data_t;
> +
> +static test_data_t test_data[MAX_CPUS];
> +
> +static cpumask_t ready;
> +static cpumask_t complete;
> +
> +static bool test_complete;
> +static bool flush_verbose;
> +static bool flush_by_page;
> +static int test_cycles=3;
> +static int secondary_cpus;
> +
> +static write_buffer * alloc_test_pages(void)
> +{
> + write_buffer *pg;
> + pg = calloc(NR_TIMESTAMPS, sizeof(u64));
> + return pg;
> +}
> +
> +static void setup_pages_for_cpu(int cpu)
> +{
> + unsigned int i;
> +
> + test_data[cpu].stable_pages = alloc_test_pages();
> +
> + for (i=0; i<NR_DYNAMIC_PAGES; i++) {
> + test_data[cpu].dynamic_pages[i] = alloc_test_pages();
> + }
> +
> + test_data[cpu].audit = calloc(NR_AUDIT_RECORDS, sizeof(audit_rec_t));
> +}
> +
> +static audit_rec_t * get_audit_record(audit_buffer *buf, unsigned int record)
> +{
> + return &buf->records[record];
> +}
> +
> +/* Sync on a given cpumask */
> +static void wait_on(int cpu, cpumask_t *mask)
> +{
Why take 'cpu' as a parameter. Just use smp_processor_id()
> + cpumask_set_cpu(cpu, mask);
> + while (!cpumask_full(mask))
> + cpu_relax();
> +}
> +
> +static uint64_t sync_start(void)
> +{
> + const uint64_t gate_mask = ~0x7ff;
> + uint64_t gate, now;
> + gate = get_cntvct() & gate_mask;
> + do {
> + now = get_cntvct();
> + } while ((now & gate_mask) == gate);
I'm not really sure what this function is doing. Trying to
get synchronized timestamps between cpus?
> +
> + return now;
> +}
> +
> +static void do_page_writes(void)
> +{
> + unsigned int i, runs = 0;
> + int cpu = smp_processor_id();
> + write_buffer *stable_pages = test_data[cpu].stable_pages;
> + write_buffer *moving_page = test_data[cpu].dynamic_pages[0];
> +
> + printf("CPU%d: ready %p/%p @ 0x%08" PRIx64"\n",
> + cpu, stable_pages, moving_page, get_cntvct());
> +
> + while (!test_complete) {
> + u64 run_start, run_end;
> +
> + smp_mb();
> + wait_on(cpu, &ready);
> + run_start = sync_start();
> +
> + for (i = 0; i < NR_TIMESTAMPS; i++) {
> + u64 ts = get_cntvct();
> + moving_page->timestamps[i] = ts;
> + stable_pages->timestamps[i] = ts;
> + }
> +
> + run_end = get_cntvct();
> + printf("CPU%d: run %d 0x%" PRIx64 "->0x%" PRIx64 " (%" PRId64 " cycles)\n",
> + cpu, runs++, run_start, run_end, run_end - run_start);
> +
> + /* wait on completion - gets clear my main thread*/
> + wait_on(cpu, &complete);
> + }
> +}
> +
> +
> +/*
> + * This is the core of the test. Timestamps are taken either side of
> + * the updating of the page table and the flush instruction. By
> + * keeping track of when the page mapping is changed we can detect any
> + * writes that shouldn't have made it to the other pages.
> + *
> + * This isn't the recommended way to update the page table. ARM
> + * recommends break-before-make so accesses that are in flight can
> + * trigger faults that can be handled cleanly.
> + */
> +
> +/* This mimics __flush_tlb_range from the kernel, doing a series of
> + * flush operations and then the dsb() to complete. */
> +static void flush_pages(unsigned long start, unsigned long end)
> +{
> + unsigned long addr;
> + start = start >> 12;
> + end = end >> 12;
Looks like you're assuming 4K pages, but AArch64 unit tests have 64K
pages. You're free to change that, but you'll need to disable and
re-enable the mmu with new parameters.
> +
> + dsb(ishst);
> + for (addr = start; addr < end; addr += 1 << (PAGE_SHIFT -12)) {
Hmm, start and end are 4K aligned, but now you do shift addr appropriately
for 64K pages. Why not just do
start &= PAGE_MASK;
end &= PAGE_MASK;
addr += PAGE_SIZE
> +#if defined(__aarch64__)
> + asm("tlbi vaae1is, %0" :: "r" (addr));
> +#else
> + asm volatile("mcr p15, 0, %0, c8, c7, 3" :: "r" (addr));
> +#endif
> + }
> + dsb(ish);
flush_pages() may be something we want in common code.
> +}
> +
> +static void remap_one_page(test_data_t *data)
> +{
> + u64 ts_before, ts_after;
> + int pg = (data->flush_count % (NR_DYNAMIC_PAGES + 1));
> + write_buffer *dynamic_pages_vaddr = data->dynamic_pages[0];
> + write_buffer *newbuf_paddr = data->dynamic_pages[pg];
> + write_buffer *end_page_paddr = newbuf_paddr+1;
> +
> + ts_before = get_cntvct();
> + /* update the page table */
> + mmu_set_range_ptes(mmu_idmap,
> + (unsigned long) dynamic_pages_vaddr,
> + (unsigned long) newbuf_paddr,
> + (unsigned long) end_page_paddr,
> + __pgprot(PTE_WBWA));
> + /* until the flush + isb() writes may still go to old address */
> + if (flush_by_page) {
> + flush_pages((unsigned long)dynamic_pages_vaddr, (unsigned long)(dynamic_pages_vaddr+1));
> + } else {
> + flush_tlb_all();
> + }
> + ts_after = get_cntvct();
> +
> + if (data->flush_count < NR_AUDIT_RECORDS) {
> + audit_rec_t *rec = get_audit_record(data->audit, data->flush_count);
> + rec->newbuf = newbuf_paddr;
> + rec->time_before_flush = ts_before;
> + rec->time_after_flush = ts_after;
> + }
> + data->flush_count++;
> +}
> +
> +static int check_pages(int cpu, char *msg,
> + write_buffer *base_page, write_buffer *test_page,
> + audit_buffer *audit, unsigned int flushes)
> +{
> + write_buffer *prev_page = base_page;
> + unsigned int empty = 0, write = 0, late = 0, weird = 0;
The variable 'weird' is a bit weird. How about 'bad'?
> + unsigned int ts_index = 0, audit_index;
> + u64 ts;
> +
> + /* For each audit record */
> + for (audit_index = 0; audit_index < MIN(flushes, NR_AUDIT_RECORDS); audit_index++) {
> + audit_rec_t *rec = get_audit_record(audit, audit_index);
> +
> + do {
> + /* Work through timestamps until we overtake
> + * this audit record */
> + ts = test_page->timestamps[ts_index];
> +
> + if (ts == 0) {
> + empty++;
> + } else if (ts < rec->time_before_flush) {
> + if (test_page == prev_page) {
> + write++;
> + } else {
> + late++;
> + }
> + } else if (ts >= rec->time_before_flush
> + && ts <= rec->time_after_flush) {
> + if (test_page == prev_page
> + || test_page == rec->newbuf) {
> + write++;
> + } else {
> + weird++;
> + }
> + } else if (ts > rec->time_after_flush) {
> + if (test_page == rec->newbuf) {
> + write++;
> + }
> + /* It's possible the ts is way ahead
> + * of the current record so we can't
> + * call a non-match weird...
> + *
> + * Time to skip to next audit record
> + */
> + break;
> + }
> +
> + ts = test_page->timestamps[ts_index++];
> + } while (ts <= rec->time_after_flush && ts_index < NR_TIMESTAMPS);
> +
> +
> + /* Next record */
> + prev_page = rec->newbuf;
> + } /* for each audit record */
> +
> + if (flush_verbose) {
> + printf("CPU%d: %s %p => %p %u/%u/%u/%u (0/OK/L/?) = %u total\n",
> + cpu, msg, test_page, base_page,
> + empty, write, late, weird, empty+write+late+weird);
> + }
> +
> + return weird;
> +}
> +
> +static int audit_cpu_pages(int cpu, test_data_t *data)
> +{
> + unsigned int pg, writes=0, ts_index = 0;
> + write_buffer *test_page;
> + int errors = 0;
> +
> + /* first the stable page */
> + test_page = data->stable_pages;
> + do {
> + if (test_page->timestamps[ts_index++]) {
> + writes++;
> + }
> + } while (ts_index < NR_TIMESTAMPS);
> +
> + if (writes != ts_index) {
> + errors += 1;
> + }
> +
> + if (flush_verbose) {
> + printf("CPU%d: stable page %p %u writes\n",
> + cpu, test_page, writes);
> + }
> +
> +
> + /* Restore the mapping for dynamic page */
> + test_page = data->dynamic_pages[0];
> +
> + mmu_set_range_ptes(mmu_idmap,
> + (unsigned long) test_page,
> + (unsigned long) test_page,
> + (unsigned long) &test_page[1],
> + __pgprot(PTE_WBWA));
> + flush_tlb_all();
> +
> + for (pg=0; pg<NR_DYNAMIC_PAGES; pg++) {
> + errors += check_pages(cpu, "dynamic page", test_page,
> + data->dynamic_pages[pg],
> + data->audit, data->flush_count);
> + }
> +
> + /* reset for next run */
> + memset(data->stable_pages, 0, sizeof(write_buffer));
> + for (pg=0; pg<NR_DYNAMIC_PAGES; pg++) {
> + memset(data->dynamic_pages[pg], 0, sizeof(write_buffer));
> + }
> + memset(data->audit, 0, sizeof(audit_buffer));
> + data->flush_count = 0;
> + smp_mb();
> +
> + report("CPU%d: checked, errors: %d", errors == 0, cpu, errors);
> + return errors;
> +}
> +
> +static void do_page_flushes(void)
> +{
> + int i, cpu;
> +
> + printf("CPU0: ready @ 0x%08" PRIx64"\n", get_cntvct());
> +
> + for (i=0; i<test_cycles; i++) {
> + unsigned int flushes=0;
> + u64 run_start, run_end;
> + int cpus_finished;
> +
> + cpumask_clear(&complete);
> + wait_on(0, &ready);
> + run_start = sync_start();
> +
> + do {
> + for_each_present_cpu(cpu) {
> + if (cpu == 0)
> + continue;
> +
> + /* do remap & flush */
> + remap_one_page(&test_data[cpu]);
> + flushes++;
> + }
> +
> + cpus_finished = cpumask_weight(&complete);
> + } while (cpus_finished < secondary_cpus);
> +
> + run_end = get_cntvct();
> +
> + printf("CPU0: run %d 0x%" PRIx64 "->0x%" PRIx64 " (%" PRId64 " cycles, %u flushes)\n",
> + i, run_start, run_end, run_end - run_start, flushes);
> +
> + /* Reset our ready mask for next cycle */
> + cpumask_clear_cpu(0, &ready);
> + smp_mb();
> + wait_on(0, &complete);
> +
> + /* Check for discrepancies */
> + for_each_present_cpu(cpu) {
> + if (cpu == 0)
> + continue;
> + audit_cpu_pages(cpu, &test_data[cpu]);
> + }
> + }
> +
> + test_complete = true;
> + smp_mb();
> + cpumask_set_cpu(0, &ready);
> + cpumask_set_cpu(0, &complete);
> +}
> +
> +int main(int argc, char **argv)
> +{
> + int cpu, i;
> +
> + for (i=0; i<argc; i++) {
> + char *arg = argv[i];
> + if (strcmp(arg, "verbose") == 0) {
> + flush_verbose = true;
> + }
> + if (strcmp(arg, "page") == 0) {
> + flush_by_page = true;
> + }
> + if (strstr(arg, "cycles=") != NULL) {
> + char *p = strstr(arg, "=");
> + test_cycles = atol(p+1);
We have parse_keyval for this. Radim has plans to improve
parse_keyval though, as nobody (including the author, me)
really like it as is...
> + }
> + }
> +
> + for_each_present_cpu(cpu) {
> + if (cpu == 0)
> + continue;
> +
> + setup_pages_for_cpu(cpu);
> + smp_boot_secondary(cpu, do_page_writes);
> + secondary_cpus++;
> + }
> +
> + /* CPU 0 does the flushes and checks the results */
> + do_page_flushes();
> +
> + return report_summary();
> +}
> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> index beaae84..7dc7799 100644
> --- a/arm/unittests.cfg
> +++ b/arm/unittests.cfg
> @@ -96,3 +96,15 @@ file = tlbflush-code.flat
> smp = $(($MAX_SMP>4?4:$MAX_SMP))
> extra_params = -append 'page self'
> groups = tlbflush
> +
> +[tlbflush-data::all]
> +file = tlbflush-data.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +groups = tlbflush
> +
> +[tlbflush-data::page]
> +file = tlbflush-data.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +extra_params = -append "page"
> +groups = tlbflush
> +
> --
> 2.10.1
>
Same style comments as last patch apply to this one too.
I skimmed this pretty quickly mostly looking at it wrt framework API and
style. And that looks pretty good to me.
Thanks,
drew
^ permalink raw reply
* [PATCH v3] clkdev: add devm_of_clk_get()
From: kbuild test robot @ 2016-11-28 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vav89chw.wl%kuninori.morimoto.gx@renesas.com>
Hi Kuninori,
[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.9-rc7 next-20161128]
[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/Kuninori-Morimoto/clkdev-add-devm_of_clk_get/20161128-173723
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-randconfig-x004-201648 (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 errors (new ones prefixed by >>):
>> drivers/clk/clk-devres.c:57:13: error: redefinition of 'devm_of_clk_get'
struct clk *devm_of_clk_get(struct device *dev,
^~~~~~~~~~~~~~~
In file included from drivers/clk/clk-devres.c:7:0:
include/linux/clk.h:518:27: note: previous definition of 'devm_of_clk_get' was here
static inline struct clk *devm_of_clk_get(struct device *dev,
^~~~~~~~~~~~~~~
vim +/devm_of_clk_get +57 drivers/clk/clk-devres.c
51 ret = devres_release(dev, devm_clk_release, devm_clk_match, clk);
52
53 WARN_ON(ret);
54 }
55 EXPORT_SYMBOL(devm_clk_put);
56
> 57 struct clk *devm_of_clk_get(struct device *dev,
58 struct device_node *np, int index)
59 {
60 struct clk **ptr, *clk;
---
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: 26142 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/a56b37e6/attachment-0001.gz>
^ permalink raw reply
* fwd, Re: [PATCH v3] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Arnd Bergmann @ 2016-11-28 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122213245.17955-1-code@mmayer.net>
[resending my mail, this time with devicetree, linux-clk, and linux-arm-kernel
on cc]
On Tuesday, November 22, 2016 1:32:45 PM CET Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> This CPUfreq driver provides basic frequency scaling for older Broadcom
> STB SoCs that do not use AVS firmware with DVFS support. There is no
> support for voltage scaling.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
This causes multiple build errors in linux-next, please fix asap or
drop the patch again. My feeling is that it's probably too late to
fix it for v4.10, but that's up to Viresh and Rafael of course.
> +#define BRCMSTB_CPUFREQ_PREFIX "brcmstb"
> +#define BRCMSTB_CPUFREQ_NAME BRCMSTB_CPUFREQ_PREFIX "-cpufreq"
> +
> +/* We search for these compatible strings. */
> +#define BRCMSTB_DT_CPU_CLK_CTRL "brcm,brcmstb-cpu-clk-div"
> +#define BRCMSTB_DT_MEMC_DDR "brcm,brcmstb-memc-ddr"
> +#define BRCM_AVS_CPU_DATA "brcm,avs-cpu-data-mem"
> +
> +/* We also need a few clocks in device tree. These are node names. */
> +#define BRCMSTB_CLK_MDIV_CH0 "cpu_mdiv_ch0"
> +#define BRCMSTB_CLK_NDIV_INT "cpu_ndiv_int"
> +#define BRCMSTB_CLK_SW_SCB "sw_scb"
Not critical but the use of those macros obfuscates the DT interfaces
here and made it harder to analyse what was going on.
Also, a couple of them are lacking a DT binding.
> +static int get_frequencies(const struct cpufreq_policy *policy,
> + unsigned int *vco_freq, unsigned int *cpu_freq,
> + unsigned int *scb_freq)
> +{
> + struct clk *cpu_ndiv_int, *sw_scb;
> +
> + cpu_ndiv_int = __clk_lookup(BRCMSTB_CLK_NDIV_INT);
> + if (!cpu_ndiv_int)
> + return -ENODEV;
> +
> + sw_scb = __clk_lookup(BRCMSTB_CLK_SW_SCB);
> + if (!sw_scb)
> + return -ENODEV;
> +
> + /* return frequencies in kHz */
> + *vco_freq = clk_get_rate(cpu_ndiv_int) / 1000;
> + *cpu_freq = clk_get_rate(policy->clk) / 1000;
> + *scb_freq = clk_get_rate(sw_scb) / 1000;
> +
> + return 0;
> +}
You really can't do this:
../drivers/cpufreq/brcmstb-cpufreq.c: In function 'get_frequencies':
../drivers/cpufreq/brcmstb-cpufreq.c:71:17: error: implicit declaration of function '__clk_lookup';did you mean 'key_lookup'? [-Werror=implicit-function-declaration]
cpu_ndiv_int = __clk_lookup(BRCMSTB_CLK_NDIV_INT);
^~~~~~~~~~~~
__clk_lookup is an internal API for the clk providers.
In particular, relying on undocumented internal names of the
clk provider in a device driver is inappropriate.
> +static const struct of_device_id brcmstb_cpufreq_match[] = {
> + { .compatible = BRCMSTB_DT_CPU_CLK_CTRL },
> + { }
> +};
> +MODULE_DEVICE_TABLE(platform, brcmstb_cpufreq_match);
This is a simple typo, also causing the build to fail:
FATAL: drivers/cpufreq/brcmstb-cpufreq: sizeof(struct platform_device_id)=24 is not a modulo of the size of section __mod_platform__<identifier>_device_table=392.
Arnd
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Icenowy Zheng @ 2016-11-28 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67akcT6z-xOdCzpLQRZbgNGh3E5akYEs1BvFNP1rH8UeA@mail.gmail.com>
28.11.2016, 18:07, "Chen-Yu Tsai" <wens@csie.org>:
> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>> ?As there's currently a fork of U-Boot which provides simplefb support
>
> Please add it when its finalized...
>
>> ?for H3, a simplefb node can be added to the device tree.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>>
>> ?I'm still not sure which pipeline should I use.
>
> You are supposed to add _all_ the pipelines that are available and
> supported by U-boot. U-boot is then supposed to enable and update
> the one it set up.
I mean the pipeline string ;-)
>
> ChenYu
>
>> ?And, it seems that HDMI Slow Clock is not needed?
>>
>> ?(seems that it's only for EDID, but simplefb won't use EDID)
>>
>> ??arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>> ??1 file changed, 16 insertions(+)
>>
>> ?diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>> ?index 75a8654..cacc8dd 100644
>> ?--- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> ?+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> ?@@ -50,6 +50,22 @@
>> ??/ {
>> ?????????interrupt-parent = <&gic>;
>>
>> ?+ chosen {
>> ?+ #address-cells = <1>;
>> ?+ #size-cells = <1>;
>> ?+ ranges;
>> ?+
>> ?+ simplefb_hdmi: framebuffer at 0 {
>> ?+ compatible = "allwinner,simple-framebuffer",
>> ?+ "simple-framebuffer";
>> ?+ allwinner,pipeline = "de0-lcd0-hdmi";
>> ?+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>> ?+ <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>> ?+ <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>> ?+ status = "disabled";
>> ?+ };
>> ?+ };
>> ?+
>> ?????????cpus {
>> ?????????????????#address-cells = <1>;
>> ?????????????????#size-cells = <0>;
>> ?--
>> ?2.10.2
^ permalink raw reply
* [PATCH renesas-next 1/3] ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-28 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVGXQMRU-tn2EtrSAZXMLhBMNkHsxOtvUJ9duxR_Tnsxg@mail.gmail.com>
On Fri, Nov 25, 2016 at 09:58:40AM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 24, 2016 at 9:15 PM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Use the SoC-specific compat string for mmcif in DT for the r8a73a4 SoC.
> > This is in keeping with the use of compat strings for mmcif for other
> > Renesas ARM based SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued up this and the following two patches for v4.11.
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Chen-Yu Tsai @ 2016-11-28 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <496171480328390@web15g.yandex.ru>
On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
>
> 28.11.2016, 18:07, "Chen-Yu Tsai" <wens@csie.org>:
>> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
>>> As there's currently a fork of U-Boot which provides simplefb support
>>
>> Please add it when its finalized...
>>
>>> for H3, a simplefb node can be added to the device tree.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>> ---
>>>
>>> I'm still not sure which pipeline should I use.
>>
>> You are supposed to add _all_ the pipelines that are available and
>> supported by U-boot. U-boot is then supposed to enable and update
>> the one it set up.
>
> I mean the pipeline string ;-)
Looks good to me. There's no separate frontend/backend in DE 2.0.
ChenYu
>
>>
>> ChenYu
>>
>>> And, it seems that HDMI Slow Clock is not needed?
>>>
>>> (seems that it's only for EDID, but simplefb won't use EDID)
>>>
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 75a8654..cacc8dd 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -50,6 +50,22 @@
>>> / {
>>> interrupt-parent = <&gic>;
>>>
>>> + chosen {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + simplefb_hdmi: framebuffer at 0 {
>>> + compatible = "allwinner,simple-framebuffer",
>>> + "simple-framebuffer";
>>> + allwinner,pipeline = "de0-lcd0-hdmi";
>>> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>>> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>>> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +
>>> cpus {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> --
>>> 2.10.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1695441.JP1H7VIm1f@avalon>
On 11/28/2016 11:02 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
>> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
>>> On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
>>>> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
>>>>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>
>>>>>> .../bindings/display/meson/meson-drm.txt | 134
>>>>>> +++++++++++++++
>>>>>> 1 file changed, 134 insertions(+)
>>>>>> create mode 100644
>>>>>>
>>>>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new
>>>>>> file
>>>>>> mode 100644
>>>>>> index 0000000..89c1b5f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> [...]
>>
>>>>>> +
>>>>>> +VENC CBVS Output
>>>>>> +----------------------
>>>>>> +
>>>>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>>>>>> +
>>>>>> +Required properties:
>>>>>> + - compatible: value must be one of:
>>>>>> + - compatible: value should be different for each SoC family as :
>>>>> One of those two lines is redundant.
>>>>
>>>> Will fix.
>>>>
>>>>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>>>>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>>>>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>>>>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>>>>>> +
>>>>>
>>>>> No registers ? Are the encoders registers part of the VPU register
>>>>> space, intertwined in a way that they can't be specified separately here
>>>>> ?
>>>>
>>>> Exact, all the video registers on the Amlogic SoC are part of a long
>>>> history of fixup/enhance from very old SoCs, it's quite hard to
>>>> distinguish a Venc registers array since they are mixed with the
>>>> multiple encoders registers...
>>>
>>> In that case is there really a reason to model the encoders as separate
>>> nodes in DT ?
>>
>> Here, it more the encoder-connector couple that is represented as a node,
>> and the CVBS output is optional.
>
> You should actually have a DT node for the connector. I would merge the
> encoders into the VPU node (especially given that according to your diagram
> they are part of the VPU), and document the VPU output ports explicitly. If
> the CVBS output is not implemented by some of the SoCs in the family then the
> corresponding DT node should just omit that port.
>
Yes, seems a way better option !
[...]
Thanks for the hints,
Neil
^ permalink raw reply
* [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 73adbaa9ac86..a3981cc6448a 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1396,6 +1396,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
>
> + /* Mask prohibited EEE modes */
> + val &= ~phydev->eee_broken_modes;
> +
> phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
>
> return 0;
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index ba86c191a13e..83e52f1b80f2 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1121,6 +1121,43 @@ static int genphy_config_advert(struct phy_device *phydev)
> }
>
> /**
> + * genphy_config_eee_advert - disable unwanted eee mode advertisement
> + * @phydev: target phy_device struct
> + *
> + * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
> + * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
> + * changed, and 1 if it has changed.
> + */
> +static int genphy_config_eee_advert(struct phy_device *phydev)
> +{
> + u32 broken = phydev->eee_broken_modes;
> + u32 old_adv, adv;
> +
> + /* Nothing to disable */
> + if (!broken)
> + return 0;
> +
> + /* If the following call fails, we assume that EEE is not
> + * supported by the phy. If we read 0, EEE is not advertised
> + * In both case, we don't need to continue
> + */
> + adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
> + if (adv <= 0)
> + return 0;
> +
> + old_adv = adv;
> + adv &= ~broken;
> +
> + /* Advertising remains unchanged with the broken mask */
> + if (old_adv == adv)
> + return 0;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
> +
> + return 1;
> +}
> +
> +/**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> *
> @@ -1178,15 +1215,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
> */
> int genphy_config_aneg(struct phy_device *phydev)
> {
> - int result;
> + int err, changed;
> +
> + changed = genphy_config_eee_advert(phydev);
>
> if (AUTONEG_ENABLE != phydev->autoneg)
> return genphy_setup_forced(phydev);
>
> - result = genphy_config_advert(phydev);
> - if (result < 0) /* error */
> - return result;
> - if (result == 0) {
> + err = genphy_config_advert(phydev);
> + if (err < 0) /* error */
> + return err;
> +
> + changed |= err;
> +
> + if (changed == 0) {
> /* Advertisement hasn't changed, but maybe aneg was never on to
> * begin with? Or maybe phy was isolated?
> */
> @@ -1196,16 +1238,16 @@ int genphy_config_aneg(struct phy_device *phydev)
> return ctl;
>
> if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
> - result = 1; /* do restart aneg */
> + changed = 1; /* do restart aneg */
> }
>
> /* Only restart aneg if we are advertising something different
> * than we were before.
> */
> - if (result > 0)
> - result = genphy_restart_aneg(phydev);
> + if (changed > 0)
> + return genphy_restart_aneg(phydev);
>
> - return result;
> + return 0;
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> @@ -1563,6 +1605,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
> __set_phy_supported(phydev, max_speed);
> }
>
> +static void of_set_phy_eee_broken(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + u32 broken;
> +
> + if (!IS_ENABLED(CONFIG_OF_MDIO))
> + return;
> +
> + if (!node)
> + return;
> +
> + if (!of_property_read_u32(node, "eee-broken-modes", &broken))
> + phydev->eee_broken_modes = broken;
> +}
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1600,6 +1657,11 @@ static int phy_probe(struct device *dev)
> of_set_phy_supported(phydev);
> phydev->advertising = phydev->supported;
>
> + /* Get the EEE modes we want to prohibit. We will ask
> + * the PHY stop advertising these mode later on
> + */
> + of_set_phy_eee_broken(phydev);
> +
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index edde28ce163a..b53177fd38af 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -417,6 +417,9 @@ struct phy_device {
> u32 advertising;
> u32 lp_advertising;
>
> + /* Energy efficient ethernet modes which should be prohibited */
> + u32 eee_broken_modes;
> +
> int autoneg;
>
> int link_timeout;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
>
> diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
> new file mode 100644
> index 000000000000..99c6d903d439
> --- /dev/null
> +++ b/include/dt-bindings/net/mdio.h
> @@ -0,0 +1,19 @@
> +/*
> + * This header provides generic constants for ethernet MDIO bindings
> + */
> +
> +#ifndef _DT_BINDINGS_NET_MDIO_H
> +#define _DT_BINDINGS_NET_MDIO_H
> +
> +/*
> + * EEE capability Advertisement
> + */
> +
> +#define MDIO_EEE_100TX 0x0002 /* 100TX EEE cap */
> +#define MDIO_EEE_1000T 0x0004 /* 1000T EEE cap */
> +#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> +#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap */
> +#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap */
> +#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap */
> +
> +#endif
> --
> 2.7.4
>
^ permalink raw reply
* [kvm-unit-tests PATCH v7 09/11] arm/locking-tests: add comprehensive locking test
From: Andrew Jones @ 2016-11-28 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-10-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:31PM +0000, Alex Benn?e wrote:
> This test has been written mainly to stress multi-threaded TCG behaviour
> but will demonstrate failure by default on real hardware. The test takes
> the following parameters:
>
> - "lock" use GCC's locking semantics
> - "atomic" use GCC's __atomic primitives
> - "wfelock" use WaitForEvent sleep
> - "excl" use load/store exclusive semantics
>
> Also two more options allow the test to be tweaked
>
> - "noshuffle" disables the memory shuffling
> - "count=%ld" set your own per-CPU increment count
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>
> ---
> v2
> - Don't use thumb style strexeq stuff
> - Add atomic and wfelock tests
> - Add count/noshuffle test controls
> - Move barrier tests to separate test file
> v4
> - fix up unitests.cfg to use correct test name
> - move into "locking" group, remove barrier tests
> - use a table to add tests, mark which are expected to work
> - correctly report XFAIL
> v5
> - max out at -smp 4 in unittest.cfg
> v7
> - make test control flags bools
> - default the count to 100000 (so it doesn't timeout)
> ---
> arm/Makefile.common | 2 +
> arm/locking-test.c | 302 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> arm/unittests.cfg | 34 ++++++
> 3 files changed, 338 insertions(+)
> create mode 100644 arm/locking-test.c
>
> diff --git a/arm/Makefile.common b/arm/Makefile.common
> index 528166d..eb4cfdf 100644
> --- a/arm/Makefile.common
> +++ b/arm/Makefile.common
> @@ -15,6 +15,7 @@ tests-common += $(TEST_DIR)/pci-test.flat
> tests-common += $(TEST_DIR)/gic.flat
> tests-common += $(TEST_DIR)/tlbflush-code.flat
> tests-common += $(TEST_DIR)/tlbflush-data.flat
> +tests-common += $(TEST_DIR)/locking-test.flat
>
> all: test_cases
>
> @@ -85,3 +86,4 @@ test_cases: $(generated_files) $(tests-common) $(tests)
> $(TEST_DIR)/selftest.o $(cstart.o): $(asm-offsets)
> $(TEST_DIR)/tlbflush-code.elf: $(cstart.o) $(TEST_DIR)/tlbflush-code.o
> $(TEST_DIR)/tlbflush-data.elf: $(cstart.o) $(TEST_DIR)/tlbflush-data.o
> +$(TEST_DIR)/locking-test.elf: $(cstart.o) $(TEST_DIR)/locking-test.o
Instead of adding a new test file, please extend the one we already have,
which iirc was the first MTTCG test, arm/spinlock-test.c. If you don't
like the naming or code in spinlock-test.c, then feel free to change it,
delete it. It's currently not getting run by arm/unittests.cfg, and it's
not getting maintained.
> diff --git a/arm/locking-test.c b/arm/locking-test.c
> new file mode 100644
> index 0000000..f10c61b
> --- /dev/null
> +++ b/arm/locking-test.c
> @@ -0,0 +1,302 @@
> +#include <libcflat.h>
> +#include <asm/smp.h>
> +#include <asm/cpumask.h>
> +#include <asm/barrier.h>
> +#include <asm/mmu.h>
> +
> +#include <prng.h>
> +
> +#define MAX_CPUS 8
> +
> +/* Test definition structure
> + *
> + * A simple structure that describes the test name, expected pass and
> + * increment function.
> + */
> +
> +/* Function pointers for test */
> +typedef void (*inc_fn)(int cpu);
> +
> +typedef struct {
> + const char *test_name;
> + bool should_pass;
> + inc_fn main_fn;
> +} test_descr_t;
> +
> +/* How many increments to do */
> +static int increment_count = 1000000;
> +static bool do_shuffle = true;
> +
> +/* Shared value all the tests attempt to safely increment using
> + * various forms of atomic locking and exclusive behaviour.
> + */
> +static unsigned int shared_value;
> +
> +/* PAGE_SIZE * uint32_t means we span several pages */
> +__attribute__((aligned(PAGE_SIZE))) static uint32_t memory_array[PAGE_SIZE];
> +
> +/* We use the alignment of the following to ensure accesses to locking
> + * and synchronisation primatives don't interfere with the page of the
> + * shared value
> + */
> +__attribute__((aligned(PAGE_SIZE))) static unsigned int per_cpu_value[MAX_CPUS];
> +__attribute__((aligned(PAGE_SIZE))) static cpumask_t smp_test_complete;
> +__attribute__((aligned(PAGE_SIZE))) struct isaac_ctx prng_context[MAX_CPUS];
> +
> +/* Some of the approaches use a global lock to prevent contention. */
> +static int global_lock;
> +
> +/* In any SMP setting this *should* fail due to cores stepping on
> + * each other updating the shared variable
> + */
> +static void increment_shared(int cpu)
> +{
> + (void)cpu;
> +
> + shared_value++;
> +}
> +
> +/* GCC __sync primitives are deprecated in favour of __atomic */
> +static void increment_shared_with_lock(int cpu)
> +{
> + (void)cpu;
> +
> + while (__sync_lock_test_and_set(&global_lock, 1));
> + shared_value++;
> + __sync_lock_release(&global_lock);
> +}
> +
> +/* In practice even __ATOMIC_RELAXED uses ARM's ldxr/stex exclusive
> + * semantics */
> +static void increment_shared_with_atomic(int cpu)
> +{
> + (void)cpu;
> +
> + __atomic_add_fetch(&shared_value, 1, __ATOMIC_SEQ_CST);
> +}
> +
> +
> +/*
> + * Load/store exclusive with WFE (wait-for-event)
> + *
> + * See ARMv8 ARM examples:
> + * Use of Wait For Event (WFE) and Send Event (SEV) with locks
> + */
> +
> +static void increment_shared_with_wfelock(int cpu)
> +{
> + (void)cpu;
> +
> +#if defined(__aarch64__)
> + asm volatile(
> + " mov w1, #1\n"
> + " sevl\n"
> + " prfm PSTL1KEEP, [%[lock]]\n"
> + "1: wfe\n"
> + " ldaxr w0, [%[lock]]\n"
> + " cbnz w0, 1b\n"
> + " stxr w0, w1, [%[lock]]\n"
> + " cbnz w0, 1b\n"
> + /* lock held */
> + " ldr w0, [%[sptr]]\n"
> + " add w0, w0, #0x1\n"
> + " str w0, [%[sptr]]\n"
> + /* now release */
> + " stlr wzr, [%[lock]]\n"
> + : /* out */
> + : [lock] "r" (&global_lock), [sptr] "r" (&shared_value) /* in */
> + : "w0", "w1", "cc");
> +#else
> + asm volatile(
> + " mov r1, #1\n"
> + "1: ldrex r0, [%[lock]]\n"
> + " cmp r0, #0\n"
> + " wfene\n"
> + " strexeq r0, r1, [%[lock]]\n"
> + " cmpeq r0, #0\n"
> + " bne 1b\n"
> + " dmb\n"
> + /* lock held */
> + " ldr r0, [%[sptr]]\n"
> + " add r0, r0, #0x1\n"
> + " str r0, [%[sptr]]\n"
> + /* now release */
> + " mov r0, #0\n"
> + " dmb\n"
> + " str r0, [%[lock]]\n"
> + " dsb\n"
> + " sev\n"
> + : /* out */
> + : [lock] "r" (&global_lock), [sptr] "r" (&shared_value) /* in */
> + : "r0", "r1", "cc");
> +#endif
> +}
> +
> +
> +/*
> + * Hand-written version of the load/store exclusive
> + */
> +static void increment_shared_with_excl(int cpu)
> +{
> + (void)cpu;
> +
> +#if defined(__aarch64__)
> + asm volatile(
> + "1: ldxr w0, [%[sptr]]\n"
> + " add w0, w0, #0x1\n"
> + " stxr w1, w0, [%[sptr]]\n"
> + " cbnz w1, 1b\n"
> + : /* out */
> + : [sptr] "r" (&shared_value) /* in */
> + : "w0", "w1", "cc");
> +#else
> + asm volatile(
> + "1: ldrex r0, [%[sptr]]\n"
> + " add r0, r0, #0x1\n"
> + " strex r1, r0, [%[sptr]]\n"
> + " cmp r1, #0\n"
> + " bne 1b\n"
> + : /* out */
> + : [sptr] "r" (&shared_value) /* in */
> + : "r0", "r1", "cc");
> +#endif
> +}
> +
> +/* Test array */
> +static test_descr_t tests[] = {
> + { "none", false, increment_shared },
> + { "lock", true, increment_shared_with_lock },
> + { "atomic", true, increment_shared_with_atomic },
> + { "wfelock", true, increment_shared_with_wfelock },
> + { "excl", true, increment_shared_with_excl }
> +};
> +
> +/* The idea of this is just to generate some random load/store
> + * activity which may or may not race with an un-barried incremented
> + * of the shared counter
> + */
> +static void shuffle_memory(int cpu)
> +{
> + int i;
> + uint32_t lspat = isaac_next_uint32(&prng_context[cpu]);
> + uint32_t seq = isaac_next_uint32(&prng_context[cpu]);
> + int count = seq & 0x1f;
> + uint32_t val=0;
> +
> + seq >>= 5;
> +
> + for (i=0; i<count; i++) {
> + int index = seq & ~PAGE_MASK;
> + if (lspat & 1) {
> + val ^= memory_array[index];
> + } else {
> + memory_array[index] = val;
> + }
> + seq >>= PAGE_SHIFT;
> + seq ^= lspat;
> + lspat >>= 1;
> + }
> +
extra line here
> +}
> +
> +static inc_fn increment_function;
> +
> +static void do_increment(void)
> +{
> + int i;
> + int cpu = smp_processor_id();
> +
> + printf("CPU%d: online and ++ing\n", cpu);
> +
> + for (i=0; i < increment_count; i++) {
> + per_cpu_value[cpu]++;
> + increment_function(cpu);
> +
> + if (do_shuffle)
> + shuffle_memory(cpu);
> + }
> +
> + printf("CPU%d: Done, %d incs\n", cpu, per_cpu_value[cpu]);
> +
> + cpumask_set_cpu(cpu, &smp_test_complete);
> + if (cpu != 0)
> + halt();
> +}
> +
> +static void setup_and_run_test(test_descr_t *test)
> +{
> + unsigned int i, sum = 0;
> + int cpu, cpu_cnt = 0;
> +
> + increment_function = test->main_fn;
> +
> + /* fill our random page */
> + for (i=0; i<PAGE_SIZE; i++) {
> + memory_array[i] = isaac_next_uint32(&prng_context[0]);
> + }
> +
> + for_each_present_cpu(cpu) {
> + uint32_t seed2 = isaac_next_uint32(&prng_context[0]);
> + cpu_cnt++;
> + if (cpu == 0)
> + continue;
> +
> + isaac_init(&prng_context[cpu], (unsigned char *) &seed2, sizeof(seed2));
> + smp_boot_secondary(cpu, do_increment);
> + }
> +
> + do_increment();
> +
> + while (!cpumask_full(&smp_test_complete))
> + cpu_relax();
> +
> + /* All CPUs done, do we add up */
> + for_each_present_cpu(cpu) {
> + sum += per_cpu_value[cpu];
> + }
> +
> + if (test->should_pass) {
> + report("total incs %d", sum == shared_value, shared_value);
> + } else {
> + report_xfail("total incs %d", true, sum == shared_value, shared_value);
> + }
> +}
> +
> +int main(int argc, char **argv)
> +{
> + static const unsigned char seed[] = "myseed";
> + test_descr_t *test = &tests[0];
> + int i;
> + unsigned int j;
> +
> + isaac_init(&prng_context[0], &seed[0], sizeof(seed));
> +
> + for (i=0; i<argc; i++) {
> + char *arg = argv[i];
> +
> + /* Check for test name */
> + for (j = 0; j < ARRAY_SIZE(tests); j++) {
> + if (strcmp(arg, tests[j].test_name) == 0)
> + test = &tests[j];
> + }
> +
> + /* Test modifiers */
> + if (strcmp(arg, "noshuffle") == 0) {
> + do_shuffle = false;
> + report_prefix_push("noshuffle");
> + } else if (strstr(arg, "count=") != NULL) {
> + char *p = strstr(arg, "=");
> + increment_count = atol(p+1);
> + } else {
> + isaac_reseed(&prng_context[0], (unsigned char *) arg, strlen(arg));
> + }
> + }
> +
> + if (test) {
> + setup_and_run_test(test);
> + } else {
> + report("Unknown test", false);
> + }
> +
> + return report_summary();
> +}
> diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> index 7dc7799..abbfe79 100644
> --- a/arm/unittests.cfg
> +++ b/arm/unittests.cfg
> @@ -108,3 +108,37 @@ smp = $(($MAX_SMP>4?4:$MAX_SMP))
> extra_params = -append "page"
> groups = tlbflush
>
> +# Locking tests
> +[locking::none]
> +file = locking-test.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +groups = locking
> +accel = tcg
> +
> +[locking::lock]
> +file = locking-test.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +extra_params = -append 'lock'
> +groups = locking
> +accel = tcg
> +
> +[locking::atomic]
> +file = locking-test.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +extra_params = -append 'atomic'
> +groups = locking
> +accel = tcg
> +
> +[locking::wfelock]
> +file = locking-test.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +extra_params = -append 'wfelock'
> +groups = locking
> +accel = tcg
> +
> +[locking::excl]
> +file = locking-test.flat
> +smp = $(($MAX_SMP>4?4:$MAX_SMP))
> +extra_params = -append 'excl'
> +groups = locking
> +accel = tcg
> --
> 2.10.1
>
I didn't look too closely at this one...
Thanks,
drew
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Adrian Hunter @ 2016-11-28 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <982d633b-e9c4-0f10-052b-e324f094d0f5@xilinx.com>
On 28/11/16 09:32, Michal Simek wrote:
> +Sai for Xilinx perspective.
>
> On 25.11.2016 16:24, Sebastian Frias wrote:
>> Hi,
>>
>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>> "Hardware initialized registers"
>>
>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>> AHB Host Controller", revision 6.0 document)
>>
>> In some platforms those signals are connected to registers that need to
>> be programmed at some point for proper driver/HW initialisation.
>>
>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>> that is called from within 'sdhci_pltfm_init', and that seems a good
>> candidate for a place to program those registers (*).
>>
>> Do you agree?
We already killed .platform_init
What is wrong with sdhci_arasan_probe()?
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>> (*): This has been prototyped on 4.7 as working properly.
>> However, upstream commit:
>>
>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>> Author: Douglas Anderson <dianders@chromium.org>
>> Date: Mon Jun 20 10:56:47 2016 -0700
>>
>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>> ...
>>
>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>> struct is used after that commit.
>>
>
>
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Sebastian Frias @ 2016-11-28 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b7f113e-34f9-69f4-a45f-9fd687d87990@gmail.com>
On 25/11/16 18:44, Florian Fainelli wrote:
> On 11/25/2016 03:13 AM, Sebastian Frias wrote:
>> On 24/11/16 19:55, Florian Fainelli wrote:
<snip>
>>> Correct, the meaning of PHY_INTERFACE_MODE should be from the
>>> perspective of the PHY device:
>>>
>>> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
>>> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
>>> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
>>> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
>>>
>>
>> Thanks for the explanation.
>> Actually I had thought that the delay was to account for board routing
>> (wires) between the MAC and the PHY.
>> From your explanation it appears that the delay is to account for board
>> routing (wires) between the PHY and the RJ45 socket.
>
> The placement of the (delay) was not meant to be exact, but it was
> wrongly place anyway, so it should be between the MAC and PHY, always.
> This is why you see people either fixing the need for a delay by
> appropriately programming the PHY, or the MAC, or by just inserting a
> fixed delay on the PCB between the PHY and the MAC and programming no
> delays (or using the default values and hoping this works).
Thanks.
Your patch "[PATCH net-next 3/4] Documentation: net: phy: Add blurb about
RGMII" on the documentation makes it clear.
>>>
>>> This also seems reasonable to do, provided that the PHY is also properly
>>> configured not to add delays in both directions, and therefore assumes
>>> that the MAC does it.
>>>
>>> We have a fairly large problem with how RGMII delays are done in PHYLIB
>>> and Ethernet MAC drivers (or just in general), where we can't really
>>> intersect properly what a PHY is supporting (in terms of internal
>>> delays), and what the MAC supports either. One possible approach could
>>> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
>>> support (ideally, even with normalized nanosecond delay values),
>>
>> Just to make sure I understood this, the DT would say something like:
>>
>> phy-connection-type = "rgmii-txid";
>> txid-delay-ns = <3>;
>>
>> For a 3ns TX delay, would that be good?
>
> That's one possibility, although, see below, some PHYs support
> sub-nanosecond values, but in general, that seems like a good
> representation. If the "txid-delay-ns" property is omitted, a standard
> 2ns delay is assumed.
Sounds good.
I did not see the "txid-delay-ns" property documented in your patches, if
it is not too late, maybe it could be "txid-delay-ps" using picoseconds as
unit, right?
>>> and
>>> then intersect that with the requested phy_interface_t during
>>> phy_{attach,connect} time, and feed this back to the MAC with a special
>>> error code/callback, so we could gracefully try to choose another
>>> PHY_INTERFACE_MODE_* value that the MAC supports....
>>>
>>> A larger problem is that a number of drivers have been deployed, and
>>> Device Trees, possibly with the meaning of "phy-mode" and
>>> "phy-connection-type" being from the MAC perspective, and not the PHY
>>> perspective *sigh*, good luck auditing those.
>>>
>>> So from there, here is possibly what we could do
>>>
>>> - submit a series of patches that update the PHYLIB documentation (there
>>> are other things missing here) and make it clear from which entity (PHY
>>> or MAC) does the delay apply to, document the "intersection" problem here
>>
>> I think documenting is necessary, thanks in advance!
>>
>> However, I'm wondering if there's a way to make this work in all cases.
>> Indeed, if we consider for example that TX delay is required, we have 4
>> cases:
>>
>> PHY | MAC | Who applies?
>> TXID supported | TXID supported | PHY
>> TXID supported | TXID not supported | PHY
>> TXID not supported | TXID supported | MAC
>> TXID not supported | TXID not supported | cannot be done
>>
>> That is basically what my patch:
>>
>> https://marc.info/?l=linux-netdev&m=147869658031783&w=2
>>
>> attempted to achieve. That would allow more combinations of MAC<->PHY to
>> work, right?
>
> Yes, indeed.
Just one thing, from your patch "[PATCH net-next 3/4] Documentation: net:
phy: Add blurb about RGMII" I have the impression that the 3rd option from
the table above, would be a little bit more complex to implement.
I will comment on the patch.
>> Nevertheless, I think we also need to keep in mind that most of this
>> discussion assumes the case where both, MAC and PHY have equal capabilities.
>> Could it happen that the PHY supports only 2ns delay, and the MAC only
>> 1ns delay?
>
> I doubt this exists at the MAC level what we should have is either a 2ns
> delay, in either RX or TX path, or nothing, because that's the value
> that results in shifting the data lines and the RX/TX lines by 90
> degrees at 125Mhz (1/125^6 = 8 ns, one quarter shift is 90 degrees =
> 2ns). The PHY may have a similar set of pre-programmed, fixed 2ns
> delays, but it is not uncommon to see 0.X ns resolution available:
>
> drivers/net/phy/mscc.c
> drivers/net/phy/dp83867.c w/ arch/arm/boot/dts/dra72-evm-revc.dts
>
> In these cases, if you end-up using a non 2ns delay, you are fixing a
> PCB problem more than an interoperability problem between your MAC and PHY.
I see, thanks.
>> Could it happen that the delay is bigger than what is supported by
>> either the PHY or MAC alone? maybe if combined it could work, for example
>> a 3ns delay required and the PHY supporting 2ns and the MAC 1ns, combined
>> it could work?
>
> I suppose such a thing would work yes, but it would be difficult to
> report correctly to the core PHYLIB how this can work considering the
> vast array of options available to introduce delays in that case:
> MAC-level, PHY-level, pinctrl/pad level and possibly at the PCB itself.
>
> Once we can't rely on the fixed 2ns delay to work, we are going to have
> people do various experiments until they can either measure what the
> right delay value is for the specific PCB, or they just found the value
> that happens to work. I don't think we can do much at that point from a
> core PHYLIB perspective other than tell the network driver that the PHY
> supports delay in either RX, TX or both directions, and have the MAC
> decide what to apply that makes sense here, considering that this is
> already kind of an exceptional situation to be in.
Fair enough.
And thanks again for documenting this.
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480272700-28888-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
> To more consistently reference nodes by label, add labels for sata,
> usb2, sdhci and usb3 nodes.
>
> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
Please don't do this for clearfog - there's changes in the pipeline which
completely replace armada-388-clearfog.dts because there's a "base" and
"pro" versions of this hardware now, and making such a huge change will
effectively mean we have to start over with the DT files.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-1-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and getting them cleaned up for merging.
>
> Some of the patches might be worth taking now if the maintainers are
> happy to do so (run_test tweaks, libcflat updates?). The others could
> do with more serious review. I've CC'd some of the ARM guys to look
> over the tlbflush/barrier tests so they can cast their expert eyes
> over them ;-)
>
> There are two additions to the series.
>
> The tcg-test is a general torture test aimed at QEMU's TCG execution
> model. It stresses the cpu execution loop through the use of
> cross-page and computed jumps. It can also add IRQ's and self-modifying
> code to the mix.
>
> The tlbflush-data test is a new one, the old tlbflush test is renamed
> tlbflush-code to better indicate the code path it exercise. The the
> code test tests the translation invalidation pathways in QEMU the data
> test exercises the SoftMMU's TLBs and explicitly that tlbflush
> completion semantics are correct.
>
> The tlbflush-data passes most of the times on real hardware but
> definitely showed the problem with deferred TLB flushes running under
> MTTCG QEMU. I've looked at some of the failure cases on real hardware
> and it did look like a timestamp appeared on a page that shouldn't
> have been accessible at the time - I don't know if this is a real
> silicon bug or my misreading of the semantics so I'd appreciate
> a comment from the experts.
>
> The code needs to be applied on top of Drew's latest ARM GIC patches
> or you can grab my tree from:
>
> https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v7
Thanks Alex,
I've skimmed over everything looking at it from a framwork/sytle
perspective. I didn't dig in trying to understand the tests though.
One general comment, I see many tests introduce MAX_CPUS 8. Why do
that? Why not allow all cpus by using NR_CPUS for the array sizes?
Thanks,
drew
>
> Cheers,
>
> Alex.
>
> Alex Benn?e (11):
> run_tests: allow forcing of acceleration mode
> run_tests: allow disabling of timeouts
> run_tests: allow passing of options to QEMU
> libcflat: add PRI(dux)32 format types
> lib: add isaac prng library from CCAN
> arm/Makefile.common: force -fno-pic
> arm/tlbflush-code: Add TLB flush during code execution test
> arm/tlbflush-data: Add TLB flush during data writes test
> arm/locking-tests: add comprehensive locking test
> arm/barrier-litmus-tests: add simple mp and sal litmus tests
> arm/tcg-test: some basic TCG exercising tests
>
> Makefile | 2 +
> arm/Makefile.arm | 2 +
> arm/Makefile.arm64 | 2 +
> arm/Makefile.common | 11 ++
> arm/barrier-litmus-test.c | 437 ++++++++++++++++++++++++++++++++++++++++++++++
> arm/locking-test.c | 302 ++++++++++++++++++++++++++++++++
> arm/tcg-test-asm.S | 170 ++++++++++++++++++
> arm/tcg-test-asm64.S | 169 ++++++++++++++++++
> arm/tcg-test.c | 337 +++++++++++++++++++++++++++++++++++
> arm/tlbflush-code.c | 212 ++++++++++++++++++++++
> arm/tlbflush-data.c | 401 ++++++++++++++++++++++++++++++++++++++++++
> arm/unittests.cfg | 190 ++++++++++++++++++++
> lib/arm/asm/barrier.h | 63 ++++++-
> lib/arm64/asm/barrier.h | 50 ++++++
> lib/libcflat.h | 5 +
> lib/prng.c | 162 +++++++++++++++++
> lib/prng.h | 82 +++++++++
> run_tests.sh | 18 +-
> scripts/functions.bash | 13 +-
> scripts/runtime.bash | 8 +
> 20 files changed, 2626 insertions(+), 10 deletions(-)
> create mode 100644 arm/barrier-litmus-test.c
> create mode 100644 arm/locking-test.c
> create mode 100644 arm/tcg-test-asm.S
> create mode 100644 arm/tcg-test-asm64.S
> create mode 100644 arm/tcg-test.c
> create mode 100644 arm/tlbflush-code.c
> create mode 100644 arm/tlbflush-data.c
> create mode 100644 lib/prng.c
> create mode 100644 lib/prng.h
>
> --
> 2.10.1
>
>
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jean-Francois Moine @ 2016-11-28 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128095900.27615-1-icenowy@aosc.xyz>
On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng <icenowy@aosc.xyz> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> I'm still not sure which pipeline should I use.
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?
In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86f2b643-c270-1483-4f35-5bdf399a5919@ti.com>
2016-11-28 8:58 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
>> On 28/11/16 07:24, Sekhar Nori wrote:
>>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>>>> It has been determined that the maximum resolution supported correctly
>>>> by tilcdc rev1 on da850 SoCs is 800x600 at 60. Due to memory throughput
>>>> constraints we must filter out higher modes.
>>>>
>>>> Specify the max-bandwidth property for the display node for
>>>> da850-based boards.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 8e30d9b..9b7c444 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -452,6 +452,7 @@
>>>> compatible = "ti,da850-tilcdc";
>>>> reg = <0x213000 0x1000>;
>>>> interrupts = <52>;
>>>> + max-bandwidth = <28800000>;
>>>
>>> If this is effectively the max pixel clock that the device supports,
>>> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
>>
>> There's a separate property for max-pixelclock. This one is maximum
>> pixels per second (which does sound almost the same), but the doc says
>> it's about the particular memory interface + LCDC combination.
>
> DA850 supports both mDDR and DDR2, at slightly different speeds. So
> memory bandwidth limitation is also board specific. This should probably
> move to board file.
>
> But I would like to know why using max-pixelclock is not good enough.
> Have experiments shown that LCDC on DA850 LCDK underflows even if pixel
> clock is below the datasheet recommendation?
>
Hi Sekhar,
I've just tested 1024x768 at 37000 KHz - indeed seems like the
underflows are gone as soon as we go below 37500 KHz. I'll submit a
new patch using the max-pixelclock property.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-1-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and getting them cleaned up for merging.
>
> Some of the patches might be worth taking now if the maintainers are
> happy to do so (run_test tweaks, libcflat updates?). The others could
> do with more serious review. I've CC'd some of the ARM guys to look
> over the tlbflush/barrier tests so they can cast their expert eyes
> over them ;-)
>
> There are two additions to the series.
>
> The tcg-test is a general torture test aimed at QEMU's TCG execution
> model. It stresses the cpu execution loop through the use of
> cross-page and computed jumps. It can also add IRQ's and self-modifying
> code to the mix.
>
> The tlbflush-data test is a new one, the old tlbflush test is renamed
> tlbflush-code to better indicate the code path it exercise. The the
> code test tests the translation invalidation pathways in QEMU the data
> test exercises the SoftMMU's TLBs and explicitly that tlbflush
> completion semantics are correct.
>
> The tlbflush-data passes most of the times on real hardware but
> definitely showed the problem with deferred TLB flushes running under
> MTTCG QEMU. I've looked at some of the failure cases on real hardware
> and it did look like a timestamp appeared on a page that shouldn't
> have been accessible at the time - I don't know if this is a real
> silicon bug or my misreading of the semantics so I'd appreciate
> a comment from the experts.
One other thought. I'm not sure how best to approach a bunch of TCG-only
tests getting integrated. I'm thinking it might be nice to give them
their own subdir under the arch dir, e.g. arm/tcg. That subdir would
have its own unittests.cfg file too. Otherwise when we run on KVM we'll
have a load of "SKIP: requires TCG" type messages...
We'll want to add a run_tests.sh option to pass the name of the subdir,
'-d tcg'. When the subdir name is 'tcg' ACCEL could automatically be
switched to 'tcg' as well.
Thanks,
drew
^ 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