* [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
V3: Use more real-life frequencies in the example.
V5: Describe hardware design as possible use for this property
V6: Even better property description, thanks Rob for your help!
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..f6442b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,24 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz. This can be
+ used for devices that in a given config support less channels than
+ normally. It may happen chipset supports a wide wireless band but it is
+ limited to some part of it due to used antennas or power amplifier.
+ An example case for this can be tri-band wireless router with two
+ identical chipsets used for two different 5 GHz subbands. Using them
+ incorrectly could not work or decrease performance noticeably.
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2482000>,
+ <5170000 5250000>;
+ };
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V6 2/3] cfg80211: move function checking range fit to util.c
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
It is needed for another cfg80211 helper that will be out of reg.c so
move it to common util.c file and make it non-static.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V5: Add this patch as suggested by Arend
---
net/wireless/core.h | 3 +++
net/wireless/reg.c | 27 +++++++--------------------
net/wireless/util.c | 15 +++++++++++++++
3 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index af6e023..bc8ba6e 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -430,6 +430,9 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);
void cfg80211_process_wdev_events(struct wireless_dev *wdev);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz);
+
/**
* cfg80211_chandef_dfs_usable - checks if chandef is DFS usable
* @wiphy: the wiphy to validate against
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..753efcd 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -748,21 +748,6 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
return true;
}
-static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
- u32 center_freq_khz, u32 bw_khz)
-{
- u32 start_freq_khz, end_freq_khz;
-
- start_freq_khz = center_freq_khz - (bw_khz/2);
- end_freq_khz = center_freq_khz + (bw_khz/2);
-
- if (start_freq_khz >= freq_range->start_freq_khz &&
- end_freq_khz <= freq_range->end_freq_khz)
- return true;
-
- return false;
-}
-
/**
* freq_in_rule_band - tells us if a frequency is in a frequency band
* @freq_range: frequency rule we want to query
@@ -1070,7 +1055,7 @@ freq_reg_info_regd(u32 center_freq,
if (!band_rule_found)
band_rule_found = freq_in_rule_band(fr, center_freq);
- bw_fits = reg_does_bw_fit(fr, center_freq, bw);
+ bw_fits = cfg80211_does_bw_fit_range(fr, center_freq, bw);
if (band_rule_found && bw_fits)
return rr;
@@ -1138,11 +1123,13 @@ static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd
max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule);
/* If we get a reg_rule we can assume that at least 5Mhz fit */
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(10)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(10)))
bw_flags |= IEEE80211_CHAN_NO_10MHZ;
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(20)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(20)))
bw_flags |= IEEE80211_CHAN_NO_20MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(10))
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2cf7df8..62dc214 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1847,6 +1847,21 @@ void cfg80211_free_nan_func(struct cfg80211_nan_func *f)
}
EXPORT_SYMBOL(cfg80211_free_nan_func);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz)
+{
+ u32 start_freq_khz, end_freq_khz;
+
+ start_freq_khz = center_freq_khz - (bw_khz / 2);
+ end_freq_khz = center_freq_khz + (bw_khz / 2);
+
+ if (start_freq_khz >= freq_range->start_freq_khz &&
+ end_freq_khz <= freq_range->end_freq_khz)
+ return true;
+
+ return false;
+}
+
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
const unsigned char rfc1042_header[] __aligned(2) =
--
2.10.1
^ permalink raw reply related
* [PATCH V6 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This patch adds a helper for reading that new property and applying
limitations of supported channels specified this way.
It is used with devices that normally support a wide wireless band but
in a given config are limited to some part of it (usually due to board
design). For example a dual-band chipset may be able to support one band
only because of used antennas.
It's also common that tri-band routers have separated radios for lower
and higher part of 5 GHz band and it may be impossible to say which is
which without a DT info.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
by Arend.
Update to support ieee80211-freq-limit (new property).
V3: Introduce separated wiphy_read_of_freq_limits function.
Add extra sanity checks for DT data.
Move code back to reg.c as suggested by Johannes.
V4: Move code to of.c
Use one helper called at init time (no runtime hooks)
Modify orig_flags
V5: Make wiphy_read_of_freq_limits return void as there isn't much point of
handling errors.
V6: Set IEEE80211_CHAN_DISABLED in "flags" instead of "orig_flags" as they will
be copied during wiphy_register. Also improve description & note that helper
has to be called before wiphy_register.
---
include/net/cfg80211.h | 28 ++++++++++
net/wireless/Makefile | 1 +
net/wireless/of.c | 138 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 167 insertions(+)
create mode 100644 net/wireless/of.c
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..30841a9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -311,6 +311,34 @@ struct ieee80211_supported_band {
struct ieee80211_sta_vht_cap vht_cap;
};
+/**
+ * wiphy_read_of_freq_limits - read frequency limits from device tree
+ *
+ * @wiphy: the wireless device to get extra limits for
+ *
+ * Some devices may have extra limitations specified in DT. This may be useful
+ * for chipsets that normally support more bands but are limited due to board
+ * design (e.g. by antennas or external power amplifier).
+ *
+ * This function reads info from DT and uses it to *modify* channels (disable
+ * unavailable ones). It's usually a *bad* idea to use it in drivers with
+ * shared channel data as DT limitations are device specific. You should make
+ * sure to call it only if channels in wiphy are copied and can be modified
+ * without affecting other devices.
+ *
+ * As this function access device node it has to be called after set_wiphy_dev.
+ * It also modifies channels so they have to be set first.
+ * If using this helper, call it before wiphy_register.
+ */
+#ifdef CONFIG_OF
+void wiphy_read_of_freq_limits(struct wiphy *wiphy);
+#else /* CONFIG_OF */
+static inline void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+}
+#endif /* !CONFIG_OF */
+
+
/*
* Wireless hardware/device configuration structures and methods
*/
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 4c9e39f..95b4c09 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o
+cfg80211-$(CONFIG_OF) += of.o
cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
diff --git a/net/wireless/of.c b/net/wireless/of.c
new file mode 100644
index 0000000..de221f0
--- /dev/null
+++ b/net/wireless/of.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <linux/of.h>
+#include <net/cfg80211.h>
+#include "core.h"
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ if (cfg80211_does_bw_fit_range(limit,
+ MHZ_TO_KHZ(chan->center_freq),
+ bw))
+ return true;
+ }
+
+ return false;
+}
+
+static void wiphy_freq_limits_apply(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (WARN_ON(!n_freq_limits))
+ return;
+
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband = wiphy->bands[band];
+
+ if (!sband)
+ continue;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+
+ if (chan->flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, freq_limits,
+ n_freq_limits,
+ chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
+void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ struct ieee80211_freq_range *freq_limits;
+ unsigned int n_freq_limits;
+ const __be32 *p;
+ int len, i;
+ int err = 0;
+
+ if (!dev)
+ return;
+ np = dev_of_node(dev);
+ if (!np)
+ return;
+
+ prop = of_find_property(np, "ieee80211-freq-limit", &len);
+ if (!prop)
+ return;
+
+ if (!len || len % sizeof(u32) || len / sizeof(u32) % 2) {
+ dev_err(dev, "ieee80211-freq-limit wrong format");
+ return;
+ }
+ n_freq_limits = len / sizeof(u32) / 2;
+
+ freq_limits = kcalloc(n_freq_limits, sizeof(*freq_limits), GFP_KERNEL);
+ if (!freq_limits) {
+ err = -ENOMEM;
+ goto out_kfree;
+ }
+
+ p = NULL;
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ p = of_prop_next_u32(prop, p, &limit->start_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ if (!limit->start_freq_khz ||
+ !limit->end_freq_khz ||
+ limit->start_freq_khz >= limit->end_freq_khz) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+ }
+
+ wiphy_freq_limits_apply(wiphy, freq_limits, n_freq_limits);
+
+out_kfree:
+ kfree(freq_limits);
+ if (err)
+ dev_err(dev, "Failed to get limits: %d\n", err);
+}
+EXPORT_SYMBOL(wiphy_read_of_freq_limits);
--
2.10.1
^ permalink raw reply related
* [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
There are some devices (e.g. Netgear R8000 home router) with one chipset
model used for different radios, some of them limited to subbands. NVRAM
entries don't contain any extra info on such limitations and firmware
reports full list of channels to us. We need to store extra limitation
info in DT to support such devices properly.
Now there is a cfg80211 helper for reading such info use it in brcmfmac.
This patch adds check for channel being disabled with orig_flags which
is how this wiphy helper and wiphy_register work.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch should probably go through wireless-driver-next which is why
it got weird number 4/3. I'm sending it just as a proof of concept.
It was succesfully tested on SmartRG SR400ac with BCM43602.
V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
V5: Update commit message
V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
with helper setting "flags" instead of "orig_flags".
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..a008ba5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
band->band);
channel[index].hw_value = ch.control_ch_num;
+ if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
/* assuming the chanspecs order is HT20,
* HT40 upper, HT40 lower, and VHT80.
*/
@@ -6478,7 +6481,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
}
}
err = brcmf_setup_wiphybands(wiphy);
- return err;
+ if (err)
+ return err;
+ wiphy_read_of_freq_limits(wiphy);
+
+ return 0;
}
static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
--
2.10.1
^ permalink raw reply related
* Re: [PATCH V2 5/5] ARM: dts: exynos5440: support the phy-pcie node for pcie
From: Jingoo Han @ 2017-01-04 18:02 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Jaehoon Chung'
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104175822.5zedyszx2phiehuv@kozik-lap>
On Wednesday, January 4, 2017 12:58 PM, Krzysztof Kozlowski wrote:
>
> On Wed, Jan 04, 2017 at 09:34:35PM +0900, Jaehoon Chung wrote:
> > Add phy-pcie node for using Exynos5440 pcie.
> > And use the reg-names as "elbi" and "config".
>
> 'and' is only for joining in compound sentences, don't start with it.
>
> > Because the getting configuratioin space address from ranges is old way.
>
> Spell-check please.
>
> > It also is helpful to distinguish more clearly.
>
> Distinguish what? Please work on the commit msg, I am not picking
> >
> > Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > ---
> > Changelog on V2:
> > - Removes the child-node
> > - Fixes the typo
> > - Removes the unnecessary comments
> >
> > arch/arm/boot/dts/exynos5440.dtsi | 34 ++++++++++++++++++++++----------
> --
> > 1 file changed, 22 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5440.dtsi
> b/arch/arm/boot/dts/exynos5440.dtsi
> > index 2a2e570..feb074d 100644
> > --- a/arch/arm/boot/dts/exynos5440.dtsi
> > +++ b/arch/arm/boot/dts/exynos5440.dtsi
> > @@ -290,11 +290,22 @@
> > clock-names = "usbhost";
> > };
> >
> > + pcie_phy0: pcie-phy@270000 {
> > + #phy-cells = <0>;
> > + compatible = "samsung,exynos5440-pcie-phy";
> > + reg = <0x270000 0x1000>, <0x271000 0x40>;
> > + };
> > +
> > + pcie_phy1: pcie-phy@272000 {
> > + #phy-cells = <0>;
> > + compatible = "samsung,exynos5440-pcie-phy";
> > + reg = <0x272000 0x1000>, <0x271040 0x40>;
> > + };
> > +
> > pcie_0: pcie@290000 {
> > compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> > - reg = <0x290000 0x1000
> > - 0x270000 0x1000
> > - 0x271000 0x40>;
> > + reg = <0x290000 0x1000>, <0x40000000 0x1000>;
> > + reg-names = "elbi", "config";
> > interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -303,9 +314,9 @@
> > #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 */
> > + phys = <&pcie_phy0>;
> > + ranges = <0x81000000 0 0 0x40001000 0 0x00010000
> > + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>;
>
> I think the comments were useful. You can leave them.
>
> > #interrupt-cells = <1>;
> > interrupt-map-mask = <0 0 0 0>;
> > interrupt-map = <0x0 0 &gic 53>;
> > @@ -315,9 +326,8 @@
> >
> > pcie_1: pcie@2a0000 {
> > compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> > - reg = <0x2a0000 0x1000
> > - 0x272000 0x1000
> > - 0x271040 0x40>;
> > + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
> > + reg-names = "elbi", "config";
> > interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -326,9 +336,9 @@
> > #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 */
> > + phys = <&pcie_phy1>;
> > + ranges = <0x81000000 0 0 0x60001000 0 0x00010000
> > + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
>
> I think the comments were useful. You can leave them.
I think so, too.
Please leave the comments
Best regards,
Jingoo Han
>
> This looks like depending on the changes in the driver, so I will need a
> tag or stable branch from PCIe maintainers.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Applied "spi: bcm-qspi: Enable the driver on BMIPS_GENERIC" to the spi tree
From: Mark Brown @ 2017-01-04 18:37 UTC (permalink / raw)
To: Jaedon Shin; +Cc: Florian Fainelli, Mark Brown, Ralf Baechle
In-Reply-To: <20161230063001.944-2-jaedon.shin@gmail.com>
The patch
spi: bcm-qspi: Enable the driver on BMIPS_GENERIC
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.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 279e4af7b4bebc6a5bf2d0e5b3209f3dcea94a19 Mon Sep 17 00:00:00 2001
From: Jaedon Shin <jaedon.shin@gmail.com>
Date: Fri, 30 Dec 2016 15:30:00 +0900
Subject: [PATCH] spi: bcm-qspi: Enable the driver on BMIPS_GENERIC
The Broadcom BCM7XXX ARM and MIPS based SoCs share a similar hardware
block for SPI.
Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec4aa252d6e8..c982a01022ba 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -162,7 +162,8 @@ config SPI_BCM63XX_HSSPI
config SPI_BCM_QSPI
tristate "Broadcom BSPI and MSPI controller support"
- depends on ARCH_BRCMSTB || ARCH_BCM || ARCH_BCM_IPROC || COMPILE_TEST
+ depends on ARCH_BRCMSTB || ARCH_BCM || ARCH_BCM_IPROC || \
+ BMIPS_GENERIC || COMPILE_TEST
default ARCH_BCM_IPROC
help
Enables support for the Broadcom SPI flash and MSPI controller.
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-04 19:26 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170104115424.GH27589@dell>
On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> On Mon, 26 Dec 2016, Bjorn Andersson wrote:
>
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >
> > Implement support for initialization of the lm3533 driver core and
> > probing child devices from Device Tree.
> >
[..]
> > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > lm3533_device_bl_init(lm3533);
> > lm3533_device_led_init(lm3533);
> >
> > + if (lm3533->dev->of_node) {
> > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > + lm3533->dev);
> > + }
>
> I think it's save to call of_platform_populate(), even if !of_node.
> It will just fail and return an error code, which you are ignoring
> anyway.
>
I thought so too, but that's apparently how you trigger probing children
of the root node. So we're stuck with a conditional.
[..]
> > static int lm3533_i2c_probe(struct i2c_client *i2c,
> > const struct i2c_device_id *id)
> > {
[..]
> >
> > + if (i2c->dev.of_node) {
>
> I'd prefer this check to be placed in lm3533_pdata_from_of_node().
>
> Just return silently if !dev->of_node.
>
I agree, will update this.
> > + ret = lm3533_pdata_from_of_node(lm3533->dev);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > return lm3533_device_init(lm3533);
> > }
> >
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rob Herring @ 2017-01-04 19:46 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg, linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Jan 4, 2017 at 11:58 AM, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties that apply to all wireless
> devices.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> V2: Switch to a single ieee80211-freq-limit property that allows specifying
> *multiple* ranges. This resolves problem with more complex rules as pointed
> by Felx.
> Make description implementation agnostic as pointed by Arend.
> Rename node to wifi as suggested by Martin.
> V3: Use more real-life frequencies in the example.
> V5: Describe hardware design as possible use for this property
> V6: Even better property description, thanks Rob for your help!
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Arend Van Spriel @ 2017-01-04 19:53 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Rob Herring,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6rxx-8499ZQKekdORF0UWQQazwGu2On1aq-fwA4oCX7pgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 4-1-2017 15:53, Rafał Miłecki wrote:
> On 4 January 2017 at 15:32, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> On 3 January 2017 at 20:55, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>
>>>>> This new file should be used for properties handled at higher level and
>>>>> so usable with all drivers.
>>>>
>>>> Why is this needed? Where would this data normally come from?
>>>
>>> Vendors limit choice of channels at their web user interface level. I
>>> want to do better and report proper channels directly at kernel level
>>> instead of masking them in every possible configuration tool.
>>
>> Why do vendors limit the channels? Is it because of a hardware
>> limitation (antenna does not support, or not calibrated, for a certain
>> band etc) or something else?
>
> Please review & comment on the latest version, currently V5:
> https://patchwork.kernel.org/patch/9495795/
> "This can be used to specify extra hardware limitations caused by e.g.
> used antennas or power amplifiers."
Just to be clear, it is does not need to be a hardware limitation, but
simply a way to assure that multiple wlan radios are not interfering
with each other and crank up the total bandwidth that vendors can put on
their box.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V2 4/5] PCI: exynos: support the using PHY generic framework
From: Jingoo Han @ 2017-01-04 19:56 UTC (permalink / raw)
To: 'Jaehoon Chung', linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-5-jh80.chung@samsung.com>
On Wednesday, January 4, 2017 7:35 AM, Jaehoon Chung wrote:
>
> This patch is for using PHY generic framework.
> To maintain backward compatibility, check whether phy is supported or
> not with 'using_phy'.
>
> And if someone use the old dt-file, display the "deprecated" message.
> But it's still working fine with it.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
It looks good!
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> Changelog on V2:
> - This patch is split from previous PATCH[1/4]
> - Maintain the backward compatibility
> - Adds 'using_phy' for cheching whether phy framework is used or not
> - Adds 'DEPRECATED' message for old dt-binding way
>
> drivers/pci/host/pci-exynos.c | 61 +++++++++++++++++++++++++++++++++++---
> -----
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index feed0fd..34f2eed 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -21,6 +21,7 @@
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> #include <linux/resource.h>
> #include <linux/signal.h>
> #include <linux/types.h>
> @@ -110,6 +111,10 @@ struct exynos_pcie {
> struct exynos_pcie_clk_res *clk_res;
> const struct exynos_pcie_ops *ops;
> int reset_gpio;
> +
> + /* For Generic PHY Framework */
> + bool using_phy;
> + struct phy *phy;
> };
>
> struct exynos_pcie_ops {
> @@ -135,6 +140,10 @@ 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))
> @@ -396,17 +405,28 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *exynos_pcie)
> }
>
> exynos_pcie_assert_core_reset(exynos_pcie);
> - exynos_pcie_assert_phy_reset(exynos_pcie);
> - exynos_pcie_deassert_phy_reset(exynos_pcie);
> - exynos_pcie_power_on_phy(exynos_pcie);
> - exynos_pcie_init_phy(exynos_pcie);
> -
> - /* pulse for common reset */
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> - PCIE_PHY_COMMON_RESET);
> - udelay(500);
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> - PCIE_PHY_COMMON_RESET);
> +
> + if (exynos_pcie->using_phy) {
> + phy_reset(exynos_pcie->phy);
> +
> + exynos_pcie_writel(exynos_pcie->mem_res->elbi_base, 1,
> + PCIE_PWR_RESET);
> +
> + phy_power_on(exynos_pcie->phy);
> + phy_init(exynos_pcie->phy);
> + } else {
> + exynos_pcie_assert_phy_reset(exynos_pcie);
> + exynos_pcie_deassert_phy_reset(exynos_pcie);
> + exynos_pcie_power_on_phy(exynos_pcie);
> + exynos_pcie_init_phy(exynos_pcie);
> +
> + /* pulse for common reset */
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
> + }
>
> exynos_pcie_deassert_core_reset(exynos_pcie);
> dw_pcie_setup_rc(pp);
> @@ -420,6 +440,11 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *exynos_pcie)
> if (!dw_pcie_wait_for_link(pp))
> return 0;
>
> + if (exynos_pcie->using_phy) {
> + phy_power_off(exynos_pcie->phy);
> + return -ETIMEDOUT;
> + }
> +
> while (exynos_pcie_readl(exynos_pcie->mem_res->phy_base,
> PCIE_PHY_PLL_LOCKED) == 0) {
> val = exynos_pcie_readl(exynos_pcie->mem_res->block_base,
> @@ -633,6 +658,17 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
>
> exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> + /* Assume that controller doesn't use the PHY framework */
> + exynos_pcie->using_phy = false;
> +
> + exynos_pcie->phy = devm_of_phy_get(dev, np, NULL);
> + if (IS_ERR(exynos_pcie->phy)) {
> + if (PTR_ERR(exynos_pcie->phy) == -EPROBE_DEFER)
> + return PTR_ERR(exynos_pcie->phy);
> + dev_warn(dev, "Use the 'phy' property. Current DT of pci-
> exynos was deprecated!!\n");
> + } else
> + exynos_pcie->using_phy = true;
> +
> if (exynos_pcie->ops && exynos_pcie->ops->get_mem_resources) {
> ret = exynos_pcie->ops->get_mem_resources(pdev, exynos_pcie);
> if (ret)
> @@ -657,6 +693,9 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
> return 0;
>
> fail_probe:
> + if (exynos_pcie->using_phy)
> + phy_exit(exynos_pcie->phy);
> +
> if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
> return ret;
> --
> 2.10.2
^ permalink raw reply
* Re: [PATCH] of: reserved_mem: set dma_ops for devices using reserved mem
From: Rob Herring @ 2017-01-04 20:02 UTC (permalink / raw)
To: Pankaj Dubey
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w, krzk-DgEjT+Ai2ygdnm+yROfE0A,
kgene-DgEjT+Ai2ygdnm+yROfE0A, Smitha T Murthy
In-Reply-To: <1482299071-22637-1-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 21, 2016 at 11:14:31AM +0530, Pankaj Dubey wrote:
> From: Smitha T Murthy <smitha.t-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> For some IPs, there may be virtual child devices created and for them its
> necessary to set the dma_ops if it's using reserved memory else it will call
> the dummy dma_ops during buffer operations for the child devices which will
> lead to memory mapping failure.
>
> Signed-off-by: Smitha T Murthy <smitha.t-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/of/of_reserved_mem.c | 4 ++++
> 1 file changed, 4 insertions(+)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: drop duplicate headers
From: Rob Herring @ 2017-01-04 20:02 UTC (permalink / raw)
To: Geliang Tang
Cc: Pantelis Antoniou, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2dbc4a9165d0a1e1569dc3990cbe5567fb312c74.1482593743.git.geliangtang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Dec 24, 2016 at 11:45:06PM +0800, Geliang Tang wrote:
> Drop duplicate headers string.h and of_platform.h.
>
> Signed-off-by: Geliang Tang <geliangtang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/of/overlay.c | 1 -
> drivers/of/resolver.c | 1 -
> drivers/of/unittest.c | 1 -
> 3 files changed, 3 deletions(-)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-04 20:07 UTC (permalink / raw)
To: Rafał Miłecki, Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-4-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 4-1-2017 18:58, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> There are some devices (e.g. Netgear R8000 home router) with one chipset
> model used for different radios, some of them limited to subbands. NVRAM
> entries don't contain any extra info on such limitations and firmware
> reports full list of channels to us. We need to store extra limitation
> info in DT to support such devices properly.
>
> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
> This patch adds check for channel being disabled with orig_flags which
> is how this wiphy helper and wiphy_register work.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> This patch should probably go through wireless-driver-next which is why
> it got weird number 4/3. I'm sending it just as a proof of concept.
> It was succesfully tested on SmartRG SR400ac with BCM43602.
>
> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
> V5: Update commit message
> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
> with helper setting "flags" instead of "orig_flags".
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index ccae3bb..a008ba5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
> band->band);
> channel[index].hw_value = ch.control_ch_num;
>
> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
> + continue;
> +
So to be clear this is still needed for subsequent calls to
brcmf_setup_wiphybands(). The subsequent calls are done from the
regulatory notifier. So I think we have an issue with this approach. Say
the device comes up with US. That would set DISABLED flags for channels
12 to 14. With a country update to PL we would want to enable channels
12 and 13, right? The orig_flags are copied from the initial flags
during wiphy_register() so it seems we will skip enabling 12 and 13. I
think we should remove the check above and call
wiphy_read_of_freq_limits() as a last step within
brcmf_setup_wiphybands(). It means it is called every time, but it
safeguards that the limits in DT are always applied.
Regards,
Arend
> /* assuming the chanspecs order is HT20,
> * HT40 upper, HT40 lower, and VHT80.
> */
> @@ -6478,7 +6481,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
> }
> }
> err = brcmf_setup_wiphybands(wiphy);
> - return err;
> + if (err)
> + return err;
> + wiphy_read_of_freq_limits(wiphy);
> +
> + return 0;
> }
>
> static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
>
^ permalink raw reply
* Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
From: Jingoo Han @ 2017-01-04 20:21 UTC (permalink / raw)
To: 'Jaehoon Chung', linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-3-jh80.chung@samsung.com>
On Wednesday, January 4, 2017 7:35 AM, Jaehoon Chung wrote:
>
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Currently, there is an exynos5440 case to support the pcie.
> So this driver is based on Exynos5440 PCIe.
> In future, will support the Other exynos SoCs likes exynos5433, exynos7.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> Changelog on V2:
> - Not include the codes relevant to pci-exynos.
> - Remove the getting child node.
>
> drivers/phy/Kconfig | 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos-pcie.c | 280
> ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 290 insertions(+)
> create mode 100644 drivers/phy/phy-exynos-pcie.c
>
^ permalink raw reply
* [PATCH v2 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x UART
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
UART. This SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI
DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
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
* [PATCH v2 1/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1483561814-21953-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
v2 changes:
* Added C66x to list of SoCs
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..61dd806 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..1265918 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..84606d8 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
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
* [PATCH v2 3/4] ARM: da850: Add ti,da830-uart compatible for serial ports
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* None
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial@42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial@10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial@10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: keystone: Add "ti,da830-uart" compatible string
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
The TI Keystone SoCs have extra UART registers beyond the standard 8250
registers, so we need a new compatible string to indicate this. Also, at
least one of these registers uses the full 32 bits, so we need to specify
reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work as
long as the bootloader configures the SoC UART power management registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* This is a new patch in v2
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c..7d7b9a8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -90,7 +90,7 @@
};
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e..e91633f 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -35,7 +35,7 @@
/include/ "keystone-k2l-clocks.dtsi"
uart2: serial@02348400 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -45,7 +45,7 @@
};
uart3: serial@02348800 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..9152610 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -98,7 +98,7 @@
/include/ "keystone-clocks.dtsi"
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -108,7 +108,7 @@
};
uart1: serial@02531000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] iio: adc: Add Renesas GyroADC driver
From: Geert Uytterhoeven @ 2017-01-04 20:36 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Geert Uytterhoeven, Simon Horman
In-Reply-To: <f4bb8922-36dc-ff69-45fc-e1d9cba821ba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Marek,
On Wed, Jan 4, 2017 at 3:27 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/02/2017 11:01 AM, Geert Uytterhoeven wrote:
>> On Fri, Dec 30, 2016 at 8:18 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
>>> @@ -0,0 +1,38 @@
>>> +* Renesas RCar GyroADC device driver
>>> +
>>> +Required properties:
>>> +- compatible: Should be "renesas,rcar-gyroadc" for regular GyroADC or
>>> + "renesas,rcar-gyroadc-r8a7792" for GyroADC without interrupt
>>
>> Please use "renesas,r8a7792-gyroadc" to match existing practices.
>
> Actually, that should probably be gyroadc-r8a7791 if we want to match
> the existing practice. Fixed.
No, "renesas,r8a7791-gyroadc" ("<vendor>,<family>-<block>").
>>> +static void rcar_gyroadc_hw_init(struct rcar_gyroadc *priv)
>>> +{
>>> + unsigned long clk_mhz = clk_get_rate(priv->clk) / 1000000;
>>> +
>>> + /* Stop the GyroADC. */
>>> + writel(0, priv->regs + RCAR_GYROADC_START_STOP);
>>> +
>>> + /* Disable IRQ, except on V2H. */
>>> + if (priv->model != RCAR_GYROADC_MODEL_R8A7792)
>>> + writel(0, priv->regs + RCAR_GYROADC_INTENR);
>>> +
>>> + /* Set mode and timing. */
>>> + writel(priv->mode, priv->regs + RCAR_GYROADC_MODE_SELECT);
>>> +
>>> + if (priv->mode == RCAR_GYROADC_MODE_SELECT_1_MB88101A)
>>> + writel(clk_mhz * 10, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_2_ADCS7476)
>>> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_3_MAX1162)
>>> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + writel(clk_mhz * 1250, priv->regs + RCAR_GYROADC_1_25MS_LENGTH);
>>> +
>>> + /*
>>> + * We can possibly turn the sampling on/off on-demand to reduce power
>>
>> And the module clock, using runtime PM (see below).
>>> +static int rcar_gyroadc_probe(struct platform_device *pdev)
>>> +{
>>
>>> + priv->fclk = devm_clk_get(dev, "fck");
>>
>> The module clock isn't used directly by this driver (you don't need
>> e.g. its rate),
>> so you can leave out all handling related to this clock iff you enable
>> runtime PM:
>>
>> pm_runtime_enable(dev);
>> pm_runtime_get_sync(dev);
>>
>> Then runtime PM will take care of enabling the module clock, as the
>> GyroADC block is part of the CPG/MSSR clock domain.
>> Doing that also means the driver keeps on working in future SoCs where
>> the GyroADC block may be located in a power area.
>
> So I won't even need the fclk phandle in DT, right ?
You still need the fclk phandle in DT, so the PM domain code can find out
which clock to use for PM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Rob Herring @ 2017-01-04 20:39 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Jiri Slaby, dri-devel, Martyn Welch, Takashi Iwai, Russell King,
Kumar Gala, Peter Senna Tschudin, Archit Taneja, Fabio Estevam,
Ian Campbell, David Miller, Mark Rutland, Russell King,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ, Mauro Carvalho Chehab,
Peter Senna Tschudin, Thierry Reding,
Greg Kroah-Hartman <gregkh@
In-Reply-To: <529b-586c3500-5-5e05b080@98620974>
On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin
<peter.senna-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> Hi Rob,
>
> Thank you for the review.
>
> On 03 January, 2017 23:51 CET, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
>> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
>> > display bridge.
>> >
>> > Cc: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>> > Cc: Martin Donnelly <martin.donnelly-JJi787mZWgc@public.gmane.org>
>> > Cc: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
>> > Cc: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> > Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> > Signed-off-by: Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> > ---
>> > There was an Acked-by from Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> for V6, but I changed
>> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
>> > message.
>> >
>> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
>>
>> Generally, bindings are not organized by vendor. Put in
>> bindings/display/bridge/... instead.
>
> Will change that.
>
>>
>> > 1 file changed, 39 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > new file mode 100644
>> > index 0000000..1bc6ebf
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > @@ -0,0 +1,39 @@
>> > +Driver for GE B850v3 LVDS/DP++ display bridge
>> > +
>> > +Required properties:
>> > + - compatible : should be "ge,b850v3-lvds-dp".
>>
>> Isn't '-lvds-dp' redundant? The part# should be enough.
>
> b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
Humm, b850v3 is the board name? This node should be the name of the bridge chip.
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
* [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
Hi,
This is v3 of the series to add support for TI-SCI Generic PM Domains.
Previous versions can be found here:
v2: https://www.spinics.net/lists/kernel/msg2364612.html
v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
This version is rebased on v4.10-rc2 but is the same as v2 with the
exception of patch 2 in which the devicetree binding documentation
needed to be updated to show the k2g_pds node should be a child of
the pmmc node. Apart from that, the acks provided by Ulf were added
to patches 1 and 3.
Now that the TI-SCI series has been merged [1] this series will be ready
to go in with an ack on the DT binding. Rob had raised some questions on
the necessity ti,sci-id property but I believe these were properly
addressed during the discussion of v2 so hopefully an ack is in order now.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg536851.html
Dave Gerlach (4):
PM / Domains: Add generic data pointer to genpd data struct
dt-bindings: Add TI SCI PM Domains
soc: ti: Add ti_sci_pm_domains driver
ARM: keystone: Drop PM domain support for k2g
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++
MAINTAINERS | 3 +
arch/arm/mach-keystone/Kconfig | 1 +
arch/arm/mach-keystone/pm_domain.c | 4 +-
drivers/soc/ti/Kconfig | 12 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++
include/dt-bindings/genpd/k2g.h | 90 ++++++++++
include/linux/pm_domain.h | 1 +
9 files changed, 368 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
create mode 100644 include/dt-bindings/genpd/k2g.h
--
2.11.0
^ permalink raw reply
* [PATCH v3 1/4] PM / Domains: Add generic data pointer to genpd data struct
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon, Dave Gerlach,
Keerthy, Russell King, Tero Kristo, Sudeep Holla,
Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <20170104205536.15963-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Add a void *data pointer to struct generic_pm_domain_data. Because this
exists for each device associated with a genpd it will allow us to
assign per-device data if needed on a platform for control of that
specific device.
Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..73c9dba5cfcc 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -117,6 +117,7 @@ struct generic_pm_domain_data {
struct pm_domain_data base;
struct gpd_timing_data td;
struct notifier_block nb;
+ void *data;
};
#ifdef CONFIG_PM_GENERIC_DOMAINS
--
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 v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.
Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2->v3:
Update k2g_pds node docs to show it should be a child of pmmc node.
In early versions a phandle was used to point to pmmc and docs still
incorrectly showed this.
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
MAINTAINERS | 2 +
include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
3 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 include/dt-bindings/genpd/k2g.h
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
new file mode 100644
index 000000000000..4c9064e512cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -0,0 +1,59 @@
+Texas Instruments TI-SCI Generic Power Domain
+---------------------------------------------
+
+Some TI SoCs contain a system controller (like the PMMC, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI-SCI [1]. This pm domain
+implementation plugs into the generic pm domain framework and makes use of
+the TI SCI protocol power on and off each device when needed.
+
+[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the PMMC,
+which in this case is the single implementation as documented by the generic
+PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+Because this relies on the TI SCI protocol to communicate with the PMMC it
+must be a child of the pmmc node.
+
+Required Properties:
+--------------------
+- compatible: should be "ti,sci-pm-domain"
+- #power-domain-cells: Must be 0.
+
+Example (K2G):
+-------------
+ pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+ ...
+
+ k2g_pds: k2g_pds {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <0>;
+ };
+ };
+
+PM Domain Consumers
+===================
+Hardware blocks that require SCI control over their state must provide
+a reference to the sci-pm-domain they are part of and a unique device
+specific ID that identifies the device.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node.
+- ti,sci-id: index representing the device id to be passed oevr SCI to
+ be used for device control.
+
+See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
+
+Example (K2G):
+--------------------
+ uart0: serial@02530c00 {
+ compatible = "ns16550a";
+ ...
+ power-domains = <&k2g_pds>;
+ ti,sci-id = <K2G_DEV_UART0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..7e68af170dae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12144,6 +12144,8 @@ S: Maintained
F: Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
+F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+F: include/dt-bindings/genpd/k2g.h
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/include/dt-bindings/genpd/k2g.h b/include/dt-bindings/genpd/k2g.h
new file mode 100644
index 000000000000..91ad827e0ca1
--- /dev/null
+++ b/include/dt-bindings/genpd/k2g.h
@@ -0,0 +1,90 @@
+/*
+ * TI K2G SoC Device definitions
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_GENPD_K2G_H
+#define _DT_BINDINGS_GENPD_K2G_H
+
+/* Documented in http://processors.wiki.ti.com/index.php/TISCI */
+
+#define K2G_DEV_PMMC0 0x0000
+#define K2G_DEV_MLB0 0x0001
+#define K2G_DEV_DSS0 0x0002
+#define K2G_DEV_MCBSP0 0x0003
+#define K2G_DEV_MCASP0 0x0004
+#define K2G_DEV_MCASP1 0x0005
+#define K2G_DEV_MCASP2 0x0006
+#define K2G_DEV_DCAN0 0x0008
+#define K2G_DEV_DCAN1 0x0009
+#define K2G_DEV_EMIF0 0x000a
+#define K2G_DEV_MMCHS0 0x000b
+#define K2G_DEV_MMCHS1 0x000c
+#define K2G_DEV_GPMC0 0x000d
+#define K2G_DEV_ELM0 0x000e
+#define K2G_DEV_SPI0 0x0010
+#define K2G_DEV_SPI1 0x0011
+#define K2G_DEV_SPI2 0x0012
+#define K2G_DEV_SPI3 0x0013
+#define K2G_DEV_ICSS0 0x0014
+#define K2G_DEV_ICSS1 0x0015
+#define K2G_DEV_USB0 0x0016
+#define K2G_DEV_USB1 0x0017
+#define K2G_DEV_NSS0 0x0018
+#define K2G_DEV_PCIE0 0x0019
+#define K2G_DEV_GPIO0 0x001b
+#define K2G_DEV_GPIO1 0x001c
+#define K2G_DEV_TIMER64_0 0x001d
+#define K2G_DEV_TIMER64_1 0x001e
+#define K2G_DEV_TIMER64_2 0x001f
+#define K2G_DEV_TIMER64_3 0x0020
+#define K2G_DEV_TIMER64_4 0x0021
+#define K2G_DEV_TIMER64_5 0x0022
+#define K2G_DEV_TIMER64_6 0x0023
+#define K2G_DEV_MSGMGR0 0x0025
+#define K2G_DEV_BOOTCFG0 0x0026
+#define K2G_DEV_ARM_BOOTROM0 0x0027
+#define K2G_DEV_DSP_BOOTROM0 0x0029
+#define K2G_DEV_DEBUGSS0 0x002b
+#define K2G_DEV_UART0 0x002c
+#define K2G_DEV_UART1 0x002d
+#define K2G_DEV_UART2 0x002e
+#define K2G_DEV_EHRPWM0 0x002f
+#define K2G_DEV_EHRPWM1 0x0030
+#define K2G_DEV_EHRPWM2 0x0031
+#define K2G_DEV_EHRPWM3 0x0032
+#define K2G_DEV_EHRPWM4 0x0033
+#define K2G_DEV_EHRPWM5 0x0034
+#define K2G_DEV_EQEP0 0x0035
+#define K2G_DEV_EQEP1 0x0036
+#define K2G_DEV_EQEP2 0x0037
+#define K2G_DEV_ECAP0 0x0038
+#define K2G_DEV_ECAP1 0x0039
+#define K2G_DEV_I2C0 0x003a
+#define K2G_DEV_I2C1 0x003b
+#define K2G_DEV_I2C2 0x003c
+#define K2G_DEV_EDMA0 0x003f
+#define K2G_DEV_SEMAPHORE0 0x0040
+#define K2G_DEV_INTC0 0x0041
+#define K2G_DEV_GIC0 0x0042
+#define K2G_DEV_QSPI0 0x0043
+#define K2G_DEV_ARM_64B_COUNTER0 0x0044
+#define K2G_DEV_TETRIS0 0x0045
+#define K2G_DEV_CGEM0 0x0046
+#define K2G_DEV_MSMC0 0x0047
+#define K2G_DEV_CBASS0 0x0049
+#define K2G_DEV_BOARD0 0x004c
+#define K2G_DEV_EDMA1 0x004f
+
+#endif
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider
to allow each device to attach and associate it's ti-sci-id so that it can
be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has
a phandle to the power domain node and also must provide an index which
represents the ID to be passed with TI SCI representing the device using a
ti,sci-id property. Through this interface the genpd dev_ops start and
stop hooks will use TI SCI to turn on and off each device as determined
by pm_runtime usage.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
MAINTAINERS | 1 +
arch/arm/mach-keystone/Kconfig | 1 +
drivers/soc/ti/Kconfig | 12 +++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++++++++++++++++++
5 files changed, 213 insertions(+)
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e68af170dae..39d05f92bfcb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12146,6 +12146,7 @@ F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
F: include/dt-bindings/genpd/k2g.h
+F: drivers/soc/ti/ti_sci_pm_domains.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..18d49465cafb 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -9,6 +9,7 @@ config ARCH_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
select ZONE_DMA if ARM_LPAE
select PINCTRL
+ select PM_GENERIC_DOMAINS if PM
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 3557c5e32a93..39e152abe6b9 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -38,4 +38,16 @@ config WKUP_M3_IPC
to communicate and use the Wakeup M3 for PM features like suspend
resume and boots it using wkup_m3_rproc driver.
+config TI_SCI_PM_DOMAINS
+ tristate "TI SCI PM Domains Driver"
+ depends on TI_SCI_PROTOCOL
+ depends on PM_GENERIC_DOMAINS
+ help
+ Generic power domain implementation for TI device implementing
+ the TI SCI protocol.
+
+ To compile this as a module, choose M here. The module will be
+ called ti_sci_pm_domains. Note this is needed early in boot before
+ rootfs may be available.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 48ff3a79634f..7d572736c86e 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
+obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
new file mode 100644
index 000000000000..ec76215d64c7
--- /dev/null
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -0,0 +1,198 @@
+/*
+ * TI SCI Generic Power Domain Driver
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy <j-keerthy@ti.com>
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/slab.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+
+/**
+ * struct ti_sci_genpd_dev_data: holds data needed for every device attached
+ * to this genpd
+ * @idx: index of the device that identifies it with the system
+ * control processor.
+ */
+struct ti_sci_genpd_dev_data {
+ int idx;
+};
+
+/**
+ * struct ti_sci_pm_domain: TI specific data needed for power domain
+ * @ti_sci: handle to TI SCI protocol driver that provides ops to
+ * communicate with system control processor.
+ * @dev: pointer to dev for the driver for devm allocs
+ * @pd: generic_pm_domain for use with the genpd framework
+ */
+struct ti_sci_pm_domain {
+ const struct ti_sci_handle *ti_sci;
+ struct device *dev;
+ struct generic_pm_domain pd;
+};
+
+#define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
+
+/**
+ * ti_sci_dev_id(): get prepopulated ti_sci id from struct dev
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns device_id stored from ti,sci_id property
+ */
+static int ti_sci_dev_id(struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ return sci_dev_data->idx;
+}
+
+/**
+ * ti_sci_dev_to_sci_handle(): get pointer to ti_sci_handle
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns ti_sci_handle to be used to communicate with system
+ * control processor.
+ */
+static const struct ti_sci_handle *ti_sci_dev_to_sci_handle(struct device *dev)
+{
+ struct generic_pm_domain *pd = pd_to_genpd(dev->pm_domain);
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(pd);
+
+ return ti_sci_genpd->ti_sci;
+}
+
+/**
+ * ti_sci_dev_start(): genpd device start hook called to turn device on
+ * @dev: pointer to device associated with this genpd to be powered on
+ */
+static int ti_sci_dev_start(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.get_device(ti_sci, idx);
+}
+
+/**
+ * ti_sci_dev_stop(): genpd device stop hook called to turn device off
+ * @dev: pointer to device associated with this genpd to be powered off
+ */
+static int ti_sci_dev_stop(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.put_device(ti_sci, idx);
+}
+
+static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(domain);
+ const struct ti_sci_handle *ti_sci = ti_sci_genpd->ti_sci;
+ struct ti_sci_genpd_dev_data *sci_dev_data;
+ struct generic_pm_domain_data *genpd_data;
+ int idx, ret = 0;
+
+ ret = of_property_read_u32(np, "ti,sci-id", &idx);
+ if (ret) {
+ dev_err(ti_sci_genpd->dev, "Cannot find ti,sci-id for %s\n",
+ dev_name(dev));
+ return -ENODEV;
+ }
+
+ /*
+ * Check the validity of the requested idx, if the index is not valid
+ * the PMMC will return a NAK here and we will not allocate it.
+ */
+ ret = ti_sci->ops.dev_ops.is_valid(ti_sci, idx);
+ if (ret)
+ return -EINVAL;
+
+ sci_dev_data = kzalloc(sizeof(*sci_dev_data), GFP_KERNEL);
+ if (!sci_dev_data)
+ return -ENOMEM;
+
+ sci_dev_data->idx = idx;
+
+ genpd_data = dev_gpd_data(dev);
+ genpd_data->data = sci_dev_data;
+
+ return 0;
+}
+
+static void ti_sci_pd_detach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ kfree(sci_dev_data);
+ genpd_data->data = NULL;
+}
+
+static const struct of_device_id ti_sci_pm_domain_matches[] = {
+ { .compatible = "ti,sci-pm-domain", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ti_sci_pm_domain_matches);
+
+static int ti_sci_pm_domain_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct ti_sci_pm_domain *ti_sci_pd;
+ int ret;
+
+ ti_sci_pd = devm_kzalloc(dev, sizeof(*ti_sci_pd), GFP_KERNEL);
+ if (!ti_sci_pd)
+ return -ENOMEM;
+
+ ti_sci_pd->ti_sci = devm_ti_sci_get_handle(dev);
+ if (IS_ERR(ti_sci_pd->ti_sci))
+ return PTR_ERR(ti_sci_pd->ti_sci);
+
+ ti_sci_pd->dev = dev;
+
+ ti_sci_pd->pd.attach_dev = ti_sci_pd_attach_dev;
+ ti_sci_pd->pd.detach_dev = ti_sci_pd_detach_dev;
+
+ ti_sci_pd->pd.dev_ops.start = ti_sci_dev_start;
+ ti_sci_pd->pd.dev_ops.stop = ti_sci_dev_stop;
+
+ pm_genpd_init(&ti_sci_pd->pd, NULL, true);
+
+ ret = of_genpd_add_provider_simple(np, &ti_sci_pd->pd);
+
+ return ret;
+}
+
+static struct platform_driver ti_sci_pm_domains_driver = {
+ .probe = ti_sci_pm_domain_probe,
+ .driver = {
+ .name = "ti_sci_pm_domains",
+ .of_match_table = ti_sci_pm_domain_matches,
+ },
+};
+module_platform_driver(ti_sci_pm_domains_driver);
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("TI System Control Interface (SCI) Power Domain driver");
+MODULE_AUTHOR("Dave Gerlach");
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox