Re: Ordering Dell XPS 13 9310 to test QCA6390

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Mitchell Nordine]

> But I have now ordered Dell XPS 13 laptop and I should get it in three weeks, keeping fingers crossed. That should make things easier as I can test patches myself.

Hi Kalle, you may already be aware of this, but I just wanted to make sure!

Not all Dell XPS 13 9310 laptops come with the AX500 connectivity chip (the one that uses the QCA6390). It seems that only the models with 32GB RAM tend to come with the AX500 wifi chip.

Most models appear to come with the AX1650 which I believe uses a totally different chip and driver that is already well supported in Linux.

It might be worth double-checking the model that you have ordered has the AX500.

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

Mitchell Nordine <mail@mitchellnordine.com> writes:

>> But I have now ordered Dell XPS 13 laptop and I should get it in
> three weeks, keeping fingers crossed. That should make things easier
> as I can test patches myself.
>
> Hi Kalle, you may already be aware of this, but I just wanted to make sure!
>
> Not all Dell XPS 13 9310 laptops come with the AX500 connectivity chip
> (the one that uses the QCA6390). It seems that only the models with
> 32GB RAM tend to come with the AX500 wifi chip.
>
> Most models appear to come with the AX1650 which I believe uses a
> totally different chip and driver that is already well supported in
> Linux.
>
> It might be worth double-checking the model that you have ordered has the AX500.

I had heard about that so I did order the 32 GB RAM model and multiple
times specified that I only want AX500. So I'm optimistic that I should
get the right chip, but you never know how it goes :) Thanks for
checking, though!

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

Kalle Valo <kvalo@codeaurora.org> writes:

> Mitchell Nordine <mail@mitchellnordine.com> writes:
>
>>> But I have now ordered Dell XPS 13 laptop and I should get it in
>> three weeks, keeping fingers crossed. That should make things easier
>> as I can test patches myself.
>>
>> Hi Kalle, you may already be aware of this, but I just wanted to make sure!
>>
>> Not all Dell XPS 13 9310 laptops come with the AX500 connectivity chip
>> (the one that uses the QCA6390). It seems that only the models with
>> 32GB RAM tend to come with the AX500 wifi chip.
>>
>> Most models appear to come with the AX1650 which I believe uses a
>> totally different chip and driver that is already well supported in
>> Linux.
>>
>> It might be worth double-checking the model that you have ordered has the AX500.
>
> I had heard about that so I did order the 32 GB RAM model and multiple
> times specified that I only want AX500. So I'm optimistic that I should
> get the right chip, but you never know how it goes :)

I got the XPS 13 9310 now and it indeed had AX500. But it also has an
updated BIOS:

[    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4 11/23/2020

And with that I can get 32 MSI vectors:

[    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is experimental!
[    2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem 0x8c300000-0x8c3fffff 64bit]
[    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
[    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
[    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x3f000000 3522560 1
[    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x3f500000 884736 4
[    3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
[    3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id 

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[wi nk]

On Wed, Jan 13, 2021 at 11:25 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Mitchell Nordine <mail@mitchellnordine.com> writes:
> >
> >>> But I have now ordered Dell XPS 13 laptop and I should get it in
> >> three weeks, keeping fingers crossed. That should make things easier
> >> as I can test patches myself.
> >>
> >> Hi Kalle, you may already be aware of this, but I just wanted to make sure!
> >>
> >> Not all Dell XPS 13 9310 laptops come with the AX500 connectivity chip
> >> (the one that uses the QCA6390). It seems that only the models with
> >> 32GB RAM tend to come with the AX500 wifi chip.
> >>
> >> Most models appear to come with the AX1650 which I believe uses a
> >> totally different chip and driver that is already well supported in
> >> Linux.
> >>
> >> It might be worth double-checking the model that you have ordered has the AX500.
> >
> > I had heard about that so I did order the 32 GB RAM model and multiple
> > times specified that I only want AX500. So I'm optimistic that I should
> > get the right chip, but you never know how it goes :)
>
> I got the XPS 13 9310 now and it indeed had AX500. But it also has an
> updated BIOS:
>
> [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4 11/23/2020
>
> And with that I can get 32 MSI vectors:
>
> [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is experimental!
> [    2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem 0x8c300000-0x8c3fffff 64bit]
> [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
> [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
> [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x3f000000 3522560 1
> [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x3f500000 884736 4
> [    3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
> [    3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
> --
> ath11k mailing list
> ath11k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath11k

Kalle,

  I did see the updated BIOS from a few weeks ago, but I've been a
little hesitant to update since I wasn't sure what would happen or if
I could downgrade.  So to confirm, the new BIOS is allowing the driver
to obtain all 32 msi vectors removing the need for the single MSI
patching?  Does the MHI / M2 behavior also change to work properly?

Thanks!

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

wi nk <wink@technolu.st> writes:

>> I got the XPS 13 9310 now and it indeed had AX500. But it also has an
>> updated BIOS:
>>
>> [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4 11/23/2020
>>
>> And with that I can get 32 MSI vectors:
>>
>> [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is experimental!
>> [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
>> 0x8c300000-0x8c3fffff 64bit]
>> [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
>> [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
>> [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x3f000000 3522560 1
>> [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x3f500000 884736 4
>> [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
>> board_id 0xff soc_id 0xffffffff
>> [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
>> fw_build_timestamp 2020-06-24 19:50 fw_build_id
>
>   I did see the updated BIOS from a few weeks ago, but I've been a
> little hesitant to update since I wasn't sure what would happen or if
> I could downgrade.

Makes sense, better to be careful.

> So to confirm, the new BIOS is allowing the driver to obtain all 32
> msi vectors removing the need for the single MSI patching? Does the
> MHI / M2 behavior also change to work properly?

I have not tested these yet as I only did a quick 10 minute test. I was
offline over two weeks so I have a lot of catching up to do, but will
get back to you in next few days on these. My plan is to also test this
new BIOS with the official 5.10 release from Linus (tag v5.10).

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[wi nk]

On Wed, Jan 13, 2021 at 12:54 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> wi nk <wink@technolu.st> writes:
>
> >> I got the XPS 13 9310 now and it indeed had AX500. But it also has an
> >> updated BIOS:
> >>
> >> [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4 11/23/2020
> >>
> >> And with that I can get 32 MSI vectors:
> >>
> >> [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is experimental!
> >> [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
> >> 0x8c300000-0x8c3fffff 64bit]
> >> [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
> >> [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
> >> [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x3f000000 3522560 1
> >> [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x3f500000 884736 4
> >> [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
> >> board_id 0xff soc_id 0xffffffff
> >> [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> >> fw_build_timestamp 2020-06-24 19:50 fw_build_id
> >
> >   I did see the updated BIOS from a few weeks ago, but I've been a
> > little hesitant to update since I wasn't sure what would happen or if
> > I could downgrade.
>
> Makes sense, better to be careful.
>
> > So to confirm, the new BIOS is allowing the driver to obtain all 32
> > msi vectors removing the need for the single MSI patching? Does the
> > MHI / M2 behavior also change to work properly?
>
> I have not tested these yet as I only did a quick 10 minute test. I was
> offline over two weeks so I have a lot of catching up to do, but will
> get back to you in next few days on these. My plan is to also test this
> new BIOS with the official 5.10 release from Linus (tag v5.10).
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Awesome, let me know how it goes.  I've got the 9310 branch running
5.10.2 with no issues (16 days uptime) so I wouldn't expect you to see
anything super new there, good luck :D.

ps - Happy new year

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: [**EXTERNAL**] Re: Ordering Dell XPS 13 9310 to test QCA6390

[Luo, Sining]

On Wed, 2021-01-13 at 13:02 +0100, wi nk wrote:
> On Wed, Jan 13, 2021 at 12:54 PM Kalle Valo <kvalo@codeaurora.org>
> wrote:
> > 
> > wi nk <wink@technolu.st> writes:
> > 
> > > > I got the XPS 13 9310 now and it indeed had AX500. But it also
> > > > has an
> > > > updated BIOS:
> > > > 
> > > > [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4
> > > > 11/23/2020
> > > > 
> > > > And with that I can get 32 MSI vectors:
> > > > 
> > > > [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI
> > > > support is experimental!
> > > > [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
> > > > 0x8c300000-0x8c3fffff 64bit]
> > > > [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 ->
> > > > 0002)
> > > > [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
> > > > [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0]
> > > > 0x3f000000 3522560 1
> > > > [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1]
> > > > 0x3f500000 884736 4
> > > > [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
> > > > board_id 0xff soc_id 0xffffffff
> > > > [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> > > > fw_build_timestamp 2020-06-24 19:50 fw_build_id
> > > 
> > >   I did see the updated BIOS from a few weeks ago, but I've been a
> > > little hesitant to update since I wasn't sure what would happen or
> > > if
> > > I could downgrade.
> > 
> > Makes sense, better to be careful.
> > 
> > > So to confirm, the new BIOS is allowing the driver to obtain all
> > > 32
> > > msi vectors removing the need for the single MSI patching? Does
> > > the
> > > MHI / M2 behavior also change to work properly?
> > 
> > I have not tested these yet as I only did a quick 10 minute test. I
> > was
> > offline over two weeks so I have a lot of catching up to do, but
> > will
> > get back to you in next few days on these. My plan is to also test
> > this
> > new BIOS with the official 5.10 release from Linus (tag v5.10).
> > 
> > --
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-wireless/list/__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusv5X588g$
> >  
> > 
> > https://urldefense.com/v3/__https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusay1hmvY$
> >  
> 
> Awesome, let me know how it goes.  I've got the 9310 branch running
> 5.10.2 with no issues (16 days uptime) so I wouldn't expect you to see
> anything super new there, good luck :D.
> 
> ps - Happy new year
> 

Hi Kalle and Wi,

I've upgraded my 9310 BIOS to the same 1.1.4 since it's available:

[    0.000000] DMI: Dell Inc. XPS 13 9310/0F7M4C, BIOS 1.1.4 11/23/2020

But it's still getting a single MSI vector:

[    3.143712] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is
experimental!
[    3.143794] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem 0x8c300000-
0x8c3fffff 64bit]
[    3.143811] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
[    3.143885] ath11k_pci 0000:56:00.0: MSI vectors: 1
[    3.755747] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x57400000
3522560 1
[    3.755748] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x54d00000
884736 4
[    3.764110] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
board_id 0xff soc_id 0xffffffff
[    3.764111] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
fw_build_timestamp 2020-06-24 19:50 fw_build_id 
[    3.933936] ath11k_pci 0000:56:00.0 wlp86s0: renamed from wlan0

Does it mean that the single MSI issue is not from the BIOS? 

There is a new bios 1.2.5 that just released 2 days ago, I will try that
and report back.

Happy New Year!
Sining
-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

"Luo, Sining" <sluo@ciena.com> writes:

> On Wed, 2021-01-13 at 13:02 +0100, wi nk wrote:
>> On Wed, Jan 13, 2021 at 12:54 PM Kalle Valo <kvalo@codeaurora.org>
>> wrote:
>> > 
>> > wi nk <wink@technolu.st> writes:
>> > 
>> > > > I got the XPS 13 9310 now and it indeed had AX500. But it also
>> > > > has an
>> > > > updated BIOS:
>> > > > 
>> > > > [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4
>> > > > 11/23/2020
>> > > > 
>> > > > And with that I can get 32 MSI vectors:
>> > > > 
>> > > > [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI
>> > > > support is experimental!
>> > > > [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
>> > > > 0x8c300000-0x8c3fffff 64bit]
>> > > > [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 ->
>> > > > 0002)
>> > > > [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
>> > > > [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0]
>> > > > 0x3f000000 3522560 1
>> > > > [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1]
>> > > > 0x3f500000 884736 4
>> > > > [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
>> > > > board_id 0xff soc_id 0xffffffff
>> > > > [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
>> > > > fw_build_timestamp 2020-06-24 19:50 fw_build_id
>> > > 
>> > >   I did see the updated BIOS from a few weeks ago, but I've been a
>> > > little hesitant to update since I wasn't sure what would happen or
>> > > if
>> > > I could downgrade.
>> > 
>> > Makes sense, better to be careful.
>> > 
>> > > So to confirm, the new BIOS is allowing the driver to obtain all
>> > > 32
>> > > msi vectors removing the need for the single MSI patching? Does
>> > > the
>> > > MHI / M2 behavior also change to work properly?
>> > 
>> > I have not tested these yet as I only did a quick 10 minute test. I
>> > was
>> > offline over two weeks so I have a lot of catching up to do, but
>> > will
>> > get back to you in next few days on these. My plan is to also test
>> > this
>> > new BIOS with the official 5.10 release from Linus (tag v5.10).
>> > 
>> > --
>> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-wireless/list/__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusv5X588g$
>> >  
>> > 
>> > https://urldefense.com/v3/__https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusay1hmvY$
>> >  
>> 
>> Awesome, let me know how it goes.  I've got the 9310 branch running
>> 5.10.2 with no issues (16 days uptime) so I wouldn't expect you to see
>> anything super new there, good luck :D.
>> 
>> ps - Happy new year
>> 
>
> Hi Kalle and Wi,
>
> I've upgraded my 9310 BIOS to the same 1.1.4 since it's available:
>
> [    0.000000] DMI: Dell Inc. XPS 13 9310/0F7M4C, BIOS 1.1.4 11/23/2020
>
> But it's still getting a single MSI vector:
>
> [    3.143712] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is
> experimental!
> [    3.143794] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem 0x8c300000-
> 0x8c3fffff 64bit]
> [    3.143811] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
> [    3.143885] ath11k_pci 0000:56:00.0: MSI vectors: 1
> [    3.755747] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x57400000
> 3522560 1
> [    3.755748] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x54d00000
> 884736 4
> [    3.764110] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
> board_id 0xff soc_id 0xffffffff
> [    3.764111] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> fw_build_timestamp 2020-06-24 19:50 fw_build_id 
> [    3.933936] ath11k_pci 0000:56:00.0 wlp86s0: renamed from wlan0
>
> Does it mean that the single MSI issue is not from the BIOS? 

Do you have vt-d enabled in BIOS? IIRC that's needed for 32 vectors.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Luo, Sining]

On Wed, 2021-01-13 at 19:05 +0200, Kalle Valo wrote:
> "Luo, Sining" <sluo@ciena.com> writes:
> 
> > On Wed, 2021-01-13 at 13:02 +0100, wi nk wrote:
> > > On Wed, Jan 13, 2021 at 12:54 PM Kalle Valo <kvalo@codeaurora.org>
> > > wrote:
> > > > 
> > > > wi nk <wink@technolu.st> writes:
> > > > 
> > > > > > I got the XPS 13 9310 now and it indeed had AX500. But it
> > > > > > also
> > > > > > has an
> > > > > > updated BIOS:
> > > > > > 
> > > > > > [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4
> > > > > > 11/23/2020
> > > > > > 
> > > > > > And with that I can get 32 MSI vectors:
> > > > > > 
> > > > > > [    2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI
> > > > > > support is experimental!
> > > > > > [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
> > > > > > 0x8c300000-0x8c3fffff 64bit]
> > > > > > [    2.758797] ath11k_pci 0000:56:00.0: enabling device
> > > > > > (0000 ->
> > > > > > 0002)
> > > > > > [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
> > > > > > [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0]
> > > > > > 0x3f000000 3522560 1
> > > > > > [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1]
> > > > > > 0x3f500000 884736 4
> > > > > > [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family
> > > > > > 0xb
> > > > > > board_id 0xff soc_id 0xffffffff
> > > > > > [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> > > > > > fw_build_timestamp 2020-06-24 19:50 fw_build_id
> > > > > 
> > > > >   I did see the updated BIOS from a few weeks ago, but I've
> > > > > been a
> > > > > little hesitant to update since I wasn't sure what would
> > > > > happen or
> > > > > if
> > > > > I could downgrade.
> > > > 
> > > > Makes sense, better to be careful.
> > > > 
> > > > > So to confirm, the new BIOS is allowing the driver to obtain
> > > > > all
> > > > > 32
> > > > > msi vectors removing the need for the single MSI patching?
> > > > > Does
> > > > > the
> > > > > MHI / M2 behavior also change to work properly?
> > > > 
> > > > I have not tested these yet as I only did a quick 10 minute
> > > > test. I
> > > > was
> > > > offline over two weeks so I have a lot of catching up to do, but
> > > > will
> > > > get back to you in next few days on these. My plan is to also
> > > > test
> > > > this
> > > > new BIOS with the official 5.10 release from Linus (tag v5.10).
> > > > 
> > > > --
> > > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-wireless/list/__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusv5X588g$
> > > >  
> > > > 
> > > > https://urldefense.com/v3/__https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches__;!!OSsGDw!d42JFwn6tITykEUQ6ZYtfIMif5BRPdVt_zOqCzoINc640OzwSHusay1hmvY$
> > > >  
> > > 
> > > Awesome, let me know how it goes.  I've got the 9310 branch
> > > running
> > > 5.10.2 with no issues (16 days uptime) so I wouldn't expect you to
> > > see
> > > anything super new there, good luck :D.
> > > 
> > > ps - Happy new year
> > > 
> > 
> > Hi Kalle and Wi,
> > 
> > I've upgraded my 9310 BIOS to the same 1.1.4 since it's available:
> > 
> > [    0.000000] DMI: Dell Inc. XPS 13 9310/0F7M4C, BIOS 1.1.4
> > 11/23/2020
> > 
> > But it's still getting a single MSI vector:
> > 
> > [    3.143712] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support
> > is
> > experimental!
> > [    3.143794] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
> > 0x8c300000-
> > 0x8c3fffff 64bit]
> > [    3.143811] ath11k_pci 0000:56:00.0: enabling device (0000 ->
> > 0002)
> > [    3.143885] ath11k_pci 0000:56:00.0: MSI vectors: 1
> > [    3.755747] ath11k_pci 0000:56:00.0: qmi req mem_seg[0]
> > 0x57400000
> > 3522560 1
> > [    3.755748] ath11k_pci 0000:56:00.0: qmi req mem_seg[1]
> > 0x54d00000
> > 884736 4
> > [    3.764110] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
> > board_id 0xff soc_id 0xffffffff
> > [    3.764111] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> > fw_build_timestamp 2020-06-24 19:50 fw_build_id 
> > [    3.933936] ath11k_pci 0000:56:00.0 wlp86s0: renamed from wlan0
> > 
> > Does it mean that the single MSI issue is not from the BIOS? 
> 
> Do you have vt-d enabled in BIOS? IIRC that's needed for 32 vectors.
> 

Yes, it was enabled in BIOS, but it wasn't enabled at boot due to the
BIOS bug:
DMAR: [Firmware Bug]: Your BIOS is broken; DMAR reported at address 0!

I went ahead to upgrade the BIOS to 1.2.5. The DMAR error is now gone
and I can get 32 MSI vectors for the first time!

[    3.971218] ath11k_pci 0000:72:00.0: WARNING: ath11k PCI support is
experimental!
[    3.971285] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-
0xa25fffff 64bit]
[    3.971302] ath11k_pci 0000:72:00.0: enabling device (0000 -> 0002)
[    3.971452] ath11k_pci 0000:72:00.0: MSI vectors: 32
[    4.609593] ath11k_pci 0000:72:00.0: qmi req mem_seg[0] 0x53c00000
3522560 1
[    4.609595] ath11k_pci 0000:72:00.0: qmi req mem_seg[1] 0x54100000
884736 4
[    4.616396] ath11k_pci 0000:72:00.0: chip_id 0x0 chip_family 0xb
board_id 0xff soc_id 0xffffffff
[    4.616398] ath11k_pci 0000:72:00.0: fw_version 0x101c06cc
fw_build_timestamp 2020-06-24 19:50 fw_build_id 
[    4.793650] ath11k_pci 0000:72:00.0 wlp114s0: renamed from wlan0

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Justin Mazzola Paluska]

On 1/13/21 1:29 PM, Luo, Sining wrote:
> Yes, it was enabled in BIOS, but it wasn't enabled at boot due to the
> BIOS bug:
> DMAR: [Firmware Bug]: Your BIOS is broken; DMAR reported at address 0!
>
> I went ahead to upgrade the BIOS to 1.2.5. The DMAR error is now gone
> and I can get 32 MSI vectors for the first time!
>
> [    3.971218] ath11k_pci 0000:72:00.0: WARNING: ath11k PCI support is
> experimental!
> [    3.971285] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-
> 0xa25fffff 64bit]
> [    3.971302] ath11k_pci 0000:72:00.0: enabling device (0000 -> 0002)
> [    3.971452] ath11k_pci 0000:72:00.0: MSI vectors: 32
> [    4.609593] ath11k_pci 0000:72:00.0: qmi req mem_seg[0] 0x53c00000
> 3522560 1
> [    4.609595] ath11k_pci 0000:72:00.0: qmi req mem_seg[1] 0x54100000
> 884736 4
> [    4.616396] ath11k_pci 0000:72:00.0: chip_id 0x0 chip_family 0xb
> board_id 0xff soc_id 0xffffffff
> [    4.616398] ath11k_pci 0000:72:00.0: fw_version 0x101c06cc
> fw_build_timestamp 2020-06-24 19:50 fw_build_id
> [    4.793650] ath11k_pci 0000:72:00.0 wlp114s0: renamed from wlan0
>


For what it's worth, I upgraded my Dell XPS 13 9310 to BIOS 1.2.5 and 
can also report that the DMAR error is gone and I also get 32 MSI vectors.

$ sudo dmesg | grep -e ath11k\\\|mhi
[   17.317099] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is 
experimental!
[   17.317153] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem 
0x8c300000-0x8c3fffff 64bit]
[   17.317170] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
[   17.317336] ath11k_pci 0000:56:00.0: MSI vectors: 32
[   17.375022] mhi 0000:56:00.0: Requested to power ON
[   17.375181] mhi 0000:56:00.0: Power on setup success
[   17.945671] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x33000000 
3522560 1
[   17.945675] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x33500000 
884736 4
[   17.953054] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb 
board_id 0xff soc_id 0xffffffff
[   17.953056] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc 
fw_build_timestamp 2020-06-24 19:50 fw_build_id
[   18.127165] ath11k_pci 0000:56:00.0 wlp86s0: renamed from wlan0

I'm still using the ath11k-qca6390-bringup-202012140938 branch.  I'm 
happy to try out new patches, particularly ones related to power 
management.  The laptop doesn't get into states lower than pc6 while the 
wireless card is running.  If I shut down the card, the laptop will 
opportunistically get down into the pc10 state, which leads to massive 
power savings.
      --Justin

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

Justin Mazzola Paluska <jmp@justinmp.com> writes:

> On 1/13/21 1:29 PM, Luo, Sining wrote:
>> Yes, it was enabled in BIOS, but it wasn't enabled at boot due to the
>> BIOS bug:
>> DMAR: [Firmware Bug]: Your BIOS is broken; DMAR reported at address 0!
>>
>> I went ahead to upgrade the BIOS to 1.2.5. The DMAR error is now gone
>> and I can get 32 MSI vectors for the first time!
>>
>> [    3.971218] ath11k_pci 0000:72:00.0: WARNING: ath11k PCI support is
>> experimental!
>> [    3.971285] ath11k_pci 0000:72:00.0: BAR 0: assigned [mem 0xa2500000-
>> 0xa25fffff 64bit]
>> [    3.971302] ath11k_pci 0000:72:00.0: enabling device (0000 -> 0002)
>> [    3.971452] ath11k_pci 0000:72:00.0: MSI vectors: 32
>> [    4.609593] ath11k_pci 0000:72:00.0: qmi req mem_seg[0] 0x53c00000
>> 3522560 1
>> [    4.609595] ath11k_pci 0000:72:00.0: qmi req mem_seg[1] 0x54100000
>> 884736 4
>> [    4.616396] ath11k_pci 0000:72:00.0: chip_id 0x0 chip_family 0xb
>> board_id 0xff soc_id 0xffffffff
>> [    4.616398] ath11k_pci 0000:72:00.0: fw_version 0x101c06cc
>> fw_build_timestamp 2020-06-24 19:50 fw_build_id
>> [    4.793650] ath11k_pci 0000:72:00.0 wlp114s0: renamed from wlan0
>>
>
>
> For what it's worth, I upgraded my Dell XPS 13 9310 to BIOS 1.2.5 and
> can also report that the DMAR error is gone and I also get 32 MSI
> vectors.
>
> $ sudo dmesg | grep -e ath11k\\\|mhi
> [   17.317099] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support is
> experimental!
> [   17.317153] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
> 0x8c300000-0x8c3fffff 64bit]
> [   17.317170] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
> [   17.317336] ath11k_pci 0000:56:00.0: MSI vectors: 32
> [   17.375022] mhi 0000:56:00.0: Requested to power ON
> [   17.375181] mhi 0000:56:00.0: Power on setup success
> [   17.945671] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x33000000
> 3522560 1
> [   17.945675] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x33500000
> 884736 4
> [   17.953054] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
> board_id 0xff soc_id 0xffffffff
> [   17.953056] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
> fw_build_timestamp 2020-06-24 19:50 fw_build_id
> [   18.127165] ath11k_pci 0000:56:00.0 wlp86s0: renamed from wlan0
>
> I'm still using the ath11k-qca6390-bringup-202012140938 branch.  I'm
> happy to try out new patches, particularly ones related to power
> management.  The laptop doesn't get into states lower than pc6 while
> the wireless card is running.  If I shut down the card, the laptop
> will opportunistically get down into the pc10 state, which leads to
> massive power savings.

I'm not familiar with pc states, do you have any pointers? How do you
check the states yourself?

At the moment in suspend we leave the firmware running in low power
state due to problems in MHI. The ideal state would be to power off the
firmware entirely, but that needs changes in MHI. But I suspect you are
not talking about suspend.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Justin Mazzola Paluska]

On 2/12/21 2:14 AM, Kalle Valo wrote:
> Justin Mazzola Paluska <jmp@justinmp.com> writes:
>> I'm still using the ath11k-qca6390-bringup-202012140938 branch.  I'm
>> happy to try out new patches, particularly ones related to power
>> management.  The laptop doesn't get into states lower than pc6 while
>> the wireless card is running.  If I shut down the card, the laptop
>> will opportunistically get down into the pc10 state, which leads to
>> massive power savings.
> I'm not familiar with pc states, do you have any pointers? How do you
> check the states yourself?

"c" states are power saving states for a core.  "pc" states are package 
c-states and are deeper power saving states that can only be reached 
when all cores in a package are in low-power c-states. Higher numbered 
states save more power than lower numbered states. Getting into the 
lowest-power states (pc10) allows the system to get into what Intel 
calls "S0ix" idle states that save a lot of power.

The best pointers I have for this stuff is 
https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux . It's 
written for a lay user, not a kernel developer. 
https://01.org/blogs/qwang59/2020/linux-s0ix-troubleshooting goes into 
more detail.

I generally check the states using powertop.  If you run powertop and 
tab over to the "Idle stats" tab, the left-most column has the pc states.

It's also possible to use a program from Intel called turbostat. (On 
Debian and derivatives, turbostat is in the linux-cpupower package.)  
turbostat spits out frequency and power information to stdout and is way 
better for scripting compared to powertop.

> At the moment in suspend we leave the firmware running in low power
> state due to problems in MHI. The ideal state would be to power off the
> firmware entirely, but that needs changes in MHI. But I suspect you are
> not talking about suspend.

Indeed, I'm not talking about suspend, I'm talking about when the 
computer is awake, but idle because I'm not putting much load on it.  
For example, when reading a PDF, the computer doesn't need to do much 
and can go into a very low-power state.

What's interesting about the Dell XPS 9310 is that suspend is no longer 
the good old S3 "s2ram" suspend, but rather S0ix "s2idle" suspend.  
Microsoft has been pushing s2idle kind of suspend as "Modern Standby" 
and as of Tiger Lake, Intel only allows s2idle.

You'll note that the word S0ix appears both for s2idle suspend and for 
the pc states power management stuff above.  It's because they're the 
same! It's theoretically possible for a running computer to 
opportunistically get itself into a S0ix state that's almost as low 
power as s2idle.

When I had access to a Dell XPS 9300 (Intel 10th Gen CPU & Intel WiFI), 
I ran powertop while I went about my normal usage and the 9300 would 
regularly get itself into pc10 states when I was reading a PDF and I 
wasn't actively using the network (the card was connected to my access 
point and I had connections open, but none of them were actively 
transmitting data).

The Dell XPS 9310 that's my daily driver can get into a pc6 state when 
doing a similar task, but won't go into a pc10 or s0ix state until I 
disable WiFi.
     --Justin

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Kalle Valo]

wi nk <wink@technolu.st> writes:

> On Wed, Jan 13, 2021 at 12:54 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> wi nk <wink@technolu.st> writes:
>>
>> >> I got the XPS 13 9310 now and it indeed had AX500. But it also has an
>> >> updated BIOS:
>> >>
>> >> [    0.000000] DMI: Dell Inc. XPS 13 9310/0MRT12, BIOS 1.1.4 11/23/2020
>> >>
>> >> And with that I can get 32 MSI vectors:
>> >>
>> >> [ 2.758219] ath11k_pci 0000:56:00.0: WARNING: ath11k PCI support
>> >> is experimental!
>> >> [ 2.758778] ath11k_pci 0000:56:00.0: BAR 0: assigned [mem
>> >> 0x8c300000-0x8c3fffff 64bit]
>> >> [    2.758797] ath11k_pci 0000:56:00.0: enabling device (0000 -> 0002)
>> >> [    2.759086] ath11k_pci 0000:56:00.0: MSI vectors: 32
>> >> [    3.208447] ath11k_pci 0000:56:00.0: qmi req mem_seg[0] 0x3f000000 3522560 1
>> >> [    3.208449] ath11k_pci 0000:56:00.0: qmi req mem_seg[1] 0x3f500000 884736 4
>> >> [ 3.215355] ath11k_pci 0000:56:00.0: chip_id 0x0 chip_family 0xb
>> >> board_id 0xff soc_id 0xffffffff
>> >> [ 3.215358] ath11k_pci 0000:56:00.0: fw_version 0x101c06cc
>> >> fw_build_timestamp 2020-06-24 19:50 fw_build_id
>> >
>> >   I did see the updated BIOS from a few weeks ago, but I've been a
>> > little hesitant to update since I wasn't sure what would happen or if
>> > I could downgrade.
>>
>> Makes sense, better to be careful.
>>
>> > So to confirm, the new BIOS is allowing the driver to obtain all 32
>> > msi vectors removing the need for the single MSI patching? Does the
>> > MHI / M2 behavior also change to work properly?
>>
>> I have not tested these yet as I only did a quick 10 minute test. I was
>> offline over two weeks so I have a lot of catching up to do, but will
>> get back to you in next few days on these. My plan is to also test this
>> new BIOS with the official 5.10 release from Linus (tag v5.10).
>>
>
> Awesome, let me know how it goes.  I've got the 9310 branch running
> 5.10.2 with no issues (16 days uptime) so I wouldn't expect you to see
> anything super new there, good luck :D.

Heh, "next few days" ended to be a month :) But anyway, I have been
using the laptop quite a lot during the last month. Windows seems to
update the BIOS without asking me and now I'm at "BIOS 1.2.5
12/10/2020". I reliably get 32 MSI vectors and I haven't see any of the
M2 kernel crashes.

I mostly use master branch of my ath.git tree, which contains latest
ath11k and other wireless components. It's working fine for me and I
haven't had crashes or anything like, but there seems to some issues
with roaming which I need to debug.

I also briefly tested tag ath11k-qca6390-bringup-202012140938 and was
able to force use of 1 MSI vectors by disabling VT-d from the BIOS.
Everything was still working fine, but after I reverted the M2
workaround kernel started crashing and I was not able to even log in to
the system. This is very good as now I have a way to test the M2 problem
even with latest BIOS.

Unfortunately 1 MSI vector support didn't make it to v5.12 as it was
crashing for me[1], even with just 32 MSI vectors, and it has to wait
v5.13.

[1] https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Stelian Pop]

Hi Kalle,

On Mon, Feb 22, 2021 at 06:10:08PM +0200, Kalle Valo wrote:
> 
> Heh, "next few days" ended to be a month :) But anyway, I have been
> using the laptop quite a lot during the last month. Windows seems to
> update the BIOS without asking me and now I'm at "BIOS 1.2.5
> 12/10/2020". I reliably get 32 MSI vectors and I haven't see any of the
> M2 kernel crashes.
[...]

FYI, I have the same hardware, but with the BIOS updated to v2.0.0.

No issues whatsoever with ath11k on either the ath11k-qca6390-bringup-202012140938
branch or plain v5.11.0 kernel.

But, and it's a big but, suspend is really broken: I cannot enter S0ix, and
sometimes I found the laptop completly frozen in the morning (maybe it did
finally enter s2idle and has trouble exiting ?).

I don't know if this is related to the ath11k driver, some other driver or
the new BIOS version.

There are probably multiple issues, the first of which is the one Justin
reported (unable to go to sleep when ath11k is loaded). I suggest you
look into this BEFORE updating the BIOS...

I have a bug on kernel bugzilla wrt to the S0ix issue:
https://bugzilla.kernel.org/show_bug.cgi?id=211879

Stelian.
-- 
Stelian Pop <stelian@popies.net>

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Justin Mazzola Paluska]

On 2/24/21 4:14 AM, Stelian Pop wrote:
> There are probably multiple issues, the first of which is the one Justin
> reported (unable to go to sleep when ath11k is loaded). I suggest you
> look into this BEFORE updating the BIOS...

To be clear, s2idle works (and I do get into S0ix states when doing 
s2idle suspend) for me with the pre-2.0.0 BIOS.

What doesn't work is opportunistic S0ix states (where the machine goes 
into very low power states when not suspended).
     --Justin

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Stelian Pop]

[Sorry for the previous HTML mail...]

Hi Justin,

On Wed, Feb 24, 2021 at 04:33:03PM -0500, Justin Mazzola Paluska wrote:
> On 2/24/21 4:14 AM, Stelian Pop wrote:
> > There are probably multiple issues, the first of which is the one Justin
> > reported (unable to go to sleep when ath11k is loaded). I suggest you
> > look into this BEFORE updating the BIOS...
> 
> To be clear, s2idle works (and I do get into S0ix states when doing s2idle
> suspend) for me with the pre-2.0.0 BIOS.

As you said previously, entering S0ix only works if you 'rfkill block all'
first before going into s2idle suspend. That was the issue I was referring
to.

Stelian.
-- 
Stelian Pop <stelian@popies.net>

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Justin Mazzola Paluska]

On 2/24/21 5:02 PM, Stelian Pop wrote:
> [Sorry for the previous HTML mail...]
>
> Hi Justin,
>
> On Wed, Feb 24, 2021 at 04:33:03PM -0500, Justin Mazzola Paluska wrote:
>> On 2/24/21 4:14 AM, Stelian Pop wrote:
>>> There are probably multiple issues, the first of which is the one Justin
>>> reported (unable to go to sleep when ath11k is loaded). I suggest you
>>> look into this BEFORE updating the BIOS...
>> To be clear, s2idle works (and I do get into S0ix states when doing s2idle
>> suspend) for me with the pre-2.0.0 BIOS.
> As you said previously, entering S0ix only works if you 'rfkill block all'
> first before going into s2idle suspend. That was the issue I was referring
> to.

No, the behavior I see on a pre-2.0.0 BIOS is:

s2idle suspend works well (including getting into S0ix states) with no 
effort on my part.  I have no idea if s2idle does rfkill by itself, but 
all I do is shut the lid and the right thing happens.

Opportunistic S0ix (when the laptop is fully powered up and in use) only 
happens if I use rfkill to shut down WiFi and Bluetooth.  If either WiFi 
or Bluetooth are on, the laptop stays in power states well above the 
lowest-power SOix states.

It sounds like the 2.0.0 BIOS prevents whatever s2idle is doing from 
working without an rfkill.
     --Justin

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Stelian Pop]

Hi Justin,

On Wed, Feb 24, 2021 at 05:38:12PM -0500, Justin Mazzola Paluska wrote:

> No, the behavior I see on a pre-2.0.0 BIOS is:
> 
> s2idle suspend works well (including getting into S0ix states) with no
> effort on my part.  I have no idea if s2idle does rfkill by itself, but all
> I do is shut the lid and the right thing happens.
> 
> Opportunistic S0ix (when the laptop is fully powered up and in use) only
> happens if I use rfkill to shut down WiFi and Bluetooth.  If either WiFi or
> Bluetooth are on, the laptop stays in power states well above the
> lowest-power SOix states.

Thanks for the clarification !

> It sounds like the 2.0.0 BIOS prevents whatever s2idle is doing from working
> without an rfkill.

Nope, rfkill or not, the 2.0.0 BIOS prevents s2idle (and opportunistic S0ix)
reach low power S0ix states. s2idle still kinda works (kernel says it enters
and exists s2idle suspend), but system remains in PC3 state instead of going
to PC10 and beyond.!

Stelian.
-- 
Stelian Pop <stelian@popies.net>

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Wren Turkal]

On 2/24/21 2:38 PM, Justin Mazzola Paluska wrote:
> No, the behavior I see on a pre-2.0.0 BIOS is:
> 
> s2idle suspend works well (including getting into S0ix states) with no 
> effort on my part.  I have no idea if s2idle does rfkill by itself, but 
> all I do is shut the lid and the right thing happens.
> 
> Opportunistic S0ix (when the laptop is fully powered up and in use) only 
> happens if I use rfkill to shut down WiFi and Bluetooth.  If either WiFi 
> or Bluetooth are on, the laptop stays in power states well above the 
> lowest-power SOix states.
> 
> It sounds like the 2.0.0 BIOS prevents whatever s2idle is doing from 
> working without an rfkill.

I see this behavior also. However, I am curious. Does anyone on here 
know if suspend is broken in other OSes with this firmware version?

Thanks,
wt

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Stelian Pop]

Hi Wren,

> I see this behavior also. However, I am curious. Does anyone on here know if
> suspend is broken in other OSes with this firmware version?

To be fair, I saw exactly zero other reports of this and I searched
the Internet quite a little. I was even suspecting that I was the only
person seing it, and that the problem might be somewhere in my
personal software configuration.

Might be a good idea to publish a "me too" comment on the kernel bug
entry here: https://bugzilla.kernel.org/show_bug.cgi?id=211879

Stelian.
-- 
Stelian Pop <stelian@popies.net>

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

Re: Ordering Dell XPS 13 9310 to test QCA6390

[Wren Turkal]

On 3/6/21 12:49 PM, Stelian Pop wrote:
> Might be a good idea to publish a "me too" comment on the kernel bug
> entry here: https://bugzilla.kernel.org/show_bug.cgi?id=211879

I added my comment. Can you please change the affected version to 5.12-rc1?

Thanks,
wt

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k