linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rakesh Pillai" <pillair@codeaurora.org>
To: "'Kalle Valo'" <kvalo@codeaurora.org>
Cc: <ath10k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] ath10k: Use bdf calibration variant for snoc targets
Date: Fri, 4 Sep 2020 16:40:44 +0000	[thread overview]
Message-ID: <0101017459fde1e4-001edcbb-cfa8-42f9-9865-2913f410e67c-000000@us-west-2.amazonses.com> (raw)
In-Reply-To: <87y2ls4lbf.fsf@codeaurora.org>

Hi Kalle,


> -----Original Message-----
> From: Kalle Valo <kvalo@codeaurora.org>
> Sent: Wednesday, September 2, 2020 2:17 PM
> To: Rakesh Pillai <pillair@codeaurora.org>
> Cc: ath10k@lists.infradead.org; linux-wireless@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] ath10k: Use bdf calibration variant for snoc targets
> 
> Rakesh Pillai <pillair@codeaurora.org> writes:
> 
> > Board Data File (BDF) is loaded upon driver boot-up procedure.
> > The right board data file is identified using bus and qmi-board-id.
> >
> > The problem, however, can occur when the (default) board data
> > file cannot fulfill with the vendor requirements and it is
> > necessary to use a different board data file.
> >
> > Add the support to get the variant field from DTSI and
> > use tht information to load the vendor specific BDF.
> >
> > The device tree requires addition strings to define the variant name
> >
> >     wifi@a000000 {
> >             status = "okay";
> >             qcom,ath10k-calibration-variant = "xyz-v2";
> >     };
> >
> >     wifi@a800000 {
> >             status = "okay";
> >             qcom,ath10k-calibration-variant = "xyz-v1";
> >     };
> >
> > This would create the boarddata identifiers for the board-2.bin search
> >
> >  *  bus=snoc,qmi-board-id=16,qmi-chip-id=0,variant=xyz-v1
> >  *  bus=snoc,qmi-board-id=17,qmi-chip-id=0,variant=xyz-v2
> 
> You mention nothing about qmi-chip-id in the commit log. Please document
> what it is and also give some examples what kind of values there can be.


Let me add a bit more details about the chip-id and send v2 for this change.


> 
> > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > @@ -576,6 +576,8 @@ static int ath10k_qmi_cap_send_sync_msg(struct
> ath10k_qmi *qmi)
> >  	if (resp->chip_info_valid) {
> >  		qmi->chip_info.chip_id = resp->chip_info.chip_id;
> >  		qmi->chip_info.chip_family = resp->chip_info.chip_family;
> > +	} else {
> > +		qmi->chip_info.chip_id = 0xFF;
> >  	}
> 
> So you hard code chip_id to 0xff if it's not valid. Is it 100%
> guaranteed that there never will be a chip id with 0xff?

0x0 and 0xff are invalid chip id and are are not used.
If the chip_id read fails, we fallback to the default board data.
0xff is used to go to the default board data (Also this is in alignment with
the current implementation of board_id)

Does that make sense ?


> 
> >
> >  	if (resp->board_info_valid)
> > @@ -817,12 +819,18 @@ static void
> ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> >  static int ath10k_qmi_fetch_board_file(struct ath10k_qmi *qmi)
> >  {
> >  	struct ath10k *ar = qmi->ar;
> > +	int ret;
> >
> >  	ar->hif.bus = ATH10K_BUS_SNOC;
> >  	ar->id.qmi_ids_valid = true;
> >  	ar->id.qmi_board_id = qmi->board_info.board_id;
> > +	ar->id.qmi_chip_id = qmi->chip_info.chip_id;
> 
> To me a safer, and cleaner, option would be to have
> ar->id.qmi_chip_id_valid, and only add qmi-chip-id=%x to the board id if
> qmi_chip_id_valid is true. That way there's not this magic 0xff value
> hardcoded anywhere.
> 
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches


  reply	other threads:[~2020-09-04 16:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26 17:53 [PATCH] ath10k: Use bdf calibration variant for snoc targets Rakesh Pillai
2020-09-02  8:47 ` Kalle Valo
2020-09-04 16:40   ` Rakesh Pillai [this message]
     [not found]   ` <0101017459fdd62b-791355e4-ea88-4142-96a7-06849bcd7b09-000000@us-west-2.amazonses.com>
2020-09-07 16:17     ` Kalle Valo
     [not found]     ` <87k0x51rz3.fsf@codeaurora.org>
2020-09-10 13:11       ` Rakesh Pillai

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=0101017459fde1e4-001edcbb-cfa8-42f9-9865-2913f410e67c-000000@us-west-2.amazonses.com \
    --to=pillair@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).