From: Petr V. <VAN...@vc...> - 2001-06-29 10:58:27
|
On 28 Jun 01 at 16:53, James Simmons wrote: > To: FrameBuffer List <lin...@vu...> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Can somebody tell me which one is current developer list? Or do we have two? > Subject: [linux-fbdev] [ANNOUNCE] fbgen "2" > @@ -306,12 +313,16 @@ > struct fb_monspecs monspecs; /* Current Monitor specs */ > struct fb_cmap cmap; /* Current cmap */ > struct fb_ops *fbops; > +#ifdef CONFIG_PM > + struct pm_dev *pm_fb; > +#endif > char *screen_base; /* Virtual address */ > struct display *disp; /* initial display variable */ I have two problems with this: (1) Please remove ifdef CONFIG_PM around that. pm.h provides dummy pm_* functions when pm is disabled, so you do not have to check CONFIG_PM in driver sources. But if structure does not have this pm_fb field, you must :-( (2) Is there any reason for having this pointer in this structure at all? Does anybody except driver itself need such thing? You can have couple of fbdevs pointing to one pm_dev, just because of they live on same device and cannot be powered up independently. Thanks, Petr Vandrovec van...@vc... |
From: Geert U. <ge...@li...> - 2001-06-29 11:19:36
|
On Fri, 29 Jun 2001, Petr Vandrovec wrote: > On 28 Jun 01 at 16:53, James Simmons wrote: > > To: FrameBuffer List <lin...@vu...> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Can somebody tell me which one is current developer list? Or do we have > two? The SourceForge one. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: James S. <jsi...@tr...> - 2001-06-29 16:15:20
|
> > > To: FrameBuffer List <lin...@vu...> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Can somebody tell me which one is current developer list? Or do we have > > two? > > The SourceForge one. That is strange. Looking at my address book fbdev list points to the sourceforge one. I bet my email client at home has the old address. Sorry about that. |
From: James S. <jsi...@tr...> - 2001-06-29 16:31:56
|
> I have two problems with this: > (1) Please remove ifdef CONFIG_PM around that. pm.h provides dummy > pm_* functions when pm is disabled, so you do not have to check > CONFIG_PM in driver sources. But if structure does not have this > pm_fb field, you must :-( Okay. I will fix that. > (2) Is there any reason for having this pointer in this structure at > all? Does anybody except driver itself need such thing? You can > have couple of fbdevs pointing to one pm_dev, just because of > they live on same device and cannot be powered up independently. Yes! One their are devices that need to do more than just blank the screen for it power management. Take a look at the SA1100 framebuffer driver from the arm tree. Second we can use the special handler in fb_info to replace the one in the console. Since their are devices that have special needs we can't depend on the default console power management function. You made the point about multiple devices. If you have more than one card of the same type you can use the same call back function. Just pass different data (struct fb_info) to the pm_register function. This will allow for different VTs to blank at different time. No would it not suck if someone left their VT and when it went blank it blanked your head while you are working. This prevents that. Yes you have to register for each device to the power management layer. The next case is same card multiple heads. You can have two cases. The first case is each head can preform its own power management. Easy, treat each card as a seperate device. You need a seperate fb_info for each framebuffer anyways. The final case is where you have multiple heads but one card and the power management is shared. Again you don't want your console to go blank because the other one is not being worked on. Again easy, share the struct pm_dev between each fb_info struct. Just make sure you have proper locking in this case. |