* Re: [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Alexander Kochetkov @ 2016-11-25 9:23 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Caesar Wang, daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480025455-6797-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello,
Here the thread where the patch was discussed:
http://lists.infradead.org/pipermail/linux-rockchip/2016-November/013174.html
Regards,
Alexander.
--
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 01/10] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-11-25 9:23 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161125090921.23138-2-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/power/supply/axp20x_usb_power.c | 39 ++++++++++++++++++++-------------
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
> index 6af6feb..b19754e 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -17,6 +17,7 @@
> #include <linux/mfd/axp20x.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/power_supply.h>
> #include <linux/regmap.h>
> @@ -45,6 +46,7 @@ struct axp20x_usb_power {
> struct device_node *np;
> struct regmap *regmap;
> struct power_supply *supply;
> + int axp20x_id;
> };
>
> static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
> @@ -86,8 +88,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
>
> switch (v & AXP20X_VBUS_CLIMIT_MASK) {
> case AXP20X_VBUC_CLIMIT_100mA:
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> val->intval = 100000;
> } else {
> val->intval = -1; /* No 100mA limit */
> @@ -130,8 +131,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
>
> val->intval = POWER_SUPPLY_HEALTH_GOOD;
>
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> ret = regmap_read(power->regmap,
> AXP20X_USB_OTG_STATUS, &v);
> if (ret)
> @@ -189,6 +189,17 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
> .get_property = axp20x_usb_power_get_property,
> };
>
> +static const struct of_device_id axp20x_usb_power_match[] = {
> + {
> + .compatible = "x-powers,axp202-usb-power-supply",
> + .data = (void *)AXP202_ID,
> + }, {
> + .compatible = "x-powers,axp221-usb-power-supply",
> + .data = (void *)AXP221_ID,
> + }, { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
> +
There's no need to move this. See why below.
> static int axp20x_usb_power_probe(struct platform_device *pdev)
> {
> struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> @@ -200,11 +211,16 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> "VBUS_PLUGIN", "VBUS_REMOVAL", NULL };
> static const char * const *irq_names;
> const struct power_supply_desc *usb_power_desc;
> + const struct of_device_id *of_id;
> int i, irq, ret;
>
> if (!of_device_is_available(pdev->dev.of_node))
> return -ENODEV;
>
> + of_id = of_match_device(axp20x_usb_power_match, &pdev->dev);
> + if (!of_id)
> + return -ENODEV;
> +
You can use of_device_get_match_data() instead.
ChenYu
> if (!axp20x) {
> dev_err(&pdev->dev, "Parent drvdata not set\n");
> return -EINVAL;
> @@ -214,11 +230,12 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> if (!power)
> return -ENOMEM;
>
> + power->axp20x_id = (int)of_id->data;
> +
> power->np = pdev->dev.of_node;
> power->regmap = axp20x->regmap;
>
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> /* Enable vbus valid checking */
> ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
> AXP20X_VBUS_MON_VBUS_VALID,
> @@ -235,8 +252,7 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
>
> usb_power_desc = &axp20x_usb_power_desc;
> irq_names = axp20x_irq_names;
> - } else if (of_device_is_compatible(power->np,
> - "x-powers,axp221-usb-power-supply")) {
> + } else if (power->axp20x_id == AXP221_ID) {
> usb_power_desc = &axp22x_usb_power_desc;
> irq_names = axp22x_irq_names;
> } else {
> @@ -272,13 +288,6 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id axp20x_usb_power_match[] = {
> - { .compatible = "x-powers,axp202-usb-power-supply" },
> - { .compatible = "x-powers,axp221-usb-power-supply" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
> -
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> .driver = {
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH V4 1/2] pinctrl: tegra: Add DT binding for io pads control
From: Thierry Reding @ 2016-11-25 9:13 UTC (permalink / raw)
To: Laxman Dewangan
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, joe-6d6DIl74uiNBDgjK7y7TUQ,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479976734-30498-2-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8349 bytes --]
On Thu, Nov 24, 2016 at 02:08:53PM +0530, Laxman Dewangan wrote:
> NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> low power state of some of its IO pads. The IO pads can work in
> the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
> sources. When IO interfaces are not used then IO pads can be
> configure in low power state to reduce the power consumption from
> that IO pads.
>
> On Tegra124, the voltage level of IO power rail source is auto
> detected by hardware(SoC) and hence it is only require to configure
> in low power mode if IO pads are not used.
>
> On T210 onwards, the auto-detection of voltage level from IO power
You say Tegra124 above but T210 here. Please use consistent spelling to
make it more obvious that we're talking about chip generations here.
Tegra<gen> is preferred over T<gen>.
> rail is removed from SoC and hence SW need to configure the PMC
> register explicitly to set proper voltage in IO pads based on
> IO rail power source voltage.
>
> Add DT binding document for detailing the DT properties for
> configuring IO pads voltage levels and its power state.
>
> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> ---
> Changes from V1:
> New in series based on pinctrl driver requirement.
>
> Changes from V2:
> Updated the statement to say 1.8V and 3.3V as nominal voltage.
> Corrected DT example by adding -supply and taken care of V1 review
> from Rob.
>
> .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> new file mode 100644
> index 0000000..a88c484
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> @@ -0,0 +1,126 @@
> +NVIDIA Tegra PMC IO pad controller
> +
> +NVIDIA Tegra124 and later SoCs support the multi-voltage level and low power
> +state of some of its IO pads. When IO interface are not used then IO pads can
> +be configure in low power state to reduce the power from that IO pads. The IO
> +pads can work in the nominal IO voltage of 1.8V and 3.3V from power rail
> +sources.
> +
> +On Tegra124, the voltage of IO power rail source is auto detected by SoC and
> +hence it is only require to configure in low power mode if IO pads are not
> +used.
> +
> +On T210 onwards, the HW based auto-detection for IO voltage is removed and
> +hence SW need to configure the PMC register explicitly, to set proper voltage
> +in IO pads, based on IO rail power source voltage.
> +
> +The voltage configurations and low power state of IO pads should be done in
> +boot if it is not going to change otherwise dynamically based on IO rail
> +voltage on that IO pads and usage of IO pads
Missing fullstop at the end.
> +
> +The DT property of the IO pads must be under the node of pmc i.e.
> +pmc@7000e400 for Tegra124 onwards.
The PMC is at a different address on Tegra186, so I think we should just
drop this to avoid having to update it whenever a new chip relocates it
to a different address.
Come to think of it, if these I/O pads are represented as subnodes in
the PMC device tree node, perhaps this should be merged into the PMC
documentation?
> +Please refer to <pinctrl-bindings.txt> in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +Tegra's pin configuration nodes act as a container for an arbitrary number of
> +subnodes. Each of these subnodes represents some desired configuration for an
> +IO pads, or a list of IO pads. This configuration can include the voltage and
> +power enable/disable control
Missing fullstop.
> +
> +The name of each subnode is not important; all subnodes should be enumerated
> +and processed purely based on their content. Each subnode only affects those
> +parameters that are explicitly listed. Unspecified is represented as an absent
> +property,
Should be fullstop instead of comma at the end of the sentence. Also I'm
not sure the last sentence is even necessary. The previous one already
says that only explicitly listed parameters take effect.
> +
> +See the TRM to determine which properties and values apply to each IO pads.
Perhaps give a reference to where in the TRM this can be found?
> +
> +Required subnode-properties:
> +==========================
> +- pins : An array of strings. Each string contains the name of an IO pads. Valid
> + values for these names are listed below.
> +
> +Optional subnode-properties:
> +==========================
> +Following properties are supported from generic pin configuration explained
> +in <dt-bindings/pinctrl/pinctrl-binding.txt>.
I don't think such a directory exists. Maybe make these relative
references, though that might become slightly more difficult if this
whole document is merged with the PMC documentation.
> +low-power-enable: enable low power mode.
> +low-power-disable: disable low power mode.
Why the extra padding with tabs? I find that difficult to read. Also, no
need for a fullstop since it's not a proper sentence.
> +Valid values for pin for T124 are:
Tegra124
> + audio, bb, cam, comp, csia, csib, csie, dsi, dsib, dsic, dsid, hdmi,
> + hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, sdmmc4, sys-ddc, uart, usb0, usb1, usb2,
> + usb-bias
> +
> +Valid values for pin for T210 are:
Tegra210
> + audio, audio-hv, cam, csia, csib, csic, csid, csie, csif,
> + dbg, debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2,
> + gpio, hdmi, hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, spi, spi-hv, uart, usb-bias, usb0,
> + usb1, usb2, usb3.
> +
> +To find out the IO rail voltage for setting the voltage of IO pad by SW,
> +the regulator supply handle must provided from the DT and it is explained
> +in the regulator DT binding document
> + <devicetree/bindings/regulator/regulator.txt>.
Again, maybe make this relative because as it is it isn't obvious as to
what the base of the above path is.
> +For example, for GPIO rail the supply name is vddio-gpio and regulator
> +handle is supplied from DT as
> + vddio-gpio-supply = <®ulator_xyz>;
> +
> +For T210, following IO pads support the 1.8V/3.3V and the corresponding
Tegra210
> +IO voltage pin names are as follows:
> + audio -> vddio-audio
> + audio-hv -> vddio-audio-hv
> + cam ->vddio-cam
> + dbg -> vddio-dbg
> + dmic -> vddio-dmic
> + gpio -> vddio-gpio
> + pex-ctrl -> vddio-pex-ctrl
> + sdmmc1 -> vddio-sdmmc1
> + sdmmc3 -> vddio-sdmmc3
> + spi -> vddio-spi
> + spi-hv -> vddio-spi-hv
> + uart -> vddio-uart
It's slightly confusing to only have this list for Tegra210. I assume
that is because on Tegra124 there is no way to control the voltage of
the pins, but I think that could be made clearer. Also, it might be
worth explicitly mentioning that this is a subset of the list of pins
given above and that the other pins (those not in this list) don't
support 1.8/3.3 V control, but only the low power state.
> +
> +Example:
> + i2c@7000d000 {
> + pmic@3c {
> + regulators {
> + vddio_sdmmc1: ldo2 {
> + /* Regulator entries for LDO2 */
> + };
> +
> + vdd_cam: ldo3 {
> + /* Regulator entries for LDO3 */
These comments are somewhat stating the obvious. Perhaps simply use a
... as a placeholder?
> + };
> + };
> + };
> + };
> +
> + pmc@7000e400 {
> + vddio-cam-supply = <&vdd_cam>;
> + vddio-sdmmc1-supply = <&vddio_sdmmc1>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tegra_io_pad_volt_default>;
> + tegra_io_pad_volt_default: common {
> + audio-hv {
> + pins = "audio-hv";
> + low-power-disable;
> + };
I wonder if this is at all useful. Shouldn't we rather put all pads into
a low-power state by default and only take them out of the low-power
state when the driver decides to do so?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: enable dumb vga-dac drm bridge
From: Bartosz Golaszewski @ 2016-11-25 9:13 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
This enables the dumb-vga-dac driver by default for davinci boards.
The driver is needed for tilcdc support on da850-lcdk board.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..ab1bf18 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -127,6 +127,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_DRM=m
CONFIG_DRM_TILCDC=m
+CONFIG_DRM_BRIDGE=y
+CONFIG_DRM_DUMB_VGA_DAC=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH] ARM: da850-lcdk: add the dumb-vga-dac node
From: Bartosz Golaszewski @ 2016-11-25 9:11 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..c5d3a2b 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,53 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga_bridge {
+ compatible = "dumb-vga-dac";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&display_out_vga>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -219,3 +266,14 @@
};
};
};
+
+&display {
+ status = "okay";
+};
+
+&display_out {
+ display_out_vga: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 36066fa..6ab8df1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -442,6 +442,23 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ display_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
};
aemif: aemif@68000000 {
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 10/10] ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: Quentin Schulz, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20161125090921.23138-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Previously, the sun8i tablets used everything declared in AXP221 DTSI
while they have an AXP223 PMIC.
This corrects that so the sun8i tablets can get some features the AXP223
has (at the moment, ability to have 100mA as maximal current on VBUS
power supply).
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd001..ea79c33 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -136,7 +136,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
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 related
* [PATCH 09/10] ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
Previously, the Allwinner Parrot R16 used everything declared in AXP221
DTSI while it has an AXP223 PMIC.
This corrects that so the Allwinner Parrot R16 can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts b/arch/arm/boot/dts/sun8i-r16-parrot.dts
index 47553e5..6afdba3 100644
--- a/arch/arm/boot/dts/sun8i-r16-parrot.dts
+++ b/arch/arm/boot/dts/sun8i-r16-parrot.dts
@@ -209,7 +209,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH 08/10] ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
Previously, the Sinlinx SinA33 used everything declared in AXP221 DTSI
while it has an AXP223 PMIC.
This corrects that so the Sinlinx SinA33 can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 573aa2c..3373164 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -161,7 +161,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH 07/10] ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
Previously, the Olimex A33-OlinuXino used everything declared in AXP221
DTSI while it has an AXP223 PMIC.
This corrects that so the Olimex A33-OlinuXino can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
index 9ea637e..3e8f2ec 100644
--- a/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
+++ b/arch/arm/boot/dts/sun8i-a33-olinuxino.dts
@@ -126,7 +126,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH 06/10] ARM: dtsi: add DTSI for AXP223
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: Quentin Schulz, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20161125090921.23138-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The AXP223 shares most of its logic with the AXP221 but it has some
differences for the VBUS driver.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/axp223.dtsi | 55 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/axp223.dtsi
diff --git a/arch/arm/boot/dts/axp223.dtsi b/arch/arm/boot/dts/axp223.dtsi
new file mode 100644
index 0000000..f8ce55c
--- /dev/null
+++ b/arch/arm/boot/dts/axp223.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2016 Free Electrons
+ *
+ * Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@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.
+ */
+
+/*
+ * AXP223 Integrated Power Management Chip
+ * http://www.x-powers.com/product/AXP22X.php
+ * http://dl.linux-sunxi.org/AXP/AXP223-en.pdf
+ */
+
+#include "axp22x.dtsi"
+
+&usb_power_supply {
+ compatible = "x-powers,axp223-usb-power-supply";
+};
--
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 related
* [PATCH 05/10] mfd: axp20x: add separate MFD cell for AXP223
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
The AXP223 shares most of its logic with the AXP221 but has some
differences for the VBUS power supply driver. Thus, to probe the driver
with the correct compatible, the AXP221 and the AXP223 now have separate
MFD cells.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/mfd/axp20x.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be..989d568 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -602,6 +602,21 @@ static struct mfd_cell axp22x_cells[] = {
},
};
+static struct mfd_cell axp223_cells[] = {
+ {
+ .name = "axp20x-pek",
+ .num_resources = ARRAY_SIZE(axp22x_pek_resources),
+ .resources = axp22x_pek_resources,
+ }, {
+ .name = "axp20x-regulator",
+ }, {
+ .name = "axp20x-usb-power-supply",
+ .of_compatible = "x-powers,axp223-usb-power-supply",
+ .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
+ .resources = axp22x_usb_power_supply_resources,
+ },
+};
+
static struct mfd_cell axp152_cells[] = {
{
.name = "axp20x-pek",
@@ -789,12 +804,17 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
break;
case AXP221_ID:
- case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;
axp20x->regmap_cfg = &axp22x_regmap_config;
axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
break;
+ case AXP223_ID:
+ axp20x->nr_cells = ARRAY_SIZE(axp223_cells);
+ axp20x->cells = axp223_cells;
+ axp20x->regmap_cfg = &axp22x_regmap_config;
+ axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
+ break;
case AXP288_ID:
axp20x->cells = axp288_cells;
axp20x->nr_cells = ARRAY_SIZE(axp288_cells);
--
2.9.3
^ permalink raw reply related
* [PATCH 04/10] power: supply: axp20x_usb_power: add 100mA max current limit for AXP223
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
The X-Powers AXP223 shares most of its behaviour with the AXP221 PMIC
but allows the VBUS power supply max current to be set to 100mA (like
the AXP209 PMIC).
This basically adds a new compatible to the VBUS power supply driver and
adds a check on the compatible when setting current max limit.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/power/supply/axp20x_usb_power.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 638cb52..6d5d451 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -88,11 +88,10 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
case AXP20X_VBUC_CLIMIT_100mA:
- if (power->axp20x_id == AXP202_ID) {
- val->intval = 100000;
- } else {
+ if (power->axp20x_id == AXP221_ID)
val->intval = -1; /* No 100mA limit */
- }
+ else
+ val->intval = 100000;
break;
case AXP20X_VBUC_CLIMIT_500mA:
val->intval = 500000;
@@ -268,6 +267,9 @@ static const struct of_device_id axp20x_usb_power_match[] = {
}, {
.compatible = "x-powers,axp221-usb-power-supply",
.data = (void *)AXP221_ID,
+ }, {
+ .compatible = "x-powers,axp223-usb-power-supply",
+ .data = (void *)AXP223_ID,
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
@@ -324,7 +326,8 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
usb_power_desc = &axp20x_usb_power_desc;
irq_names = axp20x_irq_names;
- } else if (power->axp20x_id == AXP221_ID) {
+ } else if (power->axp20x_id == AXP221_ID ||
+ power->axp20x_id == AXP223_ID) {
usb_power_desc = &axp22x_usb_power_desc;
irq_names = axp22x_irq_names;
} else {
--
2.9.3
^ permalink raw reply related
* [PATCH 03/10] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-kernel,
Quentin Schulz, linux-arm-kernel
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
This adds the "x-powers,axp223-usb-power-supply" to the list of
compatibles for AXP20X VBUS power supply driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
index f1d7bee..bf3953c 100644
--- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
@@ -3,6 +3,7 @@ AXP20x USB power supply
Required Properties:
-compatible: One of: "x-powers,axp202-usb-power-supply"
"x-powers,axp221-usb-power-supply"
+ "x-powers,axp223-usb-power-supply"
This node is a subnode of the axp20x PMIC.
--
2.9.3
^ permalink raw reply related
* [PATCH 02/10] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-kernel,
Quentin Schulz, linux-arm-kernel
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
AXP20X and AXP22X PMICs allow setting the min voltage and max current of
VBUS power supply. This adds entries in sysfs to allow to do so.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/power/supply/axp20x_usb_power.c | 72 +++++++++++++++++++++++++++++++++
include/linux/mfd/axp20x.h | 3 ++
2 files changed, 75 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index b19754e..638cb52 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -155,6 +155,74 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
return 0;
}
+static int axp20x_usb_power_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
+ int ret, val1;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN:
+ switch (val->intval) {
+ case 4000000:
+ case 4100000:
+ case 4200000:
+ case 4300000:
+ case 4400000:
+ case 4500000:
+ case 4600000:
+ case 4700000:
+ val1 = (val->intval - 4000000) / 100000;
+ ret = regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_VHOLD_MASK,
+ val1 << 3);
+ if (ret)
+ return ret;
+
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+
+ case POWER_SUPPLY_PROP_CURRENT_MAX:
+ switch (val->intval) {
+ case 100000:
+ if (power->axp20x_id == AXP221_ID)
+ return -EINVAL;
+ case 500000:
+ case 900000:
+ val1 = (900000 - val->intval) / 400000;
+ ret = regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val1);
+ if (ret)
+ return ret;
+
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int axp20x_usb_power_prop_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
+ psp == POWER_SUPPLY_PROP_CURRENT_MAX;
+}
+
static enum power_supply_property axp20x_usb_power_properties[] = {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
@@ -178,7 +246,9 @@ static const struct power_supply_desc axp20x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp20x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp20x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static const struct power_supply_desc axp22x_usb_power_desc = {
@@ -186,7 +256,9 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
.type = POWER_SUPPLY_TYPE_USB,
.properties = axp22x_usb_power_properties,
.num_properties = ARRAY_SIZE(axp22x_usb_power_properties),
+ .property_is_writeable = axp20x_usb_power_prop_writeable,
.get_property = axp20x_usb_power_get_property,
+ .set_property = axp20x_usb_power_set_property,
};
static const struct of_device_id axp20x_usb_power_match[] = {
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index fec597f..8883595 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -56,6 +56,9 @@ enum {
#define AXP20X_LDO24_V_OUT 0x28
#define AXP20X_LDO3_V_OUT 0x29
#define AXP20X_VBUS_IPSOUT_MGMT 0x30
+
+#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
+
#define AXP20X_V_OFF 0x31
#define AXP20X_OFF_CTRL 0x32
#define AXP20X_CHRG_CTRL1 0x33
--
2.9.3
^ permalink raw reply related
* [PATCH 01/10] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-kernel,
Quentin Schulz, linux-arm-kernel
In-Reply-To: <20161125090921.23138-1-quentin.schulz@free-electrons.com>
This replaces calls to of_device_is_compatible to check data field of
of_device_id matched when probing the driver.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/power/supply/axp20x_usb_power.c | 39 ++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index 6af6feb..b19754e 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -17,6 +17,7 @@
#include <linux/mfd/axp20x.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/regmap.h>
@@ -45,6 +46,7 @@ struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
struct power_supply *supply;
+ int axp20x_id;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -86,8 +88,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
case AXP20X_VBUC_CLIMIT_100mA:
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
val->intval = 100000;
} else {
val->intval = -1; /* No 100mA limit */
@@ -130,8 +131,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
val->intval = POWER_SUPPLY_HEALTH_GOOD;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
ret = regmap_read(power->regmap,
AXP20X_USB_OTG_STATUS, &v);
if (ret)
@@ -189,6 +189,17 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
.get_property = axp20x_usb_power_get_property,
};
+static const struct of_device_id axp20x_usb_power_match[] = {
+ {
+ .compatible = "x-powers,axp202-usb-power-supply",
+ .data = (void *)AXP202_ID,
+ }, {
+ .compatible = "x-powers,axp221-usb-power-supply",
+ .data = (void *)AXP221_ID,
+ }, { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
+
static int axp20x_usb_power_probe(struct platform_device *pdev)
{
struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -200,11 +211,16 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
"VBUS_PLUGIN", "VBUS_REMOVAL", NULL };
static const char * const *irq_names;
const struct power_supply_desc *usb_power_desc;
+ const struct of_device_id *of_id;
int i, irq, ret;
if (!of_device_is_available(pdev->dev.of_node))
return -ENODEV;
+ of_id = of_match_device(axp20x_usb_power_match, &pdev->dev);
+ if (!of_id)
+ return -ENODEV;
+
if (!axp20x) {
dev_err(&pdev->dev, "Parent drvdata not set\n");
return -EINVAL;
@@ -214,11 +230,12 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
if (!power)
return -ENOMEM;
+ power->axp20x_id = (int)of_id->data;
+
power->np = pdev->dev.of_node;
power->regmap = axp20x->regmap;
- if (of_device_is_compatible(power->np,
- "x-powers,axp202-usb-power-supply")) {
+ if (power->axp20x_id == AXP202_ID) {
/* Enable vbus valid checking */
ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
AXP20X_VBUS_MON_VBUS_VALID,
@@ -235,8 +252,7 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
usb_power_desc = &axp20x_usb_power_desc;
irq_names = axp20x_irq_names;
- } else if (of_device_is_compatible(power->np,
- "x-powers,axp221-usb-power-supply")) {
+ } else if (power->axp20x_id == AXP221_ID) {
usb_power_desc = &axp22x_usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -272,13 +288,6 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id axp20x_usb_power_match[] = {
- { .compatible = "x-powers,axp202-usb-power-supply" },
- { .compatible = "x-powers,axp221-usb-power-supply" },
- { }
-};
-MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
-
static struct platform_driver axp20x_usb_power_driver = {
.probe = axp20x_usb_power_probe,
.driver = {
--
2.9.3
^ permalink raw reply related
* [PATCH 00/10] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2016-11-25 9:09 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the VBUS power
supply for both max current and min voltage supplied. This series of patch adds
the possibility to set these limits from sysfs.
Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but the
former can set the VBUS power supply max current to 100mA, unlike the latter.
The AXP223 VBUS power supply driver used to probe on the AXP221 compatible. This
series of patch introduces a new compatible for the AXP223 to be able to set the
current max limit to 100mA.
With that new compatible, boards having the AXP223 see their DT updated to use
the VBUS power supply driver with the correct compatible.
This series of patch also migrates from of_device_is_compatible function to the
data field of of_device_id to identify the compatible used to probe. This
improves the code readability.
Quentin Schulz (10):
power: supply: axp20x_usb_power: use of_device_id data field instead
of device_is_compatible
power: supply: axp20x_usb_power: set min voltage and max current from
sysfs
Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
power: supply: axp20x_usb_power: add 100mA max current limit for
AXP223
mfd: axp20x: add separate MFD cell for AXP223
ARM: dtsi: add DTSI for AXP223
ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
.../bindings/power/supply/axp20x_usb_power.txt | 1 +
arch/arm/boot/dts/axp223.dtsi | 55 ++++++++++
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 2 +-
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
.../boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
drivers/mfd/axp20x.c | 22 +++-
drivers/power/supply/axp20x_usb_power.c | 120 +++++++++++++++++----
include/linux/mfd/axp20x.h | 3 +
9 files changed, 186 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/boot/dts/axp223.dtsi
--
2.9.3
^ permalink raw reply
* Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Giuseppe CAVALLARO @ 2016-11-25 8:59 UTC (permalink / raw)
To: Jerome Brunet, Martin Blumenstingl,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, carlo-KA+7E9HrN00dnm+yROfE0A
In-Reply-To: <1480003681.17538.142.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 11/24/2016 5:08 PM, Jerome Brunet wrote:
> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>> cycle TX clock delay. This seems to work fine for many boards (for
>> example Odroid-C2 or Amlogic's reference boards) but there are some
>> others where TX traffic is simply broken.
>> There are probably multiple reasons why it's working on some boards
>> while it's broken on others:
>> - some of Amlogic's reference boards are using a Micrel PHY
>> - hardware circuit design
>> - maybe more...
>>
>> This raises a question though:
>> Which device is supposed to enable the TX delay when both MAC and PHY
>> support it? And should we implement it for each PHY / MAC separately
>> or should we think about a more generic solution (currently it's not
>> possible to disable the TX delay generated by the RTL8211F PHY via
>> devicetree when using phy-mode "rgmii")?
>>
>> iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
>> TX clock delay disabled on the MAC (as it's enabled in the PHY
>> driver).
>> TX throughput was virtually zero before:
>> $ iperf3 -c 192.168.1.100 -R
>> Connecting to host 192.168.1.100, port 5201
>> Reverse mode, remote host 192.168.1.100 is sending
>> [ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port
>> 5201
>> [ ID] Interval Transfer Bandwidth
>> [ 4] 0.00-1.00 sec 108 MBytes 901
>> Mbits/sec
>> [ 4] 1.00-2.00 sec 94.2 MBytes 791
>> Mbits/sec
>> [ 4] 2.00-3.00 sec 96.5 MBytes 810
>> Mbits/sec
>> [ 4] 3.00-4.00 sec 96.2 MBytes 808
>> Mbits/sec
>> [ 4] 4.00-5.00 sec 96.6 MBytes 810
>> Mbits/sec
>> [ 4] 5.00-6.00 sec 96.5 MBytes 810
>> Mbits/sec
>> [ 4] 6.00-7.00 sec 96.6 MBytes 810
>> Mbits/sec
>> [ 4] 7.00-8.00 sec 96.5 MBytes 809
>> Mbits/sec
>> [ 4] 8.00-9.00 sec 105 MBytes 884
>> Mbits/sec
>> [ 4] 9.00-10.00 sec 111 MBytes 934
>> Mbits/sec
>> - - - - - - - - - - - - - - - - - - - - - - - - -
>> [ ID] Interval Transfer Bandwidth Retr
>> [ 4] 0.00-10.00 sec 1000 MBytes 839
>> Mbits/sec 0 sender
>> [ 4] 0.00-10.00 sec 998 MBytes 837
>> Mbits/sec receiver
>>
>> iperf Done.
>> $ iperf3 -c 192.168.1.100
>> Connecting to host 192.168.1.100, port 5201
>> [ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port
>> 5201
>> [ ID] Interval Transfer Bandwidth Retr Cwnd
>> [ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139
>> KBytes
>> [ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7
>> KBytes
>> [ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187
>> KBytes
>> [ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143
>> KBytes
>> [ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129
>> KBytes
>> [ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195
>> KBytes
>> [ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7
>> KBytes
>> [ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6
>> KBytes
>> [ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107
>> KBytes
>> [ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139
>> KBytes
>> - - - - - - - - - - - - - - - - - - - - - - - - -
>> [ ID] Interval Transfer Bandwidth Retr
>> [ 4] 0.00-10.01 sec 1.02 GBytes 874
>> Mbits/sec 1189 sender
>> [ 4] 0.00-10.01 sec 1.02 GBytes 873
>> Mbits/sec receiver
>>
>
> Cool, one more board working ;)
> I tried your patch on another board (MXQ_V2.1, with sheep printed on
> the PCB). It 's not improving the situation for this one unfortunately.
> Actually I already tried playing with the TX delay on the MAC and PHY
> but I could get any good results with the boards I have.
>
> It is strange that we can adjust the delay by 2ns steps, when delay
> seens by the phy should be 2ns ...
>
Ok, as said, I could expect that extra delay was needed on GiGa.
FYI, on ST platforms, this extra delay was added in the pintctrl
dtsi. I mean, in some way, ad-hoc setup was solved at device-tree
level. Usually, extra delay could depend on the PCB.
peppe
>> iperf Done.
>>
>>
>> Martin Blumenstingl (2):
>> net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
>> net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
>>
>> Documentation/devicetree/bindings/net/meson-dwmac.txt | 11
>> +++++++++++
>> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 16
>> +++++++++++-----
>> include/dt-bindings/net/dwmac-meson8b.h | 18
>> ++++++++++++++++++
>> 3 files changed, 40 insertions(+), 5 deletions(-)
>> create mode 100644 include/dt-bindings/net/dwmac-meson8b.h
>>
>
--
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 mmc/next] mmc: sh_mmcif: Document r8a73a4, r8a7778 and sh73a0 DT bindings
From: Geert Uytterhoeven @ 2016-11-25 8:58 UTC (permalink / raw)
To: Simon Horman
Cc: Ulf Hansson, Linux MMC List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Magnus Damm,
Linux-Renesas
In-Reply-To: <20161125075614.GB14431-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Fri, Nov 25, 2016 at 8:56 AM, Simon Horman
<horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> Simply document new compatibility strings as the driver is already
> activated using a fallback compatibility string.
>
> These compat strings are in keeping with those for all other
> Renesas ARM based SoCs with sh_mmcif enabled in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Acked-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-25 8:46 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, benh@kernel.crashing.org,
liviu.dudau@arm.com, Linuxarm, lorenzo.pieralisi@arm.com,
xuwei (O), Jason Gunthorpe, T homas Petazzoni,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
devicetree@vger.kernel.org, minyard@acm.org, will.deacon@arm.com,
John Garry, zourongrong@gmail.com, robh+dt@kernel.org,
bhelgaas@go og le.com, kantyzc@163.com, zhichang.yuan02
In-Reply-To: <4675465.4Qhqy6WU4X@wuerfel>
Hi Arnd
Many thanks for your contribution, much appreciated
I have some comments...see inline below
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 23 November 2016 23:23
> To: linux-arm-kernel@lists.infradead.org
> Cc: Gabriele Paoloni; mark.rutland@arm.com; catalin.marinas@arm.com;
> linux-pci@vger.kernel.org; liviu.dudau@arm.com; Linuxarm;
> lorenzo.pieralisi@arm.com; xuwei (O); Jason Gunthorpe; T homas
> Petazzoni; linux-serial@vger.kernel.org; benh@kernel.crashing.org;
> devicetree@vger.kernel.org; minyard@acm.org; will.deacon@arm.com; John
> Garry; olof@lixom.net; robh+dt@kernel.org; bhelgaas@go og le.com;
> kantyzc@163.com; zhichang.yuan02@gmail.com; linux-
> kernel@vger.kernel.org; Yuanzhichang; zourongrong@gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Wednesday, November 23, 2016 6:07:11 PM CET Arnd Bergmann wrote:
> > On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni
> wrote:
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni
> wrote:
> >
> > Please don't proliferate the use of
> > pci_pio_to_address/pci_address_to_pio here, computing the physical
> > address from the logical address is trivial, you just need to
> > subtract the start of the range that you already use when matching
> > the port number range.
> >
> > The only thing we need here is to make of_address_to_resource()
> > return the correct logical port number that was registered for
> > a given host device when asked to translate an address that
> > does not have a CPU address associated with it.
>
> Ok, I admit this was a little harder than I expected, but see below
> for a rough outline of how I think it can be done.
>
> This makes it possible to translate bus specific I/O port numbers
> from device nodes into Linux port numbers, and gives a way to register
> them. We could take this further and completely remove
> pci_pio_to_address
> and pci_address_to_pio if we make the I/O port translation always
> go through the io_range list, looking up up the hostbridge by fwnode,
> but we don't have to do that now.
>
> The patch is completely untested and probably buggy, it just seemed
> easier to put out a prototype than to keep going in circles with the
> discussion.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index bf601d4df8cf..6cadf0501bb0 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct
> device *dev,
> }
> }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *node,
> + struct resource_entry *entry)
> {
> #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,11 +740,7 @@ static void acpi_pci_root_remap_iospace(struct
> resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> - if (pci_register_io_range(cpu_addr, length))
> - goto err;
> -
> - port = pci_address_to_pio(cpu_addr);
> - if (port == (unsigned long)-1)
> + if (pci_register_io_range(node, cpu_addr, length, &port))
> goto err;
>
> res->start = port;
> @@ -781,7 +778,8 @@ int acpi_pci_probe_root_resources(struct
> acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> - acpi_pci_root_remap_iospace(entry);
> + acpi_pci_root_remap_iospace(&device->fwnode,
> + entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index a50025a3777f..df96955a43f8 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -760,8 +760,10 @@ static int __nbd_ioctl(struct block_device *bdev,
> struct nbd_device *nbd,
> set_bit(NBD_RUNNING, &nbd->runtime_flags);
> blk_mq_update_nr_hw_queues(&nbd->tag_set, nbd-
> >num_connections);
> args = kcalloc(num_connections, sizeof(*args), GFP_KERNEL);
> - if (!args)
> + if (!args) {
> + error = -ENOMEM;
> goto out_err;
> + }
> nbd->task_recv = current;
> mutex_unlock(&nbd->config_lock);
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903fe9d2..5decaba96eed 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
> #define pr_fmt(fmt) "OF: " fmt
>
> #include <linux/device.h>
> +#include <linux/fwnode.h>
> #include <linux/io.h>
> #include <linux/ioport.h>
> #include <linux/module.h>
> @@ -323,14 +324,9 @@ int of_pci_range_to_resource(struct of_pci_range
> *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> - err = pci_register_io_range(range->cpu_addr, range->size);
> + err = pci_register_io_range(&np->fwnode, range->cpu_addr,
> range->size, &port);
> if (err)
> goto invalid_range;
> - port = pci_address_to_pio(range->cpu_addr);
> - if (port == (unsigned long)-1) {
> - err = -EINVAL;
> - goto invalid_range;
> - }
> res->start = port;
> } else {
> if ((sizeof(resource_size_t) < 8) &&
> @@ -479,7 +475,7 @@ static int of_empty_ranges_quirk(struct device_node
> *np)
> return false;
> }
>
> -static int of_translate_one(struct device_node *parent, struct of_bus
> *bus,
> +static u64 of_translate_one(struct device_node *parent, struct of_bus
> *bus,
> struct of_bus *pbus, __be32 *addr,
> int na, int ns, int pna, const char *rprop)
> {
> @@ -507,7 +503,7 @@ static int of_translate_one(struct device_node
> *parent, struct of_bus *bus,
> ranges = of_get_property(parent, rprop, &rlen);
> if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
> pr_debug("no ranges; cannot translate\n");
> - return 1;
> + return OF_BAD_ADDR;
> }
> if (ranges == NULL || rlen == 0) {
> offset = of_read_number(addr, na);
> @@ -528,7 +524,7 @@ static int of_translate_one(struct device_node
> *parent, struct of_bus *bus,
> }
> if (offset == OF_BAD_ADDR) {
> pr_debug("not found !\n");
> - return 1;
> + return offset;
> }
> memcpy(addr, ranges + na, 4 * pna);
>
> @@ -537,7 +533,10 @@ static int of_translate_one(struct device_node
> *parent, struct of_bus *bus,
> pr_debug("with offset: %llx\n", (unsigned long long)offset);
>
> /* Translate it into parent bus space */
> - return pbus->translate(addr, offset, pna);
> + if (pbus->translate(addr, offset, pna))
> + return OF_BAD_ADDR;
> +
> + return offset;
> }
>
> /*
> @@ -549,9 +548,14 @@ static int of_translate_one(struct device_node
> *parent, struct of_bus *bus,
> * that translation is impossible (that is we are not dealing with a
> value
> * that can be mapped to a cpu physical address). This is not really
> specified
> * that way, but this is traditionally the way IBM at least do things
> + *
> + * Whenever the translation fails, the *host pointer will be set to
> the
> + * device that lacks a tranlation, and the return code is relative to
> + * that node.
This seems to be wrong to me. We are abusing of the error conditions.
So effectively if there is a buggy DT for an IO resource we end up
assuming that we are using a special IO device with unmapped addresses.
The patch at the bottom apply on top of this one and I think is a more
reasonable approach
> */
> static u64 __of_translate_address(struct device_node *dev,
> - const __be32 *in_addr, const char *rprop)
> + const __be32 *in_addr, const char *rprop,
> + struct device_node **host)
> {
> struct device_node *parent = NULL;
> struct of_bus *bus, *pbus;
> @@ -564,6 +568,7 @@ static u64 __of_translate_address(struct
> device_node *dev,
> /* Increase refcount at current level */
> of_node_get(dev);
>
> + *host = NULL;
> /* Get parent & match bus type */
> parent = of_get_parent(dev);
> if (parent == NULL)
> @@ -600,8 +605,9 @@ static u64 __of_translate_address(struct
> device_node *dev,
> pbus = of_match_bus(parent);
> pbus->count_cells(dev, &pna, &pns);
> if (!OF_CHECK_COUNTS(pna, pns)) {
> - pr_err("Bad cell count for %s\n",
> - of_node_full_name(dev));
> + pr_debug("Bad cell count for %s\n",
> + of_node_full_name(dev));
> + *host = of_node_get(parent);
> break;
> }
>
> @@ -609,7 +615,9 @@ static u64 __of_translate_address(struct
> device_node *dev,
> pbus->name, pna, pns, of_node_full_name(parent));
>
> /* Apply bus translation */
> - if (of_translate_one(dev, bus, pbus, addr, na, ns, pna,
> rprop))
> + result = of_translate_one(dev, bus, pbus, addr, na, ns,
> + pna, rprop);
> + if (result == OF_BAD_ADDR)
It seems to me that here you missed "*host = of_node_get(parent);"..?
> break;
>
> /* Complete the move up one level */
> @@ -628,13 +636,32 @@ static u64 __of_translate_address(struct
> device_node *dev,
>
> u64 of_translate_address(struct device_node *dev, const __be32
> *in_addr)
> {
> - return __of_translate_address(dev, in_addr, "ranges");
> + struct device_node *host;
> + u64 ret;
> +
> + ret = __of_translate_address(dev, in_addr, "ranges", &host);
> + if (host) {
> + of_node_put(host);
> + return OF_BAD_ADDR;
> + }
> +
> + return ret;
> }
> EXPORT_SYMBOL(of_translate_address);
>
> u64 of_translate_dma_address(struct device_node *dev, const __be32
> *in_addr)
> {
> - return __of_translate_address(dev, in_addr, "dma-ranges");
> + struct device_node *host;
> + u64 ret;
> +
> + ret = __of_translate_address(dev, in_addr, "dma-ranges", &host);
> +
> + if (host) {
> + of_node_put(host);
> + return OF_BAD_ADDR;
> + }
> +
> + return ret;
> }
> EXPORT_SYMBOL(of_translate_dma_address);
>
> @@ -676,29 +703,48 @@ const __be32 *of_get_address(struct device_node
> *dev, int index, u64 *size,
> }
> EXPORT_SYMBOL(of_get_address);
>
> +extern unsigned long extio_translate(struct fwnode_handle *node,
> unsigned long offset);
> +
> +u64 of_translate_ioport(struct device_node *dev, const __be32
> *in_addr)
> +{
> + u64 taddr;
> + unsigned long port;
> + struct device_node *host;
> +
> + taddr = __of_translate_address(dev, in_addr, "ranges", &host);
> + if (host) {
> + /* host specific port access */
> + port = extio_translate(&host->fwnode, taddr);
> + of_node_put(host);
> + } else {
> + /* memory mapped I/O range */
> + port = pci_address_to_pio(taddr);
> + if (port == (unsigned long)-1)
> + return OF_BAD_ADDR;
> + }
> +
> + return port;
> +}
> +
> static int __of_address_to_resource(struct device_node *dev,
> const __be32 *addrp, u64 size, unsigned int flags,
> const char *name, struct resource *r)
> {
> u64 taddr;
>
> - if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
> + if (flags & IORESOURCE_MEM)
> + taddr = of_translate_address(dev, addrp);
> + else if (flags & IORESOURCE_IO)
> + taddr = of_translate_ioport(dev, addrp);
> + else
> return -EINVAL;
> - taddr = of_translate_address(dev, addrp);
> +
> if (taddr == OF_BAD_ADDR)
> return -EINVAL;
> memset(r, 0, sizeof(struct resource));
> - if (flags & IORESOURCE_IO) {
> - unsigned long port;
> - port = pci_address_to_pio(taddr);
> - if (port == (unsigned long)-1)
> - return -EINVAL;
> - r->start = port;
> - r->end = port + size - 1;
> - } else {
> - r->start = taddr;
> - r->end = taddr + size - 1;
> - }
> +
> + r->start = taddr;
> + r->end = taddr + size - 1;
> r->flags = flags;
> r->name = name ? name : dev->full_name;
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index eda6a7cf0e54..320ab9fbf6af 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3249,6 +3249,7 @@ EXPORT_SYMBOL(pci_request_regions_exclusive);
> #ifdef PCI_IOBASE
> struct io_range {
> struct list_head list;
> + struct fwnode_handle *node;
> phys_addr_t start;
> resource_size_t size;
> };
> @@ -3257,11 +3258,14 @@ static LIST_HEAD(io_range_list);
> static DEFINE_SPINLOCK(io_range_lock);
> #endif
>
> +#define IO_RANGE_IOEXT (resource_size_t)(-1ull)
> +
> /*
> * Record the PCI IO range (expressed as CPU physical address + size).
> * Return a negative value if an error has occured, zero otherwise
> */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t
> size)
> +int __weak pci_register_io_range(struct fwnode_handle *node,
> phys_addr_t addr,
> + resource_size_t size, unsigned long *port)
> {
> int err = 0;
>
> @@ -3272,7 +3276,12 @@ int __weak pci_register_io_range(phys_addr_t
> addr, resource_size_t size)
> /* check if the range hasn't been previously recorded */
> spin_lock(&io_range_lock);
> list_for_each_entry(range, &io_range_list, list) {
> - if (addr >= range->start && addr + size <= range->start +
> size) {
> + if (node == range->node)
> + goto end_register;
> +
It seems to me that the condition above is sufficient; i.e.
we can remove the one here below...?
> + if (addr != IO_RANGE_IOEXT &&
> + addr >= range->start &&
> + addr + size <= range->start + size) {
> /* range already registered, bail out */
> goto end_register;
> }
> @@ -3298,6 +3307,7 @@ int __weak pci_register_io_range(phys_addr_t
> addr, resource_size_t size)
> goto end_register;
> }
>
> + range->node = node;
> range->start = addr;
> range->size = size;
>
> @@ -3305,11 +3315,26 @@ int __weak pci_register_io_range(phys_addr_t
> addr, resource_size_t size)
>
> end_register:
> spin_unlock(&io_range_lock);
> +
> + *port = allocated_size;
> +#else
> + /*
> + * powerpc and microblaze have their own registration,
> + * just look up the value here
> + */
> + *port = pci_address_to_pio(addr);
> #endif
>
> return err;
> }
>
> +#ifdef CONFIG_IOEXT
> +int ioext_register_io_range
> +{
> + return pci_register_io_range(node, IO_RANGE_IOEXT, size, port);
> +}
> +#endif
> +
> phys_addr_t pci_pio_to_address(unsigned long pio)
> {
> phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 6bd94a803e8f..b7a8fa3da3ca 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1192,7 +1192,8 @@ int __must_check pci_bus_alloc_resource(struct
> pci_bus *bus,
> void *alignf_data);
>
>
> -int pci_register_io_range(phys_addr_t addr, resource_size_t size);
> +int pci_register_io_range(struct fwnode_handle *node, phys_addr_t
> addr,
> + resource_size_t size, unsigned long *port);
> unsigned long pci_address_to_pio(phys_addr_t addr);
> phys_addr_t pci_pio_to_address(unsigned long pio);
> int pci_remap_iospace(const struct resource *res, phys_addr_t
> phys_addr);
I think the patch below is a more reasonable approach to identify
a host that does not support address translation and it should
guarantee safety against broken DTs...
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5decaba..9bfc526 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -540,6 +540,49 @@ static u64 of_translate_one(struct device_node *parent, struct of_bus *bus,
}
Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
/*
+ * of_isa_indirect_io - get the IO address from some isa reg property value.
+ * For some isa/lpc devices, no ranges property in ancestor node.
+ * The device addresses are described directly in their regs property.
+ * This fixup function will be called to get the IO address of isa/lpc
+ * devices when the normal of_translation failed.
+ *
+ * @parent: points to the parent dts node;
+ * @bus: points to the of_bus which can be used to parse address;
+ * @addr: the address from reg property;
+ * @na: the address cell counter of @addr;
+ * @presult: store the address paresed from @addr;
+ *
+ * return 1 when successfully get the I/O address;
+ * 0 will return for some failures.
+ */
+static int of_get_isa_indirect_io(struct device_node *parent,
+ struct of_bus *bus, __be32 *addr,
+ int na, u64 *presult)
+{
+ unsigned int flags;
+ unsigned int rlen;
+
+ /* whether support indirectIO */
+ if (!indirect_io_enabled())
+ return 0;
+
+ if (!of_bus_isa_match(parent))
+ return 0;
+
+ flags = bus->get_flags(addr);
+ if (!(flags & IORESOURCE_IO))
+ return 0;
+
+ /* there is ranges property, apply the normal translation directly. */
+ if (of_get_property(parent, "ranges", &rlen))
+ return 0;
+
+ *presult = of_read_number(addr + 1, na - 1);
+ /* this fixup is only valid for specific I/O range. */
+ return addr_is_indirect_io(*presult);
+}
+
+/*
* Translate an address from the device-tree into a CPU physical address,
* this walks up the tree and applies the various bus mappings on the
* way.
@@ -600,14 +643,23 @@ static u64 __of_translate_address(struct device_node *dev,
result = of_read_number(addr, na);
break;
}
+ /*
+ * For indirectIO device which has no ranges property, get
+ * the address from reg directly.
+ */
+ if (of_get_isa_indirect_io(dev, bus, addr, na, &result)) {
+ pr_debug("isa indirectIO matched(%s)..addr = 0x%llx\n",
+ of_node_full_name(dev), result);
+ *host = of_node_get(parent);
+ break;
+ }
/* Get new parent bus and counts */
pbus = of_match_bus(parent);
pbus->count_cells(dev, &pna, &pns);
if (!OF_CHECK_COUNTS(pna, pns)) {
- pr_debug("Bad cell count for %s\n",
+ pr_err("Bad cell count for %s\n",
of_node_full_name(dev));
- *host = of_node_get(parent);
break;
}
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 3786473..14848d8 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -24,6 +24,23 @@ struct of_pci_range {
#define for_each_of_pci_range(parser, range) \
for (; of_pci_range_parser_one(parser, range);)
+#ifndef indirect_io_enabled
+#define indirect_io_enabled indirect_io_enabled
+static inline bool indirect_io_enabled(void)
+{
+ return false;
+}
+#endif
+
+#ifndef addr_is_indirect_io
+#define addr_is_indirect_io addr_is_indirect_io
+static inline int addr_is_indirect_io(u64 taddr)
+{
+ return 0;
+}
+#endif
+
+
/* Translate a DMA address from device space to CPU space */
extern u64 of_translate_dma_address(struct device_node *dev,
const __be32 *in_addr);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-11-25 8:45 UTC (permalink / raw)
To: Ulf Hansson, Adrian Hunter
Cc: Gregory CLEMENT, linux-mmc@vger.kernel.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding, Romain Perier
In-Reply-To: <76ce72f8-4b86-3b83-544f-b9a7ef871393@marvell.com>
Hi Ulf,
On 2016/11/24 23:00, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/24 21:34, Ulf Hansson wrote:
<snip>
>>>>> +
>>>>> + /*
>>>>> + * Xenon Specific property:
>>>>> + * emmc: explicitly indicate whether this slot is for eMMC
>>>>> + * slotno: the index of slot. Refer to SDHC_SYS_CFG_INFO register
>>>>> + * tun-count: the interval between re-tuning
>>>>> + * PHY type: "sdhc phy", "emmc phy 5.0" or "emmc phy 5.1"
>>>>> + */
>>>>> + if (of_property_read_bool(np, "marvell,xenon-emmc"))
>>>>> + priv->emmc_slot = true;
>>>>
>>>> So, you need this because of the eMMC voltage switch behaviour, right?
>>>>
>>>> Then I would rather like to describe this a generic DT bindings for
>>>> the eMMC voltage level support. There have acutally been some earlier
>>>> discussions for this, but we haven't yet made some changes.
>>>>
>>>> I think what is missing is a mmc-ddr-3_3v DT binding, which when set,
>>>> allows the host driver to accept I/O voltage switches to 3.3V. If not
>>>> supported the ->start_signal_voltage_switch() ops may return -EINVAL.
>>>> This would inform the mmc core to move on to the next supported
>>>> voltage level. There might be some minor additional changes to the mmc
>>>> card initialization sequence, but those should be simple.
>>>>
>>>> I can help out to look into this, unless you want to do it yourself of course!?
>>>>
>>> Yes. One of the reasons is to provide eMMC specific voltage setting.
>>> But in my very own opinion, it should be irrelevant to voltage level.
>>> The eMMC voltage setting on our SDHC is different from SD/SDIO voltage switch.
>>> It will become more complex with different SOC implementation details.
>>
>> Got it. Although I think we can cope with that fine just by using the
>> different SD/eMMC speed modes settings defined in DT (or from the
>> SDHCI caps register)
>>
> In my very opinion, I'm not sure if there is any corner case that driver cannot
> determine the eMMC card type from DT and SDHC caps.
>
>>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>>> setting should be executed.
>>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>>
>>> Besides, additional eMMC specific settings might be implemented in future, besides
>>> voltage setting. Most of them should be completed before MMC driver recognizes the
>>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>>
>> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>>
>> Currently it's clear you don't need such a flag, so I will submit a
>> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
>> there, to see if it suits your needs.
>>
Another reason for a special "xenon-emmc" property is that our host IP usually can
support both eMMC and SD. Whether a host is used as eMMC or SD depends on the
final implementation of the actual product.
Thus our host driver needs to know whether current SDHC is fixed as eMMC or SD.
So far, It can only get the information from DT.
After out host driver get the card type information from DT, it can prepare eMMC
specific voltage, set eMMC specific mmc->caps/caps2 flags and do other
vendor specific init, before card init procedure.
Otherwise, our host driver has to wait until card type is determined in mmc_rescan().
A generic "eMMC" flag is unnecessary. I just require a private property,
which is only used in our host driver and DT.
Thank you.
Best regards,
Hu Ziji
>
> Actually, our eMMC is usually fixed as 1.8V.
>
> The pair "no-sd" + "no-sdio" can provide the similar information.
> But I'm not sure if it is proper to use those two property in such a way.
>
> Thank you.
>
> Best regards
> Hu Ziji
>
>> [...]
>>
>> Kind regards
>> Uffe
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 V3 2/4] mfd: pv88080: MFD core support
From: Lee Jones @ 2016-11-25 8:34 UTC (permalink / raw)
To: Eric Hyeung Dong Jeong
Cc: LINUX-KERNEL, Alexandre Courbot, DEVICETREE, LINUX-GPIO,
Liam Girdwood, Linus Walleij, Mark Brown, Mark Rutland,
Rob Herring, Support Opensource
In-Reply-To: <8FA4409277D6E54680546B8811D8541002A088125C@NB-EX-MBX01.diasemi.com>
On Fri, 25 Nov 2016, Eric Hyeung Dong Jeong wrote:
> On Monday, November 21, 2016 10:09 PM, Lee Jones Wrote:
> > On Fri, 18 Nov 2016, Eric Jeong wrote:
> >
> > >
> > > From: Eric Jeong <eric.jeong.opensource@diasemi.com>
> > >
> > > This patch adds supports for PV88080 MFD core device.
> > >
> > > It provides communication through the I2C interface.
> > > It contains the following components:
> > > - Regulators
> > > - Configurable GPIOs
> > >
> > > Kconfig and Makefile are updated to reflect support for PV88080 PMIC.
> > >
> > > Signed-off-by: Eric Jeong <eric.jeong.opensource@diasemi.com>
> > >
> > > ---
> > > This patch applies against linux-next and next-20161117
> > >
> > > Hi,
> > >
> > > This patch adds MFD core driver for PV88080 PMIC.
> > > This is done as part of the existing PV88080 regulator driver by
> > > expending the driver for GPIO function support.
> > >
> > > Change since PATCH V2
> > > - Make one file insted of usging core and i2c file
> > > - Use devm_ function to be managed resource automatically
> > > - Separated mfd_cell and regmap_irq_chip declaration for clarification.
> > > - Updated Kconfig to use OF and assign yes to I2C
> > >
> > > Change since PATCH V1
> > > - Patch separated from PATCH V1
> > >
> > > Regards,
> > > Eric Jeong, Dialog Semiconductor Ltd.
> > >
> > >
> > > drivers/mfd/Kconfig | 12 ++
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/pv88080.c | 331 +++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/pv88080.h | 222 +++++++++++++++++++++++++++++
> > > 4 files changed, 566 insertions(+)
> > > create mode 100644 drivers/mfd/pv88080.c create mode 100644
> > > include/linux/mfd/pv88080.h
It's a good idea to cut out all of the code/comments that is either
not relevant, or you are not providing comment (besides "will do")
on.
> > > +struct pv88080 {
> > > + struct device *dev;
> > > + struct regmap *regmap;
> > > + unsigned long type;
> >
> > Does this really need to be in here?
>
> The *type* member is used for separating silicon type.
> And, regulator and gpio driver also use the member to check the type
> for proper configuration without additional code.
> That is the reason that the member is added in the structure.
I don't see how this is being used, so assuming the other Maintainers
are happy with the implementation it's okay for this to live here.
However, please consider changing to something better than "value" or
"type". Perhaps "varian"t or "model" or similar would be better?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] v4l: async: make v4l2 coexists with devicetree nodes in a dt overlay
From: Sakari Ailus @ 2016-11-25 8:21 UTC (permalink / raw)
To: Javi Merino
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou,
Mauro Carvalho Chehab, Javier Martinez Canillas, Sakari Ailus,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <20161123161511.GB1753@ct-lt-587>
Hi Javi,
On Wed, Nov 23, 2016 at 04:15:11PM +0000, Javi Merino wrote:
> On Wed, Nov 23, 2016 at 05:10:42PM +0200, Sakari Ailus wrote:
> > Hi Javi,
>
> Hi Sakari,
>
> > On Wed, Nov 23, 2016 at 10:09:57AM +0000, Javi Merino wrote:
> > > In asd's configured with V4L2_ASYNC_MATCH_OF, if the v4l2 subdev is in
> > > a devicetree overlay, its of_node pointer will be different each time
> > > the overlay is applied. We are not interested in matching the
> > > pointer, what we want to match is that the path is the one we are
> > > expecting. Change to use of_node_cmp() so that we continue matching
> > > after the overlay has been removed and reapplied.
> > >
> > > Cc: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > Cc: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> > > Cc: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > Signed-off-by: Javi Merino <javi.merino-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > ---
> > > Hi,
> > >
> > > I feel it is a bit of a hack, but I couldn't think of anything better.
> > > I'm ccing devicetree@ and Pantelis because there may be a simpler
> > > solution.
> >
> > First I have to admit that I'm not an expert when it comes to DT overlays.
> >
> > That said, my understanding is that the sub-device and the async sub-device
> > are supposed to point to the exactly same DT node. I wonder if there's
> > actually anything wrong in the current code.
> >
> > If the overlay has changed between probing the driver for the async notifier
> > and the async sub-device, there should be no match here, should there? The
> > two nodes actually point to a node in a different overlay in that case.
>
> Overlays are parts of the devicetree that can be added and removed.
> When the overlay is applied, the camera driver is probed and does
> v4l2_async_register_subdev(). However, v4l2_async_belongs() fails.
> The problem is with comparing pointers. I haven't looked at the
> implementation of overlays in detail, but what I see is that the
> of_node pointer changes when you remove and reapply an overlay (I
> guess it's dynamically allocated and when you remove the overlay, it's
> freed).
The concern here which we were discussing was whether the overlay should be
relied on having compliant configuration compared to the part which was not
part of the overlay.
As external components are involved, quite possibly also the ISP DT node
will require changes, not just the image source (TV tuner, camera sensor
etc.). This could be because of number of CSI-2 lanes or parallel bus width,
for instance.
I'd also be interested in having an actual driver implement support for
removing and adding a DT overlay first so we'd see how this would actually
work. We need both in order to be able to actually remove and add DT
overlays _without_ unbinding the ISP driver. Otherwise it should already
work in the current codebase.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@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 1/2] mmc: core: add DT binding for CMD23
From: Ulf Hansson @ 2016-11-25 8:19 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
Rob Herring, Mark Rutland, Adrian Hunter
In-Reply-To: <20161125065215.10833-1-jh80.chung@samsung.com>
On 25 November 2016 at 07:52, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Provide the option to configure one type of multiple block read/wrte
> transatction (CMD23 - it's optional.)
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> drivers/mmc/core/host.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 98f25ff..9bdc369 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -321,6 +321,8 @@ int mmc_of_parse(struct mmc_host *host)
> host->caps2 |= MMC_CAP2_NO_SD;
> if (of_property_read_bool(np, "no-mmc"))
> host->caps2 |= MMC_CAP2_NO_MMC;
> + if (of_property_read_bool(np, "cap-mmc-cmd23"))
> + host->caps |= MMC_CAP_CMD23;
>
> host->dsr_req = !of_property_read_u32(np, "dsr", &host->dsr);
> if (host->dsr_req && (host->dsr & ~0xffff)) {
> --
> 2.10.1
>
I don't think this as HW configuration, but more a SW configuration.
Thus we don't need a DT binding for it, right?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 2/6] iio: adc: Add support for STM32 ADC core
From: Fabrice Gasnier @ 2016-11-25 8:09 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <cd958ae5-90e4-b6c5-8a23-84c49011e8e3-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 11/24/2016 09:40 PM, Jonathan Cameron wrote:
> On 21/11/16 08:54, Fabrice Gasnier wrote:
>> On 11/19/2016 01:17 PM, Jonathan Cameron wrote:
>>> On 15/11/16 15:30, Fabrice Gasnier wrote:
>>>> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
>>>> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
>>>> resources like clock prescaler, common interrupt line and analog
>>>> reference voltage.
>>>> This core driver basically manages shared resources.
>>>>
>>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
>>> There is nothing in here that demands selecting a fixed regulator.
>>> I've also switched the select regulator over to depends on inline with
>>> other drivers in IIO that have a hard dependency on regulators.
>>> Other than that which showed up during build tests, looks good to me.
>>> Shout if I've broken anything with this change.
>> Hi Jonathan, All,
>>
>> First many thanks.
>> This is not a big deal. Only thing is: I think patch 4 of this series (on stm32_defconfig) need to be updated
>> to accommodate this change. E.g. :
>> +CONFIG_REGULATOR=y
>> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
>>
>> Shall I send a new version of this series (all patches), including your changes, with updated defconfig as well ?
>> Or only updated patch on defconfig is enough ?
> Just update those that haven't already been applied.
Hi,
I'll update these only.
Thanks,
Fabrice
>
> Thanks,
>
> Jonathan
>> Please advise,
>> Fabrice
>>> Applied to the togreg branch of iio.git and pushed out as testing for
>>> the autobuilders to play with it.
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>> ---
>>>> drivers/iio/adc/Kconfig | 13 ++
>>>> drivers/iio/adc/Makefile | 1 +
>>>> drivers/iio/adc/stm32-adc-core.c | 303 +++++++++++++++++++++++++++++++++++++++
>>>> drivers/iio/adc/stm32-adc-core.h | 52 +++++++
>>>> 4 files changed, 369 insertions(+)
>>>> create mode 100644 drivers/iio/adc/stm32-adc-core.c
>>>> create mode 100644 drivers/iio/adc/stm32-adc-core.h
>>>>
>>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>>> index 7edcf32..ff30239 100644
>>>> --- a/drivers/iio/adc/Kconfig
>>>> +++ b/drivers/iio/adc/Kconfig
>>>> @@ -419,6 +419,19 @@ config ROCKCHIP_SARADC
>>>> To compile this driver as a module, choose M here: the
>>>> module will be called rockchip_saradc.
>>>> +config STM32_ADC_CORE
>>>> + tristate "STMicroelectronics STM32 adc core"
>>>> + depends on ARCH_STM32 || COMPILE_TEST
>>>> + depends on OF
>>>> + select REGULATOR
>>>> + select REGULATOR_FIXED_VOLTAGE
>>>> + help
>>>> + Select this option to enable the core driver for STMicroelectronics
>>>> + STM32 analog-to-digital converter (ADC).
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called stm32-adc-core.
>>>> +
>>>> config STX104
>>>> tristate "Apex Embedded Systems STX104 driver"
>>>> depends on X86 && ISA_BUS_API
>>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>>> index 7a40c04..a1e8f44 100644
>>>> --- a/drivers/iio/adc/Makefile
>>>> +++ b/drivers/iio/adc/Makefile
>>>> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>>>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>> obj-$(CONFIG_STX104) += stx104.o
>>>> +obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
>>>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>> obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>>> obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>>>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>>>> new file mode 100644
>>>> index 0000000..4214b0c
>>>> --- /dev/null
>>>> +++ b/drivers/iio/adc/stm32-adc-core.c
>>>> @@ -0,0 +1,303 @@
>>>> +/*
>>>> + * This file is part of STM32 ADC driver
>>>> + *
>>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>>> + * Author: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>.
>>>> + *
>>>> + * Inspired from: fsl-imx25-tsadc
>>>> + *
>>>> + * License type: GPLv2
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify it
>>>> + * under the terms of the GNU General Public License version 2 as published by
>>>> + * the Free Software Foundation.
>>>> + *
>>>> + * 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.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License along with
>>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#include <linux/clk.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/irqchip/chained_irq.h>
>>>> +#include <linux/irqdesc.h>
>>>> +#include <linux/irqdomain.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of_device.h>
>>>> +#include <linux/regulator/consumer.h>
>>>> +#include <linux/slab.h>
>>>> +
>>>> +#include "stm32-adc-core.h"
>>>> +
>>>> +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
>>>> +#define STM32F4_ADC_CSR (STM32_ADCX_COMN_OFFSET + 0x00)
>>>> +#define STM32F4_ADC_CCR (STM32_ADCX_COMN_OFFSET + 0x04)
>>>> +
>>>> +/* STM32F4_ADC_CSR - bit fields */
>>>> +#define STM32F4_EOC3 BIT(17)
>>>> +#define STM32F4_EOC2 BIT(9)
>>>> +#define STM32F4_EOC1 BIT(1)
>>>> +
>>>> +/* STM32F4_ADC_CCR - bit fields */
>>>> +#define STM32F4_ADC_ADCPRE_SHIFT 16
>>>> +#define STM32F4_ADC_ADCPRE_MASK GENMASK(17, 16)
>>>> +
>>>> +/* STM32 F4 maximum analog clock rate (from datasheet) */
>>>> +#define STM32F4_ADC_MAX_CLK_RATE 36000000
>>>> +
>>>> +/**
>>>> + * struct stm32_adc_priv - stm32 ADC core private data
>>>> + * @irq: irq for ADC block
>>>> + * @domain: irq domain reference
>>>> + * @aclk: clock reference for the analog circuitry
>>>> + * @vref: regulator reference
>>>> + * @common: common data for all ADC instances
>>>> + */
>>>> +struct stm32_adc_priv {
>>>> + int irq;
>>>> + struct irq_domain *domain;
>>>> + struct clk *aclk;
>>>> + struct regulator *vref;
>>>> + struct stm32_adc_common common;
>>>> +};
>>>> +
>>>> +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
>>>> +{
>>>> + return container_of(com, struct stm32_adc_priv, common);
>>>> +}
>>>> +
>>>> +/* STM32F4 ADC internal common clock prescaler division ratios */
>>>> +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>>>> +
>>>> +/**
>>>> + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
>>>> + * @priv: stm32 ADC core private data
>>>> + * Select clock prescaler used for analog conversions, before using ADC.
>>>> + */
>>>> +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
>>>> + struct stm32_adc_priv *priv)
>>>> +{
>>>> + unsigned long rate;
>>>> + u32 val;
>>>> + int i;
>>>> +
>>>> + rate = clk_get_rate(priv->aclk);
>>>> + for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
>>>> + if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
>>>> + break;
>>>> + }
>>>> + if (i >= ARRAY_SIZE(stm32f4_pclk_div))
>>>> + return -EINVAL;
>>>> +
>>>> + val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>>>> + val &= ~STM32F4_ADC_ADCPRE_MASK;
>>>> + val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>>>> + writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>>>> +
>>>> + dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>>>> + rate / (stm32f4_pclk_div[i] * 1000));
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +/* ADC common interrupt for all instances */
>>>> +static void stm32_adc_irq_handler(struct irq_desc *desc)
>>>> +{
>>>> + struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
>>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>>> + u32 status;
>>>> +
>>>> + chained_irq_enter(chip, desc);
>>>> + status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
>>>> +
>>>> + if (status & STM32F4_EOC1)
>>>> + generic_handle_irq(irq_find_mapping(priv->domain, 0));
>>>> +
>>>> + if (status & STM32F4_EOC2)
>>>> + generic_handle_irq(irq_find_mapping(priv->domain, 1));
>>>> +
>>>> + if (status & STM32F4_EOC3)
>>>> + generic_handle_irq(irq_find_mapping(priv->domain, 2));
>>>> +
>>>> + chained_irq_exit(chip, desc);
>>>> +};
>>>> +
>>>> +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
>>>> + irq_hw_number_t hwirq)
>>>> +{
>>>> + irq_set_chip_data(irq, d->host_data);
>>>> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
>>>> +{
>>>> + irq_set_chip_and_handler(irq, NULL, NULL);
>>>> + irq_set_chip_data(irq, NULL);
>>>> +}
>>>> +
>>>> +static const struct irq_domain_ops stm32_adc_domain_ops = {
>>>> + .map = stm32_adc_domain_map,
>>>> + .unmap = stm32_adc_domain_unmap,
>>>> + .xlate = irq_domain_xlate_onecell,
>>>> +};
>>>> +
>>>> +static int stm32_adc_irq_probe(struct platform_device *pdev,
>>>> + struct stm32_adc_priv *priv)
>>>> +{
>>>> + struct device_node *np = pdev->dev.of_node;
>>>> +
>>>> + priv->irq = platform_get_irq(pdev, 0);
>>>> + if (priv->irq < 0) {
>>>> + dev_err(&pdev->dev, "failed to get irq\n");
>>>> + return priv->irq;
>>>> + }
>>>> +
>>>> + priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
>>>> + &stm32_adc_domain_ops,
>>>> + priv);
>>>> + if (!priv->domain) {
>>>> + dev_err(&pdev->dev, "Failed to add irq domain\n");
>>>> + return -ENOMEM;
>>>> + }
>>>> +
>>>> + irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
>>>> + irq_set_handler_data(priv->irq, priv);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void stm32_adc_irq_remove(struct platform_device *pdev,
>>>> + struct stm32_adc_priv *priv)
>>>> +{
>>>> + int hwirq;
>>>> +
>>>> + for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
>>>> + irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
>>>> + irq_domain_remove(priv->domain);
>>>> + irq_set_chained_handler(priv->irq, NULL);
>>>> +}
>>>> +
>>>> +static int stm32_adc_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct stm32_adc_priv *priv;
>>>> + struct device_node *np = pdev->dev.of_node;
>>>> + struct resource *res;
>>>> + int ret;
>>>> +
>>>> + if (!pdev->dev.of_node)
>>>> + return -ENODEV;
>>>> +
>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>>> + if (!priv)
>>>> + return -ENOMEM;
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + priv->common.base = devm_ioremap_resource(&pdev->dev, res);
>>>> + if (IS_ERR(priv->common.base))
>>>> + return PTR_ERR(priv->common.base);
>>>> +
>>>> + priv->vref = devm_regulator_get(&pdev->dev, "vref");
>>>> + if (IS_ERR(priv->vref)) {
>>>> + ret = PTR_ERR(priv->vref);
>>>> + dev_err(&pdev->dev, "vref get failed, %d\n", ret);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = regulator_enable(priv->vref);
>>>> + if (ret < 0) {
>>>> + dev_err(&pdev->dev, "vref enable failed\n");
>>>> + return ret;
>>>> + }
>>>> +
>>>> + ret = regulator_get_voltage(priv->vref);
>>>> + if (ret < 0) {
>>>> + dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
>>>> + goto err_regulator_disable;
>>>> + }
>>>> + priv->common.vref_mv = ret / 1000;
>>>> + dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
>>>> +
>>>> + priv->aclk = devm_clk_get(&pdev->dev, "adc");
>>>> + if (IS_ERR(priv->aclk)) {
>>>> + ret = PTR_ERR(priv->aclk);
>>>> + dev_err(&pdev->dev, "Can't get 'adc' clock\n");
>>>> + goto err_regulator_disable;
>>>> + }
>>>> +
>>>> + ret = clk_prepare_enable(priv->aclk);
>>>> + if (ret < 0) {
>>>> + dev_err(&pdev->dev, "adc clk enable failed\n");
>>>> + goto err_regulator_disable;
>>>> + }
>>>> +
>>>> + ret = stm32f4_adc_clk_sel(pdev, priv);
>>>> + if (ret < 0) {
>>>> + dev_err(&pdev->dev, "adc clk selection failed\n");
>>>> + goto err_clk_disable;
>>>> + }
>>>> +
>>>> + ret = stm32_adc_irq_probe(pdev, priv);
>>>> + if (ret < 0)
>>>> + goto err_clk_disable;
>>>> +
>>>> + platform_set_drvdata(pdev, &priv->common);
>>>> +
>>>> + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>>>> + if (ret < 0) {
>>>> + dev_err(&pdev->dev, "failed to populate DT children\n");
>>>> + goto err_irq_remove;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +
>>>> +err_irq_remove:
>>>> + stm32_adc_irq_remove(pdev, priv);
>>>> +
>>>> +err_clk_disable:
>>>> + clk_disable_unprepare(priv->aclk);
>>>> +
>>>> +err_regulator_disable:
>>>> + regulator_disable(priv->vref);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int stm32_adc_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct stm32_adc_common *common = platform_get_drvdata(pdev);
>>>> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
>>>> +
>>>> + of_platform_depopulate(&pdev->dev);
>>>> + stm32_adc_irq_remove(pdev, priv);
>>>> + clk_disable_unprepare(priv->aclk);
>>>> + regulator_disable(priv->vref);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static const struct of_device_id stm32_adc_of_match[] = {
>>>> + { .compatible = "st,stm32f4-adc-core" },
>>>> + {},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
>>>> +
>>>> +static struct platform_driver stm32_adc_driver = {
>>>> + .probe = stm32_adc_probe,
>>>> + .remove = stm32_adc_remove,
>>>> + .driver = {
>>>> + .name = "stm32-adc-core",
>>>> + .of_match_table = stm32_adc_of_match,
>>>> + },
>>>> +};
>>>> +module_platform_driver(stm32_adc_driver);
>>>> +
>>>> +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>");
>>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC core driver");
>>>> +MODULE_LICENSE("GPL v2");
>>>> +MODULE_ALIAS("platform:stm32-adc-core");
>>>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>>>> new file mode 100644
>>>> index 0000000..081fa5f
>>>> --- /dev/null
>>>> +++ b/drivers/iio/adc/stm32-adc-core.h
>>>> @@ -0,0 +1,52 @@
>>>> +/*
>>>> + * This file is part of STM32 ADC driver
>>>> + *
>>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>>> + * Author: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>.
>>>> + *
>>>> + * License type: GPLv2
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify it
>>>> + * under the terms of the GNU General Public License version 2 as published by
>>>> + * the Free Software Foundation.
>>>> + *
>>>> + * 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.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License along with
>>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#ifndef __STM32_ADC_H
>>>> +#define __STM32_ADC_H
>>>> +
>>>> +/*
>>>> + * STM32 - ADC global register map
>>>> + * ________________________________________________________
>>>> + * | Offset | Register |
>>>> + * --------------------------------------------------------
>>>> + * | 0x000 | Master ADC1 |
>>>> + * --------------------------------------------------------
>>>> + * | 0x100 | Slave ADC2 |
>>>> + * --------------------------------------------------------
>>>> + * | 0x200 | Slave ADC3 |
>>>> + * --------------------------------------------------------
>>>> + * | 0x300 | Master & Slave common regs |
>>>> + * --------------------------------------------------------
>>>> + */
>>>> +#define STM32_ADC_MAX_ADCS 3
>>>> +#define STM32_ADCX_COMN_OFFSET 0x300
>>>> +
>>>> +/**
>>>> + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>>>> + * @base: control registers base cpu addr
>>>> + * @vref_mv: vref voltage (mv)
>>>> + */
>>>> +struct stm32_adc_common {
>>>> + void __iomem *base;
>>>> + int vref_mv;
>>>> +};
>>>> +
>>>> +#endif
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 mmc/next] mmc: sh_mmcif: Document r8a73a4, r8a7779 and sh73a0 DT bindings
From: Simon Horman @ 2016-11-25 7:56 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ulf Hansson, linux-mmc, devicetree, Magnus Damm,
linux-renesas-soc
In-Reply-To: <e0e1d92b-1b79-ec53-def0-25a080edc073@cogentembedded.com>
On Thu, Nov 24, 2016 at 09:50:38PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/24/2016 09:17 PM, Simon Horman wrote:
>
> >Simply document new compatibility strings as the driver is already
> >activated using a fallback compatibility string.
> >
> >These compat strings are in keeping with those for all other
> >Renesas ARM based SoCs with sh_mmcif enabled in mainline.
> >
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >---
> >I plan to follow-up with patches to use these new compat strings
> >to bring the DT files of the SoCs in question in-line with those
> >for other Renesas ARM based SoCs with sh_mmcif enabled in mainline.
> >---
> > Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >index ff611fa66871..e4ba92aa035e 100644
> >--- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >+++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> >@@ -8,11 +8,14 @@ Required properties:
> >
> > - compatible: should be "renesas,mmcif-<soctype>", "renesas,sh-mmcif" as a
> > fallback. Examples with <soctype> are:
> >+ - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
> > - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> >+ - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs
>
> 7779 in the subject, 7778 here.
Thanks, I have reposted with an updated subject.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox