Menu
▾
▴
linuxconsole-dev
|
From: Petr V. <VAN...@vc...> - 2001-11-14 20:24:33
|
On 14 Nov 01 at 11:58, James Simmons wrote:
> Hi folks. I finally hammered a newer api for framebuffer devices. I
> adapted skeletonfb.c to show it off. Feedback welcomed.
Thanks.
> * Blank the screen if blank_mode != 0, else unblank. Return 0 if
> * blanking succeeded, != 0 if un-/blanking failed due to e.g. a
> * video mode which doesn't support it. Implements VESA suspend
> * and powerdown modes on hardware that supports disabling hsync/vsync:
> * blank_mode == 2: suspend vsync
> * blank_mode == 3: suspend hsync
> * blank_mode == 4: powerdown
What about:
* Note: If screen is blanked, all other functions (setcolreg,
* imageblit) may be still invoked, and must work. This needs
* special care if you are blanking by programming DAC to all black.
or something like that.
> * Returns negative errno on error, or zero on success.
If driver does not support specified powerdown mode, should it
use nearest mode with greater power consumption, nearest mode with
smaller power consumption, or should it report an error?
> /*
> * We provide our own functions if we have hardware acceleration
> * or non packed pixel format layouts.
? * If we have no hardware acceleration, we provide an unaccelerated
? * functions in fbcon-cfb*.c modules. You can use these functions
? * as fallbacks if hardware unsupported action is requested.
> * xxxfb_fillrect - REQUIRED function. Can use generic routines if
> * non acclerated hardware and packed pixel based.
> * Draws a rectangle on the screen.
filled rectangle, I assume, not two horizontal and
two vertical lines...
> *
> * @info: frame buffer structure that represents a single frame buffer
> #ifdef MODULE
> module_init(xxxfb_init);
> module_exit(xxxfb_cleanup);
>
> MODULE_LICENSE("GPL");
> #endif /* MODULE */
Move #endif up below xxxfb_init, as these macros works correctly
when code is built into kernel, and we want to make sure that nobody
will remove #ifdef MODULE when doing cleanup, as we still call
init explicitly from global fb initialization. I do not need it on
my systems (due to pciorder patch), but others may use non-PCI devices,
so we probably want to retain this :-( Unless there is another
devices ordering scheme planned for 2.5.
Petr Vandrovec
van...@vc...
|
|
From: Geert U. <ge...@li...> - 2001-11-14 21:06:15
|
On Wed, 14 Nov 2001, Petr Vandrovec wrote:
> On 14 Nov 01 at 11:58, James Simmons wrote:
> > * Blank the screen if blank_mode != 0, else unblank. Return 0 if
> > * blanking succeeded, != 0 if un-/blanking failed due to e.g. a
> > * video mode which doesn't support it. Implements VESA suspend
> > * and powerdown modes on hardware that supports disabling hsync/vsync:
> > * blank_mode == 2: suspend vsync
> > * blank_mode == 3: suspend hsync
> > * blank_mode == 4: powerdown
>
> What about:
>
> * Note: If screen is blanked, all other functions (setcolreg,
> * imageblit) may be still invoked, and must work. This needs
> * special care if you are blanking by programming DAC to all black.
>
> or something like that.
Or the upper layer could take care of that.
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-11-14 22:09:26
|
> > What about: > > > > * Note: If screen is blanked, all other functions (setcolreg, > > * imageblit) may be still invoked, and must work. This needs > > * special care if you are blanking by programming DAC to all black. > > > > or something like that. > > Or the upper layer could take care of that. Hm. Code in fbmem.c can handle this. Actually I like to make the blank code more robust. I like to see real power management on alot of levels. For example many hand held devices have hooks to lower the pixclock when in power saving mode. This is needed when you lower the CPU clock speed. We really should be making use of the struct pm_dev I placed into struct fb_info. So to deal with this issue in fbmem we could atomically read struct pm_dev state field. P.S No power management function to read the current state? |
|
From: Benjamin H. <be...@ke...> - 2001-11-14 22:57:01
|
> >Hm. Code in fbmem.c can handle this. Actually I like to make the blank >code more robust. I like to see real power management on alot of levels. >For example many hand held devices have hooks to lower the pixclock when >in power saving mode. This is needed when you lower the CPU clock speed. >We really should be making use of the struct pm_dev I placed into struct >fb_info. So to deal with this issue in fbmem we could atomically read >struct pm_dev state field. > >P.S > No power management function to read the current state? You may want to sync with Patrick Mochel who is working on the new PM scheme for 2.5 along with the new unified device interface. AFAIK, pm_dev will be gone and all devices will have PM hooks as part of the standard "struct device" that _any_ HW driver will be supposed to implement. Ben. |
|
From: Paul M. <pm...@mv...> - 2001-11-14 23:04:06
|
On Wed, Nov 14, 2001 at 11:56:10PM +0100, Benjamin Herrenschmidt wrote: > You may want to sync with Patrick Mochel who is working on the new > PM scheme for 2.5 along with the new unified device interface. > AFAIK, pm_dev will be gone and all devices will have PM hooks as > part of the standard "struct device" that _any_ HW driver will > be supposed to implement. >=20 Speaking of this.. do you know what the plans for ddfs are? Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: James S. <jsi...@tr...> - 2001-11-15 17:24:42
|
> > You may want to sync with Patrick Mochel who is working on the new > > PM scheme for 2.5 along with the new unified device interface. > > AFAIK, pm_dev will be gone and all devices will have PM hooks as > > part of the standard "struct device" that _any_ HW driver will > > be supposed to implement. Where can I find this work or is it vaporware? As how stable is it? Will it be the final solution that will go in? I like to port a few subsystems in my CVS to it. > Speaking of this.. do you know what the plans for ddfs are? Yet another device filesystem? The nice thing about a new unified device interface is it will make the device filesystems I plan to work much easier to implement. |
|
From: Benjamin H. <be...@ke...> - 2001-11-16 13:51:27
|
>> > You may want to sync with Patrick Mochel who is working on the new >> > PM scheme for 2.5 along with the new unified device interface. >> > AFAIK, pm_dev will be gone and all devices will have PM hooks as >> > part of the standard "struct device" that _any_ HW driver will >> > be supposed to implement. > >Where can I find this work or is it vaporware? As how stable is it? Will >it be the final solution that will go in? I like to port a few subsystems >in my CVS to it. > >> Speaking of this.. do you know what the plans for ddfs are? > >Yet another device filesystem? The nice thing about a new unified device >interface is it will make the device filesystems I plan to work much >easier to implement. Ask Patrick and the linux mailing list. AFAIK, His current patches not only provide the unified struct device with PM hooks, but also the device filesystem. Ben. |
|
From: Benjamin H. <be...@ke...> - 2001-11-16 14:14:49
|
>Ask Patrick and the linux mailing list. AFAIK, His current patches not >only provide the unified struct device with PM hooks, but also the >device filesystem. I mean linux-kernel mailing list of course ;) Ben. |
|
From: James S. <jsi...@tr...> - 2001-11-16 17:32:12
|
> >Where can I find this work or is it vaporware? As how stable is it? Will > >it be the final solution that will go in? I like to port a few subsystems > >in my CVS to it. > > > >> Speaking of this.. do you know what the plans for ddfs are? > > > >Yet another device filesystem? The nice thing about a new unified device > >interface is it will make the device filesystems I plan to work much > >easier to implement. > > Ask Patrick and the linux mailing list. AFAIK, His current patches not > only provide the unified struct device with PM hooks, but also the > device filesystem. Good. I sent out the email. Also if he has a very mature device filesystem that will make our lives easier. |
|
From: Patrick M. <mo...@in...> - 2001-11-16 17:49:26
|
I am only half-paying attention and I saw my name... On Fri, 16 Nov 2001, James Simmons wrote: > > > >Where can I find this work or is it vaporware? As how stable is it? Will > > >it be the final solution that will go in? I like to port a few subsystems > > >in my CVS to it. > > > > > >> Speaking of this.. do you know what the plans for ddfs are? > > > > > >Yet another device filesystem? The nice thing about a new unified device > > >interface is it will make the device filesystems I plan to work much > > >easier to implement. > > > > Ask Patrick and the linux mailing list. AFAIK, His current patches not > > only provide the unified struct device with PM hooks, but also the > > device filesystem. > > Good. I sent out the email. Also if he has a very mature device filesystem > that will make our lives easier. The code lives on kernel.org: ftp://ftp.kernel.org/pub/linux/kernel/people/mochel/device There is a document that should be relatively up to date describing what's going on. The gist of it is that it provides a unified device tree based on locality. Nodes are added by the bus drivers on which a device sits. So, the PCI layer adds nodes for all devices that it finds when probing the bus. There is also a filesystem that goes along with it and presents this unified view to userspace. The power management code is not explicitly included in that code. I have implemented one suspend/resume transition, but it is in the ACPI subsystem, which you can get from Intel: http://developer.intel.com/technology/IAPC/acpi/index.htm I have thought about doing a general PM imeplementation, but probably will not, since there are too many platform-specific things that you must worry about to make it elegant.. -pat |
|
From: James S. <jsi...@tr...> - 2001-11-14 22:24:35
|
> * Note: If screen is blanked, all other functions (setcolreg, > * imageblit) may be still invoked, and must work. This needs > * special care if you are blanking by programming DAC to all black. > > or something like that. See other email. > > * Returns negative errno on error, or zero on success. > > If driver does not support specified powerdown mode, should it > use nearest mode with greater power consumption, nearest mode with > smaller power consumption, or should it report an error? > ? * If we have no hardware acceleration, we provide an unaccelerated > ? * functions in fbcon-cfb*.c modules. You can use these functions > ? * as fallbacks if hardware unsupported action is requested. Yes this is the case. I have three different files each with a soft accel for each possible accel function. The reason for breaking them up is because in theory you could have a device with only fillrect support. Then you can plug in the other two generic accel functions. As for non pack pixel and non accelerated cards you have to provide your own functions. > Move #endif up below xxxfb_init, as these macros works correctly > when code is built into kernel, and we want to make sure that nobody > will remove #ifdef MODULE when doing cleanup, as we still call > init explicitly from global fb initialization. Done :-) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X