* [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar at gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel at pengutronix.de;
> linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* RE: [PATCH v6 0/5] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-07-24 2:18 UTC (permalink / raw)
To: Jassi Brar, Oleksij Rempel
Cc: Mark Rutland, devicetree@vger.kernel.org, Vladimir Zapolskiy,
Rob Herring, dl-linux-imx, kernel@pengutronix.de, Fabio Estevam,
Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY1r=Sg64t3j45XXSJu-_HYx2Uya0WLDHP82stiQ4vnM5A@mail.gmail.com>
> -----Original Message-----
> From: Jassi Brar [mailto:jassisinghbrar@gmail.com]
> Sent: Monday, July 23, 2018 11:33 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: Oleksij Rempel <o.rempel@pengutronix.de>; kernel@pengutronix.de;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; dl-linux-
> imx <linux-imx@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Fabio
> Estevam <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Vladimir Zapolskiy
> <vladimir_zapolskiy@mentor.com>
> Subject: Re: [PATCH v6 0/5] add mailbox support for i.MX7D
>
> On Sun, Jul 22, 2018 at 4:14 PM, A.s. Dong <aisheng.dong@nxp.com> wrote:
> > Hi Oleksij,
> >
> > Thanks for the work.
> >
> > Hi Jassi,
> > Do you think if we can have your tag and let those patches go through
> > Shawn's tree as the later QXP support patches depends on them?
> >
> Hmm... I don't find the 5 patches in my mailbox. Are you sure I was CC'ed?
I guess you are missed to be CC'ed.
Oleksij,
As there're some new review comments and may need a small change,
please do not miss to CC Jassi (Mailbox Maintainer) in the next version
of your patch series.
Regards
Dong Aisheng
>
> Dong Aisheng (2):
> dt-bindings: mailbox: allow mbox-cells to be equal to 0
> dt-bindings: arm: fsl: add mu binding doc
>
> Oleksij Rempel (3):
> dt-bindings: mailbox: imx-mu: add generic MU channel support
> ARM: dts: imx7s: add i.MX7 messaging unit support
> mailbox: Add support for i.MX7D messaging unit
^ permalink raw reply
* [RELEASE] LTTng-Tools 2.9.10 - Joannès
From: Jérémie Galarneau @ 2018-07-24 2:18 UTC (permalink / raw)
To: lttng-dev
Hi all,
The tenth bug-fix release of LTTng-Tools 2.9 - Joannès has just been
released. This release addresses a number of issues listed below.
2018-07-23 lttng-tools 2.9.10 (National Vanilla Ice Cream Day)
* Fix: missing context enum values in session xml schema
* Tests: add session auto-loading test cases
* Bash completion: ignore namespace for xmllint parsing
* Typo in ust consumer log message (channek -> channel)
* Fix: use signed variable for refcounting of consumer_relayd_sock_pair
* Fix: warning due to hash_key_str() being not const-correct
* Fix: calling ht_{hash, match}_enum with wrong argument
* Fix: probes should be compared strictly by events metadata
* Fix: test_ust-dl is generated at configure-time
* Fix: perform the initialization memory barrier out of loop body
* Port: fix format warnings on Cygwin
* Fix: don't wait for the load thread before serving client commands
* Fix: sessiond fails to launch on --without-ust configuration
* Fix: agent thread poll set creation failure results in deadlock
* Fix: test uses sizeof() on the wrong operand of strncpy
As always, please report any issue you may encounter to bugs.lttng.org
or on this mailing list.
Project website: https://lttng.org
Download link:
https://lttng.org/files/lttng-tools/lttng-tools-2.9.10.tar.bz2
GPG sig:
https://lttng.org/files/lttng-tools/lttng-tools-2.9.10.tar.bz2.asc
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [RELEASE] LTTng-Tools 2.10.5 - KeKriek
From: Jérémie Galarneau @ 2018-07-24 2:18 UTC (permalink / raw)
To: lttng-dev
Hi all,
The fifth bug-fix release of LTTng-Tools 2.10 - KeKriek has just been
released. This release addresses a number of issues listed below.
2018-07-23 lttng-tools 2.10.5 (National Vanilla Ice Cream Day)
* Fix: missing context enum values in session xml schema
* Tests: add session auto-loading test cases
* Bash completion: ignore namespace for xmllint parsing
* Typo in ust consumer log message (channek -> channel)
* Fix: use signed variable for refcounting of consumer_relayd_sock_pair
* Fix: warning due to hash_key_str() being not const-correct
* Print consumerd32/64/kernel configuration
* Fix: calling ht_{hash, match}_enum with wrong argument
* Fix: probes should be compared strictly by events metadata
* Fix: test_ust-dl is generated at configure-time
* Fix: cmd line options overwrite env variable config options
* Fix: perform the initialization memory barrier out of loop body
* Port: fix format warnings on Cygwin
* Add missing include for ssize_t on Cygwin
* Fix: sessions with agent channels fail to load
* Fix: don't wait for the load thread before serving client commands
* Fix: sessiond fails to launch on --without-ust configuration
* Fix: agent thread poll set creation failure results in deadlock
* Fix: test uses sizeof() on the wrong operand of strncpy
* Fix: ret may be used uninitialized in sample_channel_positions()
As always, please report any issue you may encounter to bugs.lttng.org
or on this mailing list.
Project website: https://lttng.org
Download link:
https://lttng.org/files/lttng-tools/lttng-tools-2.10.5.tar.bz2
GPG sig:
https://lttng.org/files/lttng-tools/lttng-tools-2.10.5.tar.bz2.asc
--
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk
From: Sinan Kaya @ 2018-07-24 2:20 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-pci, linux-kernel, linux-nvme
In-Reply-To: <20180723195711.0a3c9301@t450s.home>
On 7/23/18, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 23 Jul 2018 17:40:02 -0700
> Sinan Kaya <okaya@kernel.org> wrote:
>
>> On 7/23/2018 5:13 PM, Alex Williamson wrote:
>> > + * The NVMe specification requires that controllers support PCIe FLR,
>> > but
>> > + * but some Samsung SM961/PM961 controllers fail to recover after FLR
>> > (-1
>> > + * config space) unless the device is quiesced prior to FLR.
>>
>> Does disabling the memory bit in PCI config space as part of the FLR
>> reset function help? (like the very first thing)
>
> No, it does not. I modified this to only clear PCI_COMMAND_MEMORY and
> call pcie_flr(), the Samsung controller dies just as it did previously.
>
>> Can we do that in the pcie_flr() function to cover other endpoint types
>> that might be pushing traffic while code is trying to do a reset?
>
> Do you mean PCI_COMMAND_MASTER rather than PCI_COMMAND_MEMORY?
Yes
> I tried
> that too, it doesn't work either. I'm not really sure the theory
> behind clearing memory, clearing busmaster to stop DMA seems like a
> sane thing to do, but doesn't help here.
Let me explain what I guessed. You might be able to fill in the blanks
where I am completely off.
We do vfio initiated flr reset immediately following guest machine
shutdown. The card could be fully enabled and pushing traffic to the
system at this moment.
I don't know if vfio does any device disable or not.
FLR is supposed to reset the endpoint but endpoint doesn't recover per
your report.
Having vendor specific reset routines for PCIE endpoints defeats the
purpose of FLR.
Since the adapter is fully functional, i suggested turning off bus
master and memory enable bits to stop endpoint from sending packets.
But, this is not helping either.
Those sleep statements looked very fragile to be honest.
I was curious if there is something else that we could do for other endpoints.
No objections otherwise.
>
> Alex
>
^ permalink raw reply
* Re: [PATCH] nios2: use generic dma_noncoherent_ops
From: Ley Foon Tan @ 2018-07-24 2:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: nios2-dev-g9ZBwUv/Ih/yUk5EbOjzuce+I+R0W71w,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20180723082717.GA19548-jcswGhMUV9g@public.gmane.org>
On Mon, 2018-07-23 at 10:27 +0200, Christoph Hellwig wrote:
> On Mon, Jul 23, 2018 at 04:20:42PM +0800, Ley Foon Tan wrote:
> >
> > On Thu, 2018-07-19 at 14:22 +0200, Christoph Hellwig wrote:
> > >
> > > On Thu, Jul 19, 2018 at 01:48:55PM +0800, Ley Foon Tan wrote:
> > > >
> > > >
> > > > Do you have git repo for this series of patches?
> > > This patch should apply without the need for any other patch
> > > to Linus' latest tree, but I have a tree with all the conversions
> > > here:
> > >
> > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/hea
> > > ds/g
> > > eneric-dma-noncoherent.3
> > Hi
> >
> > Compilation, system bootup and Ethernet are working fine with this
> > patch.
> Do you want to merge it through the nios tree or should I pick it up?
Hi
Please pick it up with your git tree.
Thanks.
Regards
Ley Foon
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [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
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.