All of lore.kernel.org
 help / color / mirror / Atom feed
From: dmitry pervushin <dpervushin@gmail.com>
To: Dmitry Krivoschokov <dkrivoschokov@dev.rtsoft.ru>
Cc: linux-pm@lists.osdl.org,
	ARM-kernel-linux <linux-arm-kernel@lists.arm.linux.org.uk>,
	Harald Welte <laforge@gnumonks.org>
Subject: Re: [RFC] [0/4] Voltage Framework
Date: Fri, 06 Apr 2007 22:05:40 +0400	[thread overview]
Message-ID: <1175882741.7820.7.camel@notebook> (raw)
In-Reply-To: <46166A8E.8030602@dev.rtsoft.ru>

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

           reply	other threads:[~2007-04-06 18:05 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <46166A8E.8030602@dev.rtsoft.ru>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1175882741.7820.7.camel@notebook \
    --to=dpervushin@gmail.com \
    --cc=dkrivoschokov@dev.rtsoft.ru \
    --cc=laforge@gnumonks.org \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-pm@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.