[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <980d4a8f-2ea8-4138-8885-5ace5d87e0d2@quicinc.com>
Date: Fri, 13 Dec 2024 09:59:03 +0530
From: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
<ath12k@...ts.infradead.org>
CC: <linux-wireless@...r.kernel.org>, Kalle Valo <kvalo@...nel.org>,
"Rob
Herring" <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
"Conor
Dooley" <conor+dt@...nel.org>,
Jeff Johnson <jjohnson@...nel.org>,
"Bjorn
Andersson" <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 15/22] wifi: ath12k: add BDF address in hardware
parameter
On 12/13/2024 5:48 AM, Konrad Dybcio wrote:
> On 9.12.2024 5:23 AM, Raj Kumar Bhagat wrote:
>> On 12/6/2024 4:19 PM, Konrad Dybcio wrote:
>>> On 6.12.2024 5:34 AM, Raj Kumar Bhagat wrote:
>>>> On 12/5/2024 11:12 PM, Konrad Dybcio wrote:
>>>>> On 3.12.2024 10:18 AM, Raj Kumar Bhagat wrote:
>>>>>> On 11/4/2024 7:46 PM, Konrad Dybcio wrote:
>>>>>>> On 15.10.2024 8:26 PM, Raj Kumar Bhagat wrote:
>>>>>>>> The Ath2k AHB device (IPQ5332) firmware requests BDF_MEM_REGION_TYPE
>>>>>>>> memory during QMI memory requests. This memory is part of the
>>>>>>>> HOST_DDR_REGION_TYPE. Therefore, add the BDF memory address to the
>>>>>>>> hardware parameter and provide this memory address to the firmware
>>>>>>>> during QMI memory requests.
>>>>>>>
>>>>>>> Sounds like something to put in the device tree, no?
>>>>>>>
>>>>>>
>>>>>> This BDF memory address is the RAM offset. We did add this in device tree in
>>>>>> version 1. This is removed from device tree in v2 based on the review comment that
>>>>>> DT should not store RAM offset.
>>>>>>
>>>>>> refer below link:
>>>>>> Link: https://lore.kernel.org/all/f8cd9c3d-47e1-4709-9334-78e4790acef0@kernel.org/
>>>>>
>>>>> Right, I think this could be something under /reserved-memory instead
>>>>>
>>>>
>>>> Thanks for the suggestion. However, the BDF_MEM_REGION_TYPE is already within the
>>>> memory reserved for HOST_DDR_REGION_TYPE through /reserved-memory. Therefore, reserving
>>>> the memory for BDF_MEM_REGION_TYPE again in the Device Tree (DT) will cause a warning
>>>> for 'overlapping memory reservation'.
>>>
>>> Then you can grab a handle to it with of_reserved_mem_lookup()
>>> and of_reserved_mem_device_init_by_idx()
>>>
>>
>> The memory HOST_DDR_REGION_TYPE is a bigger memory around 43MB, while the memory
>> BDF_MEM_REGION_TYPE is smaller around 256KB within HOST_DDR_REGION_TYPE, Using the
>> above mentioned API we still have to store the offset in ath12k to point at memory
>> BDF_MEM_REGION_TYPE from the start of HOST_DDR_REGION_TYPE.
>
> That's still way better than hardcoding platform specifics in the common
> driver
>
Sure, I agree. I'll update in latest version to store the offset for BDF_MEM_REGION_TYPE.
Thanks!
Powered by blists - more mailing lists