lkml.org 
[lkml]   [2020]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch V2 46/46] irqchip: Add IMS (Interrupt Message Storm) driver - NOT FOR MERGING
    On Wed, Aug 26, 2020 at 01:17:14PM +0200, Thomas Gleixner wrote:
    > + * ims_queue_info - Information to create an IMS queue domain
    > + * @queue_lock: Callback which informs the device driver that
    > + * an interrupt management operation starts.
    > + * @queue_sync_unlock: Callback which informs the device driver that an
    > + * interrupt management operation ends.
    > +
    > + * @queue_get_shadow: Callback to retrieve te shadow storage for a MSI
    > + * entry associated to a queue. The queue is
    > + * identified by the device struct which is used for
    > + * allocating interrupts and the msi entry index.
    > + *
    > + * @queue_lock() and @queue_sync_unlock() are only called for management
    > + * operations on a particular interrupt: request, free, enable, disable,
    > + * affinity setting. These functions are never called from atomic context,
    > + * like low level interrupt handling code. The purpose of these functions
    > + * is to signal the device driver the start and end of an operation which
    > + * affects the IMS queue shadow state. @queue_lock() allows the driver to
    > + * do preperatory work, e.g. locking. Note, that @queue_lock() has to
    > + * preserve the sleepable state on return. That means the driver cannot
    > + * disable preemption and (soft)interrupts in @queue_lock and then undo
    > + * that operation in @queue_sync_unlock() which restricts the lock types
    > + * for eventual serialization of these operations to sleepable locks. Of
    > + * course the driver can disable preemption and (soft)interrupts
    > + * temporarily for internal work.
    > + *
    > + * On @queue_sync_unlock() the driver has to check whether the shadow state
    > + * changed and issue a command to update the hardware state and wait for
    > + * the command to complete. If the command fails or times out then the
    > + * driver has to take care of the resulting mess as this is called from
    > + * functions which have no return value and none of the callers can deal
    > + * with the failure. The lock which is used by the driver to protect a
    > + * operation sequence must obviously not be released before the command
    > + * completes or fails. Otherwise new operations on the same interrupt line
    > + * could take place and change the shadow state before the driver was able
    > + * to compose the command.

    I haven't looked through everything in detail, but this does look like
    it is good for the mlx5 devices. Looked like it was only one small
    update to the set_affinity, so not very disruptive?

    Thanks,
    Jason

    \
     
     \ /
      Last update: 2020-08-31 16:46    [W:4.204 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site