Re: [PATCH 1/4] mailbox/omap: store mailbox interrupt type in omap_mbox_device

[Grygorii Strashko]

On 04/07/2016 03:24 PM, Suman Anna wrote:
> Hi Grygorii,
>
> On 04/07/2016 05:32 AM, Grygorii Strashko wrote:
> > On 04/07/2016 02:37 AM, Suman Anna wrote:
> > > The interrupt type used for identifying the layout of the interrupt
> > > configuration registers between OMAP4+ SoCs and older SoCs is stored
> > > only in the sub-mailbox structures for easier access. Store this type
> > > in the the omap_mbox_device structure as well along with the other
> > > global variables. This is being done to facilitate the context save
> > > and restore of appropriate registers during system suspend/resume.
> > >
> > > Signed-off-by: Suman Anna <s-anna@xxxxxx>
> > > ---
> > >    drivers/mailbox/omap-mailbox.c | 2 ++
> > >    1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/mailbox/omap-mailbox.c
> > > b/drivers/mailbox/omap-mailbox.c
> > > index 84cafc02e761..adf37f494690 100644
> > > --- a/drivers/mailbox/omap-mailbox.c
> > > +++ b/drivers/mailbox/omap-mailbox.c
> > > @@ -90,6 +90,7 @@ struct omap_mbox_device {
> > >        void __iomem *mbox_base;
> > >        u32 num_users;
> > >        u32 num_fifos;
> > > +    u32 intr_type;
> > >        struct omap_mbox **mboxes;
> > >        struct mbox_controller controller;
> > >        struct list_head elem;
> > > @@ -828,6 +829,7 @@ static int omap_mbox_probe(struct platform_device
> > > *pdev)
> > >        mdev->dev = &pdev->dev;
> > >        mdev->num_users = num_users;
> > >        mdev->num_fifos = num_fifos;
> > > +    mdev->intr_type = intr_type;
> > >        mdev->mboxes = list;
> > >
> > >        /* OMAP does not have a Tx-Done IRQ, but rather a Tx-Ready IRQ */
> >
> > This smth. which definitely has to be done using compatible props.
> > Why not to pass more info through of_device_id->data?
>
> Yeah, that's already the case, intr_type is a local variable assigned
> from compatible match data. This patch merely caches it in the
> omap_mbox_device structure so that it can be leveraged by the PM
> callback functions in the next patch.

Ah ok. Thanks for explanation.

--
regards,
-grygorii