Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On 11 October 2016 at 08:10, Horng-Shyang Liao wrote: > On Thu, 2016-10-06 at 18:40 +0530, Jassi Brar wrote: >> On 6 October 2016 at 18:31, Horng-Shyang Liao wrote: >> >> > Back to our original statement, we need to flush all tasks to queue >> > in GCE HW; i.e. we need to use mbox_client_txdone after >> > mbox_send_message, or send tx_done once mailbox controller receive >> > message (task). However, we still need a way to notice done tasks to >> > clients. Currently, we don't have a good way to call callback in mailbox >> > framework. Therefore, CMDQ driver has its owner callback functions. >> > >> mbox_client_txdone() is called by the client driver when only it knows >> the messages has been transmitted (i.e your submitted tasks are done). >> Obviously the client driver should do any callbacks to its users >> upstream. > > Hi Jassi, > > In current CMDQ driver, mbox_client_txdone() is called to prevent the > blocking of chan->active_req. It is not the real point of CMDQ task > done, so the client driver cannot do any callbacks to its user upstream. > > (1) If we don't use mbox_client_txdone(), could you tell us an > alternative way to prevent the blocking of chan->active_req? > And then we can use tx_done when CMDQ task is relly done. > mbox_client_txdone() should be used only when the mailbox controller driver can't figure when the TX is done. Client driver (by like some reply packet) realises the TX is done (for the reply to have arrived). If your hardware does flag/irq when tx is done, you should prefer that over mbox_client_txdone(). > (2) If we use mbox_client_txdone() to prevent the blocking of > chan->active_req, could CMDQ driver just uses self-defined callback > function to notice client driver CMDQ task done? > Anything above the mailbox api, is none of its business. Your platform specific 'server' driver can implement its own callbacks to notify its users.
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Thu, 2016-10-06 at 18:40 +0530, Jassi Brar wrote: > On 6 October 2016 at 18:31, Horng-Shyang Liao wrote: > > > Back to our original statement, we need to flush all tasks to queue > > in GCE HW; i.e. we need to use mbox_client_txdone after > > mbox_send_message, or send tx_done once mailbox controller receive > > message (task). However, we still need a way to notice done tasks to > > clients. Currently, we don't have a good way to call callback in mailbox > > framework. Therefore, CMDQ driver has its owner callback functions. > > > mbox_client_txdone() is called by the client driver when only it knows > the messages has been transmitted (i.e your submitted tasks are done). > Obviously the client driver should do any callbacks to its users > upstream. Hi Jassi, In current CMDQ driver, mbox_client_txdone() is called to prevent the blocking of chan->active_req. It is not the real point of CMDQ task done, so the client driver cannot do any callbacks to its user upstream. (1) If we don't use mbox_client_txdone(), could you tell us an alternative way to prevent the blocking of chan->active_req? And then we can use tx_done when CMDQ task is relly done. (2) If we use mbox_client_txdone() to prevent the blocking of chan->active_req, could CMDQ driver just uses self-defined callback function to notice client driver CMDQ task done? Thanks, HS
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On 6 October 2016 at 18:31, Horng-Shyang Liao wrote: > Back to our original statement, we need to flush all tasks to queue > in GCE HW; i.e. we need to use mbox_client_txdone after > mbox_send_message, or send tx_done once mailbox controller receive > message (task). However, we still need a way to notice done tasks to > clients. Currently, we don't have a good way to call callback in mailbox > framework. Therefore, CMDQ driver has its owner callback functions. > mbox_client_txdone() is called by the client driver when only it knows the messages has been transmitted (i.e your submitted tasks are done). Obviously the client driver should do any callbacks to its users upstream.
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Wed, 2016-10-05 at 20:13 +0530, Jassi Brar wrote:
> On 5 October 2016 at 18:01, Horng-Shyang Liao wrote:
> > On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote:
> >> On 5 October 2016 at 08:24, Horng-Shyang Liao wrote:
> >> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> >> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> >>
> >> >
> >> > After I trace mailbox driver, I realize that CMDQ driver cannot use
> >> > tx_done.
> >> >
> >> > CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> >> > driver will apply these tasks into GCE HW "immediately". These tasks,
> >> > which are queued in GCE HW, may not execute immediately since they
> >> > may need to wait event(s), e.g. vsync.
> >> >
> >> > However, in mailbox driver, mailbox uses a software buffer to queue
> >> > sent messages. It only sends next message until previous message is
> >> > done. This cannot fulfill CMDQ's requirement.
> >> >
> >> I understand
> >> a) GCE HW can internally queue many tasks in some 'FIFO'
> >> b) Execution of some task may have to wait until some external event
> >> occurs (like vsync)
> >> c) GCE does not generate irq/flag for each task executed (?)
> >>
> >> If so, may be your tx_done should return 'true' so long as the GCE HW
> >> can accept tasks in its 'FIFO'. For mailbox api, any task that is
> >> queued on GCE, is assumed to be transmitted.
> >>
> >> > Quote some code from mailbox driver. Please notice "active_req" part.
> >> >
> >> > static void msg_submit(struct mbox_chan *chan)
> >> > {
> >> > ...
> >> > if (!chan->msg_count || chan->active_req)
> >> > goto exit;
> >> > ...
> >> > err = chan->mbox->ops->send_data(chan, data);
> >> > if (!err) {
> >> > chan->active_req = data;
> >> > chan->msg_count--;
> >> > }
> >> > ...
> >> > }
> >> >
> >> > static void tx_tick(struct mbox_chan *chan, int r)
> >> > {
> >> > ...
> >> > spin_lock_irqsave(&chan->lock, flags);
> >> > mssg = chan->active_req;
> >> > chan->active_req = NULL;
> >> > spin_unlock_irqrestore(&chan->lock, flags);
> >> > ...
> >> > }
> >> >
> >> > Current workable CMDQ driver uses mbox_client_txdone() to prevent
> >> > this issue, and then uses self callback functions to handle done tasks.
> >> >
> >> > int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> >> > *task, cmdq_async_flush_cb cb, void *data)
> >> > {
> >> > ...
> >> > mbox_send_message(client->chan, task);
> >> > /* We can send next task immediately, so just call txdone. */
> >> > mbox_client_txdone(client->chan, 0);
> >> > ...
> >> > }
> >> >
> >> > Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> >> > call mbox_chan_received_data() when CMDQ task is done. But, this may
> >> > violate the design of mailbox. What do you think?
> >> >
> >> If my point (c) above does not hold, maybe look at implementing
> >> tx_done() callback and submit next task from the callback of last
> >> done.
> >
> >
> > Hi Jassi,
> >
> > For point (c), GCE irq means 1~n tasks done or
> > 0~n tasks done + 1 task error.
> > In irq, we can know which tasks are done by register and GCE pc.
> >
> > As I mentioned before, we cannot submit next task after previous task
> > call tx_done. We need to submit multiple tasks to GCE HW immediately
> > and queue them in GCE HW.
>
> > Let me explain this requirement by mouse
> > cursor example. User may move mouse quickly between two vsync, so DRM
> > may update display registers frequently. For CMDQ, that means many tasks
> > are flushed into CMDQ driver, and CMDQ driver needs to process all of
> > them in next vblank. Therefore, we cannot block any CMDQ task in SW
> > buffer.
> >
> We are interested only in the current position of cursor and not its
> trail. Also the current position should be updated at next vsync (and
> not the one after it).
> Going by this example, if the GCE HW can take in 'N' tasks at a time,
> then the N+1th submission should shift out (drop) the 1st task queued.
> So that at any time GCE HW has only the latest N tasks. Right?
>
> If yes, maybe you don't need to care about tx-done and simply keep
> shoving tasks as you generate them.
>
> If no, maybe your client driver need to emulate such a circular
> buffer where oldest task is overwritten by newest submission. And you
> submit the circular buffer (most relevant tasks) at one go to the GCE
> HW.
Hi Jassi,
CMDQ driver doesn't know the task type, so CMDQ cannot decide which
tasks can be dropped. So, I think the answer is "no".
Client driver is also hard to emulate a circular buffer where oldest
task is overwritten by newest submission. Let me illustrate with DRM
client (display driver). For DRM, the only way to know the latest
mouse cursor task before vsync is vsync interrupt. However, if we
keep latest mouse cursor task and start t
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On 5 October 2016 at 18:01, Horng-Shyang Liao wrote:
> On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote:
>> On 5 October 2016 at 08:24, Horng-Shyang Liao wrote:
>> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
>>
>> >
>> > After I trace mailbox driver, I realize that CMDQ driver cannot use
>> > tx_done.
>> >
>> > CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
>> > driver will apply these tasks into GCE HW "immediately". These tasks,
>> > which are queued in GCE HW, may not execute immediately since they
>> > may need to wait event(s), e.g. vsync.
>> >
>> > However, in mailbox driver, mailbox uses a software buffer to queue
>> > sent messages. It only sends next message until previous message is
>> > done. This cannot fulfill CMDQ's requirement.
>> >
>> I understand
>> a) GCE HW can internally queue many tasks in some 'FIFO'
>> b) Execution of some task may have to wait until some external event
>> occurs (like vsync)
>> c) GCE does not generate irq/flag for each task executed (?)
>>
>> If so, may be your tx_done should return 'true' so long as the GCE HW
>> can accept tasks in its 'FIFO'. For mailbox api, any task that is
>> queued on GCE, is assumed to be transmitted.
>>
>> > Quote some code from mailbox driver. Please notice "active_req" part.
>> >
>> > static void msg_submit(struct mbox_chan *chan)
>> > {
>> > ...
>> > if (!chan->msg_count || chan->active_req)
>> > goto exit;
>> > ...
>> > err = chan->mbox->ops->send_data(chan, data);
>> > if (!err) {
>> > chan->active_req = data;
>> > chan->msg_count--;
>> > }
>> > ...
>> > }
>> >
>> > static void tx_tick(struct mbox_chan *chan, int r)
>> > {
>> > ...
>> > spin_lock_irqsave(&chan->lock, flags);
>> > mssg = chan->active_req;
>> > chan->active_req = NULL;
>> > spin_unlock_irqrestore(&chan->lock, flags);
>> > ...
>> > }
>> >
>> > Current workable CMDQ driver uses mbox_client_txdone() to prevent
>> > this issue, and then uses self callback functions to handle done tasks.
>> >
>> > int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
>> > *task, cmdq_async_flush_cb cb, void *data)
>> > {
>> > ...
>> > mbox_send_message(client->chan, task);
>> > /* We can send next task immediately, so just call txdone. */
>> > mbox_client_txdone(client->chan, 0);
>> > ...
>> > }
>> >
>> > Another solution is to use rx_callback; i.e. CMDQ mailbox controller
>> > call mbox_chan_received_data() when CMDQ task is done. But, this may
>> > violate the design of mailbox. What do you think?
>> >
>> If my point (c) above does not hold, maybe look at implementing
>> tx_done() callback and submit next task from the callback of last
>> done.
>
>
> Hi Jassi,
>
> For point (c), GCE irq means 1~n tasks done or
> 0~n tasks done + 1 task error.
> In irq, we can know which tasks are done by register and GCE pc.
>
> As I mentioned before, we cannot submit next task after previous task
> call tx_done. We need to submit multiple tasks to GCE HW immediately
> and queue them in GCE HW.
> Let me explain this requirement by mouse
> cursor example. User may move mouse quickly between two vsync, so DRM
> may update display registers frequently. For CMDQ, that means many tasks
> are flushed into CMDQ driver, and CMDQ driver needs to process all of
> them in next vblank. Therefore, we cannot block any CMDQ task in SW
> buffer.
>
We are interested only in the current position of cursor and not its
trail. Also the current position should be updated at next vsync (and
not the one after it).
Going by this example, if the GCE HW can take in 'N' tasks at a time,
then the N+1th submission should shift out (drop) the 1st task queued.
So that at any time GCE HW has only the latest N tasks. Right?
If yes, maybe you don't need to care about tx-done and simply keep
shoving tasks as you generate them.
If no, maybe your client driver need to emulate such a circular
buffer where oldest task is overwritten by newest submission. And you
submit the circular buffer (most relevant tasks) at one go to the GCE
HW.
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Wed, 2016-10-05 at 09:07 +0530, Jassi Brar wrote:
> On 5 October 2016 at 08:24, Horng-Shyang Liao wrote:
> > On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> >> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
>
> >
> > After I trace mailbox driver, I realize that CMDQ driver cannot use
> > tx_done.
> >
> > CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> > driver will apply these tasks into GCE HW "immediately". These tasks,
> > which are queued in GCE HW, may not execute immediately since they
> > may need to wait event(s), e.g. vsync.
> >
> > However, in mailbox driver, mailbox uses a software buffer to queue
> > sent messages. It only sends next message until previous message is
> > done. This cannot fulfill CMDQ's requirement.
> >
> I understand
> a) GCE HW can internally queue many tasks in some 'FIFO'
> b) Execution of some task may have to wait until some external event
> occurs (like vsync)
> c) GCE does not generate irq/flag for each task executed (?)
>
> If so, may be your tx_done should return 'true' so long as the GCE HW
> can accept tasks in its 'FIFO'. For mailbox api, any task that is
> queued on GCE, is assumed to be transmitted.
>
> > Quote some code from mailbox driver. Please notice "active_req" part.
> >
> > static void msg_submit(struct mbox_chan *chan)
> > {
> > ...
> > if (!chan->msg_count || chan->active_req)
> > goto exit;
> > ...
> > err = chan->mbox->ops->send_data(chan, data);
> > if (!err) {
> > chan->active_req = data;
> > chan->msg_count--;
> > }
> > ...
> > }
> >
> > static void tx_tick(struct mbox_chan *chan, int r)
> > {
> > ...
> > spin_lock_irqsave(&chan->lock, flags);
> > mssg = chan->active_req;
> > chan->active_req = NULL;
> > spin_unlock_irqrestore(&chan->lock, flags);
> > ...
> > }
> >
> > Current workable CMDQ driver uses mbox_client_txdone() to prevent
> > this issue, and then uses self callback functions to handle done tasks.
> >
> > int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> > *task, cmdq_async_flush_cb cb, void *data)
> > {
> > ...
> > mbox_send_message(client->chan, task);
> > /* We can send next task immediately, so just call txdone. */
> > mbox_client_txdone(client->chan, 0);
> > ...
> > }
> >
> > Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> > call mbox_chan_received_data() when CMDQ task is done. But, this may
> > violate the design of mailbox. What do you think?
> >
> If my point (c) above does not hold, maybe look at implementing
> tx_done() callback and submit next task from the callback of last
> done.
Hi Jassi,
For point (c), GCE irq means 1~n tasks done or
0~n tasks done + 1 task error.
In irq, we can know which tasks are done by register and GCE pc.
As I mentioned before, we cannot submit next task after previous task
call tx_done. We need to submit multiple tasks to GCE HW immediately
and queue them in GCE HW. Let me explain this requirement by mouse
cursor example. User may move mouse quickly between two vsync, so DRM
may update display registers frequently. For CMDQ, that means many tasks
are flushed into CMDQ driver, and CMDQ driver needs to process all of
them in next vblank. Therefore, we cannot block any CMDQ task in SW
buffer.
CMDQ needs to call callback function to notice clients which tasks are
done. In my previous e-mail, I mentioned that rx_callback may be an
alternative solution. However, it seems to violate the design of
mailbox. Therefore, I think mailbox may not have a good solution for
CMDQ callback currently. IMHO, the better way is to use CMDQ self
callback for now.
Thanks,
HS
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On 5 October 2016 at 08:24, Horng-Shyang Liao wrote:
> On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
>> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
>
> After I trace mailbox driver, I realize that CMDQ driver cannot use
> tx_done.
>
> CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
> driver will apply these tasks into GCE HW "immediately". These tasks,
> which are queued in GCE HW, may not execute immediately since they
> may need to wait event(s), e.g. vsync.
>
> However, in mailbox driver, mailbox uses a software buffer to queue
> sent messages. It only sends next message until previous message is
> done. This cannot fulfill CMDQ's requirement.
>
I understand
a) GCE HW can internally queue many tasks in some 'FIFO'
b) Execution of some task may have to wait until some external event
occurs (like vsync)
c) GCE does not generate irq/flag for each task executed (?)
If so, may be your tx_done should return 'true' so long as the GCE HW
can accept tasks in its 'FIFO'. For mailbox api, any task that is
queued on GCE, is assumed to be transmitted.
> Quote some code from mailbox driver. Please notice "active_req" part.
>
> static void msg_submit(struct mbox_chan *chan)
> {
> ...
> if (!chan->msg_count || chan->active_req)
> goto exit;
> ...
> err = chan->mbox->ops->send_data(chan, data);
> if (!err) {
> chan->active_req = data;
> chan->msg_count--;
> }
> ...
> }
>
> static void tx_tick(struct mbox_chan *chan, int r)
> {
> ...
> spin_lock_irqsave(&chan->lock, flags);
> mssg = chan->active_req;
> chan->active_req = NULL;
> spin_unlock_irqrestore(&chan->lock, flags);
> ...
> }
>
> Current workable CMDQ driver uses mbox_client_txdone() to prevent
> this issue, and then uses self callback functions to handle done tasks.
>
> int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
> *task, cmdq_async_flush_cb cb, void *data)
> {
> ...
> mbox_send_message(client->chan, task);
> /* We can send next task immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
> ...
> }
>
> Another solution is to use rx_callback; i.e. CMDQ mailbox controller
> call mbox_chan_received_data() when CMDQ task is done. But, this may
> violate the design of mailbox. What do you think?
>
If my point (c) above does not hold, maybe look at implementing
tx_done() callback and submit next task from the callback of last
done.
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Fri, 2016-09-30 at 17:47 +0800, Horng-Shyang Liao wrote:
> On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> > Hi, HS:
> >
> > One comment inline
> >
> > On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > > Hi CK,
> > >
> > > Please see my inline reply.
> > >
> > > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > > Hi, HS:
> > > >
> > > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > > This patch is first version of Mediatek Command Queue(CMDQ) driver.
> > > > > The
> > > > > CMDQ is used to help write registers with critical time limitation,
> > > > > such as updating display configuration during the vblank. It controls
> > > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > > it can be extended to other hardwares for future requirements.
> > > > >
> > > > > Signed-off-by: HS Liao
> > > > > Signed-off-by: CK Hu
> > > > > ---
> > > >
> > > > [snip...]
> > > >
> > > > > +
> > > > > +struct cmdq_task {
> > > > > + struct cmdq *cmdq;
> > > > > + struct list_headlist_entry;
> > > > > + void*va_base;
> > > > > + dma_addr_t pa_base;
> > > > > + size_t cmd_buf_size; /* command occupied size
> > > > > */
> > > > > + size_t buf_size; /* real buffer size */
> > > > > + boolfinalized;
> > > > > + struct cmdq_thread *thread;
> > > >
> > > > I think thread info could be removed from cmdq_task. Only
> > > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > > task->thread and caller of both function has the thread info. So you
> > > > could just pass thread info into these two function and remove thread
> > > > info in cmdq_task.
> > >
> > > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > > more pointers will need to be delivered between functions for future
> > > extension. IMHO, it would be better to keep thread pointer inside
> > > cmdq_task.
> > >
> > > > > + struct cmdq_task_cb cb;
> > > >
> > > > I think this callback function is equal to mailbox client tx_done
> > > > callback. It's better to use already-defined interface rather than
> > > > creating your own.
> > >
> > > This is because CMDQ driver allows different callback functions for
> > > different tasks, but mailbox only allows one callback function per
> > > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > > callback functions. So, I will use tx_done in CMDQ v15.
> >
> > Up to now, one callback function for one channel is enough for DRM. So
> > 'different callback function for different sent-message' looks like an
> > advanced function. Maybe you should not include it in first patch.
> >
> > Regards,
> > CK
>
> Hi CK,
>
> OK. I will do it.
>
> Thanks,
> HS
>
> [snip...]
Hi CK,
After I trace mailbox driver, I realize that CMDQ driver cannot use
tx_done.
CMDQ clients will flush many tasks into CMDQ driver, and then CMDQ
driver will apply these tasks into GCE HW "immediately". These tasks,
which are queued in GCE HW, may not execute immediately since they
may need to wait event(s), e.g. vsync.
However, in mailbox driver, mailbox uses a software buffer to queue
sent messages. It only sends next message until previous message is
done. This cannot fulfill CMDQ's requirement.
Quote some code from mailbox driver. Please notice "active_req" part.
static void msg_submit(struct mbox_chan *chan)
{
...
if (!chan->msg_count || chan->active_req)
goto exit;
...
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
chan->active_req = data;
chan->msg_count--;
}
...
}
static void tx_tick(struct mbox_chan *chan, int r)
{
...
spin_lock_irqsave(&chan->lock, flags);
mssg = chan->active_req;
chan->active_req = NULL;
spin_unlock_irqrestore(&chan->lock, flags);
...
}
Current workable CMDQ driver uses mbox_client_txdone() to prevent
this issue, and then uses self callback functions to handle done tasks.
int cmdq_task_flush_async(struct cmdq_client *client, struct cmdq_task
*task, cmdq_async_flush_cb cb, void *data)
{
...
mbox_send_message(client->chan, task);
/* We can send next task immediately, so just call txdone. */
mbox_client_txdone(client->chan, 0);
...
}
Another solution is to use rx_callback; i.e. CMDQ mailbox controller
call mbox_chan_received_data() when CMDQ task is done. But, this may
violate the design of mailbox. What do you think?
Thanks,
HS
Hi Jassi,
Do you have any suggestion about previous situation?
Thanks,
HS
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Fri, 2016-09-30 at 17:11 +0800, CK Hu wrote:
> Hi, HS:
>
> One comment inline
>
> On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> > Hi CK,
> >
> > Please see my inline reply.
> >
> > On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > > Hi, HS:
> > >
> > > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > > CMDQ is used to help write registers with critical time limitation,
> > > > such as updating display configuration during the vblank. It controls
> > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > it can be extended to other hardwares for future requirements.
> > > >
> > > > Signed-off-by: HS Liao
> > > > Signed-off-by: CK Hu
> > > > ---
> > >
> > > [snip...]
> > >
> > > > +
> > > > +struct cmdq_task {
> > > > + struct cmdq *cmdq;
> > > > + struct list_headlist_entry;
> > > > + void*va_base;
> > > > + dma_addr_t pa_base;
> > > > + size_t cmd_buf_size; /* command occupied size
> > > > */
> > > > + size_t buf_size; /* real buffer size */
> > > > + boolfinalized;
> > > > + struct cmdq_thread *thread;
> > >
> > > I think thread info could be removed from cmdq_task. Only
> > > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > > task->thread and caller of both function has the thread info. So you
> > > could just pass thread info into these two function and remove thread
> > > info in cmdq_task.
> >
> > This modification will remove 1 pointer but add 2 pointers. Moreover,
> > more pointers will need to be delivered between functions for future
> > extension. IMHO, it would be better to keep thread pointer inside
> > cmdq_task.
> >
> > > > + struct cmdq_task_cb cb;
> > >
> > > I think this callback function is equal to mailbox client tx_done
> > > callback. It's better to use already-defined interface rather than
> > > creating your own.
> >
> > This is because CMDQ driver allows different callback functions for
> > different tasks, but mailbox only allows one callback function per
> > channel. But, I think I can add a wrapper for tx_done to call CMDQ
> > callback functions. So, I will use tx_done in CMDQ v15.
>
> Up to now, one callback function for one channel is enough for DRM. So
> 'different callback function for different sent-message' looks like an
> advanced function. Maybe you should not include it in first patch.
>
> Regards,
> CK
Hi CK,
OK. I will do it.
Thanks,
HS
[snip...]
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
Hi, HS:
One comment inline
On Fri, 2016-09-30 at 16:56 +0800, Horng-Shyang Liao wrote:
> Hi CK,
>
> Please see my inline reply.
>
> On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> > Hi, HS:
> >
> > On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > CMDQ is used to help write registers with critical time limitation,
> > > such as updating display configuration during the vblank. It controls
> > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > Currently, CMDQ only supports display related hardwares, but we expect
> > > it can be extended to other hardwares for future requirements.
> > >
> > > Signed-off-by: HS Liao
> > > Signed-off-by: CK Hu
> > > ---
> >
> > [snip...]
> >
> > > +
> > > +struct cmdq_task {
> > > + struct cmdq *cmdq;
> > > + struct list_headlist_entry;
> > > + void*va_base;
> > > + dma_addr_t pa_base;
> > > + size_t cmd_buf_size; /* command occupied size */
> > > + size_t buf_size; /* real buffer size */
> > > + boolfinalized;
> > > + struct cmdq_thread *thread;
> >
> > I think thread info could be removed from cmdq_task. Only
> > cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> > task->thread and caller of both function has the thread info. So you
> > could just pass thread info into these two function and remove thread
> > info in cmdq_task.
>
> This modification will remove 1 pointer but add 2 pointers. Moreover,
> more pointers will need to be delivered between functions for future
> extension. IMHO, it would be better to keep thread pointer inside
> cmdq_task.
>
> > > + struct cmdq_task_cb cb;
> >
> > I think this callback function is equal to mailbox client tx_done
> > callback. It's better to use already-defined interface rather than
> > creating your own.
>
> This is because CMDQ driver allows different callback functions for
> different tasks, but mailbox only allows one callback function per
> channel. But, I think I can add a wrapper for tx_done to call CMDQ
> callback functions. So, I will use tx_done in CMDQ v15.
Up to now, one callback function for one channel is enough for DRM. So
'different callback function for different sent-message' looks like an
advanced function. Maybe you should not include it in first patch.
Regards,
CK
>
> > > +};
> > > +
> >
> > [snip...]
> >
> > > +
> > > +static int cmdq_suspend(struct device *dev)
> > > +{
> > > + struct cmdq *cmdq = dev_get_drvdata(dev);
> > > + struct cmdq_thread *thread;
> > > + int i;
> > > + bool task_running = false;
> > > +
> > > + mutex_lock(&cmdq->task_mutex);
> > > + cmdq->suspended = true;
> > > + mutex_unlock(&cmdq->task_mutex);
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> > > + thread = &cmdq->thread[i];
> > > + if (!list_empty(&thread->task_busy_list)) {
> > > + mod_timer(&thread->timeout, jiffies + 1);
> > > + task_running = true;
> > > + }
> > > + }
> > > +
> > > + if (task_running) {
> > > + dev_warn(dev, "exist running task(s) in suspend\n");
> > > + msleep(20);
> >
> > Why sleep here? It looks like a recovery but could 20ms recovery
> > something? I think warning message is enough because you see the warning
> > message, and you fix the bug, so no need to recovery anything.
>
> My purpose is context switch to finish timer's work.
> I will replace it by schedule().
>
> > > + }
> > > +
> > > + clk_unprepare(cmdq->clock);
> > > + return 0;
> > > +}
> > > +
> >
> > Regards,
> > CK
>
> Thanks,
> HS
>
>
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
Hi CK,
Please see my inline reply.
On Fri, 2016-09-30 at 11:06 +0800, CK Hu wrote:
> Hi, HS:
>
> On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > CMDQ is used to help write registers with critical time limitation,
> > such as updating display configuration during the vblank. It controls
> > Global Command Engine (GCE) hardware to achieve this requirement.
> > Currently, CMDQ only supports display related hardwares, but we expect
> > it can be extended to other hardwares for future requirements.
> >
> > Signed-off-by: HS Liao
> > Signed-off-by: CK Hu
> > ---
>
> [snip...]
>
> > +
> > +struct cmdq_task {
> > + struct cmdq *cmdq;
> > + struct list_headlist_entry;
> > + void*va_base;
> > + dma_addr_t pa_base;
> > + size_t cmd_buf_size; /* command occupied size */
> > + size_t buf_size; /* real buffer size */
> > + boolfinalized;
> > + struct cmdq_thread *thread;
>
> I think thread info could be removed from cmdq_task. Only
> cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
> task->thread and caller of both function has the thread info. So you
> could just pass thread info into these two function and remove thread
> info in cmdq_task.
This modification will remove 1 pointer but add 2 pointers. Moreover,
more pointers will need to be delivered between functions for future
extension. IMHO, it would be better to keep thread pointer inside
cmdq_task.
> > + struct cmdq_task_cb cb;
>
> I think this callback function is equal to mailbox client tx_done
> callback. It's better to use already-defined interface rather than
> creating your own.
This is because CMDQ driver allows different callback functions for
different tasks, but mailbox only allows one callback function per
channel. But, I think I can add a wrapper for tx_done to call CMDQ
callback functions. So, I will use tx_done in CMDQ v15.
> > +};
> > +
>
> [snip...]
>
> > +
> > +static int cmdq_suspend(struct device *dev)
> > +{
> > + struct cmdq *cmdq = dev_get_drvdata(dev);
> > + struct cmdq_thread *thread;
> > + int i;
> > + bool task_running = false;
> > +
> > + mutex_lock(&cmdq->task_mutex);
> > + cmdq->suspended = true;
> > + mutex_unlock(&cmdq->task_mutex);
> > +
> > + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> > + thread = &cmdq->thread[i];
> > + if (!list_empty(&thread->task_busy_list)) {
> > + mod_timer(&thread->timeout, jiffies + 1);
> > + task_running = true;
> > + }
> > + }
> > +
> > + if (task_running) {
> > + dev_warn(dev, "exist running task(s) in suspend\n");
> > + msleep(20);
>
> Why sleep here? It looks like a recovery but could 20ms recovery
> something? I think warning message is enough because you see the warning
> message, and you fix the bug, so no need to recovery anything.
My purpose is context switch to finish timer's work.
I will replace it by schedule().
> > + }
> > +
> > + clk_unprepare(cmdq->clock);
> > + return 0;
> > +}
> > +
>
> Regards,
> CK
Thanks,
HS
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Fri, 2016-09-23 at 17:28 +0800, Horng-Shyang Liao wrote:
> Hi Jassi,
>
> Please see my inline reply.
>
> On Thu, 2016-09-22 at 13:47 +0530, Jassi Brar wrote:
> > On Mon, Sep 5, 2016 at 7:14 AM, HS Liao wrote:
> [...]
> > > +struct cmdq_base *cmdq_register_device(struct device *dev)
> > > +{
> > > + struct cmdq_base *cmdq_base;
> > > + struct resource res;
> > > + int subsys;
> > > + u32 base;
> > > +
> > > + if (of_address_to_resource(dev->of_node, 0, &res))
> > > + return NULL;
> > > + base = (u32)res.start;
> > > +
> > > + subsys = cmdq_subsys_base_to_id(base >> 16);
> > > + if (subsys < 0)
> > > + return NULL;
> > > +
> > > + cmdq_base = devm_kmalloc(dev, sizeof(*cmdq_base), GFP_KERNEL);
> > > + if (!cmdq_base)
> > > + return NULL;
> > > + cmdq_base->subsys = subsys;
> > > + cmdq_base->base = base;
> > > +
> > > + return cmdq_base;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_register_device);
> > > +
> > > +struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
> > > +{
> > > + struct cmdq_client *client;
> > > +
> > > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > > + client->client.dev = dev;
> > > + client->client.tx_block = false;
> > > + client->chan = mbox_request_channel(&client->client, index);
> > > + return client;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_mbox_create);
> > > +
> > > +int cmdq_task_create(struct device *dev, struct cmdq_task **task_ptr)
> > > +{
> > > + struct cmdq_task *task;
> > > + int err;
> > > +
> > > + task = kzalloc(sizeof(*task), GFP_KERNEL);
> > > + if (!task)
> > > + return -ENOMEM;
> > > + task->cmdq = dev_get_drvdata(dev);
> > > + err = cmdq_task_realloc_cmd_buffer(task, PAGE_SIZE);
> > > + if (err < 0) {
> > > + kfree(task);
> > > + return err;
> > > + }
> > > + *task_ptr = task;
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_create);
> > > +
> > > +static int cmdq_task_append_command(struct cmdq_task *task, enum
> > > cmdq_code code,
> > > + u32 arg_a, u32 arg_b)
> > > +{
> > > + u64 *cmd_ptr;
> > > + int err;
> > > +
> > > + if (WARN_ON(task->finalized))
> > > + return -EBUSY;
> > > + if (unlikely(task->cmd_buf_size + CMDQ_INST_SIZE >
> > > task->buf_size)) {
> > > + err = cmdq_task_realloc_cmd_buffer(task, task->buf_size *
> > > 2);
> > > + if (err < 0)
> > > + return err;
> > > + }
> > > + cmd_ptr = task->va_base + task->cmd_buf_size;
> > > + (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 |
> > > arg_b;
> > > + task->cmd_buf_size += CMDQ_INST_SIZE;
> > > + return 0;
> > > +}
> > > +
> > > +int cmdq_task_write(struct cmdq_task *task, u32 value, struct cmdq_base
> > > *base,
> > > + u32 offset)
> > > +{
> > > + u32 arg_a = ((base->base + offset) & CMDQ_ARG_A_WRITE_MASK) |
> > > + (base->subsys << CMDQ_SUBSYS_SHIFT);
> > > + return cmdq_task_append_command(task, CMDQ_CODE_WRITE, arg_a,
> > > value);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_write);
> > > +
> > > +int cmdq_task_write_mask(struct cmdq_task *task, u32 value,
> > > +struct cmdq_base *base, u32 offset, u32 mask)
> > > +{
> > > + u32 offset_mask = offset;
> > > + int err;
> > > +
> > > + if (mask != 0x) {
> > > + err = cmdq_task_append_command(task, CMDQ_CODE_MASK, 0,
> > > ~mask);
> > > + if (err < 0)
> > > + return err;
> > > + offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> > > + }
> > > + return cmdq_task_write(task, value, base, offset_mask);
> > > +}
> > > +EXPORT_SYMBOL(cmdq_task_write_mask);
> > > +
> > > +static const u32 cmdq_event_value[CMDQ_MAX_EVENT] = {
> > > + /* Display start of frame(SOF) events */
> > > + [CMDQ_EVENT_DISP_OVL0_SOF] = 11,
> > > + [CMDQ_EVENT_DISP_OVL1_SOF] = 12,
> > > + [CMDQ_EVENT_DISP_RDMA0_SOF] = 13,
> > > + [CMDQ_EVENT_DISP_RDMA1_SOF] = 14,
> > > + [CMDQ_EVENT_DISP_RDMA2_SOF] = 15,
> > > + [CMDQ_EVENT_DISP_WDMA0_SOF] = 16,
> > > + [CMDQ_EVENT_DISP_WDMA1_SOF] = 17,
> > > + /* Display end of frame(EOF) events */
> > > + [CMDQ_EVENT_DISP_OVL0_EOF] = 39,
> > > + [CMDQ_EVENT_DISP_OVL1_EOF] = 40,
> > > + [CMDQ_EVENT_DISP_RDMA0_EOF] = 41,
> > > + [CMDQ_EVENT_DISP_RDMA1_EOF] = 42,
> > > + [CMDQ_EVENT_DISP_RDMA2_EOF] = 43,
> > > + [CMDQ_EVENT_DISP_WDMA0_EOF] = 44,
> > > + [CMDQ_EVENT_DISP_WDMA1_EOF] = 45,
> > > + /* Mutex end of frame(EOF) events */
> > > + [CMDQ_EVENT_MUTEX0_STREAM_EOF] = 53,
> > > + [CMDQ_EVENT_MUTEX1_STREAM_EOF] = 54,
> > > + [CM
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
Hi, HS:
On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> CMDQ is used to help write registers with critical time limitation,
> such as updating display configuration during the vblank. It controls
> Global Command Engine (GCE) hardware to achieve this requirement.
> Currently, CMDQ only supports display related hardwares, but we expect
> it can be extended to other hardwares for future requirements.
>
> Signed-off-by: HS Liao
> Signed-off-by: CK Hu
> ---
[snip...]
> +
> +struct cmdq_task {
> + struct cmdq *cmdq;
> + struct list_headlist_entry;
> + void*va_base;
> + dma_addr_t pa_base;
> + size_t cmd_buf_size; /* command occupied size */
> + size_t buf_size; /* real buffer size */
> + boolfinalized;
> + struct cmdq_thread *thread;
I think thread info could be removed from cmdq_task. Only
cmdq_task_handle_error() and cmdq_task_insert_into_thread() use
task->thread and caller of both function has the thread info. So you
could just pass thread info into these two function and remove thread
info in cmdq_task.
> + struct cmdq_task_cb cb;
I think this callback function is equal to mailbox client tx_done
callback. It's better to use already-defined interface rather than
creating your own.
> +};
> +
[snip...]
> +
> +static int cmdq_suspend(struct device *dev)
> +{
> + struct cmdq *cmdq = dev_get_drvdata(dev);
> + struct cmdq_thread *thread;
> + int i;
> + bool task_running = false;
> +
> + mutex_lock(&cmdq->task_mutex);
> + cmdq->suspended = true;
> + mutex_unlock(&cmdq->task_mutex);
> +
> + for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> + thread = &cmdq->thread[i];
> + if (!list_empty(&thread->task_busy_list)) {
> + mod_timer(&thread->timeout, jiffies + 1);
> + task_running = true;
> + }
> + }
> +
> + if (task_running) {
> + dev_warn(dev, "exist running task(s) in suspend\n");
> + msleep(20);
Why sleep here? It looks like a recovery but could 20ms recovery
something? I think warning message is enough because you see the warning
message, and you fix the bug, so no need to recovery anything.
> + }
> +
> + clk_unprepare(cmdq->clock);
> + return 0;
> +}
> +
Regards,
CK
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
Hi Jassi,
Please see my inline reply.
On Thu, 2016-09-22 at 13:47 +0530, Jassi Brar wrote:
> On Mon, Sep 5, 2016 at 7:14 AM, HS Liao wrote:
[...]
> > +struct cmdq_base *cmdq_register_device(struct device *dev)
> > +{
> > + struct cmdq_base *cmdq_base;
> > + struct resource res;
> > + int subsys;
> > + u32 base;
> > +
> > + if (of_address_to_resource(dev->of_node, 0, &res))
> > + return NULL;
> > + base = (u32)res.start;
> > +
> > + subsys = cmdq_subsys_base_to_id(base >> 16);
> > + if (subsys < 0)
> > + return NULL;
> > +
> > + cmdq_base = devm_kmalloc(dev, sizeof(*cmdq_base), GFP_KERNEL);
> > + if (!cmdq_base)
> > + return NULL;
> > + cmdq_base->subsys = subsys;
> > + cmdq_base->base = base;
> > +
> > + return cmdq_base;
> > +}
> > +EXPORT_SYMBOL(cmdq_register_device);
> > +
> > +struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
> > +{
> > + struct cmdq_client *client;
> > +
> > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > + client->client.dev = dev;
> > + client->client.tx_block = false;
> > + client->chan = mbox_request_channel(&client->client, index);
> > + return client;
> > +}
> > +EXPORT_SYMBOL(cmdq_mbox_create);
> > +
> > +int cmdq_task_create(struct device *dev, struct cmdq_task **task_ptr)
> > +{
> > + struct cmdq_task *task;
> > + int err;
> > +
> > + task = kzalloc(sizeof(*task), GFP_KERNEL);
> > + if (!task)
> > + return -ENOMEM;
> > + task->cmdq = dev_get_drvdata(dev);
> > + err = cmdq_task_realloc_cmd_buffer(task, PAGE_SIZE);
> > + if (err < 0) {
> > + kfree(task);
> > + return err;
> > + }
> > + *task_ptr = task;
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_task_create);
> > +
> > +static int cmdq_task_append_command(struct cmdq_task *task, enum cmdq_code
> > code,
> > + u32 arg_a, u32 arg_b)
> > +{
> > + u64 *cmd_ptr;
> > + int err;
> > +
> > + if (WARN_ON(task->finalized))
> > + return -EBUSY;
> > + if (unlikely(task->cmd_buf_size + CMDQ_INST_SIZE > task->buf_size))
> > {
> > + err = cmdq_task_realloc_cmd_buffer(task, task->buf_size *
> > 2);
> > + if (err < 0)
> > + return err;
> > + }
> > + cmd_ptr = task->va_base + task->cmd_buf_size;
> > + (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 |
> > arg_b;
> > + task->cmd_buf_size += CMDQ_INST_SIZE;
> > + return 0;
> > +}
> > +
> > +int cmdq_task_write(struct cmdq_task *task, u32 value, struct cmdq_base
> > *base,
> > + u32 offset)
> > +{
> > + u32 arg_a = ((base->base + offset) & CMDQ_ARG_A_WRITE_MASK) |
> > + (base->subsys << CMDQ_SUBSYS_SHIFT);
> > + return cmdq_task_append_command(task, CMDQ_CODE_WRITE, arg_a,
> > value);
> > +}
> > +EXPORT_SYMBOL(cmdq_task_write);
> > +
> > +int cmdq_task_write_mask(struct cmdq_task *task, u32 value,
> > +struct cmdq_base *base, u32 offset, u32 mask)
> > +{
> > + u32 offset_mask = offset;
> > + int err;
> > +
> > + if (mask != 0x) {
> > + err = cmdq_task_append_command(task, CMDQ_CODE_MASK, 0,
> > ~mask);
> > + if (err < 0)
> > + return err;
> > + offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> > + }
> > + return cmdq_task_write(task, value, base, offset_mask);
> > +}
> > +EXPORT_SYMBOL(cmdq_task_write_mask);
> > +
> > +static const u32 cmdq_event_value[CMDQ_MAX_EVENT] = {
> > + /* Display start of frame(SOF) events */
> > + [CMDQ_EVENT_DISP_OVL0_SOF] = 11,
> > + [CMDQ_EVENT_DISP_OVL1_SOF] = 12,
> > + [CMDQ_EVENT_DISP_RDMA0_SOF] = 13,
> > + [CMDQ_EVENT_DISP_RDMA1_SOF] = 14,
> > + [CMDQ_EVENT_DISP_RDMA2_SOF] = 15,
> > + [CMDQ_EVENT_DISP_WDMA0_SOF] = 16,
> > + [CMDQ_EVENT_DISP_WDMA1_SOF] = 17,
> > + /* Display end of frame(EOF) events */
> > + [CMDQ_EVENT_DISP_OVL0_EOF] = 39,
> > + [CMDQ_EVENT_DISP_OVL1_EOF] = 40,
> > + [CMDQ_EVENT_DISP_RDMA0_EOF] = 41,
> > + [CMDQ_EVENT_DISP_RDMA1_EOF] = 42,
> > + [CMDQ_EVENT_DISP_RDMA2_EOF] = 43,
> > + [CMDQ_EVENT_DISP_WDMA0_EOF] = 44,
> > + [CMDQ_EVENT_DISP_WDMA1_EOF] = 45,
> > + /* Mutex end of frame(EOF) events */
> > + [CMDQ_EVENT_MUTEX0_STREAM_EOF] = 53,
> > + [CMDQ_EVENT_MUTEX1_STREAM_EOF] = 54,
> > + [CMDQ_EVENT_MUTEX2_STREAM_EOF] = 55,
> > + [CMDQ_EVENT_MUTEX3_STREAM_EOF] = 56,
> > + [CMDQ_EVENT_MUTEX4_STREAM_EOF] = 57,
> > + /* Display underrun events */
> > + [CMDQ_EVENT_DISP_RDMA0_UNDERRUN] = 63,
> > + [CMDQ_EVENT_DISP_RDMA1_UNDERRUN] = 64,
> > + [CMDQ_EVENT_DISP_RDMA2_UNDERRUN] = 65,
> >
Re: [PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
On Mon, Sep 5, 2016 at 7:14 AM, HS Liao wrote: > This patch is first version of Mediatek Command Queue(CMDQ) driver. The > CMDQ is used to help write registers with critical time limitation, > such as updating display configuration during the vblank. It controls > Global Command Engine (GCE) hardware to achieve this requirement. > Currently, CMDQ only supports display related hardwares, but we expect > it can be extended to other hardwares for future requirements. > > Signed-off-by: HS Liao > Signed-off-by: CK Hu > --- > drivers/mailbox/Kconfig | 10 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/mtk-cmdq.c | 927 > +++ > include/linux/mailbox/mtk-cmdq.h | 180 > 4 files changed, 1119 insertions(+) > create mode 100644 drivers/mailbox/mtk-cmdq.c > create mode 100644 include/linux/mailbox/mtk-cmdq.h > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig > index 97c3729..c987382 100644 > --- a/drivers/mailbox/Kconfig > +++ b/drivers/mailbox/Kconfig > @@ -132,4 +132,14 @@ config BCM_PDC_MBOX > Mailbox implementation for the Broadcom PDC ring manager, > which provides access to various offload engines on Broadcom > SoCs. Say Y here if you want to use the Broadcom PDC. > + > +config MTK_CMDQ > + bool "MediaTek CMDQ Support" > + depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST ) > + select MTK_INFRACFG > + help > + Say yes here to add support for the MediaTek Command Queue (CMDQ) > + driver. The CMDQ is used to help read/write registers with critical > + time limitation, such as updating display configuration during the > + vblank. > endif > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile > index 66c38e3..eb5e04e 100644 > --- a/drivers/mailbox/Makefile > +++ b/drivers/mailbox/Makefile > @@ -27,3 +27,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o > obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o > > obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o > + > +obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o > diff --git a/drivers/mailbox/mtk-cmdq.c b/drivers/mailbox/mtk-cmdq.c > new file mode 100644 > index 000..daf5561 > --- /dev/null > +++ b/drivers/mailbox/mtk-cmdq.c > @@ -0,0 +1,927 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */ > +#define CMDQ_INST_SIZE 8 /* instruction is 64-bit */ > +#define CMDQ_TIMEOUT_MS1000 > +#define CMDQ_IRQ_MASK 0x > +#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / > CMDQ_INST_SIZE) > + > +#define CMDQ_CURR_IRQ_STATUS 0x10 > +#define CMDQ_THR_SLOT_CYCLES 0x30 > + > +#define CMDQ_THR_BASE 0x100 > +#define CMDQ_THR_SIZE 0x80 > +#define CMDQ_THR_WARM_RESET0x00 > +#define CMDQ_THR_ENABLE_TASK 0x04 > +#define CMDQ_THR_SUSPEND_TASK 0x08 > +#define CMDQ_THR_CURR_STATUS 0x0c > +#define CMDQ_THR_IRQ_STATUS0x10 > +#define CMDQ_THR_IRQ_ENABLE0x14 > +#define CMDQ_THR_CURR_ADDR 0x20 > +#define CMDQ_THR_END_ADDR 0x24 > +#define CMDQ_THR_WAIT_TOKEN0x30 > + > +#define CMDQ_THR_ENABLED 0x1 > +#define CMDQ_THR_DISABLED 0x0 > +#define CMDQ_THR_SUSPEND 0x1 > +#define CMDQ_THR_RESUME0x0 > +#define CMDQ_THR_STATUS_SUSPENDED BIT(1) > +#define CMDQ_THR_DO_WARM_RESET BIT(0) > +#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200 > +#define CMDQ_THR_IRQ_DONE 0x1 > +#define CMDQ_THR_IRQ_ERROR 0x12 > +#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | > CMDQ_THR_IRQ_DONE) > +#define CMDQ_THR_IS_WAITINGBIT(31) > + > +#define CMDQ_OP_CODE_SHIFT 24 > +#define CMDQ_SUBSYS_SHIFT 16 > + > +#define CMDQ_ARG_A_WRITE_MASK 0x > +#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT) > + > +#define CMDQ_WRITE_ENABLE_MASK BIT(0) > +#define CMDQ_JUMP_BY_OFFSET0x1000 > +#define CMDQ_JUMP_BY_PA
[PATCH v14 2/4] CMDQ: Mediatek CMDQ driver
This patch is first version of Mediatek Command Queue(CMDQ) driver. The CMDQ is used to help write registers with critical time limitation, such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement. Currently, CMDQ only supports display related hardwares, but we expect it can be extended to other hardwares for future requirements. Signed-off-by: HS Liao Signed-off-by: CK Hu --- drivers/mailbox/Kconfig | 10 + drivers/mailbox/Makefile | 2 + drivers/mailbox/mtk-cmdq.c | 927 +++ include/linux/mailbox/mtk-cmdq.h | 180 4 files changed, 1119 insertions(+) create mode 100644 drivers/mailbox/mtk-cmdq.c create mode 100644 include/linux/mailbox/mtk-cmdq.h diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index 97c3729..c987382 100644 --- a/drivers/mailbox/Kconfig +++ b/drivers/mailbox/Kconfig @@ -132,4 +132,14 @@ config BCM_PDC_MBOX Mailbox implementation for the Broadcom PDC ring manager, which provides access to various offload engines on Broadcom SoCs. Say Y here if you want to use the Broadcom PDC. + +config MTK_CMDQ + bool "MediaTek CMDQ Support" + depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST ) + select MTK_INFRACFG + help + Say yes here to add support for the MediaTek Command Queue (CMDQ) + driver. The CMDQ is used to help read/write registers with critical + time limitation, such as updating display configuration during the + vblank. endif diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index 66c38e3..eb5e04e 100644 --- a/drivers/mailbox/Makefile +++ b/drivers/mailbox/Makefile @@ -27,3 +27,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o + +obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq.o diff --git a/drivers/mailbox/mtk-cmdq.c b/drivers/mailbox/mtk-cmdq.c new file mode 100644 index 000..daf5561 --- /dev/null +++ b/drivers/mailbox/mtk-cmdq.c @@ -0,0 +1,927 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define CMDQ_THR_MAX_COUNT 3 /* main, sub, general(misc) */ +#define CMDQ_INST_SIZE 8 /* instruction is 64-bit */ +#define CMDQ_TIMEOUT_MS1000 +#define CMDQ_IRQ_MASK 0x +#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / CMDQ_INST_SIZE) + +#define CMDQ_CURR_IRQ_STATUS 0x10 +#define CMDQ_THR_SLOT_CYCLES 0x30 + +#define CMDQ_THR_BASE 0x100 +#define CMDQ_THR_SIZE 0x80 +#define CMDQ_THR_WARM_RESET0x00 +#define CMDQ_THR_ENABLE_TASK 0x04 +#define CMDQ_THR_SUSPEND_TASK 0x08 +#define CMDQ_THR_CURR_STATUS 0x0c +#define CMDQ_THR_IRQ_STATUS0x10 +#define CMDQ_THR_IRQ_ENABLE0x14 +#define CMDQ_THR_CURR_ADDR 0x20 +#define CMDQ_THR_END_ADDR 0x24 +#define CMDQ_THR_WAIT_TOKEN0x30 + +#define CMDQ_THR_ENABLED 0x1 +#define CMDQ_THR_DISABLED 0x0 +#define CMDQ_THR_SUSPEND 0x1 +#define CMDQ_THR_RESUME0x0 +#define CMDQ_THR_STATUS_SUSPENDED BIT(1) +#define CMDQ_THR_DO_WARM_RESET BIT(0) +#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200 +#define CMDQ_THR_IRQ_DONE 0x1 +#define CMDQ_THR_IRQ_ERROR 0x12 +#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | CMDQ_THR_IRQ_DONE) +#define CMDQ_THR_IS_WAITINGBIT(31) + +#define CMDQ_OP_CODE_SHIFT 24 +#define CMDQ_SUBSYS_SHIFT 16 + +#define CMDQ_ARG_A_WRITE_MASK 0x +#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT) + +#define CMDQ_WRITE_ENABLE_MASK BIT(0) +#define CMDQ_JUMP_BY_OFFSET0x1000 +#define CMDQ_JUMP_BY_PA0x1001 +#define CMDQ_JUMP_PASS CMDQ_INST_SIZE +#define CMDQ_WFE_UPDATEBIT(31) +#define CMDQ_WFE_WAIT BIT(15) +#define CMDQ_WFE_WAIT_VALUE0x1 +#define CMDQ_EOC_IRQ_ENBIT(0) + +/* + * CMDQ_CO
