Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Quoting Bjorn Andersson (2019-05-23 12:09:25) > > I had to read through the clock code to conclude that this was indeed > the design, so I'm happy with your patch of ensuring that this is > followed. Perhaps add a statement in the kerneldoc for struct clk_hw as > well to state that init won't be accessed past the return of > clk_register. > I noticed that I had a branch for this that didn't go away this rebase. I've thrown this on my todo list now. I added the comment to the code, but I'm afraid I can't just merge this patch to clk-next yet because various drivers access hw->init after calling clk_register() and friends. I'll have to go through and find the users by looking at git grep '->init' -- drivers/clk/ results. This is a pain.
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
On Sat 25 May 10:53 PDT 2019, Sai Prakash Ranjan wrote: > On 5/1/2019 10:07 AM, Bjorn Andersson wrote: > > The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver > > is used to communicate with the AOSS for certain side-channel requests, > > that are not available through the RPMh interface. > > > > The communication is a very simple synchronous mechanism of messages > > being written in message RAM and a doorbell in the AOSS is rung. As the > > AOSS has processed the message length is cleared and an interrupt is > > fired by the AOSS as acknowledgment. > > > > The driver exposes the QDSS clock as a clock and the low-power state > > associated with the remoteprocs in the system as a set of power-domains. > > > > Signed-off-by: Bjorn Andersson > > --- > > > > Changes since v6: > > - Squash the pd into the same driver as the communication, to simplify > >the interaction. > > - Representing the QDSS clocks as a clock/power domain turns out to > >cascade into a request to make all Coresight drivers have a secondary > >compatible to replace the required bus clock with a required power > >domain. So in v7 this is exposed as a clock instead. > > - Some error checking updates, as reported by Doug. > > > > Thanks for the patch Bjorn. > Tested the QDSS functionality on SDM845 based Cheza board with this > change and it works just fine. > > Tested-by: Sai Prakash Ranjan Thanks for the confirmation Sai! Regards, Bjorn
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
On 5/1/2019 10:07 AM, Bjorn Andersson wrote: The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver is used to communicate with the AOSS for certain side-channel requests, that are not available through the RPMh interface. The communication is a very simple synchronous mechanism of messages being written in message RAM and a doorbell in the AOSS is rung. As the AOSS has processed the message length is cleared and an interrupt is fired by the AOSS as acknowledgment. The driver exposes the QDSS clock as a clock and the low-power state associated with the remoteprocs in the system as a set of power-domains. Signed-off-by: Bjorn Andersson --- Changes since v6: - Squash the pd into the same driver as the communication, to simplify the interaction. - Representing the QDSS clocks as a clock/power domain turns out to cascade into a request to make all Coresight drivers have a secondary compatible to replace the required bus clock with a required power domain. So in v7 this is exposed as a clock instead. - Some error checking updates, as reported by Doug. Thanks for the patch Bjorn. Tested the QDSS functionality on SDM845 based Cheza board with this change and it works just fine. Tested-by: Sai Prakash Ranjan -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
On Thu 23 May 11:05 PDT 2019, Stephen Boyd wrote:
> Quoting Doug Anderson (2019-05-23 09:38:13)
> > Hi,
> >
> > On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> > wrote:
> >
> > > +static int qmp_qdss_clk_add(struct qmp *qmp)
> > > +{
> > > + struct clk_init_data qdss_init = {
> > > + .ops = _qdss_clk_ops,
> > > + .name = "qdss",
> > > + };
> >
> > Can't qdss_init be "static const"? That had the advantage of not
> > needing to construct it on the stack and also of it having a longer
> > lifetime. It looks like clk_register() stores the "hw" pointer in its
> > structure and the "hw" structure will have a pointer here. While I
> > can believe that it never looks at it again, it's nice if that pointer
> > doesn't point somewhere on an old stack.
> >
> > I suppose we could go the other way and try to mark more stuff in this
> > module as __init and __initdata, but even then at least the pointer
> > won't be onto a stack. ;-)
> >
>
> Const would be nice, but otherwise making it static isn't a good idea.
> The clk_init_data structure is all copied over, although we do leave a
> dangling pointer to it stored inside the clk_hw structure we don't use
> it after clk registration. Maybe we should overwrite the pointer with
> NULL once we're done in clk_register() so that clk providers can't use
> it. It might break somebody but would at least clarify this point.
>
I had to read through the clock code to conclude that this was indeed
the design, so I'm happy with your patch of ensuring that this is
followed. Perhaps add a statement in the kerneldoc for struct clk_hw as
well to state that init won't be accessed past the return of
clk_register.
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index aa51756fd4d6..56997a974408 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3438,9 +3438,9 @@ static int clk_cpy_name(const char **dst_p, const char
> *src, bool must_exist)
> return 0;
> }
>
> -static int clk_core_populate_parent_map(struct clk_core *core)
> +static int clk_core_populate_parent_map(struct clk_core *core,
> + const struct clk_init_data *init)
> {
> - const struct clk_init_data *init = core->hw->init;
> u8 num_parents = init->num_parents;
> const char * const *parent_names = init->parent_names;
> const struct clk_hw **parent_hws = init->parent_hws;
> @@ -3520,6 +3520,14 @@ __clk_register(struct device *dev, struct device_node
> *np, struct clk_hw *hw)
> {
> int ret;
> struct clk_core *core;
> + const struct clk_init_data *init = hw->init;
> +
> + /*
> + * The init data is not supposed to be used outside of registration
> path.
> + * Set it to NULL so that provider drivers can't use it either and so
> that
> + * we catch use of hw->init early on in the core.
> + */
> + hw->init = NULL;
>
> core = kzalloc(sizeof(*core), GFP_KERNEL);
> if (!core) {
> @@ -3527,17 +3535,17 @@ __clk_register(struct device *dev, struct device_node
> *np, struct clk_hw *hw)
> goto fail_out;
> }
>
> - core->name = kstrdup_const(hw->init->name, GFP_KERNEL);
> + core->name = kstrdup_const(init->name, GFP_KERNEL);
> if (!core->name) {
> ret = -ENOMEM;
> goto fail_name;
> }
>
> - if (WARN_ON(!hw->init->ops)) {
> + if (WARN_ON(!init->ops)) {
> ret = -EINVAL;
> goto fail_ops;
> }
> - core->ops = hw->init->ops;
> + core->ops = init->ops;
>
> if (dev && pm_runtime_enabled(dev))
> core->rpm_enabled = true;
> @@ -3546,13 +3554,13 @@ __clk_register(struct device *dev, struct device_node
> *np, struct clk_hw *hw)
> if (dev && dev->driver)
> core->owner = dev->driver->owner;
> core->hw = hw;
> - core->flags = hw->init->flags;
> - core->num_parents = hw->init->num_parents;
> + core->flags = init->flags;
> + core->num_parents = init->num_parents;
> core->min_rate = 0;
> core->max_rate = ULONG_MAX;
> hw->core = core;
>
> - ret = clk_core_populate_parent_map(core);
> + ret = clk_core_populate_parent_map(core, init);
> if (ret)
> goto fail_parents;
>
I've reviewed this and it looks good!
Regards,
Bjorn
>
> >
> >
> > > +static void qmp_pd_remove(struct qmp *qmp)
> > > +{
> > > + struct genpd_onecell_data *data = >pd_data;
> > > + struct device *dev = qmp->dev;
> > > + int i;
> > > +
> > > + of_genpd_del_provider(dev->of_node);
> > > +
> > > + for (i = 0; i < data->num_domains; i++)
> > > + pm_genpd_remove(data->domains[i]);
> >
> > Still feels like the above loop would be better as:
> > for (i = data->num_domains - 1; i >= 0; i--)
> >
>
> Reason being to remove in reverse order? Otherwise this looks like an
> opinion.
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
On Thu 23 May 09:38 PDT 2019, Doug Anderson wrote:
> Hi,
>
> On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> wrote:
> >
> > +static int qmp_qdss_clk_prepare(struct clk_hw *hw)
> > +{
> > + struct qmp *qmp = container_of(hw, struct qmp, qdss_clk);
> > + char buf[QMP_MSG_LEN] = "{class: clock, res: qdss, val: 1}";
>
> nit: "static const" the buf? No need to copy it to the stack each
> time. In qmp_qdss_clk_unprepare() too.
>
Thanks, that makes sense.
> ...your string is also now fixed at 34 bytes big (including the '\0').
> Do we still need to send exactly 96 bytes, or can we dumb this down to
> 36? We'll get a compile error if we overflow, right? If this truly
> needs to be exactly 96 bytes maybe qmp_send()'s error checks should
> check for things being exactly 96 bytes instead of checking for > and
> % 4.
>
I double checked with my contacts and the only requirement here is that
memory has to be word-accessed, so I'll figure out a sane way to write
this.
>
> > +static int qmp_qdss_clk_add(struct qmp *qmp)
> > +{
> > + struct clk_init_data qdss_init = {
> > + .ops = _qdss_clk_ops,
> > + .name = "qdss",
> > + };
>
> Can't qdss_init be "static const"? That had the advantage of not
> needing to construct it on the stack and also of it having a longer
> lifetime. It looks like clk_register() stores the "hw" pointer in its
> structure and the "hw" structure will have a pointer here. While I
> can believe that it never looks at it again, it's nice if that pointer
> doesn't point somewhere on an old stack.
>
The purpose here was for clk_hw_register() to consume it and never look
back, but I agree that it's a bit fragile. I'll review Stephen's
proposed patch.
> I suppose we could go the other way and try to mark more stuff in this
> module as __init and __initdata, but even then at least the pointer
> won't be onto a stack. ;-)
>
>
> > + int ret;
> > +
> > + qmp->qdss_clk.init = _init;
> > + ret = clk_hw_register(qmp->dev, >qdss_clk);
> > + if (ret < 0) {
> > + dev_err(qmp->dev, "failed to register qdss clock\n");
> > + return ret;
> > + }
> > +
> > + return of_clk_add_hw_provider(qmp->dev->of_node,
> > of_clk_hw_simple_get,
> > + >qdss_clk);
>
> devm_clk_hw_register() and devm_of_clk_add_hw_provider()? If you're
> worried about ordering you could always throw in
> devm_add_action_or_reset() to handle the qmp_pd_remove(), qmp_close()
> and mbox_free_channel().
>
> ...with that you could fully get rid of qmp_remove() and also your
> setting of drvdata.
>
Yeah, I was worried about qmp_close() before unregistering the clock.
I'll take another look, will at least have to fix the error handling on
of_clk_add_hw_provider()
>
> > +static void qmp_pd_remove(struct qmp *qmp)
> > +{
> > + struct genpd_onecell_data *data = >pd_data;
> > + struct device *dev = qmp->dev;
> > + int i;
> > +
> > + of_genpd_del_provider(dev->of_node);
> > +
> > + for (i = 0; i < data->num_domains; i++)
> > + pm_genpd_remove(data->domains[i]);
>
> Still feels like the above loop would be better as:
> for (i = data->num_domains - 1; i >= 0; i--)
>
To me this carries a message that the removal order is significant,
which I'm unable to convince myself that it is.
>
> (BTW: any way you could add me to the CC list for future patches so I
> notice them earlier?)
>
Yes of course, thanks for your review.
Regards,
Bjorn
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Hi,
On Thu, May 23, 2019 at 11:05 AM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2019-05-23 09:38:13)
> > Hi,
> >
> > On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> > wrote:
> >
> > > +static int qmp_qdss_clk_add(struct qmp *qmp)
> > > +{
> > > + struct clk_init_data qdss_init = {
> > > + .ops = _qdss_clk_ops,
> > > + .name = "qdss",
> > > + };
> >
> > Can't qdss_init be "static const"? That had the advantage of not
> > needing to construct it on the stack and also of it having a longer
> > lifetime. It looks like clk_register() stores the "hw" pointer in its
> > structure and the "hw" structure will have a pointer here. While I
> > can believe that it never looks at it again, it's nice if that pointer
> > doesn't point somewhere on an old stack.
> >
> > I suppose we could go the other way and try to mark more stuff in this
> > module as __init and __initdata, but even then at least the pointer
> > won't be onto a stack. ;-)
> >
>
> Const would be nice, but otherwise making it static isn't a good idea.
Even aside from the whole "not having it store a pointer to the
stack", "static const" is likely to reduce overall memory consumption
/ number of instructions by a tiny bit because we don't need to copy
this structure onto the stack--we can just use it in place.
As written (or by just adding const but not static const): qmp_probe()
is 1840 bytes long.
...and has this snippet:
0xff80084a58d4 <+1152>: adrpx1, 0xff8008a5b000
0xff80084a58d8 <+1156>: add x1, x1, #0x600
0xff80084a58dc <+1160>: add x0, sp, #0x10
0xff80084a58e0 <+1164>: mov w2, #0x28 // #40
0xff80084a58e4 <+1168>: add x22, sp, #0x10
0xff80084a58e8 <+1172>: bl 0xff800896e800
With this as static const: qmp_probe is 1820 bytes long.
...and has this snippet:
0xff80084a58dc <+1160>: adrpx8, 0xff8008a5b000
0xff80084a58e0 <+1164>: add x8, x8, #0x550
> The clk_init_data structure is all copied over, although we do leave a
> dangling pointer to it stored inside the clk_hw structure we don't use
> it after clk registration. Maybe we should overwrite the pointer with
> NULL once we're done in clk_register() so that clk providers can't use
> it. It might break somebody but would at least clarify this point.
Setting it to NULL seems like it would be a good idea. Now that I
think on it I believe I've actually tripped over this before trying to
read the '.name' from here... :-P
> > > +static void qmp_pd_remove(struct qmp *qmp)
> > > +{
> > > + struct genpd_onecell_data *data = >pd_data;
> > > + struct device *dev = qmp->dev;
> > > + int i;
> > > +
> > > + of_genpd_del_provider(dev->of_node);
> > > +
> > > + for (i = 0; i < data->num_domains; i++)
> > > + pm_genpd_remove(data->domains[i]);
> >
> > Still feels like the above loop would be better as:
> > for (i = data->num_domains - 1; i >= 0; i--)
> >
>
> Reason being to remove in reverse order? Otherwise this looks like an
> opinion.
1. Matches the order of the error handling case above (see unroll_genpds label)
2. In general you avoid more unexpected problems by un-initting in the
reverse order you initted.
-Doug
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Quoting Doug Anderson (2019-05-23 09:38:13)
> Hi,
>
> On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> wrote:
>
> > +static int qmp_qdss_clk_add(struct qmp *qmp)
> > +{
> > + struct clk_init_data qdss_init = {
> > + .ops = _qdss_clk_ops,
> > + .name = "qdss",
> > + };
>
> Can't qdss_init be "static const"? That had the advantage of not
> needing to construct it on the stack and also of it having a longer
> lifetime. It looks like clk_register() stores the "hw" pointer in its
> structure and the "hw" structure will have a pointer here. While I
> can believe that it never looks at it again, it's nice if that pointer
> doesn't point somewhere on an old stack.
>
> I suppose we could go the other way and try to mark more stuff in this
> module as __init and __initdata, but even then at least the pointer
> won't be onto a stack. ;-)
>
Const would be nice, but otherwise making it static isn't a good idea.
The clk_init_data structure is all copied over, although we do leave a
dangling pointer to it stored inside the clk_hw structure we don't use
it after clk registration. Maybe we should overwrite the pointer with
NULL once we're done in clk_register() so that clk providers can't use
it. It might break somebody but would at least clarify this point.
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index aa51756fd4d6..56997a974408 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3438,9 +3438,9 @@ static int clk_cpy_name(const char **dst_p, const char
*src, bool must_exist)
return 0;
}
-static int clk_core_populate_parent_map(struct clk_core *core)
+static int clk_core_populate_parent_map(struct clk_core *core,
+ const struct clk_init_data *init)
{
- const struct clk_init_data *init = core->hw->init;
u8 num_parents = init->num_parents;
const char * const *parent_names = init->parent_names;
const struct clk_hw **parent_hws = init->parent_hws;
@@ -3520,6 +3520,14 @@ __clk_register(struct device *dev, struct device_node
*np, struct clk_hw *hw)
{
int ret;
struct clk_core *core;
+ const struct clk_init_data *init = hw->init;
+
+ /*
+* The init data is not supposed to be used outside of registration
path.
+* Set it to NULL so that provider drivers can't use it either and so
that
+* we catch use of hw->init early on in the core.
+*/
+ hw->init = NULL;
core = kzalloc(sizeof(*core), GFP_KERNEL);
if (!core) {
@@ -3527,17 +3535,17 @@ __clk_register(struct device *dev, struct device_node
*np, struct clk_hw *hw)
goto fail_out;
}
- core->name = kstrdup_const(hw->init->name, GFP_KERNEL);
+ core->name = kstrdup_const(init->name, GFP_KERNEL);
if (!core->name) {
ret = -ENOMEM;
goto fail_name;
}
- if (WARN_ON(!hw->init->ops)) {
+ if (WARN_ON(!init->ops)) {
ret = -EINVAL;
goto fail_ops;
}
- core->ops = hw->init->ops;
+ core->ops = init->ops;
if (dev && pm_runtime_enabled(dev))
core->rpm_enabled = true;
@@ -3546,13 +3554,13 @@ __clk_register(struct device *dev, struct device_node
*np, struct clk_hw *hw)
if (dev && dev->driver)
core->owner = dev->driver->owner;
core->hw = hw;
- core->flags = hw->init->flags;
- core->num_parents = hw->init->num_parents;
+ core->flags = init->flags;
+ core->num_parents = init->num_parents;
core->min_rate = 0;
core->max_rate = ULONG_MAX;
hw->core = core;
- ret = clk_core_populate_parent_map(core);
+ ret = clk_core_populate_parent_map(core, init);
if (ret)
goto fail_parents;
>
>
> > +static void qmp_pd_remove(struct qmp *qmp)
> > +{
> > + struct genpd_onecell_data *data = >pd_data;
> > + struct device *dev = qmp->dev;
> > + int i;
> > +
> > + of_genpd_del_provider(dev->of_node);
> > +
> > + for (i = 0; i < data->num_domains; i++)
> > + pm_genpd_remove(data->domains[i]);
>
> Still feels like the above loop would be better as:
> for (i = data->num_domains - 1; i >= 0; i--)
>
Reason being to remove in reverse order? Otherwise this looks like an
opinion.
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Hi,
On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
wrote:
>
> +static int qmp_qdss_clk_prepare(struct clk_hw *hw)
> +{
> + struct qmp *qmp = container_of(hw, struct qmp, qdss_clk);
> + char buf[QMP_MSG_LEN] = "{class: clock, res: qdss, val: 1}";
nit: "static const" the buf? No need to copy it to the stack each
time. In qmp_qdss_clk_unprepare() too.
...your string is also now fixed at 34 bytes big (including the '\0').
Do we still need to send exactly 96 bytes, or can we dumb this down to
36? We'll get a compile error if we overflow, right? If this truly
needs to be exactly 96 bytes maybe qmp_send()'s error checks should
check for things being exactly 96 bytes instead of checking for > and
% 4.
> +static int qmp_qdss_clk_add(struct qmp *qmp)
> +{
> + struct clk_init_data qdss_init = {
> + .ops = _qdss_clk_ops,
> + .name = "qdss",
> + };
Can't qdss_init be "static const"? That had the advantage of not
needing to construct it on the stack and also of it having a longer
lifetime. It looks like clk_register() stores the "hw" pointer in its
structure and the "hw" structure will have a pointer here. While I
can believe that it never looks at it again, it's nice if that pointer
doesn't point somewhere on an old stack.
I suppose we could go the other way and try to mark more stuff in this
module as __init and __initdata, but even then at least the pointer
won't be onto a stack. ;-)
> + int ret;
> +
> + qmp->qdss_clk.init = _init;
> + ret = clk_hw_register(qmp->dev, >qdss_clk);
> + if (ret < 0) {
> + dev_err(qmp->dev, "failed to register qdss clock\n");
> + return ret;
> + }
> +
> + return of_clk_add_hw_provider(qmp->dev->of_node, of_clk_hw_simple_get,
> + >qdss_clk);
devm_clk_hw_register() and devm_of_clk_add_hw_provider()? If you're
worried about ordering you could always throw in
devm_add_action_or_reset() to handle the qmp_pd_remove(), qmp_close()
and mbox_free_channel().
...with that you could fully get rid of qmp_remove() and also your
setting of drvdata.
> +static void qmp_pd_remove(struct qmp *qmp)
> +{
> + struct genpd_onecell_data *data = >pd_data;
> + struct device *dev = qmp->dev;
> + int i;
> +
> + of_genpd_del_provider(dev->of_node);
> +
> + for (i = 0; i < data->num_domains; i++)
> + pm_genpd_remove(data->domains[i]);
Still feels like the above loop would be better as:
for (i = data->num_domains - 1; i >= 0; i--)
(BTW: any way you could add me to the CC list for future patches so I
notice them earlier?)
-Doug
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
On 30-04-19, 21:37, Bjorn Andersson wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
I would have preferred this as first one, but this is fine too :)
> +/* Linux-side offsets */
> +#define QMP_DESC_MCORE_LINK_STATE0x24
> +#define QMP_DESC_MCORE_LINK_STATE_ACK0x28
> +#define QMP_DESC_MCORE_CH_STATE 0x2c
> +#define QMP_DESC_MCORE_CH_STATE_ACK 0x30
> +#define QMP_DESC_MCORE_MBOX_SIZE 0x34
> +#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
> +
> +#define QMP_STATE_UP 0x
I prefer using GENMASK(15, 0)
> +#define QMP_STATE_DOWN 0x
GENMASK(31, 16)?
> +/**
> + * struct qmp - driver state for QMP implementation
> + * @msgram: iomem referencing the message RAM used for communication
> + * @dev: reference to QMP device
> + * @mbox_client: mailbox client used to ring the doorbell on transmit
> + * @mbox_chan: mailbox channel used to ring the doorbell on transmit
> + * @offset: offset within @msgram where messages should be written
> + * @size: maximum size of the messages to be transmitted
> + * @event: wait_queue for synchronization with the IRQ
> + * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
/s/syncrhonization/synchronization
> +int qmp_send(struct qmp *qmp, const void *data, size_t len)
> +{
> + int ret;
> +
> + if (WARN_ON(len + sizeof(u32) > qmp->size))
> + return -EINVAL;
> +
> + if (WARN_ON(len % sizeof(u32)))
> + return -EINVAL;
> +
> + mutex_lock(>tx_lock);
> +
> + /* The message RAM only implements 32-bit accesses */
> + __iowrite32_copy(qmp->msgram + qmp->offset + sizeof(u32),
> + data, len / sizeof(u32));
> + writel(len, qmp->msgram + qmp->offset);
> + qmp_kick(qmp);
> +
> + ret = wait_event_interruptible_timeout(qmp->event,
> +qmp_message_empty(qmp), HZ);
> + if (!ret) {
> + dev_err(qmp->dev, "ucore did not ack channel\n");
> + ret = -ETIMEDOUT;
> +
> + /* Clear message from buffer */
> + writel(0, qmp->msgram + qmp->offset);
> + } else {
> + ret = 0;
Isn't this redundant?
> + }
> +
> + mutex_unlock(>tx_lock);
> +
> + return ret;
> +}
--
~Vinod
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Hi Bjorn,
On 5/1/2019 10:07 AM, Bjorn Andersson wrote:
The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
is used to communicate with the AOSS for certain side-channel requests,
that are not available through the RPMh interface.
The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.
The driver exposes the QDSS clock as a clock and the low-power state
associated with the remoteprocs in the system as a set of power-domains.
Signed-off-by: Bjorn Andersson
---
Changes since v6:
- Squash the pd into the same driver as the communication, to simplify
the interaction.
- Representing the QDSS clocks as a clock/power domain turns out to
cascade into a request to make all Coresight drivers have a secondary
compatible to replace the required bus clock with a required power
domain. So in v7 this is exposed as a clock instead.
- Some error checking updates, as reported by Doug.
drivers/soc/qcom/Kconfig | 11 +
drivers/soc/qcom/Makefile| 1 +
drivers/soc/qcom/qcom_aoss.c | 473 +++
3 files changed, 485 insertions(+)
create mode 100644 drivers/soc/qcom/qcom_aoss.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 1ee298f6bf17..3e460b334b47 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,17 @@
#
menu "Qualcomm SoC drivers"
+config QCOM_AOSS_QMP
+ tristate "Qualcomm AOSS Driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on MAILBOX
+ select PM_GENERIC_DOMAINS
+ help
+ This driver provides the means of communicating with and controlling
+ the low-power state for resources related to the remoteproc
+ subsystems as well as controlling the debug clocks exposed by the
Always On
+ Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
+
config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..eeb088beb15f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) += glink_ssr.o
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
new file mode 100644
index ..f1fc26ab2e36
--- /dev/null
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION 0x4
+#define QMP_DESC_FEATURES 0x8
+
+/* AOP-side offsets */
+#define QMP_DESC_UCORE_LINK_STATE 0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK 0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE 0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+/* Linux-side offsets */
+#define QMP_DESC_MCORE_LINK_STATE 0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK 0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE 0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP 0x
+#define QMP_STATE_DOWN 0x
+
+#define QMP_MAGIC 0x4d41494c
+#define QMP_VERSION1
+
+/* Requests are expected to be 96 bytes long */
+#define QMP_MSG_LEN96
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
+ * @qdss_clk: QDSS clock hw struct
+ * @pd_data: genpd data
+ */
+struct qmp {
+ void __iomem *msgram;
+ struct device *dev;
+
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ size_t offset;
+ size_t size;
+
+ wait_queue_head_t event;
+
+ struct mutex tx_lock;
+
+ struct clk_hw qdss_clk;
+ struct genpd_onecell_data pd_data;
+};
+
+struct qmp_pd {
+ struct qmp *qmp;
+ struct generic_pm_domain pd;
+};
+
+#define
Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
Hey Bjorn,
On 5/1/19 10:07 AM, Bjorn Andersson wrote:
The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
is used to communicate with the AOSS for certain side-channel requests,
that are not available through the RPMh interface.
The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.
The driver exposes the QDSS clock as a clock and the low-power state
associated with the remoteprocs in the system as a set of power-domains.
Signed-off-by: Bjorn Andersson
---
Changes since v6:
- Squash the pd into the same driver as the communication, to simplify
the interaction.
- Representing the QDSS clocks as a clock/power domain turns out to
cascade into a request to make all Coresight drivers have a secondary
compatible to replace the required bus clock with a required power
domain. So in v7 this is exposed as a clock instead.
- Some error checking updates, as reported by Doug.
drivers/soc/qcom/Kconfig | 11 +
drivers/soc/qcom/Makefile| 1 +
drivers/soc/qcom/qcom_aoss.c | 473 +++
3 files changed, 485 insertions(+)
create mode 100644 drivers/soc/qcom/qcom_aoss.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 1ee298f6bf17..3e460b334b47 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,17 @@
#
menu "Qualcomm SoC drivers"
+config QCOM_AOSS_QMP
+ tristate "Qualcomm AOSS Driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on MAILBOX
+ select PM_GENERIC_DOMAINS
+ help
+ This driver provides the means of communicating with and controlling
+ the low-power state for resources related to the remoteproc
+ subsystems as well as controlling the debug clocks exposed by the
Always On
+ Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
+
config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..eeb088beb15f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) += glink_ssr.o
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
new file mode 100644
index ..f1fc26ab2e36
--- /dev/null
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
alphabetical order..
+#include
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION 0x4
+#define QMP_DESC_FEATURES 0x8
+
+/* AOP-side offsets */
+#define QMP_DESC_UCORE_LINK_STATE 0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK 0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE 0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+/* Linux-side offsets */
+#define QMP_DESC_MCORE_LINK_STATE 0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK 0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE 0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP 0x
+#define QMP_STATE_DOWN 0x
+
+#define QMP_MAGIC 0x4d41494c
you may want to mention that the magic stands for MAIL
+#define QMP_VERSION1
+
+/* Requests are expected to be 96 bytes long */
+#define QMP_MSG_LEN96
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
+ * @qdss_clk: QDSS clock hw struct
+ * @pd_data: genpd data
+ */
+struct qmp {
+ void __iomem *msgram;
+ struct device *dev;
+
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ size_t offset;
+ size_t size;
+
+ wait_queue_head_t event;
+
+ struct mutex tx_lock;
+
+ struct clk_hw qdss_clk;
+ struct genpd_onecell_data pd_data;
+};
+
+struct
[PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
is used to communicate with the AOSS for certain side-channel requests,
that are not available through the RPMh interface.
The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.
The driver exposes the QDSS clock as a clock and the low-power state
associated with the remoteprocs in the system as a set of power-domains.
Signed-off-by: Bjorn Andersson
---
Changes since v6:
- Squash the pd into the same driver as the communication, to simplify
the interaction.
- Representing the QDSS clocks as a clock/power domain turns out to
cascade into a request to make all Coresight drivers have a secondary
compatible to replace the required bus clock with a required power
domain. So in v7 this is exposed as a clock instead.
- Some error checking updates, as reported by Doug.
drivers/soc/qcom/Kconfig | 11 +
drivers/soc/qcom/Makefile| 1 +
drivers/soc/qcom/qcom_aoss.c | 473 +++
3 files changed, 485 insertions(+)
create mode 100644 drivers/soc/qcom/qcom_aoss.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 1ee298f6bf17..3e460b334b47 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,17 @@
#
menu "Qualcomm SoC drivers"
+config QCOM_AOSS_QMP
+ tristate "Qualcomm AOSS Driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on MAILBOX
+ select PM_GENERIC_DOMAINS
+ help
+ This driver provides the means of communicating with and controlling
+ the low-power state for resources related to the remoteproc
+ subsystems as well as controlling the debug clocks exposed by the
Always On
+ Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
+
config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..eeb088beb15f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
new file mode 100644
index ..f1fc26ab2e36
--- /dev/null
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -0,0 +1,473 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Linaro Ltd
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION 0x4
+#define QMP_DESC_FEATURES 0x8
+
+/* AOP-side offsets */
+#define QMP_DESC_UCORE_LINK_STATE 0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK 0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE 0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+/* Linux-side offsets */
+#define QMP_DESC_MCORE_LINK_STATE 0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK 0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE 0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP 0x
+#define QMP_STATE_DOWN 0x
+
+#define QMP_MAGIC 0x4d41494c
+#define QMP_VERSION1
+
+/* Requests are expected to be 96 bytes long */
+#define QMP_MSG_LEN96
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
+ * @qdss_clk: QDSS clock hw struct
+ * @pd_data: genpd data
+ */
+struct qmp {
+ void __iomem *msgram;
+ struct device *dev;
+
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ size_t offset;
+ size_t size;
+
+ wait_queue_head_t event;
+
+ struct mutex tx_lock;
+
+ struct clk_hw qdss_clk;
+ struct genpd_onecell_data pd_data;
+};
+
+struct qmp_pd {
+ struct qmp *qmp;
+ struct generic_pm_domain pd;
+};
+
+#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
+
+static void
