[Skiboot] [RFC PATCH 2/2] Add SBE driver support

[Vasant Hegde]

On 02/22/2017 05:36 PM, Oliver O'Halloran wrote:
> On Wed, Feb 22, 2017 at 9:21 PM, Vasant Hegde
> <hegdevasant at linux.vnet.ibm.com> wrote:
>> On 02/16/2017 11:56 AM, Oliver O'Halloran wrote:
>>>
>>> On Wed, 2017-02-15 at 20:44 +0530, Vasant Hegde wrote:
>>>>
>>>> SBE (Self Boot Engine) on P9 has two different jobs:
>>>>     - Boot the chip-up till core is functional
>>>>     - Provide various services like timer, scom, etc., at runtime
>>
>>
>> .../...
>>
>>>> +static inline struct sbe_msg *__sbe_allocmsg(void)
>>>> +{
>>>> +       return zalloc(sizeof(struct sbe_msg));
>>>> +}
>>>> +
>>>> +struct sbe_msg *sbe_allocmsg(bool alloc_response)
>>>> +{
>>>> +       struct sbe_msg *msg;
>>>> +
>>>> +       msg = __sbe_allocmsg();
>>>> +       if (!msg)
>>>> +               return NULL;
>>>> +
>>>> +       if (alloc_response) {
>>>> +               msg->resp = __sbe_allocmsg();
>>>> +               if (!msg->resp) {
>>>> +                       free(msg);
>>>> +                       return NULL;
>>>> +               }
>>>
>>> Given that we're limited to one outstanding response per SBE we could
>>> have a sbe_msg inside the sbe structure itself and skip this extra
>>> allocation. Up to you.
>>
>>
>> I think I should have explained this in commit message.  Actually caller can
>> queue any number of messages for given SBE. And driver will serialize
>> sending message. Hence I've added two structures.
>
> I know you can have any number of messages queued up, but like you
> said sending them is serialised. As far as I can tell the receive
> logic looks something like this:
>
> msg = msg_at_top_of_queue();
> remove_from_queue(msg);
> if (msg->complete)
>       msg->complete(msg);
> sbe_free(msg);

I want caller to decide whether to free message or not. Like in case of timer, I 
want o allocate msg once and reuse it instead of allocate/free/allocate.


> sbe_queue_poke();
>
> So we completely handle the message at the top of the queue before
> processing the next one. The space that was allocated for the response
> to the first message is free()ed immediately after calling the
> completion function. What I was getting at is that because responses
> are also serialised there is no need to allocate a separate response
> structure for each message. Instead we could have a single response
> structure (for each SBE) that is re-used when processing each message
> in the queue. I think, I might have missed something ;)


Yeah. I can allocate response message in sbe structure itself and then pass the 
response message to caller. something like
comp(msg, resp);

-Vasant