* [PATCH v2 4/4] ARM: dts: sunxi: add support for Lichee Pi Zero board
From: Icenowy Zheng @ 2017-01-16 18:01 UTC (permalink / raw)
To: Jonathan Corbet, Maxime Ripard, Chen-Yu Tsai, Rob Herring, Zepan
Cc: linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170116180116.36729-2-icenowy-ymACFijhrKM@public.gmane.org>
Lichee Pi Zero is a small-sized V3s board, which is
breadboard-compatible, and with a MicroUSB port with both OTG function
and power function.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 73 +++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..3e099e9b1ad7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -853,7 +853,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-h3-orangepi-pc-plus.dtb \
sun8i-h3-orangepi-plus.dtb \
sun8i-h3-orangepi-plus2e.dtb \
- sun8i-r16-parrot.dtb
+ sun8i-r16-parrot.dtb \
+ sun8i-v3s-licheepi-zero.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
new file mode 100644
index 000000000000..0099affc6ce3
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -0,0 +1,73 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-v3s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+/ {
+ model = "Lichee Pi Zero";
+ compatible = "licheepi,licheepi-zero", "allwinner,sun8i-v3s";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&mmc0 {
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-names = "default";
+ broken-cd;
+ bus-width = <4>;
+ vmmc-supply = <®_vcc3v3>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pins_a>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
From: David Miller @ 2017-01-16 18:30 UTC (permalink / raw)
To: m-karicheri2-l0cyMroinI0
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0
In-Reply-To: <1484317954-27871-1-git-send-email-m-karicheri2-l0cyMroinI0@public.gmane.org>
From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Date: Fri, 13 Jan 2017 09:32:34 -0500
> Currently dp83867 driver returns error if phy interface type
> PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
> delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
> Fix this by checking also the interface type if a particular delay
> value is missing in the phy dt bindings. Also update the DT document
> accordingly.
>
> Signed-off-by: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Applied, thanks.
--
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 03/10] devicetree: bindings: add bindings for ahci-da850
From: David Lechner @ 2017-01-16 18:47 UTC (permalink / raw)
To: Bartosz Golaszewski, Sekhar Nori
Cc: Kevin Hilman, Patrick Titiano, Michael Turquette, Tejun Heo,
Rob Herring, Mark Rutland, Russell King, linux-ide,
linux-devicetree, LKML, arm-soc
In-Reply-To: <CAMpxmJW9ns-aG=4zYHcV5-2b_TdmJ7q+Ap1jdyoxstZjWYRL2A@mail.gmail.com>
On 01/16/2017 08:30 AM, Bartosz Golaszewski wrote:
> 2017-01-16 13:45 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> On Monday 16 January 2017 03:43 PM, Bartosz Golaszewski wrote:
>>> 2017-01-13 20:25 GMT+01:00 David Lechner <david@lechnology.com>:
>>>>
>>>> A clock multiplier property seems redundant if you are specifying a clock.
>>>> It should be possible to get the rate from the clock to determine which
>>>> multiplier is needed.
>>>>
>>>
>>> I probably should have named it differently. This is not a multiplier
>>> of a clock derived from PLL0 or PLL1. Instead it's a value set by
>>> writing to the Port PHY Control Register (MPY bits) of the SATA
>>> controller that configures the multiplier for the external low-jitter
>>> clock. On the lcdk the signals (REFCLKP, REFCLKN) are provided by
>>> CDCM61001 (SATA OSCILLATOR component on the schematics).
>>>
>>> I'll find a better name and comment the property accordingly.
>>>
>>> FYI: the da850 platform does not use the common clock framework, so I
>>> don't specify the clock property on the sata node in the device tree.
>>> Instead I add the clock lookup entry in patch [01/10]. This is
>>> transparent for AHCI which can get the clock as usual by calling
>>> clk_get() in ahci_platform_get_resources().
>>
>> I think David's point is that the SATA_REFCLK needs to be modeled as a
>> actual clock input to the IP. You should be able to get the rate using
>> clk_get_rate() and make the MPY bits calculation depending on the
>> incoming rate.
>>
>> You should be able to model the clock even when not using common clock
>> framework.
>>
>> DA850 AHCI does not use a con_id at the moment (it assumes a single
>> clock), and that needs to change.
>>
>
> It's true that once davinci gets ported (is this planned?) to using
> the common clock framework, we could just create a fixed-clock node in
> da850-lcdk for the SATA oscillator, so the new property is redundant.
>
I have some commits[1] where I started on converting da850 to use the
common clock framework. But, I don't know anything about other davinci
family devices, so I don't think I could really take that to completion
without lots of help.
[1]: https://github.com/dlech/ev3dev-kernel/commits/wip-20160509
> What I don't get is how should I model a clock that is not
> configurable and is board-specific? Is hard-coding the relevant rate
> in da850.c with a huge FIXME the right way?
In arch/arm/mach-davinci/usb-da8xx.c, there is a "usb_refclkin" that is
very similar to the situation with the sata refclk. You could do
something like this to register the clock...
---
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index c2457b3..790efce9 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -1023,6 +1023,34 @@ int __init da8xx_register_spi_bus(int instance,
unsigned num_chipselect)
}
#ifdef CONFIG_ARCH_DAVINCI_DA850
+
+static struct clk sata_refclkin = {
+ .name = "sata_refclkin",
+ .set_rate = davinci_simple_set_rate,
+};
+
+static struct clk_lookup sata_refclkin_lookup =
+ CLK(NULL, "sata_refclkin", &sata_refclkin);
+
+/**
+ * da8xx_register_sata_refclkin - register SATA_REFCLKIN clock
+ *
+ * @rate: The clock rate in Hz
+ */
+int __init da850_register_sata_refclkin(int rate)
+{
+ int ret;
+
+ sata_refclkin.rate = rate;
+ ret = clk_register(&sata_refclkin);
+ if (ret)
+ return ret;
+
+ clkdev_add(&sata_refclkin_lookup);
+
+ return 0;
+}
+
static struct resource da850_sata_resources[] = {
{
.start = DA850_SATA_BASE,
@@ -1055,8 +1083,11 @@ static struct platform_device da850_sata_device = {
int __init da850_register_sata(unsigned long refclkpn)
{
- /* please see comment in drivers/ata/ahci_da850.c */
- BUG_ON(refclkpn != 100 * 1000 * 1000);
+ int err;
+
+ err = da850_register_sata_refclkin(refclkpn);
+ if (err)
+ return err;
return platform_device_register(&da850_sata_device);
}
---
Then to get things working from device tree, add this...
---
diff --git a/arch/arm/mach-davinci/da8xx-dt.c
b/arch/arm/mach-davinci/da8xx-dt.c
index d2be194..b54bdd6 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -60,6 +60,14 @@ static void __init da850_init_machine(void)
pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
__func__, ret);
+ if (of_machine_is_compatible("ti,da850-evm") ||
+ of_machine_is_compatible("ti,da850-lcdk")) {
+ ret = da850_register_sata_refclkin(100000000);
+ if (ret)
+ pr_warn("%s: registering SATA_REFCLK clock
failed: %d",
+ __func__, ret);
+ }
+
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
pdata_quirks_init();
---
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Krzysztof Kozlowski @ 2017-01-16 18:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, Mark Rutland, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Heiko Stuebner, Matthias Brugger, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Linus Walleij, Alexandre Belloni,
Thomas Petazzoni, Boris Brezillon, Antoine Ténart
In-Reply-To: <20170116132424.7038-1-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> Allwinner, Amlogic, Mediatek or Rockchip.
>
> Add a binding for the GPU of that family.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>
Hi,
Do you have a driver in kernel which will implement these bindings?
Defining them for out-of-tree driver does not bring any benefits (3rd
party driver will not respect them anyway).
Best regards,
Krzysztof
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> new file mode 100644
> index 000000000000..df05ba0ec357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -0,0 +1,76 @@
> +ARM Mali Utgard GPU
> +===================
> +
> +Required properties:
> + - compatible:
> + * "arm,mali-utgard" and one of the following:
> + + "arm,mali-300"
> + + "arm,mali-400"
> + + "arm,mali-450"
> +
> + - reg: Physical base address and length of the GPU registers
> +
> + - interrupts: an entry for each entry in interrupt-names.
> + See ../interrupt-controller/interrupts.txt for details.
> +
> + - interrupt-names:
> + * ppX: Pixel Processor X interrupt (X from 0 to 7)
> + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
> + * pp: Pixel Processor broadcast interrupt (mali-450 only)
> + * gp: Geometry Processor interrupt
> + * gpmmu: Geometry Processor MMU interrupt
> +
> +
> +Optional properties:
> + - interrupt-names:
> + * pmu: Power Management Unit interrupt, if implemented in hardware
> +
> +Vendor-specific bindings
> +------------------------
> +
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accommodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> + - allwinner,sun4i-a10-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> + - allwinner,sun7i-a20-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> +Example:
> +
> +mali: gpu@01c40000 {
> + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400",
> + "arm,mali-utgard";
> + reg = <0x01c40000 0x10000>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp",
> + "gpmmu",
> + "pp0",
> + "ppmmu0",
> + "pp1",
> + "ppmmu1",
> + "pmu";
> + clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
> + clock-names = "bus", "core";
> + resets = <&ccu RST_BUS_GPU>;
> +};
> +
> +
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/4] Enable USB OTG on Allwinner H3 and two boards
From: Icenowy Zheng @ 2017-01-16 19:14 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
This patchset depends on the following patch (only the patch, as it adds the
MUSB controller used in H3, the patchset itself is for V3s):
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/476387.html
This patchset enables USB OTG ports on Orange Pi Zero and One board, using the
SoC's MUSB controller.
The mode of PHY0 is currently set to MUSB mode, as supporting EHCI/OHCI will
cost more time and code; but MUSB can supply both host and peripheral mode.
OTG function is only enabled for these two boards, as they're the only H3/H2+
boards that I have.
I think other boards' owners can easily enable their boards' OTG function with
these patches.
Icenowy Zheng (4):
phy: sun4i-usb: support PHY0 on H3 in MUSB mode
ARM: dts: sun8i: add MUSB node to H3 SoC
ARM: dts: sun8i: enable USB OTG for Orange Pi Zero board
ARM: dts: sun8i: enable USB OTG on Orange Pi One board
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 6 ++++++
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 12 +++++++++++
arch/arm/boot/dts/sun8i-h3.dtsi | 13 ++++++++++++
drivers/phy/phy-sun4i-usb.c | 25 ++++++++---------------
4 files changed, 40 insertions(+), 16 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Icenowy Zheng @ 2017-01-16 19:14 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170116191449.50397-1-icenowy-ymACFijhrKM@public.gmane.org>
The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
controller.
The original driver wired it to OHCI/EHCI controller; however, as the
code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
unusable.
Rename the register (according to its function and the name in BSP
driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
can support both peripheral and host mode (although the host mode of
MUSB is buggy).
The register that is renamed is now unused, as its initial value is just
MUSB mode. However, when OHCI/EHCI mode support is added, the register
can be used again.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
drivers/phy/phy-sun4i-usb.c | 25 +++++++++----------------
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bf28a0fdd569..6b193a635c6b 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -49,7 +49,7 @@
#define REG_PHYBIST 0x08
#define REG_PHYTUNE 0x0c
#define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTGCTL 0x20
#define REG_PMU_UNK1 0x10
@@ -269,23 +269,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
- if (data->cfg->type == sun8i_h3_phy) {
- if (phy->index == 0) {
- val = readl(data->base + REG_PHY_UNK_H3);
- writel(val & ~1, data->base + REG_PHY_UNK_H3);
- }
- } else {
- /* Enable USB 45 Ohm resistor calibration */
- if (phy->index == 0)
- sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+ /* Enable USB 45 Ohm resistor calibration */
+ if (phy->index == 0)
+ sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
- /* Adjust PHY's magnitude and rate */
- sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+ /* Adjust PHY's magnitude and rate */
+ sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
- /* Disconnect threshold adjustment */
- sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
- data->cfg->disc_thresh, 2);
- }
+ /* Disconnect threshold adjustment */
+ sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+ data->cfg->disc_thresh, 2);
sun4i_usb_phy_passby(phy, 1);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: sun8i: add MUSB node to H3 SoC
From: Icenowy Zheng @ 2017-01-16 19:14 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170116191449.50397-1-icenowy-ymACFijhrKM@public.gmane.org>
As we have already H3 PHY support code to MUSB mode fixed, and the H3
MUSB controller supported, we can now add the MUSB node to the DTSI file
of H3.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 08fd0860bb6b..60dd88c7fb9a 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -206,6 +206,19 @@
#size-cells = <0>;
};
+ usb_otg: usb@01c19000 {
+ compatible = "allwinner,sun8i-h3-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
usbphy: phy@01c19400 {
compatible = "allwinner,sun8i-h3-usb-phy";
reg = <0x01c19400 0x2c>,
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: sun8i: enable USB OTG for Orange Pi Zero board
From: Icenowy Zheng @ 2017-01-16 19:14 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170116191449.50397-1-icenowy-ymACFijhrKM@public.gmane.org>
Orange Pi Zero board features a USB OTG port, which has a ID pin, and
can be used to power up the borad. However, even if the board is powered
via +5V pin in GPIO/expansion headers, the VBUS in the OTG port cannot
be powered up, thus it's impossible to use it in host mode with simple
OTG cables.
Add support for it in peripheral mode.
If someone really want to use it in host mode, the dr_mode property of
&usb_otg can be changed into "otg", then a powered USB OTG cable or USB
HUB is needed for powering out the external USB devices.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index b7ca916d871d..437536e2b594 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -154,7 +154,13 @@
status = "disabled";
};
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
&usbphy {
/* USB VBUS is always on */
status = "okay";
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
};
--
2.11.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: sun8i: enable USB OTG on Orange Pi One board
From: Icenowy Zheng @ 2017-01-16 19:14 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170116191449.50397-1-icenowy-ymACFijhrKM@public.gmane.org>
Orange Pi One board features a USB OTG port, which cannot be used to
power up the board, but have a gateable VBUS and an ID pin, which makes
it possible to be used in both host and peripheral mode.
Enable its OTG port in dual-role mode.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 34da853ee037..8f69c8c9995c 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -115,6 +115,11 @@
};
};
+®_usb0_vbus {
+ gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+ status = "okay";
+};
+
&r_pio {
leds_r_opc: led_pins@0 {
pins = "PL10";
@@ -151,7 +156,14 @@
status = "disabled";
};
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
&usbphy {
/* USB VBUS is always on */
status = "okay";
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+ usb0_vbus-supply = <®_usb0_vbus>;
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes
From: Corentin Labbe @ 2017-01-16 19:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree, Ulf Hansson, Andre Przywara, linux-mmc, linux-kernel,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel
In-Reply-To: <ac77b9e25e7633886822cd1f1ebafd5985751ae4.1484585798.git-series.maxime.ripard@free-electrons.com>
On Mon, Jan 16, 2017 at 05:56:58PM +0100, Maxime Ripard wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The A64 has 3 MMC controllers, one of them being especially targeted to
> eMMC. Among other things, it has a data strobe signal and a 8 bits data
> width.
>
> The two other are more usual controllers that will have a 4 bits width at
> most and no data strobe signal, which limits it to more usual SD or MMC
> peripherals.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 ++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 99b6bb1e141c..143e9706438f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -299,6 +299,45 @@
> #size-cells = <0>;
> };
>
> + mmc0: mmc@1c0f000 {
> + compatible = "allwinner,sun50i-a64-mmc";
> + reg = <0x01c0f000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc1: mmc@1c10000 {
> + compatible = "allwinner,sun50i-a64-mmc";
> + reg = <0x01c10000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC1>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc2: mmc@1c11000 {
> + compatible = "allwinner,sun50i-a64-emmc";
> + reg = <0x01c11000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC2>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> gic: interrupt-controller@1c81000 {
> compatible = "arm,gic-400";
> reg = <0x01c81000 0x1000>,
Hello
It seems that mmc node is after i2c@1c2b400 so not in address order.
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-16 19:31 UTC (permalink / raw)
To: John Crispin, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3fecb422-8185-7ee0-c203-2bfdc4fd1393-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Am 10.01.2017 um 11:18 schrieb John Crispin:
> On 10/01/2017 10:48, Andreas Färber wrote:
>> Am 10.01.2017 um 08:00 schrieb John Crispin:
>>> On 08/01/2017 14:30, Andreas Färber wrote:
>>>>
>>>> Andreas Färber (4):
>>>> Documentation: devicetree: Add vendor prefix for AsiaRF
>>>> Documentation: devicetree: arm: mediatek: Add Geek Force board
>>>> ARM: dts: mt7623: Add Geek Force config
>>>> MAINTAINERS: Extend ARM/Mediatek SoC support section
>>>>
>>>
>>> Hi,
>>>
>>> i need to NAK this series. the asiarf board is nothing more than the
>>> official MTK EVB with AsiaRF written on it. this board is already
>>> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
>>> EVB dts file nstead of adding a duplicate and letting the original
> bitrot.
>>
>> Well, I disagree.
>
> reading the rest of the email you seem to be quite agro about this.
Please re-read your reply above and my comments and reconsider your
attitude when replying in the future. It's not about whether these
patches go in or not, it's about your wording. And that continues with
aggressively throwing around the term "agro" in two mails already. I
don't see anything aggressive or angry in my original cover letter that
would've prompted your reply and can only interpret that as your own
frustration with your mt7623 progress. Instead you should've taken the
time to explain a bit better what you really meant, then we could've
spared or shortened this lengthy discussion and have a v2 already.
>> First of all I'm not letting "the original" bitrot, because I have
>> nothing to do with that .dts! If anyone is to blame for letting it
>> bitrot since February 2016, pick your own nose:
>>
>>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
>
> what should i pick my nose about ?
Don't blame _me_ for "bitrot" of a file _you_ added almost a year ago
that did not see any updates since.
Nothing wrong with you not working on something, just don't blame me for
it then, especially when I don't (knowingly) have that hardware and have
never come in touch with it before. I am new to linux-mediatek and had
checked LAKML in vein for any mt7623 patches before sending mine.
[snip]
>> Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
>> files either because they were based on a Samsung SMDK, or .dts files
>> for Amlogic TV boxes because they're almost identical to reference
>> designs, etc.
>> Users need to know which .dts file to choose, so having a sane .dts
>> filename is warranted. Depending on how similar they are, one could
>> either #include the -evb.dts or factor out a shared .dtsi, but that
>> takes us back to the previous point of hardly anyone having access to
>> EVB information to identify such a subset. Therefore duplicating trivial
>> nodes is the method of choice for all practical purposes - mt7623.dtsi
>> is getting reused just fine.
>>
>
> in that case add a dtsi file for the EVB and include it in your geek
> board.dts and only update the compat string.
The question that I am not in a position to answer is: Are those two
boards identical or just very similar? Paul in CC can hopefully clarify
this when he is back. Matthias as maintainer has also remained silent.
>> Comparing our two .dts files, mine has two more UART nodes enabled, the
>> U-Boot bootloader's baudrate set to actually get serial output, a
>> different board compatible string for identification, and I chose the
>> new dual-licensing header that is being requested for new DT files.
>
> 1) at the time we adde this the uart support was not ready
> 2) the bootloader i am using is a custom built one hence the random baudrate
Well, did the _original_ bootloader use 115200? In that case we could
update -evb.dts with it, and you could still override it via console=
for your custom build.
Or maybe having source access you could even contribute to mainline
U-Boot, so we can all work on the same codebase? I read a BPi-R2 is
coming up with mt7623, so booting without appended .dtb and uImage will
come in handy for more people than just EVB owners and Geek Force
backers. I'd happily contribute to making bootefi command work.
> 3) you can just updae the license if you want to, no problem
OK, will gladly look into the feasibility.
>> For lack of schematics I figured out UART1 by testing - continuity tests
>> for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
>> I can't do that for a board I don't have access to.
>> UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
>
> you do have the EVB directly in front of you
>
>> Do you actually have access to a Geek Force board yourself, or what are
>> you basing your claims on? Mine looks different from the Indiegogo
>> picture and thus has different identification from that on
>> https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
>
> i dont need the geek board as i have the EVB and they are identical
> according to MTK
>
>> If you confirm the EVB's baudrate I can happily send that part your way.
>> I've seen 921600 on the Helio X20 96board for instance.
>
> see above
So... 4) add my UART nodes to your -evb.dts? Any nitpicks on the actual
patch 3/4?
>> Also, none of what you've said justifies NAK'ing patch 4/4, which
>> applies to any mt7* and arm64 .dts, including yours.
>
> agreed, i never even mentioned 4/4
You replied to the cover letter 0/4 "i need to NAK this series" - and
series includes all four patches. Therefore my frustration with your
hip-shot reply. If you haven't read the patch, don't NAK it!
In fact still no one replied to it at all, even now that you're aware of
its existence.
>> While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
>> network driver but no corresponding .dtsi node. Talk about bitrot...
>
> the idea is that we work together to make thins optimal. this is not a
> you or is right. this is about the FOSS peer review process. please dont
> be so agro.
See above, please reconsider your tone. Peer review is no excuse for
rude and destructive behavior towards contributors you don't know.
Had you looked at the lists and codebase you would know that I am not
new to FOSS.
And please stop writing "agro", it sounds like some pothead making a
peace sign; not helpful among professional software developers.
Taking the time to start your sentences with a capital letter would also
be a respectful gesture.
> to me it seems suboptimal to support 2 dts files for the same board.
If it is the identical board, then we are in violent agreement. I just
find all your replies to me offensive so far, I don't know you and thus
have no reason to trust your unsubstantiated claims about my board.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-16 19:34 UTC (permalink / raw)
To: John Crispin, linux-mediatek
Cc: Matthias Brugger, devicetree, linux-kernel, Paul Lai,
linux-arm-kernel
In-Reply-To: <0bd6567e-1c5b-0ff6-d044-57d25e1a40d2@phrozen.org>
Hi John,
Am 12.01.2017 um 09:23 schrieb John Crispin:
> had a look last night why the ethernet dtsi was not added and it
> obviously was not added as we were waiting for the clk-mt2701 to be
> merged. the ethernet dtsi will have phandles pointing at the clk nodes
> which did not exist at the time. same is true for the PWM code.
>
> i sat down last night and worked out what pending patches i still have
> for mt7623 and out of the ~80 required to get v4.4 working i only need
> around 10 for v4.10-rc1.
>
> i started to rebase these patches last night and will have time to test
> them tomorrow or early next week. as the pwrap node alone is around 200
> lines of devicetree we need to figure out a way to add this to the dts
> files without duplicating it. i'll try to post a series early next week
> that we can then discuss and rebase your geekboard patches on.
Sounds like a plan. Many thanks!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mtd: spi-nor: add dt support for Everspin MRAMs
From: Uwe Kleine-König @ 2017-01-16 19:41 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, Geert Uytterhoeven, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACna6ryLDwr0S=e-uUt+ZGcY8mNDnUtBPg_RmqtSVBziJkZd5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 16, 2017 at 02:55:01PM +0100, Rafał Miłecki wrote:
> On 16 January 2017 at 14:35, Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > The MR25 family doesn't support JEDEC, so they need explicit mentioning
> > in the list of supported spi IDs. This makes it possible to add these
> > using for example:
> >
> > compatible = "everspin,mr25h40";
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > Hello,
> >
> > independent of the decision if -nonjedec is ok for m25p, this is needed
> > to make Everspin's MRAMs work.
> >
> > Best regards
> > Uwe
> >
> > drivers/mtd/devices/m25p80.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
> > {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> > {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> >
> > + /* Everspin MRAMs without JEDEC support */
> > + { "mr25h256" }, /* 256 kib, 40 MHz */
>
> A trivial thing: I think it should be Kib
> https://en.wikipedia.org/wiki/Binary_prefix
Oh, really? 10^3 = k and 2^10 = Ki, stange. Should I resend for that?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Christopher Spinrath @ 2017-01-16 20:12 UTC (permalink / raw)
To: Shawn Guo, p.zabel
Cc: mark.rutland, devicetree, linux, robh+dt, grinberg, kernel,
fabio.estevam, linux-arm-kernel
In-Reply-To: <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
Hi Philipp,
ping? It would be very nice if you comment on this patch before it's too
late for v4.11 (which is soon, I think).
Cheers,
Christopher
On 12/30/2016 03:27 PM, Shawn Guo wrote:
> On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath@rwth-aachen.de wrote:
>> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>>
>> Apart from the already enabled Designware HDMI port, the Utilite Pro
>> has a second display pipeline which has the following shape:
>>
>> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
>> --> HDMI connector.
>> Enable support for it.
>>
>> In addition, since this pipeline is hardwired to IPU1, sever the link
>> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
>> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
>> possible to drive both displays at high resolution due to the bandwidth
>> limitations of a single IPU.
>>
>> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> @Philipp, can you help review the changes?
>
>> ---
>>
>> Hi all,
>>
>> the removal of the link between IPU1 and the Designware HDMI encoder is the
>> result of a discussion I had with Philipp Zabel:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>>
>> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
>> approach has at least one disadvantage: if the resolution is low enough such
>> that a single IPU can handle both displays then muxing both displays to IPU1
>> would reduce the power consumption.
>>
>> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
>> solution since I'm not aware of any OS/driver that is capable of switching IPUs
>> or can handle the bandwidth limitation in a sane way. In particular, Linux is
>> unusable when both displays are supposed to be driven at high resolution and
>> both muxing options for the DW HDMI are available (this is not a userspace
>> issue; the system becomes almost unresponsive as soon as the kernel sets the
>> initial resolution).
>>
>> Cheers,
>> Christopher
>>
>> P.S.: this patch depends on the tfp410 bridge driver which has recently been
>> merged into drm-next.
>
> v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
>>
>> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> index 2200994..69bdd82 100644
>> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> @@ -59,6 +59,33 @@
>> rtc1 = &snvs_rtc;
>> };
>>
>> + encoder {
>> + compatible = "ti,tfp410";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint {
>> + remote-endpoint = <¶llel_display_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint {
>> + remote-endpoint = <&hdmi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>> pinctrl-names = "default";
>> @@ -72,6 +99,19 @@
>> };
>> };
>>
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> +
>
> The newline is unnecessary.
>
>> + type = "a";
>> + ddc-i2c-bus = <&i2c_dvi_ddc>;
>> +
>> + port {
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> + };
>> +
>> i2cmux {
>> compatible = "i2c-mux-gpio";
>> pinctrl-names = "default";
>> @@ -105,8 +145,46 @@
>> #size-cells = <0>;
>> };
>> };
>> +
>> + parallel-display {
>> + compatible = "fsl,imx-parallel-display";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ipu1>;
>> +
>
> Ditto
>
> I can fix them up if I get a Reviewed-by tag from Philipp on this
> version.
>
> Shawn
>
>> + interface-pix-fmt = "rgb24";
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + parallel_display_in: endpoint {
>> + remote-endpoint = <&ipu1_di0_disp0>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + parallel_display_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + };
>> + };
>> + };
>> };
>>
>> +/*
>> + * A single IPU is not able to drive both display interfaces available on the
>> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
>> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
>> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
>> + * IPU2 instead of IPU1.
>> + */
>> +/delete-node/&ipu1_di0_hdmi;
>> +/delete-node/&hdmi_mux_0;
>> +/delete-node/&ipu1_di1_hdmi;
>> +/delete-node/&hdmi_mux_1;
>> +
>> &hdmi {
>> ddc-i2c-bus = <&i2c2>;
>> status = "okay";
>> @@ -151,6 +229,39 @@
>> >;
>> };
>>
>> + pinctrl_ipu1: ipu1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
>> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
>> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
>> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
>> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
>> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
>> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
>> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
>> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
>> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
>> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
>> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
>> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
>> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
>> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
>> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
>> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
>> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
>> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
>> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
>> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
>> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
>> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
>> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
>> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
>> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
>> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
>> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
>> + >;
>> + };
>> +
>> pinctrl_uart2: uart2grp {
>> fsl,pins = <
>> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
>> @@ -194,6 +305,10 @@
>> };
>> };
>>
>> +&ipu1_di0_disp0 {
>> + remote-endpoint = <¶llel_display_in>;
>> +};
>> +
>> &pcie {
>> pcie@0,0 {
>> reg = <0x000000 0 0 0 0>;
>> --
>> 2.10.2
>>
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Laurent Pinchart @ 2017-01-16 20:30 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Alexandre TORGUE, Arnd Bergmann,
Russell King, Rob Herring, Philippe Cornu, Yannick Fertre,
Maxime Coquelin, Mickael Reulier, Gabriel FERNANDEZ,
linux-arm-kernel, kernel
In-Reply-To: <1484573344-11609-2-git-send-email-yannick.fertre@st.com>
Hi Yannick,
Thank you for the patch.
On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
> .../devicetree/bindings/display/st,ltdc.txt | 57 ++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
>
> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
> 100644
> index 0000000..20e89da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> @@ -0,0 +1,57 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- st-display-subsystem: Master device for DRM sub-components
> + This device must be the parent of all the sub-components and is
> responsible
> + of bind them.
Why do you need this ? At a quick glance the ltdc node should be enough.
> + Required properties:
> + - compatible: "st,display-subsystem"
> + - ranges: to allow probing of subdevices
> +
> +- ltdc_host: lcd-tft display controller host
> + must be a sub-node of st-display-subsystem
> + Required properties:
> + - compatible: "st,ltdc"
> + - reg: Physical base address of the IP registers and length of memory
> mapped region.
> + - clocks: from common clock binding: handle hardware IP needed clocks,
> the
> + number of clocks may depend of the SoC type.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: names of the clocks listed in clocks property in the same
> + order.
You need to define the required/optional clocks with their names here. If they
vary depending on the SoC, the DT bindings document need to list them for each
SoC.
> + - resets: resets to be used by the device
> + See ../reset/reset.txt for details.
> + - reset-names: names of the resets listed in resets property in the same
> + order.
> + Required nodes:
> + - Video port for RGB output.
> +
> +Example:
> +
> +/ {
> + ...
> + soc {
> + ...
> + st-display-subsystem {
> + compatible = "st,display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + dma-ranges;
> +
> + ltdc_host: stm32-ltdc@40016800 {
> + compatible = "st,ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = <&rcc 314>;
> + clocks = <&rcc 1 8>;
> + clock-names = "clk-lcd";
> + status = "disabled";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> + ...
> + };
> +};
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 1/2] of: fix of_device_get_modalias returned length when truncating buffers
From: Rob Herring @ 2017-01-16 20:41 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Frank Rowand
If the length of the modalias is greater than the buffer size, then the
modalias is truncated. However the untruncated length is returned which
will cause an error. Fix this to return the truncated length. If an error
in the case was desired, then then we should just return -ENOMEM.
The reality is no device will ever have 4KB of compatible strings to hit
this case.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/of/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad7c403..bd620452f255 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -223,7 +223,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
str[i] = '_';
}
- return tsize;
+ return repend;
}
/**
--
2.10.1
--
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 2/2] of: Add function for generating a DT modalias with a newline
From: Rob Herring @ 2017-01-16 20:41 UTC (permalink / raw)
To: devicetree, linux-kernel, Frank Rowand
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <20170116204122.5858-1-robh@kernel.org>
The modalias sysfs attr is lacking a newline for DT aliases on platform
devices. The macio and ibmebus correctly add the newline, but open code it.
Introduce a new function, of_device_modalias(), that fills the buffer with
the modalias including the newline and update users of the old
of_device_get_modalias function.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/pseries/ibmebus.c | 5 +----
drivers/base/platform.c | 2 +-
drivers/macintosh/macio_sysfs.c | 7 +------
drivers/of/device.c | 16 +++++++++++++++-
include/linux/of_device.h | 7 +++----
5 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c b/arch/powerpc/platforms/pseries/ibmebus.c
index 614c28537141..18f5a7a2896f 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -410,10 +410,7 @@ static ssize_t name_show(struct device *dev,
static ssize_t modalias_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- ssize_t len = of_device_get_modalias(dev, buf, PAGE_SIZE - 2);
- buf[len] = '\n';
- buf[len+1] = 0;
- return len+1;
+ return of_device_modalias(dev, buf, PAGE_SIZE);
}
static struct device_attribute ibmebus_bus_device_attrs[] = {
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c4af00385502..d92f60d7f15d 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -837,7 +837,7 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *a,
struct platform_device *pdev = to_platform_device(dev);
int len;
- len = of_device_get_modalias(dev, buf, PAGE_SIZE -1);
+ len = of_device_modalias(dev, buf, PAGE_SIZE);
if (len != -ENODEV)
return len;
diff --git a/drivers/macintosh/macio_sysfs.c b/drivers/macintosh/macio_sysfs.c
index 8eb40afbd0f5..0b1f9c76c68d 100644
--- a/drivers/macintosh/macio_sysfs.c
+++ b/drivers/macintosh/macio_sysfs.c
@@ -41,12 +41,7 @@ compatible_show (struct device *dev, struct device_attribute *attr, char *buf)
static ssize_t modalias_show (struct device *dev, struct device_attribute *attr,
char *buf)
{
- int len = of_device_get_modalias(dev, buf, PAGE_SIZE - 2);
-
- buf[len] = '\n';
- buf[len+1] = 0;
-
- return len+1;
+ return of_device_modalias(dev, buf, PAGE_SIZE);
}
static ssize_t devspec_show(struct device *dev,
diff --git a/drivers/of/device.c b/drivers/of/device.c
index bd620452f255..f3c3108d5a3a 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -176,7 +176,7 @@ const void *of_device_get_match_data(const struct device *dev)
}
EXPORT_SYMBOL(of_device_get_match_data);
-ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
+static ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
{
const char *compat;
int cplen, i;
@@ -227,6 +227,20 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
}
/**
+ * of_device_modalias - Fill buffer with newline terminated modalias string
+ */
+ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
+{
+ ssize_t sl = of_device_get_modalias(dev, str, len - 2);
+ if (sl < 0)
+ return sl;
+
+ str[sl++] = '\n';
+ str[sl] = 0;
+ return sl;
+}
+
+/**
* of_device_uevent - Display OF related uevent information
*/
void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687a89d..971d7250a8a4 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -35,8 +35,7 @@ extern void of_device_unregister(struct platform_device *ofdev);
extern const void *of_device_get_match_data(const struct device *dev);
-extern ssize_t of_device_get_modalias(struct device *dev,
- char *str, ssize_t len);
+extern ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len);
extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env);
@@ -72,8 +71,8 @@ static inline const void *of_device_get_match_data(const struct device *dev)
return NULL;
}
-static inline int of_device_get_modalias(struct device *dev,
- char *str, ssize_t len)
+static inline int of_device_modalias(struct device *dev,
+ char *str, ssize_t len)
{
return -ENODEV;
}
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rafał Miłecki @ 2017-01-16 20:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, Geert Uytterhoeven, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170116194154.v2p2gbyvvfb5bwe6-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 16 January 2017 at 20:41, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> On Mon, Jan 16, 2017 at 02:55:01PM +0100, Rafał Miłecki wrote:
>> On 16 January 2017 at 14:35, Uwe Kleine-König
>> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> > The MR25 family doesn't support JEDEC, so they need explicit mentioning
>> > in the list of supported spi IDs. This makes it possible to add these
>> > using for example:
>> >
>> > compatible = "everspin,mr25h40";
>> >
>> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> > ---
>> > Hello,
>> >
>> > independent of the decision if -nonjedec is ok for m25p, this is needed
>> > to make Everspin's MRAMs work.
>> >
>> > Best regards
>> > Uwe
>> >
>> > drivers/mtd/devices/m25p80.c | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> > --- a/drivers/mtd/devices/m25p80.c
>> > +++ b/drivers/mtd/devices/m25p80.c
>> > @@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
>> > {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
>> > {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
>> >
>> > + /* Everspin MRAMs without JEDEC support */
>> > + { "mr25h256" }, /* 256 kib, 40 MHz */
>>
>> A trivial thing: I think it should be Kib
>> https://en.wikipedia.org/wiki/Binary_prefix
>
> Oh, really? 10^3 = k and 2^10 = Ki, stange. Should I resend for that?
I don't think I understand you now. This is 262'144b device. You most
likely want to divide it by 1024 and use Kib then, right?
So it should be just 256 Kib instead of 256 kib.
--
Rafał
--
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 0/6] ARM: dts: am335x-sl50: Update to new hardware
From: Enric Balletbo Serra @ 2017-01-16 20:53 UTC (permalink / raw)
To: Tony Lindgren
Cc: Enric Balletbo i Serra, Rob Herring, Russell King,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel
In-Reply-To: <20170116174149.GE7403-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hi Tony,
2017-01-16 18:41 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> * Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> [170116 08:58]:
>> Hi Tony,
>>
>> The following patches updates the device tree file for the SL50 device, there
>> are few v1 boards and IMHO doesn't make sense to maintain the device tree
>> for these old devices, so mostly of the updates are related to changes done in
>> the next hardware revision v2 (the one that will go out).
>
> This is only if the v1 boards are company internal and can be easily
> replaced. As long as that's the case I'm fine with that.
>
Yes thats the case, I don't expect see v1 board outside.
Regards,
Enric
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH v2] mtd: spi-nor: add dt support for Everspin MRAMs
From: Uwe Kleine-König @ 2017-01-16 21:00 UTC (permalink / raw)
To: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen
Cc: Mark Rutland, devicetree, Rafał Miłecki,
Geert Uytterhoeven, kernel, linux-mtd
In-Reply-To: <CACna6ryLDwr0S=e-uUt+ZGcY8mNDnUtBPg_RmqtSVBziJkZd5w@mail.gmail.com>
The MR25 family doesn't support JEDEC, so they need explicit mentioning
in the list of supported spi IDs. This makes it possible to add these
using for example:
compatible = "everspin,mr25h40";
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Changes since (implicit) v1:
- use Kib instead of kib
drivers/mtd/devices/m25p80.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 9cf7fcd28034..aa50bd96de3a 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
{"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
{"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
+ /* Everspin MRAMs */
+ { "mr25h256" }, /* 256 Kib, 40 MHz */
+ { "mr25h10" }, /* 1 Mib, 40 MHz */
+ { "mr25h40" }, /* 4 Mib, 40 MHz */
+
{ },
};
MODULE_DEVICE_TABLE(spi, m25p_ids);
--
2.11.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* Re: [PATCH v2] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rafał Miłecki @ 2017-01-16 21:02 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Marek Vasut, Mark Rutland, devicetree@vger.kernel.org,
Masahiko Iwamoto, linux-mtd@lists.infradead.org, Sascha Hauer,
Geert Uytterhoeven, Cyrille Pitchen, Jagan Teki
In-Reply-To: <20170116210039.25267-1-u.kleine-koenig@pengutronix.de>
On 16 January 2017 at 22:00, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> in the list of supported spi IDs. This makes it possible to add these
> using for example:
>
> compatible = "everspin,mr25h40";
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Looks OK to me, thanks!
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH linux v3 0/6] drivers: hwmon: Add On-Chip Controller driver
From: eajames.ibm @ 2017-01-16 21:13 UTC (permalink / raw)
To: linux
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
corbet, mark.rutland, robh+dt, wsa, andrew, joel, benh,
Edward A. James
From: "Edward A. James" <eajames@us.ibm.com>
This patchset adds a hwmon driver to support the OCC (On-Chip Controller)
on the IBM POWER8 and POWER9 processors, from a BMC (Baseboard Management
Controller). The OCC is an embedded processor that provides real time
power and thermal monitoring.
The driver provides an interface on a BMC to poll OCC sensor data, set
user power caps, and perform some basic OCC error handling. It interfaces
with userspace through hwmon.
The driver is currently functional only for the OCC on POWER8 chips.
Communicating with the POWER9 OCC requries FSI support.
Edward A. James (6):
hwmon: Add core On-Chip Controller support for POWER CPUs
hwmon: occ: Add sysfs interface
hwmon: occ: Add I2C transport implementation for SCOM operations
hwmon: occ: Add callbacks for parsing P8 OCC datastructures
hwmon: occ: Add hwmon implementation for the P8 OCC
hwmon: occ: Add callbacks for parsing P9 OCC datastructures
Documentation/devicetree/bindings/hwmon/occ.txt | 13 +
Documentation/hwmon/occ | 114 ++++++
MAINTAINERS | 7 +
drivers/hwmon/Kconfig | 2 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/occ/Kconfig | 29 ++
drivers/hwmon/occ/Makefile | 2 +
drivers/hwmon/occ/occ.c | 522 ++++++++++++++++++++++++
drivers/hwmon/occ/occ.h | 81 ++++
drivers/hwmon/occ/occ_p8.c | 247 +++++++++++
drivers/hwmon/occ/occ_p8.h | 30 ++
drivers/hwmon/occ/occ_p9.c | 308 ++++++++++++++
drivers/hwmon/occ/occ_p9.h | 30 ++
drivers/hwmon/occ/occ_scom_i2c.c | 72 ++++
drivers/hwmon/occ/occ_scom_i2c.h | 26 ++
drivers/hwmon/occ/occ_sysfs.c | 271 ++++++++++++
drivers/hwmon/occ/occ_sysfs.h | 44 ++
drivers/hwmon/occ/p8_occ_i2c.c | 104 +++++
drivers/hwmon/occ/scom.h | 47 +++
19 files changed, 1950 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
create mode 100644 Documentation/hwmon/occ
create mode 100644 drivers/hwmon/occ/Kconfig
create mode 100644 drivers/hwmon/occ/Makefile
create mode 100644 drivers/hwmon/occ/occ.c
create mode 100644 drivers/hwmon/occ/occ.h
create mode 100644 drivers/hwmon/occ/occ_p8.c
create mode 100644 drivers/hwmon/occ/occ_p8.h
create mode 100644 drivers/hwmon/occ/occ_p9.c
create mode 100644 drivers/hwmon/occ/occ_p9.h
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
create mode 100644 drivers/hwmon/occ/occ_sysfs.c
create mode 100644 drivers/hwmon/occ/occ_sysfs.h
create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
create mode 100644 drivers/hwmon/occ/scom.h
--
1.9.1
^ permalink raw reply
* [PATCH linux v3 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs
From: eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-16 21:13 UTC (permalink / raw)
To: linux-0h96xk9xTtrk1uMJSBkQmQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, jdelvare-IBi9RG/b67k,
corbet-T1hC0tSOHrs, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, wsa-z923LK4zBo2bacvFa/9K2g,
andrew-zrmu5oMJ5Fs, joel-U3u1mxZcP9KHXe+LvDLADg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Edward A. James
In-Reply-To: <1484601219-30196-1-git-send-email-eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: "Edward A. James" <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Add core support for polling the OCC for it's sensor data and parsing that
data into sensor-specific information.
Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
---
Documentation/hwmon/occ | 40 ++++
MAINTAINERS | 7 +
drivers/hwmon/Kconfig | 2 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/occ/Kconfig | 15 ++
drivers/hwmon/occ/Makefile | 1 +
drivers/hwmon/occ/occ.c | 522 +++++++++++++++++++++++++++++++++++++++++++++
drivers/hwmon/occ/occ.h | 81 +++++++
drivers/hwmon/occ/scom.h | 47 ++++
9 files changed, 716 insertions(+)
create mode 100644 Documentation/hwmon/occ
create mode 100644 drivers/hwmon/occ/Kconfig
create mode 100644 drivers/hwmon/occ/Makefile
create mode 100644 drivers/hwmon/occ/occ.c
create mode 100644 drivers/hwmon/occ/occ.h
create mode 100644 drivers/hwmon/occ/scom.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
new file mode 100644
index 0000000..79d1642
--- /dev/null
+++ b/Documentation/hwmon/occ
@@ -0,0 +1,40 @@
+Kernel driver occ
+=================
+
+Supported chips:
+ * ASPEED AST2400
+ * ASPEED AST2500
+
+Please note that the chip must be connected to a POWER8 or POWER9 processor
+(see the BMC - Host Communications section).
+
+Author: Eddie James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
+
+Description
+-----------
+
+This driver implements support for the OCC (On-Chip Controller) on the IBM
+POWER8 and POWER9 processors, from a BMC (Baseboard Management Controller). The
+OCC is an embedded processor that provides real time power and thermal
+monitoring.
+
+This driver provides an interface on a BMC to poll OCC sensor data, set user
+power caps, and perform some basic OCC error handling.
+
+Currently, all versions of the OCC support four types of sensor data: power,
+temperature, frequency, and "caps," which indicate limits and thresholds used
+internally on the OCC.
+
+BMC - Host Communications
+-------------------------
+
+For the POWER8 application, the BMC can communicate with the P8 over I2C bus.
+However, to access the OCC register space, any data transfer must use a SCOM
+operation. SCOM is a procedure to initiate a data transfer, typically of 8
+bytes. SCOMs consist of writing a 32-bit command register and then
+reading/writing two 32-bit data registers. This driver implements these
+SCOM operations over I2C bus in order to communicate with the OCC.
+
+For the POWER9 application, the BMC can communicate with the P9 over FSI bus
+and SBE engine. Once again, SCOM operations are required. This driver will
+implement SCOM ops over FSI/SBE. This will require the FSI driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f0420a..f5d4195 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9112,6 +9112,13 @@ T: git git://linuxtv.org/media_tree.git
S: Maintained
F: drivers/media/i2c/ov7670.c
+ON-CHIP CONTROLLER HWMON DRIVER
+M: Eddie James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
+L: linux-hwmon-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+S: Maintained
+F: Documentation/hwmon/occ
+F: drivers/hwmon/occ/
+
ONENAND FLASH DRIVER
M: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
L: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 190d270..e80ca81 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1240,6 +1240,8 @@ config SENSORS_NSA320
This driver can also be built as a module. If so, the module
will be called nsa320-hwmon.
+source drivers/hwmon/occ/Kconfig
+
config SENSORS_PCF8591
tristate "Philips PCF8591 ADC/DAC"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2cb7e8..c7ec5d4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_SENSORS_WM831X) += wm831x-hwmon.o
obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o
obj-$(CONFIG_SENSORS_XGENE) += xgene-hwmon.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ/
obj-$(CONFIG_PMBUS) += pmbus/
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
new file mode 100644
index 0000000..cdb64a7
--- /dev/null
+++ b/drivers/hwmon/occ/Kconfig
@@ -0,0 +1,15 @@
+#
+# On Chip Controller configuration
+#
+
+menuconfig SENSORS_PPC_OCC
+ bool "PPC On-Chip Controller"
+ help
+ If you say yes here you get support to monitor Power CPU
+ sensors via the On-Chip Controller (OCC).
+
+ Generally this is used by management controllers such as a BMC
+ on an OpenPower system.
+
+ This driver can also be built as a module. If so, the module
+ will be called occ.
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
new file mode 100644
index 0000000..93cb52f
--- /dev/null
+++ b/drivers/hwmon/occ/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
diff --git a/drivers/hwmon/occ/occ.c b/drivers/hwmon/occ/occ.c
new file mode 100644
index 0000000..3089762
--- /dev/null
+++ b/drivers/hwmon/occ/occ.c
@@ -0,0 +1,522 @@
+/*
+ * occ.c - OCC hwmon driver
+ *
+ * This file contains the methods and data structures for the OCC hwmon driver.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/unaligned.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include "occ.h"
+
+#define OCC_DATA_MAX 4096
+#define OCC_BMC_TIMEOUT_MS 20000
+
+/* To generate attn to OCC */
+#define ATTN_DATA 0x0006B035
+
+/* For BMC to read/write SRAM */
+#define OCB_ADDRESS 0x0006B070
+#define OCB_DATA 0x0006B075
+#define OCB_STATUS_CONTROL_AND 0x0006B072
+#define OCB_STATUS_CONTROL_OR 0x0006B073
+
+/* To init OCB */
+#define OCB_AND_INIT0 0xFBFFFFFF
+#define OCB_AND_INIT1 0xFFFFFFFF
+#define OCB_OR_INIT0 0x08000000
+#define OCB_OR_INIT1 0x00000000
+
+/* To generate attention on OCC */
+#define ATTN0 0x01010000
+#define ATTN1 0x00000000
+
+/* OCC return status */
+#define RESP_RETURN_CMD_IN_PRG 0xFF
+#define RESP_RETURN_SUCCESS 0
+#define RESP_RETURN_CMD_INVAL 0x11
+#define RESP_RETURN_CMD_LEN 0x12
+#define RESP_RETURN_DATA_INVAL 0x13
+#define RESP_RETURN_CHKSUM 0x14
+#define RESP_RETURN_OCC_ERR 0x15
+#define RESP_RETURN_STATE 0x16
+
+/* time interval to retry on "command in progress" return status */
+#define CMD_IN_PRG_INT_MS 100
+#define CMD_IN_PRG_RETRIES (OCC_BMC_TIMEOUT_MS / CMD_IN_PRG_INT_MS)
+
+/* OCC command definitions */
+#define OCC_POLL 0
+#define OCC_SET_USER_POWR_CAP 0x22
+
+/* OCC poll command data */
+#define OCC_POLL_STAT_SENSOR 0x10
+
+/* OCC response data offsets */
+#define RESP_RETURN_STATUS 2
+#define RESP_DATA_LENGTH 3
+#define RESP_HEADER_OFFSET 5
+#define SENSOR_STR_OFFSET 37
+#define SENSOR_BLOCK_NUM_OFFSET 43
+#define SENSOR_BLOCK_OFFSET 45
+
+/* occ_poll_header
+ * structure to match the raw occ poll response data
+ */
+struct occ_poll_header {
+ u8 status;
+ u8 ext_status;
+ u8 occs_present;
+ u8 config;
+ u8 occ_state;
+ u8 mode;
+ u8 ips_status;
+ u8 error_log_id;
+ u32 error_log_addr_start;
+ u16 error_log_length;
+ u8 reserved2;
+ u8 reserved3;
+ u8 occ_code_level[16];
+ u8 sensor_eye_catcher[6];
+ u8 sensor_block_num;
+ u8 sensor_data_version;
+} __attribute__((packed, aligned(4)));
+
+struct occ_response {
+ struct occ_poll_header header;
+ struct occ_blocks data;
+};
+
+struct occ {
+ struct device *dev;
+ void *bus;
+ struct occ_bus_ops bus_ops;
+ struct occ_ops ops;
+ struct occ_config config;
+ unsigned long update_interval;
+ unsigned long last_updated;
+ struct mutex update_lock;
+ struct occ_response response;
+ bool valid;
+};
+
+static void deinit_occ_resp_buf(struct occ_response *resp)
+{
+ int i;
+
+ if (!resp)
+ return;
+
+ if (!resp->data.blocks)
+ return;
+
+ for (i = 0; i < resp->header.sensor_block_num; ++i)
+ kfree(resp->data.blocks[i].sensors);
+
+ kfree(resp->data.blocks);
+
+ memset(resp, 0, sizeof(struct occ_response));
+
+ for (i = 0; i < MAX_OCC_SENSOR_TYPE; ++i)
+ resp->data.sensor_block_id[i] = -1;
+}
+
+static void *occ_get_sensor_by_type(struct occ_response *resp,
+ enum sensor_type t)
+{
+ if (!resp->data.blocks)
+ return NULL;
+
+ if (resp->data.sensor_block_id[t] == -1)
+ return NULL;
+
+ return resp->data.blocks[resp->data.sensor_block_id[t]].sensors;
+}
+
+static int occ_check_sensor(struct occ *driver, u8 sensor_length,
+ u8 sensor_num, enum sensor_type t, int block)
+{
+ void *sensor;
+ int type_block_id;
+ struct occ_response *resp = &driver->response;
+
+ sensor = occ_get_sensor_by_type(resp, t);
+
+ /* empty sensor block, release older sensor data */
+ if (sensor_num == 0 || sensor_length == 0) {
+ kfree(sensor);
+ dev_err(driver->dev, "no sensor blocks available\n");
+ return -ENODATA;
+ }
+
+ type_block_id = resp->data.sensor_block_id[t];
+ if (!sensor || sensor_num !=
+ resp->data.blocks[type_block_id].header.sensor_num) {
+ kfree(sensor);
+ resp->data.blocks[block].sensors =
+ driver->ops.alloc_sensor(t, sensor_num);
+ if (!resp->data.blocks[block].sensors)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static int parse_occ_response(struct occ *driver, u8 *data,
+ struct occ_response *resp)
+{
+ int b;
+ int s;
+ int rc;
+ int offset = SENSOR_BLOCK_OFFSET;
+ int sensor_type;
+ u8 sensor_block_num;
+ char sensor_type_string[5] = { 0 };
+ struct sensor_data_block_header *block;
+ struct device *dev = driver->dev;
+
+ /* check if the data is valid */
+ if (strncmp(&data[SENSOR_STR_OFFSET], "SENSOR", 6) != 0) {
+ dev_err(dev, "no SENSOR string in response\n");
+ rc = -ENODATA;
+ goto err;
+ }
+
+ sensor_block_num = data[SENSOR_BLOCK_NUM_OFFSET];
+ if (sensor_block_num == 0) {
+ dev_err(dev, "no sensor blocks available\n");
+ rc = -ENODATA;
+ goto err;
+ }
+
+ /* if number of sensor block has changed, re-malloc */
+ if (sensor_block_num != resp->header.sensor_block_num) {
+ deinit_occ_resp_buf(resp);
+ resp->data.blocks = kcalloc(sensor_block_num,
+ sizeof(struct sensor_data_block),
+ GFP_KERNEL);
+ if (!resp->data.blocks)
+ return -ENOMEM;
+ }
+
+ memcpy(&resp->header, &data[RESP_HEADER_OFFSET],
+ sizeof(struct occ_poll_header));
+ resp->header.error_log_addr_start =
+ be32_to_cpu(resp->header.error_log_addr_start);
+ resp->header.error_log_length =
+ be16_to_cpu(resp->header.error_log_length);
+
+ dev_dbg(dev, "Reading %d sensor blocks\n",
+ resp->header.sensor_block_num);
+ for (b = 0; b < sensor_block_num; b++) {
+ block = (struct sensor_data_block_header *)&data[offset];
+ /* copy to a null terminated string */
+ strncpy(sensor_type_string, block->sensor_type, 4);
+ offset += 8;
+
+ dev_dbg(dev, "sensor block[%d]: type: %s, sensor_num: %d\n", b,
+ sensor_type_string, block->sensor_num);
+
+ if (strncmp(block->sensor_type, "FREQ", 4) == 0)
+ sensor_type = FREQ;
+ else if (strncmp(block->sensor_type, "TEMP", 4) == 0)
+ sensor_type = TEMP;
+ else if (strncmp(block->sensor_type, "POWR", 4) == 0)
+ sensor_type = POWER;
+ else if (strncmp(block->sensor_type, "CAPS", 4) == 0)
+ sensor_type = CAPS;
+ else {
+ dev_err(dev, "sensor type not supported %s\n",
+ sensor_type_string);
+ continue;
+ }
+
+ rc = occ_check_sensor(driver, block->sensor_length,
+ block->sensor_num, sensor_type, b);
+ if (rc == -ENOMEM)
+ goto err;
+ else if (rc)
+ continue;
+
+ resp->data.sensor_block_id[sensor_type] = b;
+ for (s = 0; s < block->sensor_num; s++) {
+ driver->ops.parse_sensor(data,
+ resp->data.blocks[b].sensors,
+ sensor_type, offset, s);
+ offset += block->sensor_length;
+ }
+
+ /* copy block data over to response pointer */
+ resp->data.blocks[b].header = *block;
+ }
+
+ return 0;
+err:
+ deinit_occ_resp_buf(resp);
+ return rc;
+}
+
+static u8 occ_send_cmd(struct occ *driver, u8 seq, u8 type, u16 length,
+ const u8 *data, u8 *resp)
+{
+ u32 cmd1, cmd2;
+ u16 checksum = 0;
+ u16 length_le = cpu_to_le16(length);
+ bool retry = 0;
+ int i, rc, tries = 0;
+
+ cmd1 = (seq << 24) | (type << 16) | length_le;
+ memcpy(&cmd2, data, length);
+ cmd2 <<= ((4 - length) * 8);
+
+ /* checksum: sum of every bytes of cmd1, cmd2 */
+ for (i = 0; i < 4; i++) {
+ checksum += (cmd1 >> (i * 8)) & 0xFF;
+ checksum += (cmd2 >> (i * 8)) & 0xFF;
+ }
+
+ cmd2 |= checksum << ((2 - length) * 8);
+
+ /* Init OCB */
+ rc = driver->bus_ops.putscom(driver->bus, OCB_STATUS_CONTROL_OR,
+ OCB_OR_INIT0, OCB_OR_INIT1);
+ if (rc)
+ goto err;
+
+ rc = driver->bus_ops.putscom(driver->bus, OCB_STATUS_CONTROL_AND,
+ OCB_AND_INIT0, OCB_AND_INIT1);
+ if (rc)
+ goto err;
+
+ /* Send command, 2nd half of the 64-bit addr is unused (write 0) */
+ rc = driver->bus_ops.putscom(driver->bus, OCB_ADDRESS,
+ driver->config.command_addr, 0);
+ if (rc)
+ goto err;
+
+ rc = driver->bus_ops.putscom(driver->bus, OCB_DATA, cmd1, cmd2);
+ if (rc)
+ goto err;
+
+ /* Trigger attention */
+ rc = driver->bus_ops.putscom(driver->bus, ATTN_DATA, ATTN0, ATTN1);
+ if (rc)
+ goto err;
+
+ /* Get response data */
+ rc = driver->bus_ops.putscom(driver->bus, OCB_ADDRESS,
+ driver->config.response_addr, 0);
+ if (rc)
+ goto err;
+
+ do {
+ if (retry) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(msecs_to_jiffies(CMD_IN_PRG_INT_MS));
+ }
+
+ rc = driver->bus_ops.getscom(driver->bus, OCB_DATA,
+ (u64 *)resp);
+ if (rc)
+ goto err;
+
+ /* retry if we get "command in progress" return status */
+ retry = (resp[RESP_RETURN_STATUS] == RESP_RETURN_CMD_IN_PRG) &&
+ (tries++ < CMD_IN_PRG_RETRIES);
+ } while (retry);
+
+ switch (resp[RESP_RETURN_STATUS]) {
+ case RESP_RETURN_CMD_IN_PRG:
+ rc = -EALREADY;
+ break;
+ case RESP_RETURN_SUCCESS:
+ rc = 0;
+ break;
+ case RESP_RETURN_CMD_INVAL:
+ case RESP_RETURN_CMD_LEN:
+ case RESP_RETURN_DATA_INVAL:
+ case RESP_RETURN_CHKSUM:
+ rc = -EINVAL;
+ break;
+ case RESP_RETURN_OCC_ERR:
+ rc = -EREMOTE;
+ break;
+ default:
+ rc = -EFAULT;
+ }
+
+ return rc;
+
+err:
+ dev_err(driver->dev, "scom op failed rc:%d\n", rc);
+ return rc;
+}
+
+static int occ_get_all(struct occ *driver)
+{
+ int i = 0, rc;
+ u8 *occ_data;
+ u16 num_bytes;
+ const u8 poll_cmd_data = OCC_POLL_STAT_SENSOR;
+ struct device *dev = driver->dev;
+ struct occ_response *resp = &driver->response;
+
+ occ_data = devm_kzalloc(dev, OCC_DATA_MAX, GFP_KERNEL);
+ if (!occ_data)
+ return -ENOMEM;
+
+ rc = occ_send_cmd(driver, 0, OCC_POLL, 1, &poll_cmd_data, occ_data);
+ if (rc) {
+ dev_err(dev, "OCC poll failed: %d\n", rc);
+ goto out;
+ }
+
+ num_bytes = get_unaligned((u16 *)&occ_data[RESP_DATA_LENGTH]);
+ num_bytes = be16_to_cpu(num_bytes);
+ dev_dbg(dev, "OCC data length: %d\n", num_bytes);
+
+ if (num_bytes > OCC_DATA_MAX) {
+ dev_err(dev, "OCC data length must be < 4KB\n");
+ rc = -EINVAL;
+ goto out;
+ }
+
+ if (num_bytes <= 0) {
+ dev_err(dev, "OCC data length is zero\n");
+ rc = -EINVAL;
+ goto out;
+ }
+
+ /* read remaining data */
+ for (i = 8; i < num_bytes + 8; i += 8) {
+ rc = driver->bus_ops.getscom(driver->bus, OCB_DATA,
+ (u64 *)&occ_data[i]);
+ if (rc) {
+ dev_err(dev, "scom op failed rc:%d\n", rc);
+ goto out;
+ }
+ }
+
+ /* don't need more sanity checks; buffer is alloc'd for max response
+ * size so we just check for valid data in parse_occ_response
+ */
+ rc = parse_occ_response(driver, occ_data, resp);
+
+out:
+ devm_kfree(dev, occ_data);
+ return rc;
+}
+
+int occ_update_device(struct occ *driver)
+{
+ int rc = 0;
+
+ mutex_lock(&driver->update_lock);
+
+ if (time_after(jiffies, driver->last_updated + driver->update_interval)
+ || !driver->valid) {
+ driver->valid = 1;
+
+ rc = occ_get_all(driver);
+ if (rc)
+ driver->valid = 0;
+
+ driver->last_updated = jiffies;
+ }
+
+ mutex_unlock(&driver->update_lock);
+
+ return rc;
+}
+EXPORT_SYMBOL(occ_update_device);
+
+void *occ_get_sensor(struct occ *driver, int sensor_type)
+{
+ int rc;
+
+ /* occ_update_device locks the update lock */
+ rc = occ_update_device(driver);
+ if (rc) {
+ dev_err(driver->dev, "cannot get occ sensor data: %d\n",
+ rc);
+ return NULL;
+ }
+
+ return occ_get_sensor_by_type(&driver->response, sensor_type);
+}
+EXPORT_SYMBOL(occ_get_sensor);
+
+int occ_get_sensor_value(struct occ *occ, int sensor_type, int sensor_num,
+ u32 hwmon, long *val)
+{
+ return occ->ops.get_sensor(occ, sensor_type, sensor_num, hwmon, val);
+}
+EXPORT_SYMBOL(occ_get_sensor_value);
+
+void occ_get_response_blocks(struct occ *occ, struct occ_blocks **blocks)
+{
+ *blocks = &occ->response.data;
+}
+EXPORT_SYMBOL(occ_get_response_blocks);
+
+void occ_set_update_interval(struct occ *occ, unsigned long interval)
+{
+ occ->update_interval = msecs_to_jiffies(interval);
+}
+EXPORT_SYMBOL(occ_set_update_interval);
+
+int occ_set_user_powercap(struct occ *occ, u16 cap)
+{
+ u8 resp[8];
+
+ cap = cpu_to_be16(cap);
+
+ return occ_send_cmd(occ, 0, OCC_SET_USER_POWR_CAP, 2, (const u8 *)&cap,
+ resp);
+}
+EXPORT_SYMBOL(occ_set_user_powercap);
+
+struct occ *occ_start(struct device *dev, void *bus,
+ struct occ_bus_ops *bus_ops, const struct occ_ops *ops,
+ const struct occ_config *config)
+{
+ struct occ *driver = devm_kzalloc(dev, sizeof(struct occ), GFP_KERNEL);
+
+ if (!driver)
+ return ERR_PTR(-ENOMEM);
+
+ driver->dev = dev;
+ driver->bus = bus;
+ driver->bus_ops = *bus_ops;
+ driver->ops = *ops;
+ driver->config = *config;
+
+ driver->update_interval = HZ;
+ mutex_init(&driver->update_lock);
+
+ return driver;
+}
+EXPORT_SYMBOL(occ_start);
+
+MODULE_AUTHOR("Eddie James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>");
+MODULE_DESCRIPTION("OCC hwmon core driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ.h b/drivers/hwmon/occ/occ.h
new file mode 100644
index 0000000..c86b06a
--- /dev/null
+++ b/drivers/hwmon/occ/occ.h
@@ -0,0 +1,81 @@
+/*
+ * occ.h - hwmon OCC driver
+ *
+ * This file contains data structures and function prototypes for common access
+ * between different bus protocols and host systems.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 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.
+ */
+
+#ifndef __OCC_H__
+#define __OCC_H__
+
+#include "scom.h"
+
+struct device;
+struct occ;
+
+/* sensor_data_block_header
+ * structure to match the raw occ sensor block header
+ */
+struct sensor_data_block_header {
+ u8 sensor_type[4];
+ u8 reserved0;
+ u8 sensor_format;
+ u8 sensor_length;
+ u8 sensor_num;
+} __attribute__((packed, aligned(4)));
+
+struct sensor_data_block {
+ struct sensor_data_block_header header;
+ void *sensors;
+};
+
+enum sensor_type {
+ FREQ = 0,
+ TEMP,
+ POWER,
+ CAPS,
+ MAX_OCC_SENSOR_TYPE
+};
+
+struct occ_ops {
+ void (*parse_sensor)(u8 *data, void *sensor, int sensor_type, int off,
+ int snum);
+ void *(*alloc_sensor)(int sensor_type, int num_sensors);
+ int (*get_sensor)(struct occ *driver, int sensor_type, int sensor_num,
+ u32 hwmon, long *val);
+};
+
+struct occ_config {
+ u32 command_addr;
+ u32 response_addr;
+};
+
+struct occ_blocks {
+ int sensor_block_id[MAX_OCC_SENSOR_TYPE];
+ struct sensor_data_block *blocks;
+};
+
+struct occ *occ_start(struct device *dev, void *bus,
+ struct occ_bus_ops *bus_ops, const struct occ_ops *ops,
+ const struct occ_config *config);
+void *occ_get_sensor(struct occ *occ, int sensor_type);
+int occ_get_sensor_value(struct occ *occ, int sensor_type, int sensor_num,
+ u32 hwmon, long *val);
+void occ_get_response_blocks(struct occ *occ, struct occ_blocks **blocks);
+int occ_update_device(struct occ *driver);
+void occ_set_update_interval(struct occ *occ, unsigned long interval);
+int occ_set_user_powercap(struct occ *occ, u16 cap);
+
+#endif /* __OCC_H__ */
diff --git a/drivers/hwmon/occ/scom.h b/drivers/hwmon/occ/scom.h
new file mode 100644
index 0000000..c1da645
--- /dev/null
+++ b/drivers/hwmon/occ/scom.h
@@ -0,0 +1,47 @@
+/*
+ * scom.h - hwmon OCC driver
+ *
+ * This file contains data structures for scom operations to the OCC
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 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.
+ */
+
+#ifndef __SCOM_H__
+#define __SCOM_H__
+
+/*
+ * occ_bus_ops - represent the low-level transfer methods to communicate with
+ * the OCC.
+ *
+ * getscom - OCC scom read
+ * @bus: handle to slave device
+ * @address: address
+ * @data: where to store data read from slave; buffer size must be at least
+ * eight bytes.
+ *
+ * Returns 0 on success or a negative errno on error
+ *
+ * putscom - OCC scom write
+ * @bus: handle to slave device
+ * @address: address
+ * @data0: first data byte to write
+ * @data1: second data byte to write
+ *
+ * Returns 0 on success or a negative errno on error
+ */
+struct occ_bus_ops {
+ int (*getscom)(void *bus, u32 address, u64 *data);
+ int (*putscom)(void *bus, u32 address, u32 data0, u32 data1);
+};
+
+#endif /* __SCOM_H__ */
--
1.9.1
--
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 linux v3 2/6] hwmon: occ: Add sysfs interface
From: eajames.ibm @ 2017-01-16 21:13 UTC (permalink / raw)
To: linux
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
corbet, mark.rutland, robh+dt, wsa, andrew, joel, benh,
Edward A. James
In-Reply-To: <1484601219-30196-1-git-send-email-eajames.ibm@gmail.com>
From: "Edward A. James" <eajames@us.ibm.com>
Add a generic mechanism to expose the sensors provided by the OCC in
sysfs.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
Documentation/hwmon/occ | 62 ++++++++++
drivers/hwmon/occ/Makefile | 2 +-
drivers/hwmon/occ/occ_sysfs.c | 271 ++++++++++++++++++++++++++++++++++++++++++
drivers/hwmon/occ/occ_sysfs.h | 44 +++++++
4 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 drivers/hwmon/occ/occ_sysfs.c
create mode 100644 drivers/hwmon/occ/occ_sysfs.h
diff --git a/Documentation/hwmon/occ b/Documentation/hwmon/occ
index 79d1642..d0bdf06 100644
--- a/Documentation/hwmon/occ
+++ b/Documentation/hwmon/occ
@@ -25,6 +25,68 @@ Currently, all versions of the OCC support four types of sensor data: power,
temperature, frequency, and "caps," which indicate limits and thresholds used
internally on the OCC.
+sysfs Entries
+-------------
+
+The OCC driver uses the hwmon sysfs framework to provide data to userspace.
+
+The driver exports a number of sysfs files for each type of sensor. The
+sensor-specific files vary depending on the processor type, though many of the
+attributes are common for both the POWER8 and POWER9.
+
+The hwmon interface cannot define every type of sensor that may be used.
+Therefore, the frequency sensor on the OCC uses the "input" type sensor defined
+by the hwmon interface, rather than defining a new type of custom sensor.
+
+Below are detailed the names and meaning of each sensor file for both types of
+processors. All sensors are read-only unless otherwise specified. <x> indicates
+the hwmon index. sensor id indicates the unique internal OCC identifer. Please
+see the POWER OCC specification for details on all these sensor values.
+
+frequency:
+ all processors:
+ in<x>_input - frequency value
+ in<x>_label - sensor id
+temperature:
+ POWER8:
+ temp<x>_input - temperature value
+ temp<x>_label - sensor id
+ POWER9 (in addition to above):
+ temp<x>_type - FRU type
+
+power:
+ POWER8:
+ power<x>_input - power value
+ power<x>_label - sensor id
+ power<x>_average - accumulator
+ power<x>_average_interval - update tag (number of samples in
+ accumulator)
+ POWER9:
+ power<x>_input - power value
+ power<x>_label - sensor id
+ power<x>_average_min - accumulator[0]
+ power<x>_average_max - accumulator[1] (64 bits total)
+ power<x>_average_interval - update tag
+ power<x>_reset_history - (function_id | (apss_channel << 8)
+
+caps:
+ POWER8:
+ power<x>_cap - current powercap
+ power<x>_cap_max - max powercap
+ power<x>_cap_min - min powercap
+ power<x>_max - normal powercap
+ power<x>_alarm - user powercap, r/w
+ POWER9:
+ power<x>_cap_alarm - user powercap source
+
+The driver also provides two sysfs entries through hwmon to better
+control the driver and monitor the master OCC. Though there may be multiple
+OCCs present on the system, these two files are only present for the "master"
+OCC.
+ name - read the name of the driver
+ update_interval - read or write the minimum interval for polling the
+ OCC.
+
BMC - Host Communications
-------------------------
diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
index 93cb52f..a6881f9 100644
--- a/drivers/hwmon/occ/Makefile
+++ b/drivers/hwmon/occ/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o
+obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
diff --git a/drivers/hwmon/occ/occ_sysfs.c b/drivers/hwmon/occ/occ_sysfs.c
new file mode 100644
index 0000000..2f20c40
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.c
@@ -0,0 +1,271 @@
+/*
+ * occ_sysfs.c - OCC sysfs interface
+ *
+ * This file contains the methods and data structures for implementing the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/init.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include "occ.h"
+#include "occ_sysfs.h"
+
+#define RESP_RETURN_CMD_INVAL 0x13
+
+static int occ_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ int rc = 0;
+ struct occ_sysfs *driver = dev_get_drvdata(dev);
+ struct occ *occ = driver->occ;
+
+ switch (type) {
+ case hwmon_in:
+ rc = occ_get_sensor_value(occ, FREQ, channel, attr, val);
+ break;
+ case hwmon_temp:
+ rc = occ_get_sensor_value(occ, TEMP, channel, attr, val);
+ break;
+ case hwmon_power:
+ rc = occ_get_sensor_value(occ, POWER, channel, attr, val);
+ break;
+ default:
+ rc = -EOPNOTSUPP;
+ }
+
+ return rc;
+}
+
+static int occ_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, char **str)
+{
+ int rc;
+ unsigned long val = 0;
+
+ if (!((type == hwmon_in && attr == hwmon_in_label) ||
+ (type == hwmon_temp && attr == hwmon_temp_label) ||
+ (type == hwmon_power && attr == hwmon_power_label)))
+ return -EOPNOTSUPP;
+
+ rc = occ_hwmon_read(dev, type, attr, channel, &val);
+ if (rc < 0)
+ return rc;
+
+ rc = snprintf(*str, PAGE_SIZE - 1, "%ld", val);
+ if (rc > 0)
+ rc = 0;
+
+ return rc;
+}
+
+static int occ_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long val)
+{
+ int rc = 0;
+ struct occ_sysfs *driver = dev_get_drvdata(dev);
+
+ if (type == hwmon_chip && attr == hwmon_chip_update_interval) {
+ occ_set_update_interval(driver->occ, val);
+ return 0;
+ } else if (type == hwmon_power && attr == hwmon_power_alarm) {
+ rc = occ_set_user_powercap(driver->occ, val);
+ if (rc) {
+ if (rc == RESP_RETURN_CMD_INVAL) {
+ dev_err(dev,
+ "set invalid powercap value: %ld\n",
+ val);
+ return -EINVAL;
+ }
+
+ dev_err(dev, "set user powercap failed: 0x:%x\n", rc);
+ return rc;
+ }
+
+ driver->user_powercap = val;
+
+ return rc;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static umode_t occ_is_visible(const void *data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct occ_sysfs *driver = data;
+
+ switch (type) {
+ case hwmon_chip:
+ if (attr == hwmon_chip_update_interval)
+ return S_IRUGO | S_IWUSR;
+ break;
+ case hwmon_in:
+ if (BIT(attr) & driver->sensor_hwmon_configs[0])
+ return S_IRUGO;
+ break;
+ case hwmon_temp:
+ if (BIT(attr) & driver->sensor_hwmon_configs[1])
+ return S_IRUGO;
+ break;
+ case hwmon_power:
+ /* user power limit */
+ if (attr == hwmon_power_alarm)
+ return S_IRUGO | S_IWUSR;
+ else if ((BIT(attr) & driver->sensor_hwmon_configs[2]) ||
+ (BIT(attr) & driver->sensor_hwmon_configs[3]))
+ return S_IRUGO;
+ break;
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+
+static const struct hwmon_ops occ_hwmon_ops = {
+ .is_visible = occ_is_visible,
+ .read = occ_hwmon_read,
+ .read_string = occ_hwmon_read_string,
+ .write = occ_hwmon_write,
+};
+
+static const u32 occ_chip_config[] = {
+ HWMON_C_UPDATE_INTERVAL,
+ 0
+};
+
+static const struct hwmon_channel_info occ_chip = {
+ .type = hwmon_chip,
+ .config = occ_chip_config
+};
+
+static const enum hwmon_sensor_types occ_sensor_types[MAX_OCC_SENSOR_TYPE] = {
+ hwmon_in,
+ hwmon_temp,
+ hwmon_power,
+ hwmon_power
+};
+
+struct occ_sysfs *occ_sysfs_start(struct device *dev, struct occ *occ,
+ const u32 *sensor_hwmon_configs,
+ const char *name)
+{
+ bool master_occ = false;
+ int rc, i, j, sensor_num, index = 0, id;
+ char *brk;
+ struct occ_blocks *resp = NULL;
+ u32 *sensor_config;
+ struct occ_sysfs *hwmon = devm_kzalloc(dev, sizeof(struct occ_sysfs),
+ GFP_KERNEL);
+ if (!hwmon)
+ return ERR_PTR(-ENOMEM);
+
+ /* need space for null-termination and occ chip */
+ hwmon->occ_sensors =
+ devm_kzalloc(dev, sizeof(struct hwmon_channel_info *) *
+ (MAX_OCC_SENSOR_TYPE + 2), GFP_KERNEL);
+ if (!hwmon->occ_sensors)
+ return ERR_PTR(-ENOMEM);
+
+ hwmon->occ = occ;
+ hwmon->sensor_hwmon_configs = (u32 *)sensor_hwmon_configs;
+ hwmon->occ_info.ops = &occ_hwmon_ops;
+ hwmon->occ_info.info =
+ (const struct hwmon_channel_info **)hwmon->occ_sensors;
+
+ occ_get_response_blocks(occ, &resp);
+
+ for (i = 0; i < MAX_OCC_SENSOR_TYPE; ++i)
+ resp->sensor_block_id[i] = -1;
+
+ /* read sensor data from occ */
+ rc = occ_update_device(occ);
+ if (rc) {
+ dev_err(dev, "cannot get occ sensor data: %d\n", rc);
+ return ERR_PTR(rc);
+ }
+ if (!resp->blocks)
+ return ERR_PTR(-ENOMEM);
+
+ master_occ = resp->sensor_block_id[CAPS] >= 0;
+
+ for (i = 0; i < MAX_OCC_SENSOR_TYPE; i++) {
+ id = resp->sensor_block_id[i];
+ if (id < 0)
+ continue;
+
+ sensor_num = resp->blocks[id].header.sensor_num;
+ /* need null-termination */
+ sensor_config = devm_kzalloc(dev,
+ sizeof(u32) * (sensor_num + 1),
+ GFP_KERNEL);
+ if (!sensor_config)
+ return ERR_PTR(-ENOMEM);
+
+ for (j = 0; j < sensor_num; j++)
+ sensor_config[j] = sensor_hwmon_configs[i];
+
+ hwmon->occ_sensors[index] =
+ devm_kzalloc(dev, sizeof(struct hwmon_channel_info),
+ GFP_KERNEL);
+ if (!hwmon->occ_sensors[index])
+ return ERR_PTR(-ENOMEM);
+
+ hwmon->occ_sensors[index]->type = occ_sensor_types[i];
+ hwmon->occ_sensors[index]->config = sensor_config;
+ index++;
+ }
+
+ /* only need one of these for any number of occs */
+ if (master_occ)
+ hwmon->occ_sensors[index] =
+ (struct hwmon_channel_info *)&occ_chip;
+
+ /* search for bad chars */
+ strncpy(hwmon->hwmon_name, name, OCC_HWMON_NAME_LENGTH);
+ brk = strpbrk(hwmon->hwmon_name, "-* \t\n");
+ while (brk) {
+ *brk = '_';
+ brk = strpbrk(brk, "-* \t\n");
+ }
+
+ hwmon->dev = devm_hwmon_device_register_with_info(dev,
+ hwmon->hwmon_name,
+ hwmon,
+ &hwmon->occ_info,
+ NULL);
+ if (IS_ERR(hwmon->dev)) {
+ dev_err(dev, "cannot register hwmon device %s: %ld\n",
+ hwmon->hwmon_name, PTR_ERR(hwmon->dev));
+ return ERR_CAST(hwmon->dev);
+ }
+
+ return hwmon;
+}
+EXPORT_SYMBOL(occ_sysfs_start);
+
+MODULE_AUTHOR("Eddie James <eajames@us.ibm.com>");
+MODULE_DESCRIPTION("OCC sysfs driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_sysfs.h b/drivers/hwmon/occ/occ_sysfs.h
new file mode 100644
index 0000000..7de92e7
--- /dev/null
+++ b/drivers/hwmon/occ/occ_sysfs.h
@@ -0,0 +1,44 @@
+/*
+ * occ_sysfs.h - OCC sysfs interface
+ *
+ * This file contains the data structures and function prototypes for the OCC
+ * hwmon sysfs entries.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 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.
+ */
+
+#ifndef __OCC_SYSFS_H__
+#define __OCC_SYSFS_H__
+
+#include <linux/hwmon.h>
+
+struct occ;
+struct device;
+
+#define OCC_HWMON_NAME_LENGTH 32
+
+struct occ_sysfs {
+ struct device *dev;
+ struct occ *occ;
+
+ char hwmon_name[OCC_HWMON_NAME_LENGTH + 1];
+ u32 *sensor_hwmon_configs;
+ struct hwmon_channel_info **occ_sensors;
+ struct hwmon_chip_info occ_info;
+ u16 user_powercap;
+};
+
+struct occ_sysfs *occ_sysfs_start(struct device *dev, struct occ *occ,
+ const u32 *sensor_hwmon_configs,
+ const char *name);
+#endif /* __OCC_SYSFS_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH linux v3 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
From: eajames.ibm @ 2017-01-16 21:13 UTC (permalink / raw)
To: linux
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
corbet, mark.rutland, robh+dt, wsa, andrew, joel, benh,
Edward A. James
In-Reply-To: <1484601219-30196-1-git-send-email-eajames.ibm@gmail.com>
From: "Edward A. James" <eajames@us.ibm.com>
Add functions to send SCOM operations over I2C bus. The BMC can
communicate with the Power8 host processor over I2C, but needs to use SCOM
operations in order to access the OCC register space.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/hwmon/occ/occ_scom_i2c.c | 72 ++++++++++++++++++++++++++++++++++++++++
drivers/hwmon/occ/occ_scom_i2c.h | 26 +++++++++++++++
2 files changed, 98 insertions(+)
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.c
create mode 100644 drivers/hwmon/occ/occ_scom_i2c.h
diff --git a/drivers/hwmon/occ/occ_scom_i2c.c b/drivers/hwmon/occ/occ_scom_i2c.c
new file mode 100644
index 0000000..8b4ca13
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.c
@@ -0,0 +1,72 @@
+/*
+ * occ_scom_i2c.c - hwmon OCC driver
+ *
+ * This file contains the functions for performing SCOM operations over I2C bus
+ * to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include "occ_scom_i2c.h"
+#include "scom.h"
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data)
+{
+ ssize_t rc;
+ u64 buf;
+ struct i2c_client *client = bus;
+
+ rc = i2c_master_send(client, (const char *)&address, sizeof(u32));
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32))
+ return -EIO;
+
+ rc = i2c_master_recv(client, (char *)&buf, sizeof(u64));
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u64))
+ return -EIO;
+
+ *data = be64_to_cpu(buf);
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_getscom);
+
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
+{
+ u32 buf[3];
+ ssize_t rc;
+ struct i2c_client *client = bus;
+
+ buf[0] = address;
+ buf[1] = data1;
+ buf[2] = data0;
+
+ rc = i2c_master_send(client, (const char *)buf, sizeof(u32) * 3);
+ if (rc < 0)
+ return rc;
+ else if (rc != sizeof(u32) * 3)
+ return -EIO;
+
+ return 0;
+}
+EXPORT_SYMBOL(occ_i2c_putscom);
+
+MODULE_AUTHOR("Eddie James <eajames@us.ibm.com>");
+MODULE_DESCRIPTION("I2C OCC SCOM transport");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/occ/occ_scom_i2c.h b/drivers/hwmon/occ/occ_scom_i2c.h
new file mode 100644
index 0000000..945739c
--- /dev/null
+++ b/drivers/hwmon/occ/occ_scom_i2c.h
@@ -0,0 +1,26 @@
+/*
+ * occ_scom_i2c.h - hwmon OCC driver
+ *
+ * This file contains function protoypes for peforming SCOM operations over I2C
+ * bus to access the OCC.
+ *
+ * Copyright 2016 IBM Corp.
+ *
+ * This program 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 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.
+ */
+
+#ifndef __OCC_SCOM_I2C_H__
+#define __OCC_SCOM_I2C_H__
+
+int occ_i2c_getscom(void *bus, u32 address, u64 *data);
+int occ_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1);
+
+#endif /* __OCC_SCOM_I2C_H__ */
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox