* Re: [RFC] [0/4] Voltage Framework
[not found] ` <46166A8E.8030602@dev.rtsoft.ru>
@ 2007-04-06 18:05 ` dmitry pervushin
0 siblings, 0 replies; only message in thread
From: dmitry pervushin @ 2007-04-06 18:05 UTC (permalink / raw)
To: Dmitry Krivoschokov; +Cc: linux-pm, ARM-kernel-linux, Harald Welte
On Птн, 2007-04-06 at 19:43 +0400, Dmitry Krivoschokov wrote:
[skipped]
> The struct resource was initially intended for IO resources only,
> (which looks wrong to me, at least its naming, it could be called
> as io_resources). But voltage is not an IO resource, so struct resource
> is not appropriate place for that
You object on naming of the structure (have you ever tried to do output
on interrupt line :) )?
The struct resource layout is not well suitable to keep information
about clocks/voltage and ever gpio lines, but all of these things are
resources. Resources of device. Well, resources that belongs to
platform_device.
I don't like idea to keep two separate lists of resources - one for I/O
ports/memory windows/IRQ lines and the another one to keep pm resources.
Why should they be separated ?
> >This might sound odd, but after all, why not look at power [voltage] as
> >a resource just loke memory, IO ports, GPIO or IRQ lines?
> >
> I'd consider voltage and clocks as a power resources, every computer
> (say CMOS) system (or device) consumes (requires for) voltage and clocks,
> so it looks natural that device driver will check what resources
> are needed for device on this particular platform.
>
> >
> >This keeps the drivers clean from having to know any device specifics.
> >
> >
> Yep.
>
> >It also keeps the actual device driver of any peripheral independent of
> >the PMU driver, since the latter would sit behind the 'struct resource'
> >abstraction.
> >A device driver would then just call something like
> >requrest_power(struct resource *) whic hides all the magic of
> >calling back into the individual PMU driver.
> >
> It assumes some infrastructure to deal with power resources, like
> we have for interrupts now.
>
> Actually, all Linux PM-related problems are discussed on
> linux-pm@lists.linux-foundation.org list, here it's offtopic.
> Continue the discassion on linux-pm, if you will.
I added linux-pm to Cc, so let's continue there.
>
>
> Thanks,
> Dmitry
>
>
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2007-04-06 18:05 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1174469715.19019.65.camel@amit-laptop>
[not found] ` <20070406073159.GE4081@prithivi.gnumonks.org>
[not found] ` <46166A8E.8030602@dev.rtsoft.ru>
2007-04-06 18:05 ` [RFC] [0/4] Voltage Framework dmitry pervushin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.