Re: [PATCH 1/3] soc: qcom: Introduce Protection Domain Restart helpers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-11-20 04:47, Bjorn Andersson wrote:
On Tue 19 Nov 02:18 PST 2019, sibis@xxxxxxxxxxxxxx wrote:

Hey Bjorn,
Thanks for taking the time to
review the series :)

On 2019-11-19 12:10, Bjorn Andersson wrote:
> On Mon 18 Nov 06:27 PST 2019, Sibi Sankar wrote:
> > diff --git a/drivers/soc/qcom/pdr_interface.c
> > b/drivers/soc/qcom/pdr_interface.c
> [..]
> > +static void pdr_indack_work(struct work_struct *work)
> > +{
> > +	struct pdr_handle *pdr = container_of(work, struct pdr_handle,
> > +					      indack_work);
> > +	struct pdr_list_node *ind, *tmp;
> > +	struct pdr_service *pds;
> > +
> > +	list_for_each_entry_safe(ind, tmp, &pdr->indack_list, node) {
> > +		pds = ind->pds;
> > +		pdr_send_indack_msg(pdr, pds, ind->transaction_id);
>
> So when we et a ind_cb with the new status, we need to send an ack
> request, which will result in a response, just to confirm that we got
> the event?
>
> Seems like we should fix the qmi code to make it possible to send a
> request from the indication handler and then we could simply ignore the

yeah maybe having a provision to send custom requests back on
indication would be the way to go. Not all indication need to be
services with requests.


Let's put this on the todo list.

> response. Or do we need to not pdr->status() until we get the response
> for some reason?

adsp waits on the ack response for a fixed duration and seems to throw
a fatal err is the ack is not serviced. Hence holding back pd->status
till we service the ack here.


You mean to ensure that someone sleeping in pd->status() doesn't delay
that until its too late?

yes


[..]
> > +int pdr_handle_init(struct pdr_handle *pdr,
> > +		    int (*status)(struct pdr_handle *pdr,
> > +				  struct pdr_service *pds))
> > +{
> [..]
> > +	pdr->servreg_wq = create_singlethread_workqueue("pdr_servreg_wq");
> > +	if (!pdr->servreg_wq)
> > +		return -ENOMEM;
> > +
> > +	pdr->indack_wq = alloc_ordered_workqueue("pdr_indack_wq",
> > WQ_HIGHPRI);
>
> The two workqueues means that we should be able to call pdr->status()
> rom two concurrent contexts, I don't think our clients will expect that.
>

would creating another ordered wq to relay all the pd->status make
sense?


I would prefer less work queues ;) But I presume you split out the
indack_wq in order to improve the likelihood of meeting the latency
requirements of the remote side.

Perhaps just wrap the status() calls with a status-mutex and then remove
that by reworking the QMI interface to allow us to remove the indack
work?

okay will fix it in the next
re-spin.


Regards,
Bjorn

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux