lkml.org 
[lkml]   [2006]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe : Re : [HELP] Power management for embedded system
    Russell King wrote:
    > On Thu, Aug 24, 2006 at 09:37:39AM +0000, moreau francis wrote:
    >> Russell King wrote:
    >>> On Thu, Aug 24, 2006 at 08:44:25AM +0000, moreau francis wrote:
    >>>> Mips one seems to be a copy and paste of arm one and both of them
    >>>> have removed all APM bios stuff orginally part of i386 implementation.
    >>> The BIOS stuff makes no sense on ARM - there isn't a BIOS to do anything
    >>> with.
    >> I haven't said that it has been widely/wrongly removed...
    >
    > ROTFL! No, you were stating that the APM bios stuff was removed, and
    > I gave the reason for it. Why are you now objecting to my explaination?
    >

    Take it easy ! I'm not objecting your explanation. Your explanation, which
    was not asked, sounded to me like I said something wrong/bad on this
    amputation. I have prefered to make things clear, no more.

    >>>> It doesn't seem that APM is something really stable and finished.
    >>> It's complete. It's purpose is to provide the interface to userland so
    >>> that programs know about suspend/resume events, and can initiate suspends.
    >>> Eg, the X server.
    >>>
    >> Is there something specific to ARM in this implementation ? I don't think
    >> so and it's surely the reason why MIPS did copy it with almost no changes.
    >
    > MIPS copied it because presumably it was useful for them.
    >

    Actually my point is that it could be usefull for _all_ embedded systems,
    whatever the arches it comes from, couldn't it ?

    >> I understand that ARM implementation has been the first one but maybe now

    So does it make sense to you to have

    linux/driver/apm
    |-- apm_userland_interface_emulation_and_not_a_power_management_infrastructure.c
    |-- idle.c
    |-- core.c

    linux/arch/arm/kernel/
    |- apm_specific_to_arm_which_is_needed_by_generic_driver.c
    | ...

    for example ?


    >> why not making it the common power management for embedded system that
    >> could be used by all arches which need it ?
    >
    > It could well become a common interface. But it is NOT power management
    > infrastructure. It is merely a _userland_ interface. Nothing more. It
    > does not do anything other than that.
    >

    apm_queue_event() (and kapmd) doens't seem something usefull for user space.
    It seems to be designed to be used by the kernel no ?

    >> BTW, why has apm_cpu_idle() logic been removed from ARM implementation ?
    >
    > This APM is just a userland interface. It has nothing to do with actual
    > power management. CPU idling is handled entirely differently on ARM.
    >

    Could you point out where it is handled ?

    >>> The power management really comes from the Linux drivers themselves,
    >>> which are written to peripherals off when they're not in use. The other
    >>> power saving comes from things like cpufreq - again, nothing to do with
    >>> the magical "APM" or "ACPI" terms.
    >> BTW why is it still called "APM" on ARM ?
    >
    > That's what the userland interface is called on x86. We could've called it
    > apm_userland_interface_emulation_and_not_a_power_management_infrastructure.c
    > but although that clearly states what it is, it would've been far too long
    > a name. 8)
    >

    Sure, but something that can reflect that it's a userland interface emulation
    implementation would have been usefull. APM, despite it's already used by APM
    BIOS terminology, is rather a name for a complete subsystem.

    Francis



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-24 13:01    [W:0.026 / U:90.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site