On 1/16/23 01:53, Mukunda,Vijendar wrote:
> On 14/01/23 00:11, Pierre-Louis Bossart wrote:
>>>>> + for (index = 0; index < 2; index++) {
>>>>> + if (response_buf[index] == -ETIMEDOUT) {
>>>>> + dev_err(ctrl->dev, "Program SCP cmd timeout\n");
>>>>> + timeout = 1;
>>>>> + } else if (!(response_buf[index] & AMD_SDW_MCP_RESP_ACK)) {
>>>>> + no_ack = 1;
>>>>> + if (response_buf[index] & AMD_SDW_MCP_RESP_NACK) {
>>>>> + nack = 1;
>>>>> + dev_err(ctrl->dev, "Program SCP NACK received\n");
>>>>> + }
>>>> this is a copy of the cadence_master.c code... With the error added that
>>>> this is not for a controller but for a master...
>>> Its manager instance only. Our immediate command and response
>>> mechanism allows sending commands over the link and get the
>>> response for every command immediately, unlike as mentioned in
>>> candence_master.c.
>> I don't get the reply. The Cadence IP also has the ability to get the
>> response immediately. There's limited scope for creativity, the commands
>> are defined in the spec and the responses as well.
> As per our understanding in Intel code, responses are processed
> after sending all commands.
> In our case, we send the command and process the response
> immediately before invoking the next command.
The Cadence IP can queue a number of commands, I think 8 off the top of
my head. But the response is provided immediately after each command.
Maybe the disconnect is that there's an ability to define a watermark on
the response buffer, so that the software can decide to process the
command responses in one shot.
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + if (timeout) {
>>>>> + dev_err_ratelimited(ctrl->dev,
>>>>> + "SCP_addrpage command timeout for Slave %d\n", msg->dev_num);
>>>>> + return SDW_CMD_TIMEOUT;
>>>>> + }
>>>>> +
>>>>> + if (nack) {
>>>>> + dev_err_ratelimited(ctrl->dev,
>>>>> + "SCP_addrpage NACKed for Slave %d\n", msg->dev_num);
>>>>> + return SDW_CMD_FAIL;
>>>>> + }
>>>>> +
>>>>> + if (no_ack) {
>>>>> + dev_dbg_ratelimited(ctrl->dev,
>>>>> + "SCP_addrpage ignored for Slave %d\n", msg->dev_num);
>>>>> + return SDW_CMD_IGNORED;
>>>>> + }
>>>>> + return SDW_CMD_OK;
>>>> this should probably become a helper since the response is really the
>>>> same as in cadence_master.c
>>>>
>>>> There's really room for optimization and reuse here.
>>> not really needed. Please refer above comment as command/response
>>> mechanism differs from Intel's implementation.
>> how? there's a buffer of responses in both cases. please clarify.
> Ours implementation is not interrupt driven like Intel.
> When we send command over the link, we will wait for command's
> response in polling method and process the response immediately
> before issuing the new command.
On the Intel side we use an interrupt to avoid polling, and in case of N
commands the watermark will be set to N to reduce the overhead. That
said, most users only use 1 command at a time, it's only recently that
Cirrus Logic experimented with multiple commands to speed-up transfers.
Even if there are differences in the way the responses are processed,
whether one-at-a-time or in a batch, the point remains that each command
response can be individually analyzed and that could be using a helper -
moving code from cadence_master.c into the bus layer.
