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 04/11] ath10k: add start_once support
Date: Fri, 22 Dec 2017 15:25:08 +0000 [thread overview]
Message-ID: <87shc2aip8.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-5-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:06 +0200")
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> Add possibility to configure the driver to only start target once.
> This can reduce startup time of SDIO devices significantly since
> loading the firmware can take a substantial amount of time.
But it also makes it impossible to restart the firmware if it crashes,
right? Good to mention that in the commit log.
> The patch is also necessary for high latency devices in general since
> it does not seem to be possible to rerun the BMI phase (fw upload)
> without power-cycling the device.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
[...]
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -784,6 +784,8 @@ struct ath10k {
>
> bool is_high_latency;
>
> + bool is_started;
Is a separate boolean really needed? State management becomes really
difficult if an enum ath10k_state and this boolean to define the state
of the device. Can't you use ar->state?
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -569,6 +569,12 @@ struct ath10k_hw_params {
> bool is_high_latency;
>
> enum ath10k_bus bus;
> +
> + /* Specifies whether or not the device should be started once.
> + * If set, the device will be started once by the early fw probe
> + * and it will not be terminated afterwards.
> + */
> + bool start_once;
> };
I would actually prefer that the bus driver (eg. usb.c) decides this and
provides it though ath10k_core_register(). It might be that some SDIO
devices have a GPIO line to reset the device etc.
The struct ath10k_bus_params I mentioned earlier might be handy also
here.
--
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 04/11] ath10k: add start_once support
Date: Fri, 22 Dec 2017 15:25:08 +0000 [thread overview]
Message-ID: <87shc2aip8.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20170917194013.8658-5-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Sun, 17 Sep 2017 21:40:06 +0200")
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> Add possibility to configure the driver to only start target once.
> This can reduce startup time of SDIO devices significantly since
> loading the firmware can take a substantial amount of time.
But it also makes it impossible to restart the firmware if it crashes,
right? Good to mention that in the commit log.
> The patch is also necessary for high latency devices in general since
> it does not seem to be possible to rerun the BMI phase (fw upload)
> without power-cycling the device.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
[...]
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -784,6 +784,8 @@ struct ath10k {
> =20
> bool is_high_latency;
> =20
> + bool is_started;
Is a separate boolean really needed? State management becomes really
difficult if an enum ath10k_state and this boolean to define the state
of the device. Can't you use ar->state?
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -569,6 +569,12 @@ struct ath10k_hw_params {
> bool is_high_latency;
> =20
> enum ath10k_bus bus;
> +
> + /* Specifies whether or not the device should be started once.
> + * If set, the device will be started once by the early fw probe
> + * and it will not be terminated afterwards.
> + */
> + bool start_once;
> };
I would actually prefer that the bus driver (eg. usb.c) decides this and
provides it though ath10k_core_register(). It might be that some SDIO
devices have a GPIO line to reset the device etc.
The struct ath10k_bus_params I mentioned earlier might be handy also
here.
--=20
Kalle Valo=
next prev parent reply other threads:[~2017-12-22 15:25 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 [this message]
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
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=87shc2aip8.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.