[PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[Rajkumar Manoharan]

Some of of qca988x solutions are having global reset issue
during target initialization. Bypassing PLL setting before
downloading firmware and letting the SoC run on REF_CLK is fixing
the problem. Corresponding firmware change is also needed to set
the clock source once the target is initialized. Since 10.2.4
firmware is having this ROM patch, applying skip_clock_init only
for 10.2.4 firmware versions.

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 310e12b..cd20805 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -797,6 +797,16 @@ static int ath10k_download_cal_data(struct ath10k *ar)
 	ar->cal_mode = ATH10K_CAL_MODE_OTP;
 
 done:
+	if ((ar->hw_rev == ATH10K_HW_QCA988X) &&
+	    (ar->wmi.op_version == ATH10K_FW_WMI_OP_VERSION_10_2_4)) {
+		ret = ath10k_bmi_write32(ar, hi_skip_clock_init, 1);
+		if (ret) {
+			ath10k_err(ar, "could not write skip_clock_init (%d)\n",
+				   ret);
+			return ret;
+		}
+	}
+
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using calibration mode %s\n",
 		   ath10k_cal_mode_str(ar->cal_mode));
 	return 0;
-- 
2.2.2

[PATCH v2 2/2] ath10k: Increase copy engine entries for rx wmi

[Rajkumar Manoharan]

Having lower number of copy engine entries for target to host
WMI ring is causing drops in receiving management frames. This
issue is observed during max clients (128 clients) stress testing.
While bursting deauthentication frames from simulated clients,
approx. 70% of frames are getting dropped due to lower ring entries.

Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e6972b0..f3174a6 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -113,7 +113,7 @@ static const struct ce_attr host_ce_config_wlan[] = {
 		.flags = CE_ATTR_FLAGS,
 		.src_nentries = 0,
 		.src_sz_max = 2048,
-		.dest_nentries = 32,
+		.dest_nentries = 128,
 	},
 
 	/* CE3: host->target WMI */
@@ -183,7 +183,7 @@ static const struct ce_pipe_config target_ce_config_wlan[] = {
 	{
 		.pipenum = __cpu_to_le32(2),
 		.pipedir = __cpu_to_le32(PIPEDIR_IN),
-		.nentries = __cpu_to_le32(32),
+		.nentries = __cpu_to_le32(64),
 		.nbytes_max = __cpu_to_le32(2048),
 		.flags = __cpu_to_le32(CE_ATTR_FLAGS),
 		.reserved = __cpu_to_le32(0),
-- 
2.2.2

Re: [PATCH v2 2/2] ath10k: Increase copy engine entries for rx wmi

[Peter Oh]

On 02/08/2015 09:46 PM, Rajkumar Manoharan wrote:
> Having lower number of copy engine entries for target to host
> WMI ring is causing drops in receiving management frames. This
> issue is observed during max clients (128 clients) stress testing.
> While bursting deauthentication frames from simulated clients,
> approx. 70% of frames are getting dropped due to lower ring entries.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath10k/pci.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c
> b/drivers/net/wireless/ath/ath10k/pci.c
> index e6972b0..f3174a6 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -113,7 +113,7 @@ static const struct ce_attr host_ce_config_wlan[] = {
>   		.flags = CE_ATTR_FLAGS,
>   		.src_nentries = 0,
>   		.src_sz_max = 2048,
> -		.dest_nentries = 32,
> +		.dest_nentries = 128,
>   	},
>   
>   	/* CE3: host->target WMI */
> @@ -183,7 +183,7 @@ static const struct ce_pipe_config
> target_ce_config_wlan[] = {
>   	{
>   		.pipenum = __cpu_to_le32(2),
>   		.pipedir = __cpu_to_le32(PIPEDIR_IN),
> -		.nentries = __cpu_to_le32(32),
> +		.nentries = __cpu_to_le32(64),
Could you explain why the value of nentries are different?
>   		.nbytes_max = __cpu_to_le32(2048),
>   		.flags = __cpu_to_le32(CE_ATTR_FLAGS),
>   		.reserved = __cpu_to_le32(0),
Thanks,
Peter

Re: [PATCH v2 2/2] ath10k: Increase copy engine entries for rx wmi

[Rajkumar]

On Mon, Feb 09, 2015 at 02:54:00PM -0800, Peter Oh wrote:
> 
> On 02/08/2015 09:46 PM, Rajkumar Manoharan wrote:
> Could you explain why the value of nentries are different?
There are separate copy engine configuration tables for host
and target. Host-side and Target-side configurations are different
and it never be same for any CE due to memory constraints in Target.

-Rajkumar

Re: [PATCH v2 2/2] ath10k: Increase copy engine entries for rx wmi

[Kalle Valo]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> Having lower number of copy engine entries for target to host
> WMI ring is causing drops in receiving management frames. This
> issue is observed during max clients (128 clients) stress testing.
> While bursting deauthentication frames from simulated clients,
> approx. 70% of frames are getting dropped due to lower ring entries.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>

Thanks, patch 2 applied.

-- 
Kalle Valo

Re: [PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[Rajkumar]

On Mon, Feb 09, 2015 at 11:16:53AM +0530, Rajkumar Manoharan wrote:
> Some of of qca988x solutions are having global reset issue
> during target initialization. Bypassing PLL setting before
> downloading firmware and letting the SoC run on REF_CLK is fixing
> the problem. Corresponding firmware change is also needed to set
> the clock source once the target is initialized. Since 10.2.4
> firmware is having this ROM patch, applying skip_clock_init only
> for 10.2.4 firmware versions.
> 
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
Kalle,

Its been pending for a while. Shall I resend this series?

-Rajkumar

Re: [PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[Kalle Valo]

Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:

> Some of of qca988x solutions are having global reset issue
> during target initialization. Bypassing PLL setting before
> downloading firmware and letting the SoC run on REF_CLK is fixing
> the problem. Corresponding firmware change is also needed to set
> the clock source once the target is initialized. Since 10.2.4
> firmware is having this ROM patch, applying skip_clock_init only
> for 10.2.4 firmware versions.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> ---
>  drivers/net/wireless/ath/ath10k/core.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 310e12b..cd20805 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -797,6 +797,16 @@ static int ath10k_download_cal_data(struct ath10k *ar)
>  	ar->cal_mode = ATH10K_CAL_MODE_OTP;
>  
>  done:
> +	if ((ar->hw_rev == ATH10K_HW_QCA988X) &&
> +	    (ar->wmi.op_version == ATH10K_FW_WMI_OP_VERSION_10_2_4)) {
> +		ret = ath10k_bmi_write32(ar, hi_skip_clock_init, 1);
> +		if (ret) {
> +			ath10k_err(ar, "could not write skip_clock_init (%d)\n",
> +				   ret);
> +			return ret;
> +		}
> +	}

Didn't Michal mention that this should be a firmware feature flag?
Checking for firmware versions can easily get too complicated, that's
why we have tried to use feature flags for things like this.

Also I think this should not be hidden inside
ath10k_download_cal_data(). Maybe ath10k_core_start() is a better place
to do this?

I can send v3 for this patch.

-- 
Kalle Valo

Re: [PATCH v2 1/2] ath10k: Bypass PLL setting on target init for QCA9888

[Rajkumar Manoharan]

On Thu, Mar 05, 2015 at 02:41:16PM +0200, Kalle Valo wrote:
> Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> 
> > Some of of qca988x solutions are having global reset issue
> > during target initialization. Bypassing PLL setting before
> > downloading firmware and letting the SoC run on REF_CLK is fixing
> > the problem. Corresponding firmware change is also needed to set
> > the clock source once the target is initialized. Since 10.2.4
> > firmware is having this ROM patch, applying skip_clock_init only
> > for 10.2.4 firmware versions.
> >
> > Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> > index 310e12b..cd20805 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -797,6 +797,16 @@ static int ath10k_download_cal_data(struct ath10k *ar)
> >  	ar->cal_mode = ATH10K_CAL_MODE_OTP;
> >  
> >  done:
> > +	if ((ar->hw_rev == ATH10K_HW_QCA988X) &&
> > +	    (ar->wmi.op_version == ATH10K_FW_WMI_OP_VERSION_10_2_4)) {
> > +		ret = ath10k_bmi_write32(ar, hi_skip_clock_init, 1);
> > +		if (ret) {
> > +			ath10k_err(ar, "could not write skip_clock_init (%d)\n",
> > +				   ret);
> > +			return ret;
> > +		}
> > +	}
> 
> Didn't Michal mention that this should be a firmware feature flag?
> Checking for firmware versions can easily get too complicated, that's
> why we have tried to use feature flags for things like this.
>
Oops.. Sorry for the delay. I missed this mail. IIRC i replied to
Michal's question for previous version. From the existing fw_feature
flag, there is no clear way to identify 10.2.4 firmware version. Since
this patch is needed only for 10.2.4, I used op_version. Otherwise
fw_feature has to be extended for 10.2.4. Am i correct?

> Also I think this should not be hidden inside
> ath10k_download_cal_data(). Maybe ath10k_core_start() is a better place
> to do this?
>
Hmm.. agree.

> I can send v3 for this patch.
> 
Thanks for taking care of this. Please let me know if you need help.

-Rajkumar