Received-SPF: pass (google.com: domain of linux-kernel+bounces-6552-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <a1f5a86e-f1ab-04ee-d682-8c2116a6a961@quicinc.com>
Date: Wed, 20 Dec 2023 13:45:48 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v2 10/34] media: iris: add PIL functionality for video
 firmware
Content-Language: en-US
To: Konrad Dybcio <konrad.dybcio@linaro.org>, <linux-media@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <stanimir.k.varbanov@gmail.com>,
        <quic_vgarodia@quicinc.com>, <agross@kernel.org>,
        <andersson@kernel.org>, <mchehab@kernel.org>,
        <bryan.odonoghue@linaro.org>
CC: <linux-arm-msm@vger.kernel.org>, <quic_abhinavk@quicinc.com>
References: <1702899149-21321-1-git-send-email-quic_dikshita@quicinc.com>
 <1702899149-21321-11-git-send-email-quic_dikshita@quicinc.com>
 <2997fa9b-2702-437c-ac46-118808f1138a@linaro.org>
From: Dikshita Agarwal <quic_dikshita@quicinc.com>
In-Reply-To: <2997fa9b-2702-437c-ac46-118808f1138a@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit


On 12/19/2023 3:10 AM, Konrad Dybcio wrote:
> 
> 
> On 12/18/23 12:32, Dikshita Agarwal wrote:
>> Load/unload firmware in memory via mdt loader.
>> Firmware loading is part of core initialization
>> and unloading is part of core de-initialization.
>> This also changes the core states accordingly.
>>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
>> ---
> [...]
> 
>> +
>> +#include "iris_core.h"
>> +#include "iris_helpers.h"
>> +#include "iris_hfi.h"
>> +#include "iris_state.h"
>> +
>> +static int iris_core_deinit_locked(struct iris_core *core)
> I suppose you meant to call this something like _nolock, as
> you're calling it with a lock around it
> 
We are trying to coney that this particular API should be called with
locked context only.
doesn't _nolock mean other way? please correct if my understanding is wrong.
>> +{
>> +    int ret;
>> +
>> +    ret = check_core_lock(core);
>> +    if (ret)
>> +        return ret;
>> +
>> +    if (core->state == IRIS_CORE_DEINIT)
>> +        return 0;
>> +
>> +    iris_hfi_core_deinit(core);
>> +
>> +    iris_change_core_state(core, IRIS_CORE_DEINIT);
> You're casually ignoring the return value of the two
> above funcs here :/
> 
Right, since this is the tear-down sequence, we don't care of the return
value here.
>> +
>> +    return ret;
>> +}
>> +
>> +int iris_core_deinit(struct iris_core *core)
>> +{
>> +    int ret;
>> +
>> +    mutex_lock(&core->lock);
>> +    ret = iris_core_deinit_locked(core);
>> +    mutex_unlock(&core->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +int iris_core_init(struct iris_core *core)
>> +{
>> +    int ret = 0;
>> +
>> +    mutex_lock(&core->lock);
> You may be interested in scoped mutexes
> 
Will explore this.
>> +    if (core_in_valid_state(core)) {
>> +        goto unlock;
>> +    } else if (core->state == IRIS_CORE_ERROR) {
>> +        ret = -EINVAL;
>> +        goto unlock;
>> +    }
>> +
>> +    if (iris_change_core_state(core, IRIS_CORE_INIT_WAIT)) {
>> +        iris_change_core_state(core, IRIS_CORE_ERROR);
>> +        ret = -EINVAL;
>> +        goto unlock;
>> +    }
>> +
>> +    ret = iris_hfi_core_init(core);
>> +    if (ret) {
>> +        iris_change_core_state(core, IRIS_CORE_ERROR);
>> +        dev_err(core->dev, "%s: core init failed\n", __func__);
> __func__ still seems overly verbose in my eyes
> 
Sure, will remove such instances.
> [...]
> 
>> +
>> +int check_core_lock(struct iris_core *core)
>> +{
>> +    bool fatal = !mutex_is_locked(&core->lock);
>> +
>> +    WARN_ON(fatal);
>> +
>> +    return fatal ? -EINVAL : 0;
> You can simply inline this:
> 
> if (WARN_ON(!mutex_is_locked(&core->lock))
>     return -EINVAL;
> 
Thanks for the suggestion, will update this.
> [...]
>> +#define CP_START           0
>> +#define CP_SIZE            0x25800000
>> +#define CP_NONPIXEL_START  0x01000000
>> +#define CP_NONPIXEL_SIZE   0x24800000
>> +
>> +#define FW_NAME "vpu30_4v.mbn"
> This doesn't scale, at all.
> 
As mentioned in previous patches, we have not introduced platform specific
file yet, when I introduce that in later patch, this will be moved to
platform specific file.
> Konrad