Re: [RFC PATCH 5/5] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bjorn,

On 5/23/2018 1:07 PM, Vinod wrote:
> On 22-05-18, 23:58, Bjorn Andersson wrote:
>> On Tue 22 May 23:05 PDT 2018, Vinod wrote:
>>
>>> On 22-05-18, 22:20, Bjorn Andersson wrote:
>>>
>>>> +static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
>>>> +{
>>>> +	int ret;
>>>> +	u32 val;
>>>> +	int i;
>>>> +
>>>> +	/* Assert resets, stop core */
>>>> +	val = readl(wcss->reg_base + QDSP6SS_RESET_REG);
>>>> +	val |= Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE;
>>>> +	writel(val, wcss->reg_base + QDSP6SS_RESET_REG);
>>>> +
>>>> +	/* BHS require xo cbcr to be enabled */
>>>> +	val = readl(wcss->reg_base + QDSP6SS_XO_CBCR);
>>>> +	val |= 0x1;
>>>> +	writel(val, wcss->reg_base + QDSP6SS_XO_CBCR);
>>>
>>> As commented on previous patch, it would help IMO to add a modify() wrapper
>>> here which would perform read, modify and write.
>>>
>>
>> Iirc the code ended up like this because a lot of these operations ended
>> up being line wrapped and harder to read using some modify(reg, mask,
>> val) helper. That said, the function isn't very pretty in it's current
>> state either...
> 
> Agreed :) and i thought modify make help it make better
> 
>> One of the parts of the RFC is that this sequence is a verbatim copy
>> from the qcom_q6v5_pil.c driver for 8996, so if we find this duplication
>> suitable I would prefer that we keep them the same.
>>
>>
>> The alternative to duplicating this function is as Sricharan proposed to
>> have the qcom_q6v5_pil.c be both a driver for both the single-stage
>> remoteproc and the two-stage (load boot loader, then modem firmware).
>>
>>> Looking at the patch, few other comments would be applicable too, so would be
>>> great if you/Sricharan can update this
>>>
>>
>> I agree, the primary purpose of this patch was rather to get feedback on
>> the structure of the drivers, I do expect this to take another round
>> through the editor to get some polishing touches. Sorry if this wasn't
>> clear from the description.
> 
> Since Sricharan replied to comments, I though they would be fixed. Yeah this is
> fine from RFC..
> 

 Thanks for this.

 Tested this on ipq8074 and wcss rproc is up with this.

 Tested-by: Sricharan R <sricharan@xxxxxxxxxxxxxx>

 So regarding the cleanup, as i see, this consolidates the code much better.

 so about the point of avoiding duplication for soc specific functions like
 qcv5_wcss_reset common between qcv5_wcss and qcv5_pil drivers as done in my
 series, with a second thought that feels it might be difficult to maintain
 in the longer run. Since the sequences are specific to each soc and for now
 although some part of it is common, for a minor update in one soc, common
 code needs to reworked every time and tested on all boards that share them.

 So feels like having the duplication for hw init sequences is the cleaner way.

 Apart from that for other comments on the q6v5 wcss driver, i can address them
 on this final patch that you have posted and same can be included in your
 next version. Please let me know how you want to go about it.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux