* [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724011551.49603-4-icenowy@aosc.io>
On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Pine H64 model A has a Wi-Fi module connector and the model B has an
> on-board RTL8723BS Wi-Fi module.
>
> Add support for them. For model A, as it's not defaultly present, keep
> it disabled now.
Nope. Pine64 actually has two WiFi/BT modules. And they require different
device tree snippets for both the WiFi and BT side. This is better resolved
with device tree overlays.
I have both, though I've yet found time to work on them.
ChenYu
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 +++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index d0fcc25efb00..d0f775613c9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -18,3 +18,11 @@
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> +};
> +
> +&wifi_pwrseq {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index a85867f8b684..75db6d4139bf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -40,6 +40,12 @@
> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> };
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
> + status = "disabled";
> + };
> };
>
> &mmc0 {
> @@ -50,6 +56,17 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_cldo2>;
> + vqmmc-supply = <®_bldo2>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "disabled";
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> @@ -128,12 +145,24 @@
> };
>
> reg_cldo2: cldo2 {
> + /*
> + * This regulator is connected with CLDO3.
> + * Before the kernel can support synchronized
> + * enable of coupled regulators, keep them
> + * both always on as a ugly hack.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-1";
> };
>
> reg_cldo3: cldo3 {
> + /*
> + * This regulator is connected with CLDO2.
> + * See the comments for CLDO2.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-2";
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180724011551.49603-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> The Pine H64 model A has a Wi-Fi module connector and the model B has an
> on-board RTL8723BS Wi-Fi module.
>
> Add support for them. For model A, as it's not defaultly present, keep
> it disabled now.
Nope. Pine64 actually has two WiFi/BT modules. And they require different
device tree snippets for both the WiFi and BT side. This is better resolved
with device tree overlays.
I have both, though I've yet found time to work on them.
ChenYu
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 +++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index d0fcc25efb00..d0f775613c9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -18,3 +18,11 @@
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> +};
> +
> +&wifi_pwrseq {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index a85867f8b684..75db6d4139bf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -40,6 +40,12 @@
> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> };
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
> + status = "disabled";
> + };
> };
>
> &mmc0 {
> @@ -50,6 +56,17 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_cldo2>;
> + vqmmc-supply = <®_bldo2>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "disabled";
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> @@ -128,12 +145,24 @@
> };
>
> reg_cldo2: cldo2 {
> + /*
> + * This regulator is connected with CLDO3.
> + * Before the kernel can support synchronized
> + * enable of coupled regulators, keep them
> + * both always on as a ugly hack.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-1";
> };
>
> reg_cldo3: cldo3 {
> + /*
> + * This regulator is connected with CLDO2.
> + * See the comments for CLDO2.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-2";
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845
From: Taniya Das @ 2018-07-24 2:22 UTC (permalink / raw)
To: Douglas Anderson, sboyd, andy.gross
Cc: grahamr, girishm, anischal, bjorn.andersson, Michael Turquette,
linux-arm-msm, linux-kernel, David Brown, linux-soc, linux-clk
In-Reply-To: <20180723215404.74296-3-dianders@chromium.org>
On 7/24/2018 3:24 AM, Douglas Anderson wrote:
> Add both the interface and core clock.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> Changes in v2:
> - Only 19.2, 100, 150, and 300 MHz now.
> - All clocks come from MAIN rather than EVEN.
> - Use parent map 0 instead of new parent map 9.
>
> drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
> index 0f694ed4238a..5bca634e277a 100644
> --- a/drivers/clk/qcom/gcc-sdm845.c
> +++ b/drivers/clk/qcom/gcc-sdm845.c
> @@ -162,6 +162,13 @@ static const char * const gcc_parent_names_10[] = {
> "core_bi_pll_test_se",
> };
>
> +static const char * const gcc_parent_names_9[] = {
> + "bi_tcxo",
> + "gpll0",
> + "gpll0_out_even",
> + "core_pi_sleep_clk",
> +};
> +
Please remove this.
> static struct clk_alpha_pll gpll0 = {
> .offset = 0x0,
> .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
> @@ -358,6 +365,28 @@ static struct clk_rcg2 gcc_pcie_phy_refgen_clk_src = {
> },
> };
>
> +static const struct freq_tbl ftbl_gcc_qspi_core_clk_src[] = {
> + F(19200000, P_BI_TCXO, 1, 0, 0),
> + F(100000000, P_GPLL0_OUT_MAIN, 6, 0, 0),
> + F(150000000, P_GPLL0_OUT_MAIN, 4, 0, 0),
> + F(300000000, P_GPLL0_OUT_MAIN, 2, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 gcc_qspi_core_clk_src = {
> + .cmd_rcgr = 0x4b008,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = gcc_parent_map_0,
> + .freq_tbl = ftbl_gcc_qspi_core_clk_src,
> + .clkr.hw.init = &(struct clk_init_data){
> + .name = "gcc_qspi_core_clk_src",
> + .parent_names = gcc_parent_names_9,
This would point to "gcc_parent_names_0".
> + .num_parents = 4,
> + .ops = &clk_rcg2_floor_ops,
> + },
> +};
> +
> static const struct freq_tbl ftbl_gcc_pdm2_clk_src[] = {
> F(9600000, P_BI_TCXO, 2, 0, 0),
> F(19200000, P_BI_TCXO, 1, 0, 0),
> @@ -1935,6 +1964,37 @@ static struct clk_branch gcc_qmip_video_ahb_clk = {
> },
> };
>
> +static struct clk_branch gcc_qspi_cnoc_periph_ahb_clk = {
> + .halt_reg = 0x4b000,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x4b000,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_qspi_cnoc_periph_ahb_clk",
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch gcc_qspi_core_clk = {
> + .halt_reg = 0x4b004,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x4b004,
> + .enable_mask = BIT(0),
> + .hw.init = &(struct clk_init_data){
> + .name = "gcc_qspi_core_clk",
> + .parent_names = (const char *[]){
> + "gcc_qspi_core_clk_src",
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> static struct clk_branch gcc_qupv3_wrap0_s0_clk = {
> .halt_reg = 0x17030,
> .halt_check = BRANCH_HALT_VOTED,
> @@ -3383,6 +3443,9 @@ static struct clk_regmap *gcc_sdm845_clocks[] = {
> [GPLL4] = &gpll4.clkr,
> [GCC_CPUSS_DVM_BUS_CLK] = &gcc_cpuss_dvm_bus_clk.clkr,
> [GCC_CPUSS_GNOC_CLK] = &gcc_cpuss_gnoc_clk.clkr,
> + [GCC_QSPI_CORE_CLK_SRC] = &gcc_qspi_core_clk_src.clkr,
> + [GCC_QSPI_CORE_CLK] = &gcc_qspi_core_clk.clkr,
> + [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = &gcc_qspi_cnoc_periph_ahb_clk.clkr,
> };
>
> static const struct qcom_reset_map gcc_sdm845_resets[] = {
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
^ permalink raw reply
* Re: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices
From: Lu Baolu @ 2018-07-24 2:22 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kumar, Sanjay K,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sun, Yi Y,
Pan, Jacob jun
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA143E-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> With the Intel IOMMU supporting PASID granularity isolation and protection, a
>> mediated device could be isolated and protected by an IOMMU unit. We need to
>> allocate a new group instead of a PCI group.
> Existing vfio mdev framework also allocates an iommu group for mediate device.
>
> mdev_probe()
> |_ mdev_attach_iommu()
> |_ iommu_group_alloc()
When external components ask iommu to allocate a group for a device,
it will call pci_device_group in Intel IOMMU driver's @device_group
callback. In another word, current Intel IOMMU driver doesn't aware
the mediated device and treat all devices as PCI ones. This patch
extends the @device_group call back to make it aware of a mediated
device.
Best regards,
Lu Baolu
>
> IMHO, this patch actually do a wrapper to the group allocation API. The reason is: it
> is not necessary to apply the group allocation rules when the allocation is for mediated
> device. Instead, just allocate a new one for it. :)
>
> Thanks,
> Yi Liu
>> Cc: Ashok Raj <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Kevin Tian <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Liu Yi L <yi.l.liu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Lu Baolu <baolu.lu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> drivers/iommu/intel-iommu.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 3ede34a..57ccfc4 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -5276,6 +5276,17 @@ static void intel_iommu_put_resv_regions(struct device
>> *dev,
>> }
>> }
>>
>> +static struct iommu_group *intel_iommu_device_group(struct device *dev)
>> +{
>> + if (dev_is_pci(dev))
>> + return pci_device_group(dev);
>> +
>> + if (dev_is_mdev(dev))
>> + return iommu_group_alloc();
>> +
>> + return ERR_PTR(-EINVAL);
>> +}
>> +
>> #ifdef CONFIG_INTEL_IOMMU_SVM
>> int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct intel_svm_dev
>> *sdev) { @@ -5370,7 +5381,7 @@ const struct iommu_ops intel_iommu_ops = {
>> .remove_device = intel_iommu_remove_device,
>> .get_resv_regions = intel_iommu_get_resv_regions,
>> .put_resv_regions = intel_iommu_put_resv_regions,
>> - .device_group = pci_device_group,
>> + .device_group = intel_iommu_device_group,
>> .pgsize_bitmap = INTEL_IOMMU_PGSIZES,
>> };
>>
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180724011551.49603-4-icenowy@aosc.io>
On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The Pine H64 model A has a Wi-Fi module connector and the model B has an
> on-board RTL8723BS Wi-Fi module.
>
> Add support for them. For model A, as it's not defaultly present, keep
> it disabled now.
Nope. Pine64 actually has two WiFi/BT modules. And they require different
device tree snippets for both the WiFi and BT side. This is better resolved
with device tree overlays.
I have both, though I've yet found time to work on them.
ChenYu
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 +++++++++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> index d0fcc25efb00..d0f775613c9b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
> @@ -18,3 +18,11 @@
> };
> };
> };
> +
> +&mmc1 {
> + status = "okay";
> +};
> +
> +&wifi_pwrseq {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index a85867f8b684..75db6d4139bf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -40,6 +40,12 @@
> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> };
> };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
> + status = "disabled";
> + };
> };
>
> &mmc0 {
> @@ -50,6 +56,17 @@
> status = "okay";
> };
>
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_cldo2>;
> + vqmmc-supply = <®_bldo2>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "disabled";
> +};
> +
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins>;
> @@ -128,12 +145,24 @@
> };
>
> reg_cldo2: cldo2 {
> + /*
> + * This regulator is connected with CLDO3.
> + * Before the kernel can support synchronized
> + * enable of coupled regulators, keep them
> + * both always on as a ugly hack.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-1";
> };
>
> reg_cldo3: cldo3 {
> + /*
> + * This regulator is connected with CLDO2.
> + * See the comments for CLDO2.
> + */
> + regulator-always-on;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-name = "vcc-wifi-2";
> --
> 2.18.0
>
^ permalink raw reply
* Re: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated devices
From: Lu Baolu @ 2018-07-24 2:22 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA143E@SHSMSX104.ccr.corp.intel.com>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> With the Intel IOMMU supporting PASID granularity isolation and protection, a
>> mediated device could be isolated and protected by an IOMMU unit. We need to
>> allocate a new group instead of a PCI group.
> Existing vfio mdev framework also allocates an iommu group for mediate device.
>
> mdev_probe()
> |_ mdev_attach_iommu()
> |_ iommu_group_alloc()
When external components ask iommu to allocate a group for a device,
it will call pci_device_group in Intel IOMMU driver's @device_group
callback. In another word, current Intel IOMMU driver doesn't aware
the mediated device and treat all devices as PCI ones. This patch
extends the @device_group call back to make it aware of a mediated
device.
Best regards,
Lu Baolu
>
> IMHO, this patch actually do a wrapper to the group allocation API. The reason is: it
> is not necessary to apply the group allocation rules when the allocation is for mediated
> device. Instead, just allocate a new one for it. :)
>
> Thanks,
> Yi Liu
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 3ede34a..57ccfc4 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -5276,6 +5276,17 @@ static void intel_iommu_put_resv_regions(struct device
>> *dev,
>> }
>> }
>>
>> +static struct iommu_group *intel_iommu_device_group(struct device *dev)
>> +{
>> + if (dev_is_pci(dev))
>> + return pci_device_group(dev);
>> +
>> + if (dev_is_mdev(dev))
>> + return iommu_group_alloc();
>> +
>> + return ERR_PTR(-EINVAL);
>> +}
>> +
>> #ifdef CONFIG_INTEL_IOMMU_SVM
>> int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct intel_svm_dev
>> *sdev) { @@ -5370,7 +5381,7 @@ const struct iommu_ops intel_iommu_ops = {
>> .remove_device = intel_iommu_remove_device,
>> .get_resv_regions = intel_iommu_get_resv_regions,
>> .put_resv_regions = intel_iommu_put_resv_regions,
>> - .device_group = pci_device_group,
>> + .device_group = intel_iommu_device_group,
>> .pgsize_bitmap = INTEL_IOMMU_PGSIZES,
>> };
>>
>> --
>> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: remove 'interrupt-parent' from bindings
From: Rob Herring @ 2018-07-24 2:22 UTC (permalink / raw)
To: Vladimir Zapolskiy; +Cc: linux-kernel@vger.kernel.org, devicetree, Mark Rutland
In-Reply-To: <811b4c0c-7d9c-2bbc-5029-58a458a13f7e@mleia.com>
On Mon, Jul 23, 2018 at 5:20 PM Vladimir Zapolskiy <vz@mleia.com> wrote:
>
> Hi Rob,
>
> On 07/24/2018 01:13 AM, Rob Herring wrote:
> > 'interrupt-parent' is often documented as part of define bindings, but
> > it is really outside the scope of a device binding. It's never required
> > in a given node as it is often inherited from a parent node. Or it can
> > be implicit if a parent node is an 'interrupt-controller' node. So
> > remove it from all the binding files.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
>
> [snip]
>
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> > index 38211f344dc8..0bfb3ba55f4c 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt
> > @@ -14,8 +14,6 @@ Required properties:
> > Reset value is IRQ_TYPE_LEVEL_LOW.
> >
> > Optional properties:
> > -- interrupt-parent: empty for MIC interrupt controller, link to parent
> > - MIC interrupt controller for SIC1 and SIC2
> > - interrupts: empty for MIC interrupt controller, cascaded MIC
> > hardware interrupts for SIC1 and SIC2
> >
>
> I would rather ask you to keep the property here, it is optional in sense that
> its presence distinguishes MIC and SIC types of interrupt controllers.
Sure, no problem.
Hopefully I remember on the next round of wack-a-mole.
Rob
^ permalink raw reply
* [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67zR-Q9n7L6CaFKDUJFHFEC_h8-RYxkdyeyJb_GbNmkJw@mail.gmail.com>
? 2018?7?24? GMT+08:00 ??10:21:59, Chen-Yu Tsai <wens@csie.org> ??:
>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>an
>> on-board RTL8723BS Wi-Fi module.
>>
>> Add support for them. For model A, as it's not defaultly present,
>keep
>> it disabled now.
>
>Nope. Pine64 actually has two WiFi/BT modules. And they require
>different
>device tree snippets for both the WiFi and BT side. This is better
>resolved
>with device tree overlays.
>
>I have both, though I've yet found time to work on them.
I have also both.
The skeleton here can get the Wi-Fi of both to work.
>
>ChenYu
>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>+++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> index d0fcc25efb00..d0f775613c9b 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> @@ -18,3 +18,11 @@
>> };
>> };
>> };
>> +
>> +&mmc1 {
>> + status = "okay";
>> +};
>> +
>> +&wifi_pwrseq {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> index a85867f8b684..75db6d4139bf 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> @@ -40,6 +40,12 @@
>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>*/
>> };
>> };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>> + status = "disabled";
>> + };
>> };
>>
>> &mmc0 {
>> @@ -50,6 +56,17 @@
>> status = "okay";
>> };
>>
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_cldo2>;
>> + vqmmc-supply = <®_bldo2>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "disabled";
>> +};
>> +
>> &mmc2 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mmc2_pins>;
>> @@ -128,12 +145,24 @@
>> };
>>
>> reg_cldo2: cldo2 {
>> + /*
>> + * This regulator is connected with
>CLDO3.
>> + * Before the kernel can support
>synchronized
>> + * enable of coupled regulators, keep
>them
>> + * both always on as a ugly hack.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-1";
>> };
>>
>> reg_cldo3: cldo3 {
>> + /*
>> + * This regulator is connected with
>CLDO2.
>> + * See the comments for CLDO2.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-2";
>> --
>> 2.18.0
>>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAGb2v67zR-Q9n7L6CaFKDUJFHFEC_h8-RYxkdyeyJb_GbNmkJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>an
>> on-board RTL8723BS Wi-Fi module.
>>
>> Add support for them. For model A, as it's not defaultly present,
>keep
>> it disabled now.
>
>Nope. Pine64 actually has two WiFi/BT modules. And they require
>different
>device tree snippets for both the WiFi and BT side. This is better
>resolved
>with device tree overlays.
>
>I have both, though I've yet found time to work on them.
I have also both.
The skeleton here can get the Wi-Fi of both to work.
>
>ChenYu
>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>+++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> index d0fcc25efb00..d0f775613c9b 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> @@ -18,3 +18,11 @@
>> };
>> };
>> };
>> +
>> +&mmc1 {
>> + status = "okay";
>> +};
>> +
>> +&wifi_pwrseq {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> index a85867f8b684..75db6d4139bf 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> @@ -40,6 +40,12 @@
>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>*/
>> };
>> };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>> + status = "disabled";
>> + };
>> };
>>
>> &mmc0 {
>> @@ -50,6 +56,17 @@
>> status = "okay";
>> };
>>
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_cldo2>;
>> + vqmmc-supply = <®_bldo2>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "disabled";
>> +};
>> +
>> &mmc2 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mmc2_pins>;
>> @@ -128,12 +145,24 @@
>> };
>>
>> reg_cldo2: cldo2 {
>> + /*
>> + * This regulator is connected with
>CLDO3.
>> + * Before the kernel can support
>synchronized
>> + * enable of coupled regulators, keep
>them
>> + * both always on as a ugly hack.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-1";
>> };
>>
>> reg_cldo3: cldo3 {
>> + /*
>> + * This regulator is connected with
>CLDO2.
>> + * See the comments for CLDO2.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-2";
>> --
>> 2.18.0
>>
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* RE: Enquiry on unbalanced memory throughput for dual-Cortex A9 core.
From: Ooi, Tzy Way @ 2018-07-24 2:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-kernel@vger.kernel.org, See, Chin Liang, Tan, Ley Foon,
Nguyen, Dinh, Aw, Khai Liang
In-Reply-To: <20180720103627.GA29084@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 9542 bytes --]
> -----Original Message-----
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
> Sent: Friday, July 20, 2018 6:36 PM
> To: Ooi, Tzy Way <tzy.way.ooi@intel.com>
> Cc: linux-kernel@vger.kernel.org; See, Chin Liang
> <chin.liang.see@intel.com>; Tan, Ley Foon <ley.foon.tan@intel.com>;
> Nguyen, Dinh <dinh.nguyen@intel.com>; Aw, Khai Liang
> <khai.liang.aw@intel.com>
> Subject: Re: Enquiry on unbalanced memory throughput for dual-Cortex A9
> core.
>
> On Fri, Jul 20, 2018 at 08:49:47AM +0000, Ooi, Tzy Way wrote:
> > Hi Russell,
> >
> > I am trying the memory write operation with the LM benchmark test. I
> > tried to execute the memory write operation here
> > <http://lmbench.sourceforge.net/cgi-
> bin/man?section=8&keyword=bw_mem>
> > twice to get both Cortex A9 core processor to work on each processes.
> > Both processors is going to perform write operation at almost the same
> > time to the memory.
> >
> > As shown in the pictures below, the memory throughput from one of the
> > cores is about double the throughput of another core. i.e. 377MB/s VS
> > 728MB/s
> >
> > [cid:image001.png@01D42049.5A7D0070]
> >
> > I have tested this operation across few dual cores Cortex A9 boards
> > and all the board is having the same result. The test is tested on
> > kernel version 4.9 and newest Linux kernel version 4.18.0-rc2
>
> Here's how 4.14 behaves on an iMX6D SoC (also dual core Cortex A9):
>
> $ taskset -c 0 ./bw_mem -N 1000 1M fwr & taskset -c 1 ./bw_mem -N 1000
> 1M fwr [1] 21799
> 1.00 521.10
> 1.00 497.27
> [1]+ Done taskset -c 0 ./bw_mem -N 1000 1M fwr
> $ taskset -c 0 ./bw_mem -N 1000 1M fwr & taskset -c 1 ./bw_mem -N 1000
> 1M fwr [1] 21803
> 1.00 520.83
> 1.00 496.44
>
> which shows some asymmetry but nowhere near yours.
>
> I'm using taskset to force each to be locked to a particular CPU - you'll see
> why further down. Even without it, I get similar results to those I mention
> above.
>
> Now, playing around with this, so we can identify which bw_mem output is
> which:
>
> $ taskset -c 0 ./bw_mem -N 1000 1M fwr & c1=$(taskset -c 1 ./bw_mem -N
> 1000 1M fwr 2>&1); echo "c1: $c1"
> [1] 21876
> 1.00 521.92
> c1: 1.00 496.69
> $ taskset -c 1 ./bw_mem -N 1000 1M fwr & c1=$(taskset -c 0 ./bw_mem -N
> 1000 1M fwr 2>&1); echo "c0: $c1"
> [1] 21881
> c0: 1.00 521.83
> 1.00 496.20
>
> CPU0 is always the slightly faster of the two. If we use /usr/bin/time to time
> these:
>
> CPU0:
> 6.10user 0.25system 0:06.56elapsed 96%CPU (0avgtext+0avgdata
> 1664maxresident)k
> 0inputs+0outputs (0major+407minor)pagefaults 0swaps
>
> CPU1:
> 6.36user 0.24system 0:06.77elapsed 97%CPU (0avgtext+0avgdata
> 1600maxresident)k
> 0inputs+0outputs (0major+399minor)pagefaults 0swaps
>
> So, CPU1 takes slightly longer in userspace, has less resident pages and less
> minor faults which is rather odd. Repeatedly running just one instance gives
> different results each time... disabling virtual address space randomisation
> solves that:
>
> echo 0 >/proc/sys/kernel/randomize_va_space
>
> which then gives me:
>
> CPU0: 1.00 520.20
> 6.18user 0.20system 0:06.59elapsed 96%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
> CPU1: 1.00 496.61
> 6.46user 0.14system 0:06.77elapsed 97%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
>
> CPU0: 1.00 521.10
> 6.13user 0.21system 0:06.57elapsed 96%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
> CPU1: 1.00 498.01
> 6.40user 0.18system 0:06.75elapsed 97%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
>
> which is rather more stable as far as resource usage goes between the two
> CPUs, but still an asymmetry in the reported bandwidths and times.
> So, this has ruled out differences in VA layout.
>
> Now for the interesting bit... it's important to understand what and how stuff
> is being measured. Looking at the bw_mem.c and associated source code, it
> measures the performance against the wall clock, which includes everything
> that the system is doing on each particular CPU.
> So, if a CPU is interrupted by another thread wanting to run, it'll affect the
> results. Hence, it's best to run on an otherwise quiet system, eg, without an
> init daemon (eg, booted with init=/bin/sh on the kernel command line - but
> note there won't be any job control, so ^C won't work!)
>
> However, continuing on...
>
> If I run bw_mem on just one CPU:
>
> CPU1: 1.00 2617.31
> 5.74user 0.18system 0:06.03elapsed 98%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
>
> Same number of iterations, same memory size, but notice that it appears to
> be a lot faster reported by bw_mem, but the time taken is about the same.
> cpufreq comes to mind, but that's disabled on this system.
>
> So, it brings up a rather obvious question: what exactly is bw_mem
> measuring, and is it measuring it correctly?
>
> $ /usr/bin/time taskset -c 1 ./bw_mem -P 1 -N 1000 1M fwr
> 1.00 2601.26
> 5.80user 0.16system 0:06.06elapsed 98%CPU (0avgtext+0avgdata
> 1700maxresident)k
> 0inputs+0outputs (0major+403minor)pagefaults 0swaps
> $ /usr/bin/time ./bw_mem -P 2 -N 1000 1M fwr ^CCommand terminated by
> signal 2 5.54user 0.13system 1:12.20elapsed 7%CPU (0avgtext+0avgdata
> 1696maxresident)k
> 0inputs+0outputs (0major+365minor)pagefaults 0swaps
>
> so requesting a parallelism of 2 results in the program never seemingly
> ending in a reasonable period of time, which suggests a bug somewhere.
> Are we sure that bw_mem is actually working as intended?
>
> Maybe if Larry is reading this, he could share some thoughts.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps
> up According to speedtest.net: 13Mbps down 490kbps up
Thanks for the detail explanation on LM bench test.
Initially, I tested to run my own's created memory test program and encountered the same unbalanced memory throughput whenever two threads are running on different cores. I tested to run the memory test program on either one core or two cores. The unbalanced memory throughput is seen when running on two cores. Hence, I tried out the bw_mem test as it is a general benchmark program and it appears to be alike to my own test case.
Attached is the memory test program memtest.c file and the Linux executable file. The memtest -a1 will forces the two threads running on different cores while memtest -a2 will forces the two threads running on one core.
May I know if is it possible if you could try out my test program on your iMX6D SoC (also dual core Cortex A9) board?
Below show the comparison between two threads running on one core vs two cores
One core:
========= Multi Thread =========
Thread 3067511920 - data size 1 MB, runs = 1000
Thread 3059123312 - data size 1 MB, runs = 1000
Thread :3059123312: Datarate: 974.887201 MB/s
Thread :3067511920: Datarate: 960.289834 MB/s
Thread :3067511920: Datarate: 1083.249741 MB/s
Thread :3059123312: Datarate: 1055.545769 MB/s
Thread :3067511920: Datarate: 1085.555446 MB/s
Thread :3059123312: Datarate: 1084.503430 MB/s
Thread :3067511920: Datarate: 1063.379303 MB/s
Thread :3059123312: Datarate: 1070.705338 MB/s
Thread :3067511920: Datarate: 1050.933243 MB/s
Thread :3059123312: Datarate: 1050.153330 MB/s
Thread :3067511920: Datarate: 1085.489144 MB/s
Thread :3059123312: Datarate: 1071.774560 MB/s
Thread :3067511920: Datarate: 1084.506795 MB/s
Thread :3059123312: Datarate: 1060.260066 MB/s
Thread :3067511920: Datarate: 1074.058027 MB/s
Thread :3059123312: Datarate: 1069.279388 MB/s
Thread :3067511920: Datarate: 1073.924924 MB/s
Thread :3059123312: Datarate: 1080.818992 MB/s
Thread :3067511920: Datarate: 1081.871683 MB/s
Thread :3067511920: Average Datarate: 1064.325814 MB/s
Thread :3059123312: Datarate: 1097.549768 MB/s
Thread :3059123312: Average Datarate: 1061.547784 MB/s
Finished!
Two cores:
========= Multi Thread =========
Thread 3067954288 - data size 1 MB, runs = 1000
Thread 3059565680 - data size 1 MB, runs = 1000
Thread :3067954288: Datarate: 741.930805 MB/s
Thread :3059565680: Datarate: 377.979641 MB/s
Thread :3067954288: Datarate: 741.976479 MB/s
Thread :3067954288: Datarate: 740.548015 MB/s
Thread :3059565680: Datarate: 376.706463 MB/s
Thread :3067954288: Datarate: 740.313260 MB/s
Thread :3067954288: Datarate: 740.363440 MB/s
Thread :3059565680: Datarate: 376.129877 MB/s
Thread :3067954288: Datarate: 740.056194 MB/s
Thread :3067954288: Datarate: 740.219191 MB/s
Thread :3059565680: Datarate: 376.114092 MB/s
Thread :3067954288: Datarate: 740.152311 MB/s
Thread :3067954288: Datarate: 724.094688 MB/s
Thread :3059565680: Datarate: 388.118117 MB/s
Thread :3067954288: Datarate: 740.556383 MB/s
Thread :3067954288: Average Datarate: 739.021077 MB/s
Thread :3059565680: Datarate: 1323.735631 MB/s
Thread :3059565680: Datarate: 2072.948256 MB/s
Thread :3059565680: Datarate: 2069.817984 MB/s
Thread :3059565680: Datarate: 2069.295149 MB/s
Thread :3059565680: Datarate: 2040.932474 MB/s
Thread :3059565680: Average Datarate: 1147.177768 MB/s
Finished!
Thanks
Tzy Way
[-- Attachment #2: memtest.c --]
[-- Type: text/plain, Size: 6496 bytes --]
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <malloc.h>
#include <pthread.h>
#include <semaphore.h>
#include <string.h>
#include <sys/time.h>
#include <sched.h>
#include <sys/resource.h>
#include <sys/mman.h>
#define MB (1024*1024)
#define QUAD_CORE 0
# define handle_error_en(en, msg) \
do { errno = en; perror(msg); exit(EXIT_FAILURE); } while (0);
unsigned long l_megabytes = 1;
unsigned long l_repeat = 1000;
void SingleFct(void)
{
unsigned long l_size = l_megabytes*MB;
unsigned char * l_memBuffer = memalign(32, l_size);
int i,j;
unsigned long l_time;
double l_datarate;
double t_datarate = 0.0;
struct timeval start, end;
printf("Single Thread - data size %ld MB, runs = %ld\n", l_megabytes, l_repeat);
for(j=0; j<10; j++)
{
gettimeofday(&start, NULL);
for(i=0; i<l_repeat; i++)
{
memset(l_memBuffer, 0x5a, l_size);
}
gettimeofday(&end, NULL);
l_time = (end.tv_sec*1000000 + end.tv_usec) - (start.tv_sec*1000000 + start.tv_usec);
// printf("end time = %u.%06u, start time = %u.%06u\n", end.tv_sec, end.tv_usec, start.tv_sec, start.tv_usec);
// printf("l_time = %u\n", l_time);
l_datarate = (double)l_size*(double)l_repeat/(double)l_time;
printf("Single Thread Datarate: %f MB/s\n", l_datarate);
t_datarate += l_datarate;
}
printf("Single Thread Average Datarate: %f MB/s\n", t_datarate/10.0f);
free(l_memBuffer);
}
void Fct(void)
{
unsigned long l_size = l_megabytes*MB;
unsigned char * l_memBuffer = memalign(32, l_size);
unsigned long l_time;
double l_datarate;
double t_datarate = 0.0;
int i,j;
struct timeval start, end;
printf("Thread %u - data size %ld MB, runs = %ld\n", (unsigned int)pthread_self(), l_megabytes, l_repeat);
for(j=0; j<10; j++)
{
gettimeofday(&start, NULL);
for(i=0; i<l_repeat; i++)
{
memset(l_memBuffer, 0x5a, l_size);
}
gettimeofday(&end, NULL);
l_time = (end.tv_sec*1000000 + end.tv_usec) - (start.tv_sec*1000000 + start.tv_usec);
l_datarate = (double)l_size*(double)l_repeat/(double)l_time;
printf("Thread :%u: Datarate: %lf MB/s\n", (unsigned int)pthread_self(), l_datarate);
t_datarate += l_datarate;
}
printf("Thread :%u: Average Datarate: %lf MB/s\n", (unsigned int)pthread_self(), t_datarate/10.0f);
free(l_memBuffer);
pthread_exit((void *) 0);
}
int main(int argc, char** argv) {
pthread_t t1, t2, t3, t4;
pthread_attr_t t1_attr, t2_attr, t3_attr, t4_attr;
cpu_set_t t1_cpuset, t2_cpuset, t3_cpuset, t4_cpuset;
int rv;
int affinity = 0;
int iarg = 1;
while (iarg < argc) {
if (!strcmp(argv[iarg],"-a1")) {
affinity = 1;
}
else if (!strcmp(argv[iarg],"-a2")) {
affinity = 2;
}
else if (!strcmp(argv[iarg],"-s1")) {
l_megabytes = 1;
}
else if (!strcmp(argv[iarg],"-s2")) {
l_megabytes = 10;
}
else if (!strcmp(argv[iarg],"-s3")) {
l_megabytes = 100;
}
else {
printf("Usage: %s [-a1|-a2 ] [-s1|-s2|-s3]\n",argv[0]);
exit(0);
}
iarg++;
}
printf("========= Single Thread =========\n\n");
SingleFct();
printf("\n\n========= Multi Thread =========\n\n");
rv = pthread_attr_init(&t1_attr);
if (rv != 0) handle_error_en(rv,"pthread_attr_init thread #1");
rv = pthread_attr_init(&t2_attr);
if (rv != 0) handle_error_en(rv,"pthread_attr_init thread #2");
if (affinity == 1)
{
CPU_ZERO(&t1_cpuset);
CPU_SET(0,&t1_cpuset);
rv = pthread_attr_setaffinity_np(&t1_attr,sizeof(t1_cpuset),&t1_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #1");
CPU_ZERO(&t2_cpuset);
CPU_SET(1,&t2_cpuset);
rv = pthread_attr_setaffinity_np(&t2_attr,sizeof(t2_cpuset),&t2_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #2");
}
else if (affinity == 2)
{
CPU_ZERO(&t1_cpuset);
CPU_SET(0,&t1_cpuset);
rv = pthread_attr_setaffinity_np(&t1_attr,sizeof(t1_cpuset),&t1_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #1");
CPU_ZERO(&t2_cpuset);
CPU_SET(0,&t2_cpuset);
rv = pthread_attr_setaffinity_np(&t2_attr,sizeof(t2_cpuset),&t2_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #2");
}
rv = pthread_create(&t1, &t1_attr, (void *)&Fct, (void *)NULL);
if (rv != 0) handle_error_en(rv,"pthread_create thread #1");
rv = pthread_create(&t2, &t2_attr, (void *)&Fct, (void *)NULL);
if (rv != 0) handle_error_en(rv,"pthread_create thread #2");
#if QUAD_CORE
rv = pthread_attr_init(&t3_attr);
if (rv != 0) handle_error_en(rv,"pthread_attr_init thread #3");
rv = pthread_attr_init(&t4_attr);
if (rv != 0) handle_error_en(rv,"pthread_attr_init thread #4");
if (affinity == 1)
{
CPU_ZERO(&t3_cpuset);
CPU_SET(2,&t3_cpuset);
rv = pthread_attr_setaffinity_np(&t3_attr,sizeof(t3_cpuset),&t3_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #3");
CPU_ZERO(&t4_cpuset);
CPU_SET(3,&t4_cpuset);
rv = pthread_attr_setaffinity_np(&t4_attr,sizeof(t4_cpuset),&t4_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #4");
}
else if (affinity == 2)
{
CPU_ZERO(&t3_cpuset);
CPU_SET(0,&t3_cpuset);
rv = pthread_attr_setaffinity_np(&t3_attr,sizeof(t3_cpuset),&t3_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #3");
CPU_ZERO(&t4_cpuset);
CPU_SET(0,&t4_cpuset);
rv = pthread_attr_setaffinity_np(&t4_attr,sizeof(t4_cpuset),&t4_cpuset);
if (rv != 0) handle_error_en(rv,"pthread_attr_setaffinity_np thread #4");
}
rv = pthread_create(&t3, &t3_attr, (void *)&Fct, (void *)NULL);
if (rv != 0) handle_error_en(rv,"pthread_create thread #3");
rv = pthread_create(&t4, &t4_attr, (void *)&Fct, (void *)NULL);
if (rv != 0) handle_error_en(rv,"pthread_create thread #4");
#endif
pthread_join(t1, NULL);
pthread_join(t2, NULL);
#if QUAD_CORE
pthread_join(t3, NULL);
pthread_join(t4, NULL);
#endif
printf("Finished!\n");
return 0;
}
[-- Attachment #3: memtest_2 --]
[-- Type: application/octet-stream, Size: 10384 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAGb2v67zR-Q9n7L6CaFKDUJFHFEC_h8-RYxkdyeyJb_GbNmkJw@mail.gmail.com>
于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens@csie.org> 写到:
>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>an
>> on-board RTL8723BS Wi-Fi module.
>>
>> Add support for them. For model A, as it's not defaultly present,
>keep
>> it disabled now.
>
>Nope. Pine64 actually has two WiFi/BT modules. And they require
>different
>device tree snippets for both the WiFi and BT side. This is better
>resolved
>with device tree overlays.
>
>I have both, though I've yet found time to work on them.
I have also both.
The skeleton here can get the Wi-Fi of both to work.
>
>ChenYu
>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>+++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> index d0fcc25efb00..d0f775613c9b 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>> @@ -18,3 +18,11 @@
>> };
>> };
>> };
>> +
>> +&mmc1 {
>> + status = "okay";
>> +};
>> +
>> +&wifi_pwrseq {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> index a85867f8b684..75db6d4139bf 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> @@ -40,6 +40,12 @@
>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>*/
>> };
>> };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>> + status = "disabled";
>> + };
>> };
>>
>> &mmc0 {
>> @@ -50,6 +56,17 @@
>> status = "okay";
>> };
>>
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_cldo2>;
>> + vqmmc-supply = <®_bldo2>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "disabled";
>> +};
>> +
>> &mmc2 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mmc2_pins>;
>> @@ -128,12 +145,24 @@
>> };
>>
>> reg_cldo2: cldo2 {
>> + /*
>> + * This regulator is connected with
>CLDO3.
>> + * Before the kernel can support
>synchronized
>> + * enable of coupled regulators, keep
>them
>> + * both always on as a ugly hack.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-1";
>> };
>>
>> reg_cldo3: cldo3 {
>> + /*
>> + * This regulator is connected with
>CLDO2.
>> + * See the comments for CLDO2.
>> + */
>> + regulator-always-on;
>> regulator-min-microvolt = <3300000>;
>> regulator-max-microvolt = <3300000>;
>> regulator-name = "vcc-wifi-2";
>> --
>> 2.18.0
>>
^ permalink raw reply
* [xen-unstable test] 125507: regressions - trouble: broken/fail/pass
From: osstest service owner @ 2018-07-24 2:23 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125507 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw <job status> broken
test-arm64-arm64-xl-credit2 <job status> broken in 125496
test-arm64-arm64-xl-xsm <job status> broken in 125496
test-arm64-arm64-xl <job status> broken in 125496
test-amd64-i386-xl-raw 10 debian-di-install fail in 125496 REGR. vs. 125178
build-armhf-libvirt 6 libvirt-build fail in 125496 REGR. vs. 125178
build-armhf-pvops 6 kernel-build fail in 125496 REGR. vs. 125178
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 5 host-install broken in 125496 pass in 125507
test-arm64-arm64-xl-credit2 4 host-install(4) broken in 125496 pass in 125507
test-arm64-arm64-xl 4 host-install(4) broken in 125496 pass in 125507
test-arm64-arm64-xl-xsm 4 host-install(4) broken in 125496 pass in 125507
test-amd64-i386-xl-raw 4 host-install(4) broken pass in 125496
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-vhd 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-arndale 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-examine 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-rtds 1 build-check(1) blocked in 125496 n/a
test-armhf-armhf-xl-credit2 1 build-check(1) blocked in 125496 n/a
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 125178
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 125178
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 125178
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125178
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125178
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 125178
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 125178
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 125178
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125178
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
xen 5437bdcd48e9812e66ec3ea656fd655289d08435
baseline version:
xen e3f667bc5f51d0aa44357a64ca134cd952679c81
Last test of basis 125178 2018-07-15 10:20:11 Z 8 days
Failing since 125259 2018-07-17 04:22:41 Z 6 days 5 attempts
Testing same since 125496 2018-07-21 07:55:59 Z 2 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Christopher Clark <christopher.clark6@baesystems.com>
Christopher Clark <christopher.w.clark@gmail.com>
Doug Goldstein <cardoe@cardoe.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Kevin Tian <kevin.tian@intel.com>
Olaf Hering <olaf@aepfle.de>
Paul Durrant <paul.durrant@citrix.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw broken
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job test-amd64-i386-xl-raw broken
broken-step test-amd64-i386-xl-raw host-install(4)
broken-job test-arm64-arm64-xl-credit2 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job test-arm64-arm64-xl broken
Not pushing.
(No revision log; it would be 800 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 2/3] [BUGFIX] ring_buffer: tracing: Inherit the tracing setting to next ring buffer
From: Steven Rostedt @ 2018-07-24 2:25 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Shuah Khan, Tom Zanussi, Hiraku Toyooka,
linux-kernel, stable
In-Reply-To: <153149929558.11274.11730609978254724394.stgit@devbox>
On Sat, 14 Jul 2018 01:28:15 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Inherit the tracing on/off setting on ring_buffer to next
> trace buffer when taking a snapshot.
>
> Taking a snapshot is done by swapping with backup ring buffer
> (max_tr_buffer). But since the tracing on/off setting is set
> in the ring buffer, when swapping it, tracing on/off setting
> can also be changed. This causes a strange result like below;
>
> /sys/kernel/debug/tracing # cat tracing_on
> 1
> /sys/kernel/debug/tracing # echo 0 > tracing_on
> /sys/kernel/debug/tracing # echo 1 > snapshot
> /sys/kernel/debug/tracing # cat tracing_on
> 1
> /sys/kernel/debug/tracing # echo 1 > snapshot
> /sys/kernel/debug/tracing # cat tracing_on
> 0
>
> We don't touch tracing_on, but snapshot changes tracing_on
> setting each time. This must be a bug, because user never know
> that each "ring_buffer" stores tracing-enable state and
> snapshot is done by swapping ring buffers.
>
> This patch fixes above strange behavior.
>
OK, so the issue is that the tracing_on state is saved with the buffer
itself. And when we swap the buffer, we also swap the state.
> Fixes: commit debdd57f5145 ("tracing: Make a snapshot feature available from userspace")
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
> Cc: stable@vger.kernel.org
> ---
> include/linux/ring_buffer.h | 1 +
> kernel/trace/ring_buffer.c | 12 ++++++++++++
> kernel/trace/trace.c | 6 ++++++
> 3 files changed, 19 insertions(+)
>
> diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
> index b72ebdff0b77..003d09ab308d 100644
> --- a/include/linux/ring_buffer.h
> +++ b/include/linux/ring_buffer.h
> @@ -165,6 +165,7 @@ void ring_buffer_record_enable(struct ring_buffer *buffer);
> void ring_buffer_record_off(struct ring_buffer *buffer);
> void ring_buffer_record_on(struct ring_buffer *buffer);
> int ring_buffer_record_is_on(struct ring_buffer *buffer);
> +int ring_buffer_record_is_set_on(struct ring_buffer *buffer);
> void ring_buffer_record_disable_cpu(struct ring_buffer *buffer, int cpu);
> void ring_buffer_record_enable_cpu(struct ring_buffer *buffer, int cpu);
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 6a46af21765c..4038ed74ab95 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -3227,6 +3227,18 @@ int ring_buffer_record_is_on(struct ring_buffer *buffer)
> }
>
> /**
> + * ring_buffer_record_is_set_on - return true if the ring buffer is set writable
> + * @buffer: The ring buffer to see if write is set enabled
> + *
> + * Returns true if the ring buffer is set writable by ring_buffer_record_on().
> + * Note that this does NOT mean it is in a writable state.
I'd add a little more context here. Something like:
* It may return true when the ring buffer has been disabled by
* ring_buffer_record_disable(), as that is a temporary disabling of
* the ring buffer.
-- Steve
> + */
> +int ring_buffer_record_is_set_on(struct ring_buffer *buffer)
> +{
> + return !(atomic_read(&buffer->record_disabled) & RB_BUFFER_OFF);
> +}
> +
> +/**
> * ring_buffer_record_disable_cpu - stop all writes into the cpu_buffer
> * @buffer: The ring buffer to stop writes to.
> * @cpu: The CPU buffer to stop
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 2556d8c097d2..bbd5a94a7ef1 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1378,6 +1378,12 @@ update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu)
>
> arch_spin_lock(&tr->max_lock);
>
> + /* Inherit the recordable setting from trace_buffer */
> + if (ring_buffer_record_is_set_on(tr->trace_buffer.buffer))
> + ring_buffer_record_on(tr->max_buffer.buffer);
> + else
> + ring_buffer_record_off(tr->max_buffer.buffer);
> +
> swap(tr->trace_buffer.buffer, tr->max_buffer.buffer);
>
> __update_max_tr(tr, tsk, cpu);
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CEA43CB7-1DA6-4983-BF18-82C4A48FB92B@aosc.io>
On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> ? 2018?7?24? GMT+08:00 ??10:21:59, Chen-Yu Tsai <wens@csie.org> ??:
>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>>an
>>> on-board RTL8723BS Wi-Fi module.
>>>
>>> Add support for them. For model A, as it's not defaultly present,
>>keep
>>> it disabled now.
>>
>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>different
>>device tree snippets for both the WiFi and BT side. This is better
>>resolved
>>with device tree overlays.
>>
>>I have both, though I've yet found time to work on them.
>
> I have also both.
>
> The skeleton here can get the Wi-Fi of both to work.
Cool. Then I can put away my RTL module for now. :)
ChenYu
>
>>
>>ChenYu
>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>+++++++++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> index d0fcc25efb00..d0f775613c9b 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> @@ -18,3 +18,11 @@
>>> };
>>> };
>>> };
>>> +
>>> +&mmc1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&wifi_pwrseq {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> index a85867f8b684..75db6d4139bf 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> @@ -40,6 +40,12 @@
>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>>*/
>>> };
>>> };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>>> + status = "disabled";
>>> + };
>>> };
>>>
>>> &mmc0 {
>>> @@ -50,6 +56,17 @@
>>> status = "okay";
>>> };
>>>
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins>;
>>> + vmmc-supply = <®_cldo2>;
>>> + vqmmc-supply = <®_bldo2>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "disabled";
>>> +};
>>> +
>>> &mmc2 {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&mmc2_pins>;
>>> @@ -128,12 +145,24 @@
>>> };
>>>
>>> reg_cldo2: cldo2 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO3.
>>> + * Before the kernel can support
>>synchronized
>>> + * enable of coupled regulators, keep
>>them
>>> + * both always on as a ugly hack.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-1";
>>> };
>>>
>>> reg_cldo3: cldo3 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO2.
>>> + * See the comments for CLDO2.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-2";
>>> --
>>> 2.18.0
>>>
>
> --
> 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
* Re: Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CEA43CB7-1DA6-4983-BF18-82C4A48FB92B-h8G6r0blFSE@public.gmane.org>
On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> 于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>>an
>>> on-board RTL8723BS Wi-Fi module.
>>>
>>> Add support for them. For model A, as it's not defaultly present,
>>keep
>>> it disabled now.
>>
>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>different
>>device tree snippets for both the WiFi and BT side. This is better
>>resolved
>>with device tree overlays.
>>
>>I have both, though I've yet found time to work on them.
>
> I have also both.
>
> The skeleton here can get the Wi-Fi of both to work.
Cool. Then I can put away my RTL module for now. :)
ChenYu
>
>>
>>ChenYu
>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> ---
>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>+++++++++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> index d0fcc25efb00..d0f775613c9b 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> @@ -18,3 +18,11 @@
>>> };
>>> };
>>> };
>>> +
>>> +&mmc1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&wifi_pwrseq {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> index a85867f8b684..75db6d4139bf 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> @@ -40,6 +40,12 @@
>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>>*/
>>> };
>>> };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>>> + status = "disabled";
>>> + };
>>> };
>>>
>>> &mmc0 {
>>> @@ -50,6 +56,17 @@
>>> status = "okay";
>>> };
>>>
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins>;
>>> + vmmc-supply = <®_cldo2>;
>>> + vqmmc-supply = <®_bldo2>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "disabled";
>>> +};
>>> +
>>> &mmc2 {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&mmc2_pins>;
>>> @@ -128,12 +145,24 @@
>>> };
>>>
>>> reg_cldo2: cldo2 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO3.
>>> + * Before the kernel can support
>>synchronized
>>> + * enable of coupled regulators, keep
>>them
>>> + * both always on as a ugly hack.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-1";
>>> };
>>>
>>> reg_cldo3: cldo3 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO2.
>>> + * See the comments for CLDO2.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-2";
>>> --
>>> 2.18.0
>>>
>
> --
> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Chen-Yu Tsai @ 2018-07-24 2:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CEA43CB7-1DA6-4983-BF18-82C4A48FB92B@aosc.io>
On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>
>
> 于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens@csie.org> 写到:
>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
>>> The Pine H64 model A has a Wi-Fi module connector and the model B has
>>an
>>> on-board RTL8723BS Wi-Fi module.
>>>
>>> Add support for them. For model A, as it's not defaultly present,
>>keep
>>> it disabled now.
>>
>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>different
>>device tree snippets for both the WiFi and BT side. This is better
>>resolved
>>with device tree overlays.
>>
>>I have both, though I've yet found time to work on them.
>
> I have also both.
>
> The skeleton here can get the Wi-Fi of both to work.
Cool. Then I can put away my RTL module for now. :)
ChenYu
>
>>
>>ChenYu
>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>> ---
>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>+++++++++++++++++++
>>> 2 files changed, 37 insertions(+)
>>>
>>> diff --git
>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> index d0fcc25efb00..d0f775613c9b 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>> @@ -18,3 +18,11 @@
>>> };
>>> };
>>> };
>>> +
>>> +&mmc1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&wifi_pwrseq {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> index a85867f8b684..75db6d4139bf 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>> @@ -40,6 +40,12 @@
>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7
>>*/
>>> };
>>> };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2 */
>>> + status = "disabled";
>>> + };
>>> };
>>>
>>> &mmc0 {
>>> @@ -50,6 +56,17 @@
>>> status = "okay";
>>> };
>>>
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins>;
>>> + vmmc-supply = <®_cldo2>;
>>> + vqmmc-supply = <®_bldo2>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "disabled";
>>> +};
>>> +
>>> &mmc2 {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&mmc2_pins>;
>>> @@ -128,12 +145,24 @@
>>> };
>>>
>>> reg_cldo2: cldo2 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO3.
>>> + * Before the kernel can support
>>synchronized
>>> + * enable of coupled regulators, keep
>>them
>>> + * both always on as a ugly hack.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-1";
>>> };
>>>
>>> reg_cldo3: cldo3 {
>>> + /*
>>> + * This regulator is connected with
>>CLDO2.
>>> + * See the comments for CLDO2.
>>> + */
>>> + regulator-always-on;
>>> regulator-min-microvolt = <3300000>;
>>> regulator-max-microvolt = <3300000>;
>>> regulator-name = "vcc-wifi-2";
>>> --
>>> 2.18.0
>>>
>
> --
> 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@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info
From: Jakub Kicinski @ 2018-07-24 1:22 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, Toshiaki Makita,
Jesper Dangaard Brouer
In-Reply-To: <20180722151308.5480-7-toshiaki.makita1@gmail.com>
On Mon, 23 Jul 2018 00:13:06 +0900, Toshiaki Makita wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> We need some mechanism to disable napi_direct on calling
> xdp_return_frame_rx_napi() from some context.
> When veth gets support of XDP_REDIRECT, it will redirects packets which
> are redirected from other devices. On redirection veth will reuse
> xdp_mem_info of the redirection source device to make return_frame work.
> But in this case .ndo_xdp_xmit() called from veth redirection uses
> xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is
> not called directly from the rxq which owns the xdp_mem_info.
>
> This approach introduces a flag in xdp_mem_info to indicate that
> napi_direct should be disabled even when _rx_napi variant is used.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To be clear - you will modify flags of the original source device if it
ever redirected a frame to a software device like veth? Seems a bit
heavy handed. The xdp_return_frame_rx_napi() is only really used on
error paths, but still.. Also as you note the original NAPI can run
concurrently with your veth dest one, but also with NAPIs of other veth
devices, so the non-atomic xdp.rxq->mem.flags |= XDP_MEM_RF_NO_DIRECT;
makes me worried.
Would you mind elaborating why not handle the RX completely in the NAPI
context of the original device?
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index fcb033f51d8c..1d1bc6553ff2 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -41,6 +41,9 @@ enum xdp_mem_type {
> MEM_TYPE_MAX,
> };
>
> +/* XDP flags for xdp_mem_info */
> +#define XDP_MEM_RF_NO_DIRECT BIT(0) /* don't use napi_direct */
> +
> /* XDP flags for ndo_xdp_xmit */
> #define XDP_XMIT_FLUSH (1U << 0) /* doorbell signal consumer */
> #define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH
> @@ -48,6 +51,7 @@ enum xdp_mem_type {
> struct xdp_mem_info {
> u32 type; /* enum xdp_mem_type, but known size type */
> u32 id;
> + u32 flags;
> };
>
> struct page_pool;
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 57285383ed00..1426c608fd75 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -330,10 +330,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> page = virt_to_head_page(data);
> - if (xa)
> + if (xa) {
> + napi_direct &= !(mem->flags & XDP_MEM_RF_NO_DIRECT);
> page_pool_put_page(xa->page_pool, page, napi_direct);
> - else
> + } else {
> put_page(page);
> + }
> rcu_read_unlock();
> break;
> case MEM_TYPE_PAGE_SHARED:
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Willem de Bruijn @ 2018-07-24 1:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: caleb.raitto, Michael S. Tsirkin, Jason Wang, David Miller,
Network Development, caraitto
In-Reply-To: <20180723175326.583ce2b8@xeon-e3>
On Mon, Jul 23, 2018 at 8:55 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 23 Jul 2018 16:11:19 -0700
> Caleb Raitto <caleb.raitto@gmail.com> wrote:
>
> > From: Caleb Raitto <caraitto@google.com>
> >
> > The driver disables tx napi if it's not certain that completions will
> > be processed affine with tx service.
> >
> > Its heuristic doesn't account for some scenarios where it is, such as
> > when the queue pair count matches the core but not hyperthread count.
> >
> > Allow userspace to override the heuristic. This is an alternative
> > solution to that in the linked patch. That added more logic in the
> > kernel for these cases, but the agreement was that this was better left
> > to user control.
> >
> > Do not expand the existing napi_tx variable to a ternary value,
> > because doing so can break user applications that expect
> > boolean ('Y'/'N') instead of integer output. Add a new param instead.
> >
> > Link: https://patchwork.ozlabs.org/patch/725249/
> > Acked-by: Willem de Bruijn <willemb@google.com>
> > Acked-by: Jon Olson <jonolson@google.com>
> > Signed-off-by: Caleb Raitto <caraitto@google.com>
> > ---
>
> Not a fan of this.
> Module parameters are frowned on by the distributions because they
> never get well tested and they force the user to do magic things
> to enable features. It looks like you are using it to paper
> over a bug in this case.
This has actually been a catch-22 that this patch tries to break.
In micro benchmarks napi-tx was an improvement for most cases. We need
wider validation to make it default. Or even to start enabling it for some
users. But we cannot get the data, because understandably no one is
going to make it default without more data.
Enabling the feature selectively to safely roll out is the intent of
(temporary) param napi_tx. But the requirement to have
has_affinity_set is proving a real obstruction.
Especially in cases where we enable the feature to do A:B comparisons,
and thus are monitoring performance metrics closely, we should be able
to override the kernel heuristic.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
From: liujunjie (A) @ 2018-07-24 2:27 UTC (permalink / raw)
To: Eric Blake, armbru@redhat.com
Cc: wangxin (U), Gonglei (Arei), Huangweidong (C),
qemu-devel@nongnu.org
In-Reply-To: <6c060312-5e49-8377-1e8a-5f86baf0eca7@redhat.com>
I am sorry for that. I have changed the git setting to avoid using this symbol next time.
> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Monday, July 23, 2018 10:52 PM
> To: liujunjie (A) <liujunjie23@huawei.com>; armbru@redhat.com
> Cc: wangxin (U) <wangxinxin.wang@huawei.com>; Gonglei (Arei)
> <arei.gonglei@huawei.com>; Huangweidong (C)
> <weidong.huang@huawei.com>; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] qstring: Fix integer overflow
>
> On 07/20/2018 08:09 AM, liujunjie wrote:
> > From: l00425170 <liujunjie23@huawei.com>
> >
> > The incoming parameters "start" and "end" is int type in
> > qstring_from_substr(), but this function can be called by
> > qstring_from_str, which is size_t type in strlen(str).
> > It may result in coredump when called g_malloc later.
> > One scene to triger is to call hmp "into tlb", which may have too long
> > length of string.
> >
> > Signed-off-by: l00425170 <liujunjie23@huawei.com>
>
> Using what looks like a username for your Author and S-o-b designation rather
> than a legal name is fishy. If 'l00425170' is really an alias that you have
> frequently used in other open source projects, it might be okay (and if so, you
> could back it up by pointing us to a URL of such contributions to other projects).
> But in general, it's better to own your patches with your real name (git
> supports UTF-8, if you would like your name to appear in native characters
> instead of or in addition to a Latin-ized form).
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64Qae4O430kP30DQNhp0Dt774OHt0nMe35ckp8X=CTFLg@mail.gmail.com>
? 2018?7?24? GMT+08:00 ??10:26:02, Chen-Yu Tsai <wens@csie.org> ??:
>On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>
>>
>> ? 2018?7?24? GMT+08:00 ??10:21:59, Chen-Yu Tsai <wens@csie.org> ??:
>>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>> The Pine H64 model A has a Wi-Fi module connector and the model B
>has
>>>an
>>>> on-board RTL8723BS Wi-Fi module.
>>>>
>>>> Add support for them. For model A, as it's not defaultly present,
>>>keep
>>>> it disabled now.
>>>
>>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>>different
>>>device tree snippets for both the WiFi and BT side. This is better
>>>resolved
>>>with device tree overlays.
>>>
>>>I have both, though I've yet found time to work on them.
>>
>> I have also both.
>>
>> The skeleton here can get the Wi-Fi of both to work.
>
>Cool. Then I can put away my RTL module for now. :)
P.S. SDIO is auto detectable, and for BCM chips, the OOB interrupt
is only a bonus function and it can fall back to standard in-band
interrupt (which doesn't need special binding, and is currently
used by mainline r8723bs driver.)
>
>ChenYu
>
>>
>>>
>>>ChenYu
>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>>+++++++++++++++++++
>>>> 2 files changed, 37 insertions(+)
>>>>
>>>> diff --git
>>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> index d0fcc25efb00..d0f775613c9b 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> @@ -18,3 +18,11 @@
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&mmc1 {
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&wifi_pwrseq {
>>>> + status = "okay";
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> index a85867f8b684..75db6d4139bf 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> @@ -40,6 +40,12 @@
>>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /*
>PL7
>>>*/
>>>> };
>>>> };
>>>> +
>>>> + wifi_pwrseq: wifi_pwrseq {
>>>> + compatible = "mmc-pwrseq-simple";
>>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2
>*/
>>>> + status = "disabled";
>>>> + };
>>>> };
>>>>
>>>> &mmc0 {
>>>> @@ -50,6 +56,17 @@
>>>> status = "okay";
>>>> };
>>>>
>>>> +&mmc1 {
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mmc1_pins>;
>>>> + vmmc-supply = <®_cldo2>;
>>>> + vqmmc-supply = <®_bldo2>;
>>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>>> + bus-width = <4>;
>>>> + non-removable;
>>>> + status = "disabled";
>>>> +};
>>>> +
>>>> &mmc2 {
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&mmc2_pins>;
>>>> @@ -128,12 +145,24 @@
>>>> };
>>>>
>>>> reg_cldo2: cldo2 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO3.
>>>> + * Before the kernel can support
>>>synchronized
>>>> + * enable of coupled regulators,
>keep
>>>them
>>>> + * both always on as a ugly hack.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-1";
>>>> };
>>>>
>>>> reg_cldo3: cldo3 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO2.
>>>> + * See the comments for CLDO2.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-2";
>>>> --
>>>> 2.18.0
>>>>
>>
>> --
>> 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
* Re: Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:28 UTC (permalink / raw)
To: wens-jdAy2FN1RRM
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAGb2v64Qae4O430kP30DQNhp0Dt774OHt0nMe35ckp8X=CTFLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
于 2018年7月24日 GMT+08:00 上午10:26:02, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>wrote:
>>
>>
>> 于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> 写到:
>>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>wrote:
>>>> The Pine H64 model A has a Wi-Fi module connector and the model B
>has
>>>an
>>>> on-board RTL8723BS Wi-Fi module.
>>>>
>>>> Add support for them. For model A, as it's not defaultly present,
>>>keep
>>>> it disabled now.
>>>
>>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>>different
>>>device tree snippets for both the WiFi and BT side. This is better
>>>resolved
>>>with device tree overlays.
>>>
>>>I have both, though I've yet found time to work on them.
>>
>> I have also both.
>>
>> The skeleton here can get the Wi-Fi of both to work.
>
>Cool. Then I can put away my RTL module for now. :)
P.S. SDIO is auto detectable, and for BCM chips, the OOB interrupt
is only a bonus function and it can fall back to standard in-band
interrupt (which doesn't need special binding, and is currently
used by mainline r8723bs driver.)
>
>ChenYu
>
>>
>>>
>>>ChenYu
>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>>+++++++++++++++++++
>>>> 2 files changed, 37 insertions(+)
>>>>
>>>> diff --git
>>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> index d0fcc25efb00..d0f775613c9b 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> @@ -18,3 +18,11 @@
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&mmc1 {
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&wifi_pwrseq {
>>>> + status = "okay";
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> index a85867f8b684..75db6d4139bf 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> @@ -40,6 +40,12 @@
>>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /*
>PL7
>>>*/
>>>> };
>>>> };
>>>> +
>>>> + wifi_pwrseq: wifi_pwrseq {
>>>> + compatible = "mmc-pwrseq-simple";
>>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2
>*/
>>>> + status = "disabled";
>>>> + };
>>>> };
>>>>
>>>> &mmc0 {
>>>> @@ -50,6 +56,17 @@
>>>> status = "okay";
>>>> };
>>>>
>>>> +&mmc1 {
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mmc1_pins>;
>>>> + vmmc-supply = <®_cldo2>;
>>>> + vqmmc-supply = <®_bldo2>;
>>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>>> + bus-width = <4>;
>>>> + non-removable;
>>>> + status = "disabled";
>>>> +};
>>>> +
>>>> &mmc2 {
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&mmc2_pins>;
>>>> @@ -128,12 +145,24 @@
>>>> };
>>>>
>>>> reg_cldo2: cldo2 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO3.
>>>> + * Before the kernel can support
>>>synchronized
>>>> + * enable of coupled regulators,
>keep
>>>them
>>>> + * both always on as a ugly hack.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-1";
>>>> };
>>>>
>>>> reg_cldo3: cldo3 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO2.
>>>> + * See the comments for CLDO2.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-2";
>>>> --
>>>> 2.18.0
>>>>
>>
>> --
>> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: h6: add Wi-Fi support for Pine H64 model A/B
From: Icenowy Zheng @ 2018-07-24 2:28 UTC (permalink / raw)
To: wens, Chen-Yu Tsai
Cc: Maxime Ripard, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAGb2v64Qae4O430kP30DQNhp0Dt774OHt0nMe35ckp8X=CTFLg@mail.gmail.com>
于 2018年7月24日 GMT+08:00 上午10:26:02, Chen-Yu Tsai <wens@csie.org> 写到:
>On Tue, Jul 24, 2018 at 10:23 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>
>>
>> 于 2018年7月24日 GMT+08:00 上午10:21:59, Chen-Yu Tsai <wens@csie.org> 写到:
>>>On Tue, Jul 24, 2018 at 9:15 AM, Icenowy Zheng <icenowy@aosc.io>
>wrote:
>>>> The Pine H64 model A has a Wi-Fi module connector and the model B
>has
>>>an
>>>> on-board RTL8723BS Wi-Fi module.
>>>>
>>>> Add support for them. For model A, as it's not defaultly present,
>>>keep
>>>> it disabled now.
>>>
>>>Nope. Pine64 actually has two WiFi/BT modules. And they require
>>>different
>>>device tree snippets for both the WiFi and BT side. This is better
>>>resolved
>>>with device tree overlays.
>>>
>>>I have both, though I've yet found time to work on them.
>>
>> I have also both.
>>
>> The skeleton here can get the Wi-Fi of both to work.
>
>Cool. Then I can put away my RTL module for now. :)
P.S. SDIO is auto detectable, and for BCM chips, the OOB interrupt
is only a bonus function and it can fall back to standard in-band
interrupt (which doesn't need special binding, and is currently
used by mainline r8723bs driver.)
>
>ChenYu
>
>>
>>>
>>>ChenYu
>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> .../allwinner/sun50i-h6-pine-h64-model-b.dts | 8 +++++
>>>> .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29
>>>+++++++++++++++++++
>>>> 2 files changed, 37 insertions(+)
>>>>
>>>> diff --git
>>>a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> index d0fcc25efb00..d0f775613c9b 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-model-b.dts
>>>> @@ -18,3 +18,11 @@
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&mmc1 {
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&wifi_pwrseq {
>>>> + status = "okay";
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> index a85867f8b684..75db6d4139bf 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>>>> @@ -40,6 +40,12 @@
>>>> gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; /*
>PL7
>>>*/
>>>> };
>>>> };
>>>> +
>>>> + wifi_pwrseq: wifi_pwrseq {
>>>> + compatible = "mmc-pwrseq-simple";
>>>> + reset-gpios = <&r_pio 1 3 GPIO_ACTIVE_LOW>; /* PL2
>*/
>>>> + status = "disabled";
>>>> + };
>>>> };
>>>>
>>>> &mmc0 {
>>>> @@ -50,6 +56,17 @@
>>>> status = "okay";
>>>> };
>>>>
>>>> +&mmc1 {
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mmc1_pins>;
>>>> + vmmc-supply = <®_cldo2>;
>>>> + vqmmc-supply = <®_bldo2>;
>>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>>> + bus-width = <4>;
>>>> + non-removable;
>>>> + status = "disabled";
>>>> +};
>>>> +
>>>> &mmc2 {
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&mmc2_pins>;
>>>> @@ -128,12 +145,24 @@
>>>> };
>>>>
>>>> reg_cldo2: cldo2 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO3.
>>>> + * Before the kernel can support
>>>synchronized
>>>> + * enable of coupled regulators,
>keep
>>>them
>>>> + * both always on as a ugly hack.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-1";
>>>> };
>>>>
>>>> reg_cldo3: cldo3 {
>>>> + /*
>>>> + * This regulator is connected with
>>>CLDO2.
>>>> + * See the comments for CLDO2.
>>>> + */
>>>> + regulator-always-on;
>>>> regulator-min-microvolt =
><3300000>;
>>>> regulator-max-microvolt =
><3300000>;
>>>> regulator-name = "vcc-wifi-2";
>>>> --
>>>> 2.18.0
>>>>
>>
>> --
>> 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@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] mkfs.f2fs: Fix the checkpoint version written to the footer of the root inode
From: Sotirios-Efstathios Maneas @ 2018-07-24 2:28 UTC (permalink / raw)
To: linux-f2fs-devel
Dear all,
The following patch fixes the checkpoint version written to the footer of the inode associated with the root directory, while creating
the file system from scratch. Furthermore, the patch fixes some typos in the printed messages.
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 1a2deae..25febd1 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -28,6 +28,7 @@ extern struct f2fs_configuration c;
struct f2fs_super_block raw_sb;
struct f2fs_super_block *sb = &raw_sb;
struct f2fs_checkpoint *cp;
+int f2fs_checkpoint_version;
/* Return first segment number of each area */
#define prev_zone(cur) (c.cur_seg[cur] - c.segs_per_zone)
@@ -592,13 +593,13 @@ static int f2fs_write_check_point_pack(void)
sum = calloc(F2FS_BLKSIZE, 1);
if (sum == NULL) {
- MSG(1, "\tError: Calloc Failed for summay_node!!!\n");
+ MSG(1, "\tError: Calloc Failed for summary_node!!!\n");
goto free_cp;
}
sum_compact = calloc(F2FS_BLKSIZE, 1);
if (sum_compact == NULL) {
- MSG(1, "\tError: Calloc Failed for summay buffer!!!\n");
+ MSG(1, "\tError: Calloc Failed for summary buffer!!!\n");
goto free_sum;
}
sum_compact_p = sum_compact;
@@ -619,8 +620,7 @@ static int f2fs_write_check_point_pack(void)
}
/* 1. cp page 1 of checkpoint pack 1 */
- srand(time(NULL));
- cp->checkpoint_ver = cpu_to_le64(rand() | 0x1);
+ cp->checkpoint_ver = cpu_to_le64(f2fs_checkpoint_version);
set_cp(cur_node_segno[0], c.cur_seg[CURSEG_HOT_NODE]);
set_cp(cur_node_segno[1], c.cur_seg[CURSEG_WARM_NODE]);
set_cp(cur_node_segno[2], c.cur_seg[CURSEG_COLD_NODE]);
@@ -920,7 +920,7 @@ static int f2fs_write_check_point_pack(void)
}
/* cp page 1 of check point pack 2
- * Initiatialize other checkpoint pack with version zero
+ * Initialise other checkpoint pack with version zero
*/
cp->checkpoint_ver = 0;
@@ -975,6 +975,10 @@ static int f2fs_write_super_block(void)
u_int8_t *zero_buff;
zero_buff = calloc(F2FS_BLKSIZE, 1);
+ if (!zero_buff) {
+ MSG(1, "\tError: Calloc Failed for f2fs_write_super_block!!!\n");
+ return -1;
+ }
memcpy(zero_buff + F2FS_SUPER_OFFSET, sb, sizeof(*sb));
DBG(1, "\tWriting super block, at offset 0x%08x\n", 0);
@@ -1057,9 +1061,12 @@ static int f2fs_write_root_inode(void)
return -1;
}
+ srand(time(NULL));
+ f2fs_checkpoint_version = rand() | 0x1;
+
raw_node->footer.nid = sb->root_ino;
raw_node->footer.ino = sb->root_ino;
- raw_node->footer.cp_ver = cpu_to_le64(1);
+ raw_node->footer.cp_ver = cpu_to_le64(f2fs_checkpoint_version);
raw_node->footer.next_blkaddr = cpu_to_le32(
get_sb(main_blkaddr) +
c.cur_seg[CURSEG_HOT_NODE] *
@@ -1630,13 +1637,13 @@ int f2fs_format_device(void)
err = f2fs_init_sit_area();
if (err < 0) {
- MSG(0, "\tError: Failed to Initialise the SIT AREA!!!\n");
+ MSG(0, "\tError: Failed to initialise the SIT AREA!!!\n");
goto exit;
}
err = f2fs_init_nat_area();
if (err < 0) {
- MSG(0, "\tError: Failed to Initialise the NAT AREA!!!\n");
+ MSG(0, "\tError: Failed to initialise the NAT AREA!!!\n");
goto exit;
}
diff --git a/mkfs/f2fs_format_main.c b/mkfs/f2fs_format_main.c
index 449a0ed..95eec67 100644
--- a/mkfs/f2fs_format_main.c
+++ b/mkfs/f2fs_format_main.c
@@ -193,22 +193,22 @@ static void f2fs_parse_options(int argc, char *argv[])
if (!(c.feature & cpu_to_le32(F2FS_FEATURE_EXTRA_ATTR))) {
if (c.feature & cpu_to_le32(F2FS_FEATURE_PRJQUOTA)) {
- MSG(0, "\tInfo: project quota feature should always been"
+ MSG(0, "\tInfo: project quota feature should always be"
"enabled with extra attr feature\n");
exit(1);
}
if (c.feature & cpu_to_le32(F2FS_FEATURE_INODE_CHKSUM)) {
- MSG(0, "\tInfo: inode checksum feature should always been"
+ MSG(0, "\tInfo: inode checksum feature should always be"
"enabled with extra attr feature\n");
exit(1);
}
if (c.feature & cpu_to_le32(F2FS_FEATURE_FLEXIBLE_INLINE_XATTR)) {
- MSG(0, "\tInfo: flexible inline xattr feature should always been"
+ MSG(0, "\tInfo: flexible inline xattr feature should always be"
"enabled with extra attr feature\n");
exit(1);
}
if (c.feature & cpu_to_le32(F2FS_FEATURE_INODE_CRTIME)) {
- MSG(0, "\tInfo: inode crtime feature should always been"
+ MSG(0, "\tInfo: inode crtime feature should always be"
"enabled with extra attr feature\n");
exit(1);
}
Kind regards,
Stathis Maneas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* [PATCH 0/5 v2] Add a standard module for accessing the layerindex
From: Mark Hatle @ 2018-07-24 2:29 UTC (permalink / raw)
To: bitbake-devel
Changes available at:
git://git.openembedded.org/bitbake-contrib bitbake-layerindex
v2:
Refactored the module to address Paul E's concerns:
* Treat LAYERSERIES_CORENAMES as a list of supported branches
* Remove type= stuff in plugins, now iterate through plugins until one
of them accepts the data
* Fix incorrect exceptions, add additional exceptions as necessary
* Replace space separated lists with python lists.. (Few minor excptions,
documented why where still necessary.)
* Refactor item and object classes:
- Each LayerIndexItem now uses both decorators and properties to manage
access to the private data
- New LayerIndexObj class to handle a -single- layerindex, the main
module now is a list of LayerIndexObjs
* Lots of variable name changes and cleanups
* Removed dummy API to implement a json query
* General refactoring to accomplish the above
* bitbake-layers layerindex-*
- Now checks the cooker first, if the layer is already present skips
going to the network
Selftest passes.
bitbake-layers layerindex-fetch and layerindex-show-depends pass
Note: as before the toaster change needs additional verication then
what I'm current able to provide. But it -should- work as patched.
V1:
In order to simply existing components, and add support to create some
new functionaly -- we need a common apporach for access the layerindex.
The class supports loading multilib layerindexes, but right now that
functionality is not being used by either bitbake-layers or the toaster.
There are a few 'TODO' items that remain in the code. These are related
to either un-implemented, but planned functionality or to display stuff
in bitbake-layers. I'm hoping that part of this review can discuss the
TODO items.
Mark Hatle (5):
bblayers/layerindex.py: Fix addition of layers
layerindexlib: Initial layer index processing module implementation
bblayers/layerindex.py: Switch to use the new layerindexlib class
bitbake-layers: disable parsing for layerindex commands
toaster/orm/management/commands/lsupdates.py: Use new layerindexlib
module
bin/bitbake-selftest | 6 +-
lib/bblayers/layerindex.py | 323 ++---
lib/layerindexlib/README | 28 +
lib/layerindexlib/__init__.py | 1364 ++++++++++++++++++++
lib/layerindexlib/cooker.py | 341 +++++
lib/layerindexlib/plugin.py | 60 +
lib/layerindexlib/restapi.py | 398 ++++++
lib/layerindexlib/tests/__init__.py | 0
lib/layerindexlib/tests/common.py | 43 +
lib/layerindexlib/tests/cooker.py | 123 ++
lib/layerindexlib/tests/layerindexobj.py | 226 ++++
lib/layerindexlib/tests/restapi.py | 174 +++
lib/layerindexlib/tests/testdata/README | 11 +
.../tests/testdata/build/conf/bblayers.conf | 15 +
.../tests/testdata/layer1/conf/layer.conf | 17 +
.../tests/testdata/layer2/conf/layer.conf | 20 +
.../tests/testdata/layer3/conf/layer.conf | 19 +
.../tests/testdata/layer4/conf/layer.conf | 22 +
lib/toaster/orm/management/commands/lsupdates.py | 216 ++--
19 files changed, 3083 insertions(+), 323 deletions(-)
create mode 100644 lib/layerindexlib/README
create mode 100644 lib/layerindexlib/__init__.py
create mode 100644 lib/layerindexlib/cooker.py
create mode 100644 lib/layerindexlib/plugin.py
create mode 100644 lib/layerindexlib/restapi.py
create mode 100644 lib/layerindexlib/tests/__init__.py
create mode 100644 lib/layerindexlib/tests/common.py
create mode 100644 lib/layerindexlib/tests/cooker.py
create mode 100644 lib/layerindexlib/tests/layerindexobj.py
create mode 100644 lib/layerindexlib/tests/restapi.py
create mode 100644 lib/layerindexlib/tests/testdata/README
create mode 100644 lib/layerindexlib/tests/testdata/build/conf/bblayers.conf
create mode 100644 lib/layerindexlib/tests/testdata/layer1/conf/layer.conf
create mode 100644 lib/layerindexlib/tests/testdata/layer2/conf/layer.conf
create mode 100644 lib/layerindexlib/tests/testdata/layer3/conf/layer.conf
create mode 100644 lib/layerindexlib/tests/testdata/layer4/conf/layer.conf
--
1.8.3.1
^ permalink raw reply
* Re: [RFC PATCH 05/10] iommu/vt-d: Setup DMA remapping for mediated devices
From: Lu Baolu @ 2018-07-24 2:29 UTC (permalink / raw)
To: Liu, Yi L, Joerg Roedel, David Woodhouse, Alex Williamson,
Kirti Wankhede
Cc: Raj, Ashok, Kumar, Sanjay K, Pan, Jacob jun, Tian, Kevin,
Sun, Yi Y, peterx@redhat.com, iommu@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jacob Pan
In-Reply-To: <A2975661238FB949B60364EF0F2C257439CA1449@SHSMSX104.ccr.corp.intel.com>
Hi,
On 07/23/2018 12:44 PM, Liu, Yi L wrote:
>> From: Lu Baolu [mailto:baolu.lu@linux.intel.com]
>> Sent: Sunday, July 22, 2018 2:09 PM
>>
>> This configures the second level page table when external components request to
>> allocate a domain for a mediated device.
> I think it should be the time when adding a mediate device to the domain.
You are right. Will correct it.
>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
>> Cc: Kevin Tian <kevin.tian@intel.com>
>> Cc: Liu Yi L <yi.l.liu@intel.com>
>> Signed-off-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>> drivers/iommu/intel-iommu.c | 73
>> ++++++++++++++++++++++++++++++++++++++++-----
>> 1 file changed, 66 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index
>> 57ccfc4..b6e9ea8 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -2569,8 +2569,9 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> if (dev)
>> dev->archdata.iommu = info;
>>
>> - if (dev && dev_is_pci(dev) && sm_supported(iommu)) {
>> - bool pass_through;
>> + if (dev && sm_supported(iommu)) {
>> + bool pass_through = hw_pass_through &&
>> + domain_type_is_si(domain);
>>
>> ret = intel_pasid_alloc_table(dev);
>> if (ret) {
>> @@ -2579,12 +2580,21 @@ static struct dmar_domain
>> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>> return NULL;
>> }
>>
>> - /* Setup the PASID entry for requests without PASID: */
>> - pass_through = hw_pass_through && domain_type_is_si(domain);
>> spin_lock(&iommu->lock);
>> - intel_pasid_setup_second_level(iommu, domain, dev,
>> - PASID_RID2PASID,
>> - pass_through);
>> +
>> + /* Setup the PASID entry for requests without PASID: */
>> + if (dev_is_pci(dev))
>> + intel_pasid_setup_second_level(iommu, domain, dev,
>> + PASID_RID2PASID,
> can domain->default_pasid be initialized to be PASID_RID2PASID if the domain
> is not a domain used by mediated device?
PASID_RID2PASID is 0 as well.
>
>> + pass_through);
>> + /* Setup the PASID entry for mediated devices: */
>> + else if (dev_is_mdev(dev))
>> + intel_pasid_setup_second_level(iommu, domain, dev,
>> + domain->default_pasid,
>> + false);
>> + else
>> + pr_err("Unsupported device %s\n", dev_name(dev));
>> +
>> spin_unlock(&iommu->lock);
>> }
>> spin_unlock_irqrestore(&device_domain_lock, flags); @@ -4937,6 +4947,32
>> @@ static void domain_context_clear(struct intel_iommu *iommu, struct device
>> *dev)
>> pci_for_each_dma_alias(to_pci_dev(dev), &domain_context_clear_one_cb,
>> iommu); }
>>
>> +static void
>> +iommu_flush_ext_iotlb(struct intel_iommu *iommu, u16 did, u32 pasid,
> Per latest VT-d spec, its new name is pasid-based-iotlb. Pls update the naming
> accordingly. :)
Okay.
Best regards,
Lu Baolu
>
> Regards,
> Yi Liu
>
>> +u64 gran) {
>> + struct qi_desc desc;
>> +
>> + desc.high = 0;
>> + desc.low = QI_EIOTLB_PASID(pasid) | QI_EIOTLB_DID(did) |
>> + QI_EIOTLB_GRAN(gran) | QI_EIOTLB_TYPE;
>> +
>> + qi_submit_sync(&desc, iommu);
>> +}
>> +
>> +static void iommu_flush_pasid_dev_iotlb(struct intel_iommu *iommu,
>> + struct device *dev, int sid, int pasid) {
>> + struct qi_desc desc;
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + int qdep = pci_ats_queue_depth(pdev);
>> +
>> + desc.low = QI_DEV_EIOTLB_PASID(pasid) | QI_DEV_EIOTLB_SID(sid) |
>> + QI_DEV_EIOTLB_QDEP(qdep) | QI_DEIOTLB_TYPE;
>> + desc.high = QI_DEV_EIOTLB_ADDR(-1ULL >> 1) | QI_DEV_EIOTLB_SIZE;
>> +
>> + qi_submit_sync(&desc, iommu);
>> +}
>> +
>> static void __dmar_remove_one_dev_info(struct device_domain_info *info) {
>> struct intel_iommu *iommu;
>> @@ -4949,6 +4985,29 @@ static void __dmar_remove_one_dev_info(struct
>> device_domain_info *info)
>>
>> iommu = info->iommu;
>>
>> + if (dev_is_mdev(info->dev)) {
>> + struct dmar_domain *domain = info->domain;
>> + int did = domain->iommu_did[iommu->seq_id];
>> + int sid = info->bus << 8 | info->devfn;
>> + struct device *dev = info->dev;
>> +
>> + intel_pasid_clear_entry(dev, domain->default_pasid);
>> +
>> + /* Flush IOTLB including PASID Cache: */
>> + iommu->flush.flush_iotlb(iommu, did, 0, 0, DMA_TLB_DSI_FLUSH);
>> +
>> + /*
>> + * Flush EIOTLB. The only way to flush global mappings within
>> + * a PASID is to use QI_GRAN_ALL_ALL.
>> + */
>> + iommu_flush_ext_iotlb(iommu, did, domain->default_pasid,
>> + QI_GRAN_ALL_ALL);
>> +
>> + /* Flush Dev TLB: */
>> + iommu_flush_pasid_dev_iotlb(iommu, dev_mdev_parent(dev), sid,
>> + domain->default_pasid);
>> + }
>> +
>> if (info->dev) {
>> iommu_disable_dev_iotlb(info);
>> domain_context_clear(iommu, info->dev);
>> --
>> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.