20 Sep, 2012

2 commits

  • Pull workqueue / powernow-k8 fix from Tejun Heo:
    "This is the fix for the bug where cpufreq/powernow-k8 was tripping
    BUG_ON() in try_to_wake_up_local() by migrating workqueue worker to a
    different CPU.

    https://bugzilla.kernel.org/show_bug.cgi?id=47301

    As discussed, the fix is now two parts - one to reimplement
    work_on_cpu() so that it doesn't create a new kthread each time and
    the actual fix which makes powernow-k8 use work_on_cpu() instead of
    performing manual migration.

    While pretty late in the merge cycle, both changes are on the safer
    side. Jiri and I verified two existing users of work_on_cpu() and
    Duncan confirmed that the powernow-k8 fix survived about 18 hours of
    testing."

    * 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
    cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU
    workqueue: reimplement work_on_cpu() using system_wq

    Linus Torvalds
     
  • powernowk8_target() runs off a per-cpu work item and if the
    cpufreq_policy->cpu is different from the current one, it migrates the
    kworker to the target CPU by manipulating current->cpus_allowed. The
    function migrates the kworker back to the original CPU but this is
    still broken. Workqueue concurrency management requires the kworkers
    to stay on the same CPU and powernowk8_target() ends up triggerring
    BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
    fidvid_mutex and sleeps.

    It is unclear why this bug is being reported now. Duncan says it
    appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
    3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool
    instead of @gcwq or @cpu where applicable" which is an non-functional
    change. Given that the reproduce case sometimes took upto days to
    trigger, it's easy to be misled while bisecting. Maybe something made
    contention on fidvid_mutex more likely? I don't know.

    This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
    isn't the same as the current one. The code assumes that
    cpufreq_policy->cpu is kept online by the caller, which Rafael tells
    me is the case.

    stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using
    system_wq") should be applied before this; otherwise, the
    behavior could be horrible.

    Signed-off-by: Tejun Heo
    Reported-by: Duncan
    Tested-by: Duncan
    Cc: Rafael J. Wysocki
    Cc: Andreas Herrmann
    Cc: stable@vger.kernel.org
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301

    Tejun Heo
     

23 Aug, 2012

1 commit


09 Aug, 2012

2 commits

  • On OMAP4, if the first CPU fails to get a valid frequency table (this
    could happen if the platform does not register any OPP table), the
    subsequent CPU instances end up dealing with a NULL freq_table and
    crash.

    Check for an already existing freq_table, before trying to create one,
    and increment the freq_table_users only if the table is sucessfully
    created.

    Signed-off-by: Rajendra Nayak
    Signed-off-by: Santosh Shilimkar
    Cc:
    Signed-off-by: Kevin Hilman

    Rajendra Nayak
     
  • Convert a 0 error return code to a negative one, as returned elsewhere in the
    function.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    //
    @@
    identifier ret;
    expression e,e1,e2,e3,e4,x;
    @@

    (
    if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
    |
    ret = 0
    )
    ... when != ret = e1
    *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
    ... when != x = e2
    when != ret = e3
    *if (x == NULL || ...)
    {
    ... when != ret = e4
    * return ret;
    }
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Rafael J. Wysocki

    Julia Lawall
     

31 Jul, 2012

1 commit

  • Pull arm-soc soc updates from Olof Johansson:
    "This is the second batch of SoC updates for the 3.6 merge window,
    containing parts that arrived close to the merge window opening and
    thus needed to sit in linux-next for a while.

    Most contents is updates of Renesas shmobile, with a couple of Samsung
    Exynos patches in the mix."

    * tag 'soc2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (39 commits)
    ARM: S3C64XX: Add header file protection macros in pm-core.h
    [CPUFREQ] EXYNOS5250: Add support max 1.7GHz for EXYNOS5250
    ARM: EXYNOS: Add G2D related clock entries for SMDK4X12
    ARM: EXYNOS: Move G2D clock entries to clock-exynos4210.c file
    ARM: shmobile: Fix build problem in pm-sh7372.c for unusual .config
    ARM: shmobile: Take cpuidle dependencies into account correctly
    ARM: mach-shmobile: sh7377 generic board support via DT
    ARM: mach-shmobile: r8a7740 generic board support via DT
    ARM: shmobile: sh7372: completely switch over to using pm-rmobile API
    ARM: shmobile: ap4evb: switch to using pm-rmobile API
    ARM: shmobile: mackerel: switch to using pm-rmobile API
    ARM: shmobile: sh7372: add pm-rmobile domain support
    ARM: shmobile: r8a7740: add A4LC pm domain support
    ARM: shmobile: r8a7740: add A3SP pm domain support
    ARM: shmobile: r8a7740: add A4S pm domain support
    ARM: shmobile: r8a7740: fixup: MSEL1CR 7bit control
    ARM: shmobile: soc-core: add R-mobile PM domain common APIs
    ARM: shmobile: sh7372 A3SM CPUIdle support
    ARM: shmobile: Use INTCA with sh7372 A3SM power domain
    ARM: mach-shmobile: Convert sh_clk_mstp32_register to sh_clk_mstp_register
    ...

    Linus Torvalds
     

25 Jul, 2012

1 commit

  • Pull trivial tree from Jiri Kosina:
    "Trivial updates all over the place as usual."

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (29 commits)
    Fix typo in include/linux/clk.h .
    pci: hotplug: Fix typo in pci
    iommu: Fix typo in iommu
    video: Fix typo in drivers/video
    Documentation: Add newline at end-of-file to files lacking one
    arm,unicore32: Remove obsolete "select MISC_DEVICES"
    module.c: spelling s/postition/position/g
    cpufreq: Fix typo in cpufreq driver
    trivial: typo in comment in mksysmap
    mach-omap2: Fix typo in debug message and comment
    scsi: aha152x: Fix sparse warning and make printing pointer address more portable.
    Change email address for Steve Glendinning
    Btrfs: fix typo in convert_extent_bit
    via: Remove bogus if check
    netprio_cgroup.c: fix comment typo
    backlight: fix memory leak on obscure error path
    Documentation: asus-laptop.txt references an obsolete Kconfig item
    Documentation: ManagementStyle: fixed typo
    mm/vmscan: cleanup comment error in balance_pgdat
    mm: cleanup on the comments of zone_reclaim_stat
    ...

    Linus Torvalds
     

21 Jul, 2012

1 commit

  • Running one program that continuously hotplugs and replugs a cpu
    concurrently with another program that continuously writes to the
    scaling_setspeed node eventually deadlocks with:

    =============================================
    [ INFO: possible recursive locking detected ]
    3.4.0 #37 Tainted: G W
    ---------------------------------------------
    filemonkey/122 is trying to acquire lock:
    (s_active#13){++++.+}, at: [] sysfs_remove_dir+0x9c/0xb4

    but task is already holding lock:
    (s_active#13){++++.+}, at: [] sysfs_write_file+0xe8/0x140

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0
    ----
    lock(s_active#13);
    lock(s_active#13);

    *** DEADLOCK ***

    May be due to missing lock nesting notation

    2 locks held by filemonkey/122:
    #0: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x28/0x140
    #1: (s_active#13){++++.+}, at: [] sysfs_write_file+0xe8/0x140

    stack backtrace:
    [] (unwind_backtrace+0x0/0x120) from [] (validate_chain+0x6f8/0x1054)
    [] (validate_chain+0x6f8/0x1054) from [] (__lock_acquire+0x81c/0x8d8)
    [] (__lock_acquire+0x81c/0x8d8) from [] (lock_acquire+0x18c/0x1e8)
    [] (lock_acquire+0x18c/0x1e8) from [] (sysfs_addrm_finish+0xd0/0x180)
    [] (sysfs_addrm_finish+0xd0/0x180) from [] (sysfs_remove_dir+0x9c/0xb4)
    [] (sysfs_remove_dir+0x9c/0xb4) from [] (kobject_del+0x10/0x38)
    [] (kobject_del+0x10/0x38) from [] (kobject_release+0xf0/0x194)
    [] (kobject_release+0xf0/0x194) from [] (cpufreq_cpu_put+0xc/0x24)
    [] (cpufreq_cpu_put+0xc/0x24) from [] (store+0x6c/0x74)
    [] (store+0x6c/0x74) from [] (sysfs_write_file+0x10c/0x140)
    [] (sysfs_write_file+0x10c/0x140) from [] (vfs_write+0xb0/0x128)
    [] (vfs_write+0xb0/0x128) from [] (sys_write+0x3c/0x68)
    [] (sys_write+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c)

    This is because store() in cpufreq.c indirectly calls
    kobject_get() via cpufreq_cpu_get() and is the last one to call
    kobject_put() via cpufreq_cpu_put(). Sysfs code should not call
    kobject_get() or kobject_put() directly (see the comment around
    sysfs_schedule_callback() for more information).

    Fix this deadlock by introducing two new functions:

    struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
    void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)

    which do the same thing as cpufreq_cpu_{get,put}() but don't call
    kobject functions.

    To easily trigger this deadlock you can insert an msleep() with a
    reasonably large value right after the fail label at the bottom
    of the store() function in cpufreq.c and then write
    scaling_setspeed in one task and offline the cpu in another. The
    first task will hang and be detected by the hung task detector.

    Signed-off-by: Stephen Boyd
    Signed-off-by: Rafael J. Wysocki

    Stephen Boyd
     

20 Jul, 2012

2 commits

  • The policy might have been changed since last call of target().
    Thus, using cpufreq_frequency_table_target(), which depends on
    policy to find the corresponding index from a frequency, may return
    inconsistent index for freqs.old. Thus, old_index should be
    calculated not based on the current policy.

    We have been observing such issue when scaling_min/max_freq were
    updated and sometimes cuased system lockups deu to incorrectly
    configured voltages.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Rafael J. Wysocki

    Jonghwa Lee
     
  • Correct spelling typo in cpufreq driver.

    Signed-off-by: Masanari Iida
    Signed-off-by: Jiri Kosina

    Masanari Iida
     

19 Jul, 2012

1 commit


02 May, 2012

1 commit

  • This adds support for the U9540 variant of the U8500 series. This
    is an application processor without internal modem. This is the
    most basic part with ASIC ID, CPU-related fixes, IRQ list, register
    ranges, timer, UART, and L2 cache setup. This is based on a patch
    by Michel Jaouen which was rewritten to fit with the latest 3.3
    kernel.

    ChangeLog v1->v2: deleted the irqs-db9540.h file since we expect to
    migrate to using Device Tree for getting the IRQs to devices.
    ChangeLog v2->v3: introduced a fixed virtual offset for the ROM
    as suggested by Arnd Bergmann.

    Acked-by: Arnd Bergmann
    Signed-off-by: Sebastien Pasdeloup
    Signed-off-by: Michel Jaouen
    Signed-off-by: Linus Walleij

    Linus Walleij
     

14 Apr, 2012

1 commit

  • The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
    builds for OMAP2+ platforms.

    This 'depends on' was in the original patch from Russell King, but was
    erroneously removed by me when making this option user-selectable in
    commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.) This
    patch remedies that.

    Apologies to Russell King for breaking his originally working patch.

    Also, thanks to Grazvydas Ignotas for reporting the same problem.

    Cc: Russell King
    Cc: Grazvydas Ignotas
    Signed-off-by: Kevin Hilman
    Signed-off-by: Linus Torvalds

    Kevin Hilman
     

06 Apr, 2012

1 commit

  • Pull "ARM: SoC fixes: from Olof Johansson:
    "A bunch of fixes for regressions (and a few other problems) in
    3.4-rc1:

    - Fix for regression of mach/io.h cleanup on platforms with PCI or
    PCMCIA (adding back the include file on those for now)
    - AT91 fixes for usb and spi
    - smsc911x ethernet fixes for i.MX
    - smsc911x fixes for OMAP
    - gpio fixes for Tegra
    - A handful of build error and warning fixes for various platforms
    - cpufreq kconfig dependencies, build and lowlevel debug fixes for
    Samsung platforms

    In other words, more or less the regular collection of -rc1/2 type
    material. A few of them, in particular the smsc911x for OMAP series,
    aren't technically regressions for 3.4, but they're valid fixes and
    we're still relatively early in the rc cycle so it seems appropriate
    to include them."

    * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (60 commits)
    ARM: fix __io macro for PCMCIA
    ARM: EXYNOS: Fix compiler warning in dma.c file
    ARM: EXYNOS: fix ISO C90 warning
    ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
    ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
    ARM: OMAP2+: hwmod: Restore sysc after a reset
    ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
    ARM: OMAP3: clock data: fill in some missing clockdomains
    ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
    ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
    ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
    gpio: tegra: Iterate over the correct number of banks
    gpio: tegra: fix register address calculations for Tegra30
    EXYNOS: fix dependency for EXYNOS_CPUFREQ
    ARM: at91: dt: remove unit-address part for memory nodes
    ARM: at91: fix check of valid GPIO for SPI and USB
    USB: ehci-atmel: add needed of.h header file
    ARM: at91/NAND DT bindings: add comments
    ARM: at91/at91sam9x5.dtsi: fix NAND ale/cle in DT file
    USB: ohci-at91: trivial return code name change
    ...

    Linus Torvalds
     

05 Apr, 2012

1 commit

  • This fixes the CPUFREQ dependency for regarding EXYNOS SoCs
    such as EXYNOS4210, EXYNOS4X12 and EXYNOS5250. Its cpufreq
    driver should be built with selection of SoC arch part.

    Reported-by: Russell King
    Acked-by: Dave Jones
    Signed-off-by: Kukjin Kim

    Kukjin Kim
     

29 Mar, 2012

4 commits

  • This has been obsolescent for a while; time for the final push.

    Signed-off-by: Rusty Russell
    Cc: Dave Jones
    Cc: cpufreq@vger.kernel.org
    Cc: Sundar Iyer
    Cc: Martin Persson
    Cc: Jonas Aaberg

    Rusty Russell
     
  • …m/linux/kernel/git/dhowells/linux-asm_system

    Pull "Disintegrate and delete asm/system.h" from David Howells:
    "Here are a bunch of patches to disintegrate asm/system.h into a set of
    separate bits to relieve the problem of circular inclusion
    dependencies.

    I've built all the working defconfigs from all the arches that I can
    and made sure that they don't break.

    The reason for these patches is that I recently encountered a circular
    dependency problem that came about when I produced some patches to
    optimise get_order() by rewriting it to use ilog2().

    This uses bitops - and on the SH arch asm/bitops.h drags in
    asm-generic/get_order.h by a circuituous route involving asm/system.h.

    The main difficulty seems to be asm/system.h. It holds a number of
    low level bits with no/few dependencies that are commonly used (eg.
    memory barriers) and a number of bits with more dependencies that
    aren't used in many places (eg. switch_to()).

    These patches break asm/system.h up into the following core pieces:

    (1) asm/barrier.h

    Move memory barriers here. This already done for MIPS and Alpha.

    (2) asm/switch_to.h

    Move switch_to() and related stuff here.

    (3) asm/exec.h

    Move arch_align_stack() here. Other process execution related bits
    could perhaps go here from asm/processor.h.

    (4) asm/cmpxchg.h

    Move xchg() and cmpxchg() here as they're full word atomic ops and
    frequently used by atomic_xchg() and atomic_cmpxchg().

    (5) asm/bug.h

    Move die() and related bits.

    (6) asm/auxvec.h

    Move AT_VECTOR_SIZE_ARCH here.

    Other arch headers are created as needed on a per-arch basis."

    Fixed up some conflicts from other header file cleanups and moving code
    around that has happened in the meantime, so David's testing is somewhat
    weakened by that. We'll find out anything that got broken and fix it..

    * tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system: (38 commits)
    Delete all instances of asm/system.h
    Remove all #inclusions of asm/system.h
    Add #includes needed to permit the removal of asm/system.h
    Move all declarations of free_initmem() to linux/mm.h
    Disintegrate asm/system.h for OpenRISC
    Split arch_align_stack() out from asm-generic/system.h
    Split the switch_to() wrapper out of asm-generic/system.h
    Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h
    Create asm-generic/barrier.h
    Make asm-generic/cmpxchg.h #include asm-generic/cmpxchg-local.h
    Disintegrate asm/system.h for Xtensa
    Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt]
    Disintegrate asm/system.h for Tile
    Disintegrate asm/system.h for Sparc
    Disintegrate asm/system.h for SH
    Disintegrate asm/system.h for Score
    Disintegrate asm/system.h for S390
    Disintegrate asm/system.h for PowerPC
    Disintegrate asm/system.h for PA-RISC
    Disintegrate asm/system.h for MN10300
    ...

    Linus Torvalds
     
  • Pull MFD changes from Samuel Ortiz:
    - 4 new drivers: Freescale i.MX on-chip Anatop, Ricoh's RC5T583 and
    TI's TPS65090 and TPS65217.
    - New variants support (8420, 8520 ab9540), cleanups and bug fixes for
    the abx500 and db8500 ST-E chipsets.
    - Some minor fixes and update for the wm8994 from Mark.
    - The beginning of a long term TWL cleanup effort coming from the TI
    folks.
    - Various fixes and cleanups for the s5m, TPS659xx, pm860x, and MAX8997
    drivers.

    Fix up trivial conflicts due to duplicate patches and header file
    cleanups ( removal etc).

    * tag 'mfd_3.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: (97 commits)
    gpio/twl: Add DT support to gpio-twl4030 driver
    gpio/twl: Allocate irq_desc dynamically for SPARSE_IRQ support
    mfd: Detach twl6040 from the pmic mfd driver
    mfd: Replace twl-* pr_ macros by the dev_ equivalent and do various cleanups
    mfd: Micro-optimization on twl4030 IRQ handler
    mfd: Make twl4030 SIH SPARSE_IRQ capable
    mfd: Move twl-core IRQ allocation into twl[4030|6030]-irq files
    mfd: Remove references already defineid in header file from twl-core
    mfd: Remove unneeded header from twl-core
    mfd: Make twl-core not depend on pdata->irq_base/end
    ARM: OMAP2+: board-omap4-*: Do not use anymore TWL6030_IRQ_BASE in board files
    mfd: Return twl6030_mmc_card_detect IRQ for board setup
    Revert "mfd: Add platform data for MAX8997 haptic driver"
    mfd: Add support for TPS65090
    mfd: Add some da9052-i2c section annotations
    mfd: Build rtc5t583 only if I2C config is selected to y.
    mfd: Add anatop mfd driver
    mfd: Fix compilation error in tps65910.h
    mfd: Add 8420 variant to db8500-prcmu
    mfd: Add 8520 PRCMU variant to db8500-prcmu
    ...

    Linus Torvalds
     
  • Remove all #inclusions of asm/system.h preparatory to splitting and killing
    it. Performed with the following command:

    perl -p -i -e 's!^#\s*include\s*.*\n!!' `grep -Irl '^#\s*include\s*' *`

    Signed-off-by: David Howells

    David Howells
     

24 Mar, 2012

2 commits

  • Pull cpufreq updates for 3.4 from Dave Jones: new drivers and some fixes.

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
    provide disable_cpufreq() function to disable the API.
    EXYNOS5250: Add support cpufreq for EXYNOS5250
    EXYNOS4X12: Add support cpufreq for EXYNOS4X12
    [CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling
    [CPUFREQ] Add S3C2416/S3C2450 cpufreq driver
    [CPUFREQ] Fix exposure of ARM_EXYNOS4210_CPUFREQ
    [CPUFREQ] EXYNOS4210: update the name of EXYNOS clock register
    [CPUFREQ] EXYNOS: Initialize locking_frequency with initial frequency
    [CPUFREQ] s3c64xx: Fix mis-cherry pick of VDDINT

    Fix up trivial conflicts in Kconfig and Makefile due to just changes
    next to each other (OMAP2PLUS changes vs some new EXYNOS cpufreq
    drivers).

    Linus Torvalds
     
  • Pull cpufreq fixes from Dave Jones:
    "I meant to get some of these in for 3.3 final, but left things too
    late, so I've got two trees this time."

    * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
    cpufreq: OMAP: specify range for voltage scaling
    cpufreq: OMAP: scale voltage along with frequency
    cpufreq: OMAP driver depends CPUfreq tables

    Linus Torvalds
     

15 Mar, 2012

3 commits


07 Mar, 2012

1 commit


03 Mar, 2012

1 commit


01 Mar, 2012

6 commits

  • When a new sampling rate is shorter than the current one, (e.g., 1 sec
    --> 10 ms) regardless how short the new one is, the current ondemand
    mechanism wait for the previously set timer to be expired.

    For example, if the user has just expressed that the sampling rate
    should be 10 ms from now and the previous was 1000 ms, the new rate may
    become effective 999 ms later, which could be not acceptable for the
    user if the user has intended to speed up sampling because the system is
    expected to react to CPU load fluctuation quickly from __now__.

    In order to address this issue, we need to cancel the previously set
    timer (schedule_delayed_work) and reset the timer if resetting timer is
    expected to trigger the delayed_work ealier.

    Signed-off-by: MyungJoo Ham
    Signed-off-by: Kyungmin Park
    Signed-off-by: Dave Jones

    MyungJoo Ham
     
  • The S3C2416/S3C2450 SoCs support two sources for the armclk.

    The first source is the so called armdiv which divides the msysclk down
    to provide necessary cpu rates. In this mode the core voltage must be
    always at 1.3V. The frequency from the armdiv is not allowed to be
    lower than the hclk frequency.

    In the second mode the armclk can be sourced directly from the hclk in
    the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv
    isn't used at all. Also in this mode the core voltage may be lowered.
    Existing hardware and tests with it suggest 1.0V as sufficient.

    When changing the clock source to the armdiv from the hclk, the SoC
    shows stability issues if the new frequency is higher than the current
    hclk frequency. Hence the driver always forces the armdiv to the hclk
    frequency before the source change and lets the cpufreq issue another
    set_target call for higher frequencies.

    To mark the hclk frequency as lower as the corresponding armdiv
    frequency it is set 1MHz below the real frequency. This lets the cpufreq
    framework change between 133MHz based on hclk and 133MHz based on armdiv
    at will.

    Signed-off-by: Heiko Stuebner
    Tested-by: Andrey Gusakov
    Signed-off-by: Dave Jones

    Heiko Stübner
     
  • exynos4210-cpufreq.c is not buildable on non-exynos builds, so it's
    pointless allowing this option to be exposed. Fix this by adding a
    dependency on ARCH_EXYNOS.

    drivers/cpufreq/exynos4210-cpufreq.c:20:29: error: mach/regs-clock.h: No such file or directory
    drivers/cpufreq/exynos4210-cpufreq.c:21:26: error: mach/cpufreq.h: No such file or directory

    Signed-off-by: Russell King
    Cc: cpufreq@vger.kernel.org
    Cc: Kukjin Kim
    Signed-off-by: Dave Jones

    Russell King
     
  • According to replacing the name of EXYNOS clock registers,
    this patch updates exynos4210-cpufreq.c file where it is used.

    Cc: Jaecheol Lee
    Signed-off-by: Kukjin Kim
    Signed-off-by: Dave Jones

    Kukjin Kim
     
  • As per definition, locking_frequency is the initial frequency which is
    set by boot-loader. Hence the value is updated with the initial value
    during boot time init call.

    This code was present in exynos210-cpufreq.c before this consolidation
    patch.
    - a125a17fa61a ([CPUFREQ] EXYNOS: Make EXYNOS common cpufreq driver).

    Signed-off-by: Tushar Behera
    Signed-off-by: Inderpal Singh
    Signed-off-by: Dave Jones

    Tushar Behera
     
  • We don't have any of the other code for VDDINT, including the variable
    declaration, so don't try to get it as we can't build.

    Signed-off-by: Mark Brown
    Signed-off-by: Dave Jones

    Mark Brown
     

22 Feb, 2012

2 commits

  • Use the regulator framework to get the voltage regulator associated
    with the MPU voltage domain and use it to scale voltage along with
    frequency.

    While here, CONFIG_CPU_FREQ_DEBUG doesn't exist anymore, so move
    debug prints to use dev_dbg().

    Special thanks to Afzal Mohammed for suggestions on more robust error
    checking.

    Cc: Afzal Mohammed
    Signed-off-by: Kevin Hilman

    Kevin Hilman
     
  • The OMAP driver depends on CPUfreq table support for creating a table
    of frequencies from the OPP layer. Ensure that it's build to avoid
    link-time errors.

    Signed-off-by: Russell King
    [khilman@ti.com: make user-selectable, but default y]
    Signed-off-by: Kevin Hilman

    Russell King
     

14 Feb, 2012

2 commits

  • Commit fa8031aefec0cf7ea6c2387c93610d99d9659aa2 ('cpufreq: Add support
    for x86 cpuinfo auto loading v4') added a device ID table to this
    driver, but didn't declare it as the module device ID table.

    Signed-off-by: Ben Hutchings
    Acked-by: Thomas Renninger
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     
  • Commit fa8031aefec0cf7ea6c2387c93610d99d9659aa2 ('cpufreq: Add support
    for x86 cpuinfo auto loading v4') seems to have inadvertently changed
    the matched CPU family number from 6 to 7. Change it back.

    Signed-off-by: Ben Hutchings
    Acked-by: Thomas Renninger
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    Ben Hutchings
     

03 Feb, 2012

1 commit


27 Jan, 2012

1 commit

  • This marks all the x86 cpuinfo tables to the CPU specific device drivers,
    to allow auto loading by udev. This should simplify the distribution
    startup scripts for this greatly.

    I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers,
    because those probably shouldn't be auto loaded and the acpi driver
    be used instead (not fully sure on that, would appreciate feedback)

    The old nforce drivers autoload based on the PCI ID.

    ACPI cpufreq is autoloaded in another patch.

    v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones)
    v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading

    Cc: Dave Jones
    Cc: Kay Sievers
    Signed-off-by: Andi Kleen
    Signed-off-by: Thomas Renninger
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    Andi Kleen
     

12 Jan, 2012

1 commit

  • * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: (23 commits)
    [CPUFREQ] EXYNOS: Removed useless headers and codes
    [CPUFREQ] EXYNOS: Make EXYNOS common cpufreq driver
    [CPUFREQ] powernow-k8: Update copyright, maintainer and documentation information
    [CPUFREQ] powernow-k8: Fix indexing issue
    [CPUFREQ] powernow-k8: Avoid Pstate MSR accesses on systems supporting CPB
    [CPUFREQ] update lpj only if frequency has changed
    [CPUFREQ] cpufreq:userspace: fix cpu_cur_freq updation
    [CPUFREQ] Remove wall variable from cpufreq_gov_dbs_init()
    [CPUFREQ] EXYNOS4210: cpufreq code is changed for stable working
    [CPUFREQ] EXYNOS4210: Update frequency table for cpu divider
    [CPUFREQ] EXYNOS4210: Remove code about bus on cpufreq
    [CPUFREQ] s3c64xx: Use pr_fmt() for consistent log messages
    cpufreq: OMAP: fixup for omap_device changes, include
    cpufreq: OMAP: fix freq_table leak
    cpufreq: OMAP: put clk if cpu_init failed
    cpufreq: OMAP: only supports OPP library
    cpufreq: OMAP: dont support !freq_table
    cpufreq: OMAP: deny initialization if no mpudev
    cpufreq: OMAP: move clk name decision to init
    cpufreq: OMAP: notify even with bad boot frequency
    ...

    Linus Torvalds
     

09 Jan, 2012

1 commit