* [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64
From: Icenowy Zheng @ 2017-04-04 18:01 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree, linux-sunxi, linux-kernel, linux-arm-kernel,
Icenowy Zheng
In-Reply-To: <20170404180145.12897-1-icenowy@aosc.io>
Allwinner A64 SoC features a NMI controller, which is usually connected
to the AXP PMIC.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 9a75b1c7c91a..f907a64e6f0c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -401,6 +401,14 @@
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
};
+ nmi_intc: interrupt-controller@01f00c0c {
+ compatible = "allwinner,sun6i-a31-sc-nmi";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c0c 0x38>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
r_ccu: clock@1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
--
2.12.2
^ permalink raw reply related
* [PATCH 01/11] arm64: allwinner: a64: enable RSB on A64
From: Icenowy Zheng @ 2017-04-04 18:01 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
In-Reply-To: <20170404180145.12897-1-icenowy-h8G6r0blFSE@public.gmane.org>
Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
Add it and its pinmux.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 6bc606b4d74d..9a75b1c7c91a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -420,6 +420,27 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+ r_rsb_pins: rsb@0 {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ drive-strength = <20>;
+ bias-pull-up;
+ };
+ };
+
+ r_rsb: rsb@1f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu 6>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.12.2
^ permalink raw reply related
* [PATCH 00/11] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-04 18:01 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Chen-Yu Tsai, Maxime Ripard,
Liam Girdwood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Icenowy Zheng
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).
This patchset adds support for it and enabled it in Pine64 device tree.
This patchset can be splitted into two big parts:
- Part1: PATCH 1/11 to PATCH 5/11, which are enabling the MFD (and the
power key functionality) of AXP803.
- Part2: PATCH 6/11 to PATCH 11/11, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 and 2 added RSB and NMI device nodes, which are used for the
communication between A64 and AXP803.
PATCH 3 adds basical devicetree binding for AXP803.
PATCH 4 adds support for the AXP803 variant in axp20x-rsb mfd driver.
PATCH 5 enabled the AXP803 MFD in Pine64 device tree.
PATCH 6 adds devicetree binding for the regulators in AXP803.
PATCH 7 adds support for the regulators in AXP803 in the axp20x-regulator
driver.
PATCH 8 enabled the regulator MFD cell in AXP803.
PATCH 9 adds a DTSI file for AXP803, just like what have been done for other
AXPs.
PATCH 10 enabled the regulators on Pine64.
PATCH 11 enabled Wi-Fi support on Pine64, which required DLDO4 and ELDO1
regulators.
Icenowy Zheng (11):
arm64: allwinner: a64: enable RSB on A64
arm64: allwinner: a64: add NMI controller on A64
dt-bindings: add device tree binding for X-Powers AXP803 PMIC
mfd: axp20x: support AXP803 variant
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
dt-bindings: add AXP803's regulator info
regulator: axp20x-regulator: add support for AXP803
mfd: axp20x: add axp20x-regulator cell for AXP803
arm64: allwinner: a64: add DTSI file for AXP803 PMIC
arm64: allwinner: a64: enable AXP803 regulators for Pine64
arm64: allwinner: a64: enable Wi-Fi for Pine64
Documentation/devicetree/bindings/mfd/axp20x.txt | 30 ++++-
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 +++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 +++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 29 ++++
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 115 ++++++++++++++++
drivers/regulator/axp20x-regulator.c | 135 +++++++++++++++++--
include/linux/mfd/axp20x.h | 77 ++++++++++-
8 files changed, 657 insertions(+), 16 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
* Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Javier Martinez Canillas @ 2017-04-04 17:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Lee Jones,
Benoît Cousson, Wolfram Sang, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170404174323.GA13234-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hello Tony,
On 04/04/2017 01:43 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> [170404 08:33]:
>> Most patches can be applied independently, with the exception of patches
>> 2 to 4 that should be applied in the same tree to keep bisect-ability.
>
> Probably best to merge this all via MFD or i2c:
>
I would prefer MFD since the changes in that subsystem are the ones that
could cause issues. The changes for I2C is just a update to an example.
> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
Thanks!
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Tony Lindgren @ 2017-04-04 17:43 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Lee Jones,
Benoît Cousson, Wolfram Sang, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170404153036.6651-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
* Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> [170404 08:33]:
> Most patches can be applied independently, with the exception of patches
> 2 to 4 that should be applied in the same tree to keep bisect-ability.
Probably best to merge this all via MFD or i2c:
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Aaro Koskinen @ 2017-04-04 17:38 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, devicetree, Rob Herring, Tony Lindgren, Lee Jones,
Benoît Cousson, Wolfram Sang, Mark Rutland, linux-omap,
Russell King, linux-arm-kernel, linux-i2c
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
Hi,
On Tue, Apr 04, 2017 at 11:30:28AM -0400, Javier Martinez Canillas wrote:
> This series add OF device ID tables to mfd I2C drivers whose devices are
> either used in Device Tree source files or are listed in binding docs as
> a compatible string.
For patches 1-5 you can add:
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Christopher Bostic @ 2017-04-04 17:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Joel Stanley
Cc: Rob Herring, Mark Rutland, Russell King, rostedt, mingo, Greg KH,
devicetree, linux-arm-kernel, Linux Kernel Mailing List,
Andrew Jeffery, Alistair Popple, Edward A . James, Jeremy Kerr
In-Reply-To: <1490907014.3177.207.camel@kernel.crashing.org>
On 3/30/17 3:50 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote:
>>>> +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *msg,
>>>> + uint8_t num_bits)
>>>> +{
>>>> + uint8_t bit, in_bit;
>>>> +
>>>> + set_sda_input(master);
>>>> +
>>>> + for (bit = 0; bit < num_bits; bit++) {
>>>> + clock_toggle(master, 1);
>>>> + in_bit = sda_in(master);
>>>> + msg->msg <<= 1;
>>>> + msg->msg |= ~in_bit & 0x1; /* Data is negative active */
>>>> + }
>>>> + msg->bits += num_bi ts;
>>>> +}
>>>> +
>>>> +static void serial_out(struct fsi_master_gpio *master,
>>>> + const struct fsi_gpio_msg *cmd)
>>>> +{
>>>> + uint8_t bit;
>>>> + uint64_t msg = ~cmd->msg; /* Data is negative active */
>>>> + uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
>>>> + uint64_t last_bit = ~0;
>>>> + int next_bit;
>>>> +
>>>> + if (!cmd->bits) {
>>>> + dev_warn(master->dev, "trying to output 0 bits\n");
>>>> + return;
>>>> + }
>>>> + set_sda_output(master, 0);
>>>> +
>>>> + /* Send the start bit */
>>>> + sda_out(master, 0);
>>>> + clock_toggle(master, 1);
>>>> +
>>>> + /* Send the message */
>>>> + for (bit = 0; bit < cmd->bits; bit++) {
>>>> + next_bit = (msg & sda_mask) >> (cmd->bits - 1);
>>>> + if (last_bit ^ next_bit) {
>>>> + sda_out(master, next_bit);
>>>> + last_bit = next_bit;
>>>> + }
>>>> + clock_toggle(master, 1);
>>>> + msg <<= 1;
>>>> + }
>>>> +}
> As I mentioned privately, I don't think this is right, unless your
> clock signal is inverted or my protocol spec is wrong...
>
> Your clock toggle is written so you call it right after the rising
> edge. It does delay, 0, delay, 1.
>
> But according to the FSI timing diagram I have, you need to establish
> the data around the falling edge, it gets sampled by the slave on the
> rising edge. So as it is, your code risks violating the slave hold
> time.
>
> On input, you need to sample on the falling edge, right before it. You
> are sampling after the rising edge, so you aren't leaving enough time
> for the slave to establish the data.
>
> You could probably just flip clock_toggle() around. Make it: 0, delay,
> 1, delay.
>
> That way you can do for sends: sda_out + toggle, and for receive
> toggle + sda_in. That will make you establish your output data and
> sample right before the falling edge, which should be ok provided the
> diagram I have is right.
Hi Ben,
Agreed that there is room for improvement. I intend to look further
into your suggestions from here and our private conversation on the
matter and make changes as appropriate. I have an open issue to track
this. As it exists in this patch reads/writes from master to slave
fundamentally work. Given the pervasiveness and time to fully evaluate
and test any protocol updates I intend address this in the near future
with a separate follow on patch.
Thanks,
Chris
>
> Cheers,
> Ben.
>
^ permalink raw reply
* Re: [PATCH] arm: dts: genmai: Enable rtc and rtc_x1 clock
From: Simon Horman @ 2017-04-04 17:17 UTC (permalink / raw)
To: Jacopo Mondi
Cc: chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ, geert-Td1EMuHUCqxL1ZNQvxDV9g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491235398-26549-1-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On Mon, Apr 03, 2017 at 06:03:18PM +0200, Jacopo Mondi wrote:
> Enable the 32.768 kHz RTC_X1 clock by setting the frequency value to
> non-zero and enable the realtime clock.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> ---
>
> This patch depends on Chris Brandt's series
> "rtc: Reuse rtc-sh driver to support RZ/A1"
> Please queue this on top of that.
Thanks, done.
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 0/7] rtc: Reuse rtc-sh driver to support RZ/A1
From: Simon Horman @ 2017-04-04 17:11 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Chris Brandt, Alessandro Zummo, Rob Herring, Mark Rutland,
Geert Uytterhoeven, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170403160337.g3fzjbfhllnaoafz-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
On Mon, Apr 03, 2017 at 06:03:37PM +0200, Alexandre Belloni wrote:
> Hi,
>
> On 29/03/2017 at 10:30:28 -0700, Chris Brandt wrote:
> > Basically, the same RTC that was used in SuperH devices is now used in
> > RZ/A1 devices. Therefore with some slight changes, that driver can be
> > reused.
> >
> > Additionally, since ARM architectures require Device Tree configurations,
> > device tree support has been added.
> >
> > This was tested on RZ/A1H RSK board. Once the correct time was programmed
> > into the RTC running off a 32.768kHz crystal, you can retain an accurate
> > system clock between reboots (hard and soft) until power is finally removed
> > from the board (there is no batter backup on the RSK board).
> >
> > v3:
> > * remove 'power-domains' from example in documentation
> > * update commit message subject and body of dt-bindings
> >
> > v2:
> > * removed HAVE_CLK from Kconfig
> > * when using DT, look for "fck" instead of "rtc0"
> > * changed (res == NULL) to (!res)
> > * added Reviewed-by for rtc-sh.c
> > * added interrupt-names and clock-names
> > * clocks now include counting sources
> > * added clock-names "fck", "rtc_x1", "rtc_x3", "extal"
> > * changed 'is a RTC' to 'is an RTC' in commit message
> > * changed "rtc0" to "rtc"
> > * Added clock nodes for RTC_X1 and RTC_X3 pin inputs
> > * each commit now has a log message
> >
> >
> > Chris Brandt (7):
> > rtc: rtc-sh: add support for rza series
> > dt-bindings: rtc: document the rtc-sh bindings
>
> I applied those two, I'll let Simon take the device tree patches.
>
> Thanks!
>
> > ARM: dts: r7s72100: add rtc clock to device tree
> > ARM: dts: r7s72100: add RTC_X clock inputs to device tree
> > ARM: dts: r7s72100: add rtc to device tree
> > ARM: dts: rskrza1: set rtc_x1 clock value
> > ARM: dts: rskrza1: add rtc DT support
Thanks, I have queued up the dts patches.
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Javier Martinez Canillas @ 2017-04-04 17:01 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Aaro Koskinen, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tony Lindgren, Lee Jones, Mark Rutland
In-Reply-To: <CAL_JsqLfo7jbf+fdZnqhUN=RC_Z4=Evn=5XmSr-XMw+952XYaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Rob,
On 04/04/2017 12:54 PM, Rob Herring wrote:
> On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas
> <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>> There are Device Tree source files defining a device node for the
>> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>>
>> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>
>> ---
>>
>> Changes in v4:
>> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
>> - Add information about what functions the device serve (Lee Jones).
>> - Avoid using MFD in Device Tree (Lee Jones).
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
>> new file mode 100644
>> index 000000000000..7df21a2b28ea
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
>> @@ -0,0 +1,21 @@
>> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
>> +
>> +Retu and Tahvo are a multi-function devices found on Nokia Internet
>> +Tablets (770, N800 and N810). The Retu chip provides watchdog timer
>> +and power button control functionalities while Tahvo chip provides
>> +USB transceiver functionality.
>> +
>> +Required properties:
>> +- compatible: "nokia,retu" or "nokia,tahvo"
>> +- reg: Specifies the I2C slave address of the ASIC chip
>
> Missing interrupts here.
>
Right, sorry for missing that. I'll wait for Lee's feedback before
posting a new version in case I missed something else.
> With that:
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
Thanks a lot for your review and acks!
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 2/3] gpio: wm831x: Add basic device tree support
From: Andy Shevchenko @ 2017-04-04 17:00 UTC (permalink / raw)
To: Lee Jones
Cc: Charles Keepax, Rob Herring, Mark Rutland, Linus Walleij,
Alexandre Courbot, devicetree, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, patches
In-Reply-To: <20170323114727.g7huthlsuh7tplxk@dell>
On Thu, Mar 23, 2017 at 1:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Fri, 17 Mar 2017, Charles Keepax wrote:
>
>> Now the wm831x-core has basic DT support we can update this driver to
>> allow use of the GPIOs within a device tree system.
>>
>> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>>
>> No changes since v4, still should go through Lee's tree.
>>
>> Thanks,
>> Charles
>>
>> drivers/gpio/gpio-wm831x.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Applied, thanks.
>> +#ifdef CONFIG_OF_GPIO
>> + wm831x_gpio->gpio_chip.of_node = wm831x->dev->of_node;
>> +#endif
Just a bit of off topic.
If we can use struct fwnode_handle we might get rid of all those
CONFIG_OF_GPIO in the drivers.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it
From: Rob Herring @ 2017-04-04 16:54 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel@vger.kernel.org, Aaro Koskinen,
devicetree@vger.kernel.org, Tony Lindgren, Lee Jones,
Benoît Cousson, Wolfram Sang, Mark Rutland, linux-omap,
Russell King, linux-arm-kernel@lists.infradead.org,
linux-i2c@vger.kernel.org
In-Reply-To: <20170404153036.6651-1-javier@osg.samsung.com>
On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello,
>
> This series add OF device ID tables to mfd I2C drivers whose devices are
> either used in Device Tree source files or are listed in binding docs as
> a compatible string.
For the series,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: sun4i: Add CAN node
From: Patrick Menschel @ 2017-04-04 16:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel, linux-can
In-Reply-To: <20170404154018.6phu2udfgwuzklkk@lukather>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
Am 04.04.2017 um 17:40 schrieb Maxime Ripard:
> On Mon, Apr 03, 2017 at 07:00:11PM +0200, Patrick Menschel wrote:
>> The A10 SoC has an on-board CAN controller.
>> This patch adds the device node.
>>
>> This patch is adapted from the description in
>> Documentation/devicetree/bindings/net/can/sun4i_can.txt
>>
>> Signed-off-by: Patrick Menschel <menschel.p@posteo.de>
>> ---
>> arch/arm/boot/dts/sun4i-a10.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
>> index ba20b48..7c559e7 100644
>> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
>> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
>> @@ -1313,6 +1313,14 @@
>> #size-cells = <0>;
>> };
>>
>> + can0: can@01c2bc00 {
>> + compatible = "allwinner,sun4i-a10-can";
>> + reg = <0x01c2bc00 0x400>;
>> + interrupts = <26>;
>> + clocks = <&apb1_gates 4>;
>> + status = "disabled";
>> + };
>> +
> This wasn't ordered properly. Fixed and applied.
>
>
Now that you mention it, ps20 and ps21 do not follow follow the rising
address order.
uart7: serial@01c29c00 {
...
i2c0: i2c@01c2ac00 {
...
i2c1: i2c@01c2b000 {
...
i2c2: i2c@01c2b400 {
...
can0: can@01c2bc00 {
...
ps20: ps2@01c2a000 {
....
ps21: ps2@01c2a400 {
...
The correct order would be
uart7, ps20, ps21, i2c0, i2c1, i2c2, can0 .
I'll fix that in patch v4.
Thanks,
Patrick
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3709 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Rob Herring @ 2017-04-04 16:54 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel@vger.kernel.org, Aaro Koskinen,
devicetree@vger.kernel.org, Tony Lindgren, Lee Jones,
Mark Rutland
In-Reply-To: <20170404153036.6651-2-javier@osg.samsung.com>
On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> There are Device Tree source files defining a device node for the
> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v4:
> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
> - Add information about what functions the device serve (Lee Jones).
> - Avoid using MFD in Device Tree (Lee Jones).
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
> new file mode 100644
> index 000000000000..7df21a2b28ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
> @@ -0,0 +1,21 @@
> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
> +
> +Retu and Tahvo are a multi-function devices found on Nokia Internet
> +Tablets (770, N800 and N810). The Retu chip provides watchdog timer
> +and power button control functionalities while Tahvo chip provides
> +USB transceiver functionality.
> +
> +Required properties:
> +- compatible: "nokia,retu" or "nokia,tahvo"
> +- reg: Specifies the I2C slave address of the ASIC chip
Missing interrupts here.
With that:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
From: Guenter Roeck @ 2017-04-04 16:30 UTC (permalink / raw)
To: Jaghathiswari Rankappagounder Natarajan, joel, jdelvare,
linux-hwmon, linux-kernel, openbmc, corbet, linux-doc, robh+dt,
mark.rutland, devicetree
In-Reply-To: <6c02a301-fe8f-3a70-465b-ef7de8864c47@roeck-us.net>
On 04/04/2017 05:55 AM, Guenter Roeck wrote:
> On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:
>> The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
>> The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
>> inputs.
>> The device driver matches on the device tree node. The configuration
>> values are read from the device tree and written to the respective registers.
>> The driver provides a sysfs entries through which the user can
>> configure the duty-cycle value (ranging from 0 to 100 percent) and read
>> the fan tach rpm value.
>>
>> Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
>
> Applied.
>
Follow-up: Sparse complains as follows.
drivers/hwmon/aspeed-pwm-tacho.c:156:14: warning: symbol 'regs' was not declared. Should it be static?
drivers/hwmon/aspeed-pwm-tacho.c:324:30: warning: incorrect type in initializer (different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:324:30: expected void [noderef] <asn:2>*regs
drivers/hwmon/aspeed-pwm-tacho.c:324:30: got void *context
drivers/hwmon/aspeed-pwm-tacho.c:333:30: warning: incorrect type in initializer (different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:333:30: expected void [noderef] <asn:2>*regs
drivers/hwmon/aspeed-pwm-tacho.c:333:30: got void *context
drivers/hwmon/aspeed-pwm-tacho.c:516:25: warning: dubious: !x & !y
drivers/hwmon/aspeed-pwm-tacho.c:793:24: warning: incorrect type in argument 3 (different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:793:24: expected void *bus_context
drivers/hwmon/aspeed-pwm-tacho.c:793:24: got void [noderef] <asn:2>*[assigned] regs
Can you please look into this and send me a follow-up patch ?
156 seems unnecessary/unused, 324, 333, and 793 might need a typecast, 516 is really fishy.
Thanks,
Guenter
> Thanks,
> Guenter
>
>> ---
>> v6
>> - Corrected odd line breaks
>> - Changed upto to up to
>> - Dropped unrelated changes
>> - Removed struct and used regs pointer directly
>> - Made groups to be null terminated
>> - Made correction in calculation of val/raw_data
>> - Removed else after return
>> - Removed unnecessary continuation lines
>>
>> v5:
>> - Changed the driver to suit the changes in the device tree documentation
>>
>> v4:
>> - Modified this driver to suit the representation in the devicetree
>>
>> v3:
>> - Only sent out device tree documentation; did not send this driver
>>
>> v2:
>> - Used BIT()
>> - Used regmap
>> - Avoided division when raw data is 0
>> - Removed empty lines between declaration
>> - Removed macros; Used two attribute groups and used is_visible callback
>> - Returned error when properties are undefined
>> - Removed .owner field
>> - Used PTR_ERR_OR_ZERO
>> - Removed explicit of_node_put for child nodes
>>
>> Documentation/hwmon/aspeed-pwm-tacho | 22 +
>> drivers/hwmon/Kconfig | 9 +
>> drivers/hwmon/Makefile | 1 +
>> drivers/hwmon/aspeed-pwm-tacho.c | 846 +++++++++++++++++++++++++++++++++++
>> 4 files changed, 878 insertions(+)
>> create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
>> create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c
>>
>> diff --git a/Documentation/hwmon/aspeed-pwm-tacho b/Documentation/hwmon/aspeed-pwm-tacho
>> new file mode 100644
>> index 000000000000..7cfb34977460
>> --- /dev/null
>> +++ b/Documentation/hwmon/aspeed-pwm-tacho
>> @@ -0,0 +1,22 @@
>> +Kernel driver aspeed-pwm-tacho
>> +==============================
>> +
>> +Supported chips:
>> + ASPEED AST2400/2500
>> +
>> +Authors:
>> + <jaghu@google.com>
>> +
>> +Description:
>> +------------
>> +This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
>> +controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
>> +controller supports up to 16 tachometer inputs.
>> +
>> +The driver provides the following sensor accesses in sysfs:
>> +
>> +fanX_input ro provide current fan rotation value in RPM as reported
>> + by the fan to the device.
>> +
>> +pwmX rw get or set PWM fan control value. This is an integer
>> + value between 0(off) and 255(full speed).
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 45cef3d2c75c..757b5b0705bf 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -341,6 +341,15 @@ config SENSORS_ASB100
>> This driver can also be built as a module. If so, the module
>> will be called asb100.
>>
>> +config SENSORS_ASPEED
>> + tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
>> + help
>> + This driver provides support for ASPEED AST2400/AST2500 PWM
>> + and Fan Tacho controllers.
>> +
>> + This driver can also be built as a module. If so, the module
>> + will be called aspeed_pwm_tacho.
>> +
>> config SENSORS_ATXP1
>> tristate "Attansic ATXP1 VID controller"
>> depends on I2C
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index aecf4ba17460..83025cc9bb45 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
>> obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
>> obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
>> obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
>> +obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
>> obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
>> obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
>> obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
>> diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
>> new file mode 100644
>> index 000000000000..29010ad94208
>> --- /dev/null
>> +++ b/drivers/hwmon/aspeed-pwm-tacho.c
>> @@ -0,0 +1,846 @@
>> +/*
>> + * Copyright (c) 2016 Google, Inc
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 or later as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/delay.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/regmap.h>
>> +
>> +/* ASPEED PWM & FAN Tach Register Definition */
>> +#define ASPEED_PTCR_CTRL 0x00
>> +#define ASPEED_PTCR_CLK_CTRL 0x04
>> +#define ASPEED_PTCR_DUTY0_CTRL 0x08
>> +#define ASPEED_PTCR_DUTY1_CTRL 0x0c
>> +#define ASPEED_PTCR_TYPEM_CTRL 0x10
>> +#define ASPEED_PTCR_TYPEM_CTRL1 0x14
>> +#define ASPEED_PTCR_TYPEN_CTRL 0x18
>> +#define ASPEED_PTCR_TYPEN_CTRL1 0x1c
>> +#define ASPEED_PTCR_TACH_SOURCE 0x20
>> +#define ASPEED_PTCR_TRIGGER 0x28
>> +#define ASPEED_PTCR_RESULT 0x2c
>> +#define ASPEED_PTCR_INTR_CTRL 0x30
>> +#define ASPEED_PTCR_INTR_STS 0x34
>> +#define ASPEED_PTCR_TYPEM_LIMIT 0x38
>> +#define ASPEED_PTCR_TYPEN_LIMIT 0x3C
>> +#define ASPEED_PTCR_CTRL_EXT 0x40
>> +#define ASPEED_PTCR_CLK_CTRL_EXT 0x44
>> +#define ASPEED_PTCR_DUTY2_CTRL 0x48
>> +#define ASPEED_PTCR_DUTY3_CTRL 0x4c
>> +#define ASPEED_PTCR_TYPEO_CTRL 0x50
>> +#define ASPEED_PTCR_TYPEO_CTRL1 0x54
>> +#define ASPEED_PTCR_TACH_SOURCE_EXT 0x60
>> +#define ASPEED_PTCR_TYPEO_LIMIT 0x78
>> +
>> +/* ASPEED_PTCR_CTRL : 0x00 - General Control Register */
>> +#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART1 15
>> +#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART2 6
>> +#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_MASK (BIT(7) | BIT(15))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART1 14
>> +#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART2 5
>> +#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_MASK (BIT(6) | BIT(14))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART1 13
>> +#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART2 4
>> +#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_MASK (BIT(5) | BIT(13))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART1 12
>> +#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART2 3
>> +#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_MASK (BIT(4) | BIT(12))
>> +
>> +#define ASPEED_PTCR_CTRL_FAN_NUM_EN(x) BIT(16 + (x))
>> +
>> +#define ASPEED_PTCR_CTRL_PWMD_EN BIT(11)
>> +#define ASPEED_PTCR_CTRL_PWMC_EN BIT(10)
>> +#define ASPEED_PTCR_CTRL_PWMB_EN BIT(9)
>> +#define ASPEED_PTCR_CTRL_PWMA_EN BIT(8)
>> +
>> +#define ASPEED_PTCR_CTRL_CLK_SRC BIT(1)
>> +#define ASPEED_PTCR_CTRL_CLK_EN BIT(0)
>> +
>> +/* ASPEED_PTCR_CLK_CTRL : 0x04 - Clock Control Register */
>> +/* TYPE N */
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEN_MASK GENMASK(31, 16)
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEN_UNIT 24
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEN_H 20
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEN_L 16
>> +/* TYPE M */
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEM_MASK GENMASK(15, 0)
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEM_UNIT 8
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEM_H 4
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEM_L 0
>> +
>> +/*
>> + * ASPEED_PTCR_DUTY_CTRL/1/2/3 : 0x08/0x0C/0x48/0x4C - PWM-FAN duty control
>> + * 0/1/2/3 register
>> + */
>> +#define DUTY_CTRL_PWM2_FALL_POINT 24
>> +#define DUTY_CTRL_PWM2_RISE_POINT 16
>> +#define DUTY_CTRL_PWM2_RISE_FALL_MASK GENMASK(31, 16)
>> +#define DUTY_CTRL_PWM1_FALL_POINT 8
>> +#define DUTY_CTRL_PWM1_RISE_POINT 0
>> +#define DUTY_CTRL_PWM1_RISE_FALL_MASK GENMASK(15, 0)
>> +
>> +/* ASPEED_PTCR_TYPEM_CTRL : 0x10/0x18/0x50 - Type M/N/O Ctrl 0 Register */
>> +#define TYPE_CTRL_FAN_MASK (GENMASK(5, 1) | GENMASK(31, 16))
>> +#define TYPE_CTRL_FAN1_MASK GENMASK(31, 0)
>> +#define TYPE_CTRL_FAN_PERIOD 16
>> +#define TYPE_CTRL_FAN_MODE 4
>> +#define TYPE_CTRL_FAN_DIVISION 1
>> +#define TYPE_CTRL_FAN_TYPE_EN 1
>> +
>> +/* ASPEED_PTCR_TACH_SOURCE : 0x20/0x60 - Tach Source Register */
>> +/* bit [0,1] at 0x20, bit [2] at 0x60 */
>> +#define TACH_PWM_SOURCE_BIT01(x) ((x) * 2)
>> +#define TACH_PWM_SOURCE_BIT2(x) ((x) * 2)
>> +#define TACH_PWM_SOURCE_MASK_BIT01(x) (0x3 << ((x) * 2))
>> +#define TACH_PWM_SOURCE_MASK_BIT2(x) BIT((x) * 2)
>> +
>> +/* ASPEED_PTCR_RESULT : 0x2c - Result Register */
>> +#define RESULT_STATUS_MASK BIT(31)
>> +#define RESULT_VALUE_MASK 0xfffff
>> +
>> +/* ASPEED_PTCR_CTRL_EXT : 0x40 - General Control Extension #1 Register */
>> +#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART1 15
>> +#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART2 6
>> +#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_MASK (BIT(7) | BIT(15))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART1 14
>> +#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART2 5
>> +#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_MASK (BIT(6) | BIT(14))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART1 13
>> +#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART2 4
>> +#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_MASK (BIT(5) | BIT(13))
>> +
>> +#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART1 12
>> +#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART2 3
>> +#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_MASK (BIT(4) | BIT(12))
>> +
>> +#define ASPEED_PTCR_CTRL_PWMH_EN BIT(11)
>> +#define ASPEED_PTCR_CTRL_PWMG_EN BIT(10)
>> +#define ASPEED_PTCR_CTRL_PWMF_EN BIT(9)
>> +#define ASPEED_PTCR_CTRL_PWME_EN BIT(8)
>> +
>> +/* ASPEED_PTCR_CLK_EXT_CTRL : 0x44 - Clock Control Extension #1 Register */
>> +/* TYPE O */
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEO_MASK GENMASK(15, 0)
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEO_UNIT 8
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEO_H 4
>> +#define ASPEED_PTCR_CLK_CTRL_TYPEO_L 0
>> +
>> +#define PWM_MAX 255
>> +
>> +#define M_PWM_DIV_H 0x00
>> +#define M_PWM_DIV_L 0x05
>> +#define M_PWM_PERIOD 0x5F
>> +#define M_TACH_CLK_DIV 0x00
>> +#define M_TACH_MODE 0x00
>> +#define M_TACH_UNIT 0x1000
>> +#define INIT_FAN_CTRL 0xFF
>> +
>> +void __iomem *regs;
>> +
>> +struct aspeed_pwm_tacho_data {
>> + struct regmap *regmap;
>> + unsigned long clk_freq;
>> + bool pwm_present[8];
>> + bool fan_tach_present[16];
>> + u8 type_pwm_clock_unit[3];
>> + u8 type_pwm_clock_division_h[3];
>> + u8 type_pwm_clock_division_l[3];
>> + u8 type_fan_tach_clock_division[3];
>> + u16 type_fan_tach_unit[3];
>> + u8 pwm_port_type[8];
>> + u8 pwm_port_fan_ctrl[8];
>> + u8 fan_tach_ch_source[16];
>> + const struct attribute_group *groups[3];
>> +};
>> +
>> +enum type { TYPEM, TYPEN, TYPEO };
>> +
>> +struct type_params {
>> + u32 l_value;
>> + u32 h_value;
>> + u32 unit_value;
>> + u32 clk_ctrl_mask;
>> + u32 clk_ctrl_reg;
>> + u32 ctrl_reg;
>> + u32 ctrl_reg1;
>> +};
>> +
>> +static const struct type_params type_params[] = {
>> + [TYPEM] = {
>> + .l_value = ASPEED_PTCR_CLK_CTRL_TYPEM_L,
>> + .h_value = ASPEED_PTCR_CLK_CTRL_TYPEM_H,
>> + .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEM_UNIT,
>> + .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEM_MASK,
>> + .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL,
>> + .ctrl_reg = ASPEED_PTCR_TYPEM_CTRL,
>> + .ctrl_reg1 = ASPEED_PTCR_TYPEM_CTRL1,
>> + },
>> + [TYPEN] = {
>> + .l_value = ASPEED_PTCR_CLK_CTRL_TYPEN_L,
>> + .h_value = ASPEED_PTCR_CLK_CTRL_TYPEN_H,
>> + .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEN_UNIT,
>> + .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEN_MASK,
>> + .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL,
>> + .ctrl_reg = ASPEED_PTCR_TYPEN_CTRL,
>> + .ctrl_reg1 = ASPEED_PTCR_TYPEN_CTRL1,
>> + },
>> + [TYPEO] = {
>> + .l_value = ASPEED_PTCR_CLK_CTRL_TYPEO_L,
>> + .h_value = ASPEED_PTCR_CLK_CTRL_TYPEO_H,
>> + .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEO_UNIT,
>> + .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEO_MASK,
>> + .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL_EXT,
>> + .ctrl_reg = ASPEED_PTCR_TYPEO_CTRL,
>> + .ctrl_reg1 = ASPEED_PTCR_TYPEO_CTRL1,
>> + }
>> +};
>> +
>> +enum pwm_port { PWMA, PWMB, PWMC, PWMD, PWME, PWMF, PWMG, PWMH };
>> +
>> +struct pwm_port_params {
>> + u32 pwm_en;
>> + u32 ctrl_reg;
>> + u32 type_part1;
>> + u32 type_part2;
>> + u32 type_mask;
>> + u32 duty_ctrl_rise_point;
>> + u32 duty_ctrl_fall_point;
>> + u32 duty_ctrl_reg;
>> + u32 duty_ctrl_rise_fall_mask;
>> +};
>> +
>> +static const struct pwm_port_params pwm_port_params[] = {
>> + [PWMA] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMA_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY0_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
>> + },
>> + [PWMB] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMB_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY0_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
>> + },
>> + [PWMC] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMC_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY1_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
>> + },
>> + [PWMD] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMD_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY1_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
>> + },
>> + [PWME] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWME_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWME_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY2_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
>> + },
>> + [PWMF] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMF_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY2_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
>> + },
>> + [PWMG] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMG_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY3_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
>> + },
>> + [PWMH] = {
>> + .pwm_en = ASPEED_PTCR_CTRL_PWMH_EN,
>> + .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
>> + .type_part1 = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART1,
>> + .type_part2 = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART2,
>> + .type_mask = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_MASK,
>> + .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
>> + .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
>> + .duty_ctrl_reg = ASPEED_PTCR_DUTY3_CTRL,
>> + .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
>> + }
>> +};
>> +
>> +static int regmap_aspeed_pwm_tacho_reg_write(void *context, unsigned int reg,
>> + unsigned int val)
>> +{
>> + void __iomem *regs = context;
>> +
>> + writel(val, regs + reg);
>> + return 0;
>> +}
>> +
>> +static int regmap_aspeed_pwm_tacho_reg_read(void *context, unsigned int reg,
>> + unsigned int *val)
>> +{
>> + void __iomem *regs = context;
>> +
>> + *val = readl(regs + reg);
>> + return 0;
>> +}
>> +
>> +static const struct regmap_config aspeed_pwm_tacho_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> + .max_register = ASPEED_PTCR_TYPEO_LIMIT,
>> + .reg_write = regmap_aspeed_pwm_tacho_reg_write,
>> + .reg_read = regmap_aspeed_pwm_tacho_reg_read,
>> + .fast_io = true,
>> +};
>> +
>> +static void aspeed_set_clock_enable(struct regmap *regmap, bool val)
>> +{
>> + regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
>> + ASPEED_PTCR_CTRL_CLK_EN,
>> + val ? ASPEED_PTCR_CTRL_CLK_EN : 0);
>> +}
>> +
>> +static void aspeed_set_clock_source(struct regmap *regmap, int val)
>> +{
>> + regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
>> + ASPEED_PTCR_CTRL_CLK_SRC,
>> + val ? ASPEED_PTCR_CTRL_CLK_SRC : 0);
>> +}
>> +
>> +static void aspeed_set_pwm_clock_values(struct regmap *regmap, u8 type,
>> + u8 div_high, u8 div_low, u8 unit)
>> +{
>> + u32 reg_value = ((div_high << type_params[type].h_value) |
>> + (div_low << type_params[type].l_value) |
>> + (unit << type_params[type].unit_value));
>> +
>> + regmap_update_bits(regmap, type_params[type].clk_ctrl_reg,
>> + type_params[type].clk_ctrl_mask, reg_value);
>> +}
>> +
>> +static void aspeed_set_pwm_port_enable(struct regmap *regmap, u8 pwm_port,
>> + bool enable)
>> +{
>> + regmap_update_bits(regmap, pwm_port_params[pwm_port].ctrl_reg,
>> + pwm_port_params[pwm_port].pwm_en,
>> + enable ? pwm_port_params[pwm_port].pwm_en : 0);
>> +}
>> +
>> +static void aspeed_set_pwm_port_type(struct regmap *regmap,
>> + u8 pwm_port, u8 type)
>> +{
>> + u32 reg_value = (type & 0x1) << pwm_port_params[pwm_port].type_part1;
>> +
>> + reg_value |= (type & 0x2) << pwm_port_params[pwm_port].type_part2;
>> +
>> + regmap_update_bits(regmap, pwm_port_params[pwm_port].ctrl_reg,
>> + pwm_port_params[pwm_port].type_mask, reg_value);
>> +}
>> +
>> +static void aspeed_set_pwm_port_duty_rising_falling(struct regmap *regmap,
>> + u8 pwm_port, u8 rising,
>> + u8 falling)
>> +{
>> + u32 reg_value = (rising <<
>> + pwm_port_params[pwm_port].duty_ctrl_rise_point);
>> + reg_value |= (falling <<
>> + pwm_port_params[pwm_port].duty_ctrl_fall_point);
>> +
>> + regmap_update_bits(regmap, pwm_port_params[pwm_port].duty_ctrl_reg,
>> + pwm_port_params[pwm_port].duty_ctrl_rise_fall_mask,
>> + reg_value);
>> +}
>> +
>> +static void aspeed_set_tacho_type_enable(struct regmap *regmap, u8 type,
>> + bool enable)
>> +{
>> + regmap_update_bits(regmap, type_params[type].ctrl_reg,
>> + TYPE_CTRL_FAN_TYPE_EN,
>> + enable ? TYPE_CTRL_FAN_TYPE_EN : 0);
>> +}
>> +
>> +static void aspeed_set_tacho_type_values(struct regmap *regmap, u8 type,
>> + u8 mode, u16 unit, u8 division)
>> +{
>> + u32 reg_value = ((mode << TYPE_CTRL_FAN_MODE) |
>> + (unit << TYPE_CTRL_FAN_PERIOD) |
>> + (division << TYPE_CTRL_FAN_DIVISION));
>> +
>> + regmap_update_bits(regmap, type_params[type].ctrl_reg,
>> + TYPE_CTRL_FAN_MASK, reg_value);
>> + regmap_update_bits(regmap, type_params[type].ctrl_reg1,
>> + TYPE_CTRL_FAN1_MASK, unit << 16);
>> +}
>> +
>> +static void aspeed_set_fan_tach_ch_enable(struct regmap *regmap, u8 fan_tach_ch,
>> + bool enable)
>> +{
>> + regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
>> + ASPEED_PTCR_CTRL_FAN_NUM_EN(fan_tach_ch),
>> + enable ?
>> + ASPEED_PTCR_CTRL_FAN_NUM_EN(fan_tach_ch) : 0);
>> +}
>> +
>> +static void aspeed_set_fan_tach_ch_source(struct regmap *regmap, u8 fan_tach_ch,
>> + u8 fan_tach_ch_source)
>> +{
>> + u32 reg_value1 = ((fan_tach_ch_source & 0x3) <<
>> + TACH_PWM_SOURCE_BIT01(fan_tach_ch));
>> + u32 reg_value2 = (((fan_tach_ch_source & 0x4) >> 2) <<
>> + TACH_PWM_SOURCE_BIT2(fan_tach_ch));
>> +
>> + regmap_update_bits(regmap, ASPEED_PTCR_TACH_SOURCE,
>> + TACH_PWM_SOURCE_MASK_BIT01(fan_tach_ch),
>> + reg_value1);
>> +
>> + regmap_update_bits(regmap, ASPEED_PTCR_TACH_SOURCE_EXT,
>> + TACH_PWM_SOURCE_MASK_BIT2(fan_tach_ch),
>> + reg_value2);
>> +}
>> +
>> +static void aspeed_set_pwm_port_fan_ctrl(struct aspeed_pwm_tacho_data *priv,
>> + u8 index, u8 fan_ctrl)
>> +{
>> + u16 period, dc_time_on;
>> +
>> + period = priv->type_pwm_clock_unit[priv->pwm_port_type[index]];
>> + period += 1;
>> + dc_time_on = (fan_ctrl * period) / PWM_MAX;
>> +
>> + if (dc_time_on == 0) {
>> + aspeed_set_pwm_port_enable(priv->regmap, index, false);
>> + } else {
>> + if (dc_time_on == period)
>> + dc_time_on = 0;
>> +
>> + aspeed_set_pwm_port_duty_rising_falling(priv->regmap, index, 0,
>> + dc_time_on);
>> + aspeed_set_pwm_port_enable(priv->regmap, index, true);
>> + }
>> +}
>> +
>> +static u32 aspeed_get_fan_tach_ch_measure_period(struct aspeed_pwm_tacho_data
>> + *priv, u8 type)
>> +{
>> + u32 clk;
>> + u16 tacho_unit;
>> + u8 clk_unit, div_h, div_l, tacho_div;
>> +
>> + clk = priv->clk_freq;
>> + clk_unit = priv->type_pwm_clock_unit[type];
>> + div_h = priv->type_pwm_clock_division_h[type];
>> + div_h = 0x1 << div_h;
>> + div_l = priv->type_pwm_clock_division_l[type];
>> + if (div_l == 0)
>> + div_l = 1;
>> + else
>> + div_l = div_l * 2;
>> +
>> + tacho_unit = priv->type_fan_tach_unit[type];
>> + tacho_div = priv->type_fan_tach_clock_division[type];
>> +
>> + tacho_div = 0x4 << (tacho_div * 2);
>> + return clk / (clk_unit * div_h * div_l * tacho_div * tacho_unit);
>> +}
>> +
>> +static u32 aspeed_get_fan_tach_ch_rpm(struct aspeed_pwm_tacho_data *priv,
>> + u8 fan_tach_ch)
>> +{
>> + u32 raw_data, tach_div, clk_source, timeout = 0, sec, val;
>> + u8 fan_tach_ch_source, type;
>> +
>> + regmap_write(priv->regmap, ASPEED_PTCR_TRIGGER, 0);
>> + regmap_write(priv->regmap, ASPEED_PTCR_TRIGGER, 0x1 << fan_tach_ch);
>> +
>> + fan_tach_ch_source = priv->fan_tach_ch_source[fan_tach_ch];
>> + type = priv->pwm_port_type[fan_tach_ch_source];
>> +
>> + sec = (1000 / aspeed_get_fan_tach_ch_measure_period(priv, type));
>> +
>> + msleep(sec);
>> +
>> + while (!(regmap_read(priv->regmap, ASPEED_PTCR_RESULT, &val))
>> + & !(val & RESULT_STATUS_MASK)) {
>> + timeout++;
>> + if (timeout > 1)
>> + return 0;
>> + msleep(sec);
>> + }
>> +
>> + raw_data = val & RESULT_VALUE_MASK;
>> + tach_div = priv->type_fan_tach_clock_division[type];
>> + tach_div = 0x4 << (tach_div * 2);
>> + clk_source = priv->clk_freq;
>> +
>> + if (raw_data == 0)
>> + return 0;
>> +
>> + return (clk_source * 60) / (2 * raw_data * tach_div);
>> +}
>> +
>> +static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
>> + int index = sensor_attr->index;
>> + int ret;
>> + struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
>> + long fan_ctrl;
>> +
>> + ret = kstrtol(buf, 10, &fan_ctrl);
>> + if (ret != 0)
>> + return ret;
>> +
>> + if (fan_ctrl < 0 || fan_ctrl > PWM_MAX)
>> + return -EINVAL;
>> +
>> + if (priv->pwm_port_fan_ctrl[index] == fan_ctrl)
>> + return count;
>> +
>> + priv->pwm_port_fan_ctrl[index] = fan_ctrl;
>> + aspeed_set_pwm_port_fan_ctrl(priv, index, fan_ctrl);
>> +
>> + return count;
>> +}
>> +
>> +static ssize_t show_pwm(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
>> + int index = sensor_attr->index;
>> + struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
>> +
>> + return sprintf(buf, "%u\n", priv->pwm_port_fan_ctrl[index]);
>> +}
>> +
>> +static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
>> + int index = sensor_attr->index;
>> + u32 rpm;
>> + struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
>> +
>> + rpm = aspeed_get_fan_tach_ch_rpm(priv, index);
>> +
>> + return sprintf(buf, "%u\n", rpm);
>> +}
>> +
>> +static umode_t pwm_is_visible(struct kobject *kobj,
>> + struct attribute *a, int index)
>> +{
>> + struct device *dev = container_of(kobj, struct device, kobj);
>> + struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
>> +
>> + if (!priv->pwm_present[index])
>> + return 0;
>> + return a->mode;
>> +}
>> +
>> +static umode_t fan_dev_is_visible(struct kobject *kobj,
>> + struct attribute *a, int index)
>> +{
>> + struct device *dev = container_of(kobj, struct device, kobj);
>> + struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
>> +
>> + if (!priv->fan_tach_present[index])
>> + return 0;
>> + return a->mode;
>> +}
>> +
>> +static SENSOR_DEVICE_ATTR(pwm0, 0644,
>> + show_pwm, set_pwm, 0);
>> +static SENSOR_DEVICE_ATTR(pwm1, 0644,
>> + show_pwm, set_pwm, 1);
>> +static SENSOR_DEVICE_ATTR(pwm2, 0644,
>> + show_pwm, set_pwm, 2);
>> +static SENSOR_DEVICE_ATTR(pwm3, 0644,
>> + show_pwm, set_pwm, 3);
>> +static SENSOR_DEVICE_ATTR(pwm4, 0644,
>> + show_pwm, set_pwm, 4);
>> +static SENSOR_DEVICE_ATTR(pwm5, 0644,
>> + show_pwm, set_pwm, 5);
>> +static SENSOR_DEVICE_ATTR(pwm6, 0644,
>> + show_pwm, set_pwm, 6);
>> +static SENSOR_DEVICE_ATTR(pwm7, 0644,
>> + show_pwm, set_pwm, 7);
>> +static struct attribute *pwm_dev_attrs[] = {
>> + &sensor_dev_attr_pwm0.dev_attr.attr,
>> + &sensor_dev_attr_pwm1.dev_attr.attr,
>> + &sensor_dev_attr_pwm2.dev_attr.attr,
>> + &sensor_dev_attr_pwm3.dev_attr.attr,
>> + &sensor_dev_attr_pwm4.dev_attr.attr,
>> + &sensor_dev_attr_pwm5.dev_attr.attr,
>> + &sensor_dev_attr_pwm6.dev_attr.attr,
>> + &sensor_dev_attr_pwm7.dev_attr.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group pwm_dev_group = {
>> + .attrs = pwm_dev_attrs,
>> + .is_visible = pwm_is_visible,
>> +};
>> +
>> +static SENSOR_DEVICE_ATTR(fan0_input, 0444,
>> + show_rpm, NULL, 0);
>> +static SENSOR_DEVICE_ATTR(fan1_input, 0444,
>> + show_rpm, NULL, 1);
>> +static SENSOR_DEVICE_ATTR(fan2_input, 0444,
>> + show_rpm, NULL, 2);
>> +static SENSOR_DEVICE_ATTR(fan3_input, 0444,
>> + show_rpm, NULL, 3);
>> +static SENSOR_DEVICE_ATTR(fan4_input, 0444,
>> + show_rpm, NULL, 4);
>> +static SENSOR_DEVICE_ATTR(fan5_input, 0444,
>> + show_rpm, NULL, 5);
>> +static SENSOR_DEVICE_ATTR(fan6_input, 0444,
>> + show_rpm, NULL, 6);
>> +static SENSOR_DEVICE_ATTR(fan7_input, 0444,
>> + show_rpm, NULL, 7);
>> +static SENSOR_DEVICE_ATTR(fan8_input, 0444,
>> + show_rpm, NULL, 8);
>> +static SENSOR_DEVICE_ATTR(fan9_input, 0444,
>> + show_rpm, NULL, 9);
>> +static SENSOR_DEVICE_ATTR(fan10_input, 0444,
>> + show_rpm, NULL, 10);
>> +static SENSOR_DEVICE_ATTR(fan11_input, 0444,
>> + show_rpm, NULL, 11);
>> +static SENSOR_DEVICE_ATTR(fan12_input, 0444,
>> + show_rpm, NULL, 12);
>> +static SENSOR_DEVICE_ATTR(fan13_input, 0444,
>> + show_rpm, NULL, 13);
>> +static SENSOR_DEVICE_ATTR(fan14_input, 0444,
>> + show_rpm, NULL, 14);
>> +static SENSOR_DEVICE_ATTR(fan15_input, 0444,
>> + show_rpm, NULL, 15);
>> +static struct attribute *fan_dev_attrs[] = {
>> + &sensor_dev_attr_fan0_input.dev_attr.attr,
>> + &sensor_dev_attr_fan1_input.dev_attr.attr,
>> + &sensor_dev_attr_fan2_input.dev_attr.attr,
>> + &sensor_dev_attr_fan3_input.dev_attr.attr,
>> + &sensor_dev_attr_fan4_input.dev_attr.attr,
>> + &sensor_dev_attr_fan5_input.dev_attr.attr,
>> + &sensor_dev_attr_fan6_input.dev_attr.attr,
>> + &sensor_dev_attr_fan7_input.dev_attr.attr,
>> + &sensor_dev_attr_fan8_input.dev_attr.attr,
>> + &sensor_dev_attr_fan9_input.dev_attr.attr,
>> + &sensor_dev_attr_fan10_input.dev_attr.attr,
>> + &sensor_dev_attr_fan11_input.dev_attr.attr,
>> + &sensor_dev_attr_fan12_input.dev_attr.attr,
>> + &sensor_dev_attr_fan13_input.dev_attr.attr,
>> + &sensor_dev_attr_fan14_input.dev_attr.attr,
>> + &sensor_dev_attr_fan15_input.dev_attr.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group fan_dev_group = {
>> + .attrs = fan_dev_attrs,
>> + .is_visible = fan_dev_is_visible,
>> +};
>> +
>> +/*
>> + * The clock type is type M :
>> + * The PWM frequency = 24MHz / (type M clock division L bit *
>> + * type M clock division H bit * (type M PWM period bit + 1))
>> + */
>> +static void aspeed_create_type(struct aspeed_pwm_tacho_data *priv)
>> +{
>> + priv->type_pwm_clock_division_h[TYPEM] = M_PWM_DIV_H;
>> + priv->type_pwm_clock_division_l[TYPEM] = M_PWM_DIV_L;
>> + priv->type_pwm_clock_unit[TYPEM] = M_PWM_PERIOD;
>> + aspeed_set_pwm_clock_values(priv->regmap, TYPEM, M_PWM_DIV_H,
>> + M_PWM_DIV_L, M_PWM_PERIOD);
>> + aspeed_set_tacho_type_enable(priv->regmap, TYPEM, true);
>> + priv->type_fan_tach_clock_division[TYPEM] = M_TACH_CLK_DIV;
>> + priv->type_fan_tach_unit[TYPEM] = M_TACH_UNIT;
>> + aspeed_set_tacho_type_values(priv->regmap, TYPEM, M_TACH_MODE,
>> + M_TACH_UNIT, M_TACH_CLK_DIV);
>> +}
>> +
>> +static void aspeed_create_pwm_port(struct aspeed_pwm_tacho_data *priv,
>> + u8 pwm_port)
>> +{
>> + aspeed_set_pwm_port_enable(priv->regmap, pwm_port, true);
>> + priv->pwm_present[pwm_port] = true;
>> +
>> + priv->pwm_port_type[pwm_port] = TYPEM;
>> + aspeed_set_pwm_port_type(priv->regmap, pwm_port, TYPEM);
>> +
>> + priv->pwm_port_fan_ctrl[pwm_port] = INIT_FAN_CTRL;
>> + aspeed_set_pwm_port_fan_ctrl(priv, pwm_port, INIT_FAN_CTRL);
>> +}
>> +
>> +static void aspeed_create_fan_tach_channel(struct aspeed_pwm_tacho_data *priv,
>> + u8 *fan_tach_ch,
>> + int count,
>> + u8 pwm_source)
>> +{
>> + u8 val, index;
>> +
>> + for (val = 0; val < count; val++) {
>> + index = fan_tach_ch[val];
>> + aspeed_set_fan_tach_ch_enable(priv->regmap, index, true);
>> + priv->fan_tach_present[index] = true;
>> + priv->fan_tach_ch_source[index] = pwm_source;
>> + aspeed_set_fan_tach_ch_source(priv->regmap, index, pwm_source);
>> + }
>> +}
>> +
>> +static int aspeed_create_fan(struct device *dev,
>> + struct device_node *child,
>> + struct aspeed_pwm_tacho_data *priv)
>> +{
>> + u8 *fan_tach_ch;
>> + u32 pwm_port;
>> + int ret, count;
>> +
>> + ret = of_property_read_u32(child, "reg", &pwm_port);
>> + if (ret)
>> + return ret;
>> + aspeed_create_pwm_port(priv, (u8)pwm_port);
>> +
>> + count = of_property_count_u8_elems(child, "aspeed,fan-tach-ch");
>> + if (count < 1)
>> + return -EINVAL;
>> + fan_tach_ch = devm_kzalloc(dev, sizeof(*fan_tach_ch) * count,
>> + GFP_KERNEL);
>> + if (!fan_tach_ch)
>> + return -ENOMEM;
>> + ret = of_property_read_u8_array(child, "aspeed,fan-tach-ch",
>> + fan_tach_ch, count);
>> + if (ret)
>> + return ret;
>> + aspeed_create_fan_tach_channel(priv, fan_tach_ch, count, pwm_port);
>> +
>> + return 0;
>> +}
>> +
>> +static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np, *child;
>> + struct aspeed_pwm_tacho_data *priv;
>> + void __iomem *regs;
>> + struct resource *res;
>> + struct device *hwmon;
>> + struct clk *clk;
>> + int ret;
>> +
>> + np = dev->of_node;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return -ENOENT;
>> + regs = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(regs))
>> + return PTR_ERR(regs);
>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> + priv->regmap = devm_regmap_init(dev, NULL, regs,
>> + &aspeed_pwm_tacho_regmap_config);
>> + if (IS_ERR(priv->regmap))
>> + return PTR_ERR(priv->regmap);
>> + regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
>> + regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
>> +
>> + clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(clk))
>> + return -ENODEV;
>> + priv->clk_freq = clk_get_rate(clk);
>> + aspeed_set_clock_enable(priv->regmap, true);
>> + aspeed_set_clock_source(priv->regmap, 0);
>> +
>> + aspeed_create_type(priv);
>> +
>> + for_each_child_of_node(np, child) {
>> + ret = aspeed_create_fan(dev, child, priv);
>> + of_node_put(child);
>> + if (ret)
>> + return ret;
>> + }
>> + of_node_put(np);
>> +
>> + priv->groups[0] = &pwm_dev_group;
>> + priv->groups[1] = &fan_dev_group;
>> + priv->groups[2] = NULL;
>> + hwmon = devm_hwmon_device_register_with_groups(dev,
>> + "aspeed_pwm_tacho",
>> + priv, priv->groups);
>> +
>> + return PTR_ERR_OR_ZERO(hwmon);
>> +}
>> +
>> +static const struct of_device_id of_pwm_tacho_match_table[] = {
>> + { .compatible = "aspeed,ast2400-pwm-tacho", },
>> + { .compatible = "aspeed,ast2500-pwm-tacho", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
>> +
>> +static struct platform_driver aspeed_pwm_tacho_driver = {
>> + .probe = aspeed_pwm_tacho_probe,
>> + .driver = {
>> + .name = "aspeed_pwm_tacho",
>> + .of_match_table = of_pwm_tacho_match_table,
>> + },
>> +};
>> +
>> +module_platform_driver(aspeed_pwm_tacho_driver);
>> +
>> +MODULE_AUTHOR("Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>");
>> +MODULE_DESCRIPTION("ASPEED PWM and Fan Tacho device driver");
>> +MODULE_LICENSE("GPL");
>> --
>> 2.12.2.715.g7642488e1d-goog
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v5 0/5] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: santosh.shilimkar @ 2017-04-04 16:17 UTC (permalink / raw)
To: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Santosh Shilimkar, Rob Herring, Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Keerthy, Russell King, Tero Kristo, Sudeep Holla,
Olof Johansson
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
On 4/3/17 7:47 PM, Dave Gerlach wrote:
> Hi,
> This is v5 of the series to add support for TI-SCI Generic PM Domains with
> all ACKs in place and ready for Santosh to merge.
>
Applied to 'for_4.12/soc-pmdomain' and should show up in next. Based on
what arm-soc folks say about the single pull request, i will follow
it up with pull request.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v4 5/6] arm64: dts: rockchip: add dts file for RK3328
From: Heiko Stuebner @ 2017-04-04 16:15 UTC (permalink / raw)
To: cl-TNX95d0MmH7DzftRWevZcw
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
zhengxing-TNX95d0MmH7DzftRWevZcw, andy.yan-TNX95d0MmH7DzftRWevZcw,
jay.xu-TNX95d0MmH7DzftRWevZcw,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
paweljarosz3691-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, wxt-TNX95d0MmH7DzftRWevZcw,
david.wu-TNX95d0MmH7DzftRWevZcw, linux-iio-u79uwXL29TY76Z2rM5mHXA,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
dianders-F7+t8E8rja9g9hUCZPvPmw,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
afaerber-l3A5Bk7waGM, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, arnd-r2nGTMty4D4,
fabio.estevam-3arQi8VN3Tc, zhangqing-TNX95d0MmH7DzftRWevZcw,
kever.yang-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1490607650-18650-5-git-send-email-cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Montag, 27. März 2017, 17:40:49 CEST schrieb cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org:
> From: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> This patch add rk3328-evb.dts for RK3328 evaluation board.
> Tested on RK3328 evb.
>
> Signed-off-by: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
applied for 4.12
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
From: Tony Lindgren @ 2017-04-04 16:11 UTC (permalink / raw)
To: Russell King
Cc: Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Keerthy J, Dave Gerlach
In-Reply-To: <20170328205511.21166-3-d-gerlach-l0cyMroinI0@public.gmane.org>
Russell,
* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [170328 13:57]:
> Certain SoCs like Texas Instruments AM335x and AM437x require parts
> of the EMIF PM code to run late in the suspend sequence from SRAM,
> such as saving and restoring the EMIF context and placing the memory
> into self-refresh.
>
> One requirement for these SoCs to suspend and enter its lowest power
> mode, called DeepSleep0, is that the PER power domain must be shut off.
> Because the EMIF (DDR Controller) resides within this power domain, it
> will lose context during a suspend operation, so we must save it so we
> can restore once we resume. However, we cannot execute this code from
> external memory, as it is not available at this point, so the code must
> be executed late in the suspend path from SRAM.
>
> This patch introduces a ti-emif-sram driver that includes several
> functions written in ARM ASM that are relocatable so the PM SRAM
> code can use them. It also allocates a region of writable SRAM to
> be used by the code running in the executable region of SRAM to save
> and restore the EMIF context. It can export a table containing the
> absolute addresses of the available PM functions so that other SRAM
> code can branch to them. This code is required for suspend/resume on
> AM335x and AM437x to work.
>
> In addition to this, to be able to share data structures between C and
> the ti-emif-sram-pm assembly code, we can automatically generate all of
> the C struct member offsets and sizes as macros by making use of the ARM
> asm-offsets file. In the same header that we define our data structures
> in we also define all the macros in an inline function and by adding a
> call to this in the asm_offsets file all macros are properly generated
> and available to the assembly code without cluttering up the asm-offsets
> file.
>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/kernel/asm-offsets.c | 6 +
> drivers/memory/Kconfig | 10 ++
> drivers/memory/Makefile | 4 +
> drivers/memory/emif.h | 17 ++
> drivers/memory/ti-emif-pm.c | 295 ++++++++++++++++++++++++++++++++++
> drivers/memory/ti-emif-sram-pm.S | 334 +++++++++++++++++++++++++++++++++++++++
> include/linux/ti-emif-sram.h | 143 +++++++++++++++++
> 7 files changed, 809 insertions(+)
> create mode 100644 drivers/memory/ti-emif-pm.c
> create mode 100644 drivers/memory/ti-emif-sram-pm.S
> create mode 100644 include/linux/ti-emif-sram.h
>
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index 608008229c7d..d728b5660e36 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -28,6 +28,7 @@
> #include <asm/vdso_datapage.h>
> #include <asm/hardware/cache-l2x0.h>
> #include <linux/kbuild.h>
> +#include <linux/ti-emif-sram.h>
>
> /*
> * Make sure that the compiler and target are compatible.
> @@ -183,5 +184,10 @@ int main(void)
> #ifdef CONFIG_VDSO
> DEFINE(VDSO_DATA_SIZE, sizeof(union vdso_data_store));
> #endif
> +#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
> + BLANK();
> + ti_emif_offsets();
> +#endif
> +
> return 0;
> }
Does the above look OK to you?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: document rockchip rk3328-evb board
From: Heiko Stuebner @ 2017-04-04 16:10 UTC (permalink / raw)
To: cl
Cc: robh+dt, mark.rutland, zhengxing, andy.yan, jay.xu, matthias.bgg,
paweljarosz3691, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, wsa, linux-i2c, jic23, knaack.h, lars, pmeerw, wxt,
david.wu, linux-iio, shawn.lin, akpm, dianders, yamada.masahiro,
catalin.marinas, will.deacon, afaerber, shawnguo, khilman, arnd,
fabio.estevam, zhangqing, kever.yang
In-Reply-To: <1490607983-5599-1-git-send-email-cl@rock-chips.com>
Am Montag, 27. März 2017, 17:46:23 CEST schrieb cl@rock-chips.com:
> From: Liang Chen <cl@rock-chips.com>
>
> Use "rockchip,rk3328-evb" compatible string for Rockchip RK3328
> evaluation board.
>
> Signed-off-by: Liang Chen <cl@rock-chips.com>
> Acked-by: Rob Herring <robh@kernel.org>
applied after moving the entry above the rk3399-evb.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH v4 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs
From: Heiko Stuebner @ 2017-04-04 16:04 UTC (permalink / raw)
To: cl-TNX95d0MmH7DzftRWevZcw
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
zhengxing-TNX95d0MmH7DzftRWevZcw, andy.yan-TNX95d0MmH7DzftRWevZcw,
jay.xu-TNX95d0MmH7DzftRWevZcw,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
paweljarosz3691-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, wsa-z923LK4zBo2bacvFa/9K2g,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, wxt-TNX95d0MmH7DzftRWevZcw,
david.wu-TNX95d0MmH7DzftRWevZcw, linux-iio-u79uwXL29TY76Z2rM5mHXA,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
dianders-F7+t8E8rja9g9hUCZPvPmw,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
afaerber-l3A5Bk7waGM, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
khilman-rdvid1DuHRBWk0Htik3J/w, arnd-r2nGTMty4D4,
fabio.estevam-3arQi8VN3Tc, zhangqing-TNX95d0MmH7DzftRWevZcw,
kever.yang-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1490607650-18650-4-git-send-email-cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Montag, 27. März 2017, 17:40:48 CEST schrieb cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org:
> From: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> This patch adds core dtsi file for Rockchip RK3328 SoCs.
>
> Signed-off-by: Liang Chen <cl-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
applied for 4.12, with the following list of changes:
- reorder some properties to bring them in alphabetical order
- dropped the status-disabled from the power-controller
power-domain control is a quite essential part of the system, so if
boards really want to disable them, they should do it in their board file
Having power-domains on all the time, is also our default in all other
devicetrees.
- removed #dma-cells from spi0 -> this is not a dma controller
- reword the cru assigned-clocks comment a bit
- fixed sdmmc1_bus4 pins, as indicated by Shawn and after looking up the
correct pins in the manual
And a final question, are you sure about SCLK_PDM becoming a child of the
APLL in your cru assigned-clocks, as the APLL will vary later on with cpufreq
active?
Heiko
^ permalink raw reply
* Re: [PATCH] ARM: dts: am57xx-idk: Add DCAN support
From: Tony Lindgren @ 2017-04-04 15:56 UTC (permalink / raw)
To: Sekhar Nori
Cc: Rob Herring, Mark Rutland, Linux OMAP Mailing List,
Linux ARM Mailing List, Device Tree Mailing List, Schuyler Patton,
Kishon Vijay Abraham I, Franklin S Cooper Jr, Quadros, Roger
In-Reply-To: <042d52f4-3148-0564-a41a-5212ede042d5-l0cyMroinI0@public.gmane.org>
* Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> [170330 07:26]:
> Hi Tony,
>
> On Tuesday 07 March 2017 12:11 AM, Tony Lindgren wrote:
> > * Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> [170221 02:13]:
> >> On Tuesday 21 February 2017 03:30 PM, Sekhar Nori wrote:
> >>> From: Schuyler Patton <spatton-l0cyMroinI0@public.gmane.org>
> >>>
> >>> AM571x IDK and the AM572x IDK use CAN1 interface.
> >>> This patch enables it for both boards.
> >>>
> >>> Tested on AM572x IDK using cansequence.
> >>>
> >>> Signed-off-by: Schuyler Patton <spatton-l0cyMroinI0@public.gmane.org>
> >>> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> >>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
> >>> [nsekhar-l0cyMroinI0@public.gmane.org: move to use DRA7XX_CORE_IOPAD())
> >>> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> >>
> >> I should have noted that although CAN does function on the IDK with this
> >> patch, there are "omap_hwmod: dcan1: _wait_target_disable failed"
> >> messages that come up due to lack of workaround for errata i893[1]
> >>
> >> Roger does have some patches to workaround that errata. If you want to
> >> wait for those patches to be submitted and accepted first, it should be
> >> fine as well.
> >
> > OK let's wait a bit on this then to avoid introducing extra warnings.
>
> Now that Roger's hwmod patches for the DCAN errata are in linux-next,
> this patch can be applied safely. Let me know if you need me to resend it.
No need to resend, applying into omap-for-v4.12/dt-v2.
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/5] Add support for the R_CCU on Allwinner H3/A64 SoCs
From: Maxime Ripard @ 2017-04-04 15:45 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Rob Herring, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170404095100.18649-1-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Tue, Apr 04, 2017 at 05:50:55PM +0800, Icenowy Zheng wrote:
> Allwinner SoCs after sun6i-a31 nearly all have a R_CCU in PRCM part.
> (V3s and R40 do not have it, as they have even no PRCM)
>
> This patch adds support for the ones on H3/A64.
>
> Some clock/reset values are reserved for easier extending the support to
> A31/A23, but for this I think some changes to the PRCM MFD should be made,
> see [1] (Although this is only a sketch).
>
> The r_pio device node is also added for A64, as the driver is already
> merged, and its depends (r_ccu) is now met.
Applied all, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: Document STM32 DCMI bindings
From: Hugues FRUCHET @ 2017-04-04 15:45 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Benjamin Gaignard,
Alexandre TORGUE, linux-kernel@vger.kernel.org, Hans Verkuil,
Maxime Coquelin, Mauro Carvalho Chehab, Yannick FERTRE,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20170403162309.eikbsmfbxw6admdc@rob-hp-laptop>
Thanks Rob for review, find answers below.
On 04/03/2017 06:23 PM, Rob Herring wrote:
> On Thu, Mar 30, 2017 at 05:27:40PM +0200, Hugues Fruchet wrote:
>> This adds documentation of device tree bindings for the STM32 DCMI
>> (Digital Camera Memory Interface).
>>
>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>> ---
>> .../devicetree/bindings/media/st,stm32-dcmi.txt | 85 ++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
>> new file mode 100644
>> index 0000000..8180f63
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
>> @@ -0,0 +1,85 @@
>> +STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
>> +
>> +Required properties:
>> +- compatible: "st,stm32-dcmi"
>
> Same block and same errata on all stm32 variants?
Yes, it is the same IP block on all stm32 variants.
>
>> +- reg: physical base address and length of the registers set for the device
>> +- interrupts: should contain IRQ line for the DCMI
>> +- clocks: list of clock specifiers, corresponding to entries in
>> + the clock-names property
>> +- clock-names: must contain "mclk", which is the DCMI peripherial clock
>> +- resets: reference to a reset controller
>> +- reset-names: see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>> +
>> +DCMI supports a single port node with parallel bus. It should contain one
>> +'port' child node with child 'endpoint' node. Please refer to the bindings
>> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> +
>> +Device node example
>> +-------------------
>> + dcmi: dcmi@50050000 {
>> + compatible = "st,stm32-dcmi";
>> + reg = <0x50050000 0x400>;
>> + interrupts = <78>;
>> + resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
>> + clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
>> + clock-names = "mclk";
>
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&dcmi_pins>;
>
> Not documented.
Fixed in v3.
>
>> + dmas = <&dma2 1 1 0x414 0x3>;
>> + dma-names = "tx";
>
> Not documented.
Fixed in v3.
>
>> + status = "disabled";
>
> Drop status from examples.
Fixed in v3.
>
>> + };
>> +
>> +Board setup example
>
> Please don't split examples. That's just source level details and not
> part of the ABI.
Fixed in v3.
>
>> +-------------------
>> +This example is extracted from STM32F429-EVAL board devicetree.
>> +Please note that on this board, the camera sensor reset & power-down
>> +line level are inverted (so reset is active high and power-down is
>> +active low).
>> +
>> +/ {
>> + [...]
>> + clocks {
>> + clk_ext_camera: clk-ext-camera {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <24000000>;
>> + };
>> + };
>> + [...]
>> +};
>> +
>> +&dcmi {
>> + status = "okay";
>> +
>> + port {
>> + dcmi_0: endpoint@0 {
>> + remote-endpoint = <&ov2640_0>;
>> + bus-width = <8>;
>> + hsync-active = <0>;
>> + vsync-active = <0>;
>> + pclk-sample = <1>;
>> + };
>> + };
>> +};
>> +
>> +&i2c@1 {
>> + [...]
>> + ov2640: camera@30 {
>> + compatible = "ovti,ov2640";
>> + reg = <0x30>;
>> + resetb-gpios = <&stmpegpio 2 GPIO_ACTIVE_HIGH>;
>> + pwdn-gpios = <&stmpegpio 0 GPIO_ACTIVE_LOW>;
>> + clocks = <&clk_ext_camera>;
>> + clock-names = "xvclk";
>> + status = "okay";
>> +
>> + port {
>> + ov2640_0: endpoint {
>> + remote-endpoint = <&dcmi_0>;
>> + };
>> + };
>> + };
>> +};
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH v3 8/8] ARM: configs: stm32: DCMI + OV2640 camera support
From: Hugues Fruchet @ 2017-04-04 15:44 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
Mauro Carvalho Chehab, Hans Verkuil
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-media,
Benjamin Gaignard, Yannick Fertre, Hugues Fruchet
In-Reply-To: <1491320678-17246-1-git-send-email-hugues.fruchet@st.com>
Enable DCMI camera interface and OV2640 camera sensor drivers.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
arch/arm/configs/stm32_defconfig | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 84adc88..3f2e4ce 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -53,6 +53,13 @@ CONFIG_GPIO_STMPE=y
CONFIG_MFD_STMPE=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_USB_SUPPORT is not set
+CONFIG_VIDEO_V4L2=y
+CONFIG_MEDIA_SUBDRV_AUTOSELECT=n
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_VIDEO_STM32_DCMI=y
+CONFIG_VIDEO_OV2640=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
--
1.9.1
^ permalink raw reply related
* [PATCH v3 7/8] ARM: configs: stm32: STMPE1600 GPIO expander
From: Hugues Fruchet @ 2017-04-04 15:44 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
Mauro Carvalho Chehab, Hans Verkuil
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-media,
Benjamin Gaignard, Yannick Fertre, Hugues Fruchet
In-Reply-To: <1491320678-17246-1-git-send-email-hugues.fruchet@st.com>
Enable STMPE1600 GPIO expander.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..84adc88 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -49,6 +49,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
CONFIG_REGULATOR=y
+CONFIG_GPIO_STMPE=y
+CONFIG_MFD_STMPE=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_USB_SUPPORT is not set
CONFIG_NEW_LEDS=y
--
1.9.1
^ permalink raw reply related
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