* [PATCH v2 0/6] Updated lp8860 led driver
From: Dan Murphy @ 2017-12-05 20:43 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
All
v2 - Added an initial patch to bring the DT binding up to standard prior to adding
the changes for the label and triggers.
v1 Cover letter repeat below
After creating a new LED driver for the LM3692x device I went back to the
LP8860 driver that I authored and found some updates that need to be applied.
First the way the LP8860 retrieved the label from the DT was incorrect as the
label should have been from a child node as opposed to the parent. This is now
fixed with this series.
Second, since that device can be used to as either a backlight driver or as a
string agnostic driver a trigger to the backlight needed to be added.
Finally there are changes to the driver that need to be made as either
unnoticed bugs or updates to the driver to align with the current LED
framework. For instance moving to the devm LED class registration, destroying
the mutex upon driver removal and removing the in driver dependency on CONFIG_OF
and moving it to the Kconfig.
With these changes this should at least bring the driver into a better shape.
There are additional changes coming for this driver but I wanted to get the
driver up to snuff before adding a feature to it.
Dan
Dan Murphy (6):
dt: bindings: lp8860: Update bindings for lp8860
dt: bindings: lp8860: Update DT label binding
leds: lp8860: Update the dt parsing for LED labeling
dt: bindings: lp8860: Add trigger binding to the lp8860
leds: lp8860: Add DT parsing to retrieve the trigger node
leds: lp8860: Various fixes to align with LED framework
.../devicetree/bindings/leds/leds-lp8860.txt | 39 ++++++++++++++-------
drivers/leds/Kconfig | 2 +-
drivers/leds/leds-lp8860.c | 40 ++++++++++++----------
3 files changed, 49 insertions(+), 32 deletions(-)
--
2.15.0.124.g7668cbc60
^ permalink raw reply
* Re: [PATCH] dt-bindings: mtd: fsl-quadspi: Pass the qspi clock names
From: Cyrille Pitchen @ 2017-12-05 20:11 UTC (permalink / raw)
To: Rob Herring, Fabio Estevam
Cc: boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Fabio Estevam
In-Reply-To: <20171204223624.gd3iiha3qyr7nwxg@rob-hp-laptop>
Le 04/12/2017 à 23:36, Rob Herring a écrit :
> On Sun, Dec 03, 2017 at 08:36:24PM -0200, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>>
>> In order to improve the bindings documentation, explicitly pass the name
>> of the clocks: "qspi_en" and "qspi", which are mandatory.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
Applied to the spi-nor/next branch of l2-mtd
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: binding: Update endianness usage
From: Scott Wood @ 2017-12-05 20:07 UTC (permalink / raw)
To: Prabhakar Kushwaha,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <HE1PR04MB1241ADD02E472BA492AE1C8F973D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> > Sent: Tuesday, December 05, 2017 8:16 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>; linux-
> > mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> >
> > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > binding that says the *parent* of a CFI node should be looked at for this?
> > Where in general are endian properties kept in the parent of the node with
> > "reg"? The right answer is to add endianness to mtd-physmap.txt.
> >
>
> Flashes are always littler endian.
We wouldn't be having this discussion if that were true... This is about how
it presents to the CPU, not about how the actual pins on the chip are
numbered.
> It is because of IFC controller behavior, endianness is required.
> So as per my understanding, this info should go in IFC binding.
If the info should go in the IFC binding why is the code in a non-IFC-specific
place?
-Scott
--
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 V3 2/7] PCI: Export pci_find_host_bridge()
From: Bjorn Helgaas @ 2017-12-05 20:04 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: cyndis-/1wQRMveznE, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, lorenzo.pieralisi-5wv7dgnIgG8,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ, vidyas-DDmLM1+adcrQT0dZR+AlfA,
kthota-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512120007-28088-3-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Fri, Dec 01, 2017 at 02:50:02PM +0530, Manikanta Maddireddy wrote:
> PCI subsystem pass pci_bus pointer to pci_ops callback functions, Tegra
s/PCI subsystem pass/The PCI subsystem passes a/
s/, Tegra/. The Tegra/
> host driver use pci_find_host_bridge() to get pci_host_bridge from pci_bus.
s/use/uses/
> Export pci_find_host_bridge() to allow Tegra PCIe driver to be compiled as
> loadable kernel module.
s/allow Tegra/allow the Tegra/
s/loadable/a loadable/
But why do you need pci_find_host_bridge() at all? Most drivers use
the pci_bus.sysdata pointer for this purpose, e.g., see db271747a04d
("PCI: mediatek: Use bus->sysdata to get host private data")
> Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> V2:
> * commit message update
> V3:
> * EXPORT_SYMBOL is changed to EXPORT_SYMBOL_GPL
>
> drivers/pci/host-bridge.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> index add66236215c..b8c0fcde9bd7 100644
> --- a/drivers/pci/host-bridge.c
> +++ b/drivers/pci/host-bridge.c
> @@ -22,6 +22,7 @@ struct pci_host_bridge *pci_find_host_bridge(struct pci_bus *bus)
>
> return to_pci_host_bridge(root_bus->bridge);
> }
> +EXPORT_SYMBOL_GPL(pci_find_host_bridge);
>
> struct device *pci_get_host_bridge_device(struct pci_dev *dev)
> {
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH] dt: bindings: as3645a: Fix the example node
From: Dan Murphy @ 2017-12-05 20:03 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I,
sakari.ailus-X3B1VOXEql0
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171205133637.30022-1-dmurphy-l0cyMroinI0@public.gmane.org>
+Sakari driver maintainer
On 12/05/2017 07:36 AM, Dan Murphy wrote:
> Fix the address-cells and size-cells example node
> to reflect to the correct representation.
>
> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> index fdc40e354a64..8a49ccfec29b 100644
> --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> @@ -59,8 +59,8 @@ Example
> =======
>
> as3645a@30 {
> - #address-cells: 1
> - #size-cells: 0
> + #address-cells = <1>;
> + #size-cells = <0>;
> reg = <0x30>;
> compatible = "ams,as3645a";
> flash@0 {
>
--
------------------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] phylib: add reset after clk enable support
From: Richard Leitner @ 2017-12-05 18:08 UTC (permalink / raw)
To: Andrew Lunn, Richard Leitner
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
fugang.duan-3arQi8VN3Tc, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
baruch-NswTu9S1W3P6gbPvEgmw2w, david.wu-TNX95d0MmH7DzftRWevZcw,
lukma-ynQEQJNshbs, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171205173407.GN12805-g2DYL2Zd6BY@public.gmane.org>
Hi Andrew,
On 12/05/2017 06:34 PM, Andrew Lunn wrote:
> On Tue, Dec 05, 2017 at 02:25:58PM +0100, Richard Leitner wrote:
>> From: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>>
>> Some PHYs need the refclk to be a continuous clock. Therefore they don't
>> allow turning it off and on again during operation. Nonetheless such a
>> clock switching is performed by some ETH drivers (namely FEC [1]) for
>> power saving reasons. An example for an affected PHY is the
>> SMSC/Microchip LAN8720 in "REF_CLK In Mode".
>>
>> In order to provide a uniform method to overcome this problem this patch
>> adds a new phy_driver flag (PHY_RST_AFTER_CLK_EN) and corresponding
>> function phy_reset_after_clk_enable() to the phylib. These should be
>> used to trigger reset of the PHY after the refclk is switched on again.
>>
>> This patch depends on the "phylib: Add device reset GPIO support" patch
>> submitted by Geert Uytterhoeven/Sergei Shtylyov [2].
>>
>> [1] commit e8fcfcd5684a ("net: fec: optimize the clock management to save power")
>> [2] https://patchwork.kernel.org/patch/10090149/
>>
>> Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>
> Hi Richard
>
> Same comment about moving text below the ---
Ok. Thanks for your feedback and review.
>
> Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>
regards;Richard.L
> Andrew
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] phylib: Add device reset delay support
From: Richard Leitner @ 2017-12-05 18:06 UTC (permalink / raw)
To: Andrew Lunn, Richard Leitner
Cc: robh+dt, mark.rutland, fugang.duan, f.fainelli, frowand.list,
davem, geert+renesas, sergei.shtylyov, baruch, david.wu, lukma,
netdev, devicetree, linux-kernel
In-Reply-To: <20171205172852.GM12805@lunn.ch>
Hi Andrew,
On 12/05/2017 06:28 PM, Andrew Lunn wrote:
> Hi Richard
>
>> +++ b/drivers/of/of_mdio.c
>> @@ -77,6 +77,14 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
>> if (of_property_read_bool(child, "broken-turn-around"))
>> mdio->phy_ignore_ta_mask |= 1 << addr;
>>
>> + if (of_property_read_u32(child, "reset-delay-us",
>> + &phy->mdio.reset_delay))
>> + phy->mdio.reset_delay = 0;
>> +
>> + if (of_property_read_u32(child, "reset-post-delay-us",
>> + &phy->mdio.reset_post_delay))
>> + phy->mdio.reset_post_delay = 0;
>
> of_property_read_u32() should not change the variable you pass to it,
> if it does not find the property. So you can change this to:
>
> phy->mdio.reset_delay = 0;
> phy->mdio.reset_post_delay = 0;
>
> of_property_read_u32(child, "reset-delay-us",
> &phy->mdio.reset_delay);
>
> of_property_read_u32(child, "reset-post-delay-us",
> &phy->mdio.reset_post_delay);
Geert already pointed this out, but he said it's possible to omit also
the zeroing of the variables.
> On 12/05/2017 02:54 PM, Geert Uytterhoeven wrote:
>> If of_property_read_u32() fails, it doesn't write to its output
>> parameter.
>> As the structure should be zeroed during allocation, you can just
>> write:
>>
>> of_property_read_u32(child, "reset-delay-us",&phy->mdio.reset_delay);
>> of_property_read_u32(child, "reset-post-delay-us",
>> &phy->mdio.reset_post_delay);
If that's ok I'll take the shorter (Geerts) suggestion for v4.
Nonetheless thanks for your quick feedback!
regards;Richard.L
^ permalink raw reply
* Re: [PATCH v4 0/4] Teach phylib hard-resetting devices
From: David Miller @ 2017-12-05 17:51 UTC (permalink / raw)
To: geert+renesas
Cc: andrew, f.fainelli, horms, magnus.damm, sergei.shtylyov, robh+dt,
mark.rutland, nicolas.ferre, richard.leitner, netdev, devicetree,
linux-renesas-soc, linux-kernel
In-Reply-To: <1512383692-14009-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon, 4 Dec 2017 11:34:48 +0100
> This patch series adds optional PHY reset support to phylib.
Patch #1 and #2 applied to net-next, using v4.1 of patch #1.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 3/4] net: phy: smsc: LAN8710/20: add PHY_RST_AFTER_CLK_EN flag
From: Andrew Lunn @ 2017-12-05 17:35 UTC (permalink / raw)
To: Richard Leitner
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
fugang.duan-3arQi8VN3Tc, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
baruch-NswTu9S1W3P6gbPvEgmw2w, david.wu-TNX95d0MmH7DzftRWevZcw,
lukma-ynQEQJNshbs, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
richard.leitner-WcANXNA0UjBBDgjK7y7TUQ
In-Reply-To: <20171205132600.13796-4-dev-M/VWbR8SM2SsTnJN9+BGXg@public.gmane.org>
On Tue, Dec 05, 2017 at 02:25:59PM +0100, Richard Leitner wrote:
> From: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>
> The Microchip/SMSC LAN8710/LAN8720 PHYs need (according to their
> datasheet [1]) a continuous REF_CLK when configured to "REF_CLK In Mode".
> Therefore set the PHY_RST_AFTER_CLK_EN flag for those PHYs to let the
> ETH driver reset them after the REF_CLK is enabled.
>
> [1] http://ww1.microchip.com/downloads/en/DeviceDoc/00002165B.pdf
>
> Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] phylib: add reset after clk enable support
From: Andrew Lunn @ 2017-12-05 17:34 UTC (permalink / raw)
To: Richard Leitner
Cc: robh+dt, mark.rutland, fugang.duan, f.fainelli, frowand.list,
davem, geert+renesas, sergei.shtylyov, baruch, david.wu, lukma,
netdev, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20171205132600.13796-3-dev@g0hl1n.net>
On Tue, Dec 05, 2017 at 02:25:58PM +0100, Richard Leitner wrote:
> From: Richard Leitner <richard.leitner@skidata.com>
>
> Some PHYs need the refclk to be a continuous clock. Therefore they don't
> allow turning it off and on again during operation. Nonetheless such a
> clock switching is performed by some ETH drivers (namely FEC [1]) for
> power saving reasons. An example for an affected PHY is the
> SMSC/Microchip LAN8720 in "REF_CLK In Mode".
>
> In order to provide a uniform method to overcome this problem this patch
> adds a new phy_driver flag (PHY_RST_AFTER_CLK_EN) and corresponding
> function phy_reset_after_clk_enable() to the phylib. These should be
> used to trigger reset of the PHY after the refclk is switched on again.
>
> This patch depends on the "phylib: Add device reset GPIO support" patch
> submitted by Geert Uytterhoeven/Sergei Shtylyov [2].
>
> [1] commit e8fcfcd5684a ("net: fec: optimize the clock management to save power")
> [2] https://patchwork.kernel.org/patch/10090149/
>
> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Hi Richard
Same comment about moving text below the ---
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] phylib: Add device reset delay support
From: Andrew Lunn @ 2017-12-05 17:28 UTC (permalink / raw)
To: Richard Leitner
Cc: robh+dt, mark.rutland, fugang.duan, f.fainelli, frowand.list,
davem, geert+renesas, sergei.shtylyov, baruch, david.wu, lukma,
netdev, devicetree, linux-kernel, richard.leitner
In-Reply-To: <20171205132600.13796-2-dev@g0hl1n.net>
Hi Richard
> +++ b/drivers/of/of_mdio.c
> @@ -77,6 +77,14 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
> if (of_property_read_bool(child, "broken-turn-around"))
> mdio->phy_ignore_ta_mask |= 1 << addr;
>
> + if (of_property_read_u32(child, "reset-delay-us",
> + &phy->mdio.reset_delay))
> + phy->mdio.reset_delay = 0;
> +
> + if (of_property_read_u32(child, "reset-post-delay-us",
> + &phy->mdio.reset_post_delay))
> + phy->mdio.reset_post_delay = 0;
of_property_read_u32() should not change the variable you pass to it,
if it does not find the property. So you can change this to:
phy->mdio.reset_delay = 0;
phy->mdio.reset_post_delay = 0;
of_property_read_u32(child, "reset-delay-us",
&phy->mdio.reset_delay);
of_property_read_u32(child, "reset-post-delay-us",
&phy->mdio.reset_post_delay);
Andrew
^ permalink raw reply
* Re: [PATCH v11 6/6] clk: qcom: Add APCS clock controller support
From: Bjorn Andersson @ 2017-12-05 17:21 UTC (permalink / raw)
To: Georgi Djakov
Cc: sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w,
mturquette-rdvid1DuHRBWk0Htik3J/w, robh-DgEjT+Ai2ygdnm+yROfE0A,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171205154701.27730-7-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue 05 Dec 07:47 PST 2017, Georgi Djakov wrote:
> Add a driver for the APCS clock controller. It is part of the APCS
> hardware block, which among other things implements also a combined
> mux and half integer divider functionality. It can choose between a
> fixed-rate clock or the dedicated APCS (A53) PLL. The source and the
> divider can be set both at the same time.
>
> This is required for enabling CPU frequency scaling on MSM8916-based
> platforms.
>
Acked-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Regards,
Bjorn
> Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/clk/qcom/Kconfig | 11 +++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/apcs-msm8916.c | 149 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 161 insertions(+)
> create mode 100644 drivers/clk/qcom/apcs-msm8916.c
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 81ac7b9378fe..255023b439c9 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -22,6 +22,17 @@ config QCOM_A53PLL
> Say Y if you want to support higher CPU frequencies on MSM8916
> devices.
>
> +config QCOM_CLK_APCS_MSM8916
> + bool "MSM8916 APCS Clock Controller"
> + depends on COMMON_CLK_QCOM
> + depends on QCOM_APCS_IPC
> + default ARCH_QCOM
> + help
> + Support for the APCS Clock Controller on msm8916 devices. The
> + APCS is managing the mux and divider which feeds the CPUs.
> + Say Y if you want to support CPU frequency scaling on devices
> + such as msm8916.
> +
> config QCOM_CLK_RPM
> tristate "RPM based Clock Controller"
> depends on COMMON_CLK_QCOM && MFD_QCOM_RPM
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 7c51d877f967..0408cebf38d4 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -34,5 +34,6 @@ obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
> obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
> obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
> obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
> +obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> diff --git a/drivers/clk/qcom/apcs-msm8916.c b/drivers/clk/qcom/apcs-msm8916.c
> new file mode 100644
> index 000000000000..832172c2fc8b
> --- /dev/null
> +++ b/drivers/clk/qcom/apcs-msm8916.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Qualcomm APCS clock controller driver
> + *
> + * Copyright (c) 2017, Linaro Limited
> + * Author: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include "clk-regmap.h"
> +#include "clk-regmap-mux-div.h"
> +
> +enum {
> + P_GPLL0,
> + P_A53PLL,
> +};
> +
> +static const struct parent_map gpll0_a53cc_map[] = {
> + { P_GPLL0, 4 },
> + { P_A53PLL, 5 },
> +};
> +
> +static const char * const gpll0_a53cc[] = {
> + "gpll0_vote",
> + "a53pll",
> +};
> +
> +/*
> + * We use the notifier function for switching to a temporary safe configuration
> + * (mux and divider), while the A53 PLL is reconfigured.
> + */
> +static int a53cc_notifier_cb(struct notifier_block *nb, unsigned long event,
> + void *data)
> +{
> + int ret = 0;
> + struct clk_regmap_mux_div *md = container_of(nb,
> + struct clk_regmap_mux_div,
> + clk_nb);
> + if (event == PRE_RATE_CHANGE)
> + /* set the mux and divider to safe frequency (400mhz) */
> + ret = __mux_div_set_src_div(md, 4, 3);
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static int qcom_apcs_msm8916_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device *parent = dev->parent;
> + struct clk_regmap_mux_div *a53cc;
> + struct regmap *regmap;
> + struct clk_init_data init = { };
> + int ret;
> +
> + regmap = dev_get_regmap(parent, NULL);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "failed to get regmap: %d\n", ret);
> + return ret;
> + }
> +
> + a53cc = devm_kzalloc(dev, sizeof(*a53cc), GFP_KERNEL);
> + if (!a53cc)
> + return -ENOMEM;
> +
> + init.name = "a53mux";
> + init.parent_names = gpll0_a53cc;
> + init.num_parents = ARRAY_SIZE(gpll0_a53cc);
> + init.ops = &clk_regmap_mux_div_ops;
> + init.flags = CLK_SET_RATE_PARENT;
> +
> + a53cc->clkr.hw.init = &init;
> + a53cc->clkr.regmap = regmap;
> + a53cc->reg_offset = 0x50;
> + a53cc->hid_width = 5;
> + a53cc->hid_shift = 0;
> + a53cc->src_width = 3;
> + a53cc->src_shift = 8;
> + a53cc->parent_map = gpll0_a53cc_map;
> +
> + a53cc->pclk = devm_clk_get(parent, NULL);
> + if (IS_ERR(a53cc->pclk)) {
> + ret = PTR_ERR(a53cc->pclk);
> + dev_err(dev, "failed to get clk: %d\n", ret);
> + return ret;
> + }
> +
> + a53cc->clk_nb.notifier_call = a53cc_notifier_cb;
> + ret = clk_notifier_register(a53cc->pclk, &a53cc->clk_nb);
> + if (ret) {
> + dev_err(dev, "failed to register clock notifier: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_clk_register_regmap(dev, &a53cc->clkr);
> + if (ret) {
> + dev_err(dev, "failed to register regmap clock: %d\n", ret);
> + goto err;
> + }
> +
> + ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> + &a53cc->clkr.hw);
> + if (ret) {
> + dev_err(dev, "failed to add clock provider: %d\n", ret);
> + goto err;
> + }
> +
> + platform_set_drvdata(pdev, a53cc);
> +
> + return 0;
> +
> +err:
> + clk_notifier_unregister(a53cc->pclk, &a53cc->clk_nb);
> + return ret;
> +}
> +
> +static int qcom_apcs_msm8916_clk_remove(struct platform_device *pdev)
> +{
> + struct clk_regmap_mux_div *a53cc = platform_get_drvdata(pdev);
> + struct device *parent = pdev->dev.parent;
> +
> + clk_notifier_unregister(a53cc->pclk, &a53cc->clk_nb);
> + of_clk_del_provider(parent->of_node);
> +
> + return 0;
> +}
> +
> +static struct platform_driver qcom_apcs_msm8916_clk_driver = {
> + .probe = qcom_apcs_msm8916_clk_probe,
> + .remove = qcom_apcs_msm8916_clk_remove,
> + .driver = {
> + .name = "qcom-apcs-msm8916-clk",
> + },
> +};
> +module_platform_driver(qcom_apcs_msm8916_clk_driver);
> +
> +MODULE_AUTHOR("Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Qualcomm MSM8916 APCS clock driver");
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Sinan Kaya @ 2017-12-05 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Vinod Koul,
Mark Rutland, open list
In-Reply-To: <20171204221414.f5tphhn7gvlle3li@rob-hp-laptop>
On 12/4/2017 5:14 PM, Rob Herring wrote:
> Hopefully 1.2 corresponds to some actual version numbering and not just
> something you made up. I'd really rather have SoC based compatible
> strings unless you have dozens of SoCs for each version. I'll probably
> just say the same thing again when 1.3 or 2.0 gets added...
>
No, these are coming from the HW. They are user visible.
[ 107.167207] hidma-mgmt QCOM8060:00: HW rev: 1.2 @ 0x0000ffff8b800000 with 6 physical channels
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] of: dynamic: restrict overlay by targets
From: Alan Tull @ 2017-12-05 17:07 UTC (permalink / raw)
To: Frank Rowand
Cc: Moritz Fischer, Rob Herring, Pantelis Antoniou,
devicetree@vger.kernel.org, linux-kernel, linux-fpga
In-Reply-To: <edb604fa-4810-0de9-ce51-c90aa2442cb4@gmail.com>
On Mon, Dec 4, 2017 at 7:14 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Alan,
>
> In the RFC thread "of: Add whitelist", I did not understand the use case and
> asked you some questions (30 Nov 2017 07:46:36 -0500), that you seem to have
> overlooked (or my mail server failed to deliver your answer to me). Can you
> please answer that question so I can better understand this patch set is
> needed for.
Hi Frank,
Sorry I missed those, I've replied to the original questions now.
Alan
>
> Thanks,
>
> Frank
>
>
> On 12/04/17 14:13, Alan Tull wrote:
>> Restrict which nodes are valid targets for a DT overlay.
>>
>> Add a flag bit to struct device_node allowing nodes to be marked as
>> valid target for overlays.
>>
>> A driver that is always intended to handle DT overlays can
>> enable overlays by calling a function for its DT node.
>>
>> For individual nodes that need to be opened up for a specific use,
>> adding the property "overlay-allowed" enables overlays targeting
>> that node. I'll need to document the DT property, not sure where
>> specifically. New file bindings/overlay.txt?
>>
>> This patchset differs from the RFC:
>> * Added a flag bit and got rid of the whitelist
>> * Renamed the functions that enable a node
>> * Added a DT property
>>
>> Alan Tull (2):
>> of: overlay: add flag enabling overlays and enable fpga-region
>> overlays
>> of: dynamic: add overlay-allowed DT property
>>
>> drivers/fpga/of-fpga-region.c | 4 ++++
>> drivers/of/base.c | 4 ++--
>> drivers/of/dynamic.c | 3 +++
>> drivers/of/fdt.c | 3 +++
>> drivers/of/of_private.h | 2 ++
>> drivers/of/overlay.c | 26 ++++++++++++++++++++++++++
>> include/linux/of.h | 19 +++++++++++++++++++
>> 7 files changed, 59 insertions(+), 2 deletions(-)
>>
>
^ permalink raw reply
* [PATCH V6 7/7] dmaengine: qcom_hidma: Add identity register support
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Andy Gross,
David Brown, Dan Williams, Vinod Koul,
open list:ARM/QUALCOMM SUPPORT, open list
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
The location for destination event channel register has been relocated from
offset 0x28 to 0x40. Update the code accordingly.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c146c6d..963cc52 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -107,6 +107,7 @@ static void hidma_free(struct hidma_dev *dmadev)
enum hidma_cap {
HIDMA_MSI_CAP = 1,
+ HIDMA_IDENTITY_CAP,
};
/* process completed descriptors */
@@ -838,7 +839,10 @@ static int hidma_probe(struct platform_device *pdev)
if (!dmadev->nr_descriptors)
dmadev->nr_descriptors = HIDMA_NR_DEFAULT_DESC;
- dmadev->chidx = readl(dmadev->dev_trca + 0x28);
+ if (hidma_test_capability(&pdev->dev, HIDMA_IDENTITY_CAP))
+ dmadev->chidx = readl(dmadev->dev_trca + 0x40);
+ else
+ dmadev->chidx = readl(dmadev->dev_trca + 0x28);
/* Set DMA mask to 64 bits. */
rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
@@ -944,7 +948,7 @@ static int hidma_remove(struct platform_device *pdev)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
{"QCOM8062", HIDMA_MSI_CAP},
- {"QCOM8063", HIDMA_MSI_CAP},
+ {"QCOM8063", (HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP)},
{},
};
MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -953,7 +957,8 @@ static int hidma_remove(struct platform_device *pdev)
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
- {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
+ {.compatible = "qcom,hidma-1.2",
+ .data = (void *)(HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP),},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 6/7] dmaengine: qcom_hidma: Add support for the new revision
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Andy Gross,
David Brown, Dan Williams, Vinod Koul,
open list:ARM/QUALCOMM SUPPORT, open list
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
Add support for probing the newer HW and also organize MSI capable hardware
into an array for maintenance reasons.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e366985..c146c6d 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -50,6 +50,7 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/of_dma.h>
+#include <linux/of_device.h>
#include <linux/property.h>
#include <linux/delay.h>
#include <linux/acpi.h>
@@ -104,6 +105,9 @@ static void hidma_free(struct hidma_dev *dmadev)
module_param(nr_desc_prm, uint, 0644);
MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+enum hidma_cap {
+ HIDMA_MSI_CAP = 1,
+};
/* process completed descriptors */
static void hidma_process_completed(struct hidma_chan *mchan)
@@ -736,25 +740,12 @@ static int hidma_request_msi(struct hidma_dev *dmadev,
#endif
}
-static bool hidma_msi_capable(struct device *dev)
+static bool hidma_test_capability(struct device *dev, enum hidma_cap test_cap)
{
- struct acpi_device *adev = ACPI_COMPANION(dev);
- const char *of_compat;
- int ret = -EINVAL;
-
- if (!adev || acpi_disabled) {
- ret = device_property_read_string(dev, "compatible",
- &of_compat);
- if (ret)
- return false;
+ enum hidma_cap cap;
- ret = strcmp(of_compat, "qcom,hidma-1.1");
- } else {
-#ifdef CONFIG_ACPI
- ret = strcmp(acpi_device_hid(adev), "QCOM8062");
-#endif
- }
- return ret == 0;
+ cap = (enum hidma_cap) device_get_match_data(dev);
+ return cap ? ((cap & test_cap) > 0) : 0;
}
static int hidma_probe(struct platform_device *pdev)
@@ -834,8 +825,7 @@ static int hidma_probe(struct platform_device *pdev)
* Determine the MSI capability of the platform. Old HW doesn't
* support MSI.
*/
- msi = hidma_msi_capable(&pdev->dev);
-
+ msi = hidma_test_capability(&pdev->dev, HIDMA_MSI_CAP);
device_property_read_u32(&pdev->dev, "desc-count",
&dmadev->nr_descriptors);
@@ -953,7 +943,8 @@ static int hidma_remove(struct platform_device *pdev)
#if IS_ENABLED(CONFIG_ACPI)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
- {"QCOM8062"},
+ {"QCOM8062", HIDMA_MSI_CAP},
+ {"QCOM8063", HIDMA_MSI_CAP},
{},
};
MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -961,7 +952,8 @@ static int hidma_remove(struct platform_device *pdev)
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
- {.compatible = "qcom,hidma-1.1",},
+ {.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
+ {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 5/7] ACPI: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Rafael J. Wysocki,
Len Brown, open list
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
Now that we have a get_match_data() callback as part of the firmware node,
implement the ACPI specific piece for it.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/property.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index e26ea20..38b599b 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1271,6 +1271,12 @@ static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return 0;
}
+static void *acpi_fwnode_get_match_data(const struct fwnode_handle *fwnode,
+ struct device *dev)
+{
+ return acpi_get_match_data(dev);
+}
+
#define DECLARE_ACPI_FWNODE_OPS(ops) \
const struct fwnode_operations ops = { \
.device_is_available = acpi_fwnode_device_is_available, \
@@ -1289,6 +1295,7 @@ static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
acpi_fwnode_graph_get_remote_endpoint, \
.graph_get_port_parent = acpi_fwnode_get_parent, \
.graph_parse_endpoint = acpi_fwnode_graph_parse_endpoint, \
+ .get_match_data = acpi_fwnode_get_match_data, \
}; \
EXPORT_SYMBOL_GPL(ops)
--
1.9.1
^ permalink raw reply related
* [PATCH V6 4/7] OF: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, open list, Sinan Kaya, Rob Herring, Frank Rowand,
linux-arm-kernel
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
Now that we have a get_match_data() callback as part of the firmware node,
implement the OF specific piece for it.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/of/property.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 264c355..9964169 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -981,6 +981,12 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return 0;
}
+void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
+ struct device *dev)
+{
+ return (void *)of_device_get_match_data(dev);
+}
+
const struct fwnode_operations of_fwnode_ops = {
.get = of_fwnode_get,
.put = of_fwnode_put,
@@ -996,5 +1002,6 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
.graph_get_remote_endpoint = of_fwnode_graph_get_remote_endpoint,
.graph_get_port_parent = of_fwnode_graph_get_port_parent,
.graph_parse_endpoint = of_fwnode_graph_parse_endpoint,
+ .get_match_data = of_fwnode_get_match_data,
};
EXPORT_SYMBOL_GPL(of_fwnode_ops);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 3/7] device property: Introduce a common API to fetch device match data
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: Rob Herring, linux-arm-msm, Dmitry Torokhov, Rafael J. Wysocki,
open list, Sinan Kaya, Kieran Bingham, Sakari Ailus,
Greg Kroah-Hartman, Mika Westerberg, linux-arm-kernel, Len Brown
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
There is an OF/ACPI function to obtain the driver data. We want to hide
OF/ACPI details from the device drivers and abstract following the device
family of functions.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/base/property.c | 6 ++++++
include/linux/fwnode.h | 4 ++++
include/linux/property.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7ed99c1..65bf6f2 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1335,3 +1335,9 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return fwnode_call_int_op(fwnode, graph_parse_endpoint, endpoint);
}
EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+
+void *device_get_match_data(struct device *dev)
+{
+ return fwnode_call_ptr_op(dev_fwnode(dev), get_match_data, dev);
+}
+EXPORT_SYMBOL_GPL(device_get_match_data);
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 0c35b6c..ab9aab5 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -15,6 +15,7 @@
#include <linux/types.h>
struct fwnode_operations;
+struct device;
struct fwnode_handle {
struct fwnode_handle *secondary;
@@ -66,6 +67,7 @@ struct fwnode_reference_args {
* endpoint node.
* @graph_get_port_parent: Return the parent node of a port node.
* @graph_parse_endpoint: Parse endpoint for port and endpoint id.
+ * @get_match_data: Return the driver match data.
*/
struct fwnode_operations {
void (*get)(struct fwnode_handle *fwnode);
@@ -101,6 +103,8 @@ struct fwnode_operations {
(*graph_get_port_parent)(struct fwnode_handle *fwnode);
int (*graph_parse_endpoint)(const struct fwnode_handle *fwnode,
struct fwnode_endpoint *endpoint);
+ void *(*get_match_data)(const struct fwnode_handle *fwnode,
+ struct device *dev);
};
#define fwnode_has_op(fwnode, op) \
diff --git a/include/linux/property.h b/include/linux/property.h
index 6bebee1..01fa55b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ int device_add_properties(struct device *dev,
enum dev_dma_attr device_get_dma_attr(struct device *dev);
+void *device_get_match_data(struct device *dev);
+
int device_get_phy_mode(struct device *dev);
void *device_get_mac_address(struct device *dev, char *addr, int alen);
--
1.9.1
^ permalink raw reply related
* [PATCH V6 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Rafael J. Wysocki,
Len Brown, open list
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
OF has of_device_get_match_data() function to extract driver specific data
structure. Add a similar function for ACPI.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/bus.c | 12 ++++++++++++
include/linux/acpi.h | 6 ++++++
2 files changed, 18 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e..b271eb1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -785,6 +785,18 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
}
EXPORT_SYMBOL_GPL(acpi_match_device);
+void *acpi_get_match_data(const struct device *dev)
+{
+ const struct acpi_device_id *match;
+
+ match = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!match)
+ return NULL;
+
+ return (void *)match->driver_data;
+}
+EXPORT_SYMBOL_GPL(acpi_get_match_data);
+
int acpi_match_device_ids(struct acpi_device *device,
const struct acpi_device_id *ids)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 502af53..a927260 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,6 +584,7 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
const struct device *dev);
+void *acpi_get_match_data(const struct device *dev);
extern bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv);
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
@@ -755,6 +756,11 @@ static inline const struct acpi_device_id *acpi_match_device(
return NULL;
}
+static inline void *acpi_get_match_data(const struct device *dev)
+{
+ return NULL;
+}
+
static inline bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
{
--
1.9.1
^ permalink raw reply related
* [PATCH V6 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sinan Kaya,
Vinod Koul, Rob Herring, Mark Rutland, open list
In-Reply-To: <1512493493-6464-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
A new version of the HIDMA IP has been released with bug fixes. Bumping the
hardware version to differentiate from others.
Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 55492c2..5d93d6d 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
-for MSI capable HW.
+- compatible: must contain "qcom,hidma-1.0" for initial HW or
+ "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V6 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: dmaengine, timur, devicetree, linux-acpi
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya
Introduce new ACPI and OF device ids for thw HW along with the helper
functions.
Changes from v5:
* use struct device as a calling parameter to get_match_data() callback
so that we can reuse the existing OF API.
* revert the change on acpi_get_match_data() to V4.
Sinan Kaya (7):
Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
ACPI / bus: Introduce acpi_get_match_data() function
device property: Introduce a common API to fetch device match data
OF: properties: Implement get_match_data() callback
ACPI: properties: Implement get_match_data() callback
dmaengine: qcom_hidma: Add support for the new revision
dmaengine: qcom_hidma: Add identity register support
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 +--
drivers/acpi/bus.c | 12 +++++++
drivers/acpi/property.c | 7 ++++
drivers/base/property.c | 6 ++++
drivers/dma/qcom/hidma.c | 41 ++++++++++------------
drivers/of/property.c | 7 ++++
include/linux/acpi.h | 6 ++++
include/linux/fwnode.h | 4 +++
include/linux/property.h | 2 ++
9 files changed, 65 insertions(+), 24 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] ARM: dts: introduce the sama5d2 ptc ek board
From: Baruch Siach @ 2017-12-05 17:01 UTC (permalink / raw)
To: Ludovic Desroches
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171205142312.21506-1-ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Hi Ludovic,
On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote:
> Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> Kit board.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
[...]
> + memory {
> + reg = <0x20000000 0x80000>;
> + };
The size value is clearly wrong; you surely don't run on 512KB RAM. You most
likely rely on the bootloader to fix the size value. Since sama5d2.dtsi has a
memory node already with the same address, you can just drop it from here.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
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 0/2] of: Add whitelist
From: Alan Tull @ 2017-12-05 16:55 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, Pantelis Antoniou, Moritz Fischer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fpga-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <157eebaf-89a9-a230-e56b-d98a8e1e26bf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 30, 2017 at 6:18 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 11/29/17 08:31, Rob Herring wrote:
>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 11/27/17 15:58, Alan Tull wrote:
>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>>
>>>> For an overlay to be accepted, all of its targets are required to be
>>>> on a target node whitelist.
>>>>
>>>> Currently the only way I have to get on the whitelist is calling a
>>>> function to add a node. That works for fpga regions, but I think
>>>> other uses will need a way of having adding specific nodes from the
>>>> base device tree, such as by adding a property like 'allow-overlay;'
>>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>>>> advice on where that particular code should go.
>>>>
>>>> Alan
>>>>
>>>> Alan Tull (2):
>>>> of: overlay: add whitelist
>>>> fpga: of region: add of-fpga-region to whitelist
>>>>
>>>> drivers/fpga/of-fpga-region.c | 9 ++++++
>>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>>>> include/linux/of.h | 12 +++++++
>>>> 3 files changed, 94 insertions(+)
>>>>
>>>
>>> The plan was to use connectors to restrict where an overlay could be applied.
>>> I would prefer not to have multiple methods for accomplishing the same thing
>>> unless there is a compelling reason to do so.
>>
>> Connector nodes need a mechanism to enable themselves, too. I don't
>> think connector nodes are going to solve every usecase.
>>
>> Rob
>>
>
> The overlay code related to connectors does not exist yet, so my comment
> is going to be theoretical.
>
> I would expect the overlay code to check that the target of the overlay
> fragment is a connector node, so there is no need to explicitly "enable"
> applying an overlay to a connector node.
This will depend on how connectors are implemented. My proposal in v1
is that device nodes can have a flag bit. If its not set, then an
overlay that contains fragments that target that node can't be
applied. There's probably other ways a connector node could be marked
as different from other nodes, but a flag bit seems simple. The
advantage to this scheme is that it gives me something I can use while
connectors don't exist yet and it will still will be useful later for
the implementation of connectors (giving connector drivers a way of
marking their device nodes as valid targets).
>
> -Frank
--
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 0/2] of: Add whitelist
From: Alan Tull @ 2017-12-05 16:33 UTC (permalink / raw)
To: Frank Rowand
Cc: Rob Herring, Pantelis Antoniou, Moritz Fischer,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fpga
In-Reply-To: <24161ebf-81be-bec7-9fe8-36279a8b5a8d@gmail.com>
On Thu, Nov 30, 2017 at 6:46 AM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 11/29/17 11:11, Alan Tull wrote:
>> On Wed, Nov 29, 2017 at 7:31 AM, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Wed, Nov 29, 2017 at 3:20 AM, Frank Rowand <frowand.list@gmail.com> wrote:
>>>> On 11/27/17 15:58, Alan Tull wrote:
>>>>> Here's a proposal for a whitelist to lock down the dynamic device tree.
>>>>>
>>>>> For an overlay to be accepted, all of its targets are required to be
>>>>> on a target node whitelist.
>>>>>
>>>>> Currently the only way I have to get on the whitelist is calling a
>>>>> function to add a node. That works for fpga regions, but I think
>>>>> other uses will need a way of having adding specific nodes from the
>>>>> base device tree, such as by adding a property like 'allow-overlay;'
>>>>> or 'allow-overlay = "okay";' If that is acceptable, I could use some
>>>>> advice on where that particular code should go.
>>>>>
>>>>> Alan
>>>>>
>>>>> Alan Tull (2):
>>>>> of: overlay: add whitelist
>>>>> fpga: of region: add of-fpga-region to whitelist
>>>>>
>>>>> drivers/fpga/of-fpga-region.c | 9 ++++++
>>>>> drivers/of/overlay.c | 73 +++++++++++++++++++++++++++++++++++++++++++
>>>>> include/linux/of.h | 12 +++++++
>>>>> 3 files changed, 94 insertions(+)
>>>>>
>>>>
>>>> The plan was to use connectors to restrict where an overlay could be applied.
>>>> I would prefer not to have multiple methods for accomplishing the same thing
>>>> unless there is a compelling reason to do so.
>>>
>>> Connector nodes need a mechanism to enable themselves, too. I don't
>>> think connector nodes are going to solve every usecase.
>>>
>>> Rob
>>
>> The two methods I'm suggesting are intended to handle different cases.
>> There will exist some drivers that by their nature will want every
>> instance to be enabled for overlays, such as fpga regions. The other
>> case is where drivers could support overlays but that's not the
>> widespread use for them. So no need to enable every instance of that
>> driver for overlays.
>
> I understand what the paragraph, to this point, means. But I had to
> read it several times to understand it because the way the concept is
> phrased clashed with my mental model.
Hi Frank,
I see where my explanation is confusing things. I was talking about
two methods for marking a node as being a valid target for an overlay
(use a function or add a DT property). I'll drop the idea of using a
DT property to enable a node for overlays and only focus on my
proposal of a function to enable nodes.
>
> The device node is not an instance of a driver, which is why I was
> getting confused. (Yes, I do understand that the paragraph is talking
> about multiple device nodes that are bound to the same driver, but
> my mental model is tied to the device node, not to the driver.)
>
> If each of the device nodes in question is a connector, then each of
> the nodes will bind to a connector driver, based on the value of the
> compatible property. (This is of course a theoretical assumption on
> my part since the connectors are not yet implemented.)
>
> If the connector node is an fpga, or an fpga region (I may be getting
> my terminology wrong here - please correct as needed) then an fpga
> overlay could be applied to the node.
We're still pre-connector currently, but yes I want to mark FPGA
regions as being valid targets. Then I can use Pantelis' configfs
interface to apply overlays while leaving the rest of the DT locked
down. That's the FPGA use of this patch in the pre-connector era of
things.
>
> If I understand what you are saying, there will be some fpga connector
> nodes for which the usage at a given moment might be programmed to
> function in a manner that will not be described by an overlay, but
> at a different moment in time may be programmed in a way that needs
> to be described by an overlay. So there may be some times that it
> is valid to apply an overlay to the connector node and times that
> it is not valid to apply an overlay to the connector node.
I think connectors would likely always be valid targets (but I could
be wrong) and other nodes would not be valid targets. The DT needs a
way to mark some nodes as valid targets, currently it doesn't have a
way of doing that. Every connector driver's probe could use this code
to mark itself as a valid target.
>
> Is my understanding correct, or am I still confused?
Hope that helps, sorry for the muddled explanation earlier.
Alan
>
> -Frank
>
>> In that case the DT property provides some
>> granularity, only enabling overlays for specific instances of that
>> driver, leaving the rest of the DT locked down.>
>> If we only want one method, I would choose having the DT property only
>> and not exporting the functions. Users would have to add the property
>> for every FPGA region but that's not really painful. This would have
>> the benefit of still keeping the DT locked down unless someone
>> specifically wanted to enable some regions for overlays for their
>> particular use.
>>
>> Alan
>>
>
^ 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