Message-ID: <20140210171706.GR1706@sonymobile.com>
Date:	Mon, 10 Feb 2014 09:17:06 -0800
From:	Courtney Cavin <courtney.cavin@...ymobile.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	"s-anna@...com" <s-anna@...com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
	"mark.langsdorf@...xeda.com" <mark.langsdorf@...xeda.com>,
	"tony@...mide.com" <tony@...mide.com>,
	"omar.ramirez@...itl.com" <omar.ramirez@...itl.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"rob@...dley.net" <rob@...dley.net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/6] mailbox: add core framework

On Mon, Feb 10, 2014 at 03:11:00PM +0100, Arnd Bergmann wrote:
> On Friday 07 February 2014 16:50:14 Courtney Cavin wrote:
> > The mailbox drivers are fragmented, and some implement their own core.
> > Unify the drivers and implement common functionality in a framework.
> > 
> > Signed-off-by: Courtney Cavin <courtney.cavin@...ymobile.com>
> 
> This seems pretty cool overall, great to see someone getting at it@

I'm glad to hear that there's some interest!

> > +static void of_mbox_adapter_add(struct mbox_adapter *adap)
> > +{
> > +	if (!adap->dev)
> > +		return;
> > +
> > +	if (!adap->of_xlate) {
> > +		adap->of_xlate = of_mbox_simple_xlate;
> > +		adap->of_n_cells = 1;
> > +	}
> > +
> > +	of_node_get(adap->dev->of_node);
> > +}
> 
> You should probably check if of_n_cells matches the device node
> #mbox-cells value, otherwise the xlate function will get confused.

Ok.  I was under the impression that the adapter implementations would
add something like that, but I see no reason why putting it here would
hurt.

> > +
> > +	mutex_lock(&mbox_lock);
> > +	list_add(&adap->list, &mbox_adapters);
> > +
> > +	of_mbox_adapter_add(adap);
> > +	mutex_unlock(&mbox_lock);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(mbox_adapter_add);
> 
> Please use EXPORT_SYMBOL_GPL here and elsewhere.

Ok.

> > +/**
> > + * mbox_channel_notify() - notify the core that a channel has a message
> > + * @chan: the channel which has data
> > + * @data: the location of said data
> > + * @len: the length of specified data
> > + *
> > + * This function may be called from interrupt/no-sleep context.
> > + */
> > +int mbox_channel_notify(struct mbox_channel *chan,
> > +		const void *data, unsigned int len)
> > +{
> > +	return atomic_notifier_call_chain(&chan->notifier, len, (void *)data);
> > +}
> > +EXPORT_SYMBOL(mbox_channel_notify);
> 
> What is the reason to use a notifier chain here? Isn't a simple
> callback function pointer enough? I would expect that each mailbox
> can have exactly one consumer, not multiple ones.

Mostly because I didn't see a reason not to.  While a callback function
(and private data) would probably be sufficient, I don't see a specific
reason why a mailbox cannot have multiple consumers, and the API
currently is designed around that concept.

> > +/**
> > + * mbox_add_table() - add a lookup table for adapter consumers
> > + * @table: array of consumers to register
> > + * @num: number of consumers in array
> > + */
> > +void __init mbox_add_table(struct mbox_lookup *table, unsigned int num)
> > +{
> > +	mutex_lock(&mbox_lookup_lock);
> > +	while (num--) {
> > +		if (table->provider && (table->dev_id || table->con_id))
> > +			list_add_tail(&table->list, &mbox_lookup_list);
> > +		table++;
> > +	}
> > +	mutex_unlock(&mbox_lookup_lock);
> > +}
> > +EXPORT_SYMBOL(mbox_add_table);
> 
> I don't understand this part of the API. Why do you need a separate
> lookup table here? Isn't that what the DT lookup does already?

It is.  The lookup/table stuff here is specifically for non-DT-based
mailboxes.

> > +/**
> > + * mbox_request() - lookup and request a MBOX channel
> > + * @dev: device for channel consumer
> > + * @con_id: consumer name
> > + * @nb: notifier block used for receiving messages
> > + *
> > + * The notifier is called as atomic on new messages, so you may not sleep
> > + * in the notifier callback function.
> > + */
> > +struct mbox *mbox_request(struct device *dev, const char *con_id,
> > +		struct notifier_block *nb)
> > +{
> > +	struct mbox_adapter *adap;
> > +	struct mbox_channel *chan;
> > +	struct mbox *mbox;
> > +	int index = 0;
> > +
> > +	if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> > +		return of_mbox_request(dev->of_node, con_id, nb);
> 
> What use case do you have in mind for !CONFIG_OF?

None particularly, except for the existing implementations in
drivers/mailbox.  I simply presumed it wouldn't hurt to implement lookup
tables similar to those the pwm core.

> > +/**
> > + * struct mbox_adapter_ops - MBOX adapter operations
> > + * @put_message: hook for putting messages in the channels MBOX
> > + * @request: optional hook for requesting an MBOX channel
> > + * @release: optional hook for releasing an MBOX channel
> > + * @owner: helps prevent removal of modules exporting active MBOX channels
> > + */
> > +struct mbox_adapter_ops {
> > +	int (*put_message)(struct mbox_adapter *, struct mbox_channel *,
> > +				const void *, unsigned int);
> > +	int (*request)(struct mbox_adapter *, struct mbox_channel *);
> > +	int (*release)(struct mbox_adapter *, struct mbox_channel *);
> > +	struct module *owner;
> > +};
> 
> I think we will need a peek_message() callback for the upcoming
> QMTM driver, to allow client drivers to get a message out before
> the mailbox driver gets an IRQ. This will be used for IRQ mitigation
> in the network driver.

Eeek!  I'm not very fond of 'peek' functions, but I guess I can see a
reason for IRQ mitigation here.  I still cannot help but to try to think
my way out of implementing peek.

What would be the callback flow here?  There's no guarantee that a
mailbox implementation isn't implemented over a sleepy bus, which would
render peek somewhat useless.  Additionally, we have the adapter
protection mutex which can sleep anyway.  This means that a consumer can
not call peek from anywhere atomic, including a notifier, which I think
is your use-case.

Perhaps a FEED_ME return from a notifier, requesting more 'mail' if
available?

> 
> 	Arnd

Thanks for looking!  I appreciate the feedback.

-Courtney
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists