Jisheng,
On Fri, Apr 11, 2014 at 04:27:16PM +0800, Jisheng Zhang wrote:
> Hi Antoine,
>
> On Fri, 11 Apr 2014 01:18:39 -0700
> Antoine Ténart <antoine.tenart@xxxxxxxxxxxxxxxxxx> wrote:
>
> > Hi Jisheng,
> >
> > On Fri, Apr 11, 2014 at 02:44:31PM +0800, Jisheng Zhang wrote:
> > > On Thu, 10 Apr 2014 06:07:51 -0700
> > > Antoine Ténart <antoine.tenart@xxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > ...
> > > > +static int berlin_pinmux_enable(struct pinctrl_dev *pctrl_dev,
> > > > + unsigned function,
> > > > + unsigned group)
> > > > +{
> > > > + struct berlin_pinctrl *pctrl =
> > > > pinctrl_dev_get_drvdata(pctrl_dev);
> > > > + struct berlin_pinctrl_group *group_desc = pctrl->groups + group;
> > > > + struct berlin_pinctrl_function *function_desc =
> > > > + pctrl->functions + function;
> > > > + unsigned long flags;
> > > > + u32 regval;
> > > > +
> > > > + spin_lock_irqsave(&pctrl->lock, flags);
> > > > +
> > > > + regval = readl(group_desc->reg);
> > > > + regval &= group_desc->mask;
> > > > + regval |= function_desc->muxval << group_desc->lsb;
> > > > + writel(regval, group_desc->reg);
> > >
> > > Could we use relaxed version instead?
> >
> > We could, but this is not a performance issue here at all, so I guess we can
> > keep writel().
>
> Yes it's not a performance issue here but an issue for the system which is doing
> PL310 L2 cache maintenance. If pinmux operation hold the l2x0_lock due to writel()
> the important video/audio process which is cleaning PL310 cache must wait, thus
> cause jitter. So I'd like relaxed version if we can. Then I don't need to add this
> patch to mainline kernel when we upgrade internal tree.
I'm not sure I got that. As I understand it, you will need to play video/audio
*while* configuring the pinmux. But the pinmuxing configuration is done at boot
time, and I don't think a video/audio is being played then. So I'm not certain a
jitter will appear. What do you think ?
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
