devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Anilkumar Kolli <akolli@codeaurora.org>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v2 2/2] ath11k: Use reserved host DDR addresses from DT for PCI devices
Date: Fri, 19 Nov 2021 15:08:17 +0200	[thread overview]
Message-ID: <878rxkcmym.fsf@codeaurora.org> (raw)
In-Reply-To: <b1617fc74da2d65d663a82e4a4f538e2@codeaurora.org> (Anilkumar Kolli's message of "Thu, 18 Nov 2021 16:05:21 +0530")

Anilkumar Kolli <akolli@codeaurora.org> writes:

> On 2021-11-17 13:35, Kalle Valo wrote:
>> Anilkumar Kolli <akolli@codeaurora.org> writes:
>>
>>> Host DDR memory (contiguous 45 MB in mode-0 or 15 MB in mode-2)
>>> is reserved through DT entries for firmware usage. Send the base
>>> address and size from DT entries.
>>>
>>> If DT entry is available, PCI devices work with
>>> fixed_mem_region else host allocates multiple segments.
>>>
>>> IPQ8074 on HK10 board supports multiple PCI devices.
>>> IPQ8074 + QCN9074 is tested with this patch.
>>>
>>> Tested-on: QCN9074 hw1.0 PCI
>>> WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1
>>>
>>> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>

[...]

>>> +		goto no_dt_entry;
>>> +	}
>>> +
>>> +	reg_end = reg + len / (aw * sw);
>>> +
>>> +	do {
>>> +		start = of_read_number(reg, aw);
>>> +		reg += aw;
>>> +		size = of_read_number(reg, sw);
>>
>> of_read_number() takes 'const __be32 *cell' but reg is 'u32 *'?
>>
> Yes.

My point here was that doesn't this mixing of __be32 and u32 when cause
a sparse warning?

>
>>> +		reg += sw;
>>> +	} while (reg < reg_end);
>>> +
>>> +no_dt_entry:
>>> +	if (no_dt_entry) {
>>> +		mhi_ctrl->iova_start = 0;
>>> +		mhi_ctrl->iova_stop = 0xFFFFFFFF;
>>> +	} else {
>>> +		mhi_ctrl->iova_start = (dma_addr_t)(start + 0x1000000);
>>> +		mhi_ctrl->iova_stop = (dma_addr_t)(start + size);
>>
>> I don't like casts, they hide bugs like the const issue above. Is there
>> any way to do this without casts?
>>
>
> u64 start, size;
>
>     if (of_property_read_u32_array(np, "reg", reg, 4)) {
>          ath11k_dbg(ab, ATH11K_DBG_QMI,
>                     "qmi fail to get reg from hremote\n");
>          return 0;
>     }
>     start = reg[0] + reg[1];
>     size = reg[2] + reg[3];
>
> I will this code in next patch. still needs typecast form u64 to
> dma_addr_t. no ?

I suspect that a cast is not needed, but not sure. No time to check either.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2021-11-19 13:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 17:00 [PATCH v2 1/2] dt: bindings: add new DT entry for ath11k PCI device support Anilkumar Kolli
2021-11-16 17:00 ` [PATCH v2 2/2] ath11k: Use reserved host DDR addresses from DT for PCI devices Anilkumar Kolli
2021-11-17  8:05   ` Kalle Valo
2021-11-18 10:35     ` Anilkumar Kolli
2021-11-19 13:08       ` Kalle Valo [this message]
2021-11-19 13:51   ` Sven Eckelmann
2021-11-17  2:27 ` [PATCH v2 1/2] dt: bindings: add new DT entry for ath11k PCI device support Rob Herring

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=878rxkcmym.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=akolli@codeaurora.org \
    --cc=ath11k@lists.infradead.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=robh@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).