lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 28 Apr 2021 15:36:37 -0700
From:   Subbaraman Narayanamurthy <subbaram@...eaurora.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     aghayal@...eaurora.org, collinsd@...eaurora.org,
        fenglinw@...eaurora.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Add QCOM PMIC PWM driver

On 4/28/21 1:06 PM, Bjorn Andersson wrote:
> On Wed 28 Apr 13:49 CDT 2021, Subbaraman Narayanamurthy wrote:
>
>>>> Add PWM driver to support PWM modules inside QCOM PMIC chips which are accessed
>>>> through SPMI bus. Normally, there would be multiple PWM modules with adjacent
>>>> address spaces present in one PMIC chip, and each PWM module has 0x100 size of
>>>> address space. With this driver, a pwm_chip with multiple pwm_device individuals
>>>> is created, and each pwm_device individual is corresponding to one PWM module.
>>>>
>>> Exposing this as individual pwm_chips will prevent us from enabling the
>>> LED related use cases (patterns and multicolor) that most versions of
>>> the hardware support.
>>> I proposed [1] a while ago and think this is a better approach. I'll
>>> take some time to respin this and send out the next version.
>>> [1] https://lore.kernel.org/linux-arm-msm/20201021201224.3430546-1-bjorn.andersson@linaro.org/
>> Hi Bjorn,
>> Yes, we came across this patch series but this driver (leds-qcom-lpg) is a
>> combo one which provides support only for RGB LEDs (or TRI_LED module) along
>> with PWM/LPG channels allocated for it. Say, if we've additional PWM channels
>> on the same PMIC (that provides user-interface support) or another PMIC
>> (non user-interface) that has multiple PWM channels that are not used for LED
>> notifications, it would be good to have a separate PWM driver to support such
>> channels IMHO. There are couple of use cases we've come across recently.
>>
>> 1. Using a PWM channel for controlling external LCD backlight controller
>> 2. Using a PWM channel for controlling a haptics actuator
>>
> The LPG driver, as it's currently written, support using each channel as
> a LED, part of a multicolor LED or as a pwm_chip. It's been tested on
> pm8916 (which doesn't have triled or the lut), pm*8994, pmi8996 and
> pm8150* in various combinations.
Thanks for the confirmation. I must have looked at your earlier patchset which only was registering with LED class framework and not having support to register with PWM framework for the channels that're not used for LEDs.
> In particular the PWM-only modes that you describe here is how the
> driver has been used on db410c, for driving the "backlight GPIO" in the
> low-speed connector.
Yes, that should cover the use cases I was mentioning. We will look into your patch series to see if it can support our requirements.
> Regards,
> Bjorn


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ