Re: Frame buffers and early i2c

Re: Frame buffers and early i2c

[Jean Delvare]

On Mon, 9 Jun 2008 16:47:42 +0200, Uli Luckas wrote:
> I am in the process of trying out a display connected to a colibri board's 
> pxa frame buffer device. The display's power supply is switch through i2c.
> 
> In order to use the frame buffer console I have i2c and pxafb compiled in.
> 
> By default, the pxafb driver get's initialized before the i2c bus causing the 
> display power up to fail.
> 
> What do i2c people think about changing the link order here?

Why don't you ask on the i2c mailing list? Cc added.

Personally I have no objection, but dependencies can be tricky so
you'll have to be careful. video is early in the link order at the
moment.

> What do other frame buffer drivers handle the absence of i2c during early 
> boot?

Interestingly enough, they appear to do fine, despite the linking
order. Maybe because i2c_init is a subsys_initcall() while framebuffer
drivers are initialized with module_init()? Then I'm not sure why your
own driver has a problem there.

-- 
Jean Delvare

Re: Frame buffers and early i2c

[Uli Luckas]

On Monday 09 June 2008, Jean Delvare wrote:
> On Mon, 9 Jun 2008 16:47:42 +0200, Uli Luckas wrote:
> > I am in the process of trying out a display connected to a colibri
> > board's pxa frame buffer device. The display's power supply is switch
> > through i2c.
> >
> > In order to use the frame buffer console I have i2c and pxafb compiled
> > in.
> >
> > By default, the pxafb driver get's initialized before the i2c bus causing
> > the display power up to fail.
> >
> > What do i2c people think about changing the link order here?
>
> Why don't you ask on the i2c mailing list? Cc added.
>
I wanted to get i2c developers plus frame buffer and other i2c client 
developers involved. Crossposting to more then 2 lists seemed wrong.

> Personally I have no objection, but dependencies can be tricky so
> you'll have to be careful. video is early in the link order at the
> moment.
>
Yep. I might come back for help on that later.

> > What do other frame buffer drivers handle the absence of i2c during early
> > boot?
>
> Interestingly enough, they appear to do fine, despite the linking
> order. Maybe because i2c_init is a subsys_initcall() while framebuffer
> drivers are initialized with module_init()? Then I'm not sure why your
> own driver has a problem there.
>
Well, this is only very partially true. Try:
rgrep -l subsys_initcall drivers/i2c/
rgrep -l module_init drivers/i2c/

The last of which gives drivers/i2c/busses/i2c-pxa.c for example.

I'll change the pxa i2c driver to subsys_initcall and try if that works when I 
get back to my desk tomorrow.

regards,
Uli

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Frame buffers and early i2c

[Jean Delvare]

Hi Uli,

On Mon, 9 Jun 2008 23:59:35 +0200, Uli Luckas wrote:
> On Monday 09 June 2008, Jean Delvare wrote:
> > Why don't you ask on the i2c mailing list? Cc added.
>
> I wanted to get i2c developers plus frame buffer and other i2c client 
> developers involved. Crossposting to more then 2 lists seemed wrong.

So you prefer to post to one random list than the two lists where your
target audience is? Interesting approach. If you really don't want to
post to two lists at once, just send two separate posts?

> > Interestingly enough, they appear to do fine, despite the linking
> > order. Maybe because i2c_init is a subsys_initcall() while framebuffer
> > drivers are initialized with module_init()? Then I'm not sure why your
> > own driver has a problem there.
> >
> Well, this is only very partially true. Try:
> rgrep -l subsys_initcall drivers/i2c/
> rgrep -l module_init drivers/i2c/
> 
> The last of which gives drivers/i2c/busses/i2c-pxa.c for example.

Sorry, I didn't understand what you wanted originally. I thought you
only wanted the i2c-core up before pxafb (which is in fact already the
case) while what you actually want it i2c-pxa up before pxafb (which
isn't yet the case.)

> I'll change the pxa i2c driver to subsys_initcall and try if that works when I 
> get back to my desk tomorrow.

I expect it to work, as apparently other platforms are doing exactly
that already.

-- 
Jean Delvare

Re: Frame buffers and early i2c

[Uli Luckas]

On Tuesday, 10. June 2008, Jean Delvare wrote:
> Hi Uli,
>
> On Mon, 9 Jun 2008 23:59:35 +0200, Uli Luckas wrote:
> > On Monday 09 June 2008, Jean Delvare wrote:
> > > Why don't you ask on the i2c mailing list? Cc added.
> >
> > I wanted to get i2c developers plus frame buffer and other i2c client
> > developers involved. Crossposting to more then 2 lists seemed wrong.
>
> So you prefer to post to one random list than the two lists where your
> target audience is? Interesting approach. If you really don't want to
> post to two lists at once, just send two separate posts?
>
And have two seperate threads of communication??? lfml is where they all are 
and avery maintainer has different preferences. Anyway, I got your point and 
will come to the i2c list in the future if you prefere.

> > I'll change the pxa i2c driver to subsys_initcall and try if that works
> > when I get back to my desk tomorrow.
>
> I expect it to work, as apparently other platforms are doing exactly
> that already.
>
Just changing the initcall to subsys really did the trick. I thought, this was 
the first thing I tried and I thought it crashed my device. But obviousely I 
had some other problem.
If Russell gives his Ack, could this be pushed upstream through i2c?

regards,
Uli



Initialize the pxa i2c bus during subsystem initialization to make it
available during driver initialization (e.g. display powerup for pxafb).

Signed-off-by: Uli Luckas <u.luckas@road.de>
---
 drivers/i2c/busses/i2c-pxa.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index eb69fba..78c0fc4 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1134,5 +1134,5 @@ static void __exit i2c_adap_pxa_exit(void)
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:pxa2xx-i2c");
 
-module_init(i2c_adap_pxa_init);
+subsys_initcall(i2c_adap_pxa_init);
 module_exit(i2c_adap_pxa_exit);
-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit

Re: [i2c] Frame buffers and early i2c

[Ben Dooks]

On Tue, Jun 10, 2008 at 11:31:19AM +0200, Uli Luckas wrote:
> On Tuesday, 10. June 2008, Jean Delvare wrote:
> > Hi Uli,
> >
> > On Mon, 9 Jun 2008 23:59:35 +0200, Uli Luckas wrote:
> > > On Monday 09 June 2008, Jean Delvare wrote:
> > > > Why don't you ask on the i2c mailing list? Cc added.
> > >
> > > I wanted to get i2c developers plus frame buffer and other i2c client
> > > developers involved. Crossposting to more then 2 lists seemed wrong.
> >
> > So you prefer to post to one random list than the two lists where your
> > target audience is? Interesting approach. If you really don't want to
> > post to two lists at once, just send two separate posts?
> >
> And have two seperate threads of communication??? lfml is where they all are 
> and avery maintainer has different preferences. Anyway, I got your point and 
> will come to the i2c list in the future if you prefere.
> 
> > > I'll change the pxa i2c driver to subsys_initcall and try if that works
> > > when I get back to my desk tomorrow.
> >
> > I expect it to work, as apparently other platforms are doing exactly
> > that already.
> >
> Just changing the initcall to subsys really did the trick. I thought, this was 
> the first thing I tried and I thought it crashed my device. But obviousely I 
> had some other problem.
> If Russell gives his Ack, could this be pushed upstream through i2c?

Does this work if the code is built as a module? 

BTW, if people do have these sort of dependencies, then modules
are another way of sorting out the load order, unless you have
the module autoload enabled.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: [i2c] Frame buffers and early i2c

[Jean Delvare]

On Tue, 10 Jun 2008 11:02:50 +0100, Ben Dooks wrote:
> On Tue, Jun 10, 2008 at 11:31:19AM +0200, Uli Luckas wrote:
> > Just changing the initcall to subsys really did the trick. I thought, this was 
> > the first thing I tried and I thought it crashed my device. But obviousely I 
> > had some other problem.
> > If Russell gives his Ack, could this be pushed upstream through i2c?
> 
> Does this work if the code is built as a module?

subsys_initcall degrades to module_init in modules, so Uli's patch
doesn't change anything in that case.

> BTW, if people do have these sort of dependencies, then modules
> are another way of sorting out the load order, unless you have
> the module autoload enabled.

-- 
Jean Delvare

Re: [i2c] Frame buffers and early i2c

[Uli Luckas]

On Tuesday, 10. June 2008, Ben Dooks wrote:
> BTW, if people do have these sort of dependencies, then modules
> are another way of sorting out the load order, unless you have
> the module autoload enabled.
>
True. But my original post stated:
> In order to use the frame buffer console I have i2c and pxafb compiled in
This is one example where waiting for user space to be up and running is not 
an option.

regards,
Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit

Re: Frame buffers and early i2c

[Jean Delvare]

On Tue, 10 Jun 2008 11:31:19 +0200, Uli Luckas wrote:
> On Tuesday, 10. June 2008, Jean Delvare wrote:
> > So you prefer to post to one random list than the two lists where your
> > target audience is? Interesting approach. If you really don't want to
> > post to two lists at once, just send two separate posts?
> >
> And have two seperate threads of communication??? lfml is where they all are 
> and avery maintainer has different preferences. Anyway, I got your point and 
> will come to the i2c list in the future if you prefere.

If you believe that every kernel developer reads LKML, you're seriously
mistaken. We have a hundred of dedicated mailing lists for a reason. I
would have missed your post if you hadn't Cc'd directly.

> Just changing the initcall to subsys really did the trick. I thought, this was 
> the first thing I tried and I thought it crashed my device. But obviousely I 
> had some other problem.
> If Russell gives his Ack, could this be pushed upstream through i2c?
> (...)
> Initialize the pxa i2c bus during subsystem initialization to make it
> available during driver initialization (e.g. display powerup for pxafb).
> 
> Signed-off-by: Uli Luckas <u.luckas@road.de>
> ---
>  drivers/i2c/busses/i2c-pxa.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index eb69fba..78c0fc4 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1134,5 +1134,5 @@ static void __exit i2c_adap_pxa_exit(void)
>  MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:pxa2xx-i2c");
>  
> -module_init(i2c_adap_pxa_init);
> +subsys_initcall(i2c_adap_pxa_init);
>  module_exit(i2c_adap_pxa_exit);

That's fine with me.

-- 
Jean Delvare