All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <quic_jhugo@quicinc.com>
To: Qiang Yu <quic_qianyu@quicinc.com>, <mani@kernel.org>
Cc: <mhi@lists.linux.dev>, <linux-arm-msm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <quic_cang@quicinc.com>,
	<quic_mrana@quicinc.com>
Subject: Re: [PATCH] mhi: host: Add tme supported image download functionality
Date: Thu, 20 Jul 2023 23:13:37 -0600	[thread overview]
Message-ID: <c8002897-c642-fcde-a7e1-da2959d40abe@quicinc.com> (raw)
In-Reply-To: <1689907189-21844-1-git-send-email-quic_qianyu@quicinc.com>

On 7/20/2023 8:39 PM, Qiang Yu wrote:
> Add tme supported image related flag which makes decision in terms of how
> FBC image based AMSS image is being downloaded with connected endpoint.
> FBC image is having 2 image combine: SBL image + AMSS image.
> 1. FBC image download using legacy image format:
> - SBL image: 512KB of FBC image is downloaded using BHI.
> - AMSS image: full FBC image is downloaded using BHIe.
> 2. FBC image download using TME supported image format:
> - SBL image: 512 KB of FBC image is downloaded using BHI.
> - AMSS image: 512 KB onward FBC image is downloaded using BHIe.
> There is no change for SBL image download. Although AMSS image start
> address is end address of SBL image while using TME supported image format.

I know what TME is, but in the context of this patch, it doesn't seem 
like relevant information.  "tme" is just a name for this mode, but it 
is not very descriptive.  Also, I suspect that this mode is not 
intrinsically related to the TME hardware on the endpoint, it just 
happens to be used on targets where TME is present.

Is there something else we can call this?

> 
> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
> Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>

This doesn't make sense.  This patch is from you, which makes you the 
author.  But Mayank's SOB is listed first, which means he is the author. 
  Those two facts conflict.

Did Mayank author this and you are just submitting it on his behalf, or 
did the two of you co-author this?

> ---
>   drivers/bus/mhi/host/boot.c | 24 +++++++++++++++++-------
>   include/linux/mhi.h         |  2 ++
>   2 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c
> index d2a19b07..563b011 100644
> --- a/drivers/bus/mhi/host/boot.c
> +++ b/drivers/bus/mhi/host/boot.c
> @@ -365,12 +365,13 @@ int mhi_alloc_bhie_table(struct mhi_controller *mhi_cntrl,
>   }
>   
>   static void mhi_firmware_copy(struct mhi_controller *mhi_cntrl,
> -			      const struct firmware *firmware,
> +			      const u8 *image_buf,
> +			      size_t img_size,
>   			      struct image_info *img_info)
>   {
> -	size_t remainder = firmware->size;
> +	size_t remainder = img_size;
>   	size_t to_cpy;
> -	const u8 *buf = firmware->data;
> +	const u8 *buf = image_buf;
>   	struct mhi_buf *mhi_buf = img_info->mhi_buf;
>   	struct bhi_vec_entry *bhi_vec = img_info->bhi_vec;
>   
> @@ -395,8 +396,9 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>   	const char *fw_name;
>   	void *buf;
>   	dma_addr_t dma_addr;
> -	size_t size;
> +	size_t size, img_size;
>   	int i, ret;
> +	const u8 *img_buf;
>   
>   	if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
>   		dev_err(dev, "Device MHI is not in valid state\n");
> @@ -478,15 +480,23 @@ void mhi_fw_load_handler(struct mhi_controller *mhi_cntrl)
>   	 * device transitioning into MHI READY state
>   	 */
>   	if (mhi_cntrl->fbc_download) {
> -		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image,
> -					   firmware->size);
> +		img_size = firmware->size;
> +		img_buf = firmware->data;
> +		dev_dbg(dev, "tme_supported_image:%s\n",
> +				(mhi_cntrl->tme_supported_image ? "True" : "False"));
> +		if (mhi_cntrl->tme_supported_image) {
> +			img_buf = firmware->data + mhi_cntrl->sbl_size;
> +			img_size = img_size - mhi_cntrl->sbl_size;
> +		}
> +
> +		ret = mhi_alloc_bhie_table(mhi_cntrl, &mhi_cntrl->fbc_image, img_size);
>   		if (ret) {
>   			release_firmware(firmware);
>   			goto error_fw_load;
>   		}
>   
>   		/* Load the firmware into BHIE vec table */
> -		mhi_firmware_copy(mhi_cntrl, firmware, mhi_cntrl->fbc_image);
> +		mhi_firmware_copy(mhi_cntrl, img_buf, img_size, mhi_cntrl->fbc_image);
>   	}
>   
>   	release_firmware(firmware);
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index f6de4b6..5f46dc9 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -306,6 +306,7 @@ struct mhi_controller_config {
>    * @reg_len: Length of the MHI MMIO region (required)
>    * @fbc_image: Points to firmware image buffer
>    * @rddm_image: Points to RAM dump buffer
> + * @tme_supported_image: Flag to make decision about firmware download start address (optional)
>    * @mhi_chan: Points to the channel configuration table
>    * @lpm_chans: List of channels that require LPM notifications
>    * @irq: base irq # to request (required)
> @@ -391,6 +392,7 @@ struct mhi_controller {
>   	size_t reg_len;
>   	struct image_info *fbc_image;
>   	struct image_info *rddm_image;
> +	bool tme_supported_image;

A bool in the middle of several pointers?  Surely that makes the pahole 
output rather sad?  A lot of work went into the organization of this 
structure.

>   	struct mhi_chan *mhi_chan;
>   	struct list_head lpm_chans;
>   	int *irq;


  reply	other threads:[~2023-07-21  5:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21  2:39 [PATCH] mhi: host: Add tme supported image download functionality Qiang Yu
2023-07-21  5:13 ` Jeffrey Hugo [this message]
2023-07-24  7:42   ` Qiang Yu
2023-08-02 15:47     ` Jeffrey Hugo
2023-08-03  4:13       ` Qiang Yu

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=c8002897-c642-fcde-a7e1-da2959d40abe@quicinc.com \
    --to=quic_jhugo@quicinc.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=quic_cang@quicinc.com \
    --cc=quic_mrana@quicinc.com \
    --cc=quic_qianyu@quicinc.com \
    /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.