RE: warning: objtool: fn1 uses BP as a scratch register
The framepointer thing may have been fixed by this https://reviews.llvm.org/D64294 -Original Message- From: Arnd Bergmann Sent: Friday, July 19, 2019 12:44 PM To: Nick Desaulniers Cc: Josh Poimboeuf ; clang-built-linux ; Linux Kernel Mailing List ; Peter Zijlstra ; Topper, Craig ; Simon Pilgrim Subject: Re: warning: objtool: fn1 uses BP as a scratch register On Fri, Jul 19, 2019 at 8:50 PM 'Nick Desaulniers' via Clang Built Linux wrote: > On Fri, Jul 19, 2019 at 11:44 AM Arnd Bergmann wrote: > > On Fri, Jul 19, 2019 at 8:31 PM Josh Poimboeuf wrote: > > Actually the reproducer may be wrong. I reduced the test case using > > 9.0.0-svn363902-1~exp1+0~20190620001509.2315~1.gbp76e756, > > and this contains a link > > > > testl %ebp, %ebp > > > > I get the same thing with clang-8, but godbolt.org shows it only > > with clang-8 (see https://godbolt.org/z/g1lZO0) , not with trunk. > > (Sorry for sending a blank email just now) > + Craig and Simon, in case they recall this being a recent fix in > LLVM's x86 backend. > Sounds like this is fixing in upstream LLVM. Guessing this could > result in improper unwinding w/ clang-8, but that's kind of irrelevant > for x86 as there's no asm goto (though we don't need CONFIG_JUMP_LABEL > in LTS branches :P) Maybe you can try the attached .config file with a more recent clang build. This showed a few hundred warnings like this one for me, so if it was not a bugfix but a random change in clang-9 that changed my reproducer. Ignoring the 'uses BP as a scratch' warnings and the reiserfs 'unreachable instruction' ones, this is what else I got with today's linux-next: arch/x86/events/intel/core.o: warning: objtool: intel_pmu_nhm_workaround()+0x103: unreachable instruction arch/x86/ia32/ia32_signal.o: warning: objtool: ia32_setup_rt_frame()+0x151: call to memset() with UACCESS enabled arch/x86/kernel/cpu/mtrr/generic.o: warning: objtool: get_fixed_ranges()+0x144: unreachable instruction arch/x86/kernel/process.o: warning: objtool: get_tsc_mode()+0x20: call without frame pointer save/setup arch/x86/kernel/signal.o: warning: objtool: __setup_rt_frame()+0x1a0: call to memset() with UACCESS enabled arch/x86/kernel/signal.o: warning: objtool: x32_setup_rt_frame()+0x1da: call to memset() with UACCESS enabled arch/x86/kernel/tsc.o: warning: objtool: sched_clock()+0x0: call without frame pointer save/setup arch/x86/mm/fault.o: warning: objtool: do_user_addr_fault()+0x53: unreachable instruction drivers/ata/sata_dwc_460ex.o: warning: objtool: sata_dwc_bmdma_start_by_tag()+0x259: can't find switch jump table drivers/gpu/drm/amd/amdgpu/atom.o: warning: objtool: atom_op_move() falls through to next function atom_op_and() drivers/gpu/drm/radeon/atom.o: warning: objtool: atom_op_move()+0xce: sibling call from callable instruction with modified stack frame drivers/gpu/drm/radeon/atom.o: warning: objtool: atom_op_move() falls through to next function atom_op_and() modified stack frame drivers/gpu/drm/radeon/evergreen_cs.o: warning: objtool: evergreen_cs_parse()+0xbcf: sibling call from callable instruction with modified stack frame drivers/gpu/drm/radeon/evergreen_cs.o: warning: objtool: evergreen_cs_parse() falls through to next function evergreen_dma_cs_parse() drivers/hwmon/pmbus/adm1275.o: warning: objtool: adm1275_probe()+0x949: unreachable instruction drivers/media/dvb-frontends/cxd2880/cxd2880_tnrdmd_dvbt2.o: warning: objtool: x_tune_dvbt2_demod_setting()+0x92a: can't find switch jump table drivers/pinctrl/pinctrl-ingenic.o: warning: objtool: ingenic_pinconf_set()+0x93: sibling call from callable instruction with modified stack frame drivers/platform/x86/intel_speed_select_if/isst_if_common.o: warning: objtool: isst_restore_msr_local()+0x13d: unreachable instruction drivers/platform/x86/intel_speed_select_if/isst_if_mbox_msr.o: warning: objtool: isst_if_send_mbox_cmd()+0x80: unreachable instruction fs/hfsplus/xattr.o: warning: objtool: hfsplus_create_attributes_file()+0x4f7: unreachable instruction kernel/trace/ring_buffer.o: warning: objtool: ring_buffer_nest_end()+0x1b: call without frame pointer save/setup kernel/trace/trace.o: warning: objtool: saved_cmdlines_stop()+0x13: call without frame pointer save/setup lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x30: call without frame pointer save/setup lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbd: call to __stack_chk_fail() with UACCESS enabled lib/ubsan.o: warning: objtool: ubsan_type_mismatch_common()+0x448: call to __stack_chk_fail() with UACCESS enabled mm/kasan/common.o: warning: objtool: kasan_report()+0x43: call to __stack_chk_fail() with UACCESS enabled mm/page_alloc.o: warning: objtool: .altinstr_re
Re: [PATCH bpf v2] bpf, lpm: fix lookup bug in map_delete_elem
On Fri, Feb 22, 2019 at 8:19 AM Alban Crequy wrote: > > From: Alban Crequy > > trie_delete_elem() was deleting an entry even though it was not matching > if the prefixlen was correct. This patch adds a check on matchlen. > > Reproducer: > > $ sudo bpftool map create /sys/fs/bpf/mylpm type lpm_trie key 8 value 1 > entries 128 name mylpm flags 1 > $ sudo bpftool map update pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 aa bb > cc dd value hex 01 > $ sudo bpftool map dump pinned /sys/fs/bpf/mylpm > key: 10 00 00 00 aa bb cc dd value: 01 > Found 1 element > $ sudo bpftool map delete pinned /sys/fs/bpf/mylpm key hex 10 00 00 00 ff ff > ff ff > $ echo $? > 0 > $ sudo bpftool map dump pinned /sys/fs/bpf/mylpm > Found 0 elements > > A similar reproducer is added in the selftests. > > Without the patch: > > $ sudo ./tools/testing/selftests/bpf/test_lpm_map > test_lpm_map: test_lpm_map.c:485: test_lpm_delete: Assertion > `bpf_map_delete_elem(map_fd, key) == -1 && errno == ENOENT' failed. > Aborted > > With the patch: test_lpm_map runs without errors. > > Fixes: e454cf595853 ("bpf: Implement map_delete_elem for > BPF_MAP_TYPE_LPM_TRIE") > Cc: Craig Gallek > Signed-off-by: Alban Crequy > > --- Acked-by: Craig Gallek Good catch, thanks for the fix!
[PATCH] pinctrl: sdm660: Set tile property for pingroups
This was missed when tiles support was added in a revison and causes the driver to fail to load. Fixes: 9cf0c526bc58 ("pinctrl: qcom: Add sdm660 pinctrl driver") Signed-off-by: Craig Tatlor --- drivers/pinctrl/qcom/pinctrl-sdm660.c | 28 ++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pinctrl/qcom/pinctrl-sdm660.c b/drivers/pinctrl/qcom/pinctrl-sdm660.c index 6838b38555a1..1bfb0ae6b387 100644 --- a/drivers/pinctrl/qcom/pinctrl-sdm660.c +++ b/drivers/pinctrl/qcom/pinctrl-sdm660.c @@ -33,7 +33,7 @@ enum { } -#define PINGROUP(id, base, f1, f2, f3, f4, f5, f6, f7, f8, f9) \ +#define PINGROUP(id, _tile, f1, f2, f3, f4, f5, f6, f7, f8, f9)\ { \ .name = "gpio" #id, \ .pins = gpio##id##_pins,\ @@ -51,11 +51,12 @@ enum { msm_mux_##f9\ }, \ .nfuncs = 10, \ - .ctl_reg = base + REG_SIZE * id,\ - .io_reg = base + 0x4 + REG_SIZE * id, \ - .intr_cfg_reg = base + 0x8 + REG_SIZE * id, \ - .intr_status_reg = base + 0xc + REG_SIZE * id, \ - .intr_target_reg = base + 0x8 + REG_SIZE * id, \ + .ctl_reg = REG_SIZE * id, \ + .io_reg = 0x4 + REG_SIZE * id, \ + .intr_cfg_reg = 0x8 + REG_SIZE * id,\ + .intr_status_reg = 0xc + REG_SIZE * id, \ + .intr_target_reg = 0x8 + REG_SIZE * id, \ + .tile = _tile, \ .mux_bit = 2, \ .pull_bit = 0, \ .drv_bit = 6, \ @@ -82,6 +83,7 @@ enum { .intr_cfg_reg = 0, \ .intr_status_reg = 0, \ .intr_target_reg = 0, \ + .tile = NORTH, \ .mux_bit = -1, \ .pull_bit = pull, \ .drv_bit = drv, \ @@ -1397,13 +1399,13 @@ static const struct msm_pingroup sdm660_groups[] = { PINGROUP(111, SOUTH, _, _, _, _, _, _, _, _, _), PINGROUP(112, SOUTH, _, _, _, _, _, _, _, _, _), PINGROUP(113, SOUTH, _, _, _, _, _, _, _, _, _), - SDC_QDSD_PINGROUP(sdc1_clk, 0x99a000, 13, 6), - SDC_QDSD_PINGROUP(sdc1_cmd, 0x99a000, 11, 3), - SDC_QDSD_PINGROUP(sdc1_data, 0x99a000, 9, 0), - SDC_QDSD_PINGROUP(sdc2_clk, 0x99b000, 14, 6), - SDC_QDSD_PINGROUP(sdc2_cmd, 0x99b000, 11, 3), - SDC_QDSD_PINGROUP(sdc2_data, 0x99b000, 9, 0), - SDC_QDSD_PINGROUP(sdc1_rclk, 0x99a000, 15, 0), + SDC_QDSD_PINGROUP(sdc1_clk, 0x9a000, 13, 6), + SDC_QDSD_PINGROUP(sdc1_cmd, 0x9a000, 11, 3), + SDC_QDSD_PINGROUP(sdc1_data, 0x9a000, 9, 0), + SDC_QDSD_PINGROUP(sdc2_clk, 0x9b000, 14, 6), + SDC_QDSD_PINGROUP(sdc2_cmd, 0x9b000, 11, 3), + SDC_QDSD_PINGROUP(sdc2_data, 0x9b000, 9, 0), + SDC_QDSD_PINGROUP(sdc1_rclk, 0x9a000, 15, 0), }; static const struct msm_pinctrl_soc_data sdm660_pinctrl = { -- 2.19.1
Re: [PATCH V2] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
On Mon, Nov 12, 2018 at 04:34:50PM +0100, Heiko Stuebner wrote: > Hi Craig, > > Am Sonntag, 12. August 2018, 16:23:12 CET schrieb Craig Tatlor: > > Initial device tree support for Qualcomm SDM630 SoC and > > Sony Pioneer (Xperia XA2). > > > > SDM630 is based off of the SDM660 soc and all SDM660 specific drivers are > > compatible with it. SDM660 is also based off of MSM8998 so it uses some > > of its drivers aswell. > > > > The device tree is based on the CAF 4.4 kernel tree. > > > > The device can be booted into the initrd with a shell over UART. > > > > Signed-off-by: Craig Tatlor > > With I think core drivers like clk, pinctrl merged in 4.20, do you > plan on respinning the devicetree support or in general continue > working on sdm630/sdm660? > Yeah, i am just a little busy at the moment, i should probably be sending of v3 in a few weeks. > Or do you have some git tree available somewhere, were I can follow > along? I do have interest in supporting a sdm630 phone of my own > but still don't want to duplicate work :-) My git tree is https://gitlab.com/opendata26/linux the mainline-submit-2 branch, i have sdhci, usb(via downstream backport just so i can debug without opening phone) and also working on modem but that isnt in that tree and isnt working quite yet. > > > Thanks > Heiko > > >
Re: Insanely high baud rates
On 18.10.11, Alan Cox wrote: > I mean - what is the baud rate of a pty ? Solaris made the distinction between B0, which means pty hangup mode, and any other baud rate: https://docs.oracle.com/cd/E88353_01/html/E37851/pty-4d.html But... why not implement a pty bandwidth limitation layer? You say, I need to justify it? It's for, uh... protecting the system from unrestricted pty usage DOS attacks! Yeah. That's what it's for. Craig Milo Rogers
[PATCH] staging: vboxvideo: make a couple of funcs static
Fix Sparse warnings: drivers/staging/vboxvideo/vbox_mode.c:309:6: warning: symbol 'vbox_primary_atomic_disable' was not declared. Should it be static? drivers/staging/vboxvideo/vbox_mode.c:452:6: warning: symbol 'vbox_cursor_atomic_disable' was not declared. Should it be static? Signed-off-by: Craig Kewley --- drivers/staging/vboxvideo/vbox_mode.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_mode.c b/drivers/staging/vboxvideo/vbox_mode.c index 042e4f384df9..deed28c7a1db 100644 --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -306,8 +306,8 @@ static void vbox_primary_atomic_update(struct drm_plane *plane, plane->state->src_y >> 16); } -void vbox_primary_atomic_disable(struct drm_plane *plane, -struct drm_plane_state *old_state) +static void vbox_primary_atomic_disable(struct drm_plane *plane, + struct drm_plane_state *old_state) { struct drm_crtc *crtc = old_state->crtc; @@ -449,8 +449,8 @@ static void vbox_cursor_atomic_update(struct drm_plane *plane, mutex_unlock(&vbox->hw_mutex); } -void vbox_cursor_atomic_disable(struct drm_plane *plane, - struct drm_plane_state *old_state) +static void vbox_cursor_atomic_disable(struct drm_plane *plane, + struct drm_plane_state *old_state) { struct vbox_private *vbox = container_of(plane->dev, struct vbox_private, ddev); -- 2.17.1
Re: [PATCH V3 0/4] Changes for SDCC5 version
On 9 October 2018 07:01:57 BST, Veerabhadrarao Badiganti wrote: >Hi > > >On 10/8/2018 12:26 PM, Bjorn Andersson wrote: >> On Sun 07 Oct 01:07 PDT 2018, Craig wrote: >> >>> Any updates on this? >>> >> FWIW I used qcom,sdhci-msm-v5 on QCS404 successfully. >> >> Regards, >> Bjorn > >The base address and interrupt numbers needs to be updated in your dt. >you can refer the below link to update interrupt number and base >address >https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-m2/arch/arm/boot/dts/qcom/sdm660.dtsi They look correct, driver only uses pwr irq and the actual reg field is fine, just node name wrong, which wouldn't cause issues. >>> On 25 September 2018 16:39:33 BST, Craig >wrote: >>>> >>>> On 25 September 2018 12:17:26 BST, Veerabhadrarao Badiganti >>>> wrote: >>>>> On 9/25/2018 1:18 AM, Craig Tatlor wrote: >>>>>> What socs have you tested this on? >>>>>> On sdm660 it seems to crash device >>>>>> when writing pwr ctl. >>>>> Hi >>>>> We have tested this on SDM845. >>>>> SDM660 also has SDCC5 controller, so you would need to define >>>>> "qcom,sdhci-msm-v5" in your platform dt. >>>>> Can you confirm if you have defined this? >>>>> >>>> Hi, >>>> Yes my DT entry is as follows >>>> >>>> sdhc_1: sdhci@f9824900 { >Update this address. This could be the reason for the crash that you >are >observing. > >>>> >>>> >>>> compatible = "qcom,sdhci-msm-v5"; >>>> >>>> reg = <0xc0c4000 0x1000>, <0xc0c5000 0x1000>; >>>> >>>> interrupts = ; >>>> > >Please update this interrupt map aswell. > >>>> interrupt-names = "pwr_irq"; >>>> >>>> > >>>> bus-width = <8>; >>>> >>>> non-removable; >>>> >>>> > >>>> vmmc-supply = <&pm660l_l4>; >>>> >>>> vqmmc-supply = <&pm660_l8>; >>>> >>>> > >>>> pinctrl-names = "default"; >>>> >>>> pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data &sdc1_rclk>; >>>> >>>> > >>>> clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; >>>> >>>> clock-names = "core", "iface"; >>>> >>>> }; >>>> >>>>> BTW, can you please share few details of the platform that you are >>>>> checking? >>>>> We are not aware of any dev platform based on SDM660. This is just >for >>>>> my info >>>> I'm checking on the sony xperia xa2 (pioneer) smartphone. >>>>>> On Tue, Jun 19, 2018 at 11:09:17AM +0530, Vijay Viswanath wrote: >>>>>>> With SDCC5, the MCI register space got removed and the >offset/order >>>>> of >>>>>>> several registers have changed. Based on SDCC version used and >the >>>>> register, >>>>>>> we need to pick the base address and offset. >>>>>>> >>>>>>> Depends on patch series: "[PATCH V5 0/2] mmc: sdhci-msm: >>>> Configuring >>>>> IO_PAD support for sdhci-msm" >>>>>>> Changes since RFC: >>>>>>> Dropped voltage regulator changes in sdhci-msm >>>>>>> Split the "Register changes for sdcc V5" patch >>>>>>> Instead of checking mci removal for deciding which base addr to >>>>> use, >>>>>>> new function pointers are defined for the 2 variants of sdcc: >>>>>>> 1) MCI present >>>>>>> 2) V5 (mci removed) >>>>>>> Instead of string comparing with the compatible string from DT >>>>> file, >
Re: [PATCH v3] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
(Resend due to broken email client) any reviews for this? On 25 September 2018 18:35:58 BST, Craig Tatlor wrote: >From: Taniya Das > >Add support for the global clock controller found on SDM660 >based devices. This should allow most non-multimedia device >drivers to probe and control their clocks. >Based on CAF implementation. > >Signed-off-by: Taniya Das >[craig: rename parents to fit upstream, and other cleanups] >Signed-off-by: Craig Tatlor >--- >Changes from V1: >Change authorship >Add sdm630 compatible > .../devicetree/bindings/clock/qcom,gcc.txt|1 + > drivers/clk/qcom/Kconfig |9 + > drivers/clk/qcom/Makefile |1 + > drivers/clk/qcom/gcc-sdm660.c | 2480 + > include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ > 5 files changed, 2650 insertions(+) > create mode 100644 drivers/clk/qcom/gcc-sdm660.c > create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h > >diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >index 664ea1fd6c76..e498ad2e8db8 100644 >--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >@@ -38,6 +38,8 @@ Required properties : > "qcom,gcc-msm8996" > "qcom,gcc-msm8998" > "qcom,gcc-mdm9615" >+ "qcom,gcc-sdm630" >+ "qcom,gcc-sdm660" > "qcom,gcc-sdm845" > > - reg : shall contain base register location and length >diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig >index 5b181b182f40..4d478b261dfe 100644 >--- a/drivers/clk/qcom/Kconfig >+++ b/drivers/clk/qcom/Kconfig >@@ -243,6 +243,15 @@ config SDM_CAMCC_845 > Support for the camera clock controller on SDM845 devices. > Say Y if you want to support camera devices and camera >functionality. > >+config SDM_GCC_660 >+ tristate "SDM660 Global Clock Controller" >+ select QCOM_GDSC >+ depends on COMMON_CLK_QCOM >+ help >+Support for the global clock controller on SDM660 devices. >+Say Y if you want to use peripheral devices such as UART, SPI, >+i2C, USB, UFS, SDDC, PCIe, etc. >+ > config SDM_GCC_845 > tristate "SDM845 Global Clock Controller" > select QCOM_GDSC >diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile >index 935f142bc155..ab892f6d847c 100644 >--- a/drivers/clk/qcom/Makefile >+++ b/drivers/clk/qcom/Makefile >@@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o > obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o > obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o > obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o >+obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o > obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o > obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o > obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o >diff --git a/drivers/clk/qcom/gcc-sdm660.c >b/drivers/clk/qcom/gcc-sdm660.c >new file mode 100644 >index ..641bba611b5f >--- /dev/null >+++ b/drivers/clk/qcom/gcc-sdm660.c >@@ -0,0 +1,2480 @@ >+// SPDX-License-Identifier: GPL-2.0 >+/* >+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved. >+ * Copyright (c) 2018, Craig Tatlor. >+ */ >+ >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+ >+#include >+ >+#include "common.h" >+#include "clk-regmap.h" >+#include "clk-alpha-pll.h" >+#include "clk-rcg.h" >+#include "clk-branch.h" >+#include "reset.h" >+#include "gdsc.h" >+ >+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } >+ >+enum { >+ P_XO, >+ P_SLEEP_CLK, >+ P_GPLL0, >+ P_GPLL1, >+ P_GPLL4, >+ P_GPLL0_EARLY_DIV, >+ P_GPLL1_EARLY_DIV, >+}; >+ >+static const struct parent_map >gcc_parent_map_xo_gpll0_gpll0_early_div[] = { >+ { P_XO, 0 }, >+ { P_GPLL0, 1 }, >+ { P_GPLL0_EARLY_DIV, 6 }, >+}; >+ >+static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[] >= { >+ "xo", >+ "gpll0", >+ "gpll0_early_div", >+}; >+ >+static const struct parent_map gcc_parent_map_xo_gpll0[] = { >+ { P_XO, 0 }, >+ { P_GPLL0, 1 }, >+}; >+ >+static const char * const gcc_parent_names_xo_gpll0[] = { >+
Re: [PATCH V3 0/4] Changes for SDCC5 version
Any updates on this? On 25 September 2018 16:39:33 BST, Craig wrote: > > >On 25 September 2018 12:17:26 BST, Veerabhadrarao Badiganti > wrote: >> >>On 9/25/2018 1:18 AM, Craig Tatlor wrote: >>> What socs have you tested this on? >>> On sdm660 it seems to crash device >>> when writing pwr ctl. >> >>Hi >>We have tested this on SDM845. >>SDM660 also has SDCC5 controller, so you would need to define >>"qcom,sdhci-msm-v5" in your platform dt. >>Can you confirm if you have defined this? >> >Hi, >Yes my DT entry is as follows > >sdhc_1: sdhci@f9824900 { > >compatible = "qcom,sdhci-msm-v5"; > >reg = <0xc0c4000 0x1000>, <0xc0c5000 0x1000>; > >interrupts = ; > >interrupt-names = "pwr_irq"; > > >bus-width = <8>; > >non-removable; > > >vmmc-supply = <&pm660l_l4>; > >vqmmc-supply = <&pm660_l8>; > > >pinctrl-names = "default"; > >pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data &sdc1_rclk>; > > >clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; > >clock-names = "core", "iface"; > >}; > >>BTW, can you please share few details of the platform that you are >>checking? >>We are not aware of any dev platform based on SDM660. This is just for > >>my info > >I'm checking on the sony xperia xa2 (pioneer) smartphone. >> >>> On Tue, Jun 19, 2018 at 11:09:17AM +0530, Vijay Viswanath wrote: >>>> With SDCC5, the MCI register space got removed and the offset/order >>of >>>> several registers have changed. Based on SDCC version used and the >>register, >>>> we need to pick the base address and offset. >>>> >>>> Depends on patch series: "[PATCH V5 0/2] mmc: sdhci-msm: >Configuring >>IO_PAD support for sdhci-msm" >>>> >>>> Changes since RFC: >>>>Dropped voltage regulator changes in sdhci-msm >>>>Split the "Register changes for sdcc V5" patch >>>>Instead of checking mci removal for deciding which base addr to >>use, >>>>new function pointers are defined for the 2 variants of sdcc: >>>>1) MCI present >>>>2) V5 (mci removed) >>>>Instead of string comparing with the compatible string from DT >>file, >>>>the sdhci_msm_probe will now pick the data associated with the >>>>compatible entry and use it to load variant specific address >>offsets >>>>and msm variant specific read/write ops. >>>> >>>> Changes since V1: >>>>Removed unused msm_reab & msm_writeb APIs >>>>Changed certain register addresses from uppercase to lowercase hex >>>>letters >>>>Removed extra lines and spaces >>>>Split "[PATCH V1 0/3] Changes for SDCC5 version" patch into two, >>>>one for Documentation and other for the driver changes. >>>> >>>> Changes since V2: >>>>Used lower case for macro function defenitions >>>>Removed unused function pointers for msm_readb & msm_writeb >>>> >>>> >>>> Sayali Lokhande (3): >>>>mmc: sdhci-msm: Define new Register address map >>>>Documentation: sdhci-msm: Add new compatible string for SDCC v5 >>>>mmc: host: Register changes for sdcc V5 >>>> >>>> Vijay Viswanath (1): >>>>mmc: sdhci-msm: Add msm version specific ops and data structures >>>> >>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 7 +- >>>> drivers/mmc/host/sdhci-msm.c | 511 >>- >>>> 2 files changed, 391 insertions(+), 127 deletions(-) >>>> >>>> -- >>>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation >>Center, Inc. >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >a >>Linux Foundation Collaborative Project. >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>linux-arm-msm" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>Thanks, >>Veera -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v3 1/2] pinctrl: qcom: Add sdm660 pinctrl driver
Hey, You seem to have missed the bindings, it might be an idea to drop and reapply with the new ones I just sent off when they get a review. On 26 September 2018 07:57:41 BST, Linus Walleij wrote: >On Tue, Sep 25, 2018 at 7:38 PM Craig Tatlor >wrote: > >> From: Neeraj Upadhyay >> >> Add initial pinctrl driver to support pin configuration with >> pinctrl framework for sdm660. >> Based off CAF implementation. >> >> Signed-off-by: Neeraj Upadhyay >> Co-Developed-by: Venkatesh Yadav Abbarapu >> Signed-off-by: Venkatesh Yadav Abbarapu >> [craig: minor updates for upstreaming, updated tile handling] >> Signed-off-by: Craig Tatlor > >Co-Developed-by? That was innovative. > >Anyways, since there is also a signoff all is fine. > >Patch applied with Björn's ACK. > >Yours, >Linus Walleij -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH v4 1/2] pinctrl: qcom: Add sdm660 pinctrl driver
From: Neeraj Upadhyay Add initial pinctrl driver to support pin configuration with pinctrl framework for sdm660. Based off CAF implementation. Signed-off-by: Neeraj Upadhyay Co-Developed-by: Venkatesh Yadav Abbarapu Signed-off-by: Venkatesh Yadav Abbarapu [craig: minor updates for upstreaming, updated tile handling] Signed-off-by: Craig Tatlor Reviewed-by: Bjorn Andersson --- Changes from v3: none drivers/pinctrl/qcom/Kconfig |9 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sdm660.c | 1455 + 3 files changed, 1465 insertions(+) create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c Changes from V2: Sort everything Use tiles Add sdm630 compatible diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig index c17bfe3a93ea..836e9f3eae4c 100644 --- a/drivers/pinctrl/qcom/Kconfig +++ b/drivers/pinctrl/qcom/Kconfig @@ -155,6 +155,15 @@ config PINCTRL_QCOM_SSBI_PMIC which are using SSBI for communication with SoC. Example PMIC's devices are pm8058 and pm8921. +config PINCTRL_SDM660 + tristate "Qualcomm Technologies Inc SDM660 pin controller driver" + depends on GPIOLIB && OF + select PINCTRL_MSM + help + This is the pinctrl, pinmux, pinconf and gpiolib driver for the + Qualcomm Technologies Inc TLMM block found on the Qualcomm + Technologies Inc SDM660 platform. + config PINCTRL_SDM845 tristate "Qualcomm Technologies Inc SDM845 pin controller driver" depends on GPIOLIB && OF diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile index 98b18b8cd2cc..344b4c6a6c6e 100644 --- a/drivers/pinctrl/qcom/Makefile +++ b/drivers/pinctrl/qcom/Makefile @@ -20,4 +20,5 @@ obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-gpio.o obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o +obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o diff --git a/drivers/pinctrl/qcom/pinctrl-sdm660.c b/drivers/pinctrl/qcom/pinctrl-sdm660.c new file mode 100644 index ..6838b38555a1 --- /dev/null +++ b/drivers/pinctrl/qcom/pinctrl-sdm660.c @@ -0,0 +1,1455 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2016, The Linux Foundation. All rights reserved. + * Copyright (c) 2018, Craig Tatlor. + */ + +#include +#include +#include +#include + +#include "pinctrl-msm.h" + +static const char * const sdm660_tiles[] = { + "north", + "center", + "south" +}; + +enum { + NORTH, + CENTER, + SOUTH +}; + +#define REG_SIZE 0x1000 + +#define FUNCTION(fname)\ + [msm_mux_##fname] = { \ + .name = #fname, \ + .groups = fname##_groups, \ + .ngroups = ARRAY_SIZE(fname##_groups), \ + } + + +#define PINGROUP(id, base, f1, f2, f3, f4, f5, f6, f7, f8, f9) \ + { \ + .name = "gpio" #id, \ + .pins = gpio##id##_pins,\ + .npins = (unsigned)ARRAY_SIZE(gpio##id##_pins), \ + .funcs = (int[]){ \ + msm_mux_gpio, /* gpio mode */ \ + msm_mux_##f1, \ + msm_mux_##f2, \ + msm_mux_##f3, \ + msm_mux_##f4, \ + msm_mux_##f5, \ + msm_mux_##f6, \ + msm_mux_##f7, \ + msm_mux_##f8, \ + msm_mux_##f9\ + }, \ + .nfuncs = 10, \ + .ctl_reg = base + REG_SIZE * id,\ + .io_reg = base + 0x4 + REG_SIZE * id, \ + .intr_cfg_reg = base + 0x8 + REG_SIZE * id, \ + .intr_status_reg = base + 0xc + REG_SIZE * id, \ + .intr_target_reg = base + 0x8 + REG_SIZE * id, \ + .mux_bit = 2, \ + .pull_bit = 0, \ + .drv_bit = 6, \ + .oe_bit = 9,\ + .in_bit = 0,\ + .out_bit = 1, \ + .intr_enable_bit = 0, \ + .intr_status_bit = 0, \
[PATCH v4 2/2] dt-bindings: pinctrl: qcom: Add SDM660 pinctrl binding
Add the binding for the TLMM pinctrl block found in the SDM660 platform. Signed-off-by: Craig Tatlor --- Changes from v3: Updated for tile structure change irq field .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 181 ++ 1 file changed, 181 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt new file mode 100644 index ..97e6622c0b85 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt @@ -0,0 +1,191 @@ +Qualcomm Technologies, Inc. SDM660 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM660 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sdm660-pinctrl" or + "qcom,sdm630-pinctrl". + +- reg: + Usage: required + Value type: + Definition: the base address and size of the north, center and south + TLMM tiles. + +- reg-names: + Usage: required + Value type: + Definition: names for the cells of reg, must contain "north", "center" + and "south". + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- gpio-ranges: + Usage: required + Value type: + Definition: Specifies the mapping between gpio controller and + pin-controller pins. + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio113, + Supports mux, bias and drive-strength + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk, + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_gpsadc0, atest_gpsadc1, + atest_tsens, atest_tsens2, atest_usb1, atest_usb10, + atest_usb11, atest_usb12, atest_usb13, atest_usb2, + atest_usb20, atest_usb21, atest_usb22, atest_usb23, + audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2, + blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, + blsp_i2c8_a, blsp_i2c8_b, blsp_spi1, blsp_spi2, blsp_spi3, + blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi4, blsp_spi5, + blsp_spi6, blsp_spi7, blsp_spi8_a, b
[PATCH v3 1/2] pinctrl: qcom: Add sdm660 pinctrl driver
From: Neeraj Upadhyay Add initial pinctrl driver to support pin configuration with pinctrl framework for sdm660. Based off CAF implementation. Signed-off-by: Neeraj Upadhyay Co-Developed-by: Venkatesh Yadav Abbarapu Signed-off-by: Venkatesh Yadav Abbarapu [craig: minor updates for upstreaming, updated tile handling] Signed-off-by: Craig Tatlor --- drivers/pinctrl/qcom/Kconfig |9 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sdm660.c | 1455 + 3 files changed, 1465 insertions(+) create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c Changes from V2: Sort everything Use tiles Add sdm630 compatible diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig index c17bfe3a93ea..836e9f3eae4c 100644 --- a/drivers/pinctrl/qcom/Kconfig +++ b/drivers/pinctrl/qcom/Kconfig @@ -155,6 +155,15 @@ config PINCTRL_QCOM_SSBI_PMIC which are using SSBI for communication with SoC. Example PMIC's devices are pm8058 and pm8921. +config PINCTRL_SDM660 + tristate "Qualcomm Technologies Inc SDM660 pin controller driver" + depends on GPIOLIB && OF + select PINCTRL_MSM + help + This is the pinctrl, pinmux, pinconf and gpiolib driver for the + Qualcomm Technologies Inc TLMM block found on the Qualcomm + Technologies Inc SDM660 platform. + config PINCTRL_SDM845 tristate "Qualcomm Technologies Inc SDM845 pin controller driver" depends on GPIOLIB && OF diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile index 98b18b8cd2cc..344b4c6a6c6e 100644 --- a/drivers/pinctrl/qcom/Makefile +++ b/drivers/pinctrl/qcom/Makefile @@ -20,4 +20,5 @@ obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-gpio.o obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o +obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o diff --git a/drivers/pinctrl/qcom/pinctrl-sdm660.c b/drivers/pinctrl/qcom/pinctrl-sdm660.c new file mode 100644 index ..6838b38555a1 --- /dev/null +++ b/drivers/pinctrl/qcom/pinctrl-sdm660.c @@ -0,0 +1,1455 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2016, The Linux Foundation. All rights reserved. + * Copyright (c) 2018, Craig Tatlor. + */ + +#include +#include +#include +#include + +#include "pinctrl-msm.h" + +static const char * const sdm660_tiles[] = { + "north", + "center", + "south" +}; + +enum { + NORTH, + CENTER, + SOUTH +}; + +#define REG_SIZE 0x1000 + +#define FUNCTION(fname)\ + [msm_mux_##fname] = { \ + .name = #fname, \ + .groups = fname##_groups, \ + .ngroups = ARRAY_SIZE(fname##_groups), \ + } + + +#define PINGROUP(id, base, f1, f2, f3, f4, f5, f6, f7, f8, f9) \ + { \ + .name = "gpio" #id, \ + .pins = gpio##id##_pins,\ + .npins = (unsigned)ARRAY_SIZE(gpio##id##_pins), \ + .funcs = (int[]){ \ + msm_mux_gpio, /* gpio mode */ \ + msm_mux_##f1, \ + msm_mux_##f2, \ + msm_mux_##f3, \ + msm_mux_##f4, \ + msm_mux_##f5, \ + msm_mux_##f6, \ + msm_mux_##f7, \ + msm_mux_##f8, \ + msm_mux_##f9\ + }, \ + .nfuncs = 10, \ + .ctl_reg = base + REG_SIZE * id,\ + .io_reg = base + 0x4 + REG_SIZE * id, \ + .intr_cfg_reg = base + 0x8 + REG_SIZE * id, \ + .intr_status_reg = base + 0xc + REG_SIZE * id, \ + .intr_target_reg = base + 0x8 + REG_SIZE * id, \ + .mux_bit = 2, \ + .pull_bit = 0, \ + .drv_bit = 6, \ + .oe_bit = 9,\ + .in_bit = 0,\ + .out_bit = 1, \ + .intr_enable_bit = 0, \ + .intr_status_bit = 0, \ + .intr_target_bit = 5, \
[PATCH v3 2/2] dt-bindings: pinctrl: qcom: Add SDM660 pinctrl binding
Add the binding for the TLMM pinctrl block found in the SDM660 platform. Signed-off-by: Craig Tatlor --- .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 181 ++ 1 file changed, 181 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt new file mode 100644 index ..97e6622c0b85 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt @@ -0,0 +1,181 @@ +Qualcomm Technologies, Inc. SDM660 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM660 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sdm660-pinctrl" or + "qcom,sdm630-pinctrl". + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- gpio-ranges: + Usage: required + Value type: + Definition: Specifies the mapping between gpio controller and + pin-controller pins. + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio113, + Supports mux, bias and drive-strength + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk, + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_gpsadc0, atest_gpsadc1, + atest_tsens, atest_tsens2, atest_usb1, atest_usb10, + atest_usb11, atest_usb12, atest_usb13, atest_usb2, + atest_usb20, atest_usb21, atest_usb22, atest_usb23, + audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, blsp_i2c2, + blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, + blsp_i2c8_a, blsp_i2c8_b, blsp_spi1, blsp_spi2, blsp_spi3, + blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi4, blsp_spi5, + blsp_spi6, blsp_spi7, blsp_spi8_a, blsp_spi8_b, + blsp_spi8_cs1, blsp_spi8_cs2, blsp_uart1, blsp_uart2, + blsp_uart5, blsp_uart6_a, blsp_uart6_b, blsp_uim1, + blsp_uim2, blsp_uim5, blsp_uim6, cam_mclk, cci_async, + cci_i2c, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bis
[PATCH v3] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
From: Taniya Das Add support for the global clock controller found on SDM660 based devices. This should allow most non-multimedia device drivers to probe and control their clocks. Based on CAF implementation. Signed-off-by: Taniya Das [craig: rename parents to fit upstream, and other cleanups] Signed-off-by: Craig Tatlor --- Changes from V1: Change authorship Add sdm630 compatible .../devicetree/bindings/clock/qcom,gcc.txt|1 + drivers/clk/qcom/Kconfig |9 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/gcc-sdm660.c | 2480 + include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ 5 files changed, 2650 insertions(+) create mode 100644 drivers/clk/qcom/gcc-sdm660.c create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 664ea1fd6c76..e498ad2e8db8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -38,6 +38,8 @@ Required properties : "qcom,gcc-msm8996" "qcom,gcc-msm8998" "qcom,gcc-mdm9615" + "qcom,gcc-sdm630" + "qcom,gcc-sdm660" "qcom,gcc-sdm845" - reg : shall contain base register location and length diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index 5b181b182f40..4d478b261dfe 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -243,6 +243,15 @@ config SDM_CAMCC_845 Support for the camera clock controller on SDM845 devices. Say Y if you want to support camera devices and camera functionality. +config SDM_GCC_660 + tristate "SDM660 Global Clock Controller" + select QCOM_GDSC + depends on COMMON_CLK_QCOM + help + Support for the global clock controller on SDM660 devices. + Say Y if you want to use peripheral devices such as UART, SPI, + i2C, USB, UFS, SDDC, PCIe, etc. + config SDM_GCC_845 tristate "SDM845 Global Clock Controller" select QCOM_GDSC diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile index 935f142bc155..ab892f6d847c 100644 --- a/drivers/clk/qcom/Makefile +++ b/drivers/clk/qcom/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o +obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c new file mode 100644 index ..641bba611b5f --- /dev/null +++ b/drivers/clk/qcom/gcc-sdm660.c @@ -0,0 +1,2480 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved. + * Copyright (c) 2018, Craig Tatlor. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "common.h" +#include "clk-regmap.h" +#include "clk-alpha-pll.h" +#include "clk-rcg.h" +#include "clk-branch.h" +#include "reset.h" +#include "gdsc.h" + +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } + +enum { + P_XO, + P_SLEEP_CLK, + P_GPLL0, + P_GPLL1, + P_GPLL4, + P_GPLL0_EARLY_DIV, + P_GPLL1_EARLY_DIV, +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[] = { + "xo", + "gpll0", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, +}; + +static const char * const gcc_parent_names_xo_gpll0[] = { + "xo", + "gpll0", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_sleep_clk_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_SLEEP_CLK, 5 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_sleep_clk_gpll0_early_div[] = { + "xo", + "gpll0", + "sleep_clk", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_sleep_clk[] = { + { P_XO, 0 }, + { P_SLEEP_CLK, 5 }, +}; + +static const char * const gcc_parent_names_xo_
[PATCH v2] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
From: Taniya Das Add support for the global clock controller found on SDM660 based devices. This should allow most non-multimedia device drivers to probe and control their clocks. Based on CAF implementation. Signed-off-by: Taniya Das [craig: rename parents to fit upstream, and other cleanups] Signed-off-by: Craig Tatlor --- .../devicetree/bindings/clock/qcom,gcc.txt|1 + drivers/clk/qcom/Kconfig |9 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/gcc-sdm660.c | 2479 + include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ 5 files changed, 2649 insertions(+) create mode 100644 drivers/clk/qcom/gcc-sdm660.c create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 664ea1fd6c76..e498ad2e8db8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -19,6 +19,7 @@ Required properties : "qcom,gcc-msm8996" "qcom,gcc-msm8998" "qcom,gcc-mdm9615" + "qcom,gcc-sdm660" "qcom,gcc-sdm845" - reg : shall contain base register location and length diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index 5b181b182f40..4d478b261dfe 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -243,6 +243,15 @@ config SDM_CAMCC_845 Support for the camera clock controller on SDM845 devices. Say Y if you want to support camera devices and camera functionality. +config SDM_GCC_660 + tristate "SDM660 Global Clock Controller" + select QCOM_GDSC + depends on COMMON_CLK_QCOM + help + Support for the global clock controller on SDM660 devices. + Say Y if you want to use peripheral devices such as UART, SPI, + i2C, USB, UFS, SDDC, PCIe, etc. + config SDM_GCC_845 tristate "SDM845 Global Clock Controller" select QCOM_GDSC diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile index 935f142bc155..ab892f6d847c 100644 --- a/drivers/clk/qcom/Makefile +++ b/drivers/clk/qcom/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_CLK_RPMH) += clk-rpmh.o obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o obj-$(CONFIG_SDM_CAMCC_845) += camcc-sdm845.o obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o +obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c new file mode 100644 index ..cec8b4145b71 --- /dev/null +++ b/drivers/clk/qcom/gcc-sdm660.c @@ -0,0 +1,2479 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved. + * Copyright (c) 2018, Craig Tatlor. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "common.h" +#include "clk-regmap.h" +#include "clk-alpha-pll.h" +#include "clk-rcg.h" +#include "clk-branch.h" +#include "reset.h" +#include "gdsc.h" + +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } + +enum { + P_XO, + P_SLEEP_CLK, + P_GPLL0, + P_GPLL1, + P_GPLL4, + P_GPLL0_EARLY_DIV, + P_GPLL1_EARLY_DIV, +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[] = { + "xo", + "gpll0", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, +}; + +static const char * const gcc_parent_names_xo_gpll0[] = { + "xo", + "gpll0", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_sleep_clk_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_SLEEP_CLK, 5 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_sleep_clk_gpll0_early_div[] = { + "xo", + "gpll0", + "sleep_clk", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_sleep_clk[] = { + { P_XO, 0 }, + { P_SLEEP_CLK, 5 }, +}; + +static const char * const gcc_parent_names_xo_sleep_clk[] = { + "xo", + "sleep_clk&quo
Re: [PATCH V3 0/4] Changes for SDCC5 version
On 25 September 2018 12:17:26 BST, Veerabhadrarao Badiganti wrote: > >On 9/25/2018 1:18 AM, Craig Tatlor wrote: >> What socs have you tested this on? >> On sdm660 it seems to crash device >> when writing pwr ctl. > >Hi >We have tested this on SDM845. >SDM660 also has SDCC5 controller, so you would need to define >"qcom,sdhci-msm-v5" in your platform dt. >Can you confirm if you have defined this? > Hi, Yes my DT entry is as follows sdhc_1: sdhci@f9824900 { compatible = "qcom,sdhci-msm-v5"; reg = <0xc0c4000 0x1000>, <0xc0c5000 0x1000>; interrupts = ; interrupt-names = "pwr_irq"; bus-width = <8>; non-removable; vmmc-supply = <&pm660l_l4>; vqmmc-supply = <&pm660_l8>; pinctrl-names = "default"; pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data &sdc1_rclk>; clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; clock-names = "core", "iface"; }; >BTW, can you please share few details of the platform that you are >checking? >We are not aware of any dev platform based on SDM660. This is just for >my info I'm checking on the sony xperia xa2 (pioneer) smartphone. > >> On Tue, Jun 19, 2018 at 11:09:17AM +0530, Vijay Viswanath wrote: >>> With SDCC5, the MCI register space got removed and the offset/order >of >>> several registers have changed. Based on SDCC version used and the >register, >>> we need to pick the base address and offset. >>> >>> Depends on patch series: "[PATCH V5 0/2] mmc: sdhci-msm: Configuring >IO_PAD support for sdhci-msm" >>> >>> Changes since RFC: >>> Dropped voltage regulator changes in sdhci-msm >>> Split the "Register changes for sdcc V5" patch >>> Instead of checking mci removal for deciding which base addr to >use, >>> new function pointers are defined for the 2 variants of sdcc: >>> 1) MCI present >>> 2) V5 (mci removed) >>> Instead of string comparing with the compatible string from DT >file, >>> the sdhci_msm_probe will now pick the data associated with the >>> compatible entry and use it to load variant specific address >offsets >>> and msm variant specific read/write ops. >>> >>> Changes since V1: >>> Removed unused msm_reab & msm_writeb APIs >>> Changed certain register addresses from uppercase to lowercase hex >>> letters >>> Removed extra lines and spaces >>> Split "[PATCH V1 0/3] Changes for SDCC5 version" patch into two, >>> one for Documentation and other for the driver changes. >>> >>> Changes since V2: >>> Used lower case for macro function defenitions >>> Removed unused function pointers for msm_readb & msm_writeb >>> >>> >>> Sayali Lokhande (3): >>>mmc: sdhci-msm: Define new Register address map >>>Documentation: sdhci-msm: Add new compatible string for SDCC v5 >>>mmc: host: Register changes for sdcc V5 >>> >>> Vijay Viswanath (1): >>>mmc: sdhci-msm: Add msm version specific ops and data structures >>> >>> .../devicetree/bindings/mmc/sdhci-msm.txt | 7 +- >>> drivers/mmc/host/sdhci-msm.c | 511 >- >>> 2 files changed, 391 insertions(+), 127 deletions(-) >>> >>> -- >>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation >Center, Inc. >>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >Linux Foundation Collaborative Project. >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >linux-arm-msm" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >Thanks, >Veera -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
On 24 September 2018 20:19:29 BST, Bjorn Andersson wrote: >On Sat 11 Aug 09:25 PDT 2018, Craig Tatlor wrote: > >> Initial device tree support for Qualcomm SDM630 SoC and >> Sony Pioneer (Xperia XA2). >> >> SDM630 is based off of the SDM660 soc and all SDM660 specific drivers >are >> compatible with it. SDM660 is also based off of MSM8998 so it uses >some >> of its drivers aswell. > >Consider adding both sdm630 and sdm660 compatibles to the bindings and >drivers and use the right one in the dts, in case we find details that >differs in the future. This includes pinctrl and GCC? > >> >> The device tree is based on the CAF 4.4 kernel tree. >> >> The device can be booted into the initrd with a shell over UART. >> >> Signed-off-by: Craig Tatlor >[..] >> diff --git a/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi >b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi >> new file mode 100644 >> index ..78b79c1076f1 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi >> @@ -0,0 +1,17 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* Copyright (c) 2018, Craig Tatlor. */ >> + >> +&tlmm { >> +blsp1_uart1_default: blsp1_uart1_default { >> +pinmux { >> +pins = "gpio0", "gpio1", "gpio2", "gpio3"; >> +function = "gpio"; > >Please put these in the sdm630.dtsi directly, rather than spreading the >pins out in a separate file. > Okay, just followed what 8996 did >> +}; >> + >> +pinconf { >> +pins = "gpio0", "gpio1", "gpio2", "gpio3"; >> +drive-strength = <2>; >> +bias-disable; > >Please extend &blsp1_uart1_default in the pioneer dtsi with these >"electrical properties". Are you meaning to put this in the pioneer DTS or just drive strength and bias? > >> + }; >> +}; >> +}; >[..] >> diff --git a/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi >b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi >> new file mode 100644 >> index ..512792c23369 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi >> @@ -0,0 +1,22 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* Copyright (c) 2018, Craig Tatlor. */ >> + >> +#include "sdm630.dtsi" >> + >> +/ { >> +aliases { >> +serial0 = &blsp1_uart1; >> +}; >> + >> +chosen { >> +stdout-path = "serial0:115200n8"; >> +}; >> +}; >> + >> +&soc { >> +serial@c17 { > >Please reference this by &blsp1_uart1, rather than duplicating the >hierarchy. Okay, should the same still apply once more stuff is in soc? Or should I use references for them? > >> +status = "okay"; >> +pinctrl-names = "default"; >> +pinctrl-0 = <&blsp1_uart1_default>; >> +}; >> +}; >> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi >b/arch/arm64/boot/dts/qcom/sdm630.dtsi >> new file mode 100644 >> index ..8a544979b7c0 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi >> @@ -0,0 +1,383 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* Copyright (c) 2018, Craig Tatlor. */ >> + >> +#include >> +#include >> + >> +/ { >> +model = "Qualcomm Technologies, Inc. SDM630"; > >We expect the board to always override this, so no need to specify it >here. Yup >> + >> +interrupt-parent = <&intc>; >> + >> +qcom,msm-id = <318 0x0>; >> + >> +#address-cells = <2>; >> +#size-cells = <2>; >> + >> +chosen { }; >> + >> +memory { >> +device_type = "memory"; >> +/* We expect the bootloader to fill in the reg */ >> +reg = <0 0 0 0>; >> +}; >> + >> + > >Extra empty line. Okay >> +cpus { >[..] >> + >> +timer { > >Please sort these nodes by name, except for "soc" which is convenient >to have last. Okay > >> +compatible = "arm,armv8-timer"; >> +interrupts = , >> + , >> + , >> + ; >> +}; >[
Re: [PATCH v2] pinctrl: qcom: Add sdm660 pinctrl driver
On 24 September 2018 19:53:06 BST, Bjorn Andersson wrote: >On Sun 12 Aug 07:24 PDT 2018, Craig Tatlor wrote: > >> Add initial pinctrl driver to support pin configuration with >> pinctrl framework for sdm660. >> Based off CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- >> >> Changes from v1: >> Adds gpio-ranges property to bindings >> >> >> .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 202 +++ > >As the DT binding part of the patch is significant, please split it >into >its own patch. > Right >> drivers/pinctrl/qcom/Kconfig | 10 + >> drivers/pinctrl/qcom/Makefile |1 + >> drivers/pinctrl/qcom/pinctrl-sdm660.c | 1451 >+ >> 4 files changed, 1663 insertions(+) >> create mode 100644 >Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c >> >> diff --git >a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >[..] >> +- function: >> +Usage: required >> +Value type: >> +Definition: Specify the alternative function to be configured for >the >> +specified pins. Functions are only valid for gpio pins. >> +Valid values are: >> + >> +blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, >> +bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, >> +qdss_cti_trig_out_b, bimc_dte0, dac_calib1, >qdss_cti_trig_in_b, >> +dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, >> blsp_uart10, >> +blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, >atest_usb12, >> +mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, >> +atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, >atest_char, >> +cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, >qdss_tracedata_b, >> +pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, >cci_i2c, >> +qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, >> +qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, >> +atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6, >> +atest_usb20, atest_char0, dac_calib10, qdss_stm10, >> +qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, >blsp_uim6, >> +blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11, >> +qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1, >> +qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11, >> +dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6, >> +qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, >> +dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, >> +dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, >> +dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, >> +dac_calib22, dac_calib23, dac_calib24, tsif1_sync, >dac_calib25, >> +sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, >> +qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, >blsp_i2c3, >> +uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, >> blsp_i2c9, >> +blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, >> blsp_i2c7, >> +qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, >blsp_uart11, >> +blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, >cri_trng0, >> +cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, >blsp_spi4, >> +blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4, >> +qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus, >> +isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, >> ter_mi2s, >> +qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, >> gcc_gp1_clk_b, >> +sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b, >> +gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, >> blsp_uim12, >> +qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29, >> +tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, >qdss_stm27, >> +
Re: [PATCH V3 0/4] Changes for SDCC5 version
What socs have you tested this on? On sdm660 it seems to crash device when writing pwr ctl. On Tue, Jun 19, 2018 at 11:09:17AM +0530, Vijay Viswanath wrote: > With SDCC5, the MCI register space got removed and the offset/order of > several registers have changed. Based on SDCC version used and the register, > we need to pick the base address and offset. > > Depends on patch series: "[PATCH V5 0/2] mmc: sdhci-msm: Configuring IO_PAD > support for sdhci-msm" > > Changes since RFC: > Dropped voltage regulator changes in sdhci-msm > Split the "Register changes for sdcc V5" patch > Instead of checking mci removal for deciding which base addr to use, > new function pointers are defined for the 2 variants of sdcc: > 1) MCI present > 2) V5 (mci removed) > Instead of string comparing with the compatible string from DT file, > the sdhci_msm_probe will now pick the data associated with the > compatible entry and use it to load variant specific address offsets > and msm variant specific read/write ops. > > Changes since V1: > Removed unused msm_reab & msm_writeb APIs > Changed certain register addresses from uppercase to lowercase hex > letters > Removed extra lines and spaces > Split "[PATCH V1 0/3] Changes for SDCC5 version" patch into two, > one for Documentation and other for the driver changes. > > Changes since V2: > Used lower case for macro function defenitions > Removed unused function pointers for msm_readb & msm_writeb > > > Sayali Lokhande (3): > mmc: sdhci-msm: Define new Register address map > Documentation: sdhci-msm: Add new compatible string for SDCC v5 > mmc: host: Register changes for sdcc V5 > > Vijay Viswanath (1): > mmc: sdhci-msm: Add msm version specific ops and data structures > > .../devicetree/bindings/mmc/sdhci-msm.txt | 7 +- > drivers/mmc/host/sdhci-msm.c | 511 > - > 2 files changed, 391 insertions(+), 127 deletions(-) > > -- > Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, > Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux > Foundation Collaborative Project. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
On 24 September 2018 13:44:33 BST, Heiko Stuebner wrote: >Hi Craig, > >Am Montag, 13. August 2018, 09:45:09 CEST schrieb Craig Tatlor: >> On 13 August 2018 07:55:34 BST, Taniya Das >wrote: >> >Hello Craig, >> > >> >Could you please correct the authorship and also provide the >reference >> >to code where this is picked from? >> Okay, >> Got code from here >https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.6.4.r1/drivers/clk/qcom/gcc-sdm660.c >> but changed it quite a bit for upstream, >> Should I change the commit author and add your signed off by and say >I did cleanups on my signed off by. > >yep, for something this huge it is really the correct way to keep the >original authorship intact as Taniya did the initial big work, and just >add you change-description, so something like > > 8< -- >Add support for the global clock controller found on SDM660 >based devices. This should allow most non-multimedia device >drivers to probe and control their clocks. >Based on CAF implementation. > >Signed-off-by: Taniya Das >[ description of changes ... often seen in these brackets ] >Signed-off-by: Craig Tatlor > 8< -- > Sure, will do, though I'm sure qcom have a program to generate the drivers :) >Also, do you plan to continue working on this, as I would be >interessted >in the clock driver for a sdm660-based phone as well Yup, was really just waiting for reply to this question, > > >Thanks >Heiko --
Re: [PATCH v7 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
On 20 September 2018 17:58:47 BST, Sebastian Reichel wrote: >[Dropped a couple of people from CC, added Baolin] > >Hi Craig, Baolin and Rob, > >On Thu, Sep 20, 2018 at 03:32:29PM +0100, Craig wrote: >> On 16 September 2018 13:10:45 BST, Sebastian Reichel > wrote: >> >Sorry for my long delay in reviewing this. I like the binding, >> >but the "qcom," specific properties should become common properties >> >in >> > >> >Documentation/devicetree/bindings/power/supply/battery.txt >> >and referenced via monitored-battery. > >> Thanks for the review, what bindings for ocv would you prefer? The >> spreadtrum ones or mine? > >Most importantly I want to see only one generic binding supporting >both use cases. As far as I can see there are two major differences: > >1. Qcom uses legend properties and SC27XX embedds this into data >2. Qcom supports temperature based mapping > >The second point is easy: Not having temperature information can >be a subset of the data with temperature info. The main thing to >discuss are the legend properties. I suppose we have these >proposals: > >Proposal A (from Qcom BMS binding): > >ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 70 65 60 55 50 45 >...>; >ocv-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; >ocv-lut-microvolt = <4305 4305 4303 4299 > >Proposal B (from SC27XX binding): > >ocv-cap-table = <4185 100>, <4113 95>, <4066 90>, <4022 85> ...; > >I prefer the second binding (with mV -> uV), but I think it becomes >messy when temperature is added. What do you think about the >following proposal (derived from pinctrl style): > >Proposal C: > >ocv-capacity-table-temperatures = <(-10) 0 10>; >ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...; >ocv-capacity-table-1 = <420 100>, <4185000 95>, <4113000 90>, ...; >ocv-capacity-table-2 = <425 100>, <420 95>, <4185000 90>, ...; > >-- Sebastian C looks good to me however I do kinda think it should be millivolts as I don't think any hardware reads in microvolts and the zeroes make it look quite ugly
Re: [PATCH v7 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
Replies inline On 16 September 2018 14:48:36 BST, Sebastian Reichel wrote: >Hi, > >First of all thanks for the patch and big sorry for the long delay >in reviewing this. I did not find enough time to do it properly >until now :( > >On Thu, Jun 14, 2018 at 04:14:15PM +0100, Craig Tatlor wrote: >> This patch adds a driver for the BMS (Battery Monitoring System) >> block of the PM8941 PMIC, it uses a lookup table defined in the >> device tree to generate a capacity from the BMS supplied OCV, it >> then amends the coulomb counter to that to increase the accuracy >> of the estimated capacity. >> >> Signed-off-by: Craig Tatlor >> Reviewed-by: Linus Walleij >> --- >> >> * Changes from v5: > >> Uses select for REGMAP_SPMI. > >> > >> * Changes from v4: > >> Cleaned up percentage interpolation function, > >> uses new fixp interpolation helper, > >> added some more error cases, > >> uses devm_power_supply_register(), > >> uses a DIV_ROUND_CLOSEST for division and > >> uses micro(volts / amp hours) instead of > >> milli (volts / amp hours). >> >> drivers/power/supply/Kconfig| 9 + >> drivers/power/supply/Makefile | 1 + >> drivers/power/supply/qcom_bms.c | 487 > >> 3 files changed, 497 insertions(+) >> create mode 100644 drivers/power/supply/qcom_bms.c >> >> diff --git a/drivers/power/supply/Kconfig >b/drivers/power/supply/Kconfig >> index 428b426842f4..75f2f375f992 100644 >> --- a/drivers/power/supply/Kconfig >> +++ b/drivers/power/supply/Kconfig >> @@ -82,6 +82,15 @@ config BATTERY_ACT8945A >>Say Y here to enable support for power supply provided by >>Active-semi ActivePath ACT8945A charger. >> >> +config BATTERY_BMS >> +tristate "Qualcomm Battery Monitoring System driver" >> +depends on MFD_SPMI_PMIC || COMPILE_TEST >> +depends on OF >> +select REGMAP_SPMI >> +help >> + Say Y to include support for the Battery Monitoring hardware >> + found in some Qualcomm PM series PMICs. >> + >> config BATTERY_CPCAP >> tristate "Motorola CPCAP PMIC battery driver" >> depends on MFD_CPCAP && IIO >> diff --git a/drivers/power/supply/Makefile >b/drivers/power/supply/Makefile >> index e83aa843bcc6..04204174b047 100644 >> --- a/drivers/power/supply/Makefile >> +++ b/drivers/power/supply/Makefile >> @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X) += >88pm860x_battery.o >> obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o >> obj-$(CONFIG_BATTERY_AXP20X)+= axp20x_battery.o >> obj-$(CONFIG_CHARGER_AXP20X)+= axp20x_ac_power.o >> +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o >> obj-$(CONFIG_BATTERY_CPCAP) += cpcap-battery.o >> obj-$(CONFIG_BATTERY_DS2760)+= ds2760_battery.o >> obj-$(CONFIG_BATTERY_DS2780)+= ds2780_battery.o >> diff --git a/drivers/power/supply/qcom_bms.c >b/drivers/power/supply/qcom_bms.c >> new file mode 100644 >> index ..718fd745c0f7 >> --- /dev/null >> +++ b/drivers/power/supply/qcom_bms.c >> @@ -0,0 +1,487 @@ >> +// SPDX-License-Identifier: GPL >> + >> +/* >> + * Qualcomm Battery Monitoring System driver >> + * >> + * Copyright (C) 2018 Craig Tatlor >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#includ
Re: [PATCH v7 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
On 16 September 2018 13:10:45 BST, Sebastian Reichel wrote: >Hi, > >Sorry for my long delay in reviewing this. I like the binding, >but the "qcom," specific properties should become common properties >in > >Documentation/devicetree/bindings/power/supply/battery.txt Thanks for the review, what bindings for ocv would you prefer? The spreadtrum ones or mine? >and referenced via monitored-battery. > >-- Sebastian > >On Thu, Jun 14, 2018 at 04:14:16PM +0100, Craig Tatlor wrote: >> Add bindings for the Qualcomm Battery Monitoring system. >> >> Signed-off-by: Craig Tatlor >> Reviewed-by: Rob Herring >> --- >> >> * Changes from v6: >> s/celcius/celsius >> change uah to uAh. >> >> * Changes from v5: > >> Mentions which values are 8 bit. > >> > >> * Changes from v4: > >> Uses proper units and expands some definitions, > >> along with changing vadc@ to adc@. >> >> .../bindings/power/supply/qcom_bms.txt| 92 >+++ >> 1 file changed, 92 insertions(+) >> create mode 100644 >Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> >> diff --git >a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> new file mode 100644 >> index ..dc0a9ab9aa64 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> @@ -0,0 +1,92 @@ >> +Qualcomm Battery Monitoring System >> + >> +The Qualcomm Battery Monitoring System is found inside of Qualcomm >PM8941 >> +PMICs. It provides open circuit voltage (OCV) and coulomb counter >registers >> +that allow the OS to infer a capacity level. >> + >> +Required properties: >> +- compatible: Should contain "qcom,pm8941-bms". >> +- reg: Specifies the SPMI address and >length of the >> +controller's registers. >> +- interrupts: OCV threshold interrupt. >> +- io-channels: Should contain IIO channel specifier >for the >> +ADC channel that reports battery temperature. >> +- io-channel-names: Should contain "temp". >> +- qcom,fcc-temp-legend-celsius: An 8 bit array containing the >temperature, >> +in degC, for each column of the full charge >> +capacity lookup table. >> +- qcom,fcc-lut-microamp-hours: An array of full charge capacity >values in uAh, >> +one entry for each temperature defined in in >> +qcom,fcc-temp-legend-celsius. >> +- qcom,ocv-temp-legend-celsius: An 8 bit array containing the >temperature, >> +in degC, for each column of the OCV lookup >> +table. >> +- qcom,ocv-capacity-legend: An 8 bit array containing the >capacity for each >> +row of the OCV lookup table. >> +- qcom,ocv-lut-microvolt: An array of OCV values in uV, one >entry for each >> +capacity defined in qcom,ocv-capacity-legend. >> + >> +Example: >> +pm8941_vadc: adc@3100 { >> +compatible = "qcom,spmi-vadc"; >> +reg = <0x3100>; >> +interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; >> +#address-cells = <1>; >> +#size-cells = <0>; >> +#io-channel-cells = <1>; >> + >> +bat_temp { >> +reg = ; >> +}; >> +}; >> + >> +bms@4000 { >> +compatible = "qcom,pm8941-bms"; >> +reg = <0x4000>; >> +interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISI
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 20 September 2018 14:01:57 BST, Sricharan R wrote: > > >On 9/20/2018 1:54 AM, Craig wrote: >> Yup, this patch seems to have fixed the higher frequencies from the >quick test I did. >> > Thanks !!. Can i take that as Craig Tatlor ? Sure, no problem > >Regards, > Sricharan > > tested-by: >> On 7 September 2018 15:28:53 BST, Craig Tatlor >wrote: >>> >>> >>> On 7 September 2018 10:57:34 BST, Sricharan R >>> wrote: >>>> Hi Craig, >>>> >>>> >>>>>> [v12] >>>>>> * Added my signed-off that was missing in some patches. >>>>>> * Added Bjorn's acked that i missed earlier. >>>>>> >>>>> >>>>> Can you give this a try on your 8974 device and check if the >>>>> pvs version reporting, scaling for higher frequencies are fine ? >>>>> Sorry, i could not get hold of a 8974 device. So in-case if you >>>> still >>>>> have the issues with higher frequencies, can you give a quick >>> debug >>>>> and report. That would be of great help. >>>>> >>>> Ping on this .. >>> >>> Hi, didn't see your last message, >>> >>> Will have a try on mine in the weekend and report back. >>>> >>>> Regards, >>>> Sricharan >>>> >>>>> Regards, >>>>> Sricharan >>>>> >>>>> >>>>>> [v11] >>>>>> * Dropped patch 13 and 14 from v10 and >>>>>> merged the qcom-cpufreq-krait driver to the existing >>>> qcom-cpufreq-kryo.c >>>>>> * Rebased on top of clk-next >>>>>> * Fixed a bug while populating the pvs version for krait. >>>>>> >>>>>> [v10] >>>>>> * Addressed Stephen's comments to add clocks bindings >properties >>>>>> to the newly introduced nodes. >>>>>> * Added a change to include opp-supported-hw to qcom-cpufreq.c >>>>>> * Rebased on top of clk-next >>>>>> * Although there were minor changes to bindings and the driver >>>>>> retained the acked-by tags from Rob and Viresh respectively. > >>> >>>>>> >>>>>> [v9] >>>>>> * Fixed a rebase issue in Makefile and added Tag from Robh. >>>>>> >>>>>> [v8] >>>>>> * Fixed a bug in path#14 pointed out by Viresh and also added >>>> tags. >>>>>> No change in any other patch. >>>>>> >>>>>> [v7] >>>>>> * Fixed comments from Viresh for cleaning up the error handling >>>>>> in qcom-cpufreq.c. Also changed the init function to lateinit >>>>>> call. This is required because nvmem which gets initialised >>> with >>>>>> module_init needs to go first. >>>>>> * Fixed Rob's comments for bindings documentation >>>>>> * Fixed kbuild build issue in clk-lpc32xx.c >>>>>> * Rebased on top of clk-next >>>>>> >>>>>> [v6] >>>>>> * Adrressed comments from Viresh for patch #14 in v5 [5] >>>>>> * Introduced a new binding operating-points-v2-krait-cpu >>>>>> as per discussion with Rob >>>>>> * Added Review tags >>>>>> >>>>>> [v5] >>>>>> * Addressed comments from Rob for bindings >>>>>> * Addressed comments from Viresh to use >dev_pm_opp_set_prop_name, >>>> accordingly >>>>>> dropped patch #12 and corrected patch #11 from previous patch >>>> set in [4] >>>>>> * Converted to use #spdx tags for newly introduced files >>>>>> >>>>>> Mostly a resend of the v3 posted by Stephen quite some time back >>> [1] >>>>>> except for few changes. >>>>>> Based on reading some feedback from list, >>>>>> * Dropped the patch "clk: Add safe switch hook" from v3 [2]. >>>>>> Now this is taken care by patch#10 in this series only for >>>> Krait. >>>>>> * Dropped the path "clk: Avoid sending high rates to downstream >>>>>>clocks during set_rate" from v3 [3]
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
Yup, this patch seems to have fixed the higher frequencies from the quick test I did. On 7 September 2018 15:28:53 BST, Craig Tatlor wrote: > > >On 7 September 2018 10:57:34 BST, Sricharan R > wrote: >>Hi Craig, >> >> >>>> [v12] >>>> * Added my signed-off that was missing in some patches. >>>> * Added Bjorn's acked that i missed earlier. >>>> >>> >>> Can you give this a try on your 8974 device and check if the >>> pvs version reporting, scaling for higher frequencies are fine ? >>> Sorry, i could not get hold of a 8974 device. So in-case if you >>still >>> have the issues with higher frequencies, can you give a quick >debug >>> and report. That would be of great help. >>> >> Ping on this .. > >Hi, didn't see your last message, > >Will have a try on mine in the weekend and report back. >> >>Regards, >> Sricharan >> >>> Regards, >>> Sricharan >>> >>> >>>> [v11] >>>> * Dropped patch 13 and 14 from v10 and >>>> merged the qcom-cpufreq-krait driver to the existing >>qcom-cpufreq-kryo.c >>>> * Rebased on top of clk-next >>>> * Fixed a bug while populating the pvs version for krait. >>>> >>>> [v10] >>>> * Addressed Stephen's comments to add clocks bindings properties >>>> to the newly introduced nodes. >>>> * Added a change to include opp-supported-hw to qcom-cpufreq.c >>>> * Rebased on top of clk-next >>>> * Although there were minor changes to bindings and the driver >>>> retained the acked-by tags from Rob and Viresh respectively. > >>>> >>>> [v9] >>>> * Fixed a rebase issue in Makefile and added Tag from Robh. >>>> >>>> [v8] >>>> * Fixed a bug in path#14 pointed out by Viresh and also added >>tags. >>>> No change in any other patch. >>>> >>>> [v7] >>>> * Fixed comments from Viresh for cleaning up the error handling >>>> in qcom-cpufreq.c. Also changed the init function to lateinit >>>> call. This is required because nvmem which gets initialised >with >>>> module_init needs to go first. >>>> * Fixed Rob's comments for bindings documentation >>>> * Fixed kbuild build issue in clk-lpc32xx.c >>>> * Rebased on top of clk-next >>>> >>>> [v6] >>>> * Adrressed comments from Viresh for patch #14 in v5 [5] >>>> * Introduced a new binding operating-points-v2-krait-cpu >>>> as per discussion with Rob >>>> * Added Review tags >>>> >>>> [v5] >>>> * Addressed comments from Rob for bindings >>>> * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, >>accordingly >>>> dropped patch #12 and corrected patch #11 from previous patch >>set in [4] >>>> * Converted to use #spdx tags for newly introduced files >>>> >>>> Mostly a resend of the v3 posted by Stephen quite some time back >[1] >>>> except for few changes. >>>> Based on reading some feedback from list, >>>> * Dropped the patch "clk: Add safe switch hook" from v3 [2]. >>>> Now this is taken care by patch#10 in this series only for >>Krait. >>>> * Dropped the path "clk: Avoid sending high rates to downstream >>>> clocks during set_rate" from v3 [3]. >>>> * Rebased on top of clk-next. >>>> * Dropped the DT update from the series. Will send separately >>>> * Now with cpufreq-dt+opp supporting voltage scaling, registering >>the >>>> krait cpu supplies in DT should be sufficient. But one issue >is, >>>> the qcom-cpufreq drivers reads the efuse and based on that >>registers >>>> the opp data and then registers the cpufreq-dt device. So when >>>> cpufreq-dt driver probes and registers the regulator to the OPP >>framework, >>>> it expects that the opp data for the device should not be >>registered before >>>> the regulator. Will send a RFC patch removing that check, to >>find out the >>>> right way of doing it. >
Re: [PATCH V12 00/14] Krait clocks + Krait CPUfreq
On 7 September 2018 10:57:34 BST, Sricharan R wrote: >Hi Craig, > > >>> [v12] >>> * Added my signed-off that was missing in some patches. >>> * Added Bjorn's acked that i missed earlier. >>> >> >> Can you give this a try on your 8974 device and check if the >> pvs version reporting, scaling for higher frequencies are fine ? >> Sorry, i could not get hold of a 8974 device. So in-case if you >still >> have the issues with higher frequencies, can you give a quick debug >> and report. That would be of great help. >> > Ping on this .. Hi, didn't see your last message, Will have a try on mine in the weekend and report back. > >Regards, > Sricharan > >> Regards, >> Sricharan >> >> >>> [v11] >>> * Dropped patch 13 and 14 from v10 and >>> merged the qcom-cpufreq-krait driver to the existing >qcom-cpufreq-kryo.c >>> * Rebased on top of clk-next >>> * Fixed a bug while populating the pvs version for krait. >>> >>> [v10] >>> * Addressed Stephen's comments to add clocks bindings properties >>> to the newly introduced nodes. >>> * Added a change to include opp-supported-hw to qcom-cpufreq.c >>> * Rebased on top of clk-next >>> * Although there were minor changes to bindings and the driver >>> retained the acked-by tags from Rob and Viresh respectively. >>> >>> [v9] >>> * Fixed a rebase issue in Makefile and added Tag from Robh. >>> >>> [v8] >>> * Fixed a bug in path#14 pointed out by Viresh and also added >tags. >>> No change in any other patch. >>> >>> [v7] >>> * Fixed comments from Viresh for cleaning up the error handling >>> in qcom-cpufreq.c. Also changed the init function to lateinit >>> call. This is required because nvmem which gets initialised with >>> module_init needs to go first. >>> * Fixed Rob's comments for bindings documentation >>> * Fixed kbuild build issue in clk-lpc32xx.c >>> * Rebased on top of clk-next >>> >>> [v6] >>> * Adrressed comments from Viresh for patch #14 in v5 [5] >>> * Introduced a new binding operating-points-v2-krait-cpu >>> as per discussion with Rob >>> * Added Review tags >>> >>> [v5] >>> * Addressed comments from Rob for bindings >>> * Addressed comments from Viresh to use dev_pm_opp_set_prop_name, >accordingly >>> dropped patch #12 and corrected patch #11 from previous patch >set in [4] >>> * Converted to use #spdx tags for newly introduced files >>> >>> Mostly a resend of the v3 posted by Stephen quite some time back [1] >>> except for few changes. >>> Based on reading some feedback from list, >>> * Dropped the patch "clk: Add safe switch hook" from v3 [2]. >>> Now this is taken care by patch#10 in this series only for >Krait. >>> * Dropped the path "clk: Avoid sending high rates to downstream >>> clocks during set_rate" from v3 [3]. >>> * Rebased on top of clk-next. >>> * Dropped the DT update from the series. Will send separately >>> * Now with cpufreq-dt+opp supporting voltage scaling, registering >the >>> krait cpu supplies in DT should be sufficient. But one issue is, >>> the qcom-cpufreq drivers reads the efuse and based on that >registers >>> the opp data and then registers the cpufreq-dt device. So when >>> cpufreq-dt driver probes and registers the regulator to the OPP >framework, >>> it expects that the opp data for the device should not be >registered before >>> the regulator. Will send a RFC patch removing that check, to >find out the >>> right way of doing it. >>> >>> These patches provide cpufreq scaling on devices with Krait CPUs. >>> In Krait CPU designs there's one PLL and two muxes per CPU, allowing >>> us to switch CPU frequencies independently. >>> >>> secondary >>> +-++ >>> | QSB |---+|\ >>> +-+ || |-+ >>>|+---|/ | >>>|| + | >>> +-+ || | >>> | PLL |+---+ | primary >>> +-+| || + >>
Re: [RFC PATCH v2] irqchip/gic-v3: Add quirk for msm8996 secured registers
On 4 September 2018 15:05:38 BST, Srinivas Kandagatla wrote: >Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor. >Its been more than 2 years of wait for this to be fixed, which has >no hopes to be fixed. This change was introduced for the "lead device" >on msm8996 platform. It looks like all publicly available msm8996 >devices have this implementation. > >So add a quirk to not access this register on msm8996. > >With this quirk MSM8996 can at least boot out of mainline, >which can help community to work with boards based on MSM8996. > >Without this patch Qualcomm DB820c board reboots when GICR_WAKER >is accessed. > >Signed-off-by: Srinivas Kandagatla >--- >Hi Marc, > >There is no errata associated with this quirk, so I could not add >any entries into Documentation/arm64/silicon-errata.txt Or add >any number to the quirk description. > >Changes since v1: >- renamed gic_v3 references to gic >- added full mask for iidr register match > >thanks, >srini > > drivers/irqchip/irq-gic-v3.c | 29 - > 1 file changed, 28 insertions(+), 1 deletion(-) > >diff --git a/drivers/irqchip/irq-gic-v3.c >b/drivers/irqchip/irq-gic-v3.c >index d5912f1ec884..406d4a44c887 100644 >--- a/drivers/irqchip/irq-gic-v3.c >+++ b/drivers/irqchip/irq-gic-v3.c >@@ -41,6 +41,8 @@ > > #include "irq-gic-common.h" > >+#define FLAGS_WORKAROUND_GICR_WAKER_MSM8996 (1ULL << 0) >+ > struct redist_region { > void __iomem*redist_base; > phys_addr_t phys_base; >@@ -55,6 +57,7 @@ struct gic_chip_data { > struct irq_domain *domain; > u64 redist_stride; > u32 nr_redist_regions; >+ u64 flags; > boolhas_rss; > unsigned intirq_nr; > struct partition_desc *ppi_descs[16]; >@@ -139,6 +142,9 @@ static void gic_enable_redist(bool enable) > u32 count = 100;/* 1s! */ > u32 val; > >+ if (gic_data.flags & FLAGS_WORKAROUND_GICR_WAKER_MSM8996) >+ return; >+ > rbase = gic_data_rdist_rd_base(); > > val = readl_relaxed(rbase + GICR_WAKER); >@@ -1068,13 +1074,31 @@ static const struct irq_domain_ops >partition_domain_ops = { > .select = gic_irq_domain_select, > }; > >+static bool __maybe_unused gic_enable_quirk_msm8996(void *data) >+{ >+ struct gic_chip_data *d = data; >+ >+ d->flags |= FLAGS_WORKAROUND_GICR_WAKER_MSM8996; >+ >+ return true; >+} >+ >+static const struct gic_quirk gic_quirks[] = { >+ { >+ .desc = "GICv3: Qualcomm MSM8996 skip GICR_WAKER Read/Write", >+ .iidr = 0x1070, /* MSM8996 */ >+ .mask = 0x, >+ .init = gic_enable_quirk_msm8996, >+ }, >+}; >+ > static int __init gic_init_bases(void __iomem *dist_base, >struct redist_region *rdist_regs, >u32 nr_redist_regions, >u64 redist_stride, >struct fwnode_handle *handle) > { >- u32 typer; >+ u32 typer, iidr; > int gic_irqs; > int err; > >@@ -1130,6 +1154,9 @@ static int __init gic_init_bases(void __iomem >*dist_base, > if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) && gic_dist_supports_lpis()) > its_init(handle, &gic_data.rdists, gic_data.domain); > >+ iidr = readl_relaxed(dist_base + GICD_IIDR); >+ gic_enable_quirks(iidr, gic_quirks, &gic_data); >+ > gic_smp_init(); > gic_dist_init(); > gic_cpu_init(); This bug also affects sdm660/630 and probably 8998 but I cant verify so it would probably make sense to loosen up the naming for the quirk. --
Re: [PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
On 13 August 2018 07:55:34 BST, Taniya Das wrote: >Hello Craig, > >Could you please correct the authorship and also provide the reference >to code where this is picked from? > Also, don't you have a program that just spits out the clock setup? And I did leave copyright in file. >On 8/11/2018 1:51 AM, Craig Tatlor wrote: >> Add support for the global clock controller found on SDM660 >> based devices. This should allow most non-multimedia device >> drivers to probe and control their clocks. >> Based on CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- >> .../devicetree/bindings/clock/qcom,gcc.txt|1 + >> drivers/clk/qcom/Kconfig |9 + >> drivers/clk/qcom/Makefile |1 + >> drivers/clk/qcom/gcc-sdm660.c | 2479 >+ >> include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ >> 5 files changed, 2649 insertions(+) >> create mode 100644 drivers/clk/qcom/gcc-sdm660.c >> create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h >> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> index 664ea1fd6c76..e498ad2e8db8 100644 >> --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> @@ -19,6 +19,7 @@ Required properties : >> "qcom,gcc-msm8996" >> "qcom,gcc-msm8998" >> "qcom,gcc-mdm9615" >> +"qcom,gcc-sdm660" >> "qcom,gcc-sdm845" >> >> - reg : shall contain base register location and length >> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig >> index 9c3480dcc38a..c4bda6d24c1f 100644 >> --- a/drivers/clk/qcom/Kconfig >> +++ b/drivers/clk/qcom/Kconfig >> @@ -226,6 +226,15 @@ config MSM_GCC_8998 >>Say Y if you want to use peripheral devices such as UART, SPI, >>i2c, USB, UFS, SD/eMMC, PCIe, etc. >> >> +config SDM_GCC_660 >> +tristate "SDM660 Global Clock Controller" >> +select QCOM_GDSC >> +depends on COMMON_CLK_QCOM >> +help >> + Support for the global clock controller on SDM660 devices. >> + Say Y if you want to use peripheral devices such as UART, SPI, >> + i2C, USB, UFS, SDDC, PCIe, etc. >> + >> config SDM_GCC_845 >> tristate "SDM845 Global Clock Controller" >> select QCOM_GDSC >> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile >> index 762c01137c2f..6e37d30d7c02 100644 >> --- a/drivers/clk/qcom/Makefile >> +++ b/drivers/clk/qcom/Makefile >> @@ -38,6 +38,7 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o >> obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o >> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o >> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o >> +obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o >> obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o >> obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o >> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o >> diff --git a/drivers/clk/qcom/gcc-sdm660.c >b/drivers/clk/qcom/gcc-sdm660.c >> new file mode 100644 >> index ..bdb445aa4baa >> --- /dev/null >> +++ b/drivers/clk/qcom/gcc-sdm660.c >> @@ -0,0 +1,2479 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) 2016-2017, The Linux Foundation. All rights >reserved. >> + * Copyright (c) 2018, Craig Tatlor. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> + >> +#include "common.h" >> +#include "clk-regmap.h" >> +#include "clk-alpha-pll.h" >> +#include "clk-rcg.h" >> +#include "clk-branch.h" >> +#include "reset.h" >> +#include "gdsc.h" >> + >> +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } >> + >> +enum { >> +P_XO, >> +P_SLEEP_CLK, >> +P_GPLL0, >> +P_GPLL1, >> +P_GPLL4, >> +P_GPLL0_EARLY_DIV, >> +P_GPLL1_EARLY_DIV, >> +}; >> + >> +static const struct parent_map >gcc_parent_map_xo_gpll0_gpll0_early_div[] = { >> +{ P_XO, 0 }, >> +{ P_GPLL0, 1 }, >
Re: [PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
On 13 August 2018 07:55:34 BST, Taniya Das wrote: >Hello Craig, > >Could you please correct the authorship and also provide the reference >to code where this is picked from? Okay, Got code from here https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.6.4.r1/drivers/clk/qcom/gcc-sdm660.c but changed it quite a bit for upstream, Should I change the commit author and add your signed off by and say I did cleanups on my signed off by. Also, hey, you wrote the original driver :) > >On 8/11/2018 1:51 AM, Craig Tatlor wrote: >> Add support for the global clock controller found on SDM660 >> based devices. This should allow most non-multimedia device >> drivers to probe and control their clocks. >> Based on CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- >> .../devicetree/bindings/clock/qcom,gcc.txt|1 + >> drivers/clk/qcom/Kconfig |9 + >> drivers/clk/qcom/Makefile |1 + >> drivers/clk/qcom/gcc-sdm660.c | 2479 >+ >> include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ >> 5 files changed, 2649 insertions(+) >> create mode 100644 drivers/clk/qcom/gcc-sdm660.c >> create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h >> >> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> index 664ea1fd6c76..e498ad2e8db8 100644 >> --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt >> @@ -19,6 +19,7 @@ Required properties : >> "qcom,gcc-msm8996" >> "qcom,gcc-msm8998" >> "qcom,gcc-mdm9615" >> +"qcom,gcc-sdm660" >> "qcom,gcc-sdm845" >> >> - reg : shall contain base register location and length >> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig >> index 9c3480dcc38a..c4bda6d24c1f 100644 >> --- a/drivers/clk/qcom/Kconfig >> +++ b/drivers/clk/qcom/Kconfig >> @@ -226,6 +226,15 @@ config MSM_GCC_8998 >>Say Y if you want to use peripheral devices such as UART, SPI, >>i2c, USB, UFS, SD/eMMC, PCIe, etc. >> >> +config SDM_GCC_660 >> +tristate "SDM660 Global Clock Controller" >> +select QCOM_GDSC >> +depends on COMMON_CLK_QCOM >> +help >> + Support for the global clock controller on SDM660 devices. >> + Say Y if you want to use peripheral devices such as UART, SPI, >> + i2C, USB, UFS, SDDC, PCIe, etc. >> + >> config SDM_GCC_845 >> tristate "SDM845 Global Clock Controller" >> select QCOM_GDSC >> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile >> index 762c01137c2f..6e37d30d7c02 100644 >> --- a/drivers/clk/qcom/Makefile >> +++ b/drivers/clk/qcom/Makefile >> @@ -38,6 +38,7 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o >> obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o >> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o >> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o >> +obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o >> obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o >> obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o >> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o >> diff --git a/drivers/clk/qcom/gcc-sdm660.c >b/drivers/clk/qcom/gcc-sdm660.c >> new file mode 100644 >> index ..bdb445aa4baa >> --- /dev/null >> +++ b/drivers/clk/qcom/gcc-sdm660.c >> @@ -0,0 +1,2479 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) 2016-2017, The Linux Foundation. All rights >reserved. >> + * Copyright (c) 2018, Craig Tatlor. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> + >> +#include "common.h" >> +#include "clk-regmap.h" >> +#include "clk-alpha-pll.h" >> +#include "clk-rcg.h" >> +#include "clk-branch.h" >> +#include "reset.h" >> +#include "gdsc.h" >> + >> +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } >> + >> +enum { >> +P_XO, >> +P_SLEEP_CLK, >> +P_GPLL0, >> +P_GPLL1, >> +P_GPLL4, >> +P_GPLL0_EARLY_DIV, &
Re: [PATCH v2] pinctrl: qcom: Add sdm660 pinctrl driver
On 13 August 2018 08:24:43 BST, "Michal Vokáč" wrote: >Hi Craig, >On 12.8.2018 16:24, Craig Tatlor wrote: >> Add initial pinctrl driver to support pin configuration with >> pinctrl framework for sdm660. >> Based off CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- > >The documentation portion should be a separate patch. >Please refer to >Documentation/devicetree/bindings/submitting-patches.txt > >It is easier for DT maintainers to review just the relevant part. >The binding patches are also rebased to a separate tree as they are not >Linux specific and can be re-used in other OSes > >Best regards, >Michal I know, just did this because it is basically exactly same as other qcom pinctrl docs and they also only had one patch. Sorry if you got this multiple times, apparently my email client adds HTML to non inline replies > >> Changes from v1: >>Adds gpio-ranges property to bindings >> >> >> .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 202 +++ >> drivers/pinctrl/qcom/Kconfig | 10 + >> drivers/pinctrl/qcom/Makefile |1 + >> drivers/pinctrl/qcom/pinctrl-sdm660.c | 1451 >+ >> 4 files changed, 1663 insertions(+) >> create mode 100644 >Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c >> >> diff --git >a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> new file mode 100644 >> index ..801960ad2112 >> --- /dev/null >> +++ >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> @@ -0,0 +1,202 @@ >> +Qualcomm Technologies, Inc. SDM660 TLMM block >> + >> +This binding describes the Top Level Mode Multiplexer block found in >the >> +SDM660 platform. >> + >> +- compatible: >> +Usage: required >> +Value type: >> +Definition: must be "qcom,sdm660-pinctrl" >> + >> +- reg: >> +Usage: required >> +Value type: >> +Definition: the base address and size of the TLMM register space. >> + >> +- interrupts: >> +Usage: required >> +Value type: >> +Definition: should specify the TLMM summary IRQ. >> + >> +- interrupt-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as an interrupt controller >> + >> +- #interrupt-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +- gpio-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as a gpio controller >> + >> +- gpio-ranges: >> +Usage: required >> +Value type: >> +Definition: Specifies the mapping between gpio controller and >> +pin-controller pins. >> + >> +- #gpio-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +Please refer to ../gpio/gpio.txt and >../interrupt-controller/interrupts.txt for >> +a general description of GPIO and interrupt bindings. >> + >> +Please refer to pinctrl-bindings.txt in this directory for details >of the >> +common pinctrl bindings used by client devices, including the >meaning of the >> +phrase "pin configuration node". >> + >> +The pin configuration nodes act as a container for an arbitrary >number of >> +subnodes. Each of these subnodes represents some desired >configuration for a >> +pin, a group, or a list of pins or groups. This configuration can >include the >> +mux function to select on those pin(s)/group(s), and various pin >configuration >> +parameters, such as pull-up, drive strength, etc. >> + >> + >> +PIN CONFIGURATION NODES: >> + >> +The name of each subnode is not important; all subnodes should be >enumerated >> +and processed purely based on their content. >> + >> +Each subnode only affects those parameters that are explicitly >listed. In >> +other words, a subnode that lists a mux function but no pin >configuration >> +parameters implies no information about any pin configuration >parameters. >> +Similarly, a pin subnode that describes a pullup parameter implies >no >> +info
Re: [PATCH v2] pinctrl: qcom: Add sdm660 pinctrl driver
On 13 August 2018 08:24:43 BST, "Michal Vokáč" wrote: >Hi Craig, >On 12.8.2018 16:24, Craig Tatlor wrote: >> Add initial pinctrl driver to support pin configuration with >> pinctrl framework for sdm660. >> Based off CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- > >The documentation portion should be a separate patch. >Please refer to >Documentation/devicetree/bindings/submitting-patches.txt > >It is easier for DT maintainers to review just the relevant part. >The binding patches are also rebased to a separate tree as they are not >Linux specific and can be re-used in other OSes > >Best regards, >Michal I know, just did this because it is basically exactly same as other qcom pinctrl docs and they also only had one patch. Sorry if you got this multiple times, apparently my email client adds HTML to non inline replies > >> Changes from v1: >>Adds gpio-ranges property to bindings >> >> >> .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 202 +++ >> drivers/pinctrl/qcom/Kconfig | 10 + >> drivers/pinctrl/qcom/Makefile |1 + >> drivers/pinctrl/qcom/pinctrl-sdm660.c | 1451 >+ >> 4 files changed, 1663 insertions(+) >> create mode 100644 >Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c >> >> diff --git >a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> new file mode 100644 >> index ..801960ad2112 >> --- /dev/null >> +++ >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> @@ -0,0 +1,202 @@ >> +Qualcomm Technologies, Inc. SDM660 TLMM block >> + >> +This binding describes the Top Level Mode Multiplexer block found in >the >> +SDM660 platform. >> + >> +- compatible: >> +Usage: required >> +Value type: >> +Definition: must be "qcom,sdm660-pinctrl" >> + >> +- reg: >> +Usage: required >> +Value type: >> +Definition: the base address and size of the TLMM register space. >> + >> +- interrupts: >> +Usage: required >> +Value type: >> +Definition: should specify the TLMM summary IRQ. >> + >> +- interrupt-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as an interrupt controller >> + >> +- #interrupt-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +- gpio-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as a gpio controller >> + >> +- gpio-ranges: >> +Usage: required >> +Value type: >> +Definition: Specifies the mapping between gpio controller and >> +pin-controller pins. >> + >> +- #gpio-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +Please refer to ../gpio/gpio.txt and >../interrupt-controller/interrupts.txt for >> +a general description of GPIO and interrupt bindings. >> + >> +Please refer to pinctrl-bindings.txt in this directory for details >of the >> +common pinctrl bindings used by client devices, including the >meaning of the >> +phrase "pin configuration node". >> + >> +The pin configuration nodes act as a container for an arbitrary >number of >> +subnodes. Each of these subnodes represents some desired >configuration for a >> +pin, a group, or a list of pins or groups. This configuration can >include the >> +mux function to select on those pin(s)/group(s), and various pin >configuration >> +parameters, such as pull-up, drive strength, etc. >> + >> + >> +PIN CONFIGURATION NODES: >> + >> +The name of each subnode is not important; all subnodes should be >enumerated >> +and processed purely based on their content. >> + >> +Each subnode only affects those parameters that are explicitly >listed. In >> +other words, a subnode that lists a mux function but no pin >configuration >> +parameters implies no information about any pin configuration >parameters. >> +Similarly, a pin subnode that describes a pullup parameter implies >no >> +info
[PATCH v2] pinctrl: qcom: Add sdm660 pinctrl driver
Add initial pinctrl driver to support pin configuration with pinctrl framework for sdm660. Based off CAF implementation. Signed-off-by: Craig Tatlor --- Changes from v1: Adds gpio-ranges property to bindings .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 202 +++ drivers/pinctrl/qcom/Kconfig | 10 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sdm660.c | 1451 + 4 files changed, 1663 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt new file mode 100644 index ..801960ad2112 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt @@ -0,0 +1,202 @@ +Qualcomm Technologies, Inc. SDM660 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM660 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sdm660-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- gpio-ranges: + Usage: required + Value type: + Definition: Specifies the mapping between gpio controller and + pin-controller pins. + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio113, + Supports mux, bias and drive-strength + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk, + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4,
[PATCH V2] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
Initial device tree support for Qualcomm SDM630 SoC and Sony Pioneer (Xperia XA2). SDM630 is based off of the SDM660 soc and all SDM660 specific drivers are compatible with it. SDM660 is also based off of MSM8998 so it uses some of its drivers aswell. The device tree is based on the CAF 4.4 kernel tree. The device can be booted into the initrd with a shell over UART. Signed-off-by: Craig Tatlor --- Changes from v1: Adds gpio-ranges node to allow gpio-hogs to function arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/sdm630-pins.dtsi| 17 + arch/arm64/boot/dts/qcom/sdm630-pioneer.dts | 16 + arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi | 22 ++ arch/arm64/boot/dts/qcom/sdm630.dtsi | 384 +++ 5 files changed, 439 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pins.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pioneer.dts create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sdm630.dtsi diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile index 9319e74b8906..80f98bb19998 100644 --- a/arch/arm64/boot/dts/qcom/Makefile +++ b/arch/arm64/boot/dts/qcom/Makefile @@ -6,4 +6,5 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb +dtb-$(CONFIG_ARCH_QCOM)+= sdm630-pioneer.dtb dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb diff --git a/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi new file mode 100644 index ..78b79c1076f1 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +&tlmm { + blsp1_uart1_default: blsp1_uart1_default { + pinmux { + pins = "gpio0", "gpio1", "gpio2", "gpio3"; + function = "gpio"; + }; + + pinconf { + pins = "gpio0", "gpio1", "gpio2", "gpio3"; + drive-strength = <2>; + bias-disable; + }; + }; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts new file mode 100644 index ..67c7e3b57739 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts @@ -0,0 +1,16 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +/dts-v1/; + +#include "sdm630-pioneer.dtsi" + +/ { + model = "Sony Xperia XA2"; + compatible = "sony,pioneer", "qcom,sdm630"; + + /* required for bootloader to select correct board */ + qcom,board-id = <8 0>; + qcom,pmic-id = <0x0001001b 0x0101011a 0x0 0x0>, + <0x0001001b 0x0201011a 0x0 0x0>; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi new file mode 100644 index ..512792c23369 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi @@ -0,0 +1,22 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +#include "sdm630.dtsi" + +/ { + aliases { + serial0 = &blsp1_uart1; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +}; + +&soc { + serial@c17 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&blsp1_uart1_default>; + }; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi new file mode 100644 index ..8a544979b7c0 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi @@ -0,0 +1,384 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +#include +#include + +/ { + model = "Qualcomm Technologies, Inc. SDM630"; + + interrupt-parent = <&intc>; + + qcom,msm-id = <318 0x0>; + + #address-cells = <2>; + #size-cells = <2>; + + chosen { }; + + memory { + device_type = "memory"; + /* We expect the bootloader to fill in the reg */ + reg = <0 0 0 0>; + }; + + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@100 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0
Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver
On 12 August 2018 13:42:27 BST, Christian Lamparter wrote: >On Sunday, August 12, 2018 9:18:19 AM CEST you wrote: >> On 11 August 2018 18:27:43 BST, Christian Lamparter > wrote: >> >On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: >> >> Add initial pinctrl driver to support pin configuration with >> >> pinctrl framework for sdm660. >> >> Based off CAF implementation. >> >> >> >> Signed-off-by: Craig Tatlor >> >> --- >> >> >> >> diff --git >> >a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> >> new file mode 100644 >> >> index ..85e6c6c17c04 >> >> --- /dev/null >> >> +++ >> >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> >> @@ -0,0 +1,195 @@ >> >> +Qualcomm Technologies, Inc. SDM660 TLMM block >> >> + >> >> +This binding describes the Top Level Mode Multiplexer block found >in >> >the >> >> +SDM660 platform. >> >> + >> >> +- compatible: >> >> + Usage: required >> >> + Value type: >> >> + Definition: must be "qcom,sdm660-pinctrl" >> >> + >> >> +- reg: >> >> + Usage: required >> >> + Value type: >> >> + Definition: the base address and size of the TLMM register >space. >> >> + >> >> +- interrupts: >> >> + Usage: required >> >> + Value type: >> >> + Definition: should specify the TLMM summary IRQ. >> >> + >> >> +- interrupt-controller: >> >> + Usage: required >> >> + Value type: >> >> + Definition: identifies this node as an interrupt controller >> >> + >> >> +- #interrupt-cells: >> >> + Usage: required >> >> + Value type: >> >> + Definition: must be 2. Specifying the pin number and flags, as >> >defined >> >> + in >> >> + >> >> +- gpio-controller: >> >> + Usage: required >> >> + Value type: >> >> + Definition: identifies this node as a gpio controller >> >> + >> >> +- #gpio-cells: >> >> + Usage: required >> >> + Value type: >> >> + Definition: must be 2. Specifying the pin number and flags, as >> >defined >> >> + in >> >> + >> >> +Please refer to ../gpio/gpio.txt and >> >../interrupt-controller/interrupts.txt for >> >> +a general description of GPIO and interrupt bindings. >> >You want to specify gpio-ranges here as well. The property is >explained >> >in Section "2.1) gpio- and pin-controller interaction" in >> >../gpio/gpio.txt >> > >> >Without it, the gpio-hogs construct (part of ../gpio/gpio.txt) will >> >cause >> >the driver to fail during boot. (try it, ;-) ) >> Would gpio-ranges make sense for this, as the gpio and pinctrl are in >same block? >Yes, it's part of the ../gpio/gpio.txt which you link. >Here's a copy of the relevant section that explains this >gpio- and pin-controller interaction. > > >|2.1) gpio- and pin-controller interaction >|- >| >|Some or all of the GPIOs provided by a GPIO controller may be routed >to pins >|on the package via a pin controller. This allows muxing those pins >between >|GPIO and other functions. >|It is useful to represent which GPIOs correspond to which pins on >which pin >|controllers. The gpio-ranges property described below represents this, >and >|contains information structures as follows: >| >| gpio-range-list ::= [gpio-range-list] >| single-gpio-range ::= | >| numeric-gpio-range ::= >| > >| named-gpio-range ::= '<0 0>' >| pinctrl-phandle : phandle to pin controller node >| gpio-base : Base GPIO ID in the GPIO controller >| pinctrl-base : Base pinctrl pin ID in the pin controller >| count : The number of GPIOs/pins in this range >| >|The "pin controller node" mentioned above must conform to the bindings >|described in ../pinctrl/pinctrl-bindings.txt. >|... > >As for the reason why gpio-ranges is what it is, please look at the ML >discussion from the "pinctrl: msm: fix gpio-hog related boot issues" >thread >on <https://patchwork.kernel.org/patch/103
Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver
On 11 August 2018 18:27:43 BST, Christian Lamparter wrote: >On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: >> Add initial pinctrl driver to support pin configuration with >> pinctrl framework for sdm660. >> Based off CAF implementation. >> >> Signed-off-by: Craig Tatlor >> --- >> >> diff --git >a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> new file mode 100644 >> index ..85e6c6c17c04 >> --- /dev/null >> +++ >b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt >> @@ -0,0 +1,195 @@ >> +Qualcomm Technologies, Inc. SDM660 TLMM block >> + >> +This binding describes the Top Level Mode Multiplexer block found in >the >> +SDM660 platform. >> + >> +- compatible: >> +Usage: required >> +Value type: >> +Definition: must be "qcom,sdm660-pinctrl" >> + >> +- reg: >> +Usage: required >> +Value type: >> +Definition: the base address and size of the TLMM register space. >> + >> +- interrupts: >> +Usage: required >> +Value type: >> +Definition: should specify the TLMM summary IRQ. >> + >> +- interrupt-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as an interrupt controller >> + >> +- #interrupt-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +- gpio-controller: >> +Usage: required >> +Value type: >> +Definition: identifies this node as a gpio controller >> + >> +- #gpio-cells: >> +Usage: required >> +Value type: >> +Definition: must be 2. Specifying the pin number and flags, as >defined >> +in >> + >> +Please refer to ../gpio/gpio.txt and >../interrupt-controller/interrupts.txt for >> +a general description of GPIO and interrupt bindings. >You want to specify gpio-ranges here as well. The property is explained >in Section "2.1) gpio- and pin-controller interaction" in >../gpio/gpio.txt > >Without it, the gpio-hogs construct (part of ../gpio/gpio.txt) will >cause >the driver to fail during boot. (try it, ;-) ) Would gpio-ranges make sense for this, as the gpio and pinctrl are in same block? Seems no other qcom pinctrl drivers have it and I'm able to boot without it. > >> +Please refer to pinctrl-bindings.txt in this directory for details >of the >> +common pinctrl bindings used by client devices, including the >meaning of the >> +phrase "pin configuration node". >> + >> +The pin configuration nodes act as a container for an arbitrary >number of >> +subnodes. Each of these subnodes represents some desired >configuration for a >> +pin, a group, or a list of pins or groups. This configuration can >include the >> +mux function to select on those pin(s)/group(s), and various pin >configuration >> +parameters, such as pull-up, drive strength, etc. >> + >> + >> +PIN CONFIGURATION NODES: >> + >> +The name of each subnode is not important; all subnodes should be >enumerated >> +and processed purely based on their content. >> + >> +Each subnode only affects those parameters that are explicitly >listed. In >> +other words, a subnode that lists a mux function but no pin >configuration >> +parameters implies no information about any pin configuration >parameters. >> +Similarly, a pin subnode that describes a pullup parameter implies >no >> +information about e.g. the mux function. >> + >> + >> +The following generic properties as defined in pinctrl-bindings.txt >are valid >> +to specify in a pin configuration subnode: >> + >> +- pins: >> +Usage: required >> +Value type: >> +Definition: List of gpio pins affected by the properties specified >in >> +this subnode. Valid pins are: >> +gpio0-gpio149, >> +Supports mux, bias and drive-strength >> +sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data >sdc1_rclk, >> +Supports bias and drive-strength >> + >> +- function: >> +Usage: required >> +Value type: >> +Definition: Specify the alternative function to be configured for >the >> +specified pins. Functions
[PATCH] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
Initial device tree support for Qualcomm SDM630 SoC and Sony Pioneer (Xperia XA2). SDM630 is based off of the SDM660 soc and all SDM660 specific drivers are compatible with it. SDM660 is also based off of MSM8998 so it uses some of its drivers aswell. The device tree is based on the CAF 4.4 kernel tree. The device can be booted into the initrd with a shell over UART. Signed-off-by: Craig Tatlor --- arch/arm64/boot/dts/qcom/Makefile| 1 + arch/arm64/boot/dts/qcom/sdm630-pins.dtsi| 17 + arch/arm64/boot/dts/qcom/sdm630-pioneer.dts | 16 + arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi | 22 ++ arch/arm64/boot/dts/qcom/sdm630.dtsi | 383 +++ 5 files changed, 439 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pins.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pioneer.dts create mode 100644 arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sdm630.dtsi diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile index 9319e74b8906..80f98bb19998 100644 --- a/arch/arm64/boot/dts/qcom/Makefile +++ b/arch/arm64/boot/dts/qcom/Makefile @@ -6,4 +6,5 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb +dtb-$(CONFIG_ARCH_QCOM)+= sdm630-pioneer.dtb dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb diff --git a/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi new file mode 100644 index ..78b79c1076f1 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pins.dtsi @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +&tlmm { + blsp1_uart1_default: blsp1_uart1_default { + pinmux { + pins = "gpio0", "gpio1", "gpio2", "gpio3"; + function = "gpio"; + }; + + pinconf { + pins = "gpio0", "gpio1", "gpio2", "gpio3"; + drive-strength = <2>; + bias-disable; + }; + }; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts new file mode 100644 index ..67c7e3b57739 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dts @@ -0,0 +1,16 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +/dts-v1/; + +#include "sdm630-pioneer.dtsi" + +/ { + model = "Sony Xperia XA2"; + compatible = "sony,pioneer", "qcom,sdm630"; + + /* required for bootloader to select correct board */ + qcom,board-id = <8 0>; + qcom,pmic-id = <0x0001001b 0x0101011a 0x0 0x0>, + <0x0001001b 0x0201011a 0x0 0x0>; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi new file mode 100644 index ..512792c23369 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi @@ -0,0 +1,22 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +#include "sdm630.dtsi" + +/ { + aliases { + serial0 = &blsp1_uart1; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +}; + +&soc { + serial@c17 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&blsp1_uart1_default>; + }; +}; diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi new file mode 100644 index ..8a544979b7c0 --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi @@ -0,0 +1,383 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2018, Craig Tatlor. */ + +#include +#include + +/ { + model = "Qualcomm Technologies, Inc. SDM630"; + + interrupt-parent = <&intc>; + + qcom,msm-id = <318 0x0>; + + #address-cells = <2>; + #size-cells = <2>; + + chosen { }; + + memory { + device_type = "memory"; + /* We expect the bootloader to fill in the reg */ + reg = <0 0 0 0>; + }; + + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@100 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x100>; + enable-method = "psci"; +
[PATCH] pinctrl: qcom: Add sdm660 pinctrl driver
Add initial pinctrl driver to support pin configuration with pinctrl framework for sdm660. Based off CAF implementation. Signed-off-by: Craig Tatlor --- .../bindings/pinctrl/qcom,sdm660-pinctrl.txt | 195 +++ drivers/pinctrl/qcom/Kconfig | 10 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-sdm660.c | 1451 + 4 files changed, 1657 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm660.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt new file mode 100644 index ..85e6c6c17c04 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt @@ -0,0 +1,195 @@ +Qualcomm Technologies, Inc. SDM660 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM660 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sdm660-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio149, + Supports mux, bias and drive-strength + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, sdc2_data sdc1_rclk, + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, + atest_usb21, atest_char1, dbg_out, q
[PATCH] firmware: qcom: scm: Add sdm660 soc compatible
Add the compatible for SDM660. This does not need clocks to do scm calls Signed-off-by: Craig Tatlor --- Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 + drivers/firmware/qcom_scm.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index fcf6979c0b6d..499608fcc864 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -11,6 +11,7 @@ Required properties: * "qcom,scm-msm8660" for MSM8660 platforms * "qcom,scm-msm8690" for MSM8690 platforms * "qcom,scm-msm8996" for MSM8996 platforms + * "qcom,scm-sdm660" for SDM660 platforms * "qcom,scm-ipq4019" for IPQ4019 platforms * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc) - clocks: One to three clocks may be required based on compatible. diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index e778af766fae..ee113ceb5d41 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -603,6 +603,9 @@ static const struct of_device_id qcom_scm_dt_match[] = { { .compatible = "qcom,scm-msm8996", .data = NULL, /* no clocks */ }, + { .compatible = "qcom,scm-sdm660", + .data = NULL, /* no clocks */ + }, { .compatible = "qcom,scm-ipq4019", .data = NULL, /* no clocks */ }, -- 2.18.0
[PATCH] soc: qcom: smd-rpm: Add sdm660 compatible
Add the compatible for the RPM in SDM660, so that rpm resources can be made available. Signed-off-by: Craig Tatlor --- Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 + drivers/soc/qcom/smd-rpm.c | 1 + 2 files changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt index 89e1cb9212f6..c38d2b91aadb 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt @@ -23,6 +23,7 @@ resources. "qcom,rpm-msm8916" "qcom,rpm-msm8974" "qcom,rpm-msm8998" + "qcom,rpm-sdm660" - qcom,smd-channels: Usage: required diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c index 93517ed83355..05d4dec15572 100644 --- a/drivers/soc/qcom/smd-rpm.c +++ b/drivers/soc/qcom/smd-rpm.c @@ -227,6 +227,7 @@ static const struct of_device_id qcom_smd_rpm_of_match[] = { { .compatible = "qcom,rpm-msm8974" }, { .compatible = "qcom,rpm-msm8996" }, { .compatible = "qcom,rpm-msm8998" }, + { .compatible = "qcom,rpm-sdm660" }, {} }; MODULE_DEVICE_TABLE(of, qcom_smd_rpm_of_match); -- 2.18.0
[PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM660
Add support for the global clock controller found on SDM660 based devices. This should allow most non-multimedia device drivers to probe and control their clocks. Based on CAF implementation. Signed-off-by: Craig Tatlor --- .../devicetree/bindings/clock/qcom,gcc.txt|1 + drivers/clk/qcom/Kconfig |9 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/gcc-sdm660.c | 2479 + include/dt-bindings/clock/qcom,gcc-sdm660.h | 159 ++ 5 files changed, 2649 insertions(+) create mode 100644 drivers/clk/qcom/gcc-sdm660.c create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 664ea1fd6c76..e498ad2e8db8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -19,6 +19,7 @@ Required properties : "qcom,gcc-msm8996" "qcom,gcc-msm8998" "qcom,gcc-mdm9615" + "qcom,gcc-sdm660" "qcom,gcc-sdm845" - reg : shall contain base register location and length diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index 9c3480dcc38a..c4bda6d24c1f 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -226,6 +226,15 @@ config MSM_GCC_8998 Say Y if you want to use peripheral devices such as UART, SPI, i2c, USB, UFS, SD/eMMC, PCIe, etc. +config SDM_GCC_660 + tristate "SDM660 Global Clock Controller" + select QCOM_GDSC + depends on COMMON_CLK_QCOM + help + Support for the global clock controller on SDM660 devices. + Say Y if you want to use peripheral devices such as UART, SPI, + i2C, USB, UFS, SDDC, PCIe, etc. + config SDM_GCC_845 tristate "SDM845 Global Clock Controller" select QCOM_GDSC diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile index 762c01137c2f..6e37d30d7c02 100644 --- a/drivers/clk/qcom/Makefile +++ b/drivers/clk/qcom/Makefile @@ -38,6 +38,7 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o +obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c new file mode 100644 index ..bdb445aa4baa --- /dev/null +++ b/drivers/clk/qcom/gcc-sdm660.c @@ -0,0 +1,2479 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved. + * Copyright (c) 2018, Craig Tatlor. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "common.h" +#include "clk-regmap.h" +#include "clk-alpha-pll.h" +#include "clk-rcg.h" +#include "clk-branch.h" +#include "reset.h" +#include "gdsc.h" + +#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) } + +enum { + P_XO, + P_SLEEP_CLK, + P_GPLL0, + P_GPLL1, + P_GPLL4, + P_GPLL0_EARLY_DIV, + P_GPLL1_EARLY_DIV, +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[] = { + "xo", + "gpll0", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, +}; + +static const char * const gcc_parent_names_xo_gpll0[] = { + "xo", + "gpll0", +}; + +static const struct parent_map gcc_parent_map_xo_gpll0_sleep_clk_gpll0_early_div[] = { + { P_XO, 0 }, + { P_GPLL0, 1 }, + { P_SLEEP_CLK, 5 }, + { P_GPLL0_EARLY_DIV, 6 }, +}; + +static const char * const gcc_parent_names_xo_gpll0_sleep_clk_gpll0_early_div[] = { + "xo", + "gpll0", + "sleep_clk", + "gpll0_early_div", +}; + +static const struct parent_map gcc_parent_map_xo_sleep_clk[] = { + { P_XO, 0 }, + { P_SLEEP_CLK, 5 }, +}; + +static const char * const gcc_parent_names_xo_sleep_clk[] = { + "xo", + "sleep_clk", +}; + +static const struct parent_map gcc_parent_map_xo_gpll4[] = { + { P_XO, 0 }, + { P_GPLL4, 5 }, +}; + +static const char * const gcc_parent_names_xo_gpll4[] = { + "xo&
Re: [PATCH v10 13/14] cpufreq: Add module to register cpufreq on Krait CPUs
The pvs refuse check is incorrect... With downstream it says it isn't blown and that it is 11, which also happens on upstream if I import it's efuse reading code from an older revision, or comment out the check. Also, I'm still getting my issue about clocks above 2,147,483,647hz however I think this may be related to the division in the hfpll driver so I'll have a debug around there. On Tue, Jun 19, 2018 at 07:15:24PM +0530, Sricharan R wrote: > From: Stephen Boyd > > Register a cpufreq-generic device whenever we detect that a > "qcom,krait" compatible CPU is present in DT. > > Acked-by: Viresh Kumar > [Sricharan: updated to use dev_pm_opp_set_prop_name and > nvmem apis] > Signed-off-by: Sricharan R > [Thierry Escande: update to add support for opp-supported-hw] > Signed-off-by: Thierry Escande > Signed-off-by: Stephen Boyd > Acked-by: Viresh Kumar > --- > [v10] updated to add support for opp-supported-hw given by >Thierry Escande > > drivers/cpufreq/Kconfig.arm | 10 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 5 + > drivers/cpufreq/qcom-cpufreq.c | 201 > +++ > 4 files changed, 217 insertions(+) > create mode 100644 drivers/cpufreq/qcom-cpufreq.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index 7f56fe5..87e5d8d 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -134,6 +134,16 @@ config ARM_OMAP2PLUS_CPUFREQ > depends on ARCH_OMAP2PLUS > default ARCH_OMAP2PLUS > > +config ARM_QCOM_CPUFREQ > + bool "CPUfreq driver for the QCOM SoCs with KRAIT processors" > + depends on ARCH_QCOM > + select PM_OPP > + help > + This enables the CPUFreq driver for Qualcomm SoCs with > + KRAIT processors. > + > + If in doubt, say N. > + > config ARM_S3C_CPUFREQ > bool > help > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 8d24ade..c591e1e 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o > obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o > obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o > obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o > +obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o > obj-$(CONFIG_ARM_S3C2410_CPUFREQ)+= s3c2410-cpufreq.o > obj-$(CONFIG_ARM_S3C2412_CPUFREQ)+= s3c2412-cpufreq.o > obj-$(CONFIG_ARM_S3C2416_CPUFREQ)+= s3c2416-cpufreq.o > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c > b/drivers/cpufreq/cpufreq-dt-platdev.c > index 3b585e4..e2e9a99 100644 > --- a/drivers/cpufreq/cpufreq-dt-platdev.c > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c > @@ -127,6 +127,11 @@ > { .compatible = "ti,am43", }, > { .compatible = "ti,dra7", }, > > + { .compatible = "qcom,ipq8064", }, > + { .compatible = "qcom,apq8064", }, > + { .compatible = "qcom,msm8974", }, > + { .compatible = "qcom,msm8960", }, > + > { } > }; > > diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c > new file mode 100644 > index 000..1d4ab54 > --- /dev/null > +++ b/drivers/cpufreq/qcom-cpufreq.c > @@ -0,0 +1,201 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (c) 2018, The Linux Foundation. All rights reserved. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver, > + struct nvmem_cell *pvs_nvmem, u8 *buf) > +{ > + u32 pte_efuse; > + > + pte_efuse = *((u32 *)buf); > + > + *speed = pte_efuse & 0xf; > + if (*speed == 0xf) > + *speed = (pte_efuse >> 4) & 0xf; > + > + if (*speed == 0xf) { > + *speed = 0; > + pr_warn("Speed bin: Defaulting to %d\n", *speed); > + } else { > + pr_info("Speed bin: %d\n", *speed); > + } > + > + *pvs = (pte_efuse >> 10) & 0x7; > + if (*pvs == 0x7) > + *pvs = (pte_efuse >> 13) & 0x7; > + > + if (*pvs == 0x7) { > + *pvs = 0; > + pr_warn("PVS bin: Defaulting to %d\n", *pvs); > + } else { > + pr_info("PVS bin: %d\n", *pvs); > + } > + > + kfree(buf); > +} > + > +static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver, > + struct nvmem_cell *pvs_nvmem, u8 *buf) > +{ > + u32 pte_efuse, redundant_sel; > + > + pte_efuse = *((u32 *)buf); > + redundant_sel = (pte_efuse >> 24) & 0x7; > + *speed = pte_efuse & 0x7; > + > + /* 4 bits of PVS are in efuse register bits 31, 8-6. */ > + *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7); > + *pvs_ver = (pte_efuse >> 4) & 0x3; > + > + switch (redundant_sel) { > + case 1: > +
[PATCH v7 4/4] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9c125f705f78..be485caf9313 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11646,6 +11646,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MONITORING SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH v7 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm Battery Monitoring system. Signed-off-by: Craig Tatlor Reviewed-by: Rob Herring --- * Changes from v6: s/celcius/celsius change uah to uAh. * Changes from v5: Mentions which values are 8 bit. * Changes from v4: Uses proper units and expands some definitions, along with changing vadc@ to adc@. .../bindings/power/supply/qcom_bms.txt| 92 +++ 1 file changed, 92 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..dc0a9ab9aa64 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,92 @@ +Qualcomm Battery Monitoring System + +The Qualcomm Battery Monitoring System is found inside of Qualcomm PM8941 +PMICs. It provides open circuit voltage (OCV) and coulomb counter registers +that allow the OS to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend-celsius: An 8 bit array containing the temperature, + in degC, for each column of the full charge + capacity lookup table. +- qcom,fcc-lut-microamp-hours: An array of full charge capacity values in uAh, + one entry for each temperature defined in in + qcom,fcc-temp-legend-celsius. +- qcom,ocv-temp-legend-celsius: An 8 bit array containing the temperature, + in degC, for each column of the OCV lookup + table. +- qcom,ocv-capacity-legend: An 8 bit array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut-microvolt: An array of OCV values in uV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + pm8941_vadc: adc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut-microamp-hours = <323 326 338 341 336>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 +70 65 60 55 50 45 +40 35 30 25 20 15 +10 9 8 7 6 5 4 3 2 +1 0&g
[PATCH v7 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then amends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor Reviewed-by: Linus Walleij --- * Changes from v5: Uses select for REGMAP_SPMI. * Changes from v4: Cleaned up percentage interpolation function, uses new fixp interpolation helper, added some more error cases, uses devm_power_supply_register(), uses a DIV_ROUND_CLOSEST for division and uses micro(volts / amp hours) instead of milli (volts / amp hours). drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 487 3 files changed, 497 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..75f2f375f992 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + select REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..718fd745c0f7 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,487 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define BMS_CC_READING_RES
[PATCH v7 1/4] fixp-arith: add a linear interpolation function
Adds a function to interpolate against two points, this is carried arount as a helper function by tons of drivers. Signed-off-by: Craig Tatlor Reviewed-by: Linus Walleij --- include/linux/fixp-arith.h | 20 1 file changed, 20 insertions(+) diff --git a/include/linux/fixp-arith.h b/include/linux/fixp-arith.h index d4686fe1cac7..b9e2bb59a734 100644 --- a/include/linux/fixp-arith.h +++ b/include/linux/fixp-arith.h @@ -153,4 +153,24 @@ static inline s32 fixp_sin32_rad(u32 radians, u32 twopi) #define fixp_cos32_rad(rad, twopi) \ fixp_sin32_rad(rad + twopi / 4, twopi) + +/** + * fixp_linear_interpolate() - interpolates a value from two known points + * + * @x0: x value of point 0 + * @y0: y value of point 0 + * @x1: x value of point 1 + * @y1: y value of point 1 + * @x: the linear interpolant + */ +static inline int fixp_linear_interpolate(int x0, int y0, int x1, int y1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + #endif -- 2.17.0
[PATCH v6 4/4] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9c125f705f78..be485caf9313 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11646,6 +11646,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MONITORING SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH v6 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm Battery Monitoring system. Signed-off-by: Craig Tatlor --- * Changes from v5: Mentions which values are 8 bit. * Changes from v4: Uses proper units and expands some definitions, along with changing vadc@ to adc@. .../bindings/power/supply/qcom_bms.txt| 92 +++ 1 file changed, 92 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..9a29a2eb9f04 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,92 @@ +Qualcomm Battery Monitoring System + +The Qualcomm Battery Monitoring System is found inside of Qualcomm PM8941 +PMICs. It provides open circuit voltage (OCV) and coulomb counter registers +that allow the OS to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend-celcius: An 8 bit array containing the temperature, + in degC, for each column of the full charge + capacity lookup table. +- qcom,fcc-lut-microamp-hours: An array of full charge capacity values in uah, + one entry for each temperature defined in in + qcom,fcc-temp-legend-celcius. +- qcom,ocv-temp-legend-celcius: An 8 bit array containing the temperature, + in degC, for each column of the OCV lookup + table. +- qcom,ocv-capacity-legend: An 8 bit array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut-microvolt: An array of OCV values in uV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + pm8941_vadc: adc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut-microamp-hours = <323 326 338 341 336>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 +70 65 60 55 50 45 +40 35 30 25 20 15 +10 9 8 7 6 5 4 3 2 +1 0>; + qcom,ocv-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; + qcom,ocv-lut-microvolt = <4305 4305 4303 4299 4295 + 4277 4257 4255 4251 4231 + 4218 4198 4197 4192 4172 + 4159 4139 4145 4140 4120 + 4101 4081 4092 4089 4069 + 4048 4028 4044 4042 4022 + 4004 3984 4001 3998 3978 + 3962 3942 3955 3956 3936 + 3921 3901 3909 3916 3896 +
[PATCH v6 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then amends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- * Changes from v5: Uses select for REGMAP_SPMI. * Changes from v4: Cleaned up percentage interpolation function, uses new fixp interpolation helper, added some more error cases, uses devm_power_supply_register(), uses a DIV_ROUND_CLOSEST for division and uses micro(volts / amp hours) instead of milli (volts / amp hours). drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 487 3 files changed, 497 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..75f2f375f992 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + select REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..e1d6fdbf11d1 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,487 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u32 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u32 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct bms_ocv_lut ocv_lut; + struct power_supply_desc bat_desc; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + struct mutex bms_output_lock; + u32 base_addr; + + int ocv_thr_irq; + u32 ocv; +}; + +static bool between(int left, int right, int val) +{ + if (left <= val && val <= right) + return true; + + if (left >= val && val >= right) + return true; + + return false; +} + +static int interpolate_capacity(int temp, u32 ocv, + struct bms_ocv_lut *ocv_lut) +{ + int pcj_minus_one = 0, pcj = 0, i2 = 0, i3 = 0, i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut->temp_legend[j]) + break; + + if (ocv >= ocv_lut->lut[0][j]) + return ocv_lut->capacity_legend[0]; + + if (ocv <= ocv_lut->lut[ocv_lut->rows-1][j-1]) + return ocv_lut->capacity_legend[ocv_lut->rows-1];
[PATCH v6 1/4] fixp-arith: add a linear interpolation function
Adds a function to interpolate against two points, this is carried arount as a helper function by tons of drivers. Signed-off-by: Craig Tatlor --- include/linux/fixp-arith.h | 20 1 file changed, 20 insertions(+) diff --git a/include/linux/fixp-arith.h b/include/linux/fixp-arith.h index d4686fe1cac7..c21de4f358dd 100644 --- a/include/linux/fixp-arith.h +++ b/include/linux/fixp-arith.h @@ -153,4 +153,24 @@ static inline s32 fixp_sin32_rad(u32 radians, u32 twopi) #define fixp_cos32_rad(rad, twopi) \ fixp_sin32_rad(rad + twopi / 4, twopi) + +/** + * fixp_linear_interpolate() - interpolates a value from two known points + * + * @x0: x value of point 0 + * @y0: y value of point 0 + * @x1: x value of point 1 + * @y1: y value of point 1 + * @x: the linear interpolant + */ +static inline int fixp_linear_interpolate(int x0, int y0, int x1, int y1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + #endif -- 2.17.0
Re: [PATCH v5 1/4] fixp-arith: add a linear interpolation function
On Wed, Jun 13, 2018 at 01:12:45PM +0200, Linus Walleij wrote: > On Wed, Jun 13, 2018 at 1:06 PM, Linus Walleij > wrote: > > On Thu, Jun 7, 2018 at 8:12 PM, Craig Tatlor wrote: > > > >> Adds a function to interpolate against two points, > >> this is carried arount as a helper function by tons of drivers. > >> > >> Signed-off-by: Craig Tatlor > > > > The linear formula seems to fit the most natural form of linear > > interpolation. > > > > I bet some John Carmack algorithm type people will soon > > start to optimize this... :D > > For your entertainment here is some sunday reading: > https://fgiesen.wordpress.com/2012/08/15/linear-interpolation-past-present-and-future/ > > Yours, > Linus Walleij Thanks, interesting read.
Re: [PATCH v5 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
On Mon, Jun 11, 2018 at 12:15:15PM -0600, Rob Herring wrote: > On Thu, Jun 07, 2018 at 07:12:51PM +0100, Craig Tatlor wrote: > > Add bindings for the Qualcomm Battery Monitoring system. > > > > Signed-off-by: Craig Tatlor > > --- > > * Changes from v4: > > Uses proper units and expands some definitions, > > along with changing vadc@ to adc@. > > > > .../bindings/power/supply/qcom_bms.txt| 91 +++ > > 1 file changed, 91 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > > > diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > new file mode 100644 > > index ..a1a32d6ab460 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > @@ -0,0 +1,91 @@ > > +Qualcomm Battery Monitoring System > > + > > +The Qualcomm Battery Monitoring System is found inside of Qualcomm PM8941 > > +PMICs. It provides open circuit voltage (OCV) and coulomb counter registers > > +that allow the OS to infer a capacity level. > > + > > +Required properties: > > +- compatible: Should contain "qcom,pm8941-bms". > > +- reg: Specifies the SPMI address and length of > > the > > + controller's registers. > > +- interrupts: OCV threshold interrupt. > > +- io-channels: Should contain IIO channel specifier for > > the > > + ADC channel that reports battery temperature. > > +- io-channel-names: Should contain "temp". > > +- qcom,fcc-temp-legend-celcius: An array containing the temperature, in > > degC, > > + for each column of the full charge capacity > > + lookup table. > > +- qcom,fcc-lut-microamp-hours: An array of full charge capacity values in > > uah, > > + one entry for each temperature defined in in > > + qcom,fcc-temp-legend-celcius. > > +- qcom,ocv-temp-legend-celcius: An array containing the temperature, in > > degC, > > + for each column of the OCV lookup table. > > +- qcom,ocv-capacity-legend: An array containing the capacity for each > > + row of the OCV lookup table. > > +- qcom,ocv-lut-microvolt: An array of OCV values in uV, one entry > > for each > > + capacity defined in qcom,ocv-capacity-legend. > > Need to say which of these are 8-bit values. > > With that, > > Reviewed-by: Rob Herring Thanks for the review, will mark as 8 bit in v6
Re: [PATCH v5 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
On Thu, Jun 07, 2018 at 12:08:20PM -0700, Randy Dunlap wrote: > On 06/07/2018 11:12 AM, Craig Tatlor wrote: > > This patch adds a driver for the BMS (Battery Monitoring System) > > block of the PM8941 PMIC, it uses a lookup table defined in the > > device tree to generate a capacity from the BMS supplied OCV, it > > then ammends the coulomb counter to that to increase the accuracy > >amends > > > of the estimated capacity. > > > > Signed-off-by: Craig Tatlor > > --- > > > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig > > index 428b426842f4..6c354c37bc55 100644 > > --- a/drivers/power/supply/Kconfig > > +++ b/drivers/power/supply/Kconfig > > @@ -82,6 +82,15 @@ config BATTERY_ACT8945A > > Say Y here to enable support for power supply provided by > > Active-semi ActivePath ACT8945A charger. > > > > +config BATTERY_BMS > > + tristate "Qualcomm Battery Monitoring System driver" > > + depends on MFD_SPMI_PMIC || COMPILE_TEST > > + depends on OF > > + depends on REGMAP_SPMI > > select REGMAP_SPMI > > I'm not a fan of "select", but it does not have a prompt string so it isn't > user settable (not directly; it can be set indirectly). > And all other uses of it in Kconfig files use "select". > > > + help > > + Say Y to include support for the Battery Monitoring hardware > > + found in some Qualcomm PM series PMICs. > > + > > config BATTERY_CPCAP > > tristate "Motorola CPCAP PMIC battery driver" > > depends on MFD_CPCAP && IIO > Thanks for the review. > > -- > ~Randy
[PATCH v5 4/4] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9c125f705f78..be485caf9313 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11646,6 +11646,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MONITORING SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH v5 3/4] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm Battery Monitoring system. Signed-off-by: Craig Tatlor --- * Changes from v4: Uses proper units and expands some definitions, along with changing vadc@ to adc@. .../bindings/power/supply/qcom_bms.txt| 91 +++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..a1a32d6ab460 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,91 @@ +Qualcomm Battery Monitoring System + +The Qualcomm Battery Monitoring System is found inside of Qualcomm PM8941 +PMICs. It provides open circuit voltage (OCV) and coulomb counter registers +that allow the OS to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend-celcius: An array containing the temperature, in degC, + for each column of the full charge capacity + lookup table. +- qcom,fcc-lut-microamp-hours: An array of full charge capacity values in uah, + one entry for each temperature defined in in + qcom,fcc-temp-legend-celcius. +- qcom,ocv-temp-legend-celcius: An array containing the temperature, in degC, + for each column of the OCV lookup table. +- qcom,ocv-capacity-legend: An array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut-microvolt: An array of OCV values in uV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + pm8941_vadc: adc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut-microamp-hours = <323 326 338 341 336>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 80 75 +70 65 60 55 50 45 +40 35 30 25 20 15 +10 9 8 7 6 5 4 3 2 +1 0>; + qcom,ocv-temp-legend-celsius = /bits/ 8 <(-10) 0 25 50 65>; + qcom,ocv-lut-microvolt = <4305 4305 4303 4299 4295 + 4277 4257 4255 4251 4231 + 4218 4198 4197 4192 4172 + 4159 4139 4145 4140 4120 + 4101 4081 4092 4089 4069 + 4048 4028 4044 4042 4022 + 4004 3984 4001 3998 3978 + 3962 3942 3955 3956 3936 + 3921 3901 3909 3916 3896 + 3883 3863 3874 3879 3859 +
[PATCH v5 2/4] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then ammends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- * Changes from v4: Cleaned up percentage interpolation function, uses new fixp interpolation helper, added some more error cases, uses devm_power_supply_register(), uses a DIV_ROUND_CLOSEST for division and uses micro(volts / amp hours) instead of milli (volts / amp hours). drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 487 3 files changed, 497 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..6c354c37bc55 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + depends on REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..e1d6fdbf11d1 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,487 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u32 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u32 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct bms_ocv_lut ocv_lut; + struct power_supply_desc bat_desc; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + struct mutex bms_output_lock; + u32 base_addr; + + int ocv_thr_irq; + u32 ocv; +}; + +static bool between(int left, int right, int val) +{ + if (left <= val && val <= right) + return true; + + if (left >= val && val >= right) + return true; + + return false; +} + +static int interpolate_capacity(int temp, u32 ocv, + struct bms_ocv_lut *ocv_lut) +{ + int pcj_minus_one = 0, pcj = 0, i2 = 0, i3 = 0, i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut->temp_legend[j]) + break; + + if (ocv >= ocv_lut->lut[0][j]) + return ocv_lut->capacity_legend[0]; + + if (ocv <= ocv_lut->lut[ocv_lut->rows-1][j-1]) + return ocv_lut->capacity_legend[ocv_lut->rows-1]; + + for (i = 0; i < ocv_lut->rows-1; i++) {
[PATCH v5 1/4] fixp-arith: add a linear interpolation function
Adds a function to interpolate against two points, this is carried arount as a helper function by tons of drivers. Signed-off-by: Craig Tatlor --- include/linux/fixp-arith.h | 20 1 file changed, 20 insertions(+) diff --git a/include/linux/fixp-arith.h b/include/linux/fixp-arith.h index d4686fe1cac7..c21de4f358dd 100644 --- a/include/linux/fixp-arith.h +++ b/include/linux/fixp-arith.h @@ -153,4 +153,24 @@ static inline s32 fixp_sin32_rad(u32 radians, u32 twopi) #define fixp_cos32_rad(rad, twopi) \ fixp_sin32_rad(rad + twopi / 4, twopi) + +/** + * fixp_linear_interpolate() - interpolates a value from two known points + * + * @x0: x value of point 0 + * @y0: y value of point 0 + * @x1: x value of point 1 + * @y1: y value of point 1 + * @x: the linear interpolant + */ +static inline int fixp_linear_interpolate(int x0, int y0, int x1, int y1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + #endif -- 2.17.0
Re: [PATCH v2 0/2] slimbus: Add QCOM SLIMBus NGD driver
Tested on msm8974 with wcd9320 codec. Tested-by: Craig Tatlor On Fri, May 25, 2018 at 12:15:45PM +0100, Srinivas Kandagatla wrote: > This patchset adds support to basic version of Qualcomm NGD SLIMBus > controller driver found SoCs from B family. > > This controller is light-weight SLIMBus controller driver responsible for > communicating with slave HW directly over the bus using messaging > interface, and communicating with master component residing on ADSP > for bandwidth and data-channel management. > > Tested this patchset on DB820c with WCD9335 codec. > I have pushed my working branch to [1] incase someone want to try. > > This patch has dependency on https://lkml.org/lkml/2018/5/17/251 > > Changes sinc v1 (https://lwn.net/Articles/754679): > - Fixed DT binding making NGD slave of the slim controller. > - Fixed few typos spotted by Vinod. > - Removed unnessary dmaengine_slave_config suggested by Vinod > - Removed few unnessary initializations. > - fixed commit log to remove reference to B family suggested by Trilok > > Thanks, > srini > > [1] > https://git.linaro.org/people/srinivas.kandagatla/linux.git/log/?h=slimbus-ngd > > Srinivas Kandagatla (2): > slimbus: ngd: dt-bindings: Add slim ngd dt bindings > slimbus: ngd: Add qcom SLIMBus NGD driver > > .../bindings/slimbus/slim-ngd-qcom-ctrl.txt| 84 ++ > drivers/slimbus/Kconfig| 11 + > drivers/slimbus/Makefile |3 + > drivers/slimbus/qcom-ngd-ctrl.c| 1342 > > drivers/slimbus/slimbus.h |8 + > 5 files changed, 1448 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt > create mode 100644 drivers/slimbus/qcom-ngd-ctrl.c > > -- > 2.16.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
Thanks for review, replies inline. On Thu, Apr 26, 2018 at 01:34:00PM +0200, Linus Walleij wrote: > On Sat, Apr 7, 2018 at 7:57 PM, Craig Tatlor wrote: > > Hi Craig! Thanks for your patch! > > > This patch adds a driver for the BMS (Battery Monitoring System) > > block of the PM8941 PMIC, it uses a lookup table defined in the > > device tree to generate a capacity from the BMS supplied OCV, it > > then ammends the coulomb counter to that to increase the accuracy > > of the estimated capacity. > > > > Signed-off-by: Craig Tatlor > > Just some minor remarks. > > NB: I see that you are writing from a private email address > so if you're working as a hobbyist on your precious sparetime > I have lower expectation on how much work you will put into > this, so see it more as suggestions than demands. Yeah, I am a just hobbyist :) > > My overall feedback is that for algorithmic charger what > we need is infrastructure. What is currently piling up in > drivers/power/supply scares me a bit in it's lack of > framework and code reuse. > > It also scares me because this is vital technology dealing > with physical devices and as such really need to have > modularized reusable reviewed code with several users > and deployments. > > Code reuse would include: > > - Mathematical helpers such as interpolation of > values from absolute values or tables > Suggestions below! > - State machines and transitions > - CC/CV alorithms (using the above) > - Many other things > > Not that *I* can make the situation much better, I'm just > sharing my fears, > > > +static s64 sign_extend_s36(uint64_t raw) > > +{ > > + raw = raw & CC_36_BIT_MASK; > > + > > + return (raw >> 35) == 0LL ? > > + raw : (SIGN_EXTEND_36_TO_64_MASK | raw); > > +} > > #include > > Use sign_extend32() Right. > > > +static unsigned int interpolate(int y0, int x0, int y1, int x1, int x) > > +{ > > + if (y0 == y1 || x == x0) > > + return y0; > > + if (x1 == x0 || x == x1) > > + return y1; > > + > > + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); > > +} > > + > > +static unsigned int between(int left, int right, int val) > > +{ > > + if (left <= val && val <= right) > > + return 1; > > + > > + return 0; > > +} > > How are these things not library functions? > > Every cell of my brain says this code should be reusable. > > Can you put this in ? > > I bet a million to one that the video people will sooner or later > need linear interpolation and there are more users in the kernel > than drivers/power/, certainly drivers/iio as well. > > If noone else says anything I vote to put at least the linear > interpolation into with a bonus if you > move some of the current users in drivers/power over > while you're at it. I was pretty surprised there wasn't a library function for it aswell, i will add it there. > > > +static unsigned int interpolate_capacity(int temp, u16 ocv, > > + struct bms_ocv_lut ocv_lut) > > +{ > > + unsigned int pcj_minus_one = 0, pcj = 0; > > + int i, j; > > + > > + for (j = 0; j < TEMPERATURE_COLS; j++) > > + if (temp <= ocv_lut.temp_legend[j]) > > + break; > > + > > + if (ocv >= ocv_lut.lut[0][j]) > > + return ocv_lut.capacity_legend[0]; > > + > > + if (ocv <= ocv_lut.lut[ocv_lut.rows - 1][j - 1]) > > + return ocv_lut.capacity_legend[ocv_lut.rows - 1]; > > + > > + for (i = 0; i < ocv_lut.rows - 1; i++) { > > + if (pcj == 0 && between(ocv_lut.lut[i][j], > > + ocv_lut.lut[i+1][j], ocv)) > > + pcj = interpolate(ocv_lut.capacity_legend[i], > > + ocv_lut.lut[i][j], > > + ocv_lut.capacity_legend[i + 1], > > + ocv_lut.lut[i+1][j], > > + ocv); > > + > > + if (pcj_minus_one == 0 && between(ocv_lut.lut[i][j-1], > > + ocv_lut.lut[i+1][j-1], > > ocv)) > > + pcj_minus_one = > > interpolate(ocv_lut.capacity_legend[i], > > +
Re: [PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
On Fri, Apr 13, 2018 at 11:35:27AM -0500, Rob Herring wrote: > On Sat, Apr 07, 2018 at 06:57:45PM +0100, Craig Tatlor wrote: > > Add bindings for the Qualcomm Battery Monitoring system. > > > > Signed-off-by: Craig Tatlor > > --- > > .../bindings/power/supply/qcom_bms.txt| 93 +++ > > 1 file changed, 93 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > > > diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > new file mode 100644 > > index ..6296399edc09 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt > > @@ -0,0 +1,93 @@ > > +Qualcomm Battery Measurement System > > + > > +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941 > > Is it Monitoring or Measurment? > > > +PMICs. It provides OCV and coulomb counter registers that allow the kernel > > +to infer a capacity level. > > s/kernel/OS/ > > OCV? > > > + > > +Required properties: > > +- compatible: Should contain "qcom,pm8941-bms". > > +- reg: Specifies the SPMI address and length of the > > + controller's registers. > > +- interrupts: OCV threshold interrupt. > > +- io-channels: Should contain IIO channel specifier for the > > + ADC channel that reports battery temperature. > > +- io-channel-names: Should contain "temp". > > +- qcom,fcc-temp-legend: An array containing the temperature, in degC, > > + for each column of the FCC lookup table. > > What's FCC? > > > +- qcom,fcc-lut: An array of FCC values in mah, one entry for > > each > > + temperature defined in in qcom,fcc-temp-legend. > > +- qcom,ocv-temp-legend: An array containing the temperature, in degC, > > + for each column of the OCV lookup table. > > +- qcom,ocv-capacity-legend: An array containing the capacity for each > > + row of the OCV lookup table. > > +- qcom,ocv-lut: An array of OCV values in mV, one entry for > > each > > + capacity defined in qcom,ocv-capacity-legend. > > Need to specify the sizes of these if not 32-bit. > > All these seem to have units, so add unit suffixes as defined in > property-units.txt. Should i change code to use microamphours & microvolts or add a new suffix? > > > + > > +Example: > > + > > + pm8941_vadc: vadc@3100 { > > adc@... > > > + compatible = "qcom,spmi-vadc"; > > + reg = <0x3100>; > > + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + #io-channel-cells = <1>; > > + > > + bat_temp { > > + reg = ; > > + }; > > + }; > > + > > + bms@4000 { > > + compatible = "qcom,pm8941-bms"; > > + reg = <0x4000>; > > + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; > > + interrupt-names = "ocv_thr"; > > + > > + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; > > + io-channel-names = "temp"; > > + > > + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; > > + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; > > + > > + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 > > +80 75 70 65 > > +60 55 50 45 > > +40 35 30 25 > > +20 15 10 9 > > +8 7 6 5 4 > > +3 2 1 0>; > > + > > + qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; > > + qcom,ocv-lut = /bits/ 16 <428
Re: [PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
On 13 April 2018 18:08:54 BST, Craig Tatlor wrote: > > >On 13 April 2018 17:35:27 BST, Rob Herring wrote: >>On Sat, Apr 07, 2018 at 06:57:45PM +0100, Craig Tatlor wrote: >>> Add bindings for the Qualcomm Battery Monitoring system. >>> >>> Signed-off-by: Craig Tatlor >>> --- >>> .../bindings/power/supply/qcom_bms.txt| 93 >>+++ >>> 1 file changed, 93 insertions(+) >>> create mode 100644 >>Documentation/devicetree/bindings/power/supply/qcom_bms.txt >>> >>> diff --git >>a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >>b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >>> new file mode 100644 >>> index ..6296399edc09 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >>> @@ -0,0 +1,93 @@ >>> +Qualcomm Battery Measurement System >>> + >>> +The Qualcomm Battery Measurement System is found inside of Qualcomm >>PM8941 >> >>Is it Monitoring or Measurment? Monitoring, not sure how I missed that :) >> >>> +PMICs. It provides OCV and coulomb counter registers that allow the >>kernel >>> +to infer a capacity level. >> >>s/kernel/OS/ >> >>OCV? >Open Circuit Voltage - should I expand this? >> >>> + >>> +Required properties: >>> +- compatible: Should contain "qcom,pm8941-bms". >>> +- reg: Specifies the SPMI address and length >of >>the >>> + controller's registers. >>> +- interrupts: OCV threshold interrupt. >>> +- io-channels: Should contain IIO channel specifier >for >>the >>> + ADC channel that reports battery temperature. >>> +- io-channel-names: Should contain "temp". >>> +- qcom,fcc-temp-legend: An array containing the temperature, in >>degC, >>> + for each column of the FCC lookup table. >> >>What's FCC? >Full charge capacity - Should i also expand this? or maybe explain in >header paragraph? >> >>> +- qcom,fcc-lut: An array of FCC values in mah, one >entry >>for each >>> + temperature defined in in qcom,fcc-temp-legend. >>> +- qcom,ocv-temp-legend: An array containing the temperature, in >>degC, >>> + for each column of the OCV lookup table. >>> +- qcom,ocv-capacity-legend: An array containing the capacity for >>each >>> + row of the OCV lookup table. >>> +- qcom,ocv-lut: An array of OCV values in mV, one entry >>for each >>> + capacity defined in qcom,ocv-capacity-legend. >> >>Need to specify the sizes of these if not 32-bit. >Right. >> >>All these seem to have units, so add unit suffixes as defined in >>property-units.txt. >Will do. >> >>> + >>> +Example: >>> + >>> + pm8941_vadc: vadc@3100 { >> >>adc@... >Okay. >> >>> + compatible = "qcom,spmi-vadc"; >>> + reg = <0x3100>; >>> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; >>> + #address-cells = <1>; >>> + #size-cells = <0>; >>> + #io-channel-cells = <1>; >>> + >>> + bat_temp { >>> + reg = ; >>> + }; >>> + }; >>> + >>> + bms@4000 { >>> + compatible = "qcom,pm8941-bms"; >>> + reg = <0x4000>; >>> + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; >>> + interrupt-names = "ocv_thr"; >>> + >>> + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; >>> + io-channel-names = "temp"; >>> + >>> + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; >>> + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; >>> + >>> + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 >>> +80 75 70 65 >>> +
Re: [PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
On 13 April 2018 17:35:27 BST, Rob Herring wrote: >On Sat, Apr 07, 2018 at 06:57:45PM +0100, Craig Tatlor wrote: >> Add bindings for the Qualcomm Battery Monitoring system. >> >> Signed-off-by: Craig Tatlor >> --- >> .../bindings/power/supply/qcom_bms.txt| 93 >+++ >> 1 file changed, 93 insertions(+) >> create mode 100644 >Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> >> diff --git >a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> new file mode 100644 >> index ..6296399edc09 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt >> @@ -0,0 +1,93 @@ >> +Qualcomm Battery Measurement System >> + >> +The Qualcomm Battery Measurement System is found inside of Qualcomm >PM8941 > >Is it Monitoring or Measurment? > >> +PMICs. It provides OCV and coulomb counter registers that allow the >kernel >> +to infer a capacity level. > >s/kernel/OS/ > >OCV? Open Circuit Voltage - should I expand this? > >> + >> +Required properties: >> +- compatible: Should contain "qcom,pm8941-bms". >> +- reg: Specifies the SPMI address and length of >the >> +controller's registers. >> +- interrupts: OCV threshold interrupt. >> +- io-channels: Should contain IIO channel specifier for >the >> +ADC channel that reports battery temperature. >> +- io-channel-names: Should contain "temp". >> +- qcom,fcc-temp-legend: An array containing the temperature, in >degC, >> +for each column of the FCC lookup table. > >What's FCC? Full charge capacity - Should i also expand this? or maybe explain in header paragraph? > >> +- qcom,fcc-lut: An array of FCC values in mah, one entry >for each >> +temperature defined in in qcom,fcc-temp-legend. >> +- qcom,ocv-temp-legend: An array containing the temperature, in >degC, >> +for each column of the OCV lookup table. >> +- qcom,ocv-capacity-legend: An array containing the capacity for >each >> +row of the OCV lookup table. >> +- qcom,ocv-lut: An array of OCV values in mV, one entry >for each >> +capacity defined in qcom,ocv-capacity-legend. > >Need to specify the sizes of these if not 32-bit. Right. > >All these seem to have units, so add unit suffixes as defined in >property-units.txt. Will do. > >> + >> +Example: >> + >> +pm8941_vadc: vadc@3100 { > >adc@... Okay. > >> +compatible = "qcom,spmi-vadc"; >> +reg = <0x3100>; >> +interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; >> +#address-cells = <1>; >> +#size-cells = <0>; >> +#io-channel-cells = <1>; >> + >> +bat_temp { >> +reg = ; >> +}; >> +}; >> + >> +bms@4000 { >> +compatible = "qcom,pm8941-bms"; >> +reg = <0x4000>; >> +interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; >> +interrupt-names = "ocv_thr"; >> + >> +io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; >> +io-channel-names = "temp"; >> + >> +qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; >> +qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; >> + >> +qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 >> + 80 75 70 65 >> + 60 55 50 45 >> + 40 35 30 25 >> + 20 15 10 9 >> + 8 7 6 5 4 >> + 3 2 1 0>; >> + >> +qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; >> +qcom,ocv-lut = /bits/
[PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm Battery Monitoring system. Signed-off-by: Craig Tatlor --- .../bindings/power/supply/qcom_bms.txt| 93 +++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..6296399edc09 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,93 @@ +Qualcomm Battery Measurement System + +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941 +PMICs. It provides OCV and coulomb counter registers that allow the kernel +to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend: An array containing the temperature, in degC, + for each column of the FCC lookup table. +- qcom,fcc-lut: An array of FCC values in mah, one entry for each + temperature defined in in qcom,fcc-temp-legend. +- qcom,ocv-temp-legend: An array containing the temperature, in degC, + for each column of the OCV lookup table. +- qcom,ocv-capacity-legend: An array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut: An array of OCV values in mV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + + pm8941_vadc: vadc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 +80 75 70 65 +60 55 50 45 +40 35 30 25 +20 15 10 9 +8 7 6 5 4 +3 2 1 0>; + + qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,ocv-lut = /bits/ 16 <4288 4288 4306 4315 4315 + 4261 4241 4259 4266 4246 + 4201 4181 4201 4207 4187 + 4153 4133 4150 4155 4135 + 4105 4085 4100 4104 4084 + 4058 4038 4052 4058 4038 + 4012 3992 4004 4014 3994 + 3970 3950 3959 3971 3951 + 3931 3911 3915 3927 3907 + 3899 3879 3880 3884 3864 + 3873 3853 3851 3853 3833 + 3848 3828 3827 3829 3809 + 3829 3809 3808 3809 3789 + 3815 3795 3791 3791 3771 + 3801 3781 3775 3772 3752 + 3785 3765 3751 3746 3726 + 3767 3747 3727 3719
[PATCH v4 3/3] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0c3ad62c638c..aaf54b665f86 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11605,6 +11605,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MONITORING SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH v4 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then ammends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 500 3 files changed, 510 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..6c354c37bc55 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + depends on REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..f31c99c03518 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,500 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define CC_36_BIT_MASK 0xFLL +#define SIGN_EXTEND_36_TO_64_MASK (-1LL ^ CC_36_BIT_MASK) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u16 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u16 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct power_supply *bat; + struct power_supply_desc bat_desc; + struct bms_ocv_lut ocv_lut; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + spinlock_t bms_output_lock; + int base_addr; + + int ocv_thr_irq; + int ocv; +}; + +static s64 sign_extend_s36(uint64_t raw) +{ + raw = raw & CC_36_BIT_MASK; + + return (raw >> 35) == 0LL ? + raw : (SIGN_EXTEND_36_TO_64_MASK | raw); +} + +static unsigned int interpolate(int y0, int x0, int y1, int x1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + +static unsigned int between(int left, int right, int val) +{ + if (left <= val && val <= right) + return 1; + + return 0; +} + +static unsigned int interpolate_capacity(int temp, u16 ocv, + struct bms_ocv_lut ocv_lut) +{ + unsigned int pcj_minus_one = 0, pcj = 0; + int i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut.temp_legend[j]) + break; + + if (ocv >= ocv_lut.lut[0][j]) + return ocv_lut.capacity_
Re: [PATCH v3 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
On Sat, Apr 07, 2018 at 09:37:21AM -0700, Randy Dunlap wrote: > On 04/07/2018 06:59 AM, Craig Tatlor wrote: > > This patch adds a driver for the BMS (Battery Monitoring System) > > block of the PM8941 PMIC, it uses a lookup table defined in the > > device tree to generate a capacity from the BMS supplied OCV, it > > then ammends the coulomb counter to that to increase the accuracy > > of the estimated capacity. > > > > Signed-off-by: Craig Tatlor > > --- > > drivers/power/supply/Kconfig| 9 + > > drivers/power/supply/Makefile | 1 + > > drivers/power/supply/qcom_bms.c | 500 > > 3 files changed, 510 insertions(+) > > create mode 100644 drivers/power/supply/qcom_bms.c > > > diff --git a/drivers/power/supply/qcom_bms.c > > b/drivers/power/supply/qcom_bms.c > > new file mode 100644 > > index ..5aa6e906d1b9 > > --- /dev/null > > +++ b/drivers/power/supply/qcom_bms.c > > @@ -0,0 +1,500 @@ > > Hi, Hey > > > +static unsigned int between(int left, int right, int val) > > +{ > > + if (left <= val && val >= right) > > maybe double-check those if() conditions? > [or I need my morning coffee] Yeah, they are wrong, will fix. > > > + return 1; > > + > > + return 0; > > +} > > thanks, > -- > ~Randy
[PATCH v3 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm Battery Monitoring system. Signed-off-by: Craig Tatlor --- .../bindings/power/supply/qcom_bms.txt| 93 +++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..6296399edc09 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,93 @@ +Qualcomm Battery Measurement System + +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941 +PMICs. It provides OCV and coulomb counter registers that allow the kernel +to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend: An array containing the temperature, in degC, + for each column of the FCC lookup table. +- qcom,fcc-lut: An array of FCC values in mah, one entry for each + temperature defined in in qcom,fcc-temp-legend. +- qcom,ocv-temp-legend: An array containing the temperature, in degC, + for each column of the OCV lookup table. +- qcom,ocv-capacity-legend: An array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut: An array of OCV values in mV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + + pm8941_vadc: vadc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 +80 75 70 65 +60 55 50 45 +40 35 30 25 +20 15 10 9 +8 7 6 5 4 +3 2 1 0>; + + qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,ocv-lut = /bits/ 16 <4288 4288 4306 4315 4315 + 4261 4241 4259 4266 4246 + 4201 4181 4201 4207 4187 + 4153 4133 4150 4155 4135 + 4105 4085 4100 4104 4084 + 4058 4038 4052 4058 4038 + 4012 3992 4004 4014 3994 + 3970 3950 3959 3971 3951 + 3931 3911 3915 3927 3907 + 3899 3879 3880 3884 3864 + 3873 3853 3851 3853 3833 + 3848 3828 3827 3829 3809 + 3829 3809 3808 3809 3789 + 3815 3795 3791 3791 3771 + 3801 3781 3775 3772 3752 + 3785 3765 3751 3746 3726 + 3767 3747 3727 3719
[PATCH v3 3/3] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0c3ad62c638c..aaf54b665f86 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11605,6 +11605,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MONITORING SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH v3 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then ammends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 500 3 files changed, 510 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..6c354c37bc55 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + depends on REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..5aa6e906d1b9 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,500 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define CC_36_BIT_MASK 0xFLL +#define SIGN_EXTEND_36_TO_64_MASK (-1LL ^ CC_36_BIT_MASK) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u16 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u16 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct power_supply *bat; + struct power_supply_desc bat_desc; + struct bms_ocv_lut ocv_lut; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + spinlock_t bms_output_lock; + int base_addr; + + int ocv_thr_irq; + int ocv; +}; + +static s64 sign_extend_s36(uint64_t raw) +{ + raw = raw & CC_36_BIT_MASK; + + return (raw >> 35) == 0LL ? + raw : (SIGN_EXTEND_36_TO_64_MASK | raw); +} + +static unsigned int interpolate(int y0, int x0, int y1, int x1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + +static unsigned int between(int left, int right, int val) +{ + if (left <= val && val >= right) + return 1; + + return 0; +} + +static unsigned int interpolate_capacity(int temp, u16 ocv, + struct bms_ocv_lut ocv_lut) +{ + unsigned int pcj_minus_one = 0, pcj = 0; + int i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut.temp_legend[j]) + break; + + if (ocv >= ocv_lut.lut[0][j]) + return ocv_lut.capacity_
[PATCH v2 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then ammends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 500 3 files changed, 510 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..6c354c37bc55 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + depends on REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..5aa6e906d1b9 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,500 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define CC_36_BIT_MASK 0xFLL +#define SIGN_EXTEND_36_TO_64_MASK (-1LL ^ CC_36_BIT_MASK) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u16 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u16 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct power_supply *bat; + struct power_supply_desc bat_desc; + struct bms_ocv_lut ocv_lut; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + spinlock_t bms_output_lock; + int base_addr; + + int ocv_thr_irq; + int ocv; +}; + +static s64 sign_extend_s36(uint64_t raw) +{ + raw = raw & CC_36_BIT_MASK; + + return (raw >> 35) == 0LL ? + raw : (SIGN_EXTEND_36_TO_64_MASK | raw); +} + +static unsigned int interpolate(int y0, int x0, int y1, int x1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + +static unsigned int between(int left, int right, int val) +{ + if (left <= val && val >= right) + return 1; + + return 0; +} + +static unsigned int interpolate_capacity(int temp, u16 ocv, + struct bms_ocv_lut ocv_lut) +{ + unsigned int pcj_minus_one = 0, pcj = 0; + int i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut.temp_legend[j]) + break; + + if (ocv >= ocv_lut.lut[0][j]) + return ocv_lut.capacity_
[PATCH 3/3] MAINTAINERS: Add entry for the Qualcomm BMS
Signed-off-by: Craig Tatlor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0c3ad62c638c..b7ffa9268384 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11605,6 +11605,12 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k S: Supported F: drivers/net/wireless/ath/ath9k/ +QUALCOMM BATTERY MEASUREMENT SYSTEM +M: Craig Tatlor +L: linux...@vger.kernel.org +S: Maintained +F: drivers/power/supply/qcom_bms.c + QUALCOMM CAMERA SUBSYSTEM DRIVER M: Todor Tomov L: linux-me...@vger.kernel.org -- 2.17.0
[PATCH 1/3] power: supply: Add support for the Qualcomm Battery Monitoring System
This patch adds a driver for the BMS (Battery Monitoring System) block of the PM8941 PMIC, it uses a lookup table defined in the device tree to generate a capacity from the BMS supplied OCV, it then ammends the coulomb counter to that to increase the accuracy of the estimated capacity. Signed-off-by: Craig Tatlor --- drivers/power/supply/Kconfig| 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/qcom_bms.c | 500 3 files changed, 510 insertions(+) create mode 100644 drivers/power/supply/qcom_bms.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index 428b426842f4..6c354c37bc55 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -82,6 +82,15 @@ config BATTERY_ACT8945A Say Y here to enable support for power supply provided by Active-semi ActivePath ACT8945A charger. +config BATTERY_BMS + tristate "Qualcomm Battery Monitoring System driver" + depends on MFD_SPMI_PMIC || COMPILE_TEST + depends on OF + depends on REGMAP_SPMI + help + Say Y to include support for the Battery Monitoring hardware + found in some Qualcomm PM series PMICs. + config BATTERY_CPCAP tristate "Motorola CPCAP PMIC battery driver" depends on MFD_CPCAP && IIO diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index e83aa843bcc6..04204174b047 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_BATTERY_88PM860X)+= 88pm860x_battery.o obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o +obj-$(CONFIG_BATTERY_BMS) += qcom_bms.o obj-$(CONFIG_BATTERY_CPCAP)+= cpcap-battery.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/supply/qcom_bms.c b/drivers/power/supply/qcom_bms.c new file mode 100644 index ..5aa6e906d1b9 --- /dev/null +++ b/drivers/power/supply/qcom_bms.c @@ -0,0 +1,500 @@ +// SPDX-License-Identifier: GPL + +/* + * Qualcomm Battery Monitoring System driver + * + * Copyright (C) 2018 Craig Tatlor + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define REG_BMS_OCV_FOR_SOC_DATA0 0x90 +#define REG_BMS_SHDW_CC_DATA0 0xA8 +#define REG_BMS_CC_DATA_CTL0x42 +#define REG_BMS_CC_CLEAR_CTL 0x4 + +#define BMS_HOLD_OREG_DATA BIT(0) +#define BMS_CLEAR_SHDW_CC BIT(6) + +#define CC_36_BIT_MASK 0xFLL +#define SIGN_EXTEND_36_TO_64_MASK (-1LL ^ CC_36_BIT_MASK) + +#define BMS_CC_READING_RESOLUTION_N542535 +#define BMS_CC_READING_RESOLUTION_D1 +#define BMS_CC_READING_TICKS 56 +#define BMS_SLEEP_CLK_HZ 32764 + +#define SECONDS_PER_HOUR 3600 +#define TEMPERATURE_COLS 5 +#define MAX_CAPACITY_ROWS 50 + +/* lookup table for ocv -> capacity conversion */ +struct bms_ocv_lut { + int rows; + s8 temp_legend[TEMPERATURE_COLS]; + u8 capacity_legend[MAX_CAPACITY_ROWS]; + u16 lut[MAX_CAPACITY_ROWS][TEMPERATURE_COLS]; +}; + +/* lookup table for battery temperature -> fcc conversion */ +struct bms_fcc_lut { + s8 temp_legend[TEMPERATURE_COLS]; + u16 lut[TEMPERATURE_COLS]; +}; + +struct bms_device_info { + struct device *dev; + struct regmap *regmap; + struct power_supply *bat; + struct power_supply_desc bat_desc; + struct bms_ocv_lut ocv_lut; + struct bms_fcc_lut fcc_lut; + struct iio_channel *adc; + spinlock_t bms_output_lock; + int base_addr; + + int ocv_thr_irq; + int ocv; +}; + +static s64 sign_extend_s36(uint64_t raw) +{ + raw = raw & CC_36_BIT_MASK; + + return (raw >> 35) == 0LL ? + raw : (SIGN_EXTEND_36_TO_64_MASK | raw); +} + +static unsigned int interpolate(int y0, int x0, int y1, int x1, int x) +{ + if (y0 == y1 || x == x0) + return y0; + if (x1 == x0 || x == x1) + return y1; + + return y0 + ((y1 - y0) * (x - x0) / (x1 - x0)); +} + +static unsigned int between(int left, int right, int val) +{ + if (left <= val && val >= right) + return 1; + + return 0; +} + +static unsigned int interpolate_capacity(int temp, u16 ocv, + struct bms_ocv_lut ocv_lut) +{ + unsigned int pcj_minus_one = 0, pcj = 0; + int i, j; + + for (j = 0; j < TEMPERATURE_COLS; j++) + if (temp <= ocv_lut.temp_legend[j]) + break; + + if (ocv >= ocv_lut.lut[0][j]) + return ocv_lut.capacity_
[PATCH 2/3] dt-bindings: power: supply: qcom_bms: Add bindings
Add bindings for the Qualcomm battery measurement system. Signed-off-by: Craig Tatlor --- .../bindings/power/supply/qcom_bms.txt| 93 +++ 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/supply/qcom_bms.txt diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt new file mode 100644 index ..6296399edc09 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt @@ -0,0 +1,93 @@ +Qualcomm Battery Measurement System + +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941 +PMICs. It provides OCV and coulomb counter registers that allow the kernel +to infer a capacity level. + +Required properties: +- compatible: Should contain "qcom,pm8941-bms". +- reg: Specifies the SPMI address and length of the + controller's registers. +- interrupts: OCV threshold interrupt. +- io-channels: Should contain IIO channel specifier for the + ADC channel that reports battery temperature. +- io-channel-names: Should contain "temp". +- qcom,fcc-temp-legend: An array containing the temperature, in degC, + for each column of the FCC lookup table. +- qcom,fcc-lut: An array of FCC values in mah, one entry for each + temperature defined in in qcom,fcc-temp-legend. +- qcom,ocv-temp-legend: An array containing the temperature, in degC, + for each column of the OCV lookup table. +- qcom,ocv-capacity-legend: An array containing the capacity for each + row of the OCV lookup table. +- qcom,ocv-lut: An array of OCV values in mV, one entry for each + capacity defined in qcom,ocv-capacity-legend. + +Example: + + pm8941_vadc: vadc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + + bat_temp { + reg = ; + }; + }; + + bms@4000 { + compatible = "qcom,pm8941-bms"; + reg = <0x4000>; + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ocv_thr"; + + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>; + io-channel-names = "temp"; + + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>; + + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85 +80 75 70 65 +60 55 50 45 +40 35 30 25 +20 15 10 9 +8 7 6 5 4 +3 2 1 0>; + + qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>; + qcom,ocv-lut = /bits/ 16 <4288 4288 4306 4315 4315 + 4261 4241 4259 4266 4246 + 4201 4181 4201 4207 4187 + 4153 4133 4150 4155 4135 + 4105 4085 4100 4104 4084 + 4058 4038 4052 4058 4038 + 4012 3992 4004 4014 3994 + 3970 3950 3959 3971 3951 + 3931 3911 3915 3927 3907 + 3899 3879 3880 3884 3864 + 3873 3853 3851 3853 3833 + 3848 3828 3827 3829 3809 + 3829 3809 3808 3809 3789 + 3815 3795 3791 3791 3771 + 3801 3781 3775 3772 3752 + 3785 3765 3751 3746 3726 + 3767 3747 3727 3719
[PATCH] ARM: dts: qcom: pm8941: Add vadc nodes needed to estimate an ocv
vbat_sns is needed to estimate a fairly accurate on chip voltage and bat_therm is needed to produce an accurate percentage from the estimated ocv. Signed-off-by: Craig Tatlor --- arch/arm/boot/dts/qcom-pm8941.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi b/arch/arm/boot/dts/qcom-pm8941.dtsi index 1d5ef55c7ee5..2515c5c217ac 100644 --- a/arch/arm/boot/dts/qcom-pm8941.dtsi +++ b/arch/arm/boot/dts/qcom-pm8941.dtsi @@ -139,6 +139,9 @@ #size-cells = <0>; #io-channel-cells = <1>; + bat_temp { + reg = ; + }; die_temp { reg = ; }; @@ -154,6 +157,9 @@ ref_vdd { reg = ; }; + vbat_sns { + reg = ; + }; }; pm8941_iadc: iadc@3600 { -- 2.16.2
Re: [v9,04/15] clk: qcom: Add HFPLL driver
This doesn't seem to work correctly with the higher clocks on 8974pro, specifically 215040 hz or above, maybe its something to do with being bigger than an unsigned long. When i try to set any higher frequency it jumps down to 300mhz.
[PATCH v2] ARM: dts: msm8974: castor: Fix typo and add startup delay in touchscreen node
The compatible string was mistakenly pulled from the downstream tree and the startup delay property is needed to prevent io errors on initial page select. Signed-off-by: Craig Tatlor --- arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts index e87f2c99060d..701b396719c7 100644 --- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts +++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts @@ -491,7 +491,7 @@ pinctrl-0 = <&i2c8_pins>; synaptics@2c { - compatible = "syna,rmi-i2c"; + compatible = "syna,rmi4-i2c"; reg = <0x2c>; interrupt-parent = <&msmgpio>; @@ -506,6 +506,8 @@ pinctrl-names = "default"; pinctrl-0 = <&ts_int_pin>; + syna,startup-delay-ms = <10>; + rmi-f01@1 { reg = <0x1>; syna,nosleep = <1>; -- 2.16.1
[PATCH] ARM: dts: msm8974: castor: Correct typo in touchscreen compatible string
This was mistakenly pulled from the downstream tree. Signed-off-by: Craig Tatlor --- arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts index e87f2c99060d..d85311a0422c 100644 --- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts +++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts @@ -491,7 +491,7 @@ pinctrl-0 = <&i2c8_pins>; synaptics@2c { - compatible = "syna,rmi-i2c"; + compatible = "syna,rmi4-i2c"; reg = <0x2c>; interrupt-parent = <&msmgpio>; -- 2.16.1
[PATCH] arm/dts: Correct typo in touchscreen compatible string
This was mistakenly pulled from the downstream driver Signed-off-by: Craig Tatlor --- arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts index e87f2c99060d..d85311a0422c 100644 --- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts +++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts @@ -491,7 +491,7 @@ pinctrl-0 = <&i2c8_pins>; synaptics@2c { - compatible = "syna,rmi-i2c"; + compatible = "syna,rmi4-i2c"; reg = <0x2c>; interrupt-parent = <&msmgpio>; -- 2.16.1
[PATCH] drm/msm: Call msm_init_vram before binding the gpu
vram.size is needed when binding a gpu without an iommu and is defined in msm_init_vram(), so run that before binding it. Signed-off-by: Craig Tatlor --- drivers/gpu/drm/msm/msm_drv.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index bdf0fe754f7b..82d4126ca017 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -400,6 +400,14 @@ static int msm_drm_init(struct device *dev, struct drm_driver *drv) drm_mode_config_init(ddev); + ret = msm_init_vram(ddev); + if (ret) { + msm_mdss_destroy(ddev); + kfree(priv); + drm_dev_unref(ddev); + return ret; + } + /* Bind all our sub-components: */ ret = component_bind_all(dev, ddev); if (ret) { @@ -409,10 +417,6 @@ static int msm_drm_init(struct device *dev, struct drm_driver *drv) return ret; } - ret = msm_init_vram(ddev); - if (ret) - goto fail; - msm_gem_shrinker_init(ddev); switch (get_mdp_ver(pdev)) { -- 2.15.1
Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC
Gotcha. Thank you for the detailed explanation. I will give that a try and see if it fixes the problem. Cheers, Craig On Wed, Jan 10, 2018 at 3:05 PM, Shirley Her (SC) wrote: > Hi, Craig: > > The upstream user is using SD card not eMMC for this device in the current > market. BIOS does not need to set bit 4 of 0x308 to 1 for device that only > use SD card. Since Bayhub already shipped this device in the market to > support SD card and we can not just upstream driver to only support eMMC for > this device. > > We can implement a driver that can detect SD or eMMC is used in the device > but it will require a lot of code changes and retry which will delay the card > init time plus there is no device+eMMC configuration in the market now. > > Since this is the 1st time this device is used to support eMMC, so we use > 0x308 bit 4 to identify the device is connected to eMMC and BIOS can help to > do the job which makes driver implementation simpler. > > > Thanks, > Shirley > > > -Original Message- > From: Craig Bergstrom [mailto:cra...@google.com] > Sent: Wednesday, January 10, 2018 2:33 PM > To: Shirley Her (SC) > Cc: Adrian Hunter; LinuxPatchCommit; ulf.hans...@linaro.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC > > Hey Shirley, > > If all upstream users of this device need to set bit 4 of 0x308 to 1, should > the upstream driver do that? > > Craig > > > On Wed, Jan 10, 2018 at 12:05 PM, Shirley Her (SC) > wrote: >> Hi, Craig: >> >> As the message said during sign off as below. BIOS needs to set x0308 bit 4 >> to 1 so the driver will skip 3.3V in eMMC initialization process. It means >> depthcharge needs to set 0x308 bit 4 to 1 first in order for driver to use >> eMMC 1.8V. >> >> In some case of eMMC used as boot device, the eMMC signaling voltage >>> is fixed to 1.8v, bios can set o2 sd host controller register 0x308 >>> bit4 to let host controller skip try 3.3.v signaling voltage in eMMC >>> initialize process. >> >> Thanks, >> Shirley >> >> -Original Message- >> From: Craig Bergstrom [mailto:cra...@google.com] >> Sent: Thursday, December 21, 2017 9:18 AM >> To: Adrian Hunter >> Cc: LinuxPatchCommit; ulf.hans...@linaro.org; >> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Shirley Her >> (SC) >> Subject: Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning >> for eMMC >> >> Thanks for sending these patches out, I would be very excited to see these >> devices supported by Linux. >> >> I'm trying them out with a SEABIRD device (pci device 1217:8620). >> When I boot up and load the driver, it don't see any indication of the >> existence of block device and I see these messages repeatedly spammed to the >> kernel logs: >> >> [0.855163] mmc1: Unknown controller version (3). You may >> experience problems. >> [0.862519] mmc1: SDHCI controller on PCI [:01:00.0] using ADMA >> [ 93.152163] mmc1: Timeout waiting for hardware cmd interrupt. >> [ 93.157911] mmc1: sdhci: SDHCI REGISTER DUMP === >> [ 93.164347] mmc1: sdhci: Sys addr: 0x | Version: 0x0603 >> [ 93.170782] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x >> [ 93.177218] mmc1: sdhci: Argument: 0x | Trn mode: 0x >> [ 93.183652] mmc1: sdhci: Present: 0x01ff | Host ctl: 0x0001 >> [ 93.190088] mmc1: sdhci: Power: 0x000f | Blk gap: 0x >> [ 93.196523] mmc1: sdhci: Wake-up: 0x | Clock:0xfa07 >> [ 93.202956] mmc1: sdhci: Timeout: 0x | Int stat: 0x00018000 >> [ 93.209392] mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 >> [ 93.215826] mmc1: sdhci: AC12 err: 0x | Slot int: 0x0001 >> [ 93.60] mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 >> [ 93.228694] mmc1: sdhci: Cmd: 0x371a | Max curr: 0x005800c8 >> [ 93.235127] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x >> [ 93.241562] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x >> [ 93.247994] mmc1: sdhci: Host ctl2: 0x >> [ 93.252435] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x >> [ 93.258863] mmc1: sdhci: >> [ 103.392164] mmc1: Timeout waiting for hardware cmd interrupt. >> [ 103.397913] mmc1: sdhci: SDHCI REGISTER DUMP === [ >> 103.404350] mmc1: sdhci: Sys addr: 0x |
Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC
Hey Shirley, If all upstream users of this device need to set bit 4 of 0x308 to 1, should the upstream driver do that? Craig On Wed, Jan 10, 2018 at 12:05 PM, Shirley Her (SC) wrote: > Hi, Craig: > > As the message said during sign off as below. BIOS needs to set x0308 bit 4 > to 1 so the driver will skip 3.3V in eMMC initialization process. It means > depthcharge needs to set 0x308 bit 4 to 1 first in order for driver to use > eMMC 1.8V. > > In some case of eMMC used as boot device, the eMMC signaling voltage >> is fixed to 1.8v, bios can set o2 sd host controller register 0x308 >> bit4 to let host controller skip try 3.3.v signaling voltage in eMMC >> initialize process. > > Thanks, > Shirley > > -Original Message- > From: Craig Bergstrom [mailto:cra...@google.com] > Sent: Thursday, December 21, 2017 9:18 AM > To: Adrian Hunter > Cc: LinuxPatchCommit; ulf.hans...@linaro.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; Shirley Her (SC) > Subject: Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC > > Thanks for sending these patches out, I would be very excited to see these > devices supported by Linux. > > I'm trying them out with a SEABIRD device (pci device 1217:8620). > When I boot up and load the driver, it don't see any indication of the > existence of block device and I see these messages repeatedly spammed to the > kernel logs: > > [0.855163] mmc1: Unknown controller version (3). You may > experience problems. > [0.862519] mmc1: SDHCI controller on PCI [:01:00.0] using ADMA > [ 93.152163] mmc1: Timeout waiting for hardware cmd interrupt. > [ 93.157911] mmc1: sdhci: SDHCI REGISTER DUMP === > [ 93.164347] mmc1: sdhci: Sys addr: 0x | Version: 0x0603 > [ 93.170782] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x > [ 93.177218] mmc1: sdhci: Argument: 0x | Trn mode: 0x > [ 93.183652] mmc1: sdhci: Present: 0x01ff | Host ctl: 0x0001 > [ 93.190088] mmc1: sdhci: Power: 0x000f | Blk gap: 0x > [ 93.196523] mmc1: sdhci: Wake-up: 0x | Clock:0xfa07 > [ 93.202956] mmc1: sdhci: Timeout: 0x | Int stat: 0x00018000 > [ 93.209392] mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 > [ 93.215826] mmc1: sdhci: AC12 err: 0x | Slot int: 0x0001 > [ 93.60] mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 > [ 93.228694] mmc1: sdhci: Cmd: 0x371a | Max curr: 0x005800c8 > [ 93.235127] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x > [ 93.241562] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x > [ 93.247994] mmc1: sdhci: Host ctl2: 0x > [ 93.252435] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > [ 93.258863] mmc1: sdhci: > [ 103.392164] mmc1: Timeout waiting for hardware cmd interrupt. > [ 103.397913] mmc1: sdhci: SDHCI REGISTER DUMP === [ > 103.404350] mmc1: sdhci: Sys addr: 0x | Version: 0x0603 [ > 103.410786] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x [ > 103.417221] mmc1: sdhci: Argument: 0x | Trn mode: 0x > [ 103.423654] mmc1: sdhci: Present: 0x01ff | Host ctl: 0x0001 > [ 103.430089] mmc1: sdhci: Power: 0x000f | Blk gap: 0x > [ 103.436523] mmc1: sdhci: Wake-up: 0x | Clock:0xfa07 > [ 103.442955] mmc1: sdhci: Timeout: 0x | Int stat: 0x00018000 > [ 103.449390] mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 [ > 103.455823] mmc1: sdhci: AC12 err: 0x | Slot int: 0x0001 > [ 103.462255] mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 > [ 103.468689] mmc1: sdhci: Cmd: 0x371a | Max curr: 0x005800c8 > [ 103.475126] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x > [ 103.481560] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x > [ 103.487994] mmc1: sdhci: Host ctl2: 0x [ 103.492435] mmc1: sdhci: > ADMA Err: 0x | ADMA Ptr: 0x [ 103.498867] mmc1: sdhci: > > > Is it expected that this should "just work", or am I doing something wrong? > My patched kernel is based on 4.14.2. > > On Tue, Dec 19, 2017 at 2:05 AM, Adrian Hunter > wrote: >> On 04/12/17 11:39, LinuxPatchCommit wrote: >>> Dear All, >>> >>> For O2micro/Bayhubtech SD Host DeviceID 8620, eMMC HS200 mode is working at >>> 1.8v and it uses hardware tuning. The hardware tuning only needs to send >>> one tuning command instead of multiple tuning commands wit
Re: [PATCH 1/3] mmc: sdhci-pci-o2micro: Add hardware tuning for eMMC
Thanks for sending these patches out, I would be very excited to see these devices supported by Linux. I'm trying them out with a SEABIRD device (pci device 1217:8620). When I boot up and load the driver, it don't see any indication of the existence of block device and I see these messages repeatedly spammed to the kernel logs: [0.855163] mmc1: Unknown controller version (3). You may experience problems. [0.862519] mmc1: SDHCI controller on PCI [:01:00.0] using ADMA [ 93.152163] mmc1: Timeout waiting for hardware cmd interrupt. [ 93.157911] mmc1: sdhci: SDHCI REGISTER DUMP === [ 93.164347] mmc1: sdhci: Sys addr: 0x | Version: 0x0603 [ 93.170782] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x [ 93.177218] mmc1: sdhci: Argument: 0x | Trn mode: 0x [ 93.183652] mmc1: sdhci: Present: 0x01ff | Host ctl: 0x0001 [ 93.190088] mmc1: sdhci: Power: 0x000f | Blk gap: 0x [ 93.196523] mmc1: sdhci: Wake-up: 0x | Clock:0xfa07 [ 93.202956] mmc1: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 93.209392] mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 [ 93.215826] mmc1: sdhci: AC12 err: 0x | Slot int: 0x0001 [ 93.60] mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 [ 93.228694] mmc1: sdhci: Cmd: 0x371a | Max curr: 0x005800c8 [ 93.235127] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x [ 93.241562] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 93.247994] mmc1: sdhci: Host ctl2: 0x [ 93.252435] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 93.258863] mmc1: sdhci: [ 103.392164] mmc1: Timeout waiting for hardware cmd interrupt. [ 103.397913] mmc1: sdhci: SDHCI REGISTER DUMP === [ 103.404350] mmc1: sdhci: Sys addr: 0x | Version: 0x0603 [ 103.410786] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x [ 103.417221] mmc1: sdhci: Argument: 0x | Trn mode: 0x [ 103.423654] mmc1: sdhci: Present: 0x01ff | Host ctl: 0x0001 [ 103.430089] mmc1: sdhci: Power: 0x000f | Blk gap: 0x [ 103.436523] mmc1: sdhci: Wake-up: 0x | Clock:0xfa07 [ 103.442955] mmc1: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 103.449390] mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 [ 103.455823] mmc1: sdhci: AC12 err: 0x | Slot int: 0x0001 [ 103.462255] mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 [ 103.468689] mmc1: sdhci: Cmd: 0x371a | Max curr: 0x005800c8 [ 103.475126] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x [ 103.481560] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 103.487994] mmc1: sdhci: Host ctl2: 0x [ 103.492435] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 103.498867] mmc1: sdhci: Is it expected that this should "just work", or am I doing something wrong? My patched kernel is based on 4.14.2. On Tue, Dec 19, 2017 at 2:05 AM, Adrian Hunter wrote: > On 04/12/17 11:39, LinuxPatchCommit wrote: >> Dear All, >> >> For O2micro/Bayhubtech SD Host DeviceID 8620, eMMC HS200 mode is working at >> 1.8v and it uses hardware tuning. The hardware tuning only needs to send one >> tuning command instead of multiple tuning commands with software tuning. >> >> Signed-off-by: ernest.zhang >> --- >> drivers/mmc/host/sdhci-pci-o2micro.c | 276 >> ++- >> 1 file changed, 239 insertions(+), 37 deletions(-) >> >> diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c >> b/drivers/mmc/host/sdhci-pci-o2micro.c >> index 14273ca00641..2a7ffd240497 100644 >> --- a/drivers/mmc/host/sdhci-pci-o2micro.c >> +++ b/drivers/mmc/host/sdhci-pci-o2micro.c >> @@ -16,22 +16,223 @@ >> */ >> >> #include >> - >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> #include "sdhci.h" >> #include "sdhci-pci.h" >> #include "sdhci-pci-o2micro.h" >> >> +static void sdhci_o2_start_tuning(struct sdhci_host *host) { >> + u16 ctrl; >> + >> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); >> + ctrl |= SDHCI_CTRL_EXEC_TUNING; >> + if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND) >> + ctrl |= SDHCI_CTRL_TUNED_CLK; >> + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2); >> + >> + /* >> + * As per the Host Controller spec v3.00, tuning command >> + * generates Buffer Read Ready interrupt, so enable that. >> + * >> + * Note: The spec clearly says that when tuning sequence >> + * is being performed, the controller does not generate >> + * interrupts other than Buffer Read Ready interrupt. But >> + * to make sure we don't hit a controller bug, we _only_ >> + * enable Buffer Read Ready interrupt here. >> +
Re: [PATCH 3.18 08/20] tun/tap: sanitize TUNSETSNDBUF input
On Thu, Nov 16, 2017 at 12:28 PM, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Craig Gallek > > > [ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ] > > Syzkaller found several variants of the lockup below by setting negative > values with the TUNSETSNDBUF ioctl. This patch adds a sanity check > to both the tun and tap versions of this ioctl. > > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389] > Modules linked in: > irq event stamp: 329692056 > hardirqs last enabled at (329692055): [] > _raw_spin_unlock_irqrestore+0x31/0x75 > hardirqs last disabled at (329692056): [] > apic_timer_interrupt+0x98/0xb0 > softirqs last enabled at (35659740): [] > __do_softirq+0x328/0x48c > softirqs last disabled at (35659731): [] > irq_exit+0xbc/0xd0 > CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: 880009452140 task.stack: 880006a2 > RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80 > RSP: 0018:880006a27c50 EFLAGS: 0282 ORIG_RAX: ff10 > RAX: 880009ac68d0 RBX: 880006a27ce0 RCX: > RDX: 0001 RSI: 880006a27ce0 RDI: 880009ac6900 > RBP: 880006a27c60 R08: R09: > R10: 0001 R11: 0063ff00 R12: 880009ac6900 > R13: 880006a27cf8 R14: 0001 R15: 880006a27cf8 > FS: 7f4be4838700() GS:88000cc0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 20101000 CR3: 09616000 CR4: 06f0 > Call Trace: >prepare_to_wait+0x26/0xc0 >sock_alloc_send_pskb+0x14e/0x270 >? remove_wait_queue+0x60/0x60 >tun_get_user+0x2cc/0x19d0 >? __tun_get+0x60/0x1b0 >tun_chr_write_iter+0x57/0x86 >__vfs_write+0x156/0x1e0 >vfs_write+0xf7/0x230 >SyS_write+0x57/0xd0 >entry_SYSCALL_64_fastpath+0x1f/0xbe > RIP: 0033:0x7f4be4356df9 > RSP: 002b:7ffc18101c08 EFLAGS: 0293 ORIG_RAX: 0001 > RAX: ffda RBX: RCX: 7f4be4356df9 > RDX: 0046 RSI: 20101000 RDI: 0005 > RBP: 7ffc18101c40 R08: 0001 R09: 0001 > R10: 0001 R11: 0293 R12: 559c75f64780 > R13: 7ffc18101d30 R14: R15: > > Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device") > Fixes: 20d29d7a916a ("net: macvtap driver") > Signed-off-by: Craig Gallek > Reviewed-by: Eric Dumazet > Signed-off-by: David S. Miller > Signed-off-by: Greg Kroah-Hartman > --- > drivers/net/macvtap.c |2 ++ > drivers/net/tun.c |4 > 2 files changed, 6 insertions(+) > > --- a/drivers/net/macvtap.c > +++ b/drivers/net/macvtap.c > @@ -1047,6 +1047,8 @@ static long macvtap_ioctl(struct file *f > case TUNSETSNDBUF: > if (get_user(u, up)) > return -EFAULT; > + if (s <= 0) > + return -EINVAL; Yay build bot! This 's' should be a 'u' in the 3.18 version. > > q->sk.sk_sndbuf = u; > return 0; > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2054,6 +2054,10 @@ static long __tun_chr_ioctl(struct file > ret = -EFAULT; > break; > } > + if (sndbuf <= 0) { > + ret = -EINVAL; > + break; > + } > > tun->sndbuf = sndbuf; > tun_set_sndbuf(tun); > >
[tip:x86/urgent] x86/mm: Limit mmap() of /dev/mem to valid physical addresses
Commit-ID: be62a32044061cb4a3b70a10598e093f1319102e Gitweb: https://git.kernel.org/tip/be62a32044061cb4a3b70a10598e093f1319102e Author: Craig Bergstrom AuthorDate: Wed, 15 Nov 2017 15:29:51 -0700 Committer: Ingo Molnar CommitDate: Thu, 16 Nov 2017 12:49:48 +0100 x86/mm: Limit mmap() of /dev/mem to valid physical addresses One thing /dev/mem access APIs should verify is that there's no way that excessively large pfn's can leak into the high bits of the page table entry. In particular, if people can use "very large physical page addresses" through /dev/mem to set the bits past bit 58 - SOFTW4 and permission key bits and NX bit, that could *really* confuse the kernel. We had an earlier attempt: ce56a86e2ade ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses") ... which turned out to be too restrictive (breaking mem=... bootups for example) and had to be reverted in: 90edaac62729 ("Revert "x86/mm: Limit mmap() of /dev/mem to valid physical addresses"") This v2 attempt modifies the original patch and makes sure that mmap(/dev/mem) limits the pfns so that it at least fits in the actual pteval_t architecturally: - Make sure mmap_mem() actually validates that the offset fits in phys_addr_t ( This may be indirectly true due to some other check, but it's not entirely obvious. ) - Change valid_mmap_phys_addr_range() to just use phys_addr_valid() on the top byte ( Top byte is sufficient, because mmap_mem() has already checked that it cannot wrap. ) - Add a few comments about what the valid_phys_addr_range() vs. valid_mmap_phys_addr_range() difference is. Signed-off-by: Craig Bergstrom [ Fixed the checks and added comments. ] Signed-off-by: Linus Torvalds [ Collected the discussion and patches into a commit. ] Cc: Boris Ostrovsky Cc: Fengguang Wu Cc: Greg Kroah-Hartman Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Cc: Peter Zijlstra Cc: Sander Eikelenboom Cc: Sean Young Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/CA+55aFyEcOMb657vWSmrM13OxmHxC-XxeBmNis=dwvvpjuo...@mail.gmail.com Signed-off-by: Ingo Molnar --- arch/x86/include/asm/io.h | 4 arch/x86/mm/mmap.c| 16 drivers/char/mem.c| 4 3 files changed, 24 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 93ae8ae..95e9486 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -111,6 +111,10 @@ build_mmio_write(__writeq, "q", unsigned long, "r", ) #endif +#define ARCH_HAS_VALID_PHYS_ADDR_RANGE +extern int valid_phys_addr_range(phys_addr_t addr, size_t size); +extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size); + /** * virt_to_phys- map virtual addresses to physical * @address: address to remap diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 62285fe..155ecba 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -33,6 +33,8 @@ #include #include +#include "physaddr.h" + struct va_alignment __read_mostly va_align = { .flags = -1, }; @@ -220,3 +222,17 @@ bool mmap_address_hint_valid(unsigned long addr, unsigned long len) return (addr > DEFAULT_MAP_WINDOW) == (addr + len > DEFAULT_MAP_WINDOW); } + +/* Can we access it for direct reading/writing? Must be RAM: */ +int valid_phys_addr_range(phys_addr_t addr, size_t count) +{ + return addr + count <= __pa(high_memory); +} + +/* Can we access it through mmap? Must be a valid physical address: */ +int valid_mmap_phys_addr_range(unsigned long pfn, size_t count) +{ + phys_addr_t addr = (phys_addr_t)pfn << PAGE_SHIFT; + + return phys_addr_valid(addr + count - 1); +} diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 970e124..6aefe53 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -343,6 +343,10 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma) size_t size = vma->vm_end - vma->vm_start; phys_addr_t offset = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT; + /* Does it even fit in phys_addr_t? */ + if (offset >> PAGE_SHIFT != vma->vm_pgoff) + return -EINVAL; + /* It's illegal to wrap around the end of the physical address space. */ if (offset + (phys_addr_t)size - 1 < offset) return -EINVAL;
Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
Just a follow up, since I said I would come back around this week. I've come up with a couple patchsets that I'm going to attempt to test internally before I sent out more widely. I'm thinking it's appropriate to mail out two changes: (1) Reject attempts to map physical memory addresses outside the valid physical memory bus width of the system. This should reject mappings that will obviously break the page fault handler without affecting any memory mapped devices. (2) Make a page fault handler that's called with a reserved bit set kill the process instead of reboot the whole kernel. This is based on Linus' comment "I think we might also look at just also handling the whole RSVD page fault case more gracefully". Standby while I test these changes. Cheers, Craig On Fri, Oct 27, 2017 at 1:28 PM, Craig Bergstrom wrote: > Sounds good. Thanks for the context. > > I'll keep this on my plate and I'll turn something around once I've > had a chance to test a bit, probably next week. > > On Fri, Oct 27, 2017 at 1:24 PM, Ingo Molnar wrote: >> >> * Craig Bergstrom wrote: >> >>> Reverting seems like the right approach at the moment. My apologies >>> for the breakage so late the in the cycle. >> >> Note that there's no need for you to apologize and you carry exactly zero >> amount >> of blame for the late-cycle breakage: it was my decision to send it to Linus >> so >> quickly, you never asked for it to be sent upstream on such a short notice. >> >> ( Classic "patch makes sense, looks good, other arches ar doing this too, >> and I >> tested it myself too on multiple systems, so it must be obviously fine for >> everyone" moment. ) >> >> Your change still makes sense from a robustness POV, so please send it again >> with >> the suggested fixes - and I'll be more careful with the upstream merge this >> time. >> >> Thanks, >> >> Ingo
Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
Sounds good. Thanks for the context. I'll keep this on my plate and I'll turn something around once I've had a chance to test a bit, probably next week. On Fri, Oct 27, 2017 at 1:24 PM, Ingo Molnar wrote: > > * Craig Bergstrom wrote: > >> Reverting seems like the right approach at the moment. My apologies >> for the breakage so late the in the cycle. > > Note that there's no need for you to apologize and you carry exactly zero > amount > of blame for the late-cycle breakage: it was my decision to send it to Linus > so > quickly, you never asked for it to be sent upstream on such a short notice. > > ( Classic "patch makes sense, looks good, other arches ar doing this too, and > I > tested it myself too on multiple systems, so it must be obviously fine for > everyone" moment. ) > > Your change still makes sense from a robustness POV, so please send it again > with > the suggested fixes - and I'll be more careful with the upstream merge this > time. > > Thanks, > > Ingo
Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
Reverting seems like the right approach at the moment. My apologies for the breakage so late the in the cycle. Post-revert, there remains a bug here wherein you can make the system OOPS if you mmap memory above the 48 bit bus width. Linus/Ingo, is there something in particular that you'd like to see before pulling in a check on the bus width (or some other fix)? Based on Linus' comment, the bus width check smells like something that should cook for a while before pulling into mainline. On Thu, Oct 26, 2017 at 1:29 PM, Linus Torvalds wrote: > On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote: >> >> Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to >> limit >> (trim) 'RAM' and not much else. > > Agreed. You should very much be able to map in IO memory or whatever > above the 2G address even if the high_memory itself might be limited > to 2GB. > > So I think that commit ce56a86e2ade ("x86/mm: Limit mmap() of /dev/mem > to valid physical addresses") is wrong, in that "high_memory" is very > much the wrong thing to test. > > The memory mapping limit might validly be something like > >1ull << boot_cpu_data.x86_phys_bits > > or similar, but for now I suspect that the right thing to do is to > revert. I'm not convinced that our "x86_phys_bits" value is guaranteed > to be always right, since I think we mainlyjust use it for showing > things, rather than have lots of code that depends on it. > > Ingo? > >Linus
Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
Sander, thanks for the details, they've been very useful. I suspect that your host system's mem=2048M parameter is causing the problem. Any chance you can confirm by removing the parameter and running the guest code path? More specifically, since you're telling the kernel that it's high memory address is at 2048M and your device is at 0xfe1fe000 (~4G), the new mmap() limits are preventing you from mapping addresses that are explicitly disallowed by the parameter. On Thu, Oct 26, 2017 at 10:39 AM, Ingo Molnar wrote: > > * Craig Bergstrom wrote: > >> Yes, not much time left for 4.14, it might be reasonable to pull the >> change out since it's causing problems. [...] > > Ok, I'll queue up a revert tomorrow morning and send it to Linus ASAP if > there's > no good fix by then. In hindsight I should have queued it for v4.15 ... > > Thanks, > > Ingo
Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
Yes, not much time left for 4.14, it might be reasonable to pull the change out since it's causing problems. The 0day testing robot failure is relatively simple (definitely aided by the reproduction instructions), but I'm still pulling apart the qemu failure. Another alternative that I considered when coding this up would be to explicitly reject mmaps of pages that are greater than the bus width of the system. It would let through a lot more mmaps of /dev/mem that don't point to valid addresses, but prevents the page table corruption and seems less likely to cause problems (diff shown below). I haven't tested this on anything but a single 64-bit system. Standby while I figure out what's going on with the qemu failures. diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 320c6237e1d1..7d78ae4d0731 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -182,7 +182,11 @@ int valid_phys_addr_range(phys_addr_t addr, size_t count) int valid_mmap_phys_addr_range(unsigned long pfn, size_t count) { - phys_addr_t addr = (phys_addr_t)pfn << PAGE_SHIFT; + phys_addr_t addr = pfn << PAGE_SHIFT; - return valid_phys_addr_range(addr, count); + if ((addr + count) & + ~(1ul << (unsigned long)boot_cpu_data.x86_phys_bits)) + return 0; + + return 1; } On Thu, Oct 26, 2017 at 2:58 AM, Sander Eikelenboom wrote: > On 26/10/17 10:12, Sander Eikelenboom wrote: >> On 26/10/17 10:05, Sander Eikelenboom wrote: >>> On 26/10/17 00:02, Craig Bergstrom wrote: >>>> Thanks for the notification, my apologies for the breakage. I'll take a >>>> close look and see if I can figure out what went wrong. >>>> >>>> Sander, any chance you can send /proc/iomem and the inputs to the mmap call >>>> that fail on your affected system? >>> >>> Hi Craig, >>> >>> The output from /proc/iomem is simple to get and attached. >>> The mmap call is probably issued by qemu and will require more digging. >> >> Ahh grepping qemu gave a pointer, it's probably the code in: >> >> http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=blob;f=hw/xen/xen_pt_msi.c;h=ff9a79f5d27ad7d74a1b22297be560feb455063c;hb=5cd7ce5dde3f228b3b669ed9ca432f588947bd40 >> >> around line 571, that would also explain why it's only this device that >> has the problem, since it's the only one trying to use MSI(-X) >> interrupts. Will see it i can add some logging to that function. > > Attached is the qemu debug output with an extra line outputting all stuff > used to calculate the arguments used by the mmap-call. > -- > Sander > > >> -- >> Sander >> >> >>> >>> I don't know if there is that much time left for 4.14, since we are at >>> RC6 already. >>> >>> -- >>> Sander >>> >>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 2:50 PM, Boris Ostrovsky >>>> >>>> wrote: >>>> >>>>> On 10/23/2017 10:44 PM, Fengguang Wu wrote: >>>>>> Greetings, >>>>>> >>>>>> 0day kernel testing robot got the below dmesg and the first bad commit is >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>> master >>>>>> >>>>>> commit ce56a86e2ade45d052b3228cdfebe913a1ae7381 >>>>>> Author: Craig Bergstrom >>>>>> AuthorDate: Thu Oct 19 13:28:56 2017 -0600 >>>>>> Commit: Ingo Molnar >>>>>> CommitDate: Fri Oct 20 09:48:00 2017 +0200 >>>>>> >>>>>> x86/mm: Limit mmap() of /dev/mem to valid physical addresses >>>>> >>>>> Also note >>>>> https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg02935.html >>>>> >>>>> -boris >>>>> >>>> >>> >> >
[tip:x86/mm] x86/mm: Limit mmap() of /dev/mem to valid physical addresses
Commit-ID: ce56a86e2ade45d052b3228cdfebe913a1ae7381 Gitweb: https://git.kernel.org/tip/ce56a86e2ade45d052b3228cdfebe913a1ae7381 Author: Craig Bergstrom AuthorDate: Thu, 19 Oct 2017 13:28:56 -0600 Committer: Ingo Molnar CommitDate: Fri, 20 Oct 2017 09:48:00 +0200 x86/mm: Limit mmap() of /dev/mem to valid physical addresses Currently, it is possible to mmap() any offset from /dev/mem. If a program mmaps() /dev/mem offsets outside of the addressable limits of a system, the page table can be corrupted by setting reserved bits. For example if you mmap() offset 0x0001 of /dev/mem on an x86_64 system with a 48-bit bus, the page fault handler will be called with error_code set to RSVD. The kernel then crashes with a page table corruption error. This change prevents this page table corruption on x86 by refusing to mmap offsets higher than the highest valid address in the system. Signed-off-by: Craig Bergstrom Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: dsafo...@virtuozzo.com Cc: kirill.shute...@linux.intel.com Cc: mho...@suse.com Cc: o...@redhat.com Link: http://lkml.kernel.org/r/20171019192856.39672-1-cra...@google.com Signed-off-by: Ingo Molnar --- arch/x86/include/asm/io.h | 4 arch/x86/mm/mmap.c| 12 2 files changed, 16 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index c40a95c..322d25a 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -110,6 +110,10 @@ build_mmio_write(__writeq, "q", unsigned long, "r", ) #endif +#define ARCH_HAS_VALID_PHYS_ADDR_RANGE +extern int valid_phys_addr_range(phys_addr_t addr, size_t size); +extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size); + /** * virt_to_phys- map virtual addresses to physical * @address: address to remap diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index a996798..320c623 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -174,3 +174,15 @@ const char *arch_vma_name(struct vm_area_struct *vma) return "[mpx]"; return NULL; } + +int valid_phys_addr_range(phys_addr_t addr, size_t count) +{ + return addr + count <= __pa(high_memory); +} + +int valid_mmap_phys_addr_range(unsigned long pfn, size_t count) +{ + phys_addr_t addr = (phys_addr_t)pfn << PAGE_SHIFT; + + return valid_phys_addr_range(addr, count); +}
[PATCH] X86/mm limit mmap of /dev/mem to valid addrs.
Currently, it is possible to mmap any offset from /dev/mem. If a program mmaps() /dev/mem offsets outside of the addressable limits of a system, the page table is corrupted by setting some reserved bits. If you mmap offset 0x0001 of /dev/mem on an x86_64 with a 48-bit bus, the page fault handler will be called with error_code set to RSVD. The kernel then crashes with a page table corruption error. This change prevents this page table corruption on x86 by refusing to mmap offsets higher than the highest valid address in the system. Signed-off-by: Craig Bergstrom --- arch/x86/include/asm/io.h | 4 arch/x86/mm/mmap.c| 12 2 files changed, 16 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index c40a95c33bb8..322d25ae23ab 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -110,6 +110,10 @@ build_mmio_write(__writeq, "q", unsigned long, "r", ) #endif +#define ARCH_HAS_VALID_PHYS_ADDR_RANGE +extern int valid_phys_addr_range(phys_addr_t addr, size_t size); +extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size); + /** * virt_to_phys- map virtual addresses to physical * @address: address to remap diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index a99679826846..320c6237e1d1 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -174,3 +174,15 @@ const char *arch_vma_name(struct vm_area_struct *vma) return "[mpx]"; return NULL; } + +int valid_phys_addr_range(phys_addr_t addr, size_t count) +{ + return addr + count <= __pa(high_memory); +} + +int valid_mmap_phys_addr_range(unsigned long pfn, size_t count) +{ + phys_addr_t addr = (phys_addr_t)pfn << PAGE_SHIFT; + + return valid_phys_addr_range(addr, count); +} -- 2.15.0.rc1.287.g2b38de12cc-goog
[PATCH] arm64: dts: qcom: msm8916: Shrink mdp address length for msm8916
This shrinks the address size down to 89000 from its previous 9 which was mistakenly pulled from downstream. Signed-off-by: Craig Tatlor --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index dc3817593e14..47262757b09e 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -814,7 +814,7 @@ mdp: mdp@1a01000 { compatible = "qcom,mdp5"; - reg = <0x1a01000 0x9>; + reg = <0x1a01000 0x89000>; reg-names = "mdp_phys"; interrupt-parent = <&mdss>; -- 2.14.1
Re: [PATCH v2 4/4] Staging: Lustre Fix block statement style issue
On Mon, Jul 17, 2017 at 05:44:59PM +, Dilger, Andreas wrote: > On Jul 12, 2017, at 03:03, Craig Inches wrote: > > > > This fixes a block statement which didnt end with */ > > > > Signed-off-by: Craig Inches > > --- > > drivers/staging/lustre/include/linux/lnet/socklnd.h | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h > > b/drivers/staging/lustre/include/linux/lnet/socklnd.h > > index dd5bc0e46560..a1ae66ede7a8 100644 > > --- a/drivers/staging/lustre/include/linux/lnet/socklnd.h > > +++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h > > @@ -76,7 +76,8 @@ struct ksock_msg { > > __u64 ksm_zc_cookies[2]; /* Zero-Copy request/ACK cookie */ > > union { > > struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if > > - * it's NOOP */ > > + * it's NOOP > > + */ > > Rather than making the multi-line comments even more space consuming (I'm not > a big > fan of "*/ must be on a line by itself" since it wastes a lot of vertical > space), > I'd prefer to just shorten the comment, if possible, like: > > struct ksock_lnet_msg lnetmsg; /* lnet message, empty if NOOP */ That makes sense, I believe the series has already made it to staging-next, so not sure what the process would be to fix it up. I am doing another set of style fixes which I can include this change aswell. Cheers, Craig
[PATCH v2 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h
This fixes multiple block statements found not to match style as per checkpatch Signed-off-by: Craig Inches --- drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 + 1 file changed, 81 insertions(+), 48 deletions(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h b/drivers/staging/lustre/include/linux/lnet/lnetst.h index ea736f8d5231..a4f9ff01d458 100644 --- a/drivers/staging/lustre/include/linux/lnet/lnetst.h +++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h @@ -54,7 +54,8 @@ #define LSTIO_GROUP_ADD0xC10 /* add group */ #define LSTIO_GROUP_LIST 0xC11 /* list all groups in session */ #define LSTIO_GROUP_INFO 0xC12 /* query default information of -* specified group */ +* specified group +*/ #define LSTIO_GROUP_DEL0xC13 /* delete group */ #define LSTIO_NODES_ADD0xC14 /* add nodes to specified group */ #define LSTIO_GROUP_UPDATE 0xC15 /* update group */ @@ -102,27 +103,32 @@ struct lstcon_test_ent { int tse_type; /* test type */ int tse_loop; /* loop count */ int tse_concur; /* concurrency of test */ -}; /*** test summary entry, for -*** list_batch command */ +}; /* test summary entry, for +* list_batch command +*/ struct lstcon_batch_ent { int bae_state; /* batch status */ int bae_timeout;/* batch timeout */ int bae_ntest; /* # of tests in the batch */ -}; /*** batch summary entry, for -*** list_batch command */ +}; /* batch summary entry, for +* list_batch command +*/ struct lstcon_test_batch_ent { struct lstcon_ndlist_ent tbe_cli_nle; /* client (group) node_list -* entry */ +* entry +*/ struct lstcon_ndlist_ent tbe_srv_nle; /* server (group) node_list -* entry */ +* entry +*/ union { struct lstcon_test_ent tbe_test; /* test entry */ struct lstcon_batch_ent tbe_batch;/* batch entry */ } u; -}; /*** test/batch verbose information entry, -*** for list_batch command */ +}; /* test/batch verbose information entry, +* for list_batch command +*/ struct lstcon_rpc_ent { struct list_headrpe_link; /* link chain */ @@ -138,10 +144,10 @@ struct lstcon_rpc_ent { }; struct lstcon_trans_stat { - int trs_rpc_stat[4];/* RPCs stat (0: total - 1: failed - 2: finished - 4: reserved */ + int trs_rpc_stat[4];/* RPCs stat (0: total 1: failed +* 2: finished +* 4: reserved +*/ int trs_rpc_errno; /* RPC errno */ int trs_fwk_stat[8];/* framework stat */ int trs_fwk_errno; /* errno of the first remote error */ @@ -275,22 +281,28 @@ struct lstio_session_end_args { struct lstio_debug_args { int lstio_dbg_key; /* IN: session key */ int lstio_dbg_type;/* IN: debug - session|batch| - group|nodes - list */ +* session|batch| +* group|nodes list +*/ int lstio_dbg_flags; /* IN: reserved debug - flags */ +* flags +*/ int lstio_dbg_timeout; /* IN: timeout of - debug
[PATCH v2 2/4] Staging: Lustre Fix up multiple Block Comments in lib-types.h
This patch fixes some multiline comment blocks which didnt conform to the style guide, found by checkpatch. Signed-off-by: Craig Inches --- .../staging/lustre/include/linux/lnet/lib-types.h | 46 ++ 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h b/drivers/staging/lustre/include/linux/lnet/lib-types.h index 321752dfe58b..ddb808ed5d0b 100644 --- a/drivers/staging/lustre/include/linux/lnet/lib-types.h +++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h @@ -308,9 +308,11 @@ struct lnet_rc_data { struct lnet_peer { struct list_head lp_hashlist; /* chain on peer hash */ struct list_head lp_txq;/* messages blocking for - tx credits */ +* tx credits +*/ struct list_head lp_rtrq; /* messages blocking for - router credits */ +* router credits +*/ struct list_head lp_rtr_list; /* chain on router list */ int lp_txcredits; /* # tx credits available */ int lp_mintxcredits; /* low water mark */ @@ -319,23 +321,31 @@ struct lnet_peer { unsigned int lp_alive:1; /* alive/dead? */ unsigned int lp_notify:1; /* notification outstanding? */ unsigned int lp_notifylnd:1;/* outstanding notification - for LND? */ +* for LND? +*/ unsigned int lp_notifying:1; /* some thread is handling - notification */ + * notification + */ unsigned int lp_ping_notsent;/* SEND event outstanding - from ping */ + * from ping + */ int lp_alive_count; /* # times router went - dead<->alive */ - long lp_txqnob; /* bytes queued for sending */ + * dead<->alive + */ + long lp_txqnob; /* ytes queued for sending */ unsigned longlp_timestamp; /* time of last aliveness - news */ + * news + */ unsigned longlp_ping_timestamp;/* time of last ping - attempt */ + * attempt + */ unsigned longlp_ping_deadline; /* != 0 if ping reply - expected */ + * expected + */ unsigned longlp_last_alive; /* when I was last alive */ unsigned longlp_last_query; /* when lp_ni was queried - last time */ +* last time +*/ struct lnet_ni *lp_ni; /* interface peer is on */ lnet_nid_t lp_nid;/* peer's NID */ int lp_refcount; /* # refs */ @@ -386,7 +396,8 @@ struct lnet_route { struct lnet_remotenet { struct list_headlrn_list; /* chain on - ln_remote_nets_hash */ +* ln_remote_nets_hash +*/ struct list_headlrn_routes; /* routes to me */ __u32 lrn_net;/* my net number */ }; @@ -399,14 +410,16 @@ struct lnet_remotenet { struct lnet_rtrbufpool { struct list_headrbp_bufs; /* my free buffer pool */ struct list_headrbp_msgs; /* messages blocking - for a buffer */ +* for a buffer +*/ int
[PATCH v2 4/4] Staging: Lustre Fix block statement style issue
This fixes a block statement which didnt end with */ Signed-off-by: Craig Inches --- drivers/staging/lustre/include/linux/lnet/socklnd.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h b/drivers/staging/lustre/include/linux/lnet/socklnd.h index dd5bc0e46560..a1ae66ede7a8 100644 --- a/drivers/staging/lustre/include/linux/lnet/socklnd.h +++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h @@ -76,7 +76,8 @@ struct ksock_msg { __u64 ksm_zc_cookies[2]; /* Zero-Copy request/ACK cookie */ union { struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if - * it's NOOP */ + * it's NOOP + */ } WIRE_ATTR ksm_u; } WIRE_ATTR; -- 2.13.0
[PATCH v2 1/4] Staging: Lustre Clean up line over 80Char in lib-lnet.h
This patch fixes a warning generated by checkpatch for a line over 80 characters. Signed-off-by: Craig Inches --- drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h index 8ae7423b4543..f534115d402a 100644 --- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h +++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h @@ -453,7 +453,8 @@ extern int portal_rotor; int lnet_lib_init(void); void lnet_lib_exit(void); -int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, unsigned long when); +int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, + unsigned long when); void lnet_notify_locked(struct lnet_peer *lp, int notifylnd, int alive, unsigned long when); int lnet_add_route(__u32 net, __u32 hops, lnet_nid_t gateway_nid, -- 2.13.0
[PATCH v2 0/4] Staging: Lustre Style Fixes
This series fixes a few style issues in lustre. All where picked up by checkpatch. v2 Changes: - Fixed typo in patch subject s/luster/lustre/ Craig Inches (4): Staging: Lustre Clean up line over 80Char in lib-lnet.h Staging: Lustre Fix up multiple Block Comments in lib-types.h Staging: Lustre Fixing multiline block comments in lnetst.h Staging: Lustre Fix block statement style issue .../staging/lustre/include/linux/lnet/lib-lnet.h | 3 +- .../staging/lustre/include/linux/lnet/lib-types.h | 46 +--- drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 + .../staging/lustre/include/linux/lnet/socklnd.h| 3 +- 4 files changed, 115 insertions(+), 66 deletions(-) -- 2.13.0
[PATCH 2/4] Staging: Lustre Fix up multiple Block Comments in lib-types.h
This patch fixes some multiline comment blocks which didnt conform to the style guide, found by checkpatch. Signed-off-by: Craig Inches --- .../staging/lustre/include/linux/lnet/lib-types.h | 46 ++ 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h b/drivers/staging/lustre/include/linux/lnet/lib-types.h index 321752dfe58b..ddb808ed5d0b 100644 --- a/drivers/staging/lustre/include/linux/lnet/lib-types.h +++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h @@ -308,9 +308,11 @@ struct lnet_rc_data { struct lnet_peer { struct list_head lp_hashlist; /* chain on peer hash */ struct list_head lp_txq;/* messages blocking for - tx credits */ +* tx credits +*/ struct list_head lp_rtrq; /* messages blocking for - router credits */ +* router credits +*/ struct list_head lp_rtr_list; /* chain on router list */ int lp_txcredits; /* # tx credits available */ int lp_mintxcredits; /* low water mark */ @@ -319,23 +321,31 @@ struct lnet_peer { unsigned int lp_alive:1; /* alive/dead? */ unsigned int lp_notify:1; /* notification outstanding? */ unsigned int lp_notifylnd:1;/* outstanding notification - for LND? */ +* for LND? +*/ unsigned int lp_notifying:1; /* some thread is handling - notification */ + * notification + */ unsigned int lp_ping_notsent;/* SEND event outstanding - from ping */ + * from ping + */ int lp_alive_count; /* # times router went - dead<->alive */ - long lp_txqnob; /* bytes queued for sending */ + * dead<->alive + */ + long lp_txqnob; /* ytes queued for sending */ unsigned longlp_timestamp; /* time of last aliveness - news */ + * news + */ unsigned longlp_ping_timestamp;/* time of last ping - attempt */ + * attempt + */ unsigned longlp_ping_deadline; /* != 0 if ping reply - expected */ + * expected + */ unsigned longlp_last_alive; /* when I was last alive */ unsigned longlp_last_query; /* when lp_ni was queried - last time */ +* last time +*/ struct lnet_ni *lp_ni; /* interface peer is on */ lnet_nid_t lp_nid;/* peer's NID */ int lp_refcount; /* # refs */ @@ -386,7 +396,8 @@ struct lnet_route { struct lnet_remotenet { struct list_headlrn_list; /* chain on - ln_remote_nets_hash */ +* ln_remote_nets_hash +*/ struct list_headlrn_routes; /* routes to me */ __u32 lrn_net;/* my net number */ }; @@ -399,14 +410,16 @@ struct lnet_remotenet { struct lnet_rtrbufpool { struct list_headrbp_bufs; /* my free buffer pool */ struct list_headrbp_msgs; /* messages blocking - for a buffer */ +* for a buffer +*/ int
[PATCH 1/4] Staging: Luster: Clean up line over 80Char in lib-lnet.h
This patch fixes a warning generated by checkpatch for a line over 80 characters. Signed-off-by: Craig Inches --- drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h index 8ae7423b4543..f534115d402a 100644 --- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h +++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h @@ -453,7 +453,8 @@ extern int portal_rotor; int lnet_lib_init(void); void lnet_lib_exit(void); -int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, unsigned long when); +int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, + unsigned long when); void lnet_notify_locked(struct lnet_peer *lp, int notifylnd, int alive, unsigned long when); int lnet_add_route(__u32 net, __u32 hops, lnet_nid_t gateway_nid, -- 2.13.0