Re: [PATCH RESEND] arm64: dts: qcom: Add support for OnePlus 5/5T
};
+ };
+};
+
+ {
+ gpio-reserved-ranges = <0 4>, <81 4>;
+
+ hall_sensor_default: hall-sensor-default {
+ pins = "gpio124";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ input-enable;
+ };
+
+ ts_int_active: ts-int-active {
+ pins = "gpio125";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ ts_reset_active: ts-reset-active {
+ pins = "gpio89";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+ {
+ status = "okay";
+
+ vcc-supply = <_l20a_2p95>;
+ vccq-supply = <_l26a_1p2>;
+ vccq2-supply = <_s4a_1p8>;
+ vcc-max-microamp = <75>;
+ vccq-max-microamp = <56>;
+ vccq2-max-microamp = <75>;
+};
+
+ {
+ status = "okay";
+
+ vdda-phy-supply = <_l1a_0p875>;
+ vdda-pll-supply = <_l2a_1p2>;
+ vddp-ref-clk-supply = <_l26a_1p2>;
+ vdda-phy-max-microamp = <51400>;
+ vdda-pll-max-microamp = <14600>;
+ vddp-ref-clk-max-microamp = <100>;
+ vddp-ref-clk-always-on;
+};
+
+ {
+ status = "okay";
+
+ /* Disable USB3 clock requirement as the device only supports USB2
*/
+ qcom,select-utmi-as-pipe-clk;
+};
+
+_dwc3 {
+ /* Drop the unused USB 3 PHY */
+ phys = <>;
+ phy-names = "usb2-phy";
+
+ /* Fastest mode for USB 2 */
+ maximum-speed = "high-speed";
+
+ /* Force to peripheral until we can switch modes */
+ dr_mode = "peripheral";
+};
+
+/* Hold off on WLAN enablement until MSS remoteproc and friends are
brought up */
+ {
+ vdd-0.8-cx-mx-supply = <_l5a_0p8>;
+ vdd-1.8-xo-supply = <_l7a_1p8>;
+ vdd-1.3-rfa-supply = <_l17a_1p3>;
+ vdd-3.3-ch0-supply = <_l25a_3p3>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
new file mode 100644
index ..b46214a32478
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OnePlus 5T (dumpling) device tree
+ *
+ * Copyright (c) 2021, Jami Kettunen
+ */
+
+#include "msm8998-oneplus-common.dtsi"
+
+/ {
+ model = "OnePlus 5T";
+ compatible = "oneplus,dumpling", "qcom,msm8998";
+ /* Required for bootloader to select correct board */
+ qcom,board-id = <8 0 17801 43>;
+};
+
+/* Update the screen height values from 1920 to 2160 on the 5T */
+ {
+ height = <2160>;
+};
+
+/* Adjust digitizer area height to match the 5T's taller panel */
+_f12 {
+ touchscreen-y-mm = <137>;
+};
--
2.30.1
Only thing i would nit pick about it is to split it into 2 commits
maybe.
Other than that nothing.
Reviewed-by: Martin Botka
Re: [PATCH 34/41] arm64: dts: qcom: sdm630-nile: Configure WCN3990 Bluetooth
Signed-off-by: Martin Botka Sorry for the second Sob. Previous one was HTML. Sorry On Sat, Feb 27, 2021 at 11:40, Konrad Dybcio wrote: From: AngeloGioacchino Del Regno From: Martin Botka That got caught in rebasing madness.. Should any additional mistakes appear, I'll send a V2. Konrad
Re: [PATCH v5 2/4] leds: Add driver for Qualcomm LPG
Hi! > I was trying to use obviously bogus numbers to make you to specify > which patches you reviewed :-). A now that makes much more sense. I reviewed patch 2. Tho from the quick look i dont see anything wrong with the DTS changes either.
Re: [PATCH v5 2/4] leds: Add driver for Qualcomm LPG
> Good way to say that is "Patches 7 and 28, Reviewed-by:"... 7 and 28 ? I dont see any patches 7 and 28 (I assume thats a typo for 8) Either way. Reviewed-by: Martin Botka
Re: [PATCH v4 1/2] dt-bindings: interconnect: Add bindings for Qualcomm SDM660 NoC
> Documentation/devicetree/bindings/interconnect/qcom,sdm660.example.dts:20:18: > fatal error: dt-bindings/clock/qcom,mmcc-sdm660.h: No such file or directory >20 | #include > | ^~ This patch depends on my MMCC patch (sent by angelo).
Re: [PATCH v5 2/4] leds: Add driver for Qualcomm LPG
With the changes done to in V5 i have nothing to add.
Re: [PATCH 1/5] clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver
Actually, correction. This parent is used by cpp_clk_src.
Re: [PATCH 1/5] clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver
Yes, The unused parent map should be removed and resent.
Re: [PATCH 3/7] drm/msm/a5xx: Add support for Adreno 508, 509, 512 GPUs
Tested on Xperia 10 Tested-by: Martin Botka
Re: [PATCH 5/5] dt-bindings: clock: Add QCOM SDM630 and SDM660 graphics clock bindings
Tested on Xperia 10 Tested-by: Martin Botka
Re: [PATCH 4/5] clk: qcom: Add SDM660 GPU Clock Controller (GPUCC) driver
Tested on Xperia 10 Tested-by: Martin Botka
Re: [PATCH] phy: qcom-qusb2: Add support for SDM630/660
Tested on Xperia 10 Tested-by: Martin Botka
Re: [PATCH 1/5] clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver
Tested-by: Martin Botka
Re: [PATCH RFC 3/6] pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module
Hello, Mo 27. 7. 2020 at 22:10 Uwe Kleine-König wrote: > > On Fri, Jul 24, 2020 at 11:36:53PM +0200, Martin Botka wrote: > > From: Fenglin Wu > > > > Add pwm_chip to support QTI LPG module and export LPG channels as > > PWM devices for consumer drivers' usage. > > > > Signed-off-by: Fenglin Wu > > [martin.bot...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8] > > Signed-off-by: Martin Botka > > --- > > drivers/pwm/Kconfig | 10 + > > drivers/pwm/Makefile |1 + > > drivers/pwm/pwm-qti-lpg.c | 1284 + > > 3 files changed, 1295 insertions(+) > > create mode 100644 drivers/pwm/pwm-qti-lpg.c > > > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > > index cb8d739067d2..8a52d6884a9a 100644 > > --- a/drivers/pwm/Kconfig > > +++ b/drivers/pwm/Kconfig > > @@ -399,6 +399,16 @@ config PWM_RCAR > > To compile this driver as a module, choose M here: the module > > will be called pwm-rcar. > > > > +config PWM_QTI_LPG > > + tristate "Qualcomm Technologies, Inc. LPG driver" > > + depends on MFD_SPMI_PMIC && OF > > + help > > + This driver supports the LPG (Light Pulse Generator) module found in > > + Qualcomm Technologies, Inc. PMIC chips. Each LPG channel can be > > + configured to operate in PWM mode to output a fixed amplitude with > > + variable duty cycle or in LUT (Look up table) mode to output PWM > > + signal with a modulated amplitude. > > + > > config PWM_RENESAS_TPU > > tristate "Renesas TPU PWM support" > > depends on ARCH_RENESAS || COMPILE_TEST > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > > index a59c710e98c7..3555a6aa3f33 100644 > > --- a/drivers/pwm/Makefile > > +++ b/drivers/pwm/Makefile > > @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o > > obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o > > obj-$(CONFIG_PWM_PXA)+= pwm-pxa.o > > obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o > > +obj-$(CONFIG_PWM_QTI_LPG)+= pwm-qti-lpg.o > > Please keep this list alphabetically sorted. OK > > > obj-$(CONFIG_PWM_RENESAS_TPU)+= pwm-renesas-tpu.o > > obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o > > obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o > > diff --git a/drivers/pwm/pwm-qti-lpg.c b/drivers/pwm/pwm-qti-lpg.c > > new file mode 100644 > > index ..d24c3b3a3d8c > > --- /dev/null > > +++ b/drivers/pwm/pwm-qti-lpg.c > > @@ -0,0 +1,1284 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Copyright (c) 2020, The Linux Foundation. All rights reserved. > > + */ > > + > > +#define pr_fmt(fmt) "%s: " fmt, __func__ > > This smells like debug stuff. Please drop this. What do you mean ? The #define pr_fmt(fmt) or the tons of REG definitions ? > > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define REG_SIZE_PER_LPG 0x100 > > +#define LPG_BASE "lpg-base" > > +#define LUT_BASE "lut-base" > > + > > +/* LPG module registers */ > > +#define REG_LPG_PERPH_SUBTYPE 0x05 > > +#define REG_LPG_PATTERN_CONFIG 0x40 > > +#define REG_LPG_PWM_SIZE_CLK 0x41 > > +#define REG_LPG_PWM_FREQ_PREDIV_CLK 0x42 > > +#define REG_LPG_PWM_TYPE_CONFIG 0x43 > > +#define REG_LPG_PWM_VALUE_LSB 0x44 > > +#define REG_LPG_PWM_VALUE_MSB 0x45 > > +#define REG_LPG_ENABLE_CONTROL 0x46 > > +#define REG_LPG_PWM_SYNC 0x47 > > +#define REG_LPG_RAMP_STEP_DURATION_LSB 0x50 > > +#define REG_LPG_RAMP_STEP_DURATION_MSB 0x51 > > +#define REG_LPG_PAUSE_HI_MULTIPLIER 0x52 > > +#define REG_LPG_PAUSE_LO_MULTIPLIER 0x54 > > +#define REG_LPG_HI_INDEX 0x56 > > +#define REG_LPG_LO_INDEX 0x57 > > + > > +/* REG_LPG_PATTERN_CONFIG */ > > +#define LPG_PATTERN_EN_PAUSE_LO BIT(0) > > +#define LPG_PATTERN_EN_PAUSE_HI BIT(1) > > +#define LPG_PATTERN_RAMP_TOGGLE BIT(2) > > +#define LPG_PATTERN_REPEAT BIT(3) > > +#define LPG_PATTERN_RAMP_LO_TO_HI BIT(4) > > + > > +/* REG_LPG_PERPH_SUBTYPE */ > > +#define SUBTYPE_PWM 0x0b > > +#define SUBTYPE_LPG_LITE 0x11 > > + > > +/* REG_LPG_PWM_SIZE_CLK */ > > +#define LPG_PWM_SIZE_LPG_MASK BIT(4
Re: [PATCH RCC 1/6] pwm: Add different PWM output types support
Mo 27. 7. 2020 at 22:10 Uwe Kleine-König wrote:
>
> Hello,
>
> On Fri, Jul 24, 2020 at 11:36:51PM +0200, Martin Botka wrote:
> > From: Fenglin Wu
> >
> > Normally, PWM channel has fixed output until software request to change
>
> "fixed" in the sense of "periodic", not "constant", right?
Correct.
>
> > its settings. There are some PWM devices which their outputs could be
> > changed autonomously according to a predefined pattern programmed in
> > hardware. Add pwm_output_type enum type to identify these two different
> > PWM types and add relevant helper functions to set and get PWM output
> > types and pattern.
>
> You write "some devices". Which do you have in mind?
As can be seen this commit is not authored by me so the commit message
is from the original author.
So i don't know what the original author meant here.
I can only guess that s/he meant all the PWM chips made by Qcom or
other companies that also have hardware based support for patterns.
>
> > [...]
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index 2389b8669846..4ee1e81db0bc 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
>
> adapting the sysfs stuff should be done in a separate step.
By that you mean in separate commit right ?
>
> > @@ -215,11 +215,60 @@ static ssize_t capture_show(struct device *child,
> > return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
> > }
> >
> > +static ssize_t output_type_show(struct device *child,
> > + struct
> > device_attribute *attr,
> > + char *buf)
> > +{
> > + const struct pwm_device *pwm = child_to_pwm_device(child);
> > + const char *output_type = "unknown";
> > + struct pwm_state state;
> > +
> > + pwm_get_state(pwm, );
> > + switch (state.output_type) {
> > + case PWM_OUTPUT_FIXED:
> > + output_type = "fixed";
> > + break;
> > + case PWM_OUTPUT_MODULATED:
> > + output_type = "modulated";
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + return snprintf(buf, PAGE_SIZE, "%s\n", output_type);
> > +}
> > +
> > +static ssize_t output_type_store(struct device *child,
> > + struct
> > device_attribute *attr,
> > + const char
> > *buf, size_t size)
>
> Indention is broken here. Please align to the opening (.
OK. Will do.
>
> > +{
> > + struct pwm_export *export = child_to_pwm_export(child);
> > + struct pwm_device *pwm = export->pwm;
> > + struct pwm_state state;
> > + int ret = -EINVAL;
> > +
> > + mutex_lock(>lock);
> > + pwm_get_state(pwm, );
> > + if (sysfs_streq(buf, "fixed"))
> > + state.output_type = PWM_OUTPUT_FIXED;
> > + else if (sysfs_streq(buf, "modulated"))
> > + state.output_type = PWM_OUTPUT_MODULATED;
> > + else
> > + goto unlock;
> > +
> > + ret = pwm_apply_state(pwm, );
> > +unlock:
> > + mutex_unlock(>lock);
> > +
> > + return ret ? : size;
> > +}
> > +
> > static DEVICE_ATTR_RW(period);
> > static DEVICE_ATTR_RW(duty_cycle);
> > static DEVICE_ATTR_RW(enable);
> > static DEVICE_ATTR_RW(polarity);
> > static DEVICE_ATTR_RO(capture);
> > +static DEVICE_ATTR_RW(output_type);
> >
> > static struct attribute *pwm_attrs[] = {
> > _attr_period.attr,
> > @@ -227,6 +276,7 @@ static struct attribute *pwm_attrs[] = {
> > _attr_enable.attr,
> > _attr_polarity.attr,
> > _attr_capture.attr,
> > + _attr_output_type.attr,
> > NULL
> > };
> > ATTRIBUTE_GROUPS(pwm);
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > index 2635b2a55090..10a102efadc4 100644
> > --- a/include/linux/pwm.h
> > +++ b/include/linux/pwm.h
> > @@ -48,6 +48,29 @@ enum {
> > PWMF_EXPORTED = 1 << 1,
> > };
> >
> > +/*
> > + * enum pwm_output_type - output type of the PWM signal
> > + * @PWM_OUTPUT_FIXED: PWM output is fixed until a change request
> > + * @PWM_OUTPUT_MODULATED: PWM output is modulated in hardware
> > + * autonomously with a
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
Hello, > I hit "reply-to-all" and the mail only was sent to you because you wrote > to only me. Yes my reply was only to you. But your original message was sent only to me too. So when i clicked reply to all it was only you as you sent it only to me. > Also threading is somehow strange because your reply to my mail Yes Gmail would not allow me to reply to your message and also send it to everyone so i had to reply to Andy's email which is why the threading is broken there. Sorry for that. > So I assume all the strange things happened on your side until proved > otherwise. :-) I think i just proved otherwise :) Best Regards, Martin
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
> Could you please send the messages also to everyone else ? Next time of course.
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
Hello Uwe, On Sat, Jul 25, 2020 at 09:12:23PM +0200, Martin Botka wrote: >> > Note there is already a series that changes these values to u64. See >> > a9d887dc1c60ed67f2271d66560cdcf864c4a578 in linux-next. >> >> Amazing. But isn't there the same issue with it as this one where this >> would fail to build on 32 bit architecture? > > In theory all these cases are coped for. I didn't see any problems yet, > so I still assume also the 32 bit archs are fine. OK then all is fine. I will drop the patch in V2. Also Uwe i just realized that you sent the original message and also this reply only to me and not to anyone else. Could you please send the messages also to everyone else ? Thank you. Best regards, Martin
Re: [PATCH RFC 4/6] leds: leds-qti-tri-led: Add LED driver for QTI TRI_LED module
Hello. This driver has the breath feature of the driver broken as I sent a slightly modified version of it from when I was testing it. The proper version will come when i will be sending out V2 which will be hopefully soon as I'm little busy. Best regards Martin
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
> And all divisions go mad on 32-bit CPU, right? > Please, if you thought about it carefully, update a commit message to > clarify that. Hello, This patch will be dropped in V2 since another series already made these u64. See a9d887dc1c60ed67f2271d66560cdcf864c4a578 in linux-next. I have not tested compiling that commit in linux-next on 32 bit arch but if it fails i can replace this commit with fix for that. Also I'm not the author of this commit. Konrad Dybcio fast forwarded it to 5.8 from 4.14. Fenglin Wu is the author and also created that commit message. Thank you. Best regards Martin
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
> +#include > - gain_q23 = (gain_q23 * dmic->boost_gain) / 100; > + gain_q23 = div_u64(gain_q23 * dmic->boost_gain, 100); Ok so using a macro. Thank you.
Re: [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
Hello, As can be seen this divides llu by llu in few warnings and error. At the time of sending i didn't realize it but this fails on 32 bit architectures. So i would like to ask how would you like this fixed ? Using macro or some other way ? Thank you. Best regards, Martin
Re: [PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers
> First copy was ok. Second had broken formatting. Both were plaintext > AFAICT. It's just that gmail was telling me that it didn't send it to some of the email addresses because i forgot to check the "Use plain text" in Gmail.
Re: [PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers
> Vitej do klubu :-). Dakujem > Please double check. Actually, is the series for one chip or for two > of them? LED framework should is happy to talk to generic pwm driver... I'm not sure on that one. I will have to talk to some people about that. I will get back to you on that when i find out how it actually is. But i think its one single chip. Not sure tho. > Ok. Check multicolor framework in -next. I will look into it. Thank you > Aha, ok. I assume they are still quite far away from being usable with > mainline kernels. Actually no. While Konrad didn't send the patches yet we have some stuff working as: Panel Touchscreen LEDs with this series Flash light You can check https://github.com/konradybcio/linux/commits/ninges_labs for the current progress on those phones. Best Regards, Martin
Re: [PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers
Hi, Dalsi cech co hackuje LEDky? Nie. Slovak. Bindings should go first, they may need to be converted to yml (devicetree people will know). OK Can generic pwm driver be used here? I have not tried to do that. But considering it's custom chip from Qualcomm then it's unlikely. This is for RGB modules, right? It will need to use multicolor framework. This is for RGB LEDs in phones that are connected via pmic. Is this for phone, btw? If so, which one? Yes it is. And it's for many many phones actually. I have done this mainly for SONY phones (Xperia 10, 10 Plus, XA2, XA2 Plus, XA2 Ultra). All of them use these drivers for generating the PWM and controlling the LEDs. P.S resending because i sent it as HTML apparently. Best Regards, Martin
[PATCH RFC 6/6] Documentation: Add binding for pwm-qti-lpg
From: Fenglin Wu Add documentation for pwm-qti-lpg Signed-off-by: Fenglin Wu Signed-off-by: Martin Botka --- .../devicetree/bindings/pwm/pwm-qti-lpg.txt | 163 ++ 1 file changed, 163 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-qti-lpg.txt diff --git a/Documentation/devicetree/bindings/pwm/pwm-qti-lpg.txt b/Documentation/devicetree/bindings/pwm/pwm-qti-lpg.txt new file mode 100644 index ..df2810626da4 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-qti-lpg.txt @@ -0,0 +1,163 @@ +Qualcomm Technologies, Inc. LPG driver specific bindings + +This binding document describes the properties of LPG (Light Pulse Generator) +device module in Qualcomm Technologies, Inc. PMIC chips. + +- compatible: + Usage: required + Value type: + Definition: Must be "qcom,pwm-lpg". + +- reg: + Usage: required + Value type: + Definition: Register base for LPG and LUT modules. + +- reg-names: + Usage: required + Value type: + Definition: The name of the register defined in the reg property. + It must have "lpg-base", "lut-base" is optional but + it's required if any LPG channels support LUT mode. + +- #pwm-cells: + Usage: required + Value type: + Definition: The number of cells in "pwms" property specified in + PWM user nodes. It should be 2. The first cell is + the PWM channel ID indexed from 0, and the second + cell is the PWM default period in nanoseconds. + +- qcom,num-lpg-channels: + Usage: required + Value type: + Definition: The number of the consecutive LPG/PWM channels in the chip. + +- qcom,lut-patterns: + Usage: optional + Value type: + Definition: Duty ratios in percentages for LPG working at LUT mode. + These duty ratios will be translated into PWM values + and stored in LUT module. The LUT module has resource + to store 47 PWM values at max and shared for all LPG + channels. This property is required if any LPG channels + support LUT mode. + +- qcom,sync-channel-ids: + Usage: optional + Value type: + Definition: The hardware IDs of the LPG channel that required be + grouped together. These channels will share the same LUT + ramping configuration so that they will be enabled with a + synchronized pattern. If the LUT ramping configuration + differs for the channels grouped for synchronization, + configuration of the first channel will be applied for + all others. + +Subnode is optional if LUT mode is not required, it's required if any LPG +channels expected to be supported in LUT mode. + +Subnode properties: +Subnodes for each LPG channel (lpg@X) can be defined if any of the following +parameters needs to be configured for that channel. + +- qcom,lpg-chan-id: + Usage: required + Value type: + Definition: The LPG channel's hardware ID indexed from 1. Allowed + range is 1 - 8. Maximum value depends on the number of + channels supported on PMIC. + +- qcom,ramp-step-ms: + Usage: required + Value type: + Definition: The step duration in milliseconds for LPG staying at each + duty specified in the LUT pattern. Allowed range is + 1 - 511. + +- qcom,ramp-high-index: + Usage: required + Value type: + Definition: The high index of the LUT pattern where LPG ends up + ramping to. Allowed range is 1 - 47. + +- qcom,ramp-low-index: + Usage: required + Value type: + Definition: The low index of the LUT pattern from where LPG begins + ramping from. Allowed range is 0 - 46. + +- qcom,ramp-from-low-to-high: + Usage: optional + Value type: + Definition: The flag to specify the LPG ramping direction. The ramping + direction is from low index to high index of the LUT + pattern if it's specified. + +- qcom,ramp-pattern-repeat: + Usage: optional + Value type: + Definition: The flag to specify if LPG would be ramping with the LUT + pattern repeatedly. + +- qcom,ramp-toggle: + Usage: optional + Value type: + Definition: The flag to specify if LPG would toggle the LUT pattern + in ramping. If toggling enabled, LPG would return to the + low index when high index is reached, or return to the high + index when low index is reached. + +- qcom,ramp-pause-hi-count: + Usage: optional + Value type: +
[PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers
Hello, This series brings QCOM pwm-lpg and tri-led drivers from 4.14 that is required to support pmic-connected notification LED. This comes straight from downstream and I'm ready for your comments. Fenglin Wu (6): pwm: Add different PWM output types support pwm: core: Add option to config PWM duty/period with u64 data length pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module leds: leds-qti-tri-led: Add LED driver for QTI TRI_LED module Documentation: Add binding for qti-tri-led Documentation: Add binding for pwm-qti-lpg .../bindings/leds/leds-qti-tri-led.txt| 72 + .../devicetree/bindings/pwm/pwm-qti-lpg.txt | 163 +++ drivers/leds/Kconfig |9 + drivers/leds/Makefile |1 + drivers/leds/leds-qti-tri-led.c | 640 drivers/pwm/Kconfig | 10 + drivers/pwm/Makefile |1 + drivers/pwm/core.c| 56 +- drivers/pwm/pwm-qti-lpg.c | 1284 + drivers/pwm/sysfs.c | 56 +- include/linux/pwm.h | 144 +- 11 files changed, 2418 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-qti-tri-led.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-qti-lpg.txt create mode 100644 drivers/leds/leds-qti-tri-led.c create mode 100644 drivers/pwm/pwm-qti-lpg.c -- 2.27.0
[PATCH RFC 4/6] leds: leds-qti-tri-led: Add LED driver for QTI TRI_LED module
From: Fenglin Wu
QTI TRI_LED module has 3 current sinks at max for LED driver and
each is controlled by a PWM channel used for LED dimming or blinking.
Add the driver to support it.
Signed-off-by: Fenglin Wu
[martin.botka1@@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8]
Signed-off-by: Martin Botka
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-qti-tri-led.c | 640
3 files changed, 650 insertions(+)
create mode 100644 drivers/leds/leds-qti-tri-led.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ed943140e1fd..37beff922945 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -768,6 +768,15 @@ config LEDS_POWERNV
To compile this driver as a module, choose 'm' here: the module
will be called leds-powernv.
+config LEDS_QTI_TRI_LED
+ tristate "LED support for Qualcomm Technologies, Inc. TRI_LED"
+ depends on LEDS_CLASS && MFD_SPMI_PMIC && PWM && OF
+ help
+ This driver supports the TRI_LED module found in Qualcomm
+ Technologies, Inc. PMIC chips. TRI_LED supports 3 LED drivers
+ at max and each is controlled by a PWM channel used for dimming
+ or blinking.
+
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d6b8a792c936..16a5be936178 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_LEDS_BCM6328)+= leds-bcm6328.o
obj-$(CONFIG_LEDS_BCM6358) += leds-bcm6358.o
obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
+obj-$(CONFIG_LEDS_QTI_TRI_LED) += leds-qti-tri-led.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
diff --git a/drivers/leds/leds-qti-tri-led.c b/drivers/leds/leds-qti-tri-led.c
new file mode 100644
index ..ea5069e22662
--- /dev/null
+++ b/drivers/leds/leds-qti-tri-led.c
@@ -0,0 +1,640 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TRILED_REG_TYPE 0x04
+#define TRILED_REG_SUBTYPE 0x05
+#define TRILED_REG_EN_CTL 0x46
+
+/* TRILED_REG_EN_CTL */
+#define TRILED_EN_CTL_MASK GENMASK(7, 5)
+#define TRILED_EN_CTL_MAX_BIT 7
+
+#define TRILED_TYPE 0x19
+#define TRILED_SUBTYPE_LED3H0L12 0x02
+#define TRILED_SUBTYPE_LED2H0L12 0x03
+#define TRILED_SUBTYPE_LED1H2L12 0x04
+
+#define TRILED_NUM_MAX 3
+
+#define PWM_PERIOD_DEFAULT_NS 100
+
+struct pwm_setting {
+ u64 pre_period_ns;
+ u64 period_ns;
+ u64 duty_ns;
+};
+
+struct led_setting {
+ u64 on_ms;
+ u64 off_ms;
+ enum led_brightness brightness;
+ bool blink;
+ bool breath;
+};
+
+struct qpnp_led_dev {
+ struct led_classdev cdev;
+ struct pwm_device *pwm_dev;
+ struct pwm_setting pwm_setting;
+ struct led_setting led_setting;
+ struct qpnp_tri_led_chip *chip;
+ struct mutex lock;
+ const char *label;
+ const char *default_trigger;
+ u8 id;
+ bool blinking;
+ bool breathing;
+};
+
+struct qpnp_tri_led_chip {
+ struct device *dev;
+ struct regmap *regmap;
+ struct qpnp_led_dev *leds;
+ struct nvmem_device *pbs_nvmem;
+ struct mutex bus_lock;
+ int num_leds;
+ u16 reg_base;
+ u8 subtype;
+ u8 bitmap;
+};
+
+static int qpnp_tri_led_read(struct qpnp_tri_led_chip *chip, u16 addr, u8 *val)
+{
+ int rc;
+ unsigned int tmp;
+
+ mutex_lock(>bus_lock);
+ rc = regmap_read(chip->regmap, chip->reg_base + addr, );
+ if (rc < 0)
+ dev_err(chip->dev, "Read addr 0x%x failed, rc=%d\n", addr, rc);
+ else
+ *val = (u8)tmp;
+ mutex_unlock(>bus_lock);
+
+ return rc;
+}
+
+static int qpnp_tri_led_masked_write(struct qpnp_tri_led_chip *chip, u16 addr,
+u8 mask, u8 val)
+{
+ int rc;
+
+ mutex_lock(>bus_lock);
+ rc = regmap_update_bits(chip->regmap, chip->reg_base + addr, mask, val);
+ if (rc < 0)
+ dev_err(chip->dev,
+ "Update addr 0x%x to val 0x%x with mask 0x%x failed,
rc=%d\n",
+ addr, val, mask, rc);
+ mutex_unlock(>bus_lock);
+
+ return rc;
+}
+
+static int __tri_led_config_pwm(struct qpnp_led_dev *led,
+ struct pwm_se
[PATCH RFC 3/6] pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module
From: Fenglin Wu
Add pwm_chip to support QTI LPG module and export LPG channels as
PWM devices for consumer drivers' usage.
Signed-off-by: Fenglin Wu
[martin.bot...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8]
Signed-off-by: Martin Botka
---
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-qti-lpg.c | 1284 +
3 files changed, 1295 insertions(+)
create mode 100644 drivers/pwm/pwm-qti-lpg.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cb8d739067d2..8a52d6884a9a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -399,6 +399,16 @@ config PWM_RCAR
To compile this driver as a module, choose M here: the module
will be called pwm-rcar.
+config PWM_QTI_LPG
+ tristate "Qualcomm Technologies, Inc. LPG driver"
+ depends on MFD_SPMI_PMIC && OF
+ help
+ This driver supports the LPG (Light Pulse Generator) module found in
+ Qualcomm Technologies, Inc. PMIC chips. Each LPG channel can be
+ configured to operate in PWM mode to output a fixed amplitude with
+ variable duty cycle or in LUT (Look up table) mode to output PWM
+ signal with a modulated amplitude.
+
config PWM_RENESAS_TPU
tristate "Renesas TPU PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a59c710e98c7..3555a6aa3f33 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
+obj-$(CONFIG_PWM_QTI_LPG) += pwm-qti-lpg.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-qti-lpg.c b/drivers/pwm/pwm-qti-lpg.c
new file mode 100644
index ..d24c3b3a3d8c
--- /dev/null
+++ b/drivers/pwm/pwm-qti-lpg.c
@@ -0,0 +1,1284 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_SIZE_PER_LPG 0x100
+#define LPG_BASE "lpg-base"
+#define LUT_BASE "lut-base"
+
+/* LPG module registers */
+#define REG_LPG_PERPH_SUBTYPE 0x05
+#define REG_LPG_PATTERN_CONFIG 0x40
+#define REG_LPG_PWM_SIZE_CLK 0x41
+#define REG_LPG_PWM_FREQ_PREDIV_CLK 0x42
+#define REG_LPG_PWM_TYPE_CONFIG 0x43
+#define REG_LPG_PWM_VALUE_LSB 0x44
+#define REG_LPG_PWM_VALUE_MSB 0x45
+#define REG_LPG_ENABLE_CONTROL 0x46
+#define REG_LPG_PWM_SYNC 0x47
+#define REG_LPG_RAMP_STEP_DURATION_LSB 0x50
+#define REG_LPG_RAMP_STEP_DURATION_MSB 0x51
+#define REG_LPG_PAUSE_HI_MULTIPLIER 0x52
+#define REG_LPG_PAUSE_LO_MULTIPLIER 0x54
+#define REG_LPG_HI_INDEX 0x56
+#define REG_LPG_LO_INDEX 0x57
+
+/* REG_LPG_PATTERN_CONFIG */
+#define LPG_PATTERN_EN_PAUSE_LO BIT(0)
+#define LPG_PATTERN_EN_PAUSE_HI BIT(1)
+#define LPG_PATTERN_RAMP_TOGGLE BIT(2)
+#define LPG_PATTERN_REPEAT BIT(3)
+#define LPG_PATTERN_RAMP_LO_TO_HI BIT(4)
+
+/* REG_LPG_PERPH_SUBTYPE */
+#define SUBTYPE_PWM 0x0b
+#define SUBTYPE_LPG_LITE 0x11
+
+/* REG_LPG_PWM_SIZE_CLK */
+#define LPG_PWM_SIZE_LPG_MASK BIT(4)
+#define LPG_PWM_SIZE_PWM_MASK BIT(2)
+#define LPG_PWM_SIZE_LPG_SHIFT 4
+#define LPG_PWM_SIZE_PWM_SHIFT 2
+#define LPG_PWM_CLK_FREQ_SEL_MASK GENMASK(1, 0)
+
+/* REG_LPG_PWM_FREQ_PREDIV_CLK */
+#define LPG_PWM_FREQ_PREDIV_MASK GENMASK(6, 5)
+#define LPG_PWM_FREQ_PREDIV_SHIFT 5
+#define LPG_PWM_FREQ_EXPONENT_MASK GENMASK(2, 0)
+
+/* REG_LPG_PWM_TYPE_CONFIG */
+#define LPG_PWM_EN_GLITCH_REMOVAL_MASK BIT(5)
+
+/* REG_LPG_PWM_VALUE_LSB */
+#define LPG_PWM_VALUE_LSB_MASK GENMASK(7, 0)
+
+/* REG_LPG_PWM_VALUE_MSB */
+#define LPG_PWM_VALUE_MSB_MASK BIT(0)
+
+/* REG_LPG_ENABLE_CONTROL */
+#define LPG_EN_LPG_OUT_BIT BIT(7)
+#define LPG_EN_LPG_OUT_SHIFT 7
+#define LPG_PWM_SRC_SELECT_MASK BIT(2)
+#define LPG_PWM_SRC_SELECT_SHIFT 2
+#define LPG_EN_RAMP_GEN_MASK BIT(1)
+#define LPG_EN_RAMP_GEN_SHIFT 1
+
+/* REG_LPG_PWM_SYNC */
+#define LPG_PWM_VALUE_SYNC BIT(0)
+
+#define NUM_PWM_SIZE 2
+#define NUM_PWM_CLK 3
+#define NUM_CLK_PREDIV 4
+#define NUM_PWM_EXP 8
+
+#define LPG_HI_LO_IDX_MASK GENMASK(5, 0)
+
+/* LUT module registers */
+#define REG_LPG_LUT_1_LSB 0x42
+#define REG_LPG_LUT_RAMP_CONTROL 0xc8
+
+#define LPG_LUT_VALUE_MSB_MASK BIT(0)
+#define LPG_LUT_COUNT_MAX 47
+
+enum lpg_src {
+ LUT_PATTERN = 0,
+ PWM_VALUE,
+};
+
+static const int pwm_size[NUM_PWM_SIZE] = { 6, 9 };
+static const int clk_freq_hz[NUM_PWM_CLK] = { 1024, 32768, 1920 };
+static const int clk_prediv[NUM_CLK_PREDIV] =
[PATCH RFC 5/6] Documentation: Add binding for qti-tri-led
From: Fenglin Wu
Add documentation for qti-tri-led
Signed-off-by: Fenglin Wu
Signed-off-by: Martin Botka
---
.../bindings/leds/leds-qti-tri-led.txt| 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-qti-tri-led.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-qti-tri-led.txt
b/Documentation/devicetree/bindings/leds/leds-qti-tri-led.txt
new file mode 100644
index ..e179f4222739
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-qti-tri-led.txt
@@ -0,0 +1,72 @@
+Qualcomm Technologies, Inc. TRI_LED driver specific bindings
+
+This binding document describes the properties of TRI_LED module in
+Qualcomm Technologies, Inc. PMIC chips.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: Must be "qcom,tri-led".
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: Register base of the TRI_LED module and length.
+
+- nvmem-names:
+ Usage: optional
+ Value type:
+ Definition: Nvmem device name for SDAM to do PBS trigger. It must be
+ defined as "pbs_sdam". This is required only for HR_LEDs.
+
+- nvmem:
+ Usage: optional
+ Value type:
+ Definition: Phandle of the nvmem device name to access SDAM to do PBS
+ trigger. This is required only for HR_LEDs.
+
+Properties for child nodes:
+- pwms:
+ Usage: required
+ Value type:
+ Definition: The PWM device (phandle) used for controlling LED.
+
+- led-sources:
+ Usage: required
+ Value type:
+ Definition: see Documentation/devicetree/bindings/leds/common.txt;
+ Device current output identifiers are: 0 - LED1_EN,
+ 1 - LED2_EN, 2 - LED3_EN.
+
+- label:
+ Usage: optional
+ Value type:
+ Definition: see Documentation/devicetree/bindings/leds/common.txt;
+
+- linux,default-trigger:
+ Usage: optional
+ Value_type:
+ Definition: see Documentation/devicetree/bindings/leds/common.txt;
+
+Example:
+
+ pmi8998_rgb: tri-led@d000{
+ compatible = "qcom,tri-led";
+ reg = <0xd000 0x100>;
+
+ red {
+ label = "red";
+ pwms = <_lpg 4 100>;
+ led-sources = <0>;
+ };
+ green {
+ label = "green";
+ pwms = <_lpg 3 100>;
+ led-sources = <1>;
+ };
+ blue {
+ label = "blue";
+ pwms = <_lpg 2 100>;
+ led-sources = <2>;
+ };
+ };
--
2.27.0
[PATCH RCC 1/6] pwm: Add different PWM output types support
From: Fenglin Wu
Normally, PWM channel has fixed output until software request to change
its settings. There are some PWM devices which their outputs could be
changed autonomously according to a predefined pattern programmed in
hardware. Add pwm_output_type enum type to identify these two different
PWM types and add relevant helper functions to set and get PWM output
types and pattern.
Signed-off-by: Fenglin Wu
[konradyb...@gmail.com: Fast-forward from kernel 4.14 to 5.8]
Signed-off-by: Konrad Dybcio
Signed-off-by: Martin Botka
---
drivers/pwm/core.c | 26 +
drivers/pwm/sysfs.c | 50
include/linux/pwm.h | 69 +
3 files changed, 145 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 004b2ea9b5fd..f3aa44106962 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -304,6 +304,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
pwm->state.polarity = polarity;
+ pwm->state.output_type = PWM_OUTPUT_FIXED;
radix_tree_insert(_tree, pwm->pwm, pwm);
}
@@ -627,6 +628,31 @@ int pwm_apply_state(struct pwm_device *pwm, const struct
pwm_state *state)
pwm->state.polarity = state->polarity;
}
+ if (state->output_type != pwm->state.output_type) {
+ if (!pwm->chip->ops->set_output_type)
+ return -ENOTSUPP;
+
+ err = pwm->chip->ops->set_output_type(pwm->chip, pwm,
+
state->output_type);
+ if (err)
+ return err;
+
+ pwm->state.output_type = state->output_type;
+ }
+
+ if (state->output_pattern != pwm->state.output_pattern &&
+ state->output_pattern != NULL) {
+ if (!pwm->chip->ops->set_output_pattern)
+ return -ENOTSUPP;
+
+ err = pwm->chip->ops->set_output_pattern(pwm->chip,
+ pwm,
state->output_pattern);
+ if (err)
+ return err;
+
+ pwm->state.output_pattern = state->output_pattern;
+ }
+
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
err = chip->ops->config(pwm->chip, pwm,
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b8669846..4ee1e81db0bc 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -215,11 +215,60 @@ static ssize_t capture_show(struct device *child,
return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
}
+static ssize_t output_type_show(struct device *child,
+ struct device_attribute
*attr,
+ char *buf)
+{
+ const struct pwm_device *pwm = child_to_pwm_device(child);
+ const char *output_type = "unknown";
+ struct pwm_state state;
+
+ pwm_get_state(pwm, );
+ switch (state.output_type) {
+ case PWM_OUTPUT_FIXED:
+ output_type = "fixed";
+ break;
+ case PWM_OUTPUT_MODULATED:
+ output_type = "modulated";
+ break;
+ default:
+ break;
+ }
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", output_type);
+}
+
+static ssize_t output_type_store(struct device *child,
+ struct
device_attribute *attr,
+ const char
*buf, size_t size)
+{
+ struct pwm_export *export = child_to_pwm_export(child);
+ struct pwm_device *pwm = export->pwm;
+ struct pwm_state state;
+ int ret = -EINVAL;
+
+ mutex_lock(>lock);
+ pwm_get_state(pwm, );
+ if (sysfs_streq(buf, "fixed"))
+ state.output_type = PWM_OUTPUT_FIXED;
+ else if (sysfs_streq(buf, "modulated"))
+ state.output_type = PWM_OUTPUT_MODULATED;
+ else
+ goto unlock;
+
+ ret = pwm_apply_state(pwm, );
+unlock:
+ mutex_unlock(>lock);
+
+ return ret ? : size;
+}
+
static DEVICE_ATTR_RW(period);
static DEVICE_ATTR_RW(duty_cycle);
static DEVICE_ATTR_RW(enable);
static DEVICE_ATTR_RW(polarity);
static DEVICE_ATTR_RO(capture);
+static DEVICE_A
[PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length
From: Fenglin Wu
Currently, PWM core driver provides interfaces for configuring PWM
period and duty length in nanoseconds with an integer data type, so
the max period can be only set to ~2.147 seconds. Add interfaces which
can set PWM period and duty with u64 data type to remove this
limitation.
Signed-off-by: Fenglin Wu
[konradyb...@gmail.com: Fast-forward from kernel 4.14 to 5.8]
Signed-off-by: Konrad Dybcio
Signed-off-by: Martin Botka
---
drivers/pwm/core.c | 30 +++--
drivers/pwm/sysfs.c | 6 ++--
include/linux/pwm.h | 79 +
3 files changed, 95 insertions(+), 20 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f3aa44106962..82411e3ccbbb 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -511,12 +511,12 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
last->period > s2.period &&
last->period <= state->period)
dev_warn(chip->dev,
-".apply didn't pick the best available period
(requested: %u, applied: %u, possible: %u)\n",
+".apply didn't pick the best available period
(requested: %llu, applied: %llu, possible: %llu)\n",
state->period, s2.period, last->period);
if (state->enabled && state->period < s2.period)
dev_warn(chip->dev,
-".apply is supposed to round down period (requested:
%u, applied: %u)\n",
+".apply is supposed to round down period (requested:
%llu, applied: %llu)\n",
state->period, s2.period);
if (state->enabled &&
@@ -525,14 +525,14 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
last->duty_cycle > s2.duty_cycle &&
last->duty_cycle <= state->duty_cycle)
dev_warn(chip->dev,
-".apply didn't pick the best available duty cycle
(requested: %u/%u, applied: %u/%u, possible: %u/%u)\n",
+".apply didn't pick the best available duty cycle
(requested: %llu/%llu, applied: %llu/%llu, possible: %llu/%llu)\n",
state->duty_cycle, state->period,
s2.duty_cycle, s2.period,
last->duty_cycle, last->period);
if (state->enabled && state->duty_cycle < s2.duty_cycle)
dev_warn(chip->dev,
-".apply is supposed to round down duty_cycle
(requested: %u/%u, applied: %u/%u)\n",
+".apply is supposed to round down duty_cycle
(requested: %llu/%llu, applied: %llu/%llu)\n",
state->duty_cycle, state->period,
s2.duty_cycle, s2.period);
@@ -559,7 +559,7 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
(s1.enabled && s1.period != last->period) ||
(s1.enabled && s1.duty_cycle != last->duty_cycle)) {
dev_err(chip->dev,
- ".apply is not idempotent (ena=%d pol=%d %u/%u) ->
(ena=%d pol=%d %u/%u)\n",
+ ".apply is not idempotent (ena=%d pol=%d %llu/%llu) ->
(ena=%d pol=%d %llu/%llu)\n",
s1.enabled, s1.polarity, s1.duty_cycle, s1.period,
last->enabled, last->polarity, last->duty_cycle,
last->period);
@@ -655,9 +655,19 @@ int pwm_apply_state(struct pwm_device *pwm, const struct
pwm_state *state)
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
- err = chip->ops->config(pwm->chip, pwm,
- state->duty_cycle,
- state->period);
+ if (pwm->chip->ops->config_extend) {
+ err =
pwm->chip->ops->config_extend(pwm->chip,
+ pwm,
state->duty_cycle,
+ state->period);
+ } else {
+ if (state->period > UINT_MAX)
+ pr_warn("period %llu duty_cycle %llu
will be truncated\n",
+ state->period,
+
state->duty_cycle);
+ err = pwm->chip->ops->config(pwm->chip, pwm,
+
Re: [PATCH 8/8] arm64: dts: qcom: Add support for Sony Xperia 10/10 Plus (Ganges platform)
Sorry made a typo in mail. Tested-by: Martin Botka
Re: [PATCH 8/8] arm64: dts: qcom: Add support for Sony Xperia 10/10 Plus (Ganges platform)
Tested-by: Martin Botka
ne 21. 6. 2020 o 23:38 Konrad Dybcio napísal(a):
>
> From: Martin Botka
>
> Add device tree support for the Sony Xperia 10 and 10
> Plus smartphones. They are all based on the Sony Ganges
> platform (sdm630/636) and share a lot of common code.
> The differences are really minor, so a Ganges-common DTSI
> has been created to reduce clutter.
>
> 10 - Kirin
> 10 Plus - Mermaid
>
> This platform is based on SoMC Nile, but there are some
> major differences when it comes to pin configuration and
> panel setup (among others).
>
> The boards currently support:
> * Screen console
> * SDHCI
> * I2C
> * pstore log dump
> * GPIO keys
> * PSCI idle states
>
> Signed-off-by: Martin Botka
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> .../qcom/sdm630-sony-xperia-ganges-kirin.dts | 13 +++
> .../dts/qcom/sdm630-sony-xperia-ganges.dtsi | 39 +++
> .../sdm636-sony-xperia-ganges-mermaid.dts | 19 +
> 4 files changed, 73 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges-kirin.dts
> create mode 100644 arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges.dtsi
> create mode 100644
> arch/arm64/boot/dts/qcom/sdm636-sony-xperia-ganges-mermaid.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 1cad7cb07574..c98bafe03a96 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -16,9 +16,11 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8998-hp-envy-x2.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= msm8998-lenovo-miix-630.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sc7180-idp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-ganges-kirin.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-nile-discovery.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-nile-pioneer.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-nile-voyager.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm636-sony-xperia-ganges-mermaid.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm660-xiaomi-lavender.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges-kirin.dts
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges-kirin.dts
> new file mode 100644
> index ..5326e019db20
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges-kirin.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Martin Botka
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm630-sony-xperia-ganges.dtsi"
> +
> +/ {
> +model = "SoMC Kirin-RoW";
> +compatible = "sony,kirin-row", "qcom,sdm630", "qcom,sdm630-mtp";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges.dtsi
> b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges.dtsi
> new file mode 100644
> index ..6c4c30e4cd9d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm630-sony-xperia-ganges.dtsi
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, Martin Botka
> + */
> +
> +/dts-v1/;
> +
> +/* Ganges is very similar to Nile, but
> +there are some differences that will need
> +to be addresed when more peripherals are
> +enabled upstream. Hence the separate DTSI. */
> +#include "sdm630-sony-xperia-nile.dtsi"
> +
> +/ {
> +chosen {
> +framebuffer@9d40 {
> +reg = <0 0x9d40 0 (2520 * 1080 * 4)>;
> +height = <2520>;
> +};
> +};
> +
> +soc {
> +
> +i2c@c175000 {
> +status = "okay";
> +
> +/* Novatek touchscreen */
> +};
> +
> +/* Yes, this is intentional.
> +Ganges devices only use gpio-keys for
> +Volume Down, but currently there's an
> +issue with it that has to be resolved.
> +Until then, let's not make the kernel panic
> +*/
> + /delete-node/ gpio-keys;
> +};
> +
> +};
> diff --git a/arch/arm64/boot/dts/qcom/sdm636-sony-xperia-ganges-mermaid.dts
> b/arch/arm64/boot/dts/qcom/sdm636-sony-xperia-ganges-mermaid.dts
> new file mode 100644
> index ..97dce64d0185
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm636-sony-xperia-ganges-mermaid.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copy
