All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC v3 07/11] ath10k: various fixes for high latency devices
Date: Fri, 22 Dec 2017 15:43:55 +0000	[thread overview]
Message-ID: <87fu82ahtw.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-8-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:09 +0200")

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> Several DMA related functions (such as the dma_map_xxx functions)
> are not used with high latency devices and don't need to be invoked
> in this case.
>
> A few other execution paths are not applicable for high latency
> devices and can be skipped.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>

This and patch 6 are somehow connected but the division is not clear. I
think at least dma map/unmap changes should be split into their own
patch. 

I recommend revisiting both patches 6 and 7. The htt layer can be quite
tricky so better to have smaller logical changes to make it easier
review them.

> --- a/drivers/net/wireless/ath/ath10k/htt_tx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
> @@ -409,6 +409,9 @@ int ath10k_htt_tx_start(struct ath10k_htt *htt)
>  	if (htt->tx_mem_allocated)
>  		return 0;
>  
> +	if (ar->is_high_latency)
> +		return 0;
> +
>  	ret = ath10k_htt_tx_alloc_buf(htt);
>  	if (ret)
>  		goto free_idr_pending_tx;
> @@ -445,7 +448,8 @@ void ath10k_htt_tx_destroy(struct ath10k_htt *htt)
>  		return;
>  
>  	ath10k_htt_tx_free_cont_txbuf(htt);
> -	ath10k_htt_tx_free_txq(htt);
> +	if (!htt->ar->is_high_latency)
> +		ath10k_htt_tx_free_txq(htt);
>  	ath10k_htt_tx_free_cont_frag_desc(htt);
>  	ath10k_htt_tx_free_txdone_fifo(htt);
>  	htt->tx_mem_allocated = false;

These two don't look symmetric. You prevent calling these functions:

ath10k_htt_tx_alloc_cont_txbuf(htt);
ath10k_htt_tx_alloc_cont_frag_desc(htt);
ath10k_htt_tx_alloc_txq(htt);
ath10k_htt_tx_alloc_txdone_fifo(htt);

But during destroy you only prevent calling ath10k_htt_tx_free_txq(htt)
and allow these functions:

ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
ath10k_htt_tx_free_txdone_fifo(htt);

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC v3 07/11] ath10k: various fixes for high latency devices
Date: Fri, 22 Dec 2017 15:43:55 +0000	[thread overview]
Message-ID: <87fu82ahtw.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-8-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:09 +0200")

Erik Stromdahl <erik.stromdahl@gmail.com> writes:

> Several DMA related functions (such as the dma_map_xxx functions)
> are not used with high latency devices and don't need to be invoked
> in this case.
>
> A few other execution paths are not applicable for high latency
> devices and can be skipped.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>

This and patch 6 are somehow connected but the division is not clear. I
think at least dma map/unmap changes should be split into their own
patch.=20

I recommend revisiting both patches 6 and 7. The htt layer can be quite
tricky so better to have smaller logical changes to make it easier
review them.

> --- a/drivers/net/wireless/ath/ath10k/htt_tx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
> @@ -409,6 +409,9 @@ int ath10k_htt_tx_start(struct ath10k_htt *htt)
>  	if (htt->tx_mem_allocated)
>  		return 0;
> =20
> +	if (ar->is_high_latency)
> +		return 0;
> +
>  	ret =3D ath10k_htt_tx_alloc_buf(htt);
>  	if (ret)
>  		goto free_idr_pending_tx;
> @@ -445,7 +448,8 @@ void ath10k_htt_tx_destroy(struct ath10k_htt *htt)
>  		return;
> =20
>  	ath10k_htt_tx_free_cont_txbuf(htt);
> -	ath10k_htt_tx_free_txq(htt);
> +	if (!htt->ar->is_high_latency)
> +		ath10k_htt_tx_free_txq(htt);
>  	ath10k_htt_tx_free_cont_frag_desc(htt);
>  	ath10k_htt_tx_free_txdone_fifo(htt);
>  	htt->tx_mem_allocated =3D false;

These two don't look symmetric. You prevent calling these functions:

ath10k_htt_tx_alloc_cont_txbuf(htt);
ath10k_htt_tx_alloc_cont_frag_desc(htt);
ath10k_htt_tx_alloc_txq(htt);
ath10k_htt_tx_alloc_txdone_fifo(htt);

But during destroy you only prevent calling ath10k_htt_tx_free_txq(htt)
and allow these functions:

ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
ath10k_htt_tx_free_txdone_fifo(htt);

--=20
Kalle Valo=

  reply	other threads:[~2017-12-22 15:44 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-17 19:40 [RFC v3 00/11] ath10k high latency Erik Stromdahl
2017-09-17 19:40 ` Erik Stromdahl
2017-09-17 19:40 ` [RFC v3 01/11] ath10k: high_latency detection Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:06   ` Kalle Valo
2017-12-22 15:06     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 02/11] ath10k: htt: RX ring config HL support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-09-17 19:40 ` [RFC v3 03/11] ath10k: per target configurablity of various items Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:19   ` Kalle Valo
2017-12-22 15:19     ` Kalle Valo
2017-12-28 12:43     ` Erik Stromdahl
2017-12-28 12:43       ` Erik Stromdahl
2018-01-08 13:41       ` Kalle Valo
2018-01-08 13:41         ` Kalle Valo
2018-01-08 14:03         ` Govind Singh
2018-01-08 14:03           ` Govind Singh
2017-09-17 19:40 ` [RFC v3 04/11] ath10k: add start_once support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:25   ` Kalle Valo
2017-12-22 15:25     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 05/11] ath10k: htt: High latency TX support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:26   ` Kalle Valo
2017-12-22 15:26     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 06/11] ath10k: htt: High latency RX support Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:32   ` Kalle Valo
2017-12-22 15:32     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 07/11] ath10k: various fixes for high latency devices Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:43   ` Kalle Valo [this message]
2017-12-22 15:43     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 08/11] ath10k: add QCA9377 usb hw_param item Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:46   ` Kalle Valo
2017-12-22 15:46     ` Kalle Valo
2017-12-22 15:49   ` Kalle Valo
2017-12-22 15:49     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 09/11] ath10k: add QCA9377 sdio " Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:47   ` Kalle Valo
2017-12-22 15:47     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 10/11] ath10k: wmi: disable softirq's while calling ieee80211_rx Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:47   ` Kalle Valo
2017-12-22 15:47     ` Kalle Valo
2017-09-17 19:40 ` [RFC v3 11/11] ath10k: remove htt pending TX count for high latency Erik Stromdahl
2017-09-17 19:40   ` Erik Stromdahl
2017-12-22 15:55 ` [RFC v3 00/11] ath10k " Kalle Valo
2017-12-22 15:55   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fu82ahtw.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=erik.stromdahl@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.