Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote:
> On 2014-12-11 10:29, Russell King - ARM Linux wrote:
> >On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote:
> >>I assume that now it won't be possible to get l2c patches back to -next,
> >>so I will resend them (again...) with the omap related fix.
> >What, you mean you don't know the fundamental rules of kernel development?
> >
> >No one should ever dump any new code into linux-next during a merge
> >window which is not a fix for a regression or a bug fix, period.
> >
> >Linus has in the past taken a snapshot of linux-next at the beginning
> >of a merge window, and then threatened to refuse to merge anything that
> >wasn't in his local snapshot, or which doesn't qualify as the above.
> >
> >So no, it won't be possible, because I play by the community rules when
> >it comes to what gets merged and at what time in the cycle.
> 
> I know the rules. It was just my whining, that it is yet another release
> cycle
> that got missed. It is really disappointing, that those patches have been
> floating for months and noone found issues related to different order of
> initialization. It took way to long to get them scheduled for testing in
> -next.

Right, so - we're now at -rc1, and we should see about queuing this up
sooner rather than later - in its fixed form.  From what I can see,
there's been little progress on the OMAP problem.

Nishanth - can we push OMAP over to using the generic DT L2C
initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and
kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ?

>From what I can see, in the DT case, the only thing which is used
there is the ioremap() to provide omap4_get_l2cache_base() with
something to return.  Everything else - the initialisation of the
l2c_write_sec pointer, and the aux mask and values - can be specified
via the machine_desc struct.

That only leaves the non-DT stuff to worry about this, and from what I
understand, that's going to be removed soon.  If we're going to keep
the non-DT stuff, we should implement a new machine_desc hook for it
instead of hijacking one of the existing callbacks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.