Re: [PATCH] i2c: exynos5: Move initialization code to subsys_initcall()

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

On Tue, Jan 13, 2015 at 02:13:51PM +0200, Tomi Valkeinen wrote:
> On 12/01/15 10:43, Joonyoung Shim wrote:
> > +Cc Tomi Valkeinen,
> > 
> > Hi Uwe,
> > 
> > On 01/12/2015 04:50 PM, Uwe Kleine-König wrote:
> >> Hello,
> >>
> >> On Mon, Jan 12, 2015 at 11:53:02AM +0900, Joonyoung Shim wrote:
> >>> This is required in order to ensure that core system devices such as
> >>> voltage regulators attached via I2C are available early in boot.
> >> Deferred probing isn't an option? If so I suggest adding the reasoning
> >> in a comment to stop the next person converting it to that.
> >> (And if not, please fix accordingly to use deferred probing.)
> >>
> > 
> > I couldn't get penguin logo since the commit 92b004d ("video/logo:
> > prevent use of logos after they have been freed") and i just tried old
> > way because i missed the flow to move to deferred probing.
> > 
> > Fb driver probe seems to be ran between fb_logo_late_init late_initcall
> > and the freeing of the logos.
> > 
> > Any ideas?
> 
> Thierry mentioned on IRC that he encountered the same issue. And I
> encountered it also.
> 
> So... I'd rather not revert the fix, as it's quite a nasty one, and it
> happens while console lock is held, so it looks like the machine just
> froze. But I don't know how it could be improved with the current kernel.
> 
> We could make the logos non-initdata, but I don't much like that option.
> Or we could perhaps implement some new way to catch the freeing of initdata.
> 
> Any other ideas?

I think we could still make the logos non-initdata based on a Kconfig
symbol. Another option might be to copy the logo data to memory that's
not automatically freed after init, so that we get better control over
when it is released. I tried tracing the various parts that would need
this data, but couldn't find any place after which it isn't needed
anymore. Specifically it is code that can be executed on every console
switch, so we can't really get rid of it at any sensible time.

I'd argue that if it's needed at every VT switch where the framebuffer
console is activated, then we really can't get rid of it at all. Or we
don't display the logo at every switch and can free the backing memory
right after the first switch for example.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]