06 Sep, 2020

1 commit

  • PWM controller drivers should not restore the PWM state on resume. The
    convention is that PWM consumers do this by calling pwm_apply_state(),
    so that it can be done at the exact moment when the consumer needs
    the state to be stored, avoiding e.g. backlight flickering.

    The only in kernel consumers of the pwm-lpss code, the i915 driver
    and the pwm-class sysfs interface code both correctly restore the
    state on resume, so there is no need to do this in the pwm-lpss code.

    More-over the removed resume handler is buggy, since it blindly
    restores the ctrl-register contents without setting the update
    bit, which is necessary to get the controller to actually use/apply
    the restored base-unit and on-time-div values.

    Acked-by: Thierry Reding
    Signed-off-by: Hans de Goede
    Reviewed-by: Andy Shevchenko
    Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-8-hdegoede@redhat.com

    Hans de Goede
     

19 Jun, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 4122 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Kate Stewart
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

16 Oct, 2018

1 commit

  • On Cherry Trail devices under Windows the PWM controller used for the
    backlight is considered part of the GPU even though it is part of the LPSS
    block and thus is an entirely different independent hardware unit.

    Because of this on Cherry Trail the GPU's (GFX0 ACPI node) _PS3 and _PS0
    methods save and restore the PWM controller registers.

    If userspace blanks the screen before suspending, such as e.g. GNOME
    does, then the PWM controller will be runtime-suspended when the suspend
    starts. This causes the GFX0 _PS? methods to save a value of 0xffffffff
    for the PWM control register and to restore this value on resume.

    0xffffffff is not a valid value for the register and writing this causes
    problems such as e.g. a flickering backlight.

    This commit adds a prepare method to the dev_pm_ops and makes it return 0
    on Cherry Trail devices forcing a runtime-resume before other device's
    suspend methods run. This fixes the reading and writing back of 0xffffffff.

    Since we now always runtime-resume the device on suspend, it will be
    resumed on resume too and we no longer need to check for the GFX0 _PS0
    method having resumed it underneath us, so this commit removes the now no
    longer necessary complete dev_pm_op.

    Signed-off-by: Hans de Goede
    Signed-off-by: Thierry Reding

    Hans de Goede
     

12 Oct, 2018

2 commits

  • The _PS0 method for the integrated graphics on some Cherry Trail devices
    (observed on a HP Pavilion X2 10-p0XX) turns on the PWM chip (puts it in
    D0), causing an inconsistency between the state the pm-core thinks it is
    in (left runtime suspended as it was before the suspend/resume) and the
    state it actually is in.

    Interestingly enough this is done on a device where the pwm controller is
    not used for the backlight at all, since it uses an eDP panel. On devices
    where the PWM is used this is not a problem since we will resume it
    ourselves anyways.

    This inconsistency causes us to never suspend the pwm controller again,
    which causes the device to not be able to reach S0ix states when suspended.

    This commit adds a resume-complete handler, which when we think the device
    is still run-time suspended checks the actual power-state and if necessary
    updates the rpm-core's internal state.

    This fixes the Pavilion X2 10-p0XX not reaching S0ix states when suspended.

    Reviewed-by: Andy Shevchenko
    Signed-off-by: Hans de Goede
    Signed-off-by: Thierry Reding

    Hans de Goede
     
  • Move struct pwm_lpss_chip definition from pwm-lpss.c to pwm-lpss.h,
    so that the pci/platform drivers can access the info member
    (struct pwm_lpss_boardinfo *).

    This is a preparation patch for adding platform specific quirks, which
    the drivers need access to, to pwm_lpss_boardinfo.

    Reviewed-by: Andy Shevchenko
    Signed-off-by: Hans de Goede
    Signed-off-by: Thierry Reding

    Hans de Goede
     

06 Jun, 2018

1 commit

  • On some devices the contents of the ctrl register get lost over a
    suspend/resume and the PWM comes back up disabled after the resume.

    This is seen on some Bay Trail devices with the PWM in ACPI enumerated
    mode, so it shows up as a platform device instead of a PCI device.

    If we still think it is enabled and then try to change the duty-cycle
    after this, we end up with a "PWM_SW_UPDATE was not cleared" error and
    the PWM is stuck in that state from then on.

    This commit adds suspend and resume pm callbacks to the pwm-lpss-platform
    code, which save/restore the ctrl register over a suspend/resume, fixing
    this.

    Note that:

    1) There is no need to do this over a runtime suspend, since we
    only runtime suspend when disabled and then we properly set the enable
    bit and reprogram the timings when we re-enable the PWM.

    2) This may be happening on more systems then we realize, but has been
    covered up sofar by a bug in the acpi-lpss.c code which was save/restoring
    the regular device registers instead of the lpss private registers due to
    lpss_device_desc.prv_offset not being set. This is fixed by a later patch
    in this series.

    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Thierry Reding

    Hans de Goede
     

06 Apr, 2017

1 commit

  • At least on cherrytrail, the update bit will never go low when the
    enabled bit is not set.

    This causes the backlight on my cube iwork8 air tablet to never turn on
    again after being turned off because in the pwm_lpss_apply enable path
    pwm_lpss_update will fail causing an error exit and the enable-bit to
    never get set. Any following pwm_lpss_apply calls will fail the
    pwm_lpss_is_updating check.

    Since the docs say that the update bit should be set before the
    enable-bit, split pwm_lpss_update into setting the update-bit and
    pwm_lpss_wait_for_update, and move the pwm_lpss_wait_for_update call
    in the enable path to after setting the enable-bit.

    Fixes: 10d56a4 ("pwm: lpss: Avoid reconfiguring while UPDATE bit...")
    Cc: Ilkka Koskinen
    Signed-off-by: Hans de Goede
    Signed-off-by: Andy Shevchenko
    Tested-by: Hans de Goede
    Signed-off-by: Thierry Reding

    Hans de Goede
     

30 Jan, 2017

1 commit

  • The PWM LPSS probe drivers just pass a pointer to the exported board
    info structures to pwm_lpss_probe() based on device PCI or ACPI ID.

    In order to remove the knowledge of specific devices from library part of
    the driver and reduce noise in exported namespace just duplicate the
    board info structures and stop exporting them.

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Thierry Reding

    Andy Shevchenko
     

16 Dec, 2015

1 commit

  • For Broxton PWM controller, base unit is defined as 8-bit integer
    and 14-bit fraction, so need to update base unit setting to output
    wave with right frequency.

    Signed-off-by: Qipeng Zha
    Acked-by: Mika Westerberg
    Signed-off-by: Thierry Reding

    qipeng.zha
     

06 Nov, 2015

2 commits


23 Aug, 2014

1 commit

  • The driver consists of core, PCI, and platform parts. It would be better
    to split them into separate files.

    The platform driver is now called pwm-lpss-platform. Thus, previously
    set CONFIG_PWM_LPSS=m is not enough to build it. But we are on the safe
    side since it seems no one from outside Intel is using it for now.

    While here, move to use macros module_pci_driver() and
    module_platform_driver().

    Signed-off-by: Andy Shevchenko
    Reviewed-by: Mika Westerberg
    Acked-by: Alan Cox
    [thierry.reding: change select to depends on PWM_LPSS, cleanup]
    Signed-off-by: Thierry Reding

    Andy Shevchenko