Skip to content

Commit

Permalink
mailbox: ti-msgmgr: Refactor message read during interrupt handler
Browse files Browse the repository at this point in the history
Refactor the portion of code that actually reads received messages from
a queue into its own function, ti_msgmgr_queue_rx_data, that is called
by the interrupt handler instead of reading directly from the handler.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
  • Loading branch information
Dave Gerlach authored and Jassi Brar committed Mar 13, 2022
1 parent 0184cc2 commit cb62b8f
Showing 1 changed file with 49 additions and 39 deletions.
88 changes: 49 additions & 39 deletions drivers/mailbox/ti-msgmgr.c
Original file line number Diff line number Diff line change
Expand Up @@ -190,6 +190,53 @@ static inline bool ti_msgmgr_queue_is_error(const struct ti_msgmgr_desc *d,
return val ? true : false;
}

static int ti_msgmgr_queue_rx_data(struct mbox_chan *chan, struct ti_queue_inst *qinst,
const struct ti_msgmgr_desc *desc)
{
int num_words;
struct ti_msgmgr_message message;
void __iomem *data_reg;
u32 *word_data;

/*
* I have no idea about the protocol being used to communicate with the
* remote producer - 0 could be valid data, so I wont make a judgement
* of how many bytes I should be reading. Let the client figure this
* out.. I just read the full message and pass it on..
*/
message.len = desc->max_message_size;
message.buf = (u8 *)qinst->rx_buff;

/*
* NOTE about register access involved here:
* the hardware block is implemented with 32bit access operations and no
* support for data splitting. We don't want the hardware to misbehave
* with sub 32bit access - For example: if the last register read is
* split into byte wise access, it can result in the queue getting
* stuck or indeterminate behavior. An out of order read operation may
* result in weird data results as well.
* Hence, we do not use memcpy_fromio or __ioread32_copy here, instead
* we depend on readl for the purpose.
*
* Also note that the final register read automatically marks the
* queue message as read.
*/
for (data_reg = qinst->queue_buff_start, word_data = qinst->rx_buff,
num_words = (desc->max_message_size / sizeof(u32));
num_words; num_words--, data_reg += sizeof(u32), word_data++)
*word_data = readl(data_reg);

/*
* Last register read automatically clears the IRQ if only 1 message
* is pending - so send the data up the stack..
* NOTE: Client is expected to be as optimal as possible, since
* we invoke the handler in IRQ context.
*/
mbox_chan_received_data(chan, (void *)&message);

return 0;
}

/**
* ti_msgmgr_queue_rx_interrupt() - Interrupt handler for receive Queue
* @irq: Interrupt number
Expand All @@ -206,10 +253,7 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
struct ti_queue_inst *qinst = chan->con_priv;
const struct ti_msgmgr_desc *desc;
int msg_count, num_words;
struct ti_msgmgr_message message;
void __iomem *data_reg;
u32 *word_data;
int msg_count;

if (WARN_ON(!inst)) {
dev_err(dev, "no platform drv data??\n");
Expand Down Expand Up @@ -237,41 +281,7 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
return IRQ_NONE;
}

/*
* I have no idea about the protocol being used to communicate with the
* remote producer - 0 could be valid data, so I won't make a judgement
* of how many bytes I should be reading. Let the client figure this
* out.. I just read the full message and pass it on..
*/
message.len = desc->max_message_size;
message.buf = (u8 *)qinst->rx_buff;

/*
* NOTE about register access involved here:
* the hardware block is implemented with 32bit access operations and no
* support for data splitting. We don't want the hardware to misbehave
* with sub 32bit access - For example: if the last register read is
* split into byte wise access, it can result in the queue getting
* stuck or indeterminate behavior. An out of order read operation may
* result in weird data results as well.
* Hence, we do not use memcpy_fromio or __ioread32_copy here, instead
* we depend on readl for the purpose.
*
* Also note that the final register read automatically marks the
* queue message as read.
*/
for (data_reg = qinst->queue_buff_start, word_data = qinst->rx_buff,
num_words = (desc->max_message_size / sizeof(u32));
num_words; num_words--, data_reg += sizeof(u32), word_data++)
*word_data = readl(data_reg);

/*
* Last register read automatically clears the IRQ if only 1 message
* is pending - so send the data up the stack..
* NOTE: Client is expected to be as optimal as possible, since
* we invoke the handler in IRQ context.
*/
mbox_chan_received_data(chan, (void *)&message);
ti_msgmgr_queue_rx_data(chan, qinst, desc);

return IRQ_HANDLED;
}
Expand Down

0 comments on commit cb62b8f

Please sign in to comment.