[PATCH v4 2/8] scpi: Add alternative legacy structures, functions and macros
Sudeep Holla
sudeep.holla at arm.com
Mon Oct 17 04:16:23 PDT 2016
On 17/10/16 09:25, Neil Armstrong wrote:
> On 10/10/2016 04:36 PM, Sudeep Holla wrote:
>> Hi Neil,
>>
>> Sorry, I could not reply to your response on v3. Anyways I will review v4.
>>
>> On 05/10/16 08:33, Neil Armstrong wrote:
>>> This patch adds support for the Legacy SCPI protocol in early JUNO versions and
>>> shipped Amlogic ARMv8 based SoCs. Some Rockchip SoC are also known to use this
>>> version of protocol with extended vendor commands
>>> .
>>> In order to support the legacy SCPI protocol variant, add back the structures
>>> and macros that varies against the final specification.
>>> Then add indirection table for legacy commands.
>>> Finally Add bitmap field for channel selection since the Legacy protocol mandates to
>>> send a selected subset of the commands on the high priority channel instead of the
>>> low priority channel.
>>>
>>> The message sending path differs from the final SCPI procotocol because the
>>> Amlogic SCP firmware always reply 1 instead of a special value containing the command
>>> byte and replied rx data length.
>>> For this reason commands queuing cannot be used and we assume the reply command is
>>> the head of the rx_pending list since we ensure sequential command sending with a
>>> separate dedicated mutex.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
>>> ---
>>> drivers/firmware/arm_scpi.c | 221 +++++++++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 199 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>>> index 498afa0..6244eb1 100644
>>> --- a/drivers/firmware/arm_scpi.c
>>> +++ b/drivers/firmware/arm_scpi.c
>>
>> [...]
>>
>>> @@ -307,21 +398,46 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
>>> return;
>>> }
>>>
>>> - list_for_each_entry(t, &ch->rx_pending, node)
>>> - if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>>> - list_del(&t->node);
>>> - match = t;
>>> - break;
>>> - }
>>> + /* Command type is not replied by the SCP Firmware in legacy Mode
>>> + * We should consider that command is the head of pending RX commands
>>> + * if the list is not empty. In TX only mode, the list would be empty.
>>> + */
>>> + if (scpi_info->is_legacy) {
>>> + match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
>>> + node);
>>> + list_del(&match->node);
>>> + } else {
>>> + list_for_each_entry(t, &ch->rx_pending, node)
>>> + if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
>>> + list_del(&t->node);
>>> + match = t;
>>> + break;
>>> + }
>>> + }
>>> /* check if wait_for_completion is in progress or timed-out */
>>> if (match && !completion_done(&match->done)) {
>>> - struct scpi_shared_mem *mem = ch->rx_payload;
>>> - unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
>>> + unsigned int len;
>>> +
>>> + if (scpi_info->is_legacy) {
>>> + struct legacy_scpi_shared_mem *mem = ch->rx_payload;
>>> +
>>> + /* RX Length is not replied by the lagcy Firmware */
Typo above legacy
>>> + len = match->rx_len;
>>> +
>>> + match->status = le32_to_cpu(mem->status);
>>> + memcpy_fromio(match->rx_buf, mem->payload, len);
>>
>> The above 2 seems common to both, no ?
>
> No, the shared_mem structure differs.
>
Yes I see that, I was just referring the last 2 statements.
>>
>>> + } else {
>>> + struct scpi_shared_mem *mem = ch->rx_payload;
>>> +
>>> + len = min(match->rx_len, CMD_SIZE(cmd));
>>> +
>>> + match->status = le32_to_cpu(mem->status);
>>> + memcpy_fromio(match->rx_buf, mem->payload, len);
and the above 2 can be moved out of the conditions, no ?
if (scpi_info->is_legacy) {
struct legacy_scpi_shared_mem *mem = ch->rx_payload;
len = match->rx_len;
} else {
struct scpi_shared_mem *mem = ch->rx_payload;
len = min(match->rx_len, CMD_SIZE(cmd));
}
match->status = le32_to_cpu(mem->status);
memcpy_fromio(match->rx_buf, mem->payload, len);
should work.
[...]
>>
>>> + else
>>> + cmd = le32_to_cpu(mem->command);
>>>
>>> scpi_process_cmd(ch, cmd);
>>> }
>>> @@ -343,17 +464,26 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
>>> struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
>>> struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
>>>
>>> - if (t->tx_buf)
>>> - memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>>> + if (t->tx_buf) {
>>> + if (scpi_info->is_legacy)
>>> + memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
>>> + else
>>> + memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
>>> + }
>>> +
>>> if (t->rx_buf) {
>>> if (!(++ch->token))
>>> ++ch->token;
>>> ADD_SCPI_TOKEN(t->cmd, ch->token);
>>> + if (scpi_info->is_legacy)
>>> + t->slot = t->cmd;
>>
>> I thought passing token was not an issue from your previous response,
>> but you are overriding it here, why ?
>
> Indeed, I can leave it, but it's useless since it won't serve to
> distinguish multiple similar commands.
>
OK, I don't see any point in such micro optimization, so please retain it.
[...]
>>> + /* Since we cannot distinguish the original command in the
>>> + * MHU reply stat value from a Legacy SCP firmware, ensure
>>> + * sequential command sending to the firmware.
>>> + */
>>
>> OK this comment now questions the existence of this extra lock.
>> The mailbox will always send the commands in the sequential order.
>> It's only firmware that can re-order the response. Since that can't
>> happen in you case, I really don't see the need for this.
>>
>> Please explain the race you would see without this locking. Yes I
>> understand that only one command is supposed to be sent to firmware at a
>> time. Suppose you allow more callers here, all will wait on the
>> completion flags and the first in the list gets unblocked right ?
>> I am just trying to understand if there's real need for this extra
>> lock when we already have that from the list.
>
> In my current tests I have huge kernel hang when having multiple callers,
> I must find out where this issue comes from...
Yes IMO, you should understand the root cause of this issue. There may
be issue with the existing driver itself. But just adding a lock just to
avoid the hang without understanding it is wrong.
> In any case, we have an issue about the command sequencing. If we
> push a tx-only command and then right after a tx-rx command, the
> mailbox callback from the first command won't be able to distinguish
> which command is handled !
Hmm, how exactly ? I won't expect scpi_handle_remote_msg to becalled in
that case.
> In this case, the rx_pending list will not be empty, some garbage
> will be returned to the second command handler and the real data from
> the second command handling will be lost thinking it's a tx-only
> command.
>
Yes as I said why is scpi_handle_remote_msg called for tx only command.
And more over we don't have any tx only command in the driver, I am
still unable to understand the issue you are facing. Are you sure you
have tx-only command in the failure/hang case ?
>
> We have two choices here : - Also push the tx-only commands to the
> rx_pending list, and also wait for their completion
See above, I need to know details on this tx-only command. In fact, they
may not be tx-only as SCP is sending some response back, may just status.
> - Add an extra lock
>
Not this for sure.
> What is your preferred scheme ?
>
Option 1 if it legitimate case. I mean we may be misunderstanding the
definition of tx-only command.
>>> + if (scpi_info->is_legacy)
>>> + mutex_lock(&scpi_chan->legacy_lock);
>>> +
>>> ret = mbox_send_message(scpi_chan->chan, msg);
>>> if (ret < 0 || !rx_buf)
>>> goto out;
>>> @@ -421,9 +567,13 @@ static int scpi_send_message(unsigned int offset, void *tx_buf,
>>> /* first status word */
>>> ret = msg->status;
>>> out:
>>> - if (ret < 0 && rx_buf) /* remove entry from the list if timed-out */
>>> + if (ret < 0 && rx_buf)
>>> + /* remove entry from the list if timed-out */
>>> scpi_process_cmd(scpi_chan, msg->cmd);
>>>
>>> + if (scpi_info->is_legacy)
>>> + mutex_unlock(&scpi_chan->legacy_lock);
>>> +
>>> put_scpi_xfer(msg, scpi_chan);
>>> /* SCPI error codes > 0, translate them to Linux scale*/
>>> return ret > 0 ? scpi_to_linux_errno(ret) : ret;
>>
[...]
>
> I will fix the issues, but I need your advice for the locking scheme. I really want this
> to be merged and be able to go forward !
>
Yes I agree and I have no major concern with the series now except the
locking.
--
Regards,
Sudeep
More information about the linux-arm-kernel
mailing list