* [PATCH renesas/devel 0/2] ARM: Enable r8a774[35] SoCs in defconfigs
From: Simon Horman @ 2016-12-06 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series enables recently added r8a7743 (RZ/G1M) and r8a7745
(RZ/G1E) SoCs in relevant defconfigs.
Based on renesas-devel-20161206-v4.9-rc8
Simon Horman (2):
ARM: shmobile: defconfig: Enable r8a774[35] SoCs
ARM: multi_v7_defconfig: Enable r8a774[35] SoCs
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/shmobile_defconfig | 2 ++
2 files changed, 4 insertions(+)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs
From: Simon Horman @ 2016-12-06 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031173-18600-1-git-send-email-horms+renesas@verge.net.au>
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/configs/shmobile_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index b66e17aec058..760688aa5c79 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -14,6 +14,8 @@ CONFIG_ARCH_EMEV2=y
CONFIG_ARCH_R7S72100=y
CONFIG_ARCH_R8A73A4=y
CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
CONFIG_ARCH_R8A7778=y
CONFIG_ARCH_R8A7779=y
CONFIG_ARCH_R8A7790=y
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs
From: Simon Horman @ 2016-12-06 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031173-18600-1-git-send-email-horms+renesas@verge.net.au>
Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 11f37ed1dbff..770e96d61a64 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -87,6 +87,8 @@ CONFIG_ARCH_EMEV2=y
CONFIG_ARCH_R7S72100=y
CONFIG_ARCH_R8A73A4=y
CONFIG_ARCH_R8A7740=y
+CONFIG_ARCH_R8A7743=y
+CONFIG_ARCH_R8A7745=y
CONFIG_ARCH_R8A7778=y
CONFIG_ARCH_R8A7779=y
CONFIG_ARCH_R8A7790=y
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH] serial: mxs-auart: support CMSPAR termios cflag
From: Stefan Wahren @ 2016-12-06 13:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Wolfgang,
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -95,6 +95,7 @@
> #define AUART_LINECTRL_BAUD_DIVFRAC_SHIFT 8
> #define AUART_LINECTRL_BAUD_DIVFRAC_MASK 0x00003f00
> #define AUART_LINECTRL_BAUD_DIVFRAC(v) (((v) & 0x3f) << 8)
> +#define AUART_LINECTRL_SPS (1 << 7)
> #define AUART_LINECTRL_WLEN_MASK 0x00000060
> #define AUART_LINECTRL_WLEN(v) (((v) & 0x3) << 5)
> #define AUART_LINECTRL_FEN (1 << 4)
> @@ -1010,10 +1011,12 @@ static void mxs_auart_settermios(struct uart_port *u,
> ctrl |= AUART_LINECTRL_WLEN(bm);
>
> /* parity */
> - if (cflag & PARENB) {
> + if (cflag & (PARENB|CMSPAR)) {
does it make sense to enable stick parity in case parity is disabled?
The i.MX28 reference manual doesn't describe this case explicit.
Stefan
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3449091.bg2i6Oq5SM@wuerfel>
Am Freitag, den 02.12.2016, 23:11 +0100 schrieb Arnd Bergmann:
> On Friday, December 2, 2016 3:10:13 PM CET Philipp Zabel wrote:
> > Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > > On 2016?12?01? 20:05, Arnd Bergmann wrote:
> > > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > > >> + 0x20 0x10 /* 1: i2c1 */
> > > > >> + 0x20 0x20 /* 2: i2c2 */
> > > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > > >> + };
> > > > >> +
> > > > >> +Specifying reset lines connected to IP modules
> > > > >> +==============================================
> > > > >> +example:
> > > > >> +
> > > > >> + i2c0: i2c at ..... {
> > > > >> + ...
> > > > >> + resets = <&iomcu_rst 0>;
> > > > >> + ...
> > > > >> + };
> > > > > I don't really like this approach, since now the information is
> > > > > in two places. Why not put the data into the reset specifier
> > > > > directly when it is used?
> >
> > From my point of view, with the binding above, all reset controller
> > register/bit layout information is in a single place and can be easily
> > compared to a list in the reference manual, whereas with your suggestion
> > the description of the reset controller register layout is spread
> > throughout one or even several dtsi files.
> > Also, since no two reset controllers are exactly the same, we get a
> > proliferation of different slightly phandle argument meanings.
>
> There is no reason for this to be any different from other subsystems
> that all do it the same way: interrupts, gpios, dma, clk, ... all
> define #foo-cells to be used for addressing uniform things,
> and the data is only in the reference, so that the node that
> describes the controller needs no knowledge of what it's being
> used for.
For most of those bindings the knowledge about which register and bit
position(s) correspond to the handles resides in the driver.
> One exception is the case (often on clk bindings) where the register
> layout is anything but uniform
The register layout is very non-uniform for many reset controllers. Some
share the same register space with some of those clock controllers.
> and every input line has a completely different behavior.
I can't argue that the behavior is non-uniform for the sane reset
controllers though, most of them have just a single bit, for most
of them all reset lines behave the same.
> For that case, we define our own numbering
> system in the driver and hardcode those tables there.
>
> This reset driver does not seem to belong into that category though.
Yes. From what has been shown so far, it seems that in this case, while
the resets are distributed sparsely, the relative layout (set/clear
registers right next to each other) is uniform.
> Even if it did, we putting information about the controller into
> its own node is redundant as the driver already identifies the
> register layout by the compatible string.
Indeed I would prefer the driver to carry the register layout tables
instead of putting this information into the device tree at all.
> > > > Any example, still not understand.
> > > > They are consumer and provider.
> > >
> > > I mean in the i2c node, have
> > >
> > > i2c0: i2c at ..... {
> > > ...
> > > resets = <&iomcu_rst 0x20 0x8>;
> > > ...
> > > }
> >
> > There already are a few drivers that use this, and I fear people having
> > to change their bindings because new flags are needed that have not been
> > previously thought of.
>
> It rarely happens on other subsystems, and the binding can
> always specify different behavior depending on #reset-cells.
I recognize I am biased here. So feel free to ignore this point.
What I'd like to make sure is that we have thought about and are happy
to spread (partial) information about the reset controller register
layout throughout the device tree like this.
regards
Philipp
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205234028.niukdkygbdni5gvm@rob-hp-laptop>
Am Montag, den 05.12.2016, 17:40 -0600 schrieb Rob Herring:
> On Fri, Dec 02, 2016 at 03:10:13PM +0100, Philipp Zabel wrote:
> > Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > > Hi, Arnd
> > > >
> > > > On 2016?12?01? 20:05, Arnd Bergmann wrote:
> > > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > > >> + 0x20 0x10 /* 1: i2c1 */
> > > > >> + 0x20 0x20 /* 2: i2c2 */
> > > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > > >> + };
> > > > >> +
> > > > >> +Specifying reset lines connected to IP modules
> > > > >> +==============================================
> > > > >> +example:
> > > > >> +
> > > > >> + i2c0: i2c at ..... {
> > > > >> + ...
> > > > >> + resets = <&iomcu_rst 0>;
> > > > >> + ...
> > > > >> + };
> > > > > I don't really like this approach, since now the information is
> > > > > in two places. Why not put the data into the reset specifier
> > > > > directly when it is used?
> >
> > From my point of view, with the binding above, all reset controller
> > register/bit layout information is in a single place and can be easily
> > compared to a list in the reference manual, whereas with your suggestion
> > the description of the reset controller register layout is spread
> > throughout one or even several dtsi files.
>
> Which can be solved by tools.
True.
> > Also, since no two reset controllers are exactly the same, we get a
> > proliferation of different slightly phandle argument meanings.
>
> phandle args are supposed to be specific to the phandle it points to.
> Otherwise, we'd never need more than 1 cell and everything could be a
> lookup table.
What I mean is that the clk bindings mostly use <&label index> or
<&label type index> phandles, not <&label register-offset bit-offset>
phandles. Usually the bindings don't spread information about the
register layout of the clock controller throughout the device tree,
because that is contained in the driver, as determined by the compatible
property. I assumed the same should be true for reset controllers, if
possible.
> > > > Any example, still not understand.
> > > > They are consumer and provider.
> > >
> > > I mean in the i2c node, have
> > >
> > > i2c0: i2c at ..... {
> > > ...
> > > resets = <&iomcu_rst 0x20 0x8>;
> > > ...
> > > }
> >
> > There already are a few drivers that use this, and I fear people having
> > to change their bindings because new flags are needed that have not been
> > previously thought of.
>
> Drivers that use what?
Drivers that use <&label register-offset bit-offset> phandles instead of
<&label index> phandles.
regards
Philipp
^ permalink raw reply
* [PATCH v4 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Laurent Pinchart @ 2016-12-06 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481030026-7329-2-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
Thank you for the patch.
On Tuesday 06 Dec 2016 14:13:45 Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 69 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..ca437c1 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -51,6 +51,51 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga-bridge {
> + compatible = "dumb-vga-dac";
Please don't. The board uses a THS8135, which has a few control signals.
They're not used on this board so you can certainly rely on the dumb-vga-dac
driver, but you should not use that compatible string. You should instead add
DT bindings for ti,ths8135 and add that compatible string to the dumb-vga-dac
driver.
The rest looks good to me.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&display_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -236,3 +281,27 @@
> &memctrl {
> status = "okay";
> };
> +
> +&display {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> +};
> +
> +&display_out {
> + display_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-12-06 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WyoTQudydKXnA-8DKvywXXoEOJyV8Vvt5GOBgKXEN+vg@mail.gmail.com>
Hi,
On 05/12/16 17:30, Doug Anderson wrote:
<snip>
>
> AKA: you are setting up various "corecfg" stuff that's documented in
> the generic Arasan docs. Others SDHCI-Arasan implementations might
> want to set the same things, but those values may be stored elsewhere
> for them.
Exactly, that is what I'm trying to find out.
To me, one good place to store this would be DT.
>
> So if _all_ Arasan implementations need these same values or need the
> same logic to figure out these values, then you should do something
> that's not chip-specific but something generic.
>
It depends on where this needs to be set, and why am I the first to need
to set this up.
> If you've got a specific weird quirk that's specific to your platform,
> then you could do that in a chip-specific init.
Yes, or in the set_ios you talked earlier.
>
> Presumably many of the above could just be hardcoded on some
> implementations, so they might not be available in a memory-mapped
> implementation...
>
Exactly.
>
>> which seems much easier to handle (and portable).
>>
>> At any rate, one thing to note from this is that many of these
>> bits should probably be initialised based on DT, right?
>
> Probably, or by proving the voltage value of regulations. Note that I
> think DT already gets parsed and sets up caps. I'm not really an
> expert here and I'd let someone who actually knows / maintains SDMMC
> comment. I know for sure that dw_mmc (which I'm way more familiar
> with) does things very differently than sdhci (which I'm barely
> familiar with).
Thanks.
Could somebody else comment please?
Best regards,
Sebastian
>
>
>> For example, the DT has a "non-removable" property, which I think
>> should be used to setup SLOT_TYPE_EMBEDDED (if the property is
>> present) or SLOT_TYPE_REMOVABLE (if the property is not present)
>>
>> Looking at Documentation/devicetree/bindings/mmc/mmc.txt we can see
>> more related properties:
>>
>> Optional properties:
>> - bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
>> will be <1> if the property is absent.
>> - wp-gpios: Specify GPIOs for write protection, see gpio binding
>> - cd-inverted: when present, polarity on the CD line is inverted. See the note
>> below for the case, when a GPIO is used for the CD line
>> - wp-inverted: when present, polarity on the WP line is inverted. See the note
>> below for the case, when a GPIO is used for the WP line
>> - disable-wp: When set no physical WP line is present. This property should
>> only be specified when the controller has a dedicated write-protect
>> detection logic. If a GPIO is always used for the write-protect detection
>> logic it is sufficient to not specify wp-gpios property in the absence of a WP
>> line.
>> - max-frequency: maximum operating clock frequency
>> - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
>> this system, even if the controller claims it is.
>> - cap-sd-highspeed: SD high-speed timing is supported
>> - cap-mmc-highspeed: MMC high-speed timing is supported
>> - sd-uhs-sdr12: SD UHS SDR12 speed is supported
>> - sd-uhs-sdr25: SD UHS SDR25 speed is supported
>> - sd-uhs-sdr50: SD UHS SDR50 speed is supported
>> - sd-uhs-sdr104: SD UHS SDR104 speed is supported
>> - sd-uhs-ddr50: SD UHS DDR50 speed is supported
>> ...
>>
>> which makes me wonder, what is the recommended way of dealing with this?
>> - Should I use properties on the DT? If so, then I need to add code to set
>> up the register properly.
>> - Should I hardcode these values use a minimal DT? If so, then I need an
>> init function to put all this.
>> - Should I hardcode stuff at u-Boot level? If so, nothing is required and
>> should work without any modifications to the Arasan Linux driver.
>>
>> It appears that the Linux driver is expecting most of these fields to be
>> hardcoded and "pre-set" before (maybe by the bootloader) it starts, hence
>> the lack of any "init" function so far.
>>
>>>
>>> In your platform-specific init you're proposing you could set
>>> tango_pad_mode to 0. That seems tango-specific.
>>>
>>> You'd want to hook into "set_ios" for setting sel_sdio or not. That's
>>> important if anyone ever wants to plug in an external SDIO card to
>>> your slot. This one good argument for putting this in
>>> sdhci_arasan_soc_ctl_map, since you wouldn't want to do a
>>> compatibility matching every time set_ios is called.
>>
>> Thanks for the advice, I will look into that.
>>
>>>
>>> I'd have to look more into the whole SD/WP polarity issue. There are
>>> already so many levels of inversion for these signals in Linux that
>>> it's confusing. It seems like you might just want to hardcode them to
>>> "0" and let users use all the existing ways to invert things... You
>>> could either put that hardcoding into your platform init code or (if
>>> you're using sdhci_arasan_soc_ctl_map) put it in the main init code so
>>> that if anyone else needs to init similar signals then they can take
>>> advantage of it.
>>
>> Yes, I think I will leave them to 0.
>>
>>>
>>> --
>>>
>>> One random side note is that as currently documented you need to
>>> specify a "shift" of -1 for any sdhci_arasan_soc_ctl_map fields you
>>> aren't using. That seems stupid--not sure why I did that. It seems
>>> better to clue off "width = 0" so that you could just freely not init
>>> any fields you don't need.
>>
>> I see.
>> So far I'm not really convinced about using "soc_ctl_map" because what I
>> have so far is more portable, and can easily be put as is somewhere else
>> (i.e.: in different flavors of bootloaders)
>
> Well, most of your parameters are generic corecfg parameters for
> Asasan. Seems like they would fit into the map nicely...
>
> -Doug
>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao@linaro.org>
Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
> Add DT bindings documentation for hi3660 SoC reset controller.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> new file mode 100644
> index 0000000..178e478
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> @@ -0,0 +1,36 @@
> +Hisilicon System Reset Controller
> +======================================
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +The reset controller registers are part of the system-ctl block on
> +hi3660 SoC.
> +
> +Required properties:
> +- compatible: should be
> + "hisilicon,hi3660-reset"
> +- #reset-cells: 2, see below
> +- hisi,rst-syscon: phandle of the reset's syscon.
> +
> +Example:
> + iomcu: iomcu at ffd7e000 {
> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> + };
> +
> + iomcu_rst: iomcu_rst_controller {
> + compatible = "hisilicon,hi3660-reset";
> + hisi,rst-syscon = <&iomcu>;
> + #reset-cells = <2>;
> + };
> +
> +Specifying reset lines connected to IP modules
> +==============================================
> +example:
> +
> + i2c0: i2c at ..... {
> + ...
> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
Should this mention somewhere what register the offset is supposed to
point to? This is the address offset to the set register, with the
corresponding clear register being placed at offset + 4.
> + ...
> + };
regards
Philipp
^ permalink raw reply
* [PATCH 1/2] arm64: PMU: Do not use PMSELR_EL0 to access PMCCFILTR_EL0
From: Will Deacon @ 2016-12-06 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480693859-27249-2-git-send-email-marc.zyngier@arm.com>
On Fri, Dec 02, 2016 at 03:50:58PM +0000, Marc Zyngier wrote:
> The ARMv8 architecture allows the cycle counter to be configured
> by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
> hence accessing PMCCFILTR_EL0. But it disallows the use of
> PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
> PMXEVCNTR_EL0.
>
> Linux itself doesn't violate this rule, but we may end up with
> PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
> guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
> despite the guest not having done anything wrong.
>
> In order to avoid this unfortunate course of events (haha!), let's
> apply the same method armv8pmu_write_counter and co are using,
> explicitely checking for the cycle counter and writing to
> PMCCFILTR_EL0 directly. This prevents writing 0x1f to PMSELR_EL0,
> and saves a Linux guest an extra trap.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kernel/perf_event.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 57ae9d9..a65b757 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -632,7 +632,10 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
>
> static inline void armv8pmu_write_evtype(int idx, u32 val)
> {
> - if (armv8pmu_select_counter(idx) == idx) {
> + if (idx == ARMV8_IDX_CYCLE_COUNTER) {
> + val &= ARMV8_PMU_EVTYPE_MASK & ~ARMV8_PMU_EVTYPE_EVENT;
> + write_sysreg(val, pmccfiltr_el0);
> + } else if (armv8pmu_select_counter(idx) == idx) {
If we go down this route, then we also have to "fix" the 32-bit code,
which uses PMSELR in a similar way. However, neither of the perf drivers
are actually doing anything wrong here -- the problem comes about because
the architecture doesn't guarantee that PMU accesses trap to EL2 unless
both MDCR.TPM=1 *and* PMSELR_EL0 is valid. So I think that this should
be handled together, in the KVM code that enables PMU traps.
Given that the perf callbacks tend to run with preemption disabled, I
think you should be fine nuking PMSELR_EL0 to zero (i.e. no need to
save/restore).
Will
^ permalink raw reply
* [PATCH 1/3] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Linus Walleij @ 2016-12-06 13:50 UTC (permalink / raw)
To: linux-arm-kernel
This adds the device tree bindings for the Qualcomm PM8xxx
ADCs. This is based on the existing DT bindings for the
SPMI ADC so there are hopefully no controversial features.
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
1 file changed, 160 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
new file mode 100644
index 000000000000..6e51e3e74b88
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -0,0 +1,160 @@
+Qualcomm's PM8xxx voltage XOADC
+
+The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Chrystal
+oscillator ADC) encompass PM8018, PM8038, PM8058, PM8917 and PM8921.
+
+Required properties:
+
+- compatible: should be one of:
+ "qcom,pm8018-adc"
+ "qcom,pm8038-adc"
+ "qcom,pm8058-adc"
+ "qcom,pm8917-adc"
+ "qcom,pm8921-adc"
+
+- reg: should contain the ADC base address in the PMIC, typically
+ 0x197.
+
+The following required properties are standard for IO channels, see
+iio-bindings.txt for more details:
+
+- #address-cells: should be set to <1>
+
+- #size-cells: should be set to <0>
+
+- #io-channel-cells: should be set to <1>
+
+- interrupts: should refer to the parent PMIC interrupt controller
+ and reference the proper ADC interrupt.
+
+Required subnodes:
+
+The ADC channels are configured as subnodes of the ADC. Since some of
+them are used for calibrating the ADC, these nodes are compulsory:
+
+ref_625mv {
+ reg = <0x0c>;
+};
+
+ref_1250mv {
+ reg = <0x0d>;
+};
+
+ref_muxoff {
+ reg = <0x0f>;
+};
+
+These three nodes are used for absolute and ratiometric calibration
+and only need to have these reg values: they are by hardware defined
+to be 1:1 ratio converters that sample 625, 1250 and 0 V and create
+an interpolation calibration for all other ADCs.
+
+Optional subnodes: any channels other than channel 0x0c, 0x0d and
+0x0f are optional.
+
+Required channel node properties:
+
+- reg: should contain the hardware channel number in the range
+ 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+
+Optional channel node properties:
+
+- qcom,decimation:
+ Value type: <u32>
+ Definition: This parameter is used to decrease ADC sampling rate.
+ Quicker measurements can be made by reducing decimation ratio.
+ Valid values are 512, 1024, 2048, 4096.
+ If property is not found, default value of 512 will be used.
+
+- qcom,ratiometric:
+ Value type: <empty>
+ Definition: Channel calibration type. If this property is specified
+ VADC will use the VDD reference (1.8V) and GND for channel
+ calibration. If property is not found, channel will be
+ calibrated with 0.625V and 1.25V reference channels, also
+ known as absolute calibration.
+
+- qcom,ratiometric-ref:
+ Value type: <u32>
+ Definition: The reference voltage pair when using ratiometric
+ calibration:
+ 0 = XO_IN/XOADC_GND
+ 1 = PMIC_IN/XOADC_GND
+ 2 = PMIC_IN/BMS_CSP
+ 3 (invalid)
+ 4 = XOADC_GND/XOADC_GND
+ 5 = XOADC_VREF/XOADC_GND
+
+Example:
+
+xoadc: xoadc at 197 {
+ compatible = "qcom,pm8058-adc";
+ reg = <0x197>;
+ interrupt-parent = <&pm8058>;
+ interrupts = <76 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ vcoin {
+ reg = <0x00>;
+ };
+ vbat {
+ reg = <0x01>;
+ };
+ dcin {
+ reg = <0x02>;
+ };
+ ichg {
+ reg = <0x03>;
+ };
+ vph_pwr {
+ reg = <0x04>;
+ };
+ mpp5 {
+ reg = <0x05>;
+ };
+ mpp6 {
+ reg = <0x06>;
+ };
+ mpp7 {
+ reg = <0x07>;
+ };
+ mpp8 {
+ reg = <0x08>;
+ };
+ mpp9 {
+ reg = <0x09>;
+ };
+ usb_vbus {
+ reg = <0x0a>;
+ };
+ die_temp {
+ reg = <0x0b>;
+ };
+ ref_625mv {
+ reg = <0x0c>;
+ };
+ ref_1250mv {
+ reg = <0x0d>;
+ };
+ ref_325mv {
+ reg = <0x0e>;
+ };
+ ref_muxoff {
+ reg = <0x0f>;
+ };
+};
+
+
+/* IIO client node */
+iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&xoadc 0x01>, /* Battery */
+ <&xoadc 0x02>, /* DC in (charger) */
+ <&xoadc 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x0b>, /* Die temperature */
+ <&xoadc 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x0e>; /* Reference voltage 0.325V */
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] iio: adc: break out common code from SPMI VADC
From: Linus Walleij @ 2016-12-06 13:51 UTC (permalink / raw)
To: linux-arm-kernel
The SPMI VADC and the earlier XOADC share a subset of
common code, so to be able to use the same code in both
drivers, we break out a separate file with the common code,
prefix exported functions that are no longer static with
qcom_* and bake an object qcom-vadc.o that contains both
files: qcom-vadc-common.o and qcom-spmi-vadc.o.
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/iio/adc/Makefile | 3 +-
drivers/iio/adc/qcom-spmi-vadc.c | 95 +++-----------------------------------
drivers/iio/adc/qcom-vadc-common.c | 38 +++++++++++++++
drivers/iio/adc/qcom-vadc-common.h | 69 +++++++++++++++++++++++++++
4 files changed, 116 insertions(+), 89 deletions(-)
create mode 100644 drivers/iio/adc/qcom-vadc-common.c
create mode 100644 drivers/iio/adc/qcom-vadc-common.h
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04c311f..f9468d228b1e 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -38,7 +38,8 @@ obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_NAU7802) += nau7802.o
obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
-obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
+qcom-vadc-y := qcom-vadc-common.o
+obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-vadc.o qcom-spmi-vadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
obj-$(CONFIG_STX104) += stx104.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
index c2babe50a0d8..74d21afa34a9 100644
--- a/drivers/iio/adc/qcom-spmi-vadc.c
+++ b/drivers/iio/adc/qcom-spmi-vadc.c
@@ -28,6 +28,8 @@
#include <dt-bindings/iio/qcom,spmi-vadc.h>
+#include "qcom-vadc-common.h"
+
/* VADC register and bit definitions */
#define VADC_REVISION2 0x1
#define VADC_REVISION2_SUPPORTED_VADC 1
@@ -75,69 +77,9 @@
#define VADC_DATA 0x60 /* 16 bits */
-#define VADC_CONV_TIME_MIN_US 2000
-#define VADC_CONV_TIME_MAX_US 2100
-
-/* Min ADC code represents 0V */
-#define VADC_MIN_ADC_CODE 0x6000
-/* Max ADC code represents full-scale range of 1.8V */
-#define VADC_MAX_ADC_CODE 0xa800
-
-#define VADC_ABSOLUTE_RANGE_UV 625000
-#define VADC_RATIOMETRIC_RANGE_UV 1800000
-
-#define VADC_DEF_PRESCALING 0 /* 1:1 */
-#define VADC_DEF_DECIMATION 0 /* 512 */
-#define VADC_DEF_HW_SETTLE_TIME 0 /* 0 us */
-#define VADC_DEF_AVG_SAMPLES 0 /* 1 sample */
-#define VADC_DEF_CALIB_TYPE VADC_CALIB_ABSOLUTE
-
-#define VADC_DECIMATION_MIN 512
-#define VADC_DECIMATION_MAX 4096
-
-#define VADC_HW_SETTLE_DELAY_MAX 10000
-#define VADC_AVG_SAMPLES_MAX 512
-
-#define KELVINMIL_CELSIUSMIL 273150
-
#define VADC_CHAN_MIN VADC_USBIN
#define VADC_CHAN_MAX VADC_LR_MUX3_BUF_PU1_PU2_XO_THERM
-/*
- * VADC_CALIB_ABSOLUTE: uses the 625mV and 1.25V as reference channels.
- * VADC_CALIB_RATIOMETRIC: uses the reference voltage (1.8V) and GND for
- * calibration.
- */
-enum vadc_calibration {
- VADC_CALIB_ABSOLUTE = 0,
- VADC_CALIB_RATIOMETRIC
-};
-
-/**
- * struct vadc_linear_graph - Represent ADC characteristics.
- * @dy: numerator slope to calculate the gain.
- * @dx: denominator slope to calculate the gain.
- * @gnd: A/D word of the ground reference used for the channel.
- *
- * Each ADC device has different offset and gain parameters which are
- * computed to calibrate the device.
- */
-struct vadc_linear_graph {
- s32 dy;
- s32 dx;
- s32 gnd;
-};
-
-/**
- * struct vadc_prescale_ratio - Represent scaling ratio for ADC input.
- * @num: the inverse numerator of the gain applied to the input channel.
- * @den: the inverse denominator of the gain applied to the input channel.
- */
-struct vadc_prescale_ratio {
- u32 num;
- u32 den;
-};
-
/**
* struct vadc_channel_prop - VADC channel property.
* @channel: channel number, refer to the channel list.
@@ -471,33 +413,10 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
static s32 vadc_calibrate(struct vadc_priv *vadc,
const struct vadc_channel_prop *prop, u16 adc_code)
{
- const struct vadc_prescale_ratio *prescale;
- s64 voltage;
-
- voltage = adc_code - vadc->graph[prop->calibration].gnd;
- voltage *= vadc->graph[prop->calibration].dx;
- voltage = div64_s64(voltage, vadc->graph[prop->calibration].dy);
-
- if (prop->calibration == VADC_CALIB_ABSOLUTE)
- voltage += vadc->graph[prop->calibration].dx;
-
- if (voltage < 0)
- voltage = 0;
-
- prescale = &vadc_prescale_ratios[prop->prescale];
-
- voltage = voltage * prescale->den;
-
- return div64_s64(voltage, prescale->num);
-}
-
-static int vadc_decimation_from_dt(u32 value)
-{
- if (!is_power_of_2(value) || value < VADC_DECIMATION_MIN ||
- value > VADC_DECIMATION_MAX)
- return -EINVAL;
-
- return __ffs64(value / VADC_DECIMATION_MIN);
+ return qcom_vadc_calibrate(&vadc_prescale_ratios[prop->prescale],
+ &vadc->graph[prop->calibration],
+ (prop->calibration == VADC_CALIB_ABSOLUTE),
+ adc_code);
}
static int vadc_prescaling_from_dt(u32 num, u32 den)
@@ -752,7 +671,7 @@ static int vadc_get_dt_channel_data(struct device *dev,
ret = of_property_read_u32(node, "qcom,decimation", &value);
if (!ret) {
- ret = vadc_decimation_from_dt(value);
+ ret = qcom_vadc_decimation_from_dt(value);
if (ret < 0) {
dev_err(dev, "%02x invalid decimation %d\n",
chan, value);
diff --git a/drivers/iio/adc/qcom-vadc-common.c b/drivers/iio/adc/qcom-vadc-common.c
new file mode 100644
index 000000000000..f67fc5e2a702
--- /dev/null
+++ b/drivers/iio/adc/qcom-vadc-common.c
@@ -0,0 +1,38 @@
+#include <linux/kernel.h>
+#include <linux/bitops.h>
+#include <linux/math64.h>
+#include <linux/log2.h>
+#include <linux/err.h>
+
+#include "qcom-vadc-common.h"
+
+s32 qcom_vadc_calibrate(const struct vadc_prescale_ratio *prescale,
+ const struct vadc_linear_graph *graph,
+ bool absolute,
+ u16 adc_code)
+{
+ s64 voltage;
+
+ voltage = adc_code - graph->gnd;
+ voltage *= graph->dx;
+ voltage = div64_s64(voltage, graph->dy);
+
+ if (absolute)
+ voltage += graph->dx;
+
+ if (voltage < 0)
+ voltage = 0;
+
+ voltage = voltage * prescale->den;
+
+ return div64_s64(voltage, prescale->num);
+}
+
+int qcom_vadc_decimation_from_dt(u32 value)
+{
+ if (!is_power_of_2(value) || value < VADC_DECIMATION_MIN ||
+ value > VADC_DECIMATION_MAX)
+ return -EINVAL;
+
+ return __ffs64(value / VADC_DECIMATION_MIN);
+}
diff --git a/drivers/iio/adc/qcom-vadc-common.h b/drivers/iio/adc/qcom-vadc-common.h
new file mode 100644
index 000000000000..b41cb501eef8
--- /dev/null
+++ b/drivers/iio/adc/qcom-vadc-common.h
@@ -0,0 +1,69 @@
+/*
+ * Code shared between the different Qualcomm PMIC voltage ADCs
+ */
+
+#define VADC_CONV_TIME_MIN_US 2000
+#define VADC_CONV_TIME_MAX_US 2100
+
+/* Min ADC code represents 0V */
+#define VADC_MIN_ADC_CODE 0x6000
+/* Max ADC code represents full-scale range of 1.8V */
+#define VADC_MAX_ADC_CODE 0xa800
+
+#define VADC_ABSOLUTE_RANGE_UV 625000
+#define VADC_RATIOMETRIC_RANGE_UV 1800000
+
+#define VADC_DEF_PRESCALING 0 /* 1:1 */
+#define VADC_DEF_DECIMATION 0 /* 512 */
+#define VADC_DEF_HW_SETTLE_TIME 0 /* 0 us */
+#define VADC_DEF_AVG_SAMPLES 0 /* 1 sample */
+#define VADC_DEF_CALIB_TYPE VADC_CALIB_ABSOLUTE
+
+#define VADC_DECIMATION_MIN 512
+#define VADC_DECIMATION_MAX 4096
+
+#define VADC_HW_SETTLE_DELAY_MAX 10000
+#define VADC_AVG_SAMPLES_MAX 512
+
+#define KELVINMIL_CELSIUSMIL 273150
+
+/*
+ * VADC_CALIB_ABSOLUTE: uses the 625mV and 1.25V as reference channels.
+ * VADC_CALIB_RATIOMETRIC: uses the reference voltage (1.8V) and GND for
+ * calibration.
+ */
+enum vadc_calibration {
+ VADC_CALIB_ABSOLUTE = 0,
+ VADC_CALIB_RATIOMETRIC
+};
+
+/**
+ * struct vadc_linear_graph - Represent ADC characteristics.
+ * @dy: numerator slope to calculate the gain.
+ * @dx: denominator slope to calculate the gain.
+ * @gnd: A/D word of the ground reference used for the channel.
+ *
+ * Each ADC device has different offset and gain parameters which are
+ * computed to calibrate the device.
+ */
+struct vadc_linear_graph {
+ s32 dy;
+ s32 dx;
+ s32 gnd;
+};
+
+/**
+ * struct vadc_prescale_ratio - Represent scaling ratio for ADC input.
+ * @num: the inverse numerator of the gain applied to the input channel.
+ * @den: the inverse denominator of the gain applied to the input channel.
+ */
+struct vadc_prescale_ratio {
+ u32 num;
+ u32 den;
+};
+
+s32 qcom_vadc_calibrate(const struct vadc_prescale_ratio *prescale,
+ const struct vadc_linear_graph *graph,
+ bool absolute,
+ u16 adc_code);
+int qcom_vadc_decimation_from_dt(u32 value);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] iio: adc: add a driver for Qualcomm PM8xxx HK/XOADC
From: Linus Walleij @ 2016-12-06 13:51 UTC (permalink / raw)
To: linux-arm-kernel
The Qualcomm PM8xxx PMICs contain a simpler ADC than its
successors (already in the kernel as qcom-spmi-adc.c):
the HK/XO ADC (Housekeeping/Chrystal oscillator ADC).
As far as I can understand this is equal to the PMICs
using SSBI transport and encompass PM8018, PM8038,
PM8058, PM8917 and PM8921, so this is shortly named
PM8xxx.
This ADC monitors a bunch of on-board voltages and the die
temperature of the PMIC itself, but it can also be routed
to convert a few external MPPs (multi-purpose pins). On
the APQ8060 DragonBoard this feature is used to let this
ADC convert an analog ALS (Ambient Light Sensor) voltage
signal from a Capella CM3605 ALS into a LUX value.
Developed and tested with APQ8060 DragonBoard based on
Ivan's driver. The SPMI VADC driver is quite different,
but share enough minor functionality that I have split
out to the common file in a previous patch.
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/qcom-pm8xxx-xoadc.c | 755 ++++++++++++++++++++++++++++++++++++
3 files changed, 766 insertions(+)
create mode 100644 drivers/iio/adc/qcom-pm8xxx-xoadc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7edcf3238620..f0b0cbdb9519 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -380,6 +380,16 @@ config PALMAS_GPADC
is used in smartphones and tablets and supports a 16 channel
general purpose ADC.
+config QCOM_PM8XXX_XOADC
+ tristate "Qualcomm SSBI PM8xxx PMIC XOADCs"
+ depends on MFD_PM8XXX
+ help
+ ADC driver for the XOADC portions of the Qualcomm PM8xxx PMICs
+ using SSBI transport: PM8018, PM8038, PM8058, PM8917, PM8921.
+
+ To compile this driver as a module, choose M here: the module
+ will be called qcom-pm8xxx-xoadc.
+
config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index f9468d228b1e..234d45c805f9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
qcom-vadc-y := qcom-vadc-common.o
obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-vadc.o qcom-spmi-vadc.o
+obj-$(CONFIG_QCOM_PM8XXX_XOADC) += qcom-vadc.o qcom-pm8xxx-xoadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
obj-$(CONFIG_STX104) += stx104.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
diff --git a/drivers/iio/adc/qcom-pm8xxx-xoadc.c b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
new file mode 100644
index 000000000000..a045d260715b
--- /dev/null
+++ b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
@@ -0,0 +1,755 @@
+/*
+ * Qualcomm PM8xxx PMIC XOADC driver
+ *
+ * These ADCs are known as HK/XO (house keeping / chrystal oscillator)
+ * "XO" in "XOADC" means Chrystal Oscillator. It's a bunch of
+ * specific-purpose and general purpose ADC converters and channels.
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
+
+#include "qcom-vadc-common.h"
+
+/*
+ * Definitions for the "user processor" registers lifted from the v3.4
+ * Qualcomm tree. Their kernel has two out-of-tree drivers for the ADC:
+ * drivers/misc/pmic8058-xoadc.c
+ * drivers/hwmon/pm8xxx-adc.c
+ * None of them contain any complete register specification, so this is
+ * a best effort of combining the information.
+ */
+
+/* These appear to be "battery monitor" registers */
+#define ADC_ARB_BTM_CNTRL1 0x17e
+#define ADC_ARB_BTM_CNTRL1_EN_BTM BIT(0)
+#define ADC_ARB_BTM_CNTRL1_SEL_OP_MODE BIT(1)
+#define ADC_ARB_BTM_CNTRL1_MEAS_INTERVAL1 BIT(2)
+#define ADC_ARB_BTM_CNTRL1_MEAS_INTERVAL2 BIT(3)
+#define ADC_ARB_BTM_CNTRL1_MEAS_INTERVAL3 BIT(4)
+#define ADC_ARB_BTM_CNTRL1_MEAS_INTERVAL4 BIT(5)
+#define ADC_ARB_BTM_CNTRL1_EOC BIT(6)
+#define ADC_ARB_BTM_CNTRL1_REQ BIT(7)
+
+#define ADC_ARB_BTM_AMUX_CNTRL 0x17f
+#define ADC_ARB_BTM_ANA_PARAM 0x180
+#define ADC_ARB_BTM_DIG_PARAM 0x181
+#define ADC_ARB_BTM_RSV 0x182
+#define ADC_ARB_BTM_DATA1 0x183
+#define ADC_ARB_BTM_DATA0 0x184
+#define ADC_ARB_BTM_BAT_COOL_THR1 0x185
+#define ADC_ARB_BTM_BAT_COOL_THR0 0x186
+#define ADC_ARB_BTM_BAT_WARM_THR1 0x187
+#define ADC_ARB_BTM_BAT_WARM_THR0 0x188
+#define ADC_ARB_BTM_CNTRL2 0x18c
+
+/* Proper ADC registers */
+
+#define ADC_ARB_USRP_CNTRL 0x197
+#define ADC_ARB_USRP_CNTRL_EN_ARB BIT(0)
+#define ADC_ARB_USRP_CNTRL_RSV1 BIT(1)
+#define ADC_ARB_USRP_CNTRL_RSV2 BIT(2)
+#define ADC_ARB_USRP_CNTRL_RSV3 BIT(3)
+#define ADC_ARB_USRP_CNTRL_RSV4 BIT(4)
+#define ADC_ARB_USRP_CNTRL_RSV5 BIT(5)
+#define ADC_ARB_USRP_CNTRL_EOC BIT(6)
+#define ADC_ARB_USRP_CNTRL_REQ BIT(7)
+
+#define ADC_ARB_USRP_AMUX_CNTRL 0x198
+#define ADC_ARB_USRP_AMUX_CNTRL_RSV0 BIT(0)
+#define ADC_ARB_USRP_AMUX_CNTRL_RSV1 BIT(1)
+#define ADC_ARB_USRP_AMUX_CNTRL_PREMUX0 BIT(2)
+#define ADC_ARB_USRP_AMUX_CNTRL_PREMUX1 BIT(3)
+#define ADC_ARB_USRP_AMUX_CNTRL_SEL0 BIT(4)
+#define ADC_ARB_USRP_AMUX_CNTRL_SEL1 BIT(5)
+#define ADC_ARB_USRP_AMUX_CNTRL_SEL2 BIT(6)
+#define ADC_ARB_USRP_AMUX_CNTRL_SEL3 BIT(7)
+#define ADC_AMUX_PREMUX_SHIFT 2
+#define ADC_AMUX_SEL_SHIFT 4
+
+/* We know very little about the bits in this register */
+#define ADC_ARB_USRP_ANA_PARAM 0x199
+#define ADC_ARB_USRP_ANA_PARAM_DIS 0xFE
+#define ADC_ARB_USRP_ANA_PARAM_EN 0xFF
+
+#define ADC_ARB_USRP_DIG_PARAM 0x19A
+#define ADC_ARB_USRP_DIG_PARAM_SEL_SHIFT0 BIT(0)
+#define ADC_ARB_USRP_DIG_PARAM_SEL_SHIFT1 BIT(1)
+#define ADC_ARB_USRP_DIG_PARAM_CLK_RATE0 BIT(2)
+#define ADC_ARB_USRP_DIG_PARAM_CLK_RATE1 BIT(3)
+#define ADC_ARB_USRP_DIG_PARAM_EOC BIT(4)
+/*
+ * On a later ADC the decimation factors are defined as
+ * 00 = 512, 01 = 1024, 10 = 2048, 11 = 4096 so assume this
+ * holds also for this older XOADC.
+ */
+#define ADC_ARB_USRP_DIG_PARAM_DEC_RATE0 BIT(5)
+#define ADC_ARB_USRP_DIG_PARAM_DEC_RATE1 BIT(6)
+#define ADC_ARB_USRP_DIG_PARAM_EN BIT(7)
+#define ADC_DIG_PARAM_DEC_SHIFT 5
+
+#define ADC_ARB_USRP_RSV 0x19B
+#define ADC_ARB_USRP_RSV_RST BIT(0)
+#define ADC_ARB_USRP_RSV_DTEST0 BIT(1)
+#define ADC_ARB_USRP_RSV_DTEST1 BIT(2)
+#define ADC_ARB_USRP_RSV_OP BIT(3)
+#define ADC_ARB_USRP_RSV_IP_SEL0 BIT(4)
+#define ADC_ARB_USRP_RSV_IP_SEL1 BIT(5)
+#define ADC_ARB_USRP_RSV_IP_SEL2 BIT(6)
+#define ADC_ARB_USRP_RSV_TRM BIT(7)
+#define ADC_RSV_IP_SEL_SHIFT 4
+
+#define ADC_ARB_USRP_DATA0 0x19D
+#define ADC_ARB_USRP_DATA1 0x19C
+
+/* Physical channels. MPP = Multi-Purpose Pin */
+#define CHANNEL_VCOIN 0x0 /* Coincell */
+#define CHANNEL_VBAT 0x1 /* Battery voltage */
+#define CHANNEL_VCHG 0x2 /* Charger voltage */
+#define CHANNEL_CHG_MONITOR 0x3 /* Charger current monitor */
+#define CHANNEL_VPH_PWR 0x4 /* Main system power VPH */
+#define CHANNEL_MPP5 0x5 /* "Battery charge current" */
+#define CHANNEL_MPP6 0x6 /* "MPP1" */
+#define CHANNEL_MPP7 0x7 /* "MPP2" */
+#define CHANNEL_MPP8 0x8 /* Battery temperature */
+#define CHANNEL_MPP9 0x9 /* Battery detection */
+#define CHANNEL_USB_VBUS 0xa /* USB charger voltage */
+#define CHANNEL_DIE_TEMP 0xb /* PMIC die temperature */
+#define CHANNEL_INTERNAL 0xc /* 625mV reference channel */
+#define CHANNEL_125V 0xd /* 1.25V reference channel */
+#define CHANNEL_INTERNAL_2 0xe /* Charger temperature */
+#define CHANNEL_MUXOFF 0xf /* Channel to reduce input load on mux */
+
+#define XOADC_CHAN_MAX 15 /* 4 bits */
+
+/* MPP = Multi-Purpose Pins */
+#define PREMUX_MPP_SCALE_0 0x0 /* No scaling on the signal */
+#define PREMUX_MPP_SCALE_1 0x1 /* Unity scaling selected by the user */
+#define PREMUX_MPP_SCALE_1_DIV3 0x2 /* 1/3 prescaler on the input from MPP */
+
+/* Defines reference voltage for the XOADC */
+#define AMUX_RSV0 0x0 /* XO_IN/XOADC_GND */
+#define AMUX_RSV1 0x1 /* PMIC_IN/XOADC_GND */
+#define AMUX_RSV2 0x2 /* PMIC_IN/BMS_CSP */
+#define AMUX_RSV3 0x3 /* not used */
+#define AMUX_RSV4 0x4 /* XOADC_GND/XOADC_GND */
+#define AMUX_RSV5 0x5 /* XOADC_VREF/XOADC_GND */
+#define XOADC_RSV_MAX 5 /* 3 bits 0..7, 3 and 6,7 are invalid */
+
+/*
+ * The different channels have hard-coded prescale ratios defined
+ * by the hardware.
+ */
+static const struct vadc_prescale_ratio adc_prescale_ratios[] = {
+ { .num = 1, .den = 2 }, /* CHANNEL_VCOIN */
+ { .num = 1, .den = 3 }, /* CHANNEL_VBAT */
+ { .num = 1, .den = 10 }, /* CHANNEL_VCHG */
+ { .num = 1, .den = 1 }, /* CHANNEL_CHG_MONITOR */
+ { .num = 1, .den = 3 }, /* CHANNEL_VPH_PWR */
+ { .num = 1, .den = 1 }, /* CHANNEL_MPP5 */
+ { .num = 1, .den = 1 }, /* CHANNEL_MPP6 */
+ { .num = 1, .den = 2 }, /* CHANNEL_MPP7 */
+ { .num = 1, .den = 2 }, /* CHANNEL_MPP8 */
+ { .num = 1, .den = 3 }, /* CHANNEL_MPP9 */
+ { .num = 1, .den = 3 }, /* CHANNEL_USB_VBUS */
+ { .num = 1, .den = 1 }, /* CHANNEL_DIE_TEMP */
+ { .num = 1, .den = 1 }, /* CHANNEL_INTERNAL */
+ { .num = 1, .den = 1 }, /* CHANNEL_125V */
+ { .num = 1, .den = 1 }, /* CHANNEL_INTERNAL_2 */
+ { .num = 1, .den = 1 }, /* CHANNEL_MUXOFF */
+};
+
+/**
+ * struct pm8xxx_chan_info - ADC channel information
+ * @name: name of this channel
+ * @calibration: whether to use absolute or ratiometric calibration
+ * @amux_channel: channel 0..15
+ * @decimation: 0,1,2,3
+ * @amux_mpp_channel: MPP channel 0..3
+ * @amux_ip_rsv: ratiometric scale value if using ratiometric
+ * calibration: 0, 1, 2, 4, 5.
+ */
+struct pm8xxx_chan_info {
+ const char *name;
+ enum vadc_calibration calibration;
+ u8 amux_channel:4;
+ u8 decimation:2;
+ u8 amux_mpp_channel:2;
+ u8 amux_ip_rsv:3;
+};
+
+/**
+ * struct pm8xxx_xoadc - state container for the XOADC
+ * @dev: pointer to device
+ * @map: regmap to access registers
+ * @vref: reference voltage regulator
+ * @nchans: number of channels
+ * @chans: the channel information per-channel
+ * @iio_chans: IIO channel specifiers
+ * @graph: linear calibration parameters for absolute and
+ * ratiometric measurements
+ * @complete: completion to indicate end of conversion
+ */
+struct pm8xxx_xoadc {
+ struct device *dev;
+ struct regmap *map;
+ struct regulator *vref;
+ unsigned int nchans;
+ struct pm8xxx_chan_info *chans;
+ struct iio_chan_spec *iio_chans;
+ struct vadc_linear_graph graph[2];
+ struct completion complete;
+};
+
+static irqreturn_t pm8xxx_eoc_irq(int irq, void *d)
+{
+ struct iio_dev *indio_dev = d;
+ struct pm8xxx_xoadc *adc = iio_priv(indio_dev);
+
+ complete(&adc->complete);
+
+ return IRQ_HANDLED;
+}
+
+static struct pm8xxx_chan_info *
+pm8xxx_get_channel(struct pm8xxx_xoadc *adc, u8 chan)
+{
+ struct pm8xxx_chan_info *ch;
+ int i;
+
+ if (chan >= adc->nchans)
+ return NULL;
+
+ for (i = 0; i < adc->nchans; i++) {
+ ch = &adc->chans[i];
+ if (ch->amux_channel == chan)
+ break;
+ }
+ if (i == adc->nchans)
+ return NULL;
+
+ return ch;
+}
+
+static int pm8xxx_read_channel_rsv(struct pm8xxx_xoadc *adc,
+ const struct pm8xxx_chan_info *ch,
+ u8 rsv, u16 *adc_code)
+{
+ int ret;
+ unsigned int val;
+ u8 rsvmask, rsvval;
+ u8 lsb, msb;
+
+ dev_dbg(adc->dev, "read channel \"%s\", amux %d, mpp %d, rsv %d\n",
+ ch->name, ch->amux_channel, ch->amux_mpp_channel, rsv);
+
+ /* Mux in this channel */
+ ret = regmap_write(adc->map, ADC_ARB_USRP_AMUX_CNTRL,
+ ch->amux_channel << ADC_AMUX_SEL_SHIFT |
+ ch->amux_mpp_channel << ADC_AMUX_PREMUX_SHIFT);
+ if (ret)
+ return ret;
+
+ /* Set up ratiometric scale value */
+ rsvmask = (ADC_ARB_USRP_RSV_RST | ADC_ARB_USRP_RSV_DTEST0 |
+ ADC_ARB_USRP_RSV_DTEST1 | ADC_ARB_USRP_RSV_OP);
+ if (ch->calibration == VADC_CALIB_RATIOMETRIC) {
+ if (rsv == 0xff)
+ rsvval = (ch->amux_ip_rsv << ADC_RSV_IP_SEL_SHIFT) |
+ ADC_ARB_USRP_RSV_TRM;
+ else
+ rsvval = (rsv << ADC_RSV_IP_SEL_SHIFT) |
+ ADC_ARB_USRP_RSV_TRM;
+ } else {
+ /* We are not ratiometric so turn this off */
+ rsvval = ADC_ARB_USRP_RSV_IP_SEL1;
+ }
+
+ ret = regmap_update_bits(adc->map,
+ ADC_ARB_USRP_RSV,
+ ~rsvmask,
+ rsvval);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(adc->map, ADC_ARB_USRP_ANA_PARAM,
+ ADC_ARB_USRP_ANA_PARAM_DIS);
+ if (ret)
+ return ret;
+
+ /* Decimation factor */
+ ret = regmap_write(adc->map, ADC_ARB_USRP_DIG_PARAM,
+ ADC_ARB_USRP_DIG_PARAM_SEL_SHIFT0 |
+ ADC_ARB_USRP_DIG_PARAM_SEL_SHIFT1 |
+ ch->decimation << ADC_DIG_PARAM_DEC_SHIFT);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(adc->map, ADC_ARB_USRP_ANA_PARAM,
+ ADC_ARB_USRP_ANA_PARAM_EN);
+ if (ret)
+ return ret;
+
+ /* Enable the arbiter, the Qualcomm code does it twice like this */
+ ret = regmap_write(adc->map, ADC_ARB_USRP_CNTRL,
+ ADC_ARB_USRP_CNTRL_EN_ARB);
+ if (ret)
+ return ret;
+ ret = regmap_write(adc->map, ADC_ARB_USRP_CNTRL,
+ ADC_ARB_USRP_CNTRL_EN_ARB);
+ if (ret)
+ return ret;
+
+
+ /* Fire a request! */
+ reinit_completion(&adc->complete);
+ ret = regmap_write(adc->map, ADC_ARB_USRP_CNTRL,
+ ADC_ARB_USRP_CNTRL_EN_ARB |
+ ADC_ARB_USRP_CNTRL_REQ);
+ if (ret)
+ return ret;
+
+ /* Next the interrupt occurs */
+ ret = wait_for_completion_timeout(&adc->complete,
+ VADC_CONV_TIME_MAX_US);
+ if (!ret) {
+ dev_err(adc->dev, "conversion timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ ret = regmap_read(adc->map, ADC_ARB_USRP_DATA0, &val);
+ if (ret)
+ return ret;
+ lsb = val;
+ ret = regmap_read(adc->map, ADC_ARB_USRP_DATA1, &val);
+ if (ret)
+ return ret;
+ msb = val;
+ *adc_code = (msb << 8) | lsb;
+
+ /* Turn off the ADC by setting the arbiter to 0 twice */
+ ret = regmap_write(adc->map, ADC_ARB_USRP_CNTRL, 0);
+ if (ret)
+ return ret;
+ ret = regmap_write(adc->map, ADC_ARB_USRP_CNTRL, 0);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int pm8xxx_read_channel(struct pm8xxx_xoadc *adc,
+ const struct pm8xxx_chan_info *ch,
+ u16 *adc_code)
+{
+ /*
+ * Normally we just use the ratiometric scale value (RSV) predefined
+ * for the channel, but during calibration we need to modify this
+ * so this wrapper is a helper hiding the more complex version.
+ */
+ return pm8xxx_read_channel_rsv(adc, ch, 0xff, adc_code);
+}
+
+static s32 pm8xxx_calibrate(struct pm8xxx_xoadc *adc,
+ const struct pm8xxx_chan_info *ch,
+ u16 adc_code)
+{
+ return qcom_vadc_calibrate(&adc_prescale_ratios[ch->amux_channel],
+ &adc->graph[ch->calibration],
+ (ch->calibration == VADC_CALIB_ABSOLUTE),
+ adc_code);
+}
+
+static int pm8xxx_calibrate_device(struct pm8xxx_xoadc *adc)
+{
+ const struct pm8xxx_chan_info *ch;
+ u16 read_1250v;
+ u16 read_0625v;
+ u16 read_nomux_rsv5;
+ u16 read_nomux_rsv4;
+ int ret;
+
+
+ adc->graph[VADC_CALIB_ABSOLUTE].dx = VADC_ABSOLUTE_RANGE_UV;
+ adc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE_UV;
+
+ /* Common reference channel calibration */
+ ch = pm8xxx_get_channel(adc, CHANNEL_125V);
+ if (!ch)
+ return -ENODEV;
+ ret = pm8xxx_read_channel(adc, ch, &read_1250v);
+ if (ret) {
+ dev_err(adc->dev, "could not read 1.25V reference channel\n");
+ return -ENODEV;
+ }
+ ch = pm8xxx_get_channel(adc, CHANNEL_INTERNAL);
+ if (!ch)
+ return -ENODEV;
+ ret = pm8xxx_read_channel(adc, ch, &read_0625v);
+ if (ret) {
+ dev_err(adc->dev, "could not read 0.625V reference channel\n");
+ return -ENODEV;
+ }
+ if (read_1250v == read_0625v) {
+ dev_err(adc->dev, "read same ADC code for 1.25V and 0.625V\n");
+ return -ENODEV;
+ }
+
+ adc->graph[VADC_CALIB_ABSOLUTE].dy = read_1250v - read_0625v;
+ adc->graph[VADC_CALIB_ABSOLUTE].gnd = read_0625v;
+
+ dev_info(adc->dev, "absolute calibration dx = %d uV, dy = %d units\n",
+ VADC_ABSOLUTE_RANGE_UV, adc->graph[VADC_CALIB_ABSOLUTE].dy);
+
+ /* Ratiometric calibration */
+ ch = pm8xxx_get_channel(adc, CHANNEL_MUXOFF);
+ if (!ch)
+ return -ENODEV;
+ ret = pm8xxx_read_channel_rsv(adc, ch, AMUX_RSV5, &read_nomux_rsv5);
+ if (ret) {
+ dev_err(adc->dev, "could not read MUXOFF reference channel\n");
+ return -ENODEV;
+ }
+ ret = pm8xxx_read_channel_rsv(adc, ch, AMUX_RSV4, &read_nomux_rsv4);
+ if (ret) {
+ dev_err(adc->dev, "could not read MUXOFF reference channel\n");
+ return -ENODEV;
+ }
+ adc->graph[VADC_CALIB_RATIOMETRIC].dy =
+ read_nomux_rsv5 - read_nomux_rsv4;
+ adc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_nomux_rsv4;
+
+ dev_info(adc->dev, "ratiometric calibration dx = %d uV, dy = %d units\n",
+ VADC_RATIOMETRIC_RANGE_UV,
+ adc->graph[VADC_CALIB_RATIOMETRIC].dy);
+
+ return 0;
+}
+
+static int pm8xxx_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct pm8xxx_xoadc *adc = iio_priv(indio_dev);
+ const struct pm8xxx_chan_info *ch;
+ u16 adc_code;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_PROCESSED:
+ /* Only die temperature ends up here */
+ ch = pm8xxx_get_channel(adc, chan->address);
+ if (!ch) {
+ dev_err(adc->dev, "no such channel %lu\n",
+ chan->address);
+ return -EINVAL;
+ }
+ ret = pm8xxx_read_channel(adc, ch, &adc_code);
+ if (ret)
+ return ret;
+ *val = pm8xxx_calibrate(adc, ch, adc_code);
+ /* 2mV/K, return milli Celsius */
+ *val /= 2;
+ *val -= KELVINMIL_CELSIUSMIL;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ ch = pm8xxx_get_channel(adc, chan->address);
+ if (!ch) {
+ dev_err(adc->dev, "no such channel %lu\n",
+ chan->address);
+ return -EINVAL;
+ }
+ ret = pm8xxx_read_channel(adc, ch, &adc_code);
+ if (ret)
+ return ret;
+ *val = pm8xxx_calibrate(adc, ch, adc_code);
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SCALE:
+ /*
+ * Applies to all voltage channels: we scale the microvolts
+ * to millivolts as required by the userspace ABI.
+ */
+ *val = 0;
+ *val2 = 1000;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info pm8xxx_xoadc_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = pm8xxx_read_raw,
+};
+
+static int pm8xxx_xoadc_parse_channel(struct device *dev,
+ struct device_node *np,
+ struct pm8xxx_chan_info *ch)
+{
+ const char *name = np->name;
+ u32 chan, rsv, dec;
+ int ret;
+
+ ret = of_property_read_u32(np, "reg", &chan);
+ if (ret) {
+ dev_err(dev, "invalid channel number %s\n", name);
+ return ret;
+ }
+ if (chan > XOADC_CHAN_MAX) {
+ dev_err(dev, "%s too big channel number %d\n", name, chan);
+ return -EINVAL;
+ }
+
+ if (of_property_read_bool(np, "qcom,ratiometric")) {
+ ch->calibration = VADC_CALIB_RATIOMETRIC;
+ ret = of_property_read_u32(np, "qcom,ratiometric-ref", &rsv);
+ if (ret) {
+ dev_err(dev, "invalid RSV %s\n", name);
+ return ret;
+ }
+ if (rsv > XOADC_RSV_MAX) {
+ dev_err(dev, "%s too large RSV value %d\n", name, rsv);
+ return -EINVAL;
+ }
+ if (rsv == AMUX_RSV3) {
+ dev_err(dev, "%s invalid RSV value %d\n", name, rsv);
+ return -EINVAL;
+ }
+ } else {
+ ch->calibration = VADC_CALIB_ABSOLUTE;
+ rsv = 0;
+ }
+
+ ret = of_property_read_u32(np, "qcom,decimation", &dec);
+ if (!ret) {
+ /* It's OK to skip this ... */
+ ret = qcom_vadc_decimation_from_dt(dec);
+ if (ret < 0) {
+ dev_err(dev, "%s invalid decimation %d\n",
+ name, dec);
+ return ret;
+ }
+ ch->decimation = ret;
+ } else {
+ ch->decimation = VADC_DEF_DECIMATION;
+ }
+
+ ch->amux_channel = chan;
+ ch->name = name;
+ ch->amux_ip_rsv = rsv;
+ ch->amux_mpp_channel = PREMUX_MPP_SCALE_0; /* FIXME: get from DT */
+
+ dev_dbg(dev, "channel %d \"%s\" ref voltage: %d, decimation %d\n",
+ ch->amux_channel,
+ ch->name,
+ ch->amux_ip_rsv,
+ ch->decimation);
+ return 0;
+}
+
+static int pm8xxx_xoadc_parse_channels(struct pm8xxx_xoadc *adc,
+ struct device_node *np)
+{
+ struct device_node *child;
+ struct pm8xxx_chan_info *ch;
+ int ret;
+ int i;
+
+ adc->nchans = of_get_available_child_count(np);
+ if (!adc->nchans) {
+ dev_err(adc->dev, "no channel children\n");
+ return -ENODEV;
+ }
+ dev_dbg(adc->dev, "found %d ADC channels\n", adc->nchans);
+
+ adc->iio_chans = devm_kcalloc(adc->dev, adc->nchans,
+ sizeof(*adc->iio_chans), GFP_KERNEL);
+ if (!adc->iio_chans)
+ return -ENOMEM;
+
+ adc->chans = devm_kcalloc(adc->dev, adc->nchans,
+ sizeof(*adc->chans), GFP_KERNEL);
+ if (!adc->chans)
+ return -ENOMEM;
+
+ i = 0;
+ for_each_available_child_of_node(np, child) {
+ struct iio_chan_spec *iio_chan;
+
+ ch = &adc->chans[i];
+ ret = pm8xxx_xoadc_parse_channel(adc->dev, child, ch);
+ if (ret) {
+ of_node_put(child);
+ return ret;
+ }
+
+ iio_chan = &adc->iio_chans[i];
+ iio_chan->channel = ch->amux_channel;
+ iio_chan->datasheet_name = ch->name;
+ /* A single temperature channel, the rest are voltages */
+ if (ch->amux_channel == CHANNEL_DIE_TEMP) {
+ iio_chan->type = IIO_TEMP;
+ iio_chan->info_mask_separate =
+ BIT(IIO_CHAN_INFO_PROCESSED);
+ } else {
+ iio_chan->type = IIO_VOLTAGE;
+ iio_chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE);
+ }
+ iio_chan->indexed = 1;
+ iio_chan->address = ch->amux_channel;
+
+ i++;
+ }
+
+ /* Check for required channels */
+ ch = pm8xxx_get_channel(adc, CHANNEL_125V);
+ if (!ch) {
+ dev_err(adc->dev, "missing 1.25V reference channel\n");
+ return -ENODEV;
+ }
+ ch = pm8xxx_get_channel(adc, CHANNEL_INTERNAL);
+ if (!ch) {
+ dev_err(adc->dev, "missing 0.625V reference channel\n");
+ return -ENODEV;
+ }
+ ch = pm8xxx_get_channel(adc, CHANNEL_MUXOFF);
+ if (!ch) {
+ dev_err(adc->dev, "missing MUXOFF reference channel\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int pm8xxx_xoadc_probe(struct platform_device *pdev)
+{
+ struct pm8xxx_xoadc *adc;
+ struct iio_dev *indio_dev;
+ struct device_node *np = pdev->dev.of_node;
+ struct regmap *map;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*adc));
+ if (!indio_dev)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, indio_dev);
+
+ adc = iio_priv(indio_dev);
+ adc->dev = dev;
+ init_completion(&adc->complete);
+
+ ret = pm8xxx_xoadc_parse_channels(adc, np);
+ if (ret)
+ return ret;
+
+ map = dev_get_regmap(dev->parent, NULL);
+ if (!map) {
+ dev_err(dev, "Parent regmap unavailable.\n");
+ return -ENXIO;
+ }
+ adc->map = map;
+
+ /* Bring up regulator */
+ adc->vref = devm_regulator_get(dev, "xoadc-ref");
+ if (IS_ERR(adc->vref)) {
+ dev_err(dev, "failed to get XOADC VREF regulator\n");
+ return PTR_ERR(adc->vref);
+ }
+ /* We strictly require this voltage */
+ ret = regulator_set_voltage(adc->vref, 2200000, 2200000);
+ if (ret) {
+ dev_err(dev, "unable to set LDO18 voltage to 2.2V\n");
+ return ret;
+ }
+ ret = regulator_enable(adc->vref);
+ if (ret) {
+ dev_err(dev, "failed to enable XOADC VREF regulator\n");
+ return ret;
+ }
+
+ ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0),
+ pm8xxx_eoc_irq, NULL, 0, "pm8xxx-adc", indio_dev);
+ if (ret) {
+ dev_err(dev, "unable to request IRQ\n");
+ goto out_disable_vref;
+ }
+
+ indio_dev->dev.parent = dev;
+ indio_dev->dev.of_node = np;
+ indio_dev->name = "pm8xxx-xoadc";
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = &pm8xxx_xoadc_info;
+ indio_dev->channels = adc->iio_chans;
+ indio_dev->num_channels = adc->nchans;
+
+ ret = iio_device_register(indio_dev);
+ if (ret)
+ goto out_disable_vref;
+
+ ret = pm8xxx_calibrate_device(adc);
+ if (ret)
+ goto out_unreg_device;
+
+ dev_info(dev, "PM8xxx XOADC driver enabled\n");
+
+ return 0;
+
+out_unreg_device:
+ iio_device_unregister(indio_dev);
+out_disable_vref:
+ regulator_disable(adc->vref);
+
+ return ret;
+}
+
+static int pm8xxx_xoadc_remove(struct platform_device *pdev)
+{
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct pm8xxx_xoadc *adc = iio_priv(indio_dev);
+
+ iio_device_unregister(indio_dev);
+
+ regulator_disable(adc->vref);
+
+ return 0;
+}
+
+static const struct of_device_id pm8xxx_xoadc_id_table[] = {
+ {
+ .compatible = "qcom,pm8058-adc",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, pm8xxx_xoadc_id_table);
+
+static struct platform_driver pm8xxx_xoadc_driver = {
+ .driver = {
+ .name = "pm8xxx-adc",
+ .of_match_table = pm8xxx_xoadc_id_table,
+ },
+ .probe = pm8xxx_xoadc_probe,
+ .remove = pm8xxx_xoadc_remove,
+};
+module_platform_driver(pm8xxx_xoadc_driver);
+
+MODULE_DESCRIPTION("PM8xxx XOADC driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:pm8xxx-xoadc");
--
2.7.4
^ permalink raw reply related
* [PATCH v9 04/11] irqchip/gic-v3: Add missing system register definitions
From: Auger Eric @ 2016-12-06 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479906118-15832-5-git-send-email-vijay.kilari@gmail.com>
Hi,
On 23/11/2016 14:01, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> Define register definitions for ICH_VMCR_EL2, ICC_CTLR_EL1 and
> ICH_VTR_EL2, ICC_BPR0_EL1, ICC_BPR1_EL1 registers.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> include/linux/irqchip/arm-gic-v3.h | 43 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index 0deea34..b4f8287 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -352,8 +352,30 @@
> /*
> * CPU interface registers
> */
> -#define ICC_CTLR_EL1_EOImode_drop_dir (0U << 1)
> -#define ICC_CTLR_EL1_EOImode_drop (1U << 1)
> +#define ICC_CTLR_EL1_EOImode_SHIFT (1)
> +#define ICC_CTLR_EL1_EOImode_drop_dir (0U << ICC_CTLR_EL1_EOImode_SHIFT)
> +#define ICC_CTLR_EL1_EOImode_drop (1U << ICC_CTLR_EL1_EOImode_SHIFT)
> +#define ICC_CTLR_EL1_EOImode_MASK (1 << ICC_CTLR_EL1_EOImode_SHIFT)
> +#define ICC_CTLR_EL1_CBPR_SHIFT 0
> +#define ICC_CTLR_EL1_CBPR_MASK (1 << ICC_CTLR_EL1_CBPR_SHIFT)
> +#define ICC_CTLR_EL1_PRI_BITS_SHIFT 8
> +#define ICC_CTLR_EL1_PRI_BITS_MASK (0x7 << ICC_CTLR_EL1_PRI_BITS_SHIFT)
> +#define ICC_CTLR_EL1_ID_BITS_SHIFT 11
> +#define ICC_CTLR_EL1_ID_BITS_MASK (0x7 << ICC_CTLR_EL1_ID_BITS_SHIFT)
> +#define ICC_CTLR_EL1_SEIS_SHIFT 14
> +#define ICC_CTLR_EL1_SEIS_MASK (0x1 << ICC_CTLR_EL1_SEIS_SHIFT)
> +#define ICC_CTLR_EL1_A3V_SHIFT 15
> +#define ICC_CTLR_EL1_A3V_MASK (0x1 << ICC_CTLR_EL1_A3V_SHIFT)
> +#define ICC_PMR_EL1_SHIFT 0
> +#define ICC_PMR_EL1_MASK (0xff << ICC_PMR_EL1_SHIFT)
> +#define ICC_BPR0_EL1_SHIFT 0
> +#define ICC_BPR0_EL1_MASK (0x7 << ICC_BPR0_EL1_SHIFT)
> +#define ICC_BPR1_EL1_SHIFT 0
> +#define ICC_BPR1_EL1_MASK (0x7 << ICC_BPR1_EL1_SHIFT)
> +#define ICC_IGRPEN0_EL1_SHIFT 0
> +#define ICC_IGRPEN0_EL1_MASK (1 << ICC_IGRPEN0_EL1_SHIFT)
> +#define ICC_IGRPEN1_EL1_SHIFT 0
> +#define ICC_IGRPEN1_EL1_MASK (1 << ICC_IGRPEN1_EL1_SHIFT)
> #define ICC_SRE_EL1_SRE (1U << 0)
>
> /*
> @@ -384,12 +406,29 @@
>
> #define ICH_VMCR_CTLR_SHIFT 0
> #define ICH_VMCR_CTLR_MASK (0x21f << ICH_VMCR_CTLR_SHIFT)
> +#define ICH_VMCR_CBPR_SHIFT 4
> +#define ICH_VMCR_CBPR_MASK (1 << ICH_VMCR_CBPR_SHIFT)
> +#define ICH_VMCR_EOIM_SHIFT 9
> +#define ICH_VMCR_EOIM_MASK (1 << ICH_VMCR_EOIM_SHIFT)
> #define ICH_VMCR_BPR1_SHIFT 18
> #define ICH_VMCR_BPR1_MASK (7 << ICH_VMCR_BPR1_SHIFT)
> #define ICH_VMCR_BPR0_SHIFT 21
> #define ICH_VMCR_BPR0_MASK (7 << ICH_VMCR_BPR0_SHIFT)
> #define ICH_VMCR_PMR_SHIFT 24
> #define ICH_VMCR_PMR_MASK (0xffUL << ICH_VMCR_PMR_SHIFT)
> +#define ICH_VMCR_ENG0_SHIFT 0
> +#define ICH_VMCR_ENG0_MASK (1 << ICH_VMCR_ENG0_SHIFT)
> +#define ICH_VMCR_ENG1_SHIFT 1
> +#define ICH_VMCR_ENG1_MASK (1 << ICH_VMCR_ENG1_SHIFT)
Besides the fact the V* was omitted (for instance VENG0) this looks good
to me.
> +
> +#define ICH_VTR_PRI_BITS_SHIFT 29
> +#define ICH_VTR_PRI_BITS_MASK (7 << ICH_VTR_PRI_BITS_SHIFT)
> +#define ICH_VTR_ID_BITS_SHIFT 23
> +#define ICH_VTR_ID_BITS_MASK (7 << ICH_VTR_ID_BITS_SHIFT)
> +#define ICH_VTR_SEIS_SHIFT 22
> +#define ICH_VTR_SEIS_MASK (1 << ICH_VTR_SEIS_SHIFT)
> +#define ICH_VTR_A3V_SHIFT 21
> +#define ICH_VTR_A3V_MASK (1 << ICH_VTR_A3V_SHIFT)
Some fields are omitted but I guess they are not used.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
>
> #define ICC_IAR1_EL1_SPURIOUS 0x3ff
>
>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1
From: Maxime Ripard @ 2016-12-06 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9607940c-1ca9-bb49-291e-ddc7e77546be@gmail.com>
On Tue, Dec 06, 2016 at 04:23:57PM +0900, Milo Kim wrote:
> On 12/05/2016 05:09 PM, Maxime Ripard wrote:
> > On Mon, Dec 05, 2016 at 11:00:31AM +0900, Milo Kim wrote:
> > > The board has DDR3 512MB. This patch helps scanning the memory and
> > > adding memblock through the DT.
> > >
> > > Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> > > ---
> > > arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > index ec63d10..be3668f 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > @@ -45,6 +45,11 @@
> > > / {
> > > model = "FriendlyArm NanoPi M1";
> > > compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
> > > +
> > > + memory at 40000000 {
> > > + device_type = "memory";
> > > + reg = <0x40000000 0x20000000>;
> > > + };
> >
> > U-boot will fill that up, so there's no need to put it there.
>
> Right, my intention was adding memblock through the DT whether the bootload
> does or not. However I'm not sure the situation (missing memblock in u-boot)
> could really happen.
No, we need a recent U-Boot in order to boot, and such a uboot will
setup the memory node anyway.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/c5db1b59/attachment.sig>
^ permalink raw reply
* [PATCH renesas/devel 1/2] ARM: shmobile: defconfig: Enable r8a774[35] SoCs
From: Geert Uytterhoeven @ 2016-12-06 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031173-18600-2-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/3] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Peter Meerwald-Stadler @ 2016-12-06 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481032253-27019-1-git-send-email-linus.walleij@linaro.org>
> This adds the device tree bindings for the Qualcomm PM8xxx
> ADCs. This is based on the existing DT bindings for the
> SPMI ADC so there are hopefully no controversial features.
nitpicking below
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
> 1 file changed, 160 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> new file mode 100644
> index 000000000000..6e51e3e74b88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -0,0 +1,160 @@
> +Qualcomm's PM8xxx voltage XOADC
> +
> +The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Chrystal
crystal
> +oscillator ADC) encompass PM8018, PM8038, PM8058, PM8917 and PM8921.
encompassing
> +
> +Required properties:
> +
> +- compatible: should be one of:
> + "qcom,pm8018-adc"
> + "qcom,pm8038-adc"
> + "qcom,pm8058-adc"
> + "qcom,pm8917-adc"
> + "qcom,pm8921-adc"
> +
> +- reg: should contain the ADC base address in the PMIC, typically
> + 0x197.
> +
> +The following required properties are standard for IO channels, see
> +iio-bindings.txt for more details:
> +
> +- #address-cells: should be set to <1>
> +
> +- #size-cells: should be set to <0>
> +
> +- #io-channel-cells: should be set to <1>
> +
> +- interrupts: should refer to the parent PMIC interrupt controller
> + and reference the proper ADC interrupt.
> +
> +Required subnodes:
> +
> +The ADC channels are configured as subnodes of the ADC. Since some of
> +them are used for calibrating the ADC, these nodes are compulsory:
> +
> +ref_625mv {
> + reg = <0x0c>;
> +};
> +
> +ref_1250mv {
> + reg = <0x0d>;
> +};
> +
> +ref_muxoff {
> + reg = <0x0f>;
> +};
> +
> +These three nodes are used for absolute and ratiometric calibration
> +and only need to have these reg values: they are by hardware defined
they are by hardware definition 1:1 ratio converters that sample ...
> +to be 1:1 ratio converters that sample 625, 1250 and 0 V and create
milliV
or 0.625, 1.250 V
> +an interpolation calibration for all other ADCs.
> +
> +Optional subnodes: any channels other than channel 0x0c, 0x0d and
> +0x0f are optional.
> +
> +Required channel node properties:
> +
> +- reg: should contain the hardware channel number in the range
> + 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> +
> +Optional channel node properties:
> +
> +- qcom,decimation:
> + Value type: <u32>
> + Definition: This parameter is used to decrease ADC sampling rate.
> + Quicker measurements can be made by reducing decimation ratio.
> + Valid values are 512, 1024, 2048, 4096.
> + If property is not found, default value of 512 will be used.
> +
> +- qcom,ratiometric:
> + Value type: <empty>
> + Definition: Channel calibration type. If this property is specified
> + VADC will use the VDD reference (1.8V) and GND for channel
> + calibration. If property is not found, channel will be
> + calibrated with 0.625V and 1.25V reference channels, also
> + known as absolute calibration.
> +
> +- qcom,ratiometric-ref:
> + Value type: <u32>
> + Definition: The reference voltage pair when using ratiometric
> + calibration:
> + 0 = XO_IN/XOADC_GND
> + 1 = PMIC_IN/XOADC_GND
> + 2 = PMIC_IN/BMS_CSP
> + 3 (invalid)
> + 4 = XOADC_GND/XOADC_GND
> + 5 = XOADC_VREF/XOADC_GND
> +
> +Example:
> +
> +xoadc: xoadc at 197 {
> + compatible = "qcom,pm8058-adc";
> + reg = <0x197>;
> + interrupt-parent = <&pm8058>;
> + interrupts = <76 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + vcoin {
> + reg = <0x00>;
> + };
> + vbat {
> + reg = <0x01>;
> + };
> + dcin {
> + reg = <0x02>;
> + };
> + ichg {
> + reg = <0x03>;
> + };
> + vph_pwr {
> + reg = <0x04>;
> + };
> + mpp5 {
> + reg = <0x05>;
> + };
> + mpp6 {
> + reg = <0x06>;
> + };
> + mpp7 {
> + reg = <0x07>;
> + };
> + mpp8 {
> + reg = <0x08>;
> + };
> + mpp9 {
> + reg = <0x09>;
> + };
> + usb_vbus {
> + reg = <0x0a>;
> + };
> + die_temp {
> + reg = <0x0b>;
> + };
> + ref_625mv {
> + reg = <0x0c>;
> + };
> + ref_1250mv {
> + reg = <0x0d>;
> + };
> + ref_325mv {
> + reg = <0x0e>;
> + };
> + ref_muxoff {
> + reg = <0x0f>;
> + };
> +};
> +
> +
> +/* IIO client node */
> +iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&xoadc 0x01>, /* Battery */
> + <&xoadc 0x02>, /* DC in (charger) */
> + <&xoadc 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x0b>, /* Die temperature */
> + <&xoadc 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x0e>; /* Reference voltage 0.325V */
> +};
>
--
Peter Meerwald-Stadler
+43-664-2444418 (mobile)
^ permalink raw reply
* [PATCH renesas/devel 2/2] ARM: multi_v7_defconfig: Enable r8a774[35] SoCs
From: Geert Uytterhoeven @ 2016-12-06 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031173-18600-3-git-send-email-horms+renesas@verge.net.au>
On Tue, Dec 6, 2016 at 2:32 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Enable recently added r8a7743 (RZ/G1M) and r8a7745 (RZ/G1E) SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Benjamin Gaignard @ 2016-12-06 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206130048.GH25385@dell.home>
[snip]
>
> I'm not going to push too hard, but I still thing "advanced-control"
> would suit better, since this is not *just* a timer. In fact, the
> parent device (the MFD) doesn't have any timer functionality. That's
> what "timer at 0" does.
>
> The IP is called "Advanced Control" in the datasheet, no?
In datasheet only timers 1 and 8 are called "advanced-control" timers
Timers 2 to 5 and 9 to 14 are called "general purpose" timers.
Timers 6 and 7 are named "basic" timers.
I have ask around in ST and it seems that "general purpose" name was the
best to describe all the timers, so I would like to keep using it.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm at 0 {
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0 = <&pwm1_pins>;
>> + pinctrl-names = "default";
>> + };
>> +
>> + timer at 0 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + };
>> + };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: Maxime Ripard @ 2016-12-06 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161204122948.11921-1-jorik@kippendief.biz>
Hi Jorik,
On Sun, Dec 04, 2016 at 01:29:48PM +0100, jorik at kippendief.biz wrote:
> From: Jorik Jonker <jorik@kippendief.biz>
>
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
>
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
>
> Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Thanks!
This looks like a late fix for the current release which comes to an
end. Can you resend it with arm at kernel.org as a recipient, so that the
ARM SoC maintainers can apply it directly?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/c8a8bd19/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Mark Rutland @ 2016-12-06 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480536453-24781-2-git-send-email-rob.rice@broadcom.com>
On Wed, Nov 30, 2016 at 03:07:31PM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto driver.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
> ---
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> new file mode 100644
> index 0000000..e5fe942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> @@ -0,0 +1,25 @@
> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
> +multiple SPU hardware blocks.
Bindings shound describe *hardware*, not *drivers*. Please drop mention
of the driver, and just decribe the hardware.
> +Required properties:
> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
> + of the SPU-M hardware.
> +
> +- reg: Should contain SPU registers location and length.
> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
> +channels correspond to DMA rings on the device.
> +
> +Example:
> + spu-crypto at 612d0000 {
> + compatible = "brcm,spum-crypto";
> + reg = <0 0x612d0000 0 0x900>, /* SPU 0 control regs */
> + <0 0x612f0000 0 0x900>, /* SPU 1 control regs */
> + <0 0x61310000 0 0x900>, /* SPU 2 control regs */
> + <0 0x61330000 0 0x900>; /* SPU 3 control regs */
The above didn't mention there were several register sets, and the
comment beside each makes them sound like they're separate SPU
instances, so I don't think it makes sense to group them as one node.
What's going on here?
> + mboxes = <&pdc0 0>,
> + <&pdc1 0>,
> + <&pdc2 0>,
> + <&pdc3 0>;
Does each mbox correspond to one of the SPUs above? Or is there a shared
pool?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] pinctrl: meson: fix gpio request disabling other modes
From: Neil Armstrong @ 2016-12-06 14:08 UTC (permalink / raw)
To: linux-arm-kernel
The pinctrl_gpio_request is called with the "full" gpio number, already
containing the base, then meson_pmx_request_gpio is then called with the
final pin number.
Remove the base addition when calling meson_pmx_disable_other_groups.
Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
CC: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
index a579126..620c231a 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -212,7 +212,7 @@ static int meson_pmx_request_gpio(struct pinctrl_dev *pcdev,
{
struct meson_pinctrl *pc = pinctrl_dev_get_drvdata(pcdev);
- meson_pmx_disable_other_groups(pc, range->pin_base + offset, -1);
+ meson_pmx_disable_other_groups(pc, offset, -1);
return 0;
}
--
2.7.0
^ permalink raw reply related
* [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver
From: Mark Rutland @ 2016-12-06 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480536453-24781-3-git-send-email-rob.rice@broadcom.com>
On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
> +static const struct of_device_id bcm_spu_dt_ids[] = {
> + {
> + .compatible = "brcm,spum-crypto",
> + .data = &spum_ns2_types,
> + },
> + {
> + .compatible = "brcm,spum-nsp-crypto",
> + .data = &spum_nsp_types,
> + },
> + {
> + .compatible = "brcm,spu2-crypto",
> + .data = &spu2_types,
> + },
> + {
> + .compatible = "brcm,spu2-v2-crypto",
> + .data = &spu2_v2_types,
> + },
These last two weren't in the binding document.
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
> +
> +static int spu_dt_read(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct spu_hw *spu = &iproc_priv.spu;
> + struct device_node *dn = pdev->dev.of_node;
> + struct resource *spu_ctrl_regs;
> + const struct of_device_id *match;
> + struct spu_type_subtype *matched_spu_type;
> + void __iomem *spu_reg_vbase[MAX_SPUS];
> + int i;
> + int err;
> +
> + if (!of_device_is_available(dn)) {
> + dev_crit(dev, "SPU device not available");
> + return -ENODEV;
> + }
How can this happen?
> + /* Count number of mailbox channels */
> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
> + dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
> +
> + match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
> + matched_spu_type = (struct spu_type_subtype *)match->data;
This cast usn't necessary.
> + spu->spu_type = matched_spu_type->type;
> + spu->spu_subtype = matched_spu_type->subtype;
> +
> + /* Read registers and count number of SPUs */
> + i = 0;
> + while ((i < MAX_SPUS) && ((spu_ctrl_regs =
> + platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
> + dev_dbg(dev,
> + "SPU %d control register region res.start = %#x, res.end = %#x",
> + i,
> + (unsigned int)spu_ctrl_regs->start,
> + (unsigned int)spu_ctrl_regs->end);
> +
> + spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
> + if (IS_ERR(spu_reg_vbase[i])) {
> + err = PTR_ERR(spu_reg_vbase[i]);
> + dev_err(&pdev->dev, "Failed to map registers: %d\n",
> + err);
> + spu_reg_vbase[i] = NULL;
> + return err;
> + }
> + i++;
> + }
These *really* sound like independent devices. There are no shared
registers, and each has its own mbox.
Why do we group them like this?
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] ACPI/IORT: Make dma masks set-up IORT specific
From: Lorenzo Pieralisi @ 2016-12-06 14:20 UTC (permalink / raw)
To: linux-arm-kernel
The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.
On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
called for every device that has an ACPI companion, in that every device
is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
which has the side effect of initializing dma masks also for
pseudo-devices (eg CPUs and memory nodes) and potentially for devices
whose dma masks were not set-up before the acpi_dma_configure() API was
introduced, which may have noxious side effects.
Therefore, in preparation for IORT firmware specific DMA masks set-up,
wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sricharan R <sricharan@codeaurora.org>
---
Hi Joerg,
as discussed please apply it to your arm/smmu branch (and consequently
to -next) in order to get this queued along with the rest of the ACPI IORT
SMMU series for v4.10.
Thank you !
Lorenzo
v1 -> v2
- Added review tags
drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
drivers/acpi/scan.c | 14 +-------------
include/linux/acpi_iort.h | 2 ++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 47bace8..e0d2e6e 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
}
/**
+ * iort_set_dma_mask - Set-up dma mask for a device.
+ *
+ * @dev: device to configure
+ */
+void iort_set_dma_mask(struct device *dev)
+{
+ /*
+ * Set default coherent_dma_mask to 32 bit. Drivers are expected to
+ * setup the correct supported mask.
+ */
+ if (!dev->coherent_dma_mask)
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+ /*
+ * Set it to coherent_dma_mask by default if the architecture
+ * code has not set it.
+ */
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+}
+
+/**
* iort_iommu_configure - Set-up IOMMU configuration for a device.
*
* @dev: device to configure
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 80698d3..93b00cf 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
{
const struct iommu_ops *iommu;
- /*
- * Set default coherent_dma_mask to 32 bit. Drivers are expected to
- * setup the correct supported mask.
- */
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
- /*
- * Set it to coherent_dma_mask by default if the architecture
- * code has not set it.
- */
- if (!dev->dma_mask)
- dev->dma_mask = &dev->coherent_dma_mask;
+ iort_set_dma_mask(dev);
iommu = iort_iommu_configure(dev);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index dcb2b60..77e0809 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
/* IOMMU interface */
+void iort_set_dma_mask(struct device *dev);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
#else
static inline void acpi_iort_init(void) { }
@@ -45,6 +46,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
/* IOMMU interface */
+static inline void iort_set_dma_mask(struct device *dev) { }
static inline
const struct iommu_ops *iort_iommu_configure(struct device *dev)
{ return NULL; }
--
2.10.0
^ permalink raw reply related
* [PATCH v3] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Christoffer Dall @ 2016-12-06 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b2623eed-fd63-c8c6-fd66-428bd87759d9@arm.com>
On Tue, Dec 06, 2016 at 01:09:26PM +0000, Marc Zyngier wrote:
> On 06/12/16 12:16, Christoffer Dall wrote:
> > On Tue, Dec 06, 2016 at 01:12:21PM +0100, Christoffer Dall wrote:
> >> On Tue, Dec 06, 2016 at 11:17:40AM +0000, Marc Zyngier wrote:
> >>> On 01/12/16 19:32, Jintack Lim wrote:
> >>>> Current KVM world switch code is unintentionally setting wrong bits to
> >>>> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
> >>>> timer. Bit positions of CNTHCTL_EL2 are changing depending on
> >>>> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
> >>>> not set, but they are 11th and 10th bits respectively when E2H is set.
> >>>>
> >>>> In fact, on VHE we only need to set those bits once, not for every world
> >>>> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
> >>>> 1, which makes those bits have no effect for the host kernel execution.
> >>>> So we just set those bits once for guests, and that's it.
> >>>>
> >>>> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
> >>>> ---
> >>>> v2->v3:
> >>>> - Perform the initialization including CPU hotplug case.
> >>>> - Move has_vhe() to asm/virt.h
> >>>>
> >>>> v1->v2:
> >>>> - Skip configuring cnthctl_el2 in world switch path on VHE system.
> >>>> - Write patch based on linux-next.
> >>>> ---
> >>>> arch/arm/include/asm/virt.h | 5 +++++
> >>>> arch/arm/kvm/arm.c | 3 +++
> >>>> arch/arm64/include/asm/virt.h | 10 ++++++++++
> >>>> include/kvm/arm_arch_timer.h | 1 +
> >>>> virt/kvm/arm/arch_timer.c | 23 +++++++++++++++++++++++
> >>>> virt/kvm/arm/hyp/timer-sr.c | 33 +++++++++++++++++++++------------
> >>>> 6 files changed, 63 insertions(+), 12 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
> >>>> index a2e75b8..6dae195 100644
> >>>> --- a/arch/arm/include/asm/virt.h
> >>>> +++ b/arch/arm/include/asm/virt.h
> >>>> @@ -80,6 +80,11 @@ static inline bool is_kernel_in_hyp_mode(void)
> >>>> return false;
> >>>> }
> >>>>
> >>>> +static inline bool has_vhe(void)
> >>>> +{
> >>>> + return false;
> >>>> +}
> >>>> +
> >>>> /* The section containing the hypervisor idmap text */
> >>>> extern char __hyp_idmap_text_start[];
> >>>> extern char __hyp_idmap_text_end[];
> >>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> >>>> index 8f92efa..13e54e8 100644
> >>>> --- a/arch/arm/kvm/arm.c
> >>>> +++ b/arch/arm/kvm/arm.c
> >>>> @@ -1099,6 +1099,9 @@ static void cpu_init_hyp_mode(void *dummy)
> >>>> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> >>>> __cpu_init_stage2();
> >>>>
> >>>> + if (is_kernel_in_hyp_mode())
> >>>> + kvm_timer_init_vhe();
> >>>> +
> >>>> kvm_arm_init_debug();
> >>>> }
> >>>>
> >>>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> >>>> index fea1073..b043cfd 100644
> >>>> --- a/arch/arm64/include/asm/virt.h
> >>>> +++ b/arch/arm64/include/asm/virt.h
> >>>> @@ -47,6 +47,7 @@
> >>>> #include <asm/ptrace.h>
> >>>> #include <asm/sections.h>
> >>>> #include <asm/sysreg.h>
> >>>> +#include <asm/cpufeature.h>
> >>>>
> >>>> /*
> >>>> * __boot_cpu_mode records what mode CPUs were booted in.
> >>>> @@ -80,6 +81,15 @@ static inline bool is_kernel_in_hyp_mode(void)
> >>>> return read_sysreg(CurrentEL) == CurrentEL_EL2;
> >>>> }
> >>>>
> >>>> +static inline bool has_vhe(void)
> >>>> +{
> >>>> +#ifdef CONFIG_ARM64_VHE
> >>>
> >>> Is there a particular reason why this should be guarded by a #ifdef? All
> >>> the symbols should always be available, and since this is a static key,
> >>> the overhead should be really insignificant (provided that you use a
> >>> non-prehistoric compiler...).
> >>>
> >>
> >> Isn't this code called from a file shared between 32-bit arm and arm64?
> >> Does the cpus_have_const_cap work on ARM64?
> >
> > Duh, I meant on 32-bit arm of course.
>
> Well, this is a pure 64bit file - 32bit has the canonical implementation
> that always returns false. So I can't really see how this can ever break
> 32bit. Unless my lack of sleep is really showing, and I'm missing
> something terribly obvious?
>
No, I'm being an idiot, too many things at once and a lack of coffee.
-Christoffer
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox