Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register

[Al Chu]

Hey A.B,

> Al, Unfortunately SMS_ATN is KCS specific. So we can't create an 
> abstracted API.

There's no reason other drivers won't have "interrupt callbacks" in the
future.  We can abstract it by calling the API function something like
"interrupt_callback".  The only driver supported with it would be KCS in
the beginning.

Al

On Sun, 2010-02-21 at 04:29 -0800, Anand Babu Periasamy wrote:
> Matt Jerdonek wrote:
> > Al & Anand,
> > 
> > Thanks for the quick response.  I'm planning on using libfreeipmi to 
> > create a custom application that, among other things, will have to read 
> > event flags from the local event log and query sensors on local and 
> > remote BMCs.
> > 
> > I looked at the spec, and I think I have a slightly different 
> > understanding (I'm not saying I'm right -- I may be misunderstanding the 
> > spec).  I don't think SMS_ATN and OBF can be used interchangeably.  
> > Here's my understanding:
> > 1) If the SMS_ATN bit is set the local BMC requires some attention.
> > 2) A GET MESSAGE FLAGS command should be sent to query the BMC.
> > 3) If bit 0 is set in the response, that indicates a receive message is 
> > available.  From looking at the ipmi_kcs_cmd_api_ipmb code, it appears 
> > as if that code polls the local BMC with GET MESSAGE cmds instead of 
> > using this bit to indicate when the response from the remote BMC is 
> > ready.  While polling may not be ideal, it's certainly ok for my 
> > application.
> > 4) If bit 1 is set in the response, that indicates an event is available.
> > 5) I'll ignore the pre-watchdog timeout and OEM bits for now ...
> > 
> > I don't understand how libfreeipmi notifies the application that an 
> > event is available without monitoring the SMS_ATN bit.  I think I want 
> > to create a patch that does the following:
> > 1) Creates a callback from libfreeapi to the application when an event 
> > occurs.
> > 2) Monitors the SMS_ATN bit.
> > 3) If set, invokes the callback.
> > 
> > The application would be responsible for issuing the GET MESSAGE FLAGS 
> > command and handling the response.  One downside of this approach is 
> > that it prevents you from ever making ipmi_kcs_cmd_api_ipmb 
> > event-driven.  What do you two think?
> > 
> > Thanks,
> > -Matt
> > ------------------------------------------------------------------------
> > *From:* Al Chu <address@hidden>
> > *To:* Matt Jerdonek <address@hidden>
> > *Cc:* address@hidden
> > *Sent:* Thu, February 18, 2010 10:58:06 AM
> > *Subject:* Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
> > 
> > Hi Matt,
> > 
> > Definitely open to patches.  Looking over the IPMI spec, I agree w/
> > A.B., it seems to be more useful for a higher level monitoring, w/ the
> > Get Message Flags and similar commands.  I can think of several patch
> > ideas:
> > 
> > 1) add a KCS driver flag for checking for SMS_ATN in addition to OBF (or
> > instead of??).  Flags may be propogated up into higher level APIs too.
> > 
> > 2) an additional function that checks for SMS_ATN in addition/or instead
> > of OBF that users can call instead.
> > 
> > It would be useful to understand your use case too.  Are you using the
> > KCS driver and IPMI bridging commands to bridge from one BMC to another
> > BMC?
> > 
> > Thanks,
> > 
> > Al
> > 
> > On Wed, 2010-02-17 at 18:51 -0800, Matt Jerdonek wrote:
> >  > Hello,
> >  >
> >  > The KCS driver appears to not use the SMS_ATN register.  This register
> >  > is useful for BMC-to-BMC communication to know when the remote BMC has
> >  > responded.  Are there any plans to monitor this register in future
> >  > releases?  If not, are the maintainers open to including a patch?
> >  >
> >  > Thanks,
> >  > -Matt
> 
> I have attached a patch to give you an idea. I did not even compile it yet.
> If ipmi_kcs_read_sms_atn() returns 1, then you should call 
> ipmi_cmd_get_message_flags() 
> function and check what type of event occurred.
> 
> nt ipmi_kcs_read_sms_atn (ipmi_kcs_ctx_t ctx);
> int ipmi_cmd_get_message_flags (ipmi_ctx_t ctx, fiid_obj_t obj_cmd_rs);
> Use this "tmpl_cmd_get_message_flags_rs" to parse the message contents.
> 
> All IPMI commands have request (write) and response (read) transaction model. 
> So FreeIPMI 
> drivers doesn't have to  wait for interrupts. All responses are triggered by 
> its own 
> requests. Driver internally uses OBF to poll for response immediately after 
> request 
> command. Polling is very short lived.
> 
> OBF is appropriate only when you send a command request. For general polling 
> of hardware 
> triggered events, one should use SMS_ATN register. Instead of creating a 
> callback model, 
> it is better to expose ipmi_kcs_read_sms_atn () function directly. It works 
> like an 
> asynchronous function. Let the application retain the control and decide how 
> to thread or 
> poll using this function.
> 
> Al, Unfortunately SMS_ATN is KCS specific. So we can't create an abstracted 
> API.
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory