On Tue, Jul 21, 2015 at 08:14:32AM +0200, Alexander Stein wrote:
> On Monday 20 July 2015 18:26:27, Mark Brown wrote:
> > Well, it's *better* to provide defaults since otherwise everything
> > defaults to 0 but it does avoid the whole allocation during fast path
> > issue since it allocates the ca
On Monday 20 July 2015 18:26:27, Mark Brown wrote:
> > AFAICS even a flat cache seems also only be usefull when providing
> > defaults, no? (Or having volatile registers).
>
> Well, it's *better* to provide defaults since otherwise everything
> defaults to 0 but it does avoid the whole allocation
On Mon, Jul 20, 2015 at 09:04:05AM +0200, Alexander Stein wrote:
> On Thursday 16 July 2015 20:06:57, Mark Brown wrote:
Please fix your mailer to word wrap within paragraphs for legibility.
> > The expectation here is that we should either be using no or a flat
> > cache here or (if we're using r
On Thursday 16 July 2015 20:06:57, Mark Brown wrote:
> On Thu, Jul 16, 2015 at 05:48:52PM +0200, Alexander Stein wrote:
>
> > When regmap locking is done using spinlocks (e.g. using
> > devm_regmap_init_mmio_clk) access is protected using spin_lock_irqsave.
> > So when calling regmap_write the fir
On Thu, Jul 16, 2015 at 05:48:52PM +0200, Alexander Stein wrote:
> When regmap locking is done using spinlocks (e.g. using
> devm_regmap_init_mmio_clk) access is protected using spin_lock_irqsave.
> So when calling regmap_write the first time and a node is about to be
> inserted kzalloc must not b
When regmap locking is done using spinlocks (e.g. using
devm_regmap_init_mmio_clk) access is protected using spin_lock_irqsave.
So when calling regmap_write the first time and a node is about to be
inserted kzalloc must not be called with GFP_KERNEL. At this point
interrupts are disabled. This fixe
6 matches
Mail list logo
