| Message ID | 20170131102114.25085-2-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Andy Gross |
| Headers | show |
On Tue 31 Jan 02:21 PST 2017, Linus Walleij wrote: > This adds the Capella CM3605 ambient light and proximity sensor > to the APQ8060 DragonBoard device tree. Notice that we also set > up pin config for the AOUT line and GPIO lines, and that we set > the default trigger on the infrared LED to associate with the > "cm3605" trigger so the IR LED is controlled by this the CM3605 > driver. Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> [..] > + mpps@50 { > + dragon_cm3605_mpps: cm3605-mpps { > + pinconf { > + pins = "mpp5"; > + function = "analog"; > + input-enable; > + bias-high-impedance; > + /* Let's use channel 5 */ > + qcom,amux-route = <PMIC_MPP_AMUX_ROUTE_CH5>; Unrelated to this patch, I did look at how this works on later devices. It seems like we want to be able to switch the amux-route depending on which ADC "channel" we're querying - e.g. on DB820c we have thermistors on 3 different AMUX inputs but we don't have 3 mpps available. Any thoughts on how to deal with this? > + power-source = <PM8058_GPIO_S3>; > + }; > + }; > + }; Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Feb 1, 2017 at 7:36 PM, Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Tue 31 Jan 02:21 PST 2017, Linus Walleij wrote: >> + /* Let's use channel 5 */ >> + qcom,amux-route = <PMIC_MPP_AMUX_ROUTE_CH5>; > > Unrelated to this patch, I did look at how this works on later devices. > It seems like we want to be able to switch the amux-route depending on > which ADC "channel" we're querying - e.g. on DB820c we have thermistors > on 3 different AMUX inputs but we don't have 3 mpps available. > > Any thoughts on how to deal with this? The AMUX is just one big mystery to me, it's one of those areas where I think a real datasheet would be extremely helpful. In absence of datasheet, maybe a piece of ASCII art illustrating the muxes in the device tree binding docs or so, written by someone who understand it. In absence of any written sources, maybe hearsay, rumors, palimpsest... hehe. I'd seriously like to know how this is engineered. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri 03 Feb 05:05 PST 2017, Linus Walleij wrote: > On Wed, Feb 1, 2017 at 7:36 PM, Bjorn Andersson > <bjorn.andersson@linaro.org> wrote: > > On Tue 31 Jan 02:21 PST 2017, Linus Walleij wrote: > > >> + /* Let's use channel 5 */ > >> + qcom,amux-route = <PMIC_MPP_AMUX_ROUTE_CH5>; > > > > Unrelated to this patch, I did look at how this works on later devices. > > It seems like we want to be able to switch the amux-route depending on > > which ADC "channel" we're querying - e.g. on DB820c we have thermistors > > on 3 different AMUX inputs but we don't have 3 mpps available. > > > > Any thoughts on how to deal with this? > > The AMUX is just one big mystery to me, it's one of those areas where I > think a real datasheet would be extremely helpful. > After additional research and a long chat with Stephen this is what I have come up with. On PM8058 you have 16 AMUX channels that can be either read as raw, scaled or dived by 3, this is selected by the 2 "premux" bits in the AMUX selector register. AMUX channel 5-9 are called MPP5-9, connected to a switching matrix so each MPP is configured to output its signal on one of the 5 mpp-amux-channels. I.e. it's probably better to rename these just "AMUX5" through "AMXU9". On PM8921 this changes somewhat and an additional mux is introduced. The first premux looks similar to pm8058, but with no direct MPP AMUXes to be selected. Premux 1 or 2 is used to select the second level mux. This mux has channels: 1: usb_sns 2: dcin_sns 3: amux3 (reserved and called pa_therm) 4: amux4 (reserved and called amux_in) 5-8: amuxX (as configured output of MPPs) Premux 2 has the same set of channels, but with a divisor of 3. The MPP1/MPP2 AMUX channels in premux 0 found downstream are now reserved - likely they the hardware used to select unity and div/3 input from the second level mux. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 9, 2017 at 2:42 AM, Bjorn Andersson <bjorn.andersson@linaro.org> wrote: >> The AMUX is just one big mystery to me, it's one of those areas where I >> think a real datasheet would be extremely helpful. >> > > After additional research and a long chat with Stephen this is what I > have come up with. > > On PM8058 you have 16 AMUX channels that can be either read as raw, > scaled or dived by 3, this is selected by the 2 "premux" bits in the > AMUX selector register. > > AMUX channel 5-9 are called MPP5-9, > connected to a switching matrix so each MPP is configured to output its > signal on one of the 5 mpp-amux-channels. I.e. it's probably better to > rename these just "AMUX5" through "AMXU9". Awesome, that part is encoded into the next iteration of the driver. > On PM8921 this changes somewhat and an additional mux is introduced. > The first premux looks similar to pm8058, but with no direct MPP AMUXes > to be selected. Premux 1 or 2 is used to select the second level mux. > > This mux has channels: > 1: usb_sns > 2: dcin_sns > 3: amux3 (reserved and called pa_therm) > 4: amux4 (reserved and called amux_in) > 5-8: amuxX (as configured output of MPPs) > > Premux 2 has the same set of channels, but with a divisor of 3. > > The MPP1/MPP2 AMUX channels in premux 0 found downstream are now > reserved - likely they the hardware used to select unity and div/3 input > from the second level mux. That is some serious silicon duct tape work going on here... OK I am trying to accomodate it, but I will likely need verification on real hardware making use of the premuxed thingies. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts index c04960371c5e..f3bd65e284ee 100644 --- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts +++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts @@ -23,6 +23,7 @@ #include <dt-bindings/input/input.h> #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h> +#include <dt-bindings/pinctrl/qcom,pmic-mpp.h> #include "qcom-msm8660.dtsi" / { @@ -83,6 +84,25 @@ }; }; + /* + * Capella CM3605 light and proximity sensor mounted directly + * on the sensor board. + */ + cm3605 { + compatible = "capella,cm3605"; + vdd-supply = <&pm8058_l14>; // 2.85V + aset-gpios = <&pm8058_gpio 35 GPIO_ACTIVE_LOW>; + capella,aset-resistance-ohms = <100000>; + /* GPIO34 has interrupt 225 on the PM8058 */ + /* Trig on both edges - getting close or far away */ + interrupts-extended = <&pm8058 225 IRQ_TYPE_EDGE_BOTH>; + /* MPP05 analog input to the XOADC */ + io-channels = <&xoadc 0x05>; + io-channel-names = "aout"; + pinctrl-names = "default"; + pinctrl-0 = <&dragon_cm3605_gpios>, <&dragon_cm3605_mpps>; + }; + soc { pinctrl@800000 { /* eMMMC pins, all 8 data lines connected */ @@ -317,6 +337,24 @@ power-source = <PM8058_GPIO_S3>; }; }; + dragon_cm3605_gpios: cm3605-gpios { + /* Pin 34 connected to the proxy IRQ */ + pinconf_gpio34 { + pins = "gpio34"; + function = "normal"; + input-enable; + bias-disable; + power-source = <PM8058_GPIO_S3>; + }; + /* Pin 35 connected to ASET */ + pinconf_gpio35 { + pins = "gpio35"; + function = "normal"; + output-high; + bias-disable; + power-source = <PM8058_GPIO_S3>; + }; + }; dragon_veth_gpios: veth-gpios { pinconf { pins = "gpio40"; @@ -327,6 +365,20 @@ }; }; + mpps@50 { + dragon_cm3605_mpps: cm3605-mpps { + pinconf { + pins = "mpp5"; + function = "analog"; + input-enable; + bias-high-impedance; + /* Let's use channel 5 */ + qcom,amux-route = <PMIC_MPP_AMUX_ROUTE_CH5>; + power-source = <PM8058_GPIO_S3>; + }; + }; + }; + xoadc@197 { /* Reference voltage 2.2 V */ xoadc-ref-supply = <&pm8058_l18>; @@ -367,6 +419,7 @@ reg = <0x48>; label = "pm8058:infrared:proximitysensor"; default-state = "off"; + linux,default-trigger = "cm3605"; }; led@131 { compatible = "qcom,pm8058-led";
This adds the Capella CM3605 ambient light and proximity sensor to the APQ8060 DragonBoard device tree. Notice that we also set up pin config for the AOUT line and GPIO lines, and that we set the default trigger on the infrared LED to associate with the "cm3605" trigger so the IR LED is controlled by this the CM3605 driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- Andy: these bindings have been merged to the IIO tree and ACKed by DT maintainers. --- arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)