Hi Subb,
From: "ext C.A, Subramaniam" <subramaniam...@ti.com>
Subject: RE: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to
support OMAP4 mailbox.
Date: Wed, 18 Nov 2009 09:15:42 +0100
[...]
> > > /* SYSCONFIG: register bit definition */
> > > #define AUTOIDLE (1 << 0)
> > > @@ -39,7 +45,11 @@
> > > #define RESETDONE (1 << 0)
> > >
> > > #define MBOX_REG_SIZE 0x120
> > > +
> > > +#define OMAP4_MBOX_REG_SIZE 0x130
> > > +
> > > #define MBOX_NR_REGS (MBOX_REG_SIZE
> > / sizeof(u32))
> > > +#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE /
> > sizeof(u32))
> >
> > Doesn't this modification break other OMAP arch support?
> >
> > We need to support OMAP2/3/4 mailbox with this file.
> >
> > >
> > > static void __iomem *mbox_base;
> > >
> > > @@ -56,7 +66,8 @@ struct omap_mbox2_priv {
> > > unsigned long irqstatus;
> > > u32 newmsg_bit;
> > > u32 notfull_bit;
> > > - u32 ctx[MBOX_NR_REGS];
> > > + u32 ctx[OMAP4_MBOX_REG_SIZE];
>
> This reserves the array size to be max of both the values . However,
> while saving and restoring the context we decide on the size based
> on the arch
The max array reservation may work with other omap arch as well, but
at least, shoulnd't the above "ctx[OMAP4_MBOX_REG_SIZE]" be
"ctx[OMAP4_MBOX_NR_REG]"?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
