* Re: [PATCH] arm64: dts: rockchip: fix the memory size of PX5 Evaluation board
From: Heiko Stuebner @ 2017-04-07 21:15 UTC (permalink / raw)
To: Andy Yan
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1491553169-21106-1-git-send-email-andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Freitag, 7. April 2017, 16:19:29 CEST schrieb Andy Yan:
> Commit 122682b2abb6 ("arm64: dts: rockchip: Add PX5 Evaluation board")
> sets the memory size to 2 GB, but this board only has 1 GB DRAM, so change
> it to the correct value here.
>
> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
I've added a
Fixes: 122682b2abb6 ("arm64: dts: rockchip: Add PX5 Evaluation board")
and applied it for 4.12
Thanks
Heiko
--
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 net-next v4 0/5] net-next: dsa: add Mediatek MT7530 support
From: David Miller @ 2017-04-07 20:53 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Landen.Chao-NuS5LvNUpcJWk0Htik3J/w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, objelf-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1491554709-9723-1-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Date: Fri, 7 Apr 2017 16:45:04 +0800
> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
> Mediatek router platforms such as MT7623A or MT7623N which includes 7-port
> Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY. Among these ports,
> The port from 0 to 4 are the user ports connecting with the remote devices
> while the port 5 and 6 are the CPU ports connecting into Mediatek Ethernet
> GMAC.
>
> The patch series integrated Mediatek MT7530 into DSA support which
> includes the most of the essential callbacks such as tag insertion for
> port distinguishing, port control, bridge offloading, STP setup and
> ethtool operations to allow DSA to model each user port into independently
> standalone netdevice as the other DSA driver had done.
Series applied, thanks Sean.
--
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 1/2] leds: Add driver for Qualcomm LPG
From: Bjorn Andersson @ 2017-04-07 20:36 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407133223.GE4756@amd>
On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
> > For the patterns I don't know how a trigger for this would look like,
> > how would setting the pattern of a trigger be propagated down to the
> > hardware?
>
> Well... I'm not sure if we _want_ to do triggers for
> patterns. LED triggers change rather quickly (100 times a second?) so
> doing them in kernel makes sense. Patterns take 10s of seconds, so we
> do not need to handle them in kernel.
>
On any current Qualcomm based phone (using the Qualcomm PMIC to drive
the RGB notification LED) the patterns are hard coded in DeviceTree and
the option you have in runtime is to enable/disable the usage of the
configured pattern and a few knobs of how to traverse the configured
pattern.
When you enter e.g. a low-battery scenario you trigger the red LED to
run its low-battery-pattern and you don't touch it until there's a
higher prio notification (e.g. someone connects the charger).
So in the current implementation patterns "never" changes and they are
triggered only every time you get some event/notification.
A benefit of not using triggers for patterns is that I can assign
patterns to triggered events, e.g. I can configure my LEDs to flash &
fade out when some trigger happens.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Bjorn Andersson @ 2017-04-07 20:26 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Pavel Machek, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <dce7f2b1-8d1d-1c5d-5fa5-54c22b6f4758@gmail.com>
On Mon 03 Apr 13:38 PDT 2017, Jacek Anaszewski wrote:
> On 04/03/2017 09:00 PM, Bjorn Andersson wrote:
[..]
> > For the patterns I don't know how a trigger for this would look like,
> > how would setting the pattern of a trigger be propagated down to the
> > hardware?
>
> We'd need a new op and API similar to blink_set()/led_blink_set().
>
I've tried to find different LED circuits with some sort of pattern
generator in an attempt to figure out how to design this interface, but
turned out to be quite hard to find examples; the three I can compare
are:
* LP5xx series "implements" pattern generation by executing code.
* Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
fixed rate with knobs to configure what happens before starting and
after finishing iterating over the defined values. It does not support
smooth transitions between values.
* AS3676 supports a pattern of 32 values controlling if the output
should be enabled or disabled for each 32.5ms (or 250ms) time period.
The delay before repeating the pattern can be configured. It support
smooth transitions between the states.
So, while I think I see how you would like to architect this interface I
am not sure how to figure out the details.
The pattern definition would have to be expressive enough to support the
features of LP5xx and direct enough to support the limited AS3676. It
would likely have to express transitions, so that the LPG could generate
intermediate steps (and we will have to adapt the resolution of the
ramps based on the other LPGs in the system).
How do we do with patterns that are implementable by the LP5xx but are
not with the LPG? Should we reject those or should we do some sort of
best-effort approach in the kernel?
> >>> Second, there are more issues than just patterns with the RGB
> >>> LED. Most important is ability to set particular colors. You want to
> >>> set the RGB LED to "white", but that does not mean you can set
> >>> red=green=blue=1.0. You want color to look the same on LCD and on the
> >>> LED, which means coefficients for white and some kind of function for
> >>> brightness-to-PWM conversion.
> >>
> >> Shouldn't we leave that entirely to the userspace? Can we come up
> >> with coefficients that will guarantee the same result on all existing
> >> LCD devices?
> >>
> >
> > How about we just force user space perform the 3 writes and save us the
> > cost of another trigger in that case? Configuring the brightness of 3
> > LEDs is not board specific - and even with a RGB-interface we still need
> > to specify which RGB-LED should be controlled.
>
> This is what we have now, so we can live with it. Addition of a new
> RGB trigger would be an improvement of the existing state.
>
If we do the brightness compensation (for e.g. white balance
adjustments) in a trigger then there's added value.
The part where I see this affects the LPG driver is that the brightness
of the patterns might have to be adjusted accordingly - which probably
would be easier to implement if the kernel just exposed the compensation
values to user space.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Dan Williams @ 2017-04-07 20:09 UTC (permalink / raw)
To: Rob Herring
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer,
Satish Patel, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_Jsq+aM+xxbu=3v8_w9Ce+=t_pXmVWuisnckA8_8LOS-ftVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2017-04-07 at 13:48 -0500, Rob Herring wrote:
> On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> > > Turns out that the LL protocol and the TI-ST are the same thing
> > > AFAICT.
> > > The TI-ST adds firmware loading, GPIO control, and shared access
> > > for
> > > NFC, FM radio, etc. For now, we're only implementing what is
> > > needed
> > > for
> > > BT. This mirrors other drivers like BCM and Intel, but uses the
> > > new
> > > serdev bus.
> > >
> > > The firmware loading is greatly simplified by using existing
> > > infrastructure to send commands. It may be a bit slower than the
> > > original code using synchronous functions, but the real
> > > bottleneck is
> > > likely doing firmware load at 115.2kbps.
> >
> > Is there no way to put the TI-specific stuff into a TI UART module
> > rather than building it into the generic one?
>
> In case it's not clear, all of HCI_LL is the TI specific part, not
> just what I'm adding. So you are talking about putting each UART BT
> protocol into a separate module. I'd assume that is doable, but seems
> orthogonal to this patch set. I'd also assume there was some reason
> that was not done already.
Ok, thanks for the explanation. Wasn't clear at all from the file
paths in the source tree; it looked generic.
Dan
--
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 2/3] clk: vc5: Add bindings for IDT VersaClock 5P49V5935
From: Marek Vasut @ 2017-04-07 19:56 UTC (permalink / raw)
To: Alexey Firago, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
geert-Td1EMuHUCqxL1ZNQvxDV9g, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-3-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07/2017 11:12 AM, Alexey Firago wrote:
> IDT VersaClock 5 5P49V5935 has 4 clock outputs, 4 fractional dividers.
> Input clock source can be taken from either integrated crystal or from
> external reference clock.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
I think you want a R-B from Rob on this.
> ---
> .../devicetree/bindings/clock/idt,versaclock5.txt | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> index 87e9c47..53d7e50 100644
> --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> @@ -6,18 +6,21 @@ from 3 to 12 output clocks.
> ==I2C device node==
>
> Required properties:
> -- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933".
> +- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933" ,
> + "idt,5p49v5935".
> - reg: i2c device address, shall be 0x68 or 0x6a.
> - #clock-cells: from common clock binding; shall be set to 1.
> - clocks: from common clock binding; list of parent clock handles,
> - 5p49v5923: (required) either or both of XTAL or CLKIN
> reference clock.
> - - 5p49v5933: (optional) property not present (internal
> + - 5p49v5933 and
> + - 5p49v5935: (optional) property not present (internal
> Xtal used) or CLKIN reference
> clock.
> - clock-names: from common clock binding; clock input names, can be
> - 5p49v5923: (required) either or both of "xin", "clkin".
> - - 5p49v5933: (optional) property not present or "clkin".
> + - 5p49v5933 and
> + - 5p49v5935: (optional) property not present or "clkin".
>
> ==Mapping between clock specifier and physical pins==
>
> @@ -34,6 +37,13 @@ clock specifier, the following mapping applies:
> 1 -- OUT1
> 2 -- OUT4
>
> +5P49V5935:
> + 0 -- OUT0_SEL_I2CB
> + 1 -- OUT1
> + 2 -- OUT2
> + 3 -- OUT3
> + 4 -- OUT4
> +
> ==Example==
>
> /* 25MHz reference crystal */
>
--
Best regards,
Marek Vasut
--
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 3/3] clk: vc5: Add support for IDT VersaClock 5P49V5935
From: Marek Vasut @ 2017-04-07 19:56 UTC (permalink / raw)
To: Alexey Firago, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
geert-Td1EMuHUCqxL1ZNQvxDV9g, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-4-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07/2017 11:12 AM, Alexey Firago wrote:
> Update IDT VersaClock 5 driver to support 5P49V5935. This chip has
> two clock inputs (internal XTAL or external CLKIN), four fractional
> dividers (FODs) and five clock outputs (four universal clock outputs
> and one reference clock output at OUT0_SELB_I2C).
>
> Current driver supports up to 2 FODs and up to 3 clock outputs. This
> patch sets max number of supported FODs to 4 and max number of supported
> clock outputs to 5.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Best regards,
Marek Vasut
--
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 1/3] clk: vc5: Add structure to describe particular chip features
From: Marek Vasut @ 2017-04-07 19:55 UTC (permalink / raw)
To: Alexey Firago, mturquette, sboyd, robh+dt, geert, linux-clk,
devicetree
In-Reply-To: <1491556344-9465-2-git-send-email-alexey_firago@mentor.com>
On 04/07/2017 11:12 AM, Alexey Firago wrote:
> Introduce vc5_chip_info structure to describe features of a particular
> VC5 chip (id, number of FODs, number of outputs, flags).
> For now flags are only used to indicate if chip has internal XTAL.
> vc5_chip_info is set on probe from the matched of_device_id->data.
>
> Also add defines to specify maximum number of FODs and clock outputs
> supported by the driver.
>
> With these changes it should be easier to extend driver to support
> more VC5 models.
>
> Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v4 0/3] clk: Add support for IDT 5P49V5935
From: Marek Vasut @ 2017-04-07 19:55 UTC (permalink / raw)
To: Stephen Boyd, Alexey Firago
Cc: mturquette, robh+dt, geert, linux-clk, devicetree
In-Reply-To: <20170407194013.GD7065@codeaurora.org>
On 04/07/2017 09:40 PM, Stephen Boyd wrote:
> On 04/07, Alexey Firago wrote:
>> This series adds support for IDT VersaClock 5P49V5935 programmable clock
>> generator to the existing clk-versaclock5 driver. Driver is also updated to
>> simplify addition of support for more VersaClock 5 models.
>>
>> Patches were verified on Avnet UltraZed-EG board with IO Carrier Card.
>>
>> Changes in V2:
>> - Introduce vc5_chip_info structure describing chip features
>> - Set vc5_chip_info for the supported chips using clk_vc5_of_match[].data
>> - Add 5P49V5935 support using vc5_chip_info approach
>> - Fix idx comparison in vc5_of_clk_get ('>' to '>=')
>>
>> Changes in V3:
>> - Change type of clk_fod_cnt and clk_out_cnt to unsigned int
>> - Add missed 'const' to vc5_chip_info instance declaration
>> - Use of_device_get_match_data() to initialize vc5_chip_info on probe
>>
>> Changes in V4:
>> - Add 'const' to vc5_chip_info.flags
>
> Could any Reviewed-by tags get carried over? I'll wait for Marek
> to resend them I guess.
>
I'll review the patches ASAP
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v4] regulator: Add driver for voltage controlled regulators
From: Matthias Kaehlcke @ 2017-04-07 19:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson, Brian Norris,
Matthias Kaehlcke
The output voltage of a voltage controlled regulator can be controlled
through the voltage of another regulator. The current version of this
driver assumes that the output voltage is a linear function of the control
voltage.
Signed-off-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v4:
- Use phandle to configure control regulator instead of the regulator name
Changes in v3:
- Pre-calculate limits for OVP-safe downward transitions with a discrete
control regulator
- Use regulator_get_linear_step() and regulator_count_voltages() to
determine if the control regulator is continuous or discrete
- Changed some log messages to start with lowercase character for
consistency
- Misc formatting fixes
Changes in v2:
- Don't configure control regulator as supply
- Added enable/disable ops to turn control regulator on/off
- Use regulator_has_continuous_voltage_range() to determine if control
regulator is continuous or discrete
- Use regulator-min/max-microvolt as output voltage range
- Updated and fixed example in DT bindings
- Updated commit message
.../devicetree/bindings/regulator/vctrl.txt | 49 ++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/vctrl-regulator.c | 546 +++++++++++++++++++++
4 files changed, 603 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/vctrl.txt
create mode 100644 drivers/regulator/vctrl-regulator.c
diff --git a/Documentation/devicetree/bindings/regulator/vctrl.txt b/Documentation/devicetree/bindings/regulator/vctrl.txt
new file mode 100644
index 000000000000..601328d7fdbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/vctrl.txt
@@ -0,0 +1,49 @@
+Bindings for Voltage controlled regulators
+==========================================
+
+Required properties:
+--------------------
+- compatible : must be "vctrl-regulator".
+- regulator-min-microvolt : smallest voltage consumers may set
+- regulator-max-microvolt : largest voltage consumers may set
+- ctrl-supply : The regulator supplying the control voltage.
+- ctrl-voltage-range : an array of two integer values describing the range
+ (min/max) of the control voltage. The values specify
+ the control voltage needed to generate the corresponding
+ regulator-min/max-microvolt output voltage.
+
+Optional properties:
+--------------------
+- ovp-threshold-percent : overvoltage protection (OVP) threshold of the
+ regulator in percent. Some regulators have an OVP
+ circuitry which shuts down the regulator when the
+ actual output voltage deviates beyond a certain
+ margin from the expected value for a given control
+ voltage. On larger voltage decreases this can occur
+ undesiredly since the output voltage does not adjust
+ inmediately to changes in the control voltage. To
+ avoid this situation the vctrl driver breaks down
+ larger voltage decreases into multiple steps, where
+ each step is within the OVP threshold.
+- min-slew-down-rate : Describes how slowly the regulator voltage will decay
+ down in the worst case (lightest expected load).
+ Specified in uV / us (like main regulator ramp rate).
+ This value is required when ovp-threshold-percent is
+ specified.
+
+Example:
+
+ vctrl-reg {
+ compatible = "vctrl-regulator";
+ regulator-name = "vctrl_reg";
+
+ ctrl-supply = <&ctrl_reg>;
+
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1500000>;
+
+ ctrl-voltage-range = <200000 500000>;
+
+ min-slew-down-rate = <225>;
+ ovp-threshold-percent = <16>;
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb29c681..9a090e338a19 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -850,6 +850,13 @@ config REGULATOR_TWL4030
This driver supports the voltage regulators provided by
this family of companion chips.
+config REGULATOR_VCTRL
+ tristate "Voltage controlled regulators"
+ depends on OF
+ help
+ This driver provides support for voltage regulators whose output
+ voltage is controlled by the voltage of another regulator.
+
config REGULATOR_VEXPRESS
tristate "Versatile Express regulators"
depends on VEXPRESS_CONFIG
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e2592a..891dd287f26b 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o twl6030-regulator.o
+obj-$(CONFIG_REGULATOR_VCTRL) += vctrl-regulator.o
obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress-regulator.o
obj-$(CONFIG_REGULATOR_WM831X) += wm831x-dcdc.o
obj-$(CONFIG_REGULATOR_WM831X) += wm831x-isink.o
diff --git a/drivers/regulator/vctrl-regulator.c b/drivers/regulator/vctrl-regulator.c
new file mode 100644
index 000000000000..6baadef0ed74
--- /dev/null
+++ b/drivers/regulator/vctrl-regulator.c
@@ -0,0 +1,546 @@
+/*
+ * Driver for voltage controller regulators
+ *
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
+#include <linux/sort.h>
+
+struct vctrl_voltage_range {
+ int min_uV;
+ int max_uV;
+};
+
+struct vctrl_voltage_ranges {
+ struct vctrl_voltage_range ctrl;
+ struct vctrl_voltage_range out;
+};
+
+struct vctrl_voltage_table {
+ int ctrl;
+ int out;
+ int ovp_min_sel;
+};
+
+struct vctrl_data {
+ struct regulator_dev *rdev;
+ struct regulator_desc desc;
+ struct regulator *ctrl_reg;
+ bool enabled;
+ unsigned int min_slew_down_rate;
+ unsigned int ovp_threshold;
+ struct vctrl_voltage_ranges vrange;
+ struct vctrl_voltage_table *vtable;
+ unsigned int sel;
+};
+
+static int vctrl_calc_ctrl_voltage(struct vctrl_data *vctrl, int out_uV)
+{
+ struct vctrl_voltage_range *ctrl = &vctrl->vrange.ctrl;
+ struct vctrl_voltage_range *out = &vctrl->vrange.out;
+
+ return ctrl->min_uV +
+ DIV_ROUND_CLOSEST_ULL((s64)(out_uV - out->min_uV) *
+ (ctrl->max_uV - ctrl->min_uV),
+ out->max_uV - out->min_uV);
+}
+
+static int vctrl_calc_output_voltage(struct vctrl_data *vctrl, int ctrl_uV)
+{
+ struct vctrl_voltage_range *ctrl = &vctrl->vrange.ctrl;
+ struct vctrl_voltage_range *out = &vctrl->vrange.out;
+
+ if (ctrl_uV < 0) {
+ pr_err("vctrl: failed to get control voltage\n");
+ return ctrl_uV;
+ }
+
+ if (ctrl_uV < ctrl->min_uV)
+ return out->min_uV;
+
+ if (ctrl_uV > ctrl->max_uV)
+ return out->max_uV;
+
+ return out->min_uV +
+ DIV_ROUND_CLOSEST_ULL((s64)(ctrl_uV - ctrl->min_uV) *
+ (out->max_uV - out->min_uV),
+ ctrl->max_uV - ctrl->min_uV);
+}
+
+static int vctrl_get_voltage(struct regulator_dev *rdev)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+ int ctrl_uV = regulator_get_voltage(vctrl->ctrl_reg);
+
+ return vctrl_calc_output_voltage(vctrl, ctrl_uV);
+}
+
+static int vctrl_set_voltage(struct regulator_dev *rdev,
+ int req_min_uV, int req_max_uV,
+ unsigned int *selector)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+ struct regulator *ctrl_reg = vctrl->ctrl_reg;
+ int orig_ctrl_uV = regulator_get_voltage(ctrl_reg);
+ int uV = vctrl_calc_output_voltage(vctrl, orig_ctrl_uV);
+ int ret;
+
+ if (req_min_uV >= uV || !vctrl->ovp_threshold)
+ /* voltage rising or no OVP */
+ return regulator_set_voltage(
+ ctrl_reg,
+ vctrl_calc_ctrl_voltage(vctrl, req_min_uV),
+ vctrl_calc_ctrl_voltage(vctrl, req_max_uV));
+
+ while (uV > req_min_uV) {
+ int max_drop_uV = (uV * vctrl->ovp_threshold) / 100;
+ int next_uV;
+ int next_ctrl_uV;
+ int delay;
+
+ /* Make sure no infinite loop even in crazy cases */
+ if (max_drop_uV == 0)
+ max_drop_uV = 1;
+
+ next_uV = max_t(int, req_min_uV, uV - max_drop_uV);
+ next_ctrl_uV = vctrl_calc_ctrl_voltage(vctrl, next_uV);
+
+ ret = regulator_set_voltage(ctrl_reg,
+ next_ctrl_uV,
+ next_ctrl_uV);
+ if (ret)
+ goto err;
+
+ delay = DIV_ROUND_UP(uV - next_uV, vctrl->min_slew_down_rate);
+ usleep_range(delay, delay + DIV_ROUND_UP(delay, 10));
+
+ uV = next_uV;
+ }
+
+ return 0;
+
+err:
+ /* Try to go back to original voltage */
+ regulator_set_voltage(ctrl_reg, orig_ctrl_uV, orig_ctrl_uV);
+
+ return ret;
+}
+
+static int vctrl_get_voltage_sel(struct regulator_dev *rdev)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+
+ return vctrl->sel;
+}
+
+static int vctrl_set_voltage_sel(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+ struct regulator *ctrl_reg = vctrl->ctrl_reg;
+ unsigned int orig_sel = vctrl->sel;
+ int ret;
+
+ if (selector >= rdev->desc->n_voltages)
+ return -EINVAL;
+
+ if (selector >= vctrl->sel || !vctrl->ovp_threshold) {
+ /* voltage rising or no OVP */
+ ret = regulator_set_voltage(ctrl_reg,
+ vctrl->vtable[selector].ctrl,
+ vctrl->vtable[selector].ctrl);
+ if (!ret)
+ vctrl->sel = selector;
+
+ return ret;
+ }
+
+ while (vctrl->sel != selector) {
+ unsigned int next_sel;
+ int delay;
+
+ if (selector >= vctrl->vtable[vctrl->sel].ovp_min_sel)
+ next_sel = selector;
+ else
+ next_sel = vctrl->vtable[vctrl->sel].ovp_min_sel;
+
+ ret = regulator_set_voltage(ctrl_reg,
+ vctrl->vtable[next_sel].ctrl,
+ vctrl->vtable[next_sel].ctrl);
+ if (ret) {
+ dev_err(&rdev->dev,
+ "failed to set control voltage to %duV\n",
+ vctrl->vtable[next_sel].ctrl);
+ goto err;
+ }
+ vctrl->sel = next_sel;
+
+ delay = DIV_ROUND_UP(vctrl->vtable[vctrl->sel].out -
+ vctrl->vtable[next_sel].out,
+ vctrl->min_slew_down_rate);
+ usleep_range(delay, delay + DIV_ROUND_UP(delay, 10));
+ }
+
+ return 0;
+
+err:
+ if (vctrl->sel != orig_sel) {
+ /* Try to go back to original voltage */
+ if (!regulator_set_voltage(ctrl_reg,
+ vctrl->vtable[orig_sel].ctrl,
+ vctrl->vtable[orig_sel].ctrl))
+ vctrl->sel = orig_sel;
+ else
+ dev_warn(&rdev->dev,
+ "failed to restore original voltage\n");
+ }
+
+ return ret;
+}
+
+static int vctrl_list_voltage(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+
+ if (selector >= rdev->desc->n_voltages)
+ return -EINVAL;
+
+ return vctrl->vtable[selector].out;
+}
+
+static int vctrl_parse_dt(struct platform_device *pdev,
+ struct vctrl_data *vctrl)
+{
+ int ret;
+ struct device_node *np = pdev->dev.of_node;
+ u32 pval;
+ u32 vrange_ctrl[2];
+
+ vctrl->ctrl_reg = devm_regulator_get(&pdev->dev, "ctrl");
+ if (IS_ERR(vctrl->ctrl_reg))
+ return PTR_ERR(vctrl->ctrl_reg);
+
+ ret = of_property_read_u32(np, "ovp-threshold-percent", &pval);
+ if (!ret) {
+ vctrl->ovp_threshold = pval;
+ if (vctrl->ovp_threshold > 100) {
+ dev_err(&pdev->dev,
+ "ovp-threshold-percent (%u) > 100\n",
+ vctrl->ovp_threshold);
+ return -EINVAL;
+ }
+ }
+
+ ret = of_property_read_u32(np, "min-slew-down-rate", &pval);
+ if (!ret) {
+ vctrl->min_slew_down_rate = pval;
+
+ /* We use the value as int and as divider; sanity check */
+ if (vctrl->min_slew_down_rate == 0) {
+ dev_err(&pdev->dev,
+ "min-slew-down-rate must not be 0\n");
+ return -EINVAL;
+ } else if (vctrl->min_slew_down_rate > INT_MAX) {
+ dev_err(&pdev->dev, "min-slew-down-rate (%u) too big\n",
+ vctrl->min_slew_down_rate);
+ return -EINVAL;
+ }
+ }
+
+ if (vctrl->ovp_threshold && !vctrl->min_slew_down_rate) {
+ dev_err(&pdev->dev,
+ "ovp-threshold-percent requires min-slew-down-rate\n");
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(np, "regulator-min-microvolt", &pval);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to read regulator-min-microvolt: %d\n", ret);
+ return ret;
+ }
+ vctrl->vrange.out.min_uV = pval;
+
+ ret = of_property_read_u32(np, "regulator-max-microvolt", &pval);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to read regulator-max-microvolt: %d\n", ret);
+ return ret;
+ }
+ vctrl->vrange.out.max_uV = pval;
+
+ ret = of_property_read_u32_array(np, "ctrl-voltage-range", vrange_ctrl,
+ 2);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to read ctrl-voltage-range: %d\n",
+ ret);
+ return ret;
+ }
+
+ if (vrange_ctrl[0] >= vrange_ctrl[1]) {
+ dev_err(&pdev->dev, "ctrl-voltage-range is invalid: %d-%d\n",
+ vrange_ctrl[0], vrange_ctrl[1]);
+ return -EINVAL;
+ }
+
+ vctrl->vrange.ctrl.min_uV = vrange_ctrl[0];
+ vctrl->vrange.ctrl.max_uV = vrange_ctrl[1];
+
+ return 0;
+}
+
+static int vctrl_cmp_ctrl_uV(const void *a, const void *b)
+{
+ const struct vctrl_voltage_table *at = a;
+ const struct vctrl_voltage_table *bt = b;
+
+ return at->ctrl - bt->ctrl;
+}
+
+static int vctrl_init_vtable(struct platform_device *pdev)
+{
+ struct vctrl_data *vctrl = platform_get_drvdata(pdev);
+ struct regulator_desc *rdesc = &vctrl->desc;
+ struct regulator *ctrl_reg = vctrl->ctrl_reg;
+ struct vctrl_voltage_range *vrange_ctrl = &vctrl->vrange.ctrl;
+ int n_voltages;
+ int ctrl_uV;
+ int i, idx_vt;
+
+ n_voltages = regulator_count_voltages(ctrl_reg);
+
+ rdesc->n_voltages = n_voltages;
+
+ /* determine number of steps within the range of the vctrl regulator */
+ for (i = 0; i < n_voltages; i++) {
+ ctrl_uV = regulator_list_voltage(ctrl_reg, i);
+
+ if (ctrl_uV < vrange_ctrl->min_uV ||
+ ctrl_uV > vrange_ctrl->max_uV) {
+ rdesc->n_voltages--;
+ continue;
+ }
+ }
+
+ if (rdesc->n_voltages == 0) {
+ dev_err(&pdev->dev, "invalid configuration\n");
+ return -EINVAL;
+ }
+
+ vctrl->vtable = devm_kmalloc_array(
+ &pdev->dev, sizeof(struct vctrl_voltage_table),
+ rdesc->n_voltages, GFP_KERNEL | __GFP_ZERO);
+ if (!vctrl->vtable)
+ return -ENOMEM;
+
+ /* create mapping control <=> output voltage */
+ for (i = 0, idx_vt = 0; i < n_voltages; i++) {
+ ctrl_uV = regulator_list_voltage(ctrl_reg, i);
+
+ if (ctrl_uV < vrange_ctrl->min_uV ||
+ ctrl_uV > vrange_ctrl->max_uV)
+ continue;
+
+ vctrl->vtable[idx_vt].ctrl = ctrl_uV;
+ vctrl->vtable[idx_vt].out =
+ vctrl_calc_output_voltage(vctrl, ctrl_uV);
+ idx_vt++;
+ }
+
+ /* we rely on the table to be ordered by ascending voltage */
+ sort(vctrl->vtable, rdesc->n_voltages,
+ sizeof(struct vctrl_voltage_table), vctrl_cmp_ctrl_uV,
+ NULL);
+
+ /* pre-calculate OVP-safe downward transitions */
+ for (i = n_voltages - 1; i > 0; i--) {
+ int j;
+ int ovp_min_uV = (vctrl->vtable[i].out *
+ (100 - vctrl->ovp_threshold)) / 100;
+
+ for (j = 0; j < i; j++) {
+ if (vctrl->vtable[j].out >= ovp_min_uV) {
+ vctrl->vtable[i].ovp_min_sel = j;
+ break;
+ }
+ }
+
+ if (j == i) {
+ dev_warn(&pdev->dev, "switching down from %duV may cause OVP shutdown\n",
+ vctrl->vtable[i].out);
+ /* use next lowest voltage */
+ vctrl->vtable[i].ovp_min_sel = i - 1;
+ }
+ }
+
+ return 0;
+}
+
+static int vctrl_enable(struct regulator_dev *rdev)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+ int ret = regulator_enable(vctrl->ctrl_reg);
+
+ if (!ret)
+ vctrl->enabled = true;
+
+ return ret;
+}
+
+static int vctrl_disable(struct regulator_dev *rdev)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+ int ret = regulator_disable(vctrl->ctrl_reg);
+
+ if (!ret)
+ vctrl->enabled = false;
+
+ return ret;
+}
+
+static int vctrl_is_enabled(struct regulator_dev *rdev)
+{
+ struct vctrl_data *vctrl = rdev_get_drvdata(rdev);
+
+ return vctrl->enabled;
+}
+
+static const struct regulator_ops vctrl_ops_cont = {
+ .enable = vctrl_enable,
+ .disable = vctrl_disable,
+ .is_enabled = vctrl_is_enabled,
+ .get_voltage = vctrl_get_voltage,
+ .set_voltage = vctrl_set_voltage,
+};
+
+static const struct regulator_ops vctrl_ops_non_cont = {
+ .enable = vctrl_enable,
+ .disable = vctrl_disable,
+ .is_enabled = vctrl_is_enabled,
+ .set_voltage_sel = vctrl_set_voltage_sel,
+ .get_voltage_sel = vctrl_get_voltage_sel,
+ .list_voltage = vctrl_list_voltage,
+ .map_voltage = regulator_map_voltage_iterate,
+};
+
+static int vctrl_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct vctrl_data *vctrl;
+ const struct regulator_init_data *init_data;
+ struct regulator_desc *rdesc;
+ struct regulator_config cfg = { };
+ struct vctrl_voltage_range *vrange_ctrl;
+ int ctrl_uV;
+ int ret;
+
+ vctrl = devm_kzalloc(&pdev->dev, sizeof(struct vctrl_data),
+ GFP_KERNEL);
+ if (!vctrl)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, vctrl);
+
+ ret = vctrl_parse_dt(pdev, vctrl);
+ if (ret)
+ return ret;
+
+ vrange_ctrl = &vctrl->vrange.ctrl;
+
+ rdesc = &vctrl->desc;
+ rdesc->name = "vctrl";
+ rdesc->type = REGULATOR_VOLTAGE;
+ rdesc->owner = THIS_MODULE;
+
+ if ((regulator_get_linear_step(vctrl->ctrl_reg) == 1) ||
+ (regulator_count_voltages(vctrl->ctrl_reg) == -EINVAL)) {
+ rdesc->continuous_voltage_range = true;
+ rdesc->ops = &vctrl_ops_cont;
+ } else {
+ rdesc->ops = &vctrl_ops_non_cont;
+ }
+
+ init_data = of_get_regulator_init_data(&pdev->dev, np, rdesc);
+ if (!init_data)
+ return -ENOMEM;
+
+ cfg.of_node = np;
+ cfg.dev = &pdev->dev;
+ cfg.driver_data = vctrl;
+ cfg.init_data = init_data;
+
+ if (!rdesc->continuous_voltage_range) {
+ ret = vctrl_init_vtable(pdev);
+ if (ret)
+ return ret;
+
+ ctrl_uV = regulator_get_voltage(vctrl->ctrl_reg);
+ if (ctrl_uV < 0) {
+ dev_err(&pdev->dev, "failed to get control voltage\n");
+ return ctrl_uV;
+ }
+
+ /* determine current voltage selector from control voltage */
+ if (ctrl_uV < vrange_ctrl->min_uV) {
+ vctrl->sel = 0;
+ } else if (ctrl_uV > vrange_ctrl->max_uV) {
+ vctrl->sel = rdesc->n_voltages - 1;
+ } else {
+ int i;
+
+ for (i = 0; i < rdesc->n_voltages; i++) {
+ if (ctrl_uV == vctrl->vtable[i].ctrl) {
+ vctrl->sel = i;
+ break;
+ }
+ }
+ }
+ }
+
+ vctrl->rdev = devm_regulator_register(&pdev->dev, rdesc, &cfg);
+ if (IS_ERR(vctrl->rdev)) {
+ ret = PTR_ERR(vctrl->rdev);
+ dev_err(&pdev->dev, "failed to register regulator: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id vctrl_of_match[] = {
+ { .compatible = "vctrl-regulator", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, vctrl_of_match);
+
+static struct platform_driver vctrl_driver = {
+ .probe = vctrl_probe,
+ .driver = {
+ .name = "vctrl-regulator",
+ .of_match_table = of_match_ptr(vctrl_of_match),
+ },
+};
+
+module_platform_driver(vctrl_driver);
+
+MODULE_DESCRIPTION("Voltage Controlled Regulator Driver");
+MODULE_AUTHOR("Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
--
2.12.2.715.g7642488e1d-goog
--
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 related
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Stephen Boyd @ 2017-04-07 19:51 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
andrea.merello-Re5JQEeQqe8AvxtiuMwx3w,
radoslaw.pietrzyk-Re5JQEeQqe8AvxtiuMwx3w, Lee Jones,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, ludovic.barre-qxv4g6HH51o,
olivier.bideau-qxv4g6HH51o, amelie.delaunay-qxv4g6HH51o
In-Reply-To: <bd680d0a-0b2f-91fc-a940-b2fef4300ca3-qxv4g6HH51o@public.gmane.org>
On 04/06, Gabriel Fernandez wrote:
> On 04/06/2017 12:32 AM, Stephen Boyd wrote:
> >On 03/15, gabriel.fernandez-qxv4g6HH51o@public.gmane.org wrote:
> >>diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> >>new file mode 100644
> >>index 0000000..9d4b587
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
> >>@@ -0,0 +1,152 @@
> >>+
> >>+ rcc: rcc@58024400 {
> >>+ #reset-cells = <1>;
> >>+ #clock-cells = <2>
> >>+ compatible = "st,stm32h743-rcc", "st,stm32-rcc";
> >>+ reg = <0x58024400 0x400>;
> >>+ clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
> >>+
> >>+ st,syscfg = <&pwrcfg>;
> >>+
> >>+ #address-cells = <1>;
> >>+ #size-cells = <0>;
> >>+
> >>+ vco1@58024430 {
> >>+ #clock-cells = <0>;
> >>+ compatible = "stm32,pll";
> >>+ reg = <0>;
> >reg is super confusing and doesn't match unit address.
> ok i fixed it in the v2
>
> >
> >>+ };
> >Why? Shouldn't we know this from the compatible string how many
> >PLLs there are and where they're located? Export the PLLs through
> >rcc node's clock-cells?
> >
> Because i need to offer the possibility to change the PLL VCO
> frequencies at the start-up of this driver clock.
> The VCO algorithm needs a division factor, a multiplication factor
> and a fractional factor.
> Lot's of solution are possible for one frequency and it's nightmare
> to satisfy the 3 output dividers of the PLL.
Sure, but do we need to configure that on a per-board basis or a
per-SoC basis? If it's just some configuration, I wonder why we
don't put that into the driver and base it off some compatible
string that includes the SoC the device is for.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe 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 net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding
From: Florian Fainelli @ 2017-04-07 19:45 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w, andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Landen.Chao-NuS5LvNUpcJWk0Htik3J/w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, objelf-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1491554709-9723-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 04/07/2017 01:45 AM, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Add device-tree binding for Mediatek MT7530 switch.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Florian
--
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 net-next v4 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: Florian Fainelli @ 2017-04-07 19:45 UTC (permalink / raw)
To: sean.wang, andrew, vivien.didelot, matthias.bgg, robh+dt,
mark.rutland
Cc: devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-6-git-send-email-sean.wang@mediatek.com>
On 04/07/2017 01:45 AM, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
> Mediatek router platforms such as MT7623A or MT7623N platform which
> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
> Among these ports, The port from 0 to 4 are the user ports connecting
> with the remote devices while the port 5 and 6 are the CPU ports
> connecting into Mediatek Ethernet GMAC.
>
> For port 6, it can communicate with the CPU via Mediatek Ethernet GMAC
> through either the TRGMII or RGMII which could be controlled by phy-mode
> in the dt-bindings to specify which mode is preferred to use. And for
> port 5, only RGMII can be specified. However, currently, only port 6 is
> being supported in this DSA driver.
>
> The driver is made with the reference to qca8k and other existing DSA
> driver. The most of the essential callbacks of the DSA are already
> support in the driver, including tag insert for user port distinguishing,
> port control, bridge offloading, STP setup and ethtool operation to allow
> DSA to model each user port into a standalone netdevice as the other DSA
> driver had done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Landen Chao <Landen.Chao@mediatek.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797
From: Stephen Boyd @ 2017-04-07 19:41 UTC (permalink / raw)
To: Mars Cheng
Cc: Matthias Brugger, Rob Herring, Marc Zyngier, Michael Turquette,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel, linux-mediatek, devicetree, wsd_upstream,
linux-clk, Kevin-CW Chen
In-Reply-To: <1491521747.17643.6.camel@mtkswgap22>
On 04/07, Mars Cheng wrote:
> Hi Stephen
>
> On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote:
> > On 03/19, Mars Cheng wrote:
> > > From: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > >
> > > Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> > > and subsystem clocks
> > >
> > > Signed-off-by: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > > Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> > > Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
> >
> > Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > Looks fine to me except for the one comment below. Did you want
> > me to merge it into clk tree?
>
> To prevent another run, I really like you to merge it.
> However, I also want to make the patch set more cleaner.
> So I will send v4 later. :-)
Ok I'll merge v4 patch then.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 0/3] clk: Add support for IDT 5P49V5935
From: Stephen Boyd @ 2017-04-07 19:40 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-1-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07, Alexey Firago wrote:
> This series adds support for IDT VersaClock 5P49V5935 programmable clock
> generator to the existing clk-versaclock5 driver. Driver is also updated to
> simplify addition of support for more VersaClock 5 models.
>
> Patches were verified on Avnet UltraZed-EG board with IO Carrier Card.
>
> Changes in V2:
> - Introduce vc5_chip_info structure describing chip features
> - Set vc5_chip_info for the supported chips using clk_vc5_of_match[].data
> - Add 5P49V5935 support using vc5_chip_info approach
> - Fix idx comparison in vc5_of_clk_get ('>' to '>=')
>
> Changes in V3:
> - Change type of clk_fod_cnt and clk_out_cnt to unsigned int
> - Add missed 'const' to vc5_chip_info instance declaration
> - Use of_device_get_match_data() to initialize vc5_chip_info on probe
>
> Changes in V4:
> - Add 'const' to vc5_chip_info.flags
Could any Reviewed-by tags get carried over? I'll wait for Marek
to resend them I guess.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe 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 net-next v4 1/5] dt-bindings: net: dsa: add Mediatek MT7530 binding
From: Andrew Lunn @ 2017-04-07 19:38 UTC (permalink / raw)
To: sean.wang
Cc: f.fainelli, vivien.didelot, matthias.bgg, robh+dt, mark.rutland,
devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-2-git-send-email-sean.wang@mediatek.com>
On Fri, Apr 07, 2017 at 04:45:05PM +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add device-tree binding for Mediatek MT7530 switch.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: Andrew Lunn @ 2017-04-07 19:37 UTC (permalink / raw)
To: sean.wang
Cc: f.fainelli, vivien.didelot, matthias.bgg, robh+dt, mark.rutland,
devicetree, netdev, linux-kernel, linux-mediatek, davem,
Landen.Chao, keyhaede, objelf
In-Reply-To: <1491554709-9723-6-git-send-email-sean.wang@mediatek.com>
On Fri, Apr 07, 2017 at 04:45:09PM +0800, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
> Mediatek router platforms such as MT7623A or MT7623N platform which
> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
> Among these ports, The port from 0 to 4 are the user ports connecting
> with the remote devices while the port 5 and 6 are the CPU ports
> connecting into Mediatek Ethernet GMAC.
>
> For port 6, it can communicate with the CPU via Mediatek Ethernet GMAC
> through either the TRGMII or RGMII which could be controlled by phy-mode
> in the dt-bindings to specify which mode is preferred to use. And for
> port 5, only RGMII can be specified. However, currently, only port 6 is
> being supported in this DSA driver.
>
> The driver is made with the reference to qca8k and other existing DSA
> driver. The most of the essential callbacks of the DSA are already
> support in the driver, including tag insert for user port distinguishing,
> port control, bridge offloading, STP setup and ethtool operation to allow
> DSA to model each user port into a standalone netdevice as the other DSA
> driver had done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Landen Chao <Landen.Chao@mediatek.com>
Hi Sean
This is looking good now. Thanks
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v11 01/10] devicetree: power: Add battery.txt
From: Liam Breck @ 2017-04-07 19:23 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring
Cc: Andrew F. Davis, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren
In-Reply-To: <20170320094335.19224-2-liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
[+CC Tony Lindgren]
Rob & Sebastian & Tony & Andrew,
With this binding we allow a DT to hard-code battery characteristics.
But mainline dts files for boards & boxes really should NOT include
immutable battery properties unless the battery is inseparable from
the electronics. We want to prevent unpredictable behavior due to
incorrect DT properties after a user changes a battery to a different
type.
It's OK for device vendors to hard-code battery characteristics in DT,
but mainline dts is another matter.
If this is agreed, how should we document it?
On Mon, Mar 20, 2017 at 2:43 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
> From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>
> Documentation of static battery characteristics that can be defined
> for batteries which cannot self-identify. This information is required
> by fuel-gauge and charger chips for proper handling of the battery.
>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
> ---
> .../devicetree/bindings/power/supply/battery.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> new file mode 100644
> index 0000000..53a68c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -0,0 +1,43 @@
> +Battery Characteristics
> +
> +The devicetree battery node provides static battery characteristics.
> +In smart batteries, these are typically stored in non-volatile memory
> +on a fuel gauge chip. The battery node should be used where there is
> +no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> +
> +Required Properties:
> + - compatible: Must be "simple-battery"
> +
> +Optional Properties:
> + - voltage-min-design-microvolt: drained battery voltage
> + - energy-full-design-microwatt-hours: battery design energy
> + - charge-full-design-microamp-hours: battery design capacity
> +
> +Battery properties are named, where possible, for the corresponding
> +elements in enum power_supply_property, defined in
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h#n86
> +
> +Batteries must be referenced by chargers and/or fuel-gauges
> +using a phandle. The phandle's property should be named
> +"monitored-battery".
> +
> +Example:
> +
> + bat: battery {
> + compatible = "simple-battery";
> + voltage-min-design-microvolt = <3200000>;
> + energy-full-design-microwatt-hours = <5290000>;
> + charge-full-design-microamp-hours = <1430000>;
> + };
> +
> + charger: charger@11 {
> + ....
> + monitored-battery = <&bat>;
> + ...
> + };
> +
> + fuel_gauge: fuel-gauge@22 {
> + ....
> + monitored-battery = <&bat>;
> + ...
> + };
> --
> 2.9.3
>
--
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/9] ASoC: add snd_soc_get_dai_id()
From: Rob Herring @ 2017-04-07 19:16 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87h92nbdgy.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Mar 20, 2017 at 8:59 PM, Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi Rob
>
> Thank you for your review
>
>> > +{
>> > + struct device_node *node;
>> > + struct device_node *endpoint;
>> > + int i, id;
>> > +
>> > + node = of_graph_get_port_parent(ep);
>> > +
>> > + i = 0;
>> > + id = -1;
>> > + for_each_endpoint_of_node(node, endpoint) {
>> > + if (endpoint == ep)
>> > + id = i;
>>
>> I don't see how this works when you have 1 DAI controller with
>> multiple endpoints versus multiple DAI controllers with a single
>> endpoint each. All the IDs will be 0 in the latter case.
>
> It support 1:1 endpoint pattern only.
Then the endpoint id is always 0 and this function is pointless.
Rob
--
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 v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-07 18:48 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS,
linux-arm-kernel@lists.infradead.org, Gustavo Padovan,
Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer, Satish Patel,
netdev, devicetree@vger.kernel.org
In-Reply-To: <1491584978.2136.21.camel@redhat.com>
On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing
>> AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed
>> for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> Is there no way to put the TI-specific stuff into a TI UART module
> rather than building it into the generic one?
In case it's not clear, all of HCI_LL is the TI specific part, not
just what I'm adding. So you are talking about putting each UART BT
protocol into a separate module. I'd assume that is doable, but seems
orthogonal to this patch set. I'd also assume there was some reason
that was not done already.
Rob
^ permalink raw reply
* Re: [PATCH v3] regulator: Add driver for voltage controlled regulators
From: Matthias Kaehlcke @ 2017-04-07 18:44 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson, Brian Norris
In-Reply-To: <20170406182136.yrwdoyqeuz4qxc6d-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark,
Thanks for the review!
El Thu, Apr 06, 2017 at 07:21:36PM +0100 Mark Brown ha dit:
> On Fri, Mar 31, 2017 at 01:50:35PM -0700, Matthias Kaehlcke wrote:
>
> > +- compatible : must be "vctrl-regulator".
> > +- regulator-min-microvolt : smallest voltage consumers may set
> > +- regulator-max-microvolt : largest voltage consumers may set
> > +- ctrl-regulator: : the name of the regulator supplying the control
> > + voltage.
>
> This looks good except for this bit where we read the regulator name out
> of the DT, that's generally a sign of bad practice for things that are
> less simple passives than things like this or fixed voltage regulators.
> As with the supplies for fixed voltage regulators just pick a name for
> the supply (ctrl seems fine to me) and use that, neither option is
> perfect but at elast this less typing for everyone and it's consistent
> with what other similar things are already doing.
Sounds good, I will send out an updated version shortly.
Matthias
--
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
* [PATCH v2 11/11] arm64: allwinner: a64: enable Wi-Fi for Pine64
From: Icenowy Zheng @ 2017-04-07 18:34 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: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
The Wi-Fi modules of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).
Add device node for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 7da074f95065..9d90bb32aa87 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -64,6 +64,11 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+ };
};
&ehci1 {
@@ -91,6 +96,17 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dldo4>;
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.12.2
^ permalink raw reply related
* [PATCH v2 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-07 18:34 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: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 2132d8e6cb3d..7da074f95065 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -106,6 +106,115 @@
};
};
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vcc-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-name = "vcc-phy";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-mipi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vdd-1v8-csi";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v2 09/11] arm64: allwinner: a64: add DTSI file for AXP803 PMIC
From: Icenowy Zheng @ 2017-04-07 18:34 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: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++++++++++++
1 file changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index 000000000000..f0e53a7fffbd
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <3000>;
+
+ reg_dcdc1: dcdc1 {
+ regulator-name = "dcdc1";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "dcdc2";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "dcdc3";
+ };
+
+ reg_dcdc4: dcdc4 {
+ regulator-name = "dcdc4";
+ };
+
+ reg_dcdc5: dcdc5 {
+ regulator-name = "dcdc5";
+ };
+
+ reg_dcdc6: dcdc6 {
+ regulator-name = "dcdc6";
+ };
+
+ reg_dc1sw: dc1sw {
+ regulator-name = "dc1sw";
+ };
+
+ reg_aldo1: aldo1 {
+ regulator-name = "aldo1";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-name = "aldo2";
+ };
+
+ reg_aldo3: aldo3 {
+ regulator-name = "aldo3";
+ };
+
+ reg_dldo1: dldo1 {
+ regulator-name = "dldo1";
+ };
+
+ reg_dldo2: dldo2 {
+ regulator-name = "dldo2";
+ };
+
+ reg_dldo3: dldo3 {
+ regulator-name = "dldo3";
+ };
+
+ reg_dldo4: dldo4 {
+ regulator-name = "dldo4";
+ };
+
+ reg_eldo1: eldo1 {
+ regulator-name = "eldo1";
+ };
+
+ reg_eldo2: eldo2 {
+ regulator-name = "eldo2";
+ };
+
+ reg_eldo3: eldo3 {
+ regulator-name = "eldo3";
+ };
+
+ reg_fldo1: fldo1 {
+ regulator-name = "fldo1";
+ };
+
+ reg_fldo2: fldo2 {
+ regulator-name = "fldo2";
+ };
+
+ reg_ldo_io0: ldo_io0 {
+ regulator-name = "ldo_io0";
+ status = "disabled";
+ };
+
+ reg_ldo_io1: ldo_io1 {
+ regulator-name = "ldo_io1";
+ status = "disabled";
+ };
+
+ reg_rtc_ldo: rtc_ldo {
+ /* RTC_LDO is a fixed, always-on regulator */
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "rtc_ldo";
+ };
+ };
+};
--
2.12.2
^ permalink raw reply related
* [PATCH v2 08/11] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Icenowy Zheng @ 2017-04-07 18:34 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: <20170407183441.58750-1-icenowy-h8G6r0blFSE@public.gmane.org>
As axp20x-regulator now supports AXP803, add a cell for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
drivers/mfd/axp20x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 2268a6a9aa2c..08b9bbd5bd71 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -839,6 +839,8 @@ static struct mfd_cell axp803_cells[] = {
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp803_pek_resources),
.resources = axp803_pek_resources,
+ }, {
+ .name = "axp20x-regulator",
}
};
--
2.12.2
^ 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