* Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
From: Viresh Kumar @ 2017-12-27 8:56 UTC (permalink / raw)
To: Rob Herring
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, sudeep.holla-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171226202955.32j7gzonrixtwdpt@rob-hp-laptop>
On 26-12-17, 14:29, Rob Herring wrote:
> On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:
> > +On some platforms the exact frequency or voltage may be hidden from the OS by
> > +the firmware and the "opp-hz" or the "opp-microvolt" properties may contain
> > +magic values that represent the frequency or voltage in a firmware dependent
> > +way, for example an index of an array in the firmware.
>
> I'm still not convinced this is a good idea.
You were kind-of a few days back :)
lkml.kernel.org/r/CAL_JsqK-qtAaM_Ou5NtxcWR3F_q=8rMPJUm-VqGtKhbtWe5SAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
So here is the deal:
- I proposed "domain-performance-state" property for this stuff
initially.
- But Kevin didn't like that and proposed reusing "opp-hz" and
"opp-microvolt", which we all agreed to multiple times..
- And we are back to the same discussion now and its painful and time
killing for all of us.
TBH, I don't have too strong preferences about any of the suggestions
you guys have and I need you guys to tell me what binding changes to
do here and I will do that.
> If you have firmware
> partially managing things, then I think we should have platform specific
> bindings or drivers.
What about the initial idea then, like "performance-state" for the
power domains ? All platforms will anyway replicate that binding only.
> This is complex enough I'm not taking silence from Stephen as an okay.
Sure, but I am not sure how to make him speak :)
--
viresh
--
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] Device tree binding for Avago APDS990X light sensor
From: Pavel Machek @ 2017-12-27 9:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, devicetree, linux-kernel, pali.rohar, sre,
linux-arm-kernel, linux-omap, tony, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge, abcloriens, clayton,
martijn, sakari.ailus, Filip Matijević
[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]
From: Filip Matijević <filip.matijevic.pz@gmail.com>
This prepares binding for light sensor used in Nokia N9.
Signed-off-by: Filip Matijević <filip.matijevic.pz@gmail.com>
Signed-off-by: Pavel machek <pavel@ucw.cz>
---
Patches to convert APDS990X driver to device tree and to switch to iio
are available.
diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
new file mode 100644
index 0000000..e038146
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
@@ -0,0 +1,39 @@
+Avago APDS990X driver
+
+Required properties:
+- compatible: "avago,apds990x"
+- reg: address on the I2C bus
+- interrupts: external interrupt line number
+- Vdd-supply: power supply for VDD
+- Vled-supply: power supply for LEDA
+- ga: Glass attenuation
+- cf1: Clear channel factor 1
+- irf1: IR channel factor 1
+- cf2: Clear channel factor 2
+- irf2: IR channel factor 2
+- df: Device factor
+- pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
+- ppcount: Proximity pulse count
+
+Example (Nokia N9):
+
+ als_ps@39 {
+ compatible = "avago,apds990x";
+ reg = <0x39>;
+
+ interrupt-parent = <&gpio3>;
+ interrupts = <19 10>; /* gpio_83, IRQF_TRIGGER_FALLING | IRQF_TRIGGER_LOW */
+
+ Vdd-supply = <&vaux1>;
+ Vled-supply = <&vbat>;
+
+ ga = <168834>;
+ cf1 = <4096>;
+ irf1 = <7824>;
+ cf2 = <877>;
+ irf2 = <1575>;
+ df = <52>;
+
+ pdrive = <0x2>; /* APDS_IRLED_CURR_25mA */
+ ppcount = <5>;
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* [PATCH] PCI: exynos: remove the deprecated phy codes
From: Jaehoon Chung @ 2017-12-27 9:43 UTC (permalink / raw)
To: linux-pci
Cc: linux-samsung-soc, devicetree, linux-kernel, bhelgaas, robh+dt,
krzk, jingoohan1, mark.rutland, kgene, lorenzo.pieralisi,
Jaehoon Chung
In-Reply-To: <CGME20171227094329epcas1p2a7b0a0f6130db4361592d8966d5ecb85@epcas1p2.samsung.com>
pci-exynos had updated to use the PHY framework.
(drivers/phy/samsung/phy-exynos-pcie.c)
Removed the depreccated codes relevant to phy in pci-exynos.c.
Instead, use the phy-exynos-pcie.c file.
Modified the binding documentation.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
.../bindings/pci/samsung,exynos5440-pcie.txt | 58 ++----
drivers/pci/dwc/pci-exynos.c | 219 ++-------------------
2 files changed, 22 insertions(+), 255 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
index 34a11bfbfb60..651d957d1051 100644
--- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
@@ -6,9 +6,6 @@ and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
- compatible: "samsung,exynos5440-pcie"
- reg: base addresses and lengths of the PCIe controller,
- the PHY controller, additional register for the PHY controller.
- (Registers for the PHY controller are DEPRECATED.
- Use the PHY framework.)
- reg-names : First name should be set to "elbi".
And use the "config" instead of getting the configuration address space
from "ranges".
@@ -23,49 +20,8 @@ For other common properties, refer to
Example:
-SoC-specific DT Entry:
+SoC-specific DT Entry (with using PHY framework):
- pcie@290000 {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x290000 0x1000
- 0x270000 0x1000
- 0x271000 0x40>;
- interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
- clocks = <&clock 28>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
- 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
- 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
- num-lanes = <4>;
- };
-
- pcie@2a0000 {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x2a0000 0x1000
- 0x272000 0x1000
- 0x271040 0x40>;
- interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
- clocks = <&clock 29>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
- 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
- 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
- num-lanes = <4>;
- };
-
-With using PHY framework:
pcie_phy0: pcie-phy@270000 {
...
reg = <0x270000 0x1000>, <0x271000 0x40>;
@@ -74,13 +30,21 @@ With using PHY framework:
};
pcie@290000 {
- ...
+ compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x290000 0x1000>, <0x40000000 0x1000>;
reg-names = "elbi", "config";
+ clocks = <&clock 28>, <&clock 27>;
+ clock-names = "pcie", "pcie_bus";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
phys = <&pcie_phy0>;
ranges = <0x81000000 0 0 0x60001000 0 0x00010000
0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
- ...
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ num-lanes = <4>;
};
Board-specific DT Entry:
diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c
index 5596fdedbb94..56f32aeebd0a 100644
--- a/drivers/pci/dwc/pci-exynos.c
+++ b/drivers/pci/dwc/pci-exynos.c
@@ -55,49 +55,8 @@
#define PCIE_ELBI_SLV_ARMISC 0x120
#define PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
-/* PCIe Purple registers */
-#define PCIE_PHY_GLOBAL_RESET 0x000
-#define PCIE_PHY_COMMON_RESET 0x004
-#define PCIE_PHY_CMN_REG 0x008
-#define PCIE_PHY_MAC_RESET 0x00c
-#define PCIE_PHY_PLL_LOCKED 0x010
-#define PCIE_PHY_TRSVREG_RESET 0x020
-#define PCIE_PHY_TRSV_RESET 0x024
-
-/* PCIe PHY registers */
-#define PCIE_PHY_IMPEDANCE 0x004
-#define PCIE_PHY_PLL_DIV_0 0x008
-#define PCIE_PHY_PLL_BIAS 0x00c
-#define PCIE_PHY_DCC_FEEDBACK 0x014
-#define PCIE_PHY_PLL_DIV_1 0x05c
-#define PCIE_PHY_COMMON_POWER 0x064
-#define PCIE_PHY_COMMON_PD_CMN BIT(3)
-#define PCIE_PHY_TRSV0_EMP_LVL 0x084
-#define PCIE_PHY_TRSV0_DRV_LVL 0x088
-#define PCIE_PHY_TRSV0_RXCDR 0x0ac
-#define PCIE_PHY_TRSV0_POWER 0x0c4
-#define PCIE_PHY_TRSV0_PD_TSV BIT(7)
-#define PCIE_PHY_TRSV0_LVCC 0x0dc
-#define PCIE_PHY_TRSV1_EMP_LVL 0x144
-#define PCIE_PHY_TRSV1_RXCDR 0x16c
-#define PCIE_PHY_TRSV1_POWER 0x184
-#define PCIE_PHY_TRSV1_PD_TSV BIT(7)
-#define PCIE_PHY_TRSV1_LVCC 0x19c
-#define PCIE_PHY_TRSV2_EMP_LVL 0x204
-#define PCIE_PHY_TRSV2_RXCDR 0x22c
-#define PCIE_PHY_TRSV2_POWER 0x244
-#define PCIE_PHY_TRSV2_PD_TSV BIT(7)
-#define PCIE_PHY_TRSV2_LVCC 0x25c
-#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4
-#define PCIE_PHY_TRSV3_RXCDR 0x2ec
-#define PCIE_PHY_TRSV3_POWER 0x304
-#define PCIE_PHY_TRSV3_PD_TSV BIT(7)
-#define PCIE_PHY_TRSV3_LVCC 0x31c
-
struct exynos_pcie_mem_res {
void __iomem *elbi_base; /* DT 0th resource: PCIe CTRL */
- void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
- void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
};
struct exynos_pcie_clk_res {
@@ -112,8 +71,6 @@ struct exynos_pcie {
const struct exynos_pcie_ops *ops;
int reset_gpio;
- /* For Generic PHY Framework */
- bool using_phy;
struct phy *phy;
};
@@ -141,20 +98,6 @@ static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
if (IS_ERR(ep->mem_res->elbi_base))
return PTR_ERR(ep->mem_res->elbi_base);
- /* If using the PHY framework, doesn't need to get other resource */
- if (ep->using_phy)
- return 0;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(ep->mem_res->phy_base))
- return PTR_ERR(ep->mem_res->phy_base);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- ep->mem_res->block_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(ep->mem_res->block_base))
- return PTR_ERR(ep->mem_res->block_base);
-
return 0;
}
@@ -279,111 +222,6 @@ static void exynos_pcie_deassert_core_reset(struct exynos_pcie *ep)
exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_NONSTICKY_RESET);
exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_APP_INIT_RESET);
exynos_pcie_writel(ep->mem_res->elbi_base, 0, PCIE_APP_INIT_RESET);
- exynos_pcie_writel(ep->mem_res->block_base, 1, PCIE_PHY_MAC_RESET);
-}
-
-static void exynos_pcie_assert_phy_reset(struct exynos_pcie *ep)
-{
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_MAC_RESET);
- exynos_pcie_writel(ep->mem_res->block_base, 1, PCIE_PHY_GLOBAL_RESET);
-}
-
-static void exynos_pcie_deassert_phy_reset(struct exynos_pcie *ep)
-{
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_GLOBAL_RESET);
- exynos_pcie_writel(ep->mem_res->elbi_base, 1, PCIE_PWR_RESET);
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_COMMON_RESET);
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_CMN_REG);
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_TRSVREG_RESET);
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_TRSV_RESET);
-}
-
-static void exynos_pcie_power_on_phy(struct exynos_pcie *ep)
-{
- u32 val;
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_COMMON_POWER);
- val &= ~PCIE_PHY_COMMON_PD_CMN;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_COMMON_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV0_POWER);
- val &= ~PCIE_PHY_TRSV0_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV0_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV1_POWER);
- val &= ~PCIE_PHY_TRSV1_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV1_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV2_POWER);
- val &= ~PCIE_PHY_TRSV2_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV2_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV3_POWER);
- val &= ~PCIE_PHY_TRSV3_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV3_POWER);
-}
-
-static void exynos_pcie_power_off_phy(struct exynos_pcie *ep)
-{
- u32 val;
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_COMMON_POWER);
- val |= PCIE_PHY_COMMON_PD_CMN;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_COMMON_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV0_POWER);
- val |= PCIE_PHY_TRSV0_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV0_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV1_POWER);
- val |= PCIE_PHY_TRSV1_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV1_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV2_POWER);
- val |= PCIE_PHY_TRSV2_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV2_POWER);
-
- val = exynos_pcie_readl(ep->mem_res->phy_base, PCIE_PHY_TRSV3_POWER);
- val |= PCIE_PHY_TRSV3_PD_TSV;
- exynos_pcie_writel(ep->mem_res->phy_base, val, PCIE_PHY_TRSV3_POWER);
-}
-
-static void exynos_pcie_init_phy(struct exynos_pcie *ep)
-{
- /* DCC feedback control off */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x29, PCIE_PHY_DCC_FEEDBACK);
-
- /* set TX/RX impedance */
- exynos_pcie_writel(ep->mem_res->phy_base, 0xd5, PCIE_PHY_IMPEDANCE);
-
- /* set 50Mhz PHY clock */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x14, PCIE_PHY_PLL_DIV_0);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x12, PCIE_PHY_PLL_DIV_1);
-
- /* set TX Differential output for lane 0 */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x7f, PCIE_PHY_TRSV0_DRV_LVL);
-
- /* set TX Pre-emphasis Level Control for lane 0 to minimum */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x0, PCIE_PHY_TRSV0_EMP_LVL);
-
- /* set RX clock and data recovery bandwidth */
- exynos_pcie_writel(ep->mem_res->phy_base, 0xe7, PCIE_PHY_PLL_BIAS);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x82, PCIE_PHY_TRSV0_RXCDR);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x82, PCIE_PHY_TRSV1_RXCDR);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x82, PCIE_PHY_TRSV2_RXCDR);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x82, PCIE_PHY_TRSV3_RXCDR);
-
- /* change TX Pre-emphasis Level Control for lanes */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x39, PCIE_PHY_TRSV0_EMP_LVL);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x39, PCIE_PHY_TRSV1_EMP_LVL);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x39, PCIE_PHY_TRSV2_EMP_LVL);
- exynos_pcie_writel(ep->mem_res->phy_base, 0x39, PCIE_PHY_TRSV3_EMP_LVL);
-
- /* set LVCC */
- exynos_pcie_writel(ep->mem_res->phy_base, 0x20, PCIE_PHY_TRSV0_LVCC);
- exynos_pcie_writel(ep->mem_res->phy_base, 0xa0, PCIE_PHY_TRSV1_LVCC);
- exynos_pcie_writel(ep->mem_res->phy_base, 0xa0, PCIE_PHY_TRSV2_LVCC);
- exynos_pcie_writel(ep->mem_res->phy_base, 0xa0, PCIE_PHY_TRSV3_LVCC);
}
static void exynos_pcie_assert_reset(struct exynos_pcie *ep)
@@ -401,7 +239,6 @@ static int exynos_pcie_establish_link(struct exynos_pcie *ep)
struct dw_pcie *pci = ep->pci;
struct pcie_port *pp = &pci->pp;
struct device *dev = pci->dev;
- u32 val;
if (dw_pcie_link_up(pci)) {
dev_err(dev, "Link already up\n");
@@ -410,32 +247,13 @@ static int exynos_pcie_establish_link(struct exynos_pcie *ep)
exynos_pcie_assert_core_reset(ep);
- if (ep->using_phy) {
- phy_reset(ep->phy);
-
- exynos_pcie_writel(ep->mem_res->elbi_base, 1,
- PCIE_PWR_RESET);
-
- phy_power_on(ep->phy);
- phy_init(ep->phy);
- } else {
- exynos_pcie_assert_phy_reset(ep);
- exynos_pcie_deassert_phy_reset(ep);
- exynos_pcie_power_on_phy(ep);
- exynos_pcie_init_phy(ep);
-
- /* pulse for common reset */
- exynos_pcie_writel(ep->mem_res->block_base, 1,
- PCIE_PHY_COMMON_RESET);
- udelay(500);
- exynos_pcie_writel(ep->mem_res->block_base, 0,
- PCIE_PHY_COMMON_RESET);
- }
+ phy_reset(ep->phy);
- /* pulse for common reset */
- exynos_pcie_writel(ep->mem_res->block_base, 1, PCIE_PHY_COMMON_RESET);
- udelay(500);
- exynos_pcie_writel(ep->mem_res->block_base, 0, PCIE_PHY_COMMON_RESET);
+ exynos_pcie_writel(ep->mem_res->elbi_base, 1,
+ PCIE_PWR_RESET);
+
+ phy_power_on(ep->phy);
+ phy_init(ep->phy);
exynos_pcie_deassert_core_reset(ep);
dw_pcie_setup_rc(pp);
@@ -449,18 +267,7 @@ static int exynos_pcie_establish_link(struct exynos_pcie *ep)
if (!dw_pcie_wait_for_link(pci))
return 0;
- if (ep->using_phy) {
- phy_power_off(ep->phy);
- return -ETIMEDOUT;
- }
-
- while (exynos_pcie_readl(ep->mem_res->phy_base,
- PCIE_PHY_PLL_LOCKED) == 0) {
- val = exynos_pcie_readl(ep->mem_res->block_base,
- PCIE_PHY_PLL_LOCKED);
- dev_info(dev, "PLL Locked: 0x%x\n", val);
- }
- exynos_pcie_power_off_phy(ep);
+ phy_power_off(ep->phy);
return -ETIMEDOUT;
}
@@ -678,16 +485,13 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
ep->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
- /* Assume that controller doesn't use the PHY framework */
- ep->using_phy = false;
-
ep->phy = devm_of_phy_get(dev, np, NULL);
if (IS_ERR(ep->phy)) {
if (PTR_ERR(ep->phy) == -EPROBE_DEFER)
return PTR_ERR(ep->phy);
- dev_warn(dev, "Use the 'phy' property. Current DT of pci-exynos was deprecated!!\n");
- } else
- ep->using_phy = true;
+
+ ep->phy = NULL;
+ }
if (ep->ops && ep->ops->get_mem_resources) {
ret = ep->ops->get_mem_resources(pdev, ep);
@@ -713,8 +517,7 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
return 0;
fail_probe:
- if (ep->using_phy)
- phy_exit(ep->phy);
+ phy_exit(ep->phy);
if (ep->ops && ep->ops->deinit_clk_resources)
ep->ops->deinit_clk_resources(ep);
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver
From: Łukasz Stelmach @ 2017-12-27 10:12 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Herbert Xu, Krzysztof Kozlowski, Kukjin Kim,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-crypto, linux-samsung-soc, LKML, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <CAOFm3uEj7MDa_7OtigHcUPwvxkR+8cRS=UQq3x_y9k+ypcJPrg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
It was <2017-12-22 pią 19:30>, when Philippe Ombredanne wrote:
> On Fri, Dec 22, 2017 at 5:38 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>> It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
>>> Łukasz,
>>>
>>> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>> Add support for True Random Number Generator found in Samsung Exynos
>>>> 5250+ SoCs.
>>>>
>>>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>
>>> <snip>
>>>
>>>> --- /dev/null
>>>> +++ b/drivers/char/hw_random/exynos-trng.c
>>>> @@ -0,0 +1,245 @@
>>>> +/*
>>>> + * RNG driver for Exynos TRNGs
>>>> + *
>>>> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>>>> + *
>>>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>>>> + *
>>>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>>>> + * Krzysztof Kozłowski <krzk@kernel.org>
>>>> + *
>>>> + * 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;
>>>> + *
>>>> + * 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.
>>>> + */
>>>
>>>
>>> Would you mind using the new SPDX tags documented in Thomas patch set
>>> [1] rather than this fine but longer legalese?
>>>
>>> And if you could spread the word to others in your team this would be very nice.
>>> See also this fine article posted by Mauro on the Samsung Open Source
>>> Group Blog [2]
>>> Thank you!
>>
>> Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
>> more. ;-)
>
> Very nice! any pubic pointers?
^^^^^
I assume you request an URL of a publicly available web-page ;-)
https://wiki.tizen.org/Packaging/Guidelines#License_Tag
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply
* Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Sricharan R @ 2017-12-27 10:20 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Rafael J. Wysocki,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Viresh Kumar, Michael Turquette, linux-pm, Stephen Boyd,
Russell King, linux-kernel@vger.kernel.org, David Brown,
linux-arm-msm, Andy Gross, open list:ARM/QUALCOMM SUPPORT,
linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJTBgr2ctyRXGyzkRLztoy=qtvEh3AC79RjENBS=6yQRg@mail.gmail.com>
Hi Rob,
On 12/26/2017 11:06 PM, Rob Herring wrote:
> On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R <sricharan@codeaurora.org> wrote:
>> Hi Rob,
>>
>> On 12/21/2017 2:48 AM, Rob Herring wrote:
>>> On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
>>>> Hi Viresh,
>>>>
>>>> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>>>>> On 19-12-17, 21:25, Sricharan R wrote:
>>>>>> + cpu@0 {
>>>>>> + compatible = "qcom,krait";
>>>>>> + enable-method = "qcom,kpss-acc-v1";
>>>>>> + device_type = "cpu";
>>>>>> + reg = <0>;
>>>>>> + qcom,acc = <&acc0>;
>>>>>> + qcom,saw = <&saw0>;
>>>>>> + clocks = <&kraitcc 0>;
>>>>>> + clock-names = "cpu";
>>>>>> + cpu-supply = <&smb208_s2a>;
>>>>>> + operating-points-v2 = <&cpu_opp_table>;
>>>>>> + };
>>>>>> +
>>>>>> + qcom,pvs {
>>>>>> + qcom,pvs-format-a;
>>>>>> + };
>>>>>
>>>>> Not sure what Rob is going to say on that :)
>>>>>
>>>>
>>>> Yes. Would be good to know the best way.
>>>
>>> Seems like this should be a property of an efuse node either implied by
>>> the compatible or a separate property. What determines format A vs. B?
>>>
>>
>> Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
>> So this property (details like bitfields and register offsets that it represents)
>> can be put soc specific and nvmem apis can be used to read
>> the registers. Does something like below look ok ?
>>
>> qcom,pvs {
>> compatible = "qcom,pvs-ipq8064";
>> nvmem-cells = <&pvs_efuse>;
>> }
>
> Why do you need this node? It doesn't look like it corresponds to a
> h/w block. It looks like you are just creating it to instantiate a
> driver.
>
>> qfprom: qfprom@700000 {
>> compatible = "qcom,qfprom";
>
> Either this or...
>
>> reg = <0x00700000 0x1000>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>> pvs_efuse: pvs {
>
> a compatible here should be specific enough so the OS can know what
> the bits are.
Infact the above "qcom,pvs" node is required mainly to act as a consumer
for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = <&pvs_efuse>)
Then "qfprom" can be made to contain a "format_a" or "format_b" specific cell.
So all that is needed is, nvmem-cells = <&pvs_efuse_phandle> needs to be available
somewhere. The requirement is similar what is now done by "operating-points-v2-ti-cpu"
and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the syscon
register to read the efuse values. Similarly does defining a new
"operating-points-v2-krait-cpu" which would contain the nvmem-cells property look ok ?
This would avoid defining a new qcom,pvs node.
cpu@0 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
reg = <0>;
qcom,acc = <&acc0>;
qcom,saw = <&saw0>;
clocks = <&kraitcc 0>;
clock-names = "cpu";
cpu-supply = <&smb208_s2a>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu_opp_table: opp_table {
compatible = "operating-points-v2-krait-cpu";
nvmem-cells = <&pvs_efuse_format_a>;
/*
* Missing opp-shared property means CPUs switch DVFS states
* independently.
*/
opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt-speed0-pvs0-v0 = <1250000>;
opp-microvolt-speed0-pvs1-v0 = <1175000>;
opp-microvolt-speed0-pvs2-v0 = <1125000>;
opp-microvolt-speed0-pvs3-v0 = <1050000>;
};
...
}
qfprom: qfprom@700000 {
compatible = "qcom,qfprom";
reg = <0x00700000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
pvs_efuse_format_a: pvs {
reg = <0xc0 0x8>;
};
}
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI
From: Mark Brown @ 2017-12-27 10:36 UTC (permalink / raw)
To: Trent Piepho
Cc: linux-mtd@lists.infradead.org, linux@armlinux.org.uk,
cyrille.pitchen@wedev4u.fr, dwmw2@infradead.org,
computersforpeace@gmail.com, boris.brezillon@free-electrons.com,
vigneshr@ti.com, richard@nod.at, marek.vasut@gmail.com,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
nicolas.ferre@microchip.com, robh@kernel.org,
radu.pirea@microchip.com, devicetree
In-Reply-To: <1514313927.26695.19.camel@impinj.com>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
> Or, since this only fixes instances of DMA-unsafe buffers used in
> access to SPI NOR flash chips, and since there are other SPI master
> interface users, those chip specific fixes in some/all spi master
> drivers are still needed to fix transfers not originated via spi-nor?
SPI client drivers are *supposed* to use DMA safe memory already. How
often that happens in cases where it matters is a separate question, we
definitely have users with smaller transfers that don't do the right
thing but they're normally done using PIO anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Applied "regmap: Add one flag to indicate if a hwlock should be used" to the regmap tree
From: Mark Brown @ 2017-12-27 10:39 UTC (permalink / raw)
Cc: Mark Brown, lee.jones-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <29fa88f883dae4c1f8a3acb2656cbd7c5a539d40.1514180039.git.baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The patch
regmap: Add one flag to indicate if a hwlock should be used
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From a4887813c3a9481ab87c8a71ab1de50b975cc823 Mon Sep 17 00:00:00 2001
From: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Mon, 25 Dec 2017 14:37:09 +0800
Subject: [PATCH] regmap: Add one flag to indicate if a hwlock should be used
Since the hwlock id 0 is valid for hardware spinlock core, but now id 0
is treated as one invalid value for regmap. Thus we should add one extra
flag for regmap config to indicate if a hardware spinlock should be used,
then id 0 can be valid for regmap to request.
Signed-off-by: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/base/regmap/regmap.c | 2 +-
include/linux/regmap.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index f25ab18ca057..d23a5c99b639 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -671,7 +671,7 @@ struct regmap *__regmap_init(struct device *dev,
map->lock = config->lock;
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
- } else if (config->hwlock_id) {
+ } else if (config->use_hwlock) {
map->hwlock = hwspin_lock_request_specific(config->hwlock_id);
if (!map->hwlock) {
ret = -ENXIO;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 15eddc1353ba..c78e0057df66 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -317,6 +317,7 @@ typedef void (*regmap_unlock)(void *);
*
* @ranges: Array of configuration entries for virtual address ranges.
* @num_ranges: Number of range configuration entries.
+ * @use_hwlock: Indicate if a hardware spinlock should be used.
* @hwlock_id: Specify the hardware spinlock id.
* @hwlock_mode: The hardware spinlock mode, should be HWLOCK_IRQSTATE,
* HWLOCK_IRQ or 0.
@@ -365,6 +366,7 @@ struct regmap_config {
const struct regmap_range_cfg *ranges;
unsigned int num_ranges;
+ bool use_hwlock;
unsigned int hwlock_id;
unsigned int hwlock_mode;
};
--
2.15.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 related
* Re: [PATCH 1/2] ARM: dts: imx6: RDU2: disable internal watchdog
From: Fabio Estevam @ 2017-12-27 11:09 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel, Rob Herring, Chris Healy, Sascha Hauer,
Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Lucas Stach
In-Reply-To: <20171227035656.4941-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Andrey,
On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The system has an external watchdog in the environment processor
> so the internal watchdog is of no use.
>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: cphealy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch looks good.
Just not clear if the authorship comes from you or Lucas.
If Lucas is the original author then his name should appear in the From field.
--
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 2/2] ARM: dts: imx6: RDU2: correct RTC compatible
From: Fabio Estevam @ 2017-12-27 11:11 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel, Chris Healy, Lucas Stach
In-Reply-To: <20171227035656.4941-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Andrey,
On Wed, Dec 27, 2017 at 1:56 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> The RTC is manufactured by Maxim. This is a cosmetic fix, as Linux
> doesn't match the vendor string for i2c devices.
>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: cphealy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch seems to be from Lucas:
https://patchwork.kernel.org/patch/10099397/
,so his name should appear in the From field.
Anyway, this patch has been sent earlier and we suggested to keep the
existing binding, which is the documented form:
https://patchwork.kernel.org/patch/10099397/
--
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/2] Add efuse driver for Ingenic JZ4780 SoC
From: Mathieu Malaterre @ 2017-12-27 12:27 UTC (permalink / raw)
To: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA
Cc: Mathieu Malaterre, Srinivas Kandagatla, Rob Herring, Mark Rutland,
Ralf Baechle, PrasannaKumar Muralidharan, David S. Miller,
Greg Kroah-Hartman, Mauro Carvalho Chehab, Randy Dunlap,
Linus Walleij, Philippe Ombredanne, Paul Cercueil, Harvey Hunt,
Krzysztof Kozlowski, James Hogan,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
This patchset bring support for read-only access to the JZ4780 efuse as found
on MIPS Creator CI20.
To keep the driver as simple as possible, it was not possible to re-use most of
the nvmem core functionalities. This driver is not compatible with the original
efuse driver as found in the custom linux kernel from upstream (1), in
particular it does not expose to the users neither:
`/sys/devices/platform/*/chip_id` nor `/sys/devices/platform/*/user_id`.
The goal of this driver is to provide access to the MAC address to the dm9000
driver.
(1) https://github.com/ZubairLK/CI20_linux/commit/6efd4ffca7dcfaff0794ab60cd6922ce96c60419
Mathieu Malaterre (1):
dts: Probe efuse for CI20
PrasannaKumar Muralidharan (1):
nvmem: add driver for JZ4780 efuse
.../ABI/testing/sysfs-driver-jz4780-efuse | 16 ++
.../bindings/nvmem/ingenic,jz4780-efuse.txt | 17 ++
MAINTAINERS | 5 +
arch/mips/boot/dts/ingenic/jz4780.dtsi | 40 ++-
arch/mips/configs/ci20_defconfig | 2 +
drivers/nvmem/Kconfig | 10 +
drivers/nvmem/Makefile | 2 +
drivers/nvmem/jz4780-efuse.c | 274 +++++++++++++++++++++
8 files changed, 354 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-driver-jz4780-efuse
create mode 100644 Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
create mode 100644 drivers/nvmem/jz4780-efuse.c
--
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 1/2] nvmem: add driver for JZ4780 efuse
From: Mathieu Malaterre @ 2017-12-27 12:27 UTC (permalink / raw)
To: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA
Cc: PrasannaKumar Muralidharan, Srinivas Kandagatla, Rob Herring,
Mark Rutland, Ralf Baechle, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Randy Dunlap,
Mathieu Malaterre, Thomas Gleixner, Paul Cercueil, Linus Walleij,
Harvey Hunt, James Hogan, Krzysztof Kozlowski,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
In-Reply-To: <20171227122722.5219-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
From: PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch brings support for the JZ4780 efuse. Currently it only expose
a read only access to the entire 8K bits efuse memory.
Tested-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../ABI/testing/sysfs-driver-jz4780-efuse | 16 ++
.../bindings/nvmem/ingenic,jz4780-efuse.txt | 17 ++
MAINTAINERS | 5 +
arch/mips/boot/dts/ingenic/jz4780.dtsi | 40 ++-
drivers/nvmem/Kconfig | 10 +
drivers/nvmem/Makefile | 2 +
drivers/nvmem/jz4780-efuse.c | 274 +++++++++++++++++++++
7 files changed, 352 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-driver-jz4780-efuse
create mode 100644 Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
create mode 100644 drivers/nvmem/jz4780-efuse.c
diff --git a/Documentation/ABI/testing/sysfs-driver-jz4780-efuse b/Documentation/ABI/testing/sysfs-driver-jz4780-efuse
new file mode 100644
index 000000000000..bb6f5d6ceea0
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-jz4780-efuse
@@ -0,0 +1,16 @@
+What: /sys/devices/*/<our-device>/nvmem
+Date: December 2017
+Contact: PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: read-only access to the efuse on the Ingenic JZ4780 SoC
+ The SoC has a one time programmable 8K efuse that is
+ split into segments. The driver supports read only.
+ The segments are
+ 0x000 64 bit Random Number
+ 0x008 128 bit Ingenic Chip ID
+ 0x018 128 bit Customer ID
+ 0x028 3520 bit Reserved
+ 0x1E0 8 bit Protect Segment
+ 0x1E1 2296 bit HDMI Key
+ 0x300 2048 bit Security boot key
+Users: any user space application which wants to read the Chip
+ and Customer ID
diff --git a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
new file mode 100644
index 000000000000..cd6d67ec22fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
@@ -0,0 +1,17 @@
+Ingenic JZ EFUSE driver bindings
+
+Required properties:
+- "compatible" Must be set to "ingenic,jz4780-efuse"
+- "reg" Register location and length
+- "clocks" Handle for the ahb clock for the efuse.
+- "clock-names" Must be "bus_clk"
+
+Example:
+
+efuse: efuse@134100d0 {
+ compatible = "ingenic,jz4780-efuse";
+ reg = <0x134100D0 0xFF>;
+
+ clocks = <&cgu JZ4780_CLK_AHB2>;
+ clock-names = "bus_clk";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index a6e86e20761e..7a050c20c533 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6902,6 +6902,11 @@ M: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
S: Maintained
F: drivers/dma/dma-jz4780.c
+INGENIC JZ4780 EFUSE Driver
+M: PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+S: Maintained
+F: drivers/nvmem/jz4780-efuse.c
+
INGENIC JZ4780 NAND DRIVER
M: Harvey Hunt <harveyhuntnexus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
L: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 9b5794667aee..3fb9d916a2ea 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -224,21 +224,37 @@
reg = <0x10002000 0x100>;
};
- nemc: nemc@13410000 {
- compatible = "ingenic,jz4780-nemc";
- reg = <0x13410000 0x10000>;
- #address-cells = <2>;
+
+ ahb2: ahb2 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
#size-cells = <1>;
- ranges = <1 0 0x1b000000 0x1000000
- 2 0 0x1a000000 0x1000000
- 3 0 0x19000000 0x1000000
- 4 0 0x18000000 0x1000000
- 5 0 0x17000000 0x1000000
- 6 0 0x16000000 0x1000000>;
+ ranges = <>;
+
+ nemc: nemc@13410000 {
+ compatible = "ingenic,jz4780-nemc";
+ reg = <0x13410000 0x10000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0 0x1b000000 0x1000000
+ 2 0 0x1a000000 0x1000000
+ 3 0 0x19000000 0x1000000
+ 4 0 0x18000000 0x1000000
+ 5 0 0x17000000 0x1000000
+ 6 0 0x16000000 0x1000000>;
+
+ clocks = <&cgu JZ4780_CLK_NEMC>;
+
+ status = "disabled";
+ };
- clocks = <&cgu JZ4780_CLK_NEMC>;
+ efuse: efuse@134100d0 {
+ compatible = "ingenic,jz4780-efuse";
+ reg = <0x134100d0 0xff>;
- status = "disabled";
+ clocks = <&cgu JZ4780_CLK_AHB2>;
+ clock-names = "bus_clk";
+ };
};
bch: bch@134d0000 {
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index ff505af064ba..75400982abac 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,6 +36,16 @@ config NVMEM_IMX_OCOTP
This driver can also be built as a module. If so, the module
will be called nvmem-imx-ocotp.
+config JZ4780_EFUSE
+ tristate "JZ4780 EFUSE Memory Support"
+ depends on MACH_JZ4780 || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ Say Y here to include support for JZ4780 efuse memory found on
+ all JZ4780 SoC based devices.
+ To compile this driver as a module, choose M here: the module
+ will be called nvmem_jz4780_efuse.
+
config NVMEM_LPC18XX_EEPROM
tristate "NXP LPC18XX EEPROM Memory Support"
depends on ARCH_LPC18XX || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index e54dcfa6565a..3b7c18df6771 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -13,6 +13,8 @@ obj-$(CONFIG_NVMEM_IMX_IIM) += nvmem-imx-iim.o
nvmem-imx-iim-y := imx-iim.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
+obj-$(CONFIG_JZ4780_EFUSE) += nvmem_jz4780_efuse.o
+nvmem_jz4780_efuse-y := jz4780-efuse.o
obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
diff --git a/drivers/nvmem/jz4780-efuse.c b/drivers/nvmem/jz4780-efuse.c
new file mode 100644
index 000000000000..4860716ed25d
--- /dev/null
+++ b/drivers/nvmem/jz4780-efuse.c
@@ -0,0 +1,274 @@
+/*
+ * JZ4780 EFUSE Memory Support driver
+ *
+ * Copyright (c) 2017 PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+/*
+ * Currently supports JZ4780 efuse which has 8K programmable bit.
+ * Efuse is separated into seven segments as below:
+ *
+ * -----------------------------------------------------------------------
+ * | 64 bit | 128 bit | 128 bit | 3520 bit | 8 bit | 2296 bit | 2048 bit |
+ * -----------------------------------------------------------------------
+ *
+ * The rom itself is accessed using a 9 bit address line and an 8 word wide bus
+ * which reads/writes based on strobes. The strobe is configured in the config
+ * register and is based on number of cycles of the bus clock.
+ *
+ * Driver supports read only as the writes are done in the Factory.
+ */
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/timer.h>
+
+#define JZ_EFUCTRL (0x0) /* Control Register */
+#define JZ_EFUCFG (0x4) /* Configure Register*/
+#define JZ_EFUSTATE (0x8) /* Status Register */
+#define JZ_EFUDATA(n) (0xC + (n)*4)
+
+#define JZ_EFUSE_START_ADDR 0x200
+#define JZ_EFUSE_SEG1_OFF 0x00 /* 64 bit Random Number */
+#define JZ_EFUSE_SEG2_OFF 0x08 /* 128 bit Ingenic Chip ID */
+#define JZ_EFUSE_SEG3_OFF 0x18 /* 128 bit Customer ID */
+#define JZ_EFUSE_SEG4_OFF 0x28 /* 3520 bit Reserved */
+#define JZ_EFUSE_SEG5_OFF 0x1E0 /* 8 bit Protect Segment */
+#define JZ_EFUSE_SEG6_OFF 0x1E1 /* 2296 bit HDMI Key */
+#define JZ_EFUSE_SEG7_OFF 0x300 /* 2048 bit Security boot key */
+#define JZ_EFUSE_END_ADDR 0x5FF
+
+#define JZ_EFUSE_EFUCTRL_CS BIT(30)
+#define JZ_EFUSE_EFUCTRL_ADDR_MASK 0x1FF
+#define JZ_EFUSE_EFUCTRL_ADDR_SHIFT 21
+#define JZ_EFUSE_EFUCTRL_LEN_MASK 0x1F
+#define JZ_EFUSE_EFUCTRL_LEN_SHIFT 16
+#define JZ_EFUSE_EFUCTRL_PG_EN BIT(15)
+#define JZ_EFUSE_EFUCTRL_WR_EN BIT(1)
+#define JZ_EFUSE_EFUCTRL_RD_EN BIT(0)
+
+#define JZ_EFUSE_EFUCFG_INT_EN BIT(31)
+#define JZ_EFUSE_EFUCFG_RD_ADJ_MASK 0xF
+#define JZ_EFUSE_EFUCFG_RD_ADJ_SHIFT 20
+#define JZ_EFUSE_EFUCFG_RD_STR_MASK 0xF
+#define JZ_EFUSE_EFUCFG_RD_STR_SHIFT 16
+#define JZ_EFUSE_EFUCFG_WR_ADJ_MASK 0xF
+#define JZ_EFUSE_EFUCFG_WR_ADJ_SHIFT 12
+#define JZ_EFUSE_EFUCFG_WR_STR_MASK 0xFFF
+#define JZ_EFUSE_EFUCFG_WR_STR_SHIFT 0
+
+#define JZ_EFUSE_EFUSTATE_WR_DONE BIT(1)
+#define JZ_EFUSE_EFUSTATE_RD_DONE BIT(0)
+
+#define JZ_EFUSE_WORD_SIZE 16
+#define JZ_EFUSE_STRIDE 8
+
+struct jz4780_efuse {
+ struct device *dev;
+ void __iomem *iomem;
+ struct clk *clk;
+ unsigned int rd_adj;
+ unsigned int rd_strobe;
+};
+
+/* We read 32 byte chunks to avoid complexity in the driver. */
+static ssize_t jz4780_efuse_read_32bytes(struct jz4780_efuse *efuse, char *buf,
+ unsigned int addr)
+{
+ unsigned int tmp = 0;
+ int i = 0;
+ int timeout = 1000;
+ int size = 32;
+
+ /* 1. Set config register */
+ tmp = readl(efuse->iomem + JZ_EFUCFG);
+ tmp &= ~((JZ_EFUSE_EFUCFG_RD_ADJ_MASK << JZ_EFUSE_EFUCFG_RD_ADJ_SHIFT)
+ | (JZ_EFUSE_EFUCFG_RD_STR_MASK << JZ_EFUSE_EFUCFG_RD_STR_SHIFT));
+ tmp |= (efuse->rd_adj << JZ_EFUSE_EFUCFG_RD_ADJ_SHIFT)
+ | (efuse->rd_strobe << JZ_EFUSE_EFUCFG_RD_STR_SHIFT);
+ writel(tmp, efuse->iomem + JZ_EFUCFG);
+
+ /*
+ * 2. Set control register to indicate what to read data address,
+ * read data numbers and read enable.
+ */
+ tmp = readl(efuse->iomem + JZ_EFUCTRL);
+ tmp &= ~(JZ_EFUSE_EFUCFG_RD_STR_SHIFT
+ | (JZ_EFUSE_EFUCTRL_ADDR_MASK << JZ_EFUSE_EFUCTRL_ADDR_SHIFT)
+ | JZ_EFUSE_EFUCTRL_PG_EN | JZ_EFUSE_EFUCTRL_WR_EN
+ | JZ_EFUSE_EFUCTRL_WR_EN);
+
+ /* Need to select CS bit if address accesses upper 4Kbits memory */
+ if (addr >= (JZ_EFUSE_START_ADDR + 512))
+ tmp |= JZ_EFUSE_EFUCTRL_CS;
+
+ tmp |= (addr << JZ_EFUSE_EFUCTRL_ADDR_SHIFT)
+ | ((size - 1) << JZ_EFUSE_EFUCTRL_LEN_SHIFT)
+ | JZ_EFUSE_EFUCTRL_RD_EN;
+ writel(tmp, efuse->iomem + JZ_EFUCTRL);
+
+ /*
+ * 3. Wait status register RD_DONE set to 1 or EFUSE interrupted,
+ * software can read EFUSE data buffer 0 - 8 registers.
+ */
+ do {
+ tmp = readl(efuse->iomem + JZ_EFUSTATE);
+ usleep_range(1000, 2000);
+ if (timeout--)
+ break;
+ } while (!(tmp & JZ_EFUSE_EFUSTATE_RD_DONE));
+
+ if (timeout <= 0) {
+ dev_err(efuse->dev, "Timed out while reading\n");
+ return -EAGAIN;
+ }
+
+ for (i = 0; i < (size / 4); i++)
+ *((unsigned int *)(buf + i * 4))
+ = readl(efuse->iomem + JZ_EFUDATA(i));
+
+ return 0;
+}
+
+static unsigned int segments[][2] = {
+ /* offset , size in bits */
+ { JZ_EFUSE_SEG1_OFF, 64 }, /* bit Random Number */
+ { JZ_EFUSE_SEG2_OFF, 128 }, /* bit Ingenic Chip ID */
+ { JZ_EFUSE_SEG3_OFF, 128 }, /* bit Customer ID */
+ { JZ_EFUSE_SEG4_OFF, 3520 }, /* bit Reserved */
+ { JZ_EFUSE_SEG5_OFF, 8 }, /* bit Protect Segment */
+ { JZ_EFUSE_SEG6_OFF, 2296 }, /* bit HDMI Key */
+ { JZ_EFUSE_SEG7_OFF, 2048 } /* bit Security boot key */
+};
+
+/* main entry point */
+static int jz4780_efuse_read(void *context, unsigned int offset,
+ void *val, size_t bytes)
+{
+ static const int nsegments = sizeof(segments) / sizeof(*segments);
+ struct jz4780_efuse *efuse = context;
+ char buf[32];
+ char *cur = val;
+ int i;
+ /* PM recommends read/write each segment separately */
+ for (i = 0; i < nsegments; ++i) {
+ unsigned int *segment = segments[i];
+ unsigned int lpos = segment[0];
+ unsigned int buflen = segment[1] / 8;
+ unsigned int ncount = buflen / 32;
+ unsigned int remain = buflen % 32;
+ int j;
+ /* EFUSE can read or write maximum 256bit in each time */
+ for (j = 0; j < ncount ; ++j) {
+ jz4780_efuse_read_32bytes(efuse, buf, lpos);
+ memcpy(cur, buf, sizeof(buf));
+ cur += sizeof(buf);
+ lpos += sizeof(buf);
+ }
+ if (remain) {
+ jz4780_efuse_read_32bytes(efuse, buf, lpos);
+ memcpy(cur, buf, remain);
+ cur += remain;
+ }
+ }
+
+ return 0;
+}
+
+static struct nvmem_config jz4780_efuse_nvmem_config = {
+ .name = "jz4780-efuse",
+ .read_only = true,
+ .word_size = JZ_EFUSE_WORD_SIZE,
+ .stride = JZ_EFUSE_STRIDE,
+ .owner = THIS_MODULE,
+ .reg_read = jz4780_efuse_read,
+};
+
+static int jz4780_efuse_probe(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem;
+ struct jz4780_efuse *efuse;
+ struct resource *res;
+ unsigned long clk_rate;
+ struct device *dev = &pdev->dev;
+
+ efuse = devm_kzalloc(&pdev->dev, sizeof(*efuse), GFP_KERNEL);
+ if (!efuse)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ efuse->iomem = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (IS_ERR(efuse->iomem))
+ return PTR_ERR(efuse->iomem);
+
+ efuse->clk = devm_clk_get(&pdev->dev, "bus_clk");
+ if (IS_ERR(efuse->clk))
+ return PTR_ERR(efuse->clk);
+
+ clk_rate = clk_get_rate(efuse->clk);
+ /*
+ * rd_adj and rd_strobe are 4 bit values
+ * bus clk period * (rd_adj + 1) > 6.5ns
+ * bus clk period * (rd_adj + 5 + rd_strobe) > 35ns
+ */
+ efuse->rd_adj = (((6500 * (clk_rate / 1000000)) / 1000000) + 1) - 1;
+ efuse->rd_strobe = ((((35000 * (clk_rate / 1000000)) / 1000000) + 1)
+ - 5 - efuse->rd_adj);
+
+ if ((efuse->rd_adj > 0x1F) || (efuse->rd_strobe > 0x1F)) {
+ dev_err(&pdev->dev, "Cannot set clock configuration\n");
+ return -EINVAL;
+ }
+ efuse->dev = dev;
+
+ jz4780_efuse_nvmem_config.size = 1024;
+ jz4780_efuse_nvmem_config.dev = &pdev->dev;
+ jz4780_efuse_nvmem_config.priv = efuse;
+
+ nvmem = nvmem_register(&jz4780_efuse_nvmem_config);
+ if (IS_ERR(nvmem))
+ return PTR_ERR(nvmem);
+
+ platform_set_drvdata(pdev, nvmem);
+
+ return 0;
+}
+
+static int jz4780_efuse_remove(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+ return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id jz4780_efuse_match[] = {
+ { .compatible = "ingenic,jz4780-efuse" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, jz4780_efuse_match);
+
+static struct platform_driver jz4780_efuse_driver = {
+ .probe = jz4780_efuse_probe,
+ .remove = jz4780_efuse_remove,
+ .driver = {
+ .name = "jz4780-efuse",
+ .of_match_table = jz4780_efuse_match,
+ },
+};
+module_platform_driver(jz4780_efuse_driver);
+
+MODULE_AUTHOR("PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
+MODULE_DESCRIPTION("Ingenic JZ4780 efuse driver");
+MODULE_LICENSE("GPL v2");
--
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 related
* [PATCH 2/2] dts: Probe efuse for CI20
From: Mathieu Malaterre @ 2017-12-27 12:27 UTC (permalink / raw)
To: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA
Cc: Mathieu Malaterre, Srinivas Kandagatla, Rob Herring, Mark Rutland,
Ralf Baechle, PrasannaKumar Muralidharan, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Randy Dunlap,
Philippe Ombredanne, Kate Stewart, Thomas Gleixner, Paul Cercueil,
Harvey Hunt, Krzysztof Kozlowski, James Hogan,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171227122722.5219-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
---
arch/mips/configs/ci20_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index b5f4ad8f2c45..62c63617e97a 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -171,3 +171,5 @@ CONFIG_STACKTRACE=y
# CONFIG_FTRACE is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused"
+CONFIG_NVMEM=y
+CONFIG_JZ4780_EFUSE=y
--
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 related
* Re: [PATCH 2/2] dts: Probe efuse for CI20
From: Greg Kroah-Hartman @ 2017-12-27 12:46 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA, Srinivas Kandagatla,
Rob Herring, Mark Rutland, Ralf Baechle,
PrasannaKumar Muralidharan, David S. Miller,
Mauro Carvalho Chehab, Randy Dunlap, Philippe Ombredanne,
Kate Stewart, Thomas Gleixner, Paul Cercueil, Harvey Hunt,
Krzysztof Kozlowski, James Hogan,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mips-6z/3iImG2C8G8FEW9MqTrA
In-Reply-To: <20171227122722.5219-3-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Wed, Dec 27, 2017 at 01:27:02PM +0100, Mathieu Malaterre wrote:
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
I know i can't take patches without any changelog text at all, and
really, you shouldn't ever create such a thing :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 0/5] eeprom: at24: device tree support fixes
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
The first three patches fix certain issues with the DT binding
document.
The last two extend the device tree support in the driver with more
at24 EEPROM variants.
v1 -> v2:
- remove any implementation details from patch 1/5
v2 -> v3:
- reword patch 1/5: allow any "<manufacturer>,<vendor>" pair as long
as a supported fallback is used
Bartosz Golaszewski (5):
dt-bindings: at24: consistently document the compatible property
dt-bindings: at24: add a missing compatible
dt-bindings: at24: fix formatting and style
dt-bindings: at24: extend the list of supported chips
eeprom: at24: extend the list of chips supported in DT
Documentation/devicetree/bindings/eeprom/at24.txt | 71 ++++++++++++-----------
drivers/misc/eeprom/at24.c | 9 +++
2 files changed, 46 insertions(+), 34 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: at24: consistently document the compatible property
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171227135054.29690-1-brgl@bgdev.pl>
Current description of the compatible property for at24 is quite vague.
State explicitly that any "<manufacturer>,<model>" pair is accepted as
long as one of the listed strings is used as fallback.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 37 +++++++++--------------
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index cbc80e194ac6..b5ce5a247554 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -2,28 +2,21 @@ EEPROMs (I2C)
Required properties:
- - compatible : should be "<manufacturer>,<type>", like these:
-
- "atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
- "atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
- "atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"
-
- "catalyst,24c32"
-
- "microchip,24c128"
-
- "ramtron,24c64"
-
- "renesas,r1ex24002"
-
- The following manufacturers values have been deprecated:
- "at", "at24"
-
- If there is no specific driver for <manufacturer>, a generic
- device with <type> and manufacturer "atmel" should be used.
- Possible types are:
- "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
- "24c128", "24c256", "24c512", "24c1024", "spd"
+ - compatible: must be a "<manufacturer>,<model>" pair with one of the
+ following values as fallback:
+
+ "atmel,24c00",
+ "atmel,24c01",
+ "atmel,24c02",
+ "atmel,24c04",
+ "atmel,24c08",
+ "atmel,24c16",
+ "atmel,24c32",
+ "atmel,24c64",
+ "atmel,24c128",
+ "atmel,24c256",
+ "atmel,24c512",
+ "atmel,24c1024"
- reg : the I2C address of the EEPROM
--
2.15.1
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: at24: add a missing compatible
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171227135054.29690-1-brgl@bgdev.pl>
"atmel,spd" is reported by checkpatch as undocumented in the device
tree bindings. Add it to the list of supported compatible fallbacks.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index b5ce5a247554..487e1005036c 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -8,6 +8,7 @@ Required properties:
"atmel,24c00",
"atmel,24c01",
"atmel,24c02",
+ "atmel,spd",
"atmel,24c04",
"atmel,24c08",
"atmel,24c16",
--
2.15.1
^ permalink raw reply related
* [PATCH v3 3/5] dt-bindings: at24: fix formatting and style
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bartosz Golaszewski
In-Reply-To: <20171227135054.29690-1-brgl-ARrdPY/1zhM@public.gmane.org>
Make formatting and style consistent for the entire document.
This patch doesn't change the content of the binding.
Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
Reviewed-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 24 +++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index 487e1005036c..7d4dc264b3cc 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -2,7 +2,7 @@ EEPROMs (I2C)
Required properties:
- - compatible: must be a "<manufacturer>,<model>" pair with one of the
+ - compatible: Must be a "<manufacturer>,<model>" pair with one of the
following values as fallback:
"atmel,24c00",
@@ -19,23 +19,23 @@ Required properties:
"atmel,24c512",
"atmel,24c1024"
- - reg : the I2C address of the EEPROM
+ - reg: The I2C address of the EEPROM.
Optional properties:
- - pagesize : the length of the pagesize for writing. Please consult the
- manual of your device, that value varies a lot. A wrong value
- may result in data loss! If not specified, a safety value of
- '1' is used which will be very slow.
+ - pagesize: The length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
- - read-only: this parameterless property disables writes to the eeprom
+ - read-only: This parameterless property disables writes to the eeprom.
- - size: total eeprom size in bytes
+ - size: Total eeprom size in bytes.
- - no-read-rollover:
- This parameterless property indicates that the multi-address
- eeprom does not automatically roll over reads to the next
- slave address. Please consult the manual of your device.
+ - no-read-rollover: This parameterless property indicates that the
+ multi-address eeprom does not automatically roll over
+ reads to the next slave address. Please consult the
+ manual of your device.
- wp-gpios: GPIO to which the write-protect pin of the chip is connected.
--
2.15.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 v3 4/5] dt-bindings: at24: extend the list of supported chips
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171227135054.29690-1-brgl@bgdev.pl>
Add other variants of at24 EEPROMs we support in the driver to the
list of allowed compatible fallbacks.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index 7d4dc264b3cc..7b01fa020ae4 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -7,13 +7,22 @@ Required properties:
"atmel,24c00",
"atmel,24c01",
+ "atmel,24cs01",
"atmel,24c02",
+ "atmel,24cs02",
+ "atmel,24mac402",
+ "atmel,24mac602",
"atmel,spd",
"atmel,24c04",
+ "atmel,24cs04",
"atmel,24c08",
+ "atmel,24cs08",
"atmel,24c16",
+ "atmel,24cs16",
"atmel,24c32",
+ "atmel,24cs32",
"atmel,24c64",
+ "atmel,24cs64",
"atmel,24c128",
"atmel,24c256",
"atmel,24c512",
--
2.15.1
^ permalink raw reply related
* [PATCH v3 5/5] eeprom: at24: extend the list of chips supported in DT
From: Bartosz Golaszewski @ 2017-12-27 13:50 UTC (permalink / raw)
To: Andy Shevchenko, Rob Herring, Mark Rutland,
Javier Martinez Canillas, David Lechner, Divagar Mohandass,
Peter Rosin
Cc: linux-i2c, devicetree, linux-kernel, Bartosz Golaszewski
In-Reply-To: <20171227135054.29690-1-brgl@bgdev.pl>
Add all supported at24 variants to the of_match table.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/misc/eeprom/at24.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index e79833d62284..01f9c4921c50 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -209,13 +209,22 @@ MODULE_DEVICE_TABLE(i2c, at24_ids);
static const struct of_device_id at24_of_match[] = {
{ .compatible = "atmel,24c00", .data = &at24_data_24c00 },
{ .compatible = "atmel,24c01", .data = &at24_data_24c01 },
+ { .compatible = "atmel,24cs01", .data = &at24_data_24cs01 },
{ .compatible = "atmel,24c02", .data = &at24_data_24c02 },
+ { .compatible = "atmel,24cs02", .data = &at24_data_24cs02 },
+ { .compatible = "atmel,24mac402", .data = &at24_data_24mac402 },
+ { .compatible = "atmel,24mac602", .data = &at24_data_24mac602 },
{ .compatible = "atmel,spd", .data = &at24_data_spd },
{ .compatible = "atmel,24c04", .data = &at24_data_24c04 },
+ { .compatible = "atmel,24cs04", .data = &at24_data_24cs04 },
{ .compatible = "atmel,24c08", .data = &at24_data_24c08 },
+ { .compatible = "atmel,24cs08", .data = &at24_data_24cs08 },
{ .compatible = "atmel,24c16", .data = &at24_data_24c16 },
+ { .compatible = "atmel,24cs16", .data = &at24_data_24cs16 },
{ .compatible = "atmel,24c32", .data = &at24_data_24c32 },
+ { .compatible = "atmel,24cs32", .data = &at24_data_24cs32 },
{ .compatible = "atmel,24c64", .data = &at24_data_24c64 },
+ { .compatible = "atmel,24cs64", .data = &at24_data_24cs64 },
{ .compatible = "atmel,24c128", .data = &at24_data_24c128 },
{ .compatible = "atmel,24c256", .data = &at24_data_24c256 },
{ .compatible = "atmel,24c512", .data = &at24_data_24c512 },
--
2.15.1
^ permalink raw reply related
* RE: [PATCH v2 1/2] dt-bindings: Document mti,mips-cpc binding
From: Aleksandar Markovic @ 2017-12-27 13:56 UTC (permalink / raw)
To: Rob Herring, Aleksandar Markovic
Cc: linux-mips@linux-mips.org, Paul Burton,
devicetree@vger.kernel.org, Douglas Leung, Goran Ferenc,
James Hogan, linux-kernel@vger.kernel.org, Mark Rutland,
Miodrag Dinic, Petar Jovanovic, Raghu Gandham
In-Reply-To: <20171226214810.su23px4ue7q5t3xg@rob-hp-laptop>
Hi, Rob.
Thanks for the review.
> From: Rob Herring [robh@kernel.org]
> Sent: Tuesday, December 26, 2017 10:48 PM
> To: Aleksandar Markovic
> > On Thu, Dec 21, 2017 at 04:20:23PM +0100, Aleksandar Markovic wrote:
> > From: Paul Burton <paul.burton@mips.com>
> >
> > Document a binding for the MIPS Cluster Power Controller (CPC) which
> > simply allows the device tree to specify where the CPC registers are
> > located.
> >
> > Signed-off-by: Paul Burton <paul.burton@mips.com>
> > Signed-off-by: Aleksandar Markovic <aleksandar.markovic@mips.com>
> > ---
> > Documentation/devicetree/bindings/misc/mti,mips-cpc.txt | 8 ++++++++
>
> power controllers are usually documented under bindings/power/
I am going to change the file location to Documentation/devicetree/bindings/power
in v3, unless someone objects.
Regards,
Aleksandar
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: Document mti,mips-cpc binding
From: Aleksandar Markovic @ 2017-12-27 14:37 UTC (permalink / raw)
To: linux-mips-6z/3iImG2C8G8FEW9MqTrA
Cc: Paul Burton, Aleksandar Markovic,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Leung, Goran Ferenc,
James Hogan, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Miodrag Dinic, Petar Jovanovic, Raghu Gandham, Rob Herring
In-Reply-To: <1514385475-23921-1-git-send-email-aleksandar.markovic-FblTVreYubkAvxtiuMwx3w@public.gmane.org>
From: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>
Document a binding for the MIPS Cluster Power Controller (CPC) that
allows the device tree to specify where the CPC registers are located.
Signed-off-by: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic-8NJIiSa5LzA@public.gmane.org>
---
Documentation/devicetree/bindings/power/mti,mips-cpc.txt | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/mti,mips-cpc.txt
diff --git a/Documentation/devicetree/bindings/power/mti,mips-cpc.txt b/Documentation/devicetree/bindings/power/mti,mips-cpc.txt
new file mode 100644
index 0000000..c6b8251
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mti,mips-cpc.txt
@@ -0,0 +1,8 @@
+Binding for MIPS Cluster Power Controller (CPC).
+
+This binding allows a system to specify where the CPC registers are
+located.
+
+Required properties:
+compatible : Should be "mti,mips-cpc".
+regs: Should describe the address & size of the CPC register region.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] Input: mms114 - drop platform data and use generic APIs
From: Simon Shields @ 2017-12-27 15:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andi Shyti, linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171226032511.17726-1-simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
On Tue, Dec 26, 2017 at 02:25:11PM +1100, Simon Shields wrote:
> The MMS114 platform data has no in-tree users, so drop it,
> and make the driver depend on CONFIG_OF.
>
> Switch to using the standard touchscreen properties via
> touchscreen_parse_properties(), and move the old DT parsing code
> to use device_property_*() APIs.
>
> Finally, use touchscreen_report_pos to report x/y coordinates
> and drop the custom x/y inversion code.
>
> Signed-off-by: Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
> ---
> .../bindings/input/touchscreen/mms114.txt | 29 ++--
> drivers/input/touchscreen/Kconfig | 1 +
> drivers/input/touchscreen/mms114.c | 146 +++++++++------------
> include/linux/platform_data/mms114.h | 24 ----
> 4 files changed, 77 insertions(+), 123 deletions(-)
> delete mode 100644 include/linux/platform_data/mms114.h
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
> index 89d4c56c5671..8f9f9f38eff4 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
> @@ -4,14 +4,18 @@ Required properties:
> - compatible: must be "melfas,mms114"
> - reg: I2C address of the chip
> - interrupts: interrupt to which the chip is connected
> -- x-size: horizontal resolution of touchscreen
> -- y-size: vertical resolution of touchscreen
> +- touchscreen-size-x: See [1]
> +- touchscreen-size-y: See [1]
>
> Optional properties:
> -- contact-threshold:
> -- moving-threshold:
> -- x-invert: invert X axis
> -- y-invert: invert Y axis
> +- touchscreen-fuzz-x: See [1]
> +- touchscreen-fuzz-y: See [1]
> +- touchscreen-fuzz-pressure: See [1]
> +- touchscreen-inverted-x: See [1]
> +- touchscreen-inverted-y: See [1]
> +- touchscreen-swapped-x-y: See [1]
> +
> +[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>
> Example:
>
> @@ -22,12 +26,13 @@ Example:
> compatible = "melfas,mms114";
> reg = <0x48>;
> interrupts = <39 0>;
> - x-size = <720>;
> - y-size = <1280>;
> - contact-threshold = <10>;
> - moving-threshold = <10>;
> - x-invert;
> - y-invert;
> + touchscreen-size-x = <720>;
> + touchscreen-size-y = <1280>;
> + touchscreen-fuzz-x = <10>;
> + touchscreen-fuzz-y = <10>;
> + touchscreen-fuzz-pressure = <10>;
> + touchscreen-inverted-x;
> + touchscreen-inverted-y;
> };
>
> /* ... */
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index 38a226f9fcbd..f7ea5522ef91 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -524,6 +524,7 @@ config TOUCHSCREEN_MCS5000
> config TOUCHSCREEN_MMS114
> tristate "MELFAS MMS114 touchscreen"
> depends on I2C
> + depends on OF
> help
> Say Y here if you have the MELFAS MMS114 touchscreen controller
> chip in your system.
> diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
> index e5eeb6311f7d..2ca22faa10aa 100644
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -12,8 +12,8 @@
> #include <linux/of.h>
> #include <linux/i2c.h>
> #include <linux/input/mt.h>
> +#include <linux/input/touchscreen.h>
> #include <linux/interrupt.h>
> -#include <linux/platform_data/mms114.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
>
> @@ -55,7 +55,9 @@ struct mms114_data {
> struct input_dev *input_dev;
> struct regulator *core_reg;
> struct regulator *io_reg;
> - const struct mms114_platform_data *pdata;
> + struct touchscreen_properties props;
> + unsigned int contact_threshold;
> + unsigned int moving_threshold;
>
> /* Use cache data for mode control register(write only) */
> u8 cache_mode_control;
> @@ -143,7 +145,6 @@ static int mms114_write_reg(struct mms114_data *data, unsigned int reg,
>
> static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *touch)
> {
> - const struct mms114_platform_data *pdata = data->pdata;
> struct i2c_client *client = data->client;
> struct input_dev *input_dev = data->input_dev;
> unsigned int id;
> @@ -163,16 +164,6 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
> id = touch->id - 1;
> x = touch->x_lo | touch->x_hi << 8;
> y = touch->y_lo | touch->y_hi << 8;
> - if (x > pdata->x_size || y > pdata->y_size) {
> - dev_dbg(&client->dev,
> - "Wrong touch coordinates (%d, %d)\n", x, y);
> - return;
> - }
> -
> - if (pdata->x_invert)
> - x = pdata->x_size - x;
> - if (pdata->y_invert)
> - y = pdata->y_size - y;
>
> dev_dbg(&client->dev,
> "id: %d, type: %d, pressed: %d, x: %d, y: %d, width: %d, strength: %d\n",
> @@ -183,9 +174,8 @@ static void mms114_process_mt(struct mms114_data *data, struct mms114_touch *tou
> input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, touch->pressed);
>
> if (touch->pressed) {
> + touchscreen_report_pos(input_dev, &data->props, x, y, true);
> input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, touch->width);
> - input_report_abs(input_dev, ABS_MT_POSITION_X, x);
> - input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
> input_report_abs(input_dev, ABS_MT_PRESSURE, touch->strength);
> }
> }
> @@ -263,7 +253,7 @@ static int mms114_get_version(struct mms114_data *data)
>
> static int mms114_setup_regs(struct mms114_data *data)
> {
> - const struct mms114_platform_data *pdata = data->pdata;
> + const struct touchscreen_properties *props = &data->props;
> int val;
> int error;
>
> @@ -275,32 +265,32 @@ static int mms114_setup_regs(struct mms114_data *data)
> if (error < 0)
> return error;
>
> - val = (pdata->x_size >> 8) & 0xf;
> - val |= ((pdata->y_size >> 8) & 0xf) << 4;
> + val = (props->max_x >> 8) & 0xf;
> + val |= ((props->max_y >> 8) & 0xf) << 4;
> error = mms114_write_reg(data, MMS114_XY_RESOLUTION_H, val);
> if (error < 0)
> return error;
>
> - val = pdata->x_size & 0xff;
> + val = props->max_x & 0xff;
> error = mms114_write_reg(data, MMS114_X_RESOLUTION, val);
> if (error < 0)
> return error;
>
> - val = pdata->y_size & 0xff;
> + val = props->max_x & 0xff;
> error = mms114_write_reg(data, MMS114_Y_RESOLUTION, val);
> if (error < 0)
> return error;
>
> - if (pdata->contact_threshold) {
> + if (data->contact_threshold) {
> error = mms114_write_reg(data, MMS114_CONTACT_THRESHOLD,
> - pdata->contact_threshold);
> + data->contact_threshold);
> if (error < 0)
> return error;
> }
>
> - if (pdata->moving_threshold) {
> + if (data->moving_threshold) {
> error = mms114_write_reg(data, MMS114_MOVING_THRESHOLD,
> - pdata->moving_threshold);
> + data->moving_threshold);
> if (error < 0)
> return error;
> }
> @@ -335,9 +325,6 @@ static int mms114_start(struct mms114_data *data)
> return error;
> }
>
> - if (data->pdata->cfg_pin)
> - data->pdata->cfg_pin(true);
> -
> enable_irq(client->irq);
>
> return 0;
> @@ -350,9 +337,6 @@ static void mms114_stop(struct mms114_data *data)
>
> disable_irq(client->irq);
>
> - if (data->pdata->cfg_pin)
> - data->pdata->cfg_pin(false);
> -
> error = regulator_disable(data->io_reg);
> if (error)
> dev_warn(&client->dev, "Failed to disable vdd: %d\n", error);
> @@ -376,67 +360,43 @@ static void mms114_input_close(struct input_dev *dev)
> mms114_stop(data);
> }
>
> -#ifdef CONFIG_OF
> -static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
> +static int mms114_parse_dt(struct mms114_data *data)
> {
> - struct mms114_platform_data *pdata;
> - struct device_node *np = dev->of_node;
> -
> - if (!np)
> - return NULL;
> + struct device *dev = &data->client->dev;
> + struct touchscreen_properties *props = &data->props;
>
> - pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata) {
> - dev_err(dev, "failed to allocate platform data\n");
> - return NULL;
> + if (device_property_read_u32(dev, "x-size", &props->max_x)) {
> + dev_dbg(dev, "failed to get legacy x-size property\n");
> + return -EINVAL;
> }
>
> - if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
> - dev_err(dev, "failed to get x-size property\n");
> - return NULL;
> + if (device_property_read_u32(dev, "y-size", &props->max_y)) {
> + dev_dbg(dev, "failed to get legacy y-size property\n");
> + return -EINVAL;
> }
>
> - if (of_property_read_u32(np, "y-size", &pdata->y_size)) {
> - dev_err(dev, "failed to get y-size property\n");
> - return NULL;
> - }
> + device_property_read_u32(dev, "contact-threshold",
> + &data->contact_threshold);
> + device_property_read_u32(dev, "moving-threshold",
> + &data->moving_threshold);
>
> - of_property_read_u32(np, "contact-threshold",
> - &pdata->contact_threshold);
> - of_property_read_u32(np, "moving-threshold",
> - &pdata->moving_threshold);
> + if (device_property_read_bool(dev, "x-invert"))
> + props->invert_x = true;
> + if (device_property_read_bool(dev, "y-invert"))
> + props->invert_y = true;
>
> - if (of_find_property(np, "x-invert", NULL))
> - pdata->x_invert = true;
> - if (of_find_property(np, "y-invert", NULL))
> - pdata->y_invert = true;
> + props->swap_x_y = false;
>
> - return pdata;
> -}
> -#else
> -static inline struct mms114_platform_data *mms114_parse_dt(struct device *dev)
> -{
> - return NULL;
> + return 0;
> }
> -#endif
>
> static int mms114_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - const struct mms114_platform_data *pdata;
> struct mms114_data *data;
> struct input_dev *input_dev;
> int error;
>
> - pdata = dev_get_platdata(&client->dev);
> - if (!pdata)
> - pdata = mms114_parse_dt(&client->dev);
> -
> - if (!pdata) {
> - dev_err(&client->dev, "Need platform data\n");
> - return -EINVAL;
> - }
> -
> if (!i2c_check_functionality(client->adapter,
> I2C_FUNC_PROTOCOL_MANGLING)) {
> dev_err(&client->dev,
> @@ -453,8 +413,33 @@ static int mms114_probe(struct i2c_client *client,
> }
>
> data->client = client;
> +
> + input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
> + input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_X);
> + input_set_capability(input_dev, EV_ABS, ABS_MT_POSITION_Y);
> + input_set_capability(input_dev, EV_ABS, ABS_MT_PRESSURE);
> + input_set_capability(input_dev, EV_ABS, ABS_MT_TOUCH_MAJOR);
> +
> + input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 255, 0, 0);
> +
> + if (mms114_parse_dt(data) < 0) {
> + /* No valid legacy binding found, try the common one */
> + touchscreen_parse_properties(input_dev, true, &data->props);
> +
> + /* The firmware handles movement and pressure fuzz, so
> + * don't duplicate that in software.
> + */
> + data->moving_threshold =
> + input_dev->absinfo[ABS_MT_POSITION_X].fuzz;
> + data->contact_threshold =
> + input_dev->absinfo[ABS_MT_PRESSURE].fuzz;
> +
> + input_dev->absinfo[ABS_MT_POSITION_X].fuzz = 0;
> + input_dev->absinfo[ABS_MT_POSITION_Y].fuzz = 0;
> + input_dev->absinfo[ABS_MT_PRESSURE].fuzz = 0;
> + }
> +
> data->input_dev = input_dev;
> - data->pdata = pdata;
>
> input_dev->name = "MELFAS MMS114 Touchscreen";
> input_dev->id.bustype = BUS_I2C;
> @@ -462,21 +447,10 @@ static int mms114_probe(struct i2c_client *client,
> input_dev->open = mms114_input_open;
> input_dev->close = mms114_input_close;
>
> - __set_bit(EV_ABS, input_dev->evbit);
> - __set_bit(EV_KEY, input_dev->evbit);
> - __set_bit(BTN_TOUCH, input_dev->keybit);
> - input_set_abs_params(input_dev, ABS_X, 0, data->pdata->x_size, 0, 0);
> - input_set_abs_params(input_dev, ABS_Y, 0, data->pdata->y_size, 0, 0);
> -
> /* For multi touch */
> input_mt_init_slots(input_dev, MMS114_MAX_TOUCH, 0);
> input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR,
> 0, MMS114_MAX_AREA, 0, 0);
> - input_set_abs_params(input_dev, ABS_MT_POSITION_X,
> - 0, data->pdata->x_size, 0, 0);
> - input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
> - 0, data->pdata->y_size, 0, 0);
This shouldn't be dropped, it's needed for compatability with the old DTS. I
will send a v2 shortly.
> - input_set_abs_params(input_dev, ABS_MT_PRESSURE, 0, 255, 0, 0);
>
> input_set_drvdata(input_dev, data);
> i2c_set_clientdata(client, data);
> @@ -567,13 +541,11 @@ static const struct i2c_device_id mms114_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, mms114_id);
>
> -#ifdef CONFIG_OF
> static const struct of_device_id mms114_dt_match[] = {
> { .compatible = "melfas,mms114" },
> { }
> };
> MODULE_DEVICE_TABLE(of, mms114_dt_match);
> -#endif
>
> static struct i2c_driver mms114_driver = {
> .driver = {
> diff --git a/include/linux/platform_data/mms114.h b/include/linux/platform_data/mms114.h
> deleted file mode 100644
> index 5722ebfb2738..000000000000
> --- a/include/linux/platform_data/mms114.h
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/*
> - * Copyright (C) 2012 Samsung Electronics Co.Ltd
> - * Author: Joonyoung Shim <jy0922.shim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundationr
> - */
> -
> -#ifndef __LINUX_MMS114_H
> -#define __LINUX_MMS114_H
> -
> -struct mms114_platform_data {
> - unsigned int x_size;
> - unsigned int y_size;
> - unsigned int contact_threshold;
> - unsigned int moving_threshold;
> - bool x_invert;
> - bool y_invert;
> -
> - void (*cfg_pin)(bool);
> -};
> -
> -#endif /* __LINUX_MMS114_H */
> --
> 2.15.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
* Re: [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-27 15:07 UTC (permalink / raw)
To: Corentin Labbe
Cc: Maxime Ripard, wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171215061046.GA9845@Red>
Hello Corentin,
Le Fri, 15 Dec 2017 07:10:46 +0100,
Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> a écrit :
> On Tue, Dec 12, 2017 at 09:24:25AM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:
> > > On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:
> > > > This series adds SMP support for Allwinner Sun8i-a83t
> > > > with MCPM (Multi-Cluster Power Management).
> > > > Series information:
> > > > - Based on last linux-next (next-20171211)
> > > > - Had dependencies on Chen Yu's patch that add MCPM
> > > > support:
> > > > https://patchwork.kernel.org/patch/6402801/
> > > >
> > > > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > > > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > > > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > > > for MCPM.
> > > > Patch 03: Add CCI-400 node for a83t.
> > > > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > > > case of SMP support.
> > >
> > > As we discussed in private, Chen Yu's patch should be added in your series.
> >
> > Not really, she mentionned the dependency in the cover letter, and
> > it's a good way to do things too. Sure, you can do it your way, but
> > there's no preference.
> >
>
> If the goal of this series is to be applied, the dependency must be applied also.
> And since the dependency is 2 years old (and part of a serie which does not apply now), I think cherry picking the patch and send it for review is better.
>
> > > Furthermore, MCPM is not automaticaly selected via imply.
> >
> > Well, yes, is that an issue?
> >
>
> After reading the imply documentation, no.
>
> > > With all patchs I hit a bug:
> > > [ 0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
> >
> > I guess this is with CONFIG_PROVE_LOCKING enabled?
> >
>
> No, the BUG() printed is enabled by default
>
> > > [ 0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> > > [ 0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> >
> > What are the changes you've made?
> >
>
> Just adding wens's patch and this series.
I tried to reproduce your issue without success (even with
CONFIG_PROVE_LOCKING enabled, just in case).
Can you give me more details about your tests? which defconfig and
additional configurations?
>
> > > [ 0.925418] Hardware name: Allwinner sun8i Family
> > > [ 0.930118] Backtrace:
> > > [ 0.932596] [<c010cc50>] (dump_backtrace) from [<c010cf0c>] (show_stack+0x18/0x1c)
> > > [ 0.940158] r7:c0b261e4 r6:60000013 r5:00000000 r4:c0b51958
> > > [ 0.945820] [<c010cef4>] (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0)
> > > [ 0.953045] [<c06bac40>] (dump_stack) from [<c0149d40>] (___might_sleep+0x150/0x170)
> > > [ 0.960779] r7:c0b261e4 r6:00000000 r5:000000ee r4:ee844000
> > > [ 0.966437] [<c0149bf0>] (___might_sleep) from [<c0149dc8>] (__might_sleep+0x68/0xa0)
> > > [ 0.974253] r4:c0861690
> > > [ 0.976796] [<c0149d60>] (__might_sleep) from [<c06d2918>] (mutex_lock+0x24/0x68)
> > > [ 0.984269] r6:c0892f6c r5:ffffffff r4:c0b1bb24
> > > [ 0.988891] [<c06d28f4>] (mutex_lock) from [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4)
> > > [ 0.996795] r5:ffffffff r4:ee98b014
> > > [ 1.000375] [<c01ccb48>] (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> > > [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000
> > > [ 1.016447] r4:ee98b010
> > > [ 1.018989] [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> > > [ 1.027158] r10:00000000 r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> > > [ 1.034974] r4:eea19010
> > > [ 1.037511] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> > > [ 1.046371] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea19010
> > > [ 1.052026] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> > > [ 1.061062] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> > > [ 1.068879] r4:c0b2610c r3:00000000
> > > [ 1.072454] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> > > [ 1.081228] r7:00000001 r6:c045cb24 r5:ee845ac0 r4:00000000
> > > [ 1.086883] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> > > [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010
> > > [ 1.099750] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> > > [ 1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> > > [ 1.113919] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> > > [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> > > [ 1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> > > [ 1.136089] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> > > [ 1.143564] r10:00000000 r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> > > [ 1.151380] r4:eea19000
> > > [ 1.153915] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> > > [ 1.163210] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> > > [ 1.173372] r9:00000000 r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> > > [ 1.181107] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> > > [ 1.190229] r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000 r5:eedf1d04
> > > [ 1.198045] r4:eedf2154
> > > [ 1.200580] [<c0583300>] (of_platform_populate) from [<c03ef2a8>] (cci_platform_probe+0x3c/0x54)
> > > [ 1.209356] r10:00000000 r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> > > [ 1.217172] r4:eea18a00
> > > [ 1.219708] [<c03ef26c>] (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> > > [ 1.228306] r5:ffffffed r4:eea18a10
> > > [ 1.231881] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> > > [ 1.240742] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea18a10
> > > [ 1.246397] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> > > [ 1.255433] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> > > [ 1.263250] r4:c0b26168 r3:00000000
> > > [ 1.266825] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> > > [ 1.275598] r7:00000001 r6:c045cb24 r5:ee845ce8 r4:00000000
> > > [ 1.281253] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> > > [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10
> > > [ 1.294120] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> > > [ 1.302633] r7:c0b0a4c8 r6:c0b3e848 r5:eea18a10 r4:eea18a18
> > > [ 1.308288] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> > > [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> > > [ 1.324796] r7:c0b0a4c8 r6:eea18a10 r5:ee993810 r4:eea18a18
> > > [ 1.330450] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> > > [ 1.337926] r10:00000000 r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> > > [ 1.345743] r4:eea18a00
> > > [ 1.348277] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> > > [ 1.357572] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> > > [ 1.367734] r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> > > [ 1.375469] [<c058300c>] (of_platform_bus_create) from [<c058315c>] (of_platform_bus_create+0x150/0x1f0)
> > > [ 1.384938] r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedefe1c
> > > [ 1.392754] r4:eedf1d04
> > > [ 1.395289] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> > > [ 1.404411] r10:00000001 r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> > > [ 1.412228] r4:eedefe1c
> > > [ 1.414769] [<c0583300>] (of_platform_populate) from [<c0a25ee8>] (of_platform_default_populate_init+0x80/0x94)
> > > [ 1.424844] r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000 r5:c0775ce8
> > > [ 1.432661] r4:00000000
> > > [ 1.435200] [<c0a25e68>] (of_platform_default_populate_init) from [<c0102794>] (do_one_initcall+0x5c/0x194)
> > > [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> > > [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>] (kernel_init_freeable+0x1d4/0x268)
> > > [ 1.457195] r9:00000004 r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> > > [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>] (kernel_init+0x10/0x118)
> > > [ 1.473187] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0
> > > [ 1.481004] r4:00000000
> > > [ 1.483540] [<c06cf3a0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> > > [ 1.491098] Exception stack(0xee845fb0 to 0xee845ff8)
> > > [ 1.496146] 5fa0: 00000000 00000000 00000000 00000000
> > > [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > > [ 1.512480] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > > [ 1.519084] r5:c06cf3a0 r4:00000000
> > > [ 1.522737] ARM CCI_400_r1 PMU driver probed
> > >
> > > And only CPU 0 show up.
> >
> > This looks more like a bug in the CCI code, and not in this serie
> > itself. Can you share your whole boot logs?
> >
>
> This week end I will retry and send it.
By any chance, did you try it again? Can you reproduce it on your side?
Thank you in advance,
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [RFC PATCH v11 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
From: Tony Lindgren @ 2017-12-27 15:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: JeffyChen, linux-kernel, bhelgaas, linux-pm, shawn.lin,
briannorris, dianders, devicetree, linux-pci, Rob Herring,
Frank Rowand
In-Reply-To: <5491520.JsEYlZiECc@aspire.rjw.lan>
* Rafael J. Wysocki <rjw@rjwysocki.net> [171227 01:00]:
> On Tuesday, December 26, 2017 2:06:47 AM CET JeffyChen wrote:
> > Hi Rafael,
> >
> > Thanks for your reply :)
> >
> > On 12/26/2017 08:11 AM, Rafael J. Wysocki wrote:
> > >> >+
> > >> >+ dn = pci_device_to_OF_node(ppdev);
> > >> >+ if (!dn)
> > >> >+ return 0;
> > >> >+
> > >> >+ irq = of_irq_get_byname(dn, "wakeup");
> > > Why is this a property of the bridge and not of the device itself?
> >
> > That is suggested by Brian, because in that way, the wakeup pin would
> > not "tied to what exact device is installed (or no device, if it's a slot)."
>
> But I don't think it works when there are two devices using different WAKE#
> interrupt lines under the same bridge. Or how does it work then?
It won't work currently for multiple devices but adding more than
one wakeriq per device is doable. And I think we will have other
cases where multiple wakeirqs are connected to a single device, so
that issue should be sorted out sooner or later.
And if requesting wakeirq for the PCI WAKE# lines at the PCI
controller does the job, then maybe that's all we need to start with.
Then in addition to that, we could do the following to allow
PCI devices to request the wakeirq from the PCI controller:
1. PCI controller or framework implements a chained irq for
the WAKE# lines assuming it can mask/unmask the WAKE# lines
2. PCI devices then can just request the wakeirq from the PCI
controller
And that's about it. Optionally we could leave out the dependency
to having PCI devices implement PM runtime and just resume the
parent (PCI controller) if PCI devices has not implemented
PM runtime.
> > >> >+ if (irq == -EPROBE_DEFER)
> > > Braces here, please.
> > ok, will fix in the next version.
> >
> > >
> > >> >+ return irq;
> > >> >+ /* Ignore other errors, since a missing wakeup is non-fatal. */
> > >> >+ else if (irq < 0) {
> > >> >+ dev_info(&pdev->dev, "cannot get wakeup interrupt: %d\n", irq);
> > >> >+ return 0;
> > >> >+ }
> > >> >+
> > >> >+ device_init_wakeup(&pdev->dev, true);
> > > Why do you call this before dev_pm_set_dedicated_wake_irq()?
> >
> > hmmm, i thought so too, but it turns out the dedicated wake irq
> > framework requires device_init_wakeup(dev, true) before attach the wake irq:
> >
> > int device_wakeup_attach_irq(struct device *dev,
> > struct wake_irq *wakeirq)
> > {
> > struct wakeup_source *ws;
> >
> > ws = dev->power.wakeup;
> > if (!ws) {
> > dev_err(dev, "forgot to call device_init_wakeup?\n");
> > return -EINVAL;
> >
>
> Well, that's a framework issue, fair enough.
>
> That said, what if user space removes the wakeup source from under you
> concurrently via sysfs? Tony?
Hmm sounds racy, need to take a look. I think the only reason
to have the wakeirq pointer there was to save memory. It might
make sense to remove the wakeirq dependency here.
Regards,
Tony
^ permalink raw reply
* Re: [RFC PATCH v12 4/5] PCI / PM: Add support for the PCIe WAKE# signal for OF
From: Rob Herring @ 2017-12-27 15:30 UTC (permalink / raw)
To: JeffyChen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Bjorn Helgaas, linux-pm-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
Shawn Lin, Brian Norris, Rafael J. Wysocki, Doug Anderson,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Frank Rowand, Andy Shevchenko
In-Reply-To: <5A42F847.5060305-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Tue, Dec 26, 2017 at 7:32 PM, JeffyChen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for your reply.
>
> On 12/27/2017 07:56 AM, Rob Herring wrote:
>>>
>>> >
>>> > drivers/of/of_pci_irq.c | 49 +++++++++++++++++++++++++++++++
>>
>> Please move this to drivers/pci/of.c (or perhaps create pci/of_irq.c).
>>
>>> > drivers/pci/Makefile | 1 +
>>> > drivers/pci/pci-driver.c | 10 +++++++
>>> > drivers/pci/pci-of.c | 75
>>> > ++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> We already have drivers/pci/of.c. It's not clear what the difference is
>> from the filenames. Either merge with of.c or perhaps of-pm.c.
>
>
> this new file does something similar to the pci-acpi.c and pci-mid.c..
pci-acpi.c has similar things to pci/of.c. The naming is just not consistent.
Also, I plan to move the rest of drivers/of/of_pci* to drivers/pci.
> and i am agree the naming is not clear, maybe we can rename both of those
> files to something like pci-pm-***.c?
At least pci-acpi.c is more than just PM functions, so that doesn't
make sense. Given that all the ACPI related functions are in 1 file,
we should do the same for DT.
>
> Hi Rafael, do you think this would make sense?
>
>
[...]
>>> >+static int __init of_pci_init(void)
>>> >+{
>>> >+ if (!acpi_disabled)
>>> >+ return 0;
>>> >+
>>> >+ pci_set_platform_pm(&of_pci_platform_pm);
>>
>> I guess no DT based system will override this?
>
>
> i think the !acpi_disabled means acpi been disabled or CONFIG_ACPI is
> undefined.
>
> and pci-acpi.c would only work when we have CONFIG_ACPI.
>
> but i have no idea about pci-mid.c or would it possible to have more
> platform pm ops in the future...maybe we should add some dependency in the
> Kconfig?
It's probably fine given there are only 2 other implementations so far.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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