* [PATCH v8 00/16] mmc: sdhci-msm: Add clk-rates, DDR, HS400 support
From: Ritesh Harjani @ 2016-11-16 16:00 UTC (permalink / raw)
To: ulf.hansson, linux-mmc, adrian.hunter, sboyd, andy.gross
Cc: shawn.lin, devicetree, linux-clk, david.brown, linux-arm-msm,
georgi.djakov, alex.lemberg, mateusz.nowak, Yuliy.Izrailov,
asutoshd, david.griego, stummala, venkatg, rnayak, pramod.gurav,
jeremymc, Ritesh Harjani
Hi,
This is v8 version of the patch series which adds support for MSM8996.
Adds HS400 driver support as well.
These are tested on internal msm8996 & db410c HW.
Changes from v7 -> v8 :-
1. Added patch 005 to add dt bindings for xo_clock.
2. Added patch 009 to factor out sdhci_enable_clock as discussed on v7 series.
2.a. Modified patch 010 by making use of sdhci_enable_clock.
2.b. Addressed Stephen's comment on patch 010 to call clk_set_rate unconditionally.
3. Addressed Stephen comments to remove unncessary one line comments, braces and other
minor comments.
4. Added changes from Jeremy in patch 002 for gcc-msm8994 as well for sdcc clk_rcg2_floor_ops.
minor comments.
v7 series was verified on msm8994 target by Jeremy McNicoll.
Older history :-
Below are the changes in v7.
Changes from v6 -> v7 :-
1. Removed patch "clk: Add clk_hw_get_clk() helper API to be used by clk providers"
in v7 as it was not required.
2. Addressed Stephen review comments on -
"clk: qcom: Add rcg ops to return floor value closest to the requested rate"
3. Addressed comments from Stephen to add xo_clock entry in the sdhc clock node.
Using the same xo_clock entry from DT to get the clk_rate of xo_clock used in
sdhci-msm driver. Patch 04 adds this entry into DT.
Patch 05 adds the driver support for xo_clock mentioned above.
Hence there is a minor change in Patch05, which can be reviewed and taken
into the tree.
IMHO, almost all patches are almost done and are ready to be accepted.
Will below process work out?
Patches 001 & 002 :- (clock changes) - Can go via Stephen's Boyd Tree.
Patches 004 & 010 :- (DTS changes) - Can go via Andy Gross.
Patches 003, 005-009 & 011-014 :- (sdhci-msm changes) - Adrian's tree.
Please let me know in case if anything else is required on above.
Changes from v5 -> v6 :-
1. Earlier in v5 series DT node was added to get the clk-rates table
needed for sdhci-msm driver. But this is removed in this(v6) patch series
and instead the clk changes are done in the clk driver as per Rob H comment.
2. Added clk driver changes(patch 1-3) to provide floor rate values of requested
clock for sdhc client.
For following boards- apq8084, msm8996, msm8916, msm8974.
3. Other minor patch comments were addressed.
Changes from v4 -> v5 :-
1. Added HS400 sdhci-msm controller specific changes:- (Patch 10, 11, 12)
2. Addressed comment from Adrian on Patch 07 @[3].
3. Addressed comment from Arnd on Patch 03, to directly add
clk_table into sdhci_msm_host. [4]
4. Addressed comment from Bjorn to not enforce having clk-rates property
in DT for older targets based on discussion at [5]
5. Retained Acks from Adrian on patches (01 & 02 & 06) where there were no
changes made while addressing above comments.
Older history:-
This is v4 version of the patch series.
Patches 01, 02, 05 & 06 were Acked-by Adrian.
Changes from v3 -> v4 :-
1. Addressed comments from Adrian on Patch 03, 07, 08.
2. Addressed comments from Bjorn on Patch 03.
3. Added clk-rate support for sdhc DT nodes to all MSM platforms.
in Pacth 04.
4. Rebased on next branch of Ulf.
Changes from v2 -> v3 :-
1. Addded Patch 01 based on Bjorn comment[2] -
This fixes/unrolls the poor coding style of read/writes of
registers from base sdhci-msm driver.
2. Fixed/unrolled poor style of reads/writes of registers in Patch 02,
based on Bjorn comment[2]. Also changed name of flag from
use_updated_dll_reset -> use_14lpp_dll_reset.
Changes from v1->v2 :-
1. Removed patch 06 & 08 from v1 patch series[1]
(which were introducing unnecessary quirks).
Instead have implemented __sdhci_msm_set_clock version of
sdhci_set_clock in sdhci_msm driver itself in patch 07 of
this patch series.
2. Enabled extra quirk (SDHCI_QUIRK2_PRESET_VALUE_BROKEN) in
patch 05 of this patch series.
Description of patches :-
This patchset adds clk-rates & other required changes to
upstream sdhci-msm driver from codeaurora tree.
It has been tested on a db410c Dragonboard and msm8996 based
platform.
Patch 0001-0003- Adds support in qcom clk driver to return
floor value of requested clock rate instead of ceil rate
for sdhc clients.
Patch 0004- Adds updated dll sequence for newer controllers
which has minor_version >= 0x42. This is required for msm8996.
MSM controller HW recommendation is to use the base MCI clock
and directly control this MCI clock at GCC in order to
change the clk-rate.
Patches 06-08 bring in required change for this to
sdhci-msm.
MSM controller would require 2x clock rate from source
for DDR bus speed modes. Patch 09 adds this support.
Patch 0010- adds DDR support in DT for sdhc1 of msm8916.
Patches 0011-0014- Adds HS400 support to sdhci-msm.
[1]:- http://www.spinics.net/lists/linux-mmc/msg38467.html
[2]:- http://www.spinics.net/lists/linux-mmc/msg38578.html
[3]:- https://patchwork.kernel.org/patch/9289345/
[4]:- https://www.spinics.net/lists/linux-mmc/msg39107.html
[5]:- http://www.spinics.net/lists/linux-mmc/msg38749.html
[6]:- https://patchwork.kernel.org/patch/9297381/
Rajendra Nayak (2):
clk: qcom: Add rcg ops to return floor value closest to the requested
rate
clk: qcom: Move all sdcc rcgs to use clk_rcg2_floor_ops
Ritesh Harjani (12):
mmc: sdhci-msm: Change poor style writel/readl of registers
ARM: dts: Add xo_clock to sdhc nodes on qcom platforms
dt-bindings: sdhci-msm: Add xo_clock property
mmc: sdhci-msm: Add get_min_clock() and get_max_clock() callback
mmc: sdhci-msm: Enable few quirks
mmc: sdhci: Factor out sdhci_enable_clock
mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
mmc: sdhci-msm: Add clock changes for DDR mode.
arm64: dts: qcom: msm8916: Add ddr support to sdhc1
mmc: sdhci-msm: Save the calculated tuning phase
mmc: sdhci-msm: Add calibration tuning for CDCLP533 circuit
sdhci: sdhci-msm: update dll configuration
Venkat Gopalakrishnan (2):
mmc: sdhci-msm: Update DLL reset sequence
mmc: sdhci-msm: Add HS400 platform support
.../devicetree/bindings/mmc/sdhci-msm.txt | 1 +
arch/arm/boot/dts/qcom-apq8084.dtsi | 16 +-
arch/arm/boot/dts/qcom-msm8974.dtsi | 16 +-
arch/arm64/boot/dts/qcom/msm8916.dtsi | 11 +-
arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +-
drivers/clk/qcom/clk-rcg.h | 1 +
drivers/clk/qcom/clk-rcg2.c | 76 ++-
drivers/clk/qcom/common.c | 16 +
drivers/clk/qcom/common.h | 2 +
drivers/clk/qcom/gcc-apq8084.c | 8 +-
drivers/clk/qcom/gcc-msm8916.c | 4 +-
drivers/clk/qcom/gcc-msm8974.c | 8 +-
drivers/clk/qcom/gcc-msm8994.c | 8 +-
drivers/clk/qcom/gcc-msm8996.c | 8 +-
drivers/mmc/host/sdhci-msm.c | 626 +++++++++++++++++++--
drivers/mmc/host/sdhci.c | 28 +-
drivers/mmc/host/sdhci.h | 1 +
17 files changed, 739 insertions(+), 100 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v4 1/3] bus: simple-pm: add support to pm clocks
From: Nayak, Rajendra @ 2016-11-16 15:50 UTC (permalink / raw)
To: Srinivas Kandagatla, Geert Uytterhoeven, Bjorn Helgaas
Cc: svarbanov, linux-pci, Bjorn Helgaas, Rob Herring,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
Geert Uytterhoeven, Kevin Hilman, Simon Horman, Linux PM list,
Nayak, Rajendra
In-Reply-To: <d61f62d1-7a7e-6d91-d278-0fd922cd77b5@linaro.org>
Hey Srini,
On 11/15/2016 4:55 PM, Srinivas Kandagatla wrote:
> + Rajendra (qcom,gdsc author)
[]..
>>
>>>> ---
>>>> drivers/bus/simple-pm-bus.c | 13 ++++++++++++-
>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
>>>> index c5eb46c..63b7e8c 100644
>>>> --- a/drivers/bus/simple-pm-bus.c
>>>> +++ b/drivers/bus/simple-pm-bus.c
>>>> @@ -11,6 +11,7 @@
>>>> #include <linux/module.h>
>>>> #include <linux/of_platform.h>
>>>> #include <linux/platform_device.h>
>>>> +#include <linux/pm_clock.h>
>>>> #include <linux/pm_runtime.h>
>>>>
>>>>
>>>> @@ -22,17 +23,26 @@ static int simple_pm_bus_probe(struct
>>>> platform_device *pdev)
>>>>
>>>> pm_runtime_enable(&pdev->dev);
>>>>
>>>> - if (np)
>>>> + if (np) {
>>>> + of_pm_clk_add_clks(&pdev->dev);
>>
>> This should work out-of-the-box (that's the actual purpose of this
>> driver),
>> if the platform code that registers your PM Domain would take care
>> of registering the clocks needed for PM management of the bus.
>
> Yep, if the pm domain provider takes care of the bus clks, then it would
> work.
>
> Am guessing that the clocks property in the DT node would be read by the
> PM domain provider and enable/disable during attach/detach callbacks.
> If that is true, then any device tree nodes which are not children of
> "simple-pm-bus" and consumers of power-domain provider would enable all
> (including non-bus clks) clks twice. Once in the power-domain provider
> and once in the actual driver. Is this expected behavior from
> power-domains in general?
>
>>
>> Adding of_pm_clk_add_clks() here will start managing all clocks of the
>> bus,
>> which may not be wanted on all platforms.
>>
> That was the purpose.
>
>
> Rajendra,
> Looks like qcom gdsc pm domain provider driver does not handle bus clks
> along with power-domain, Is this something we should do? Or the bus
> driver take care of it?
I did post some patches to support handling of clocks associated with
gdscs [1], but it got dropped at that point since there wasn't a
real user, besides there were some open issues wrt the handling of
!CONFIG_PM cases etc.
I will revive and repost those patches again now based on the
discussions last time around.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/362492.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/2] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Chen-Yu Tsai @ 2016-11-16 15:42 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Archit Taneja
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161116154232.872-1-wens-jdAy2FN1RRM@public.gmane.org>
The Hummingbird A31 board has a VGA DAC which converts RGB output
from the LCD interface to VGA analog signals.
Add nodes for the VGA DAC, its power supply, and enable this part
of the display pipeline.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 67 +++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 62287bd2aeb5..b168d6df2b30 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -63,6 +63,60 @@
stdout-path = "serial0:115200n8";
};
+ vga-connector {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_dac_out>;
+ };
+ };
+ };
+
+ vga-dac {
+ compatible = "dumb-vga-dac";
+ vdd-supply = <®_vga_3v3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_dac_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_dac_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ reg_vga_3v3: vga_3v3_regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vga-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = <&pio 7 25 GPIO_ACTIVE_HIGH>; /* PH25 */
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
@@ -253,6 +307,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_dac_in>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Chen-Yu Tsai @ 2016-11-16 15:42 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Archit Taneja
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161116154232.872-1-wens-jdAy2FN1RRM@public.gmane.org>
Some dumb VGA DACs are active components which require external power.
Add support for specifying a regulator as its power supply.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..164cbb15f04c 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for RGB input
- Video port 1 for VGA output
+Optional properties:
+- vdd-supply: Power supply for DAC
Example
-------
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..15b549f94307 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
#include <drm/drmP.h>
#include <drm/drm_atomic_helper.h>
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connector connector;
struct i2c_adapter *ddc;
+ struct regulator *vdd;
};
static inline struct dumb_vga *
@@ -124,8 +126,32 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
}
+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+ int ret = 0;
+
+ if (vga->vdd)
+ ret = regulator_enable(vga->vdd);
+
+ if (ret) {
+ DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
+ return;
+ }
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (vga->vdd)
+ regulator_disable(vga->vdd);
+}
+
static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+ .enable = dumb_vga_enable,
+ .disable = dumb_vga_disable,
};
static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +195,15 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+ vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
+ if (IS_ERR(vga->vdd)) {
+ ret = PTR_ERR(vga->vdd);
+ if (ret == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ vga->vdd = NULL;
+ dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
+ }
+
vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {
--
2.10.2
--
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 v4 0/2] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Chen-Yu Tsai @ 2016-11-16 15:42 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Archit Taneja
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi,
This is v4 of my sun6i DRM/KMS display enablement series. It adds
regulator support to the dumb-vga-dac bridge and enables the VGA
output on the A31 Hummingbird.
Changes since v3:
- Add Rob's Ack.
- Fix up enable/disable callbacks as Archit suggested.
- Dropped pinmux settings for GPIO pin.
Changes since v2:
- Changed the enable-gpio of dumb-vga-dac to vdd-supply regulator.
This better matches the hardware that I have: the DAC has a fixed
regulator dropping the voltage from the board-wide 5V to 3.3V the
DAC uses. The regulator is controlled through a GPIO pin.
- Renamed the node of the VGA connector from "vga" to "vga-connector".
- Renamed the node of the VGA DAC from "bridge" to "vga-dac".
Regards
ChenYu
Chen-Yu Tsai (2):
drm/bridge: dumb-vga-dac: Support a VDD regulator supply
ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA
bridge
.../bindings/display/bridge/dumb-vga-dac.txt | 2 +
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 67 ++++++++++++++++++++++
drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 +++++++++++
3 files changed, 104 insertions(+)
--
2.10.2
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 15:38 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, devicetree, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161116150628.GI23231@lunn.ch>
On Wed, 2016-11-16 at 16:06 +0100, Andrew Lunn wrote:
> On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
> >
> > On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > >
> > > >
> > > >
> > > > There two kind of PHYs supporting eee, the one advertising eee
> > > > by
> > > > default (like realtek) and the one not advertising it (like
> > > > micrel).
> >
> > This is just the default register value.
> >
> > >
> > >
> > > I don't know too much about EEE. So maybe a dumb question. Does
> > > the
> > > MAC need to be involved? Or is it just the PHY?
> > >
> > > If the MAC needs to be involved, the PHY should not be
> > > advertising
> > > EEE
> > > unless the MAC asks for it by calling phy_init_eee(). If this is
> > > true,
> > > maybe we need to change the realtek driver, and others in that
> > > class.
> >
> > As far I understand, the advertised capabilities are exchanged
> > during
> > the auto-negotiation.
> >
> > At this stage, if the advertisement is disabled (regarless of the
> > actual support) on either side of the link, there will be no low
> > power
> > idle state on the Tx nor the Rx path.
> >
> > If the advertisement is enabled on both side but we don't call
> > phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>
> What i was trying to find out is, if the MAC needs to support EEE as
> well as the PHY, what happens when the MAC does not support EEE, but
> the PHYs do negotiate EEE? Does it break?
Interesting question. In a regular case, I suppose it should be fine.
As you would have LPI only on the Rx path this should be transparent to
the MAC. That's my understanding. Maybe people knowing EEE better than
me could confirm (or not) ? Peppe? Alexandre?
I just checked with the OdroidC2, I disabled eee support by forcing
"dma_cap.eee = 0" in stmmac_get_hw_features. As expected, no tx_LPI
interrupts but plenty of rx_LPI interrupts.
What was not expected is test failing like before.
So in our case, having LPI on the Rx path is fine for receiving data,
but not for sending.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Jerome Brunet @ 2016-11-16 15:20 UTC (permalink / raw)
To: Rob Herring
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Florian Fainelli, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161116151104.5sfcqjyvrzre5pkn@rob-hp-laptop>
On Wed, 2016-11-16 at 09:11 -0600, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > ---
> > .../devicetree/bindings/net/realtek-phy.txt | 20
> > ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/realtek-
> > phy.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt
> > b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > new file mode 100644
> > index 000000000000..dc2845a6b387
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > @@ -0,0 +1,20 @@
> > +Realtek Ethernet PHY
> > +
> > +Some boards require special tuning values of the phy.
> > +
> > +Optional properties:
> > +
> > +realtek,disable-eee-1000t:
> > +realtek,disable-eee-100tx:
>
> Make these generic/common.
Same feedback from the net folks. Will do.
Thx Rob
>
> >
> > + If set, respectively disable 1000-BaseT and 100-BaseTx energy
> > efficient
> > + ethernet capabilty advertisement
> > + default: Leave the phy default settings unchanged (capabilities
> > advertised)
> > +
> > +Example:
> > +
> > +&mdio0 {
> > + ethernetphy0: ethernet-phy@0 {
> > + reg = <0>;
> > + realtek,disable-eee-1000t;
> > + };
> > +};
> > --
> > 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] DW DMAC: update device tree
From: Andy Shevchenko @ 2016-11-16 15:18 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, 2016-11-16 at 16:56 +0300, Eugeniy Paltsev wrote:
> It wasn't possible to enable some features like
> memory-to-memory transfers or multi block transfers via DT.
> It is fixed by these patches.
>
> * Rename is_private to is-private as ordered by DT policy.
> (just for cleanup) The change leaves the support for the
> old format.
>
> * Add is-memcpu property, so it is possible to
> enable memory-to-memory transfers support via DT.
>
> * Add hw-llp property, so it is possible to enable
> hardware multi block transfers support via DT.
>
> * Update DW DMAC device tree documentation.
I have few comments I posted. Besides that don't forget about current
users of the DT properties you standardized (by naming). Better you
convert them at the same time. Older DT (blobs) are being still
supported.
Otherwise looks okay after you address all my comments and maybe others
will do some. The DT people ACK is a must before this goes somewhere.
Also, please keep Cc list as small as possible. For example I'm not sure
Viresh has time to look at them, but he might keep an eye on the
dmaengine mailing list. Same about Dan.
>
> Eugeniy Paltsev (4):
> DW DMAC: rename is_private property as ordered by DT policy
> DW DMAC: add is-memcpu property to device tree
> DW DMAC: add hw-llp property to device tree
> Update device tree Synopsys DW DMAC documentation
>
> Documentation/devicetree/bindings/dma/snps-dma.txt | 10 ++++++++--
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 10 ++++++++++
> include/linux/platform_data/dma-dw.h | 4 ++--
> 4 files changed, 21 insertions(+), 5 deletions(-)
>
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
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 1/6] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Rob Herring @ 2016-11-16 15:15 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: linux-iio, linux-arm-kernel, devicetree, linux-kernel, jic23,
linux, mark.rutland, mcoquelin.stm32, alexandre.torgue, lars,
knaack.h, pmeerw
In-Reply-To: <1479223861-21747-2-git-send-email-fabrice.gasnier@st.com>
On Tue, Nov 15, 2016 at 04:30:56PM +0100, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 83 ++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/4] DW DMAC: add hw-llp property to device tree
From: Andy Shevchenko @ 2016-11-16 15:13 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree
Cc: mark.rutland, vinod.koul, vireshk, linux-kernel, robh+dt,
dmaengine, dan.j.williams, linux-snps-arc
In-Reply-To: <1479304615-11360-4-git-send-email-Eugeniy.Paltsev@synopsys.com>
On Wed, 2016-11-16 at 16:56 +0300, Eugeniy Paltsev wrote:
> Several versions of DW DMAC have multi block transfers hardware
> support. Hardware support of multi block transfers is disabled
> by default if we use DT to configure DMAC and software emulation
> of multi block transfers used instead.
> Add hw-llp property, so it is possible to enable hardware
> multi block transfers (if present) via DT.
You forgot to explain the conversion from per device value to per
channel one.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
> ---
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 5 +++++
> include/linux/platform_data/dma-dw.h | 4 ++--
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index c2c0a61..e3ff4ea 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
> (dwc_params >> DWC_PARAMS_MBLK_EN &
> 0x1) == 0;
> } else {
> dwc->block_size = pdata->block_size;
> - dwc->nollp = pdata->is_nollp;
> + dwc->nollp = pdata->hw_llp[i];
> }
> }
>
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index daeceac..2722e60 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -151,6 +151,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
> pdata->data_width[tmp] = BIT(arr[tmp] &
> 0x07);
> }
>
> + if (!of_property_read_u32_array(np, "hw-llp", arr,
> nr_masters)) {
> + for (tmp = 0; tmp < nr_masters; tmp++)
> + pdata->hw_llp[tmp] = arr[tmp];
> + }
> +
> return pdata;
> }
> #else
> diff --git a/include/linux/platform_data/dma-dw.h
> b/include/linux/platform_data/dma-dw.h
> index 5f0e11e..5bc8124 100644
> --- a/include/linux/platform_data/dma-dw.h
> +++ b/include/linux/platform_data/dma-dw.h
> @@ -40,19 +40,18 @@ struct dw_dma_slave {
> * @is_private: The device channels should be marked as private and
> not for
> * by the general purpose DMA channel allocator.
> * @is_memcpy: The device channels do support memory-to-memory
> transfers.
> - * @is_nollp: The device channels does not support multi block
> transfers.
> * @chan_allocation_order: Allocate channels starting from 0 or 7
> * @chan_priority: Set channel priority increasing from 0 to 7 or 7
> to 0.
> * @block_size: Maximum block size supported by the controller
> * @nr_masters: Number of AHB masters supported by the controller
> * @data_width: Maximum data width supported by hardware per AHB
> master
> * (in bytes, power of 2)
> + * @hw_llp: Multi block transfers supported by hardware per AHB
> master.
> */
> struct dw_dma_platform_data {
> unsigned int nr_channels;
> bool is_private;
> bool is_memcpy;
> - bool is_nollp;
> #define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
> unsigned char chan_allocation_order;
> @@ -62,6 +61,7 @@ struct dw_dma_platform_data {
> unsigned int block_size;
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> + unsigned char hw_llp[DW_DMA_MAX_NR_MASTERS];
> };
>
> #endif /* _PLATFORM_DATA_DMA_DW_H */
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [PATCH 2/4] DW DMAC: add is-memcpu property to device tree
From: Andy Shevchenko @ 2016-11-16 15:12 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree
Cc: robh+dt, mark.rutland, linux-kernel, vireshk, dan.j.williams,
vinod.koul, dmaengine, linux-snps-arc
In-Reply-To: <1479304615-11360-3-git-send-email-Eugeniy.Paltsev@synopsys.com>
On Wed, 2016-11-16 at 16:56 +0300, Eugeniy Paltsev wrote:
> Memory-to-memory dma transfers were disabled by default if we
> used DT to cofigure DMAC.
> Add is-memcpu property, so it became possible to enable
> memory-to-memory transfers support via DT.
Fix "memcpu" to "memcpy" everywhere you use it.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
> ---
> drivers/dma/dw/platform.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index 4103f1d..daeceac 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -131,6 +131,9 @@ dw_dma_parse_dt(struct platform_device *pdev)
> else if (of_property_read_bool(np, "is-private"))
> pdata->is_private = true;
>
> + if (of_property_read_bool(np, "is-memcpu"))
> + pdata->is_memcpy = true;
> +
> if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH 1/4] DW DMAC: rename is_private property as ordered by DT policy
From: Andy Shevchenko @ 2016-11-16 15:11 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree
Cc: mark.rutland, vinod.koul, vireshk, linux-kernel, robh+dt,
dmaengine, dan.j.williams, linux-snps-arc
In-Reply-To: <1479304615-11360-2-git-send-email-Eugeniy.Paltsev@synopsys.com>
On Wed, 2016-11-16 at 16:56 +0300, Eugeniy Paltsev wrote:
> Rename is_private to is-private as ordered by DT policy.
> The change leaves the support for the old format.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
> ---
> drivers/dma/dw/platform.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index 5bda0eb..4103f1d 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -128,6 +128,8 @@ dw_dma_parse_dt(struct platform_device *pdev)
>
> if (of_property_read_bool(np, "is_private"))
> pdata->is_private = true;
> + else if (of_property_read_bool(np, "is-private"))
> + pdata->is_private = true;
First, try new one, then fall back.
>
> if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Rob Herring @ 2016-11-16 15:11 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Florian Fainelli, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479220154-25851-3-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/net/realtek-phy.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt b/Documentation/devicetree/bindings/net/realtek-phy.txt
> new file mode 100644
> index 000000000000..dc2845a6b387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> @@ -0,0 +1,20 @@
> +Realtek Ethernet PHY
> +
> +Some boards require special tuning values of the phy.
> +
> +Optional properties:
> +
> +realtek,disable-eee-1000t:
> +realtek,disable-eee-100tx:
Make these generic/common.
> + If set, respectively disable 1000-BaseT and 100-BaseTx energy efficient
> + ethernet capabilty advertisement
> + default: Leave the phy default settings unchanged (capabilities advertised)
> +
> +Example:
> +
> +&mdio0 {
> + ethernetphy0: ethernet-phy@0 {
> + reg = <0>;
> + realtek,disable-eee-1000t;
> + };
> +};
> --
> 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
--
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 4/4] Update device tree Synopsys DW DMAC documentation
From: Andy Shevchenko @ 2016-11-16 15:10 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479304615-11360-5-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, 2016-11-16 at 16:56 +0300, Eugeniy Paltsev wrote:
> * Rename is_private to is-private as ordered by DT policy.
> The change leaves the support for the old format.
>
> * Add is-memcpu property, so it is possible to
> enable memory-to-memory transfers support via DT.
>
> * Add hw-llp property, so it is possible to enable
> hardware multi block transfers support via DT.
>
> Fix white spaces.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/dma/snps-dma.txt | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
> b/Documentation/devicetree/bindings/dma/snps-dma.txt
> index 0f55832..d41d960 100644
> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> @@ -20,13 +20,19 @@ Required properties:
> Deprecated properties:
> - data_width: Maximum data width supported by hardware per AHB master
> (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
> +- is_private: The device channels should be marked as private and not
> for by the
> + general purpose DMA channel allocator. False if not passed.
This...
>
>
> Optional properties:
> - interrupt-parent: Should be the phandle for the interrupt
> controller
> that services interrupts for this device
> -- is_private: The device channels should be marked as private and not
> for by the
> +- is-private: The device channels should be marked as private and not
> for by the
> general purpose DMA channel allocator. False if not passed.
...and this is a part of patch 1.
> +- is-memcpu: The device channels do support memory-to-memory
memcpy
> transfers.
> False
> + if not passed.
> +- hw-llp: Multi block transfers supported by hardware per AHB master.
> + 0 (default): not supported, 1: supported.
Overall, since we are going to expose some properties to the Device Tree
I would really think twice about naming. Better if we reuse something
existing already.
So, what I can see is
dmacap,private
dmacap,memcpy
Here is a selling point as well, i.e. standardization.
'hw-llp' sounds too tricky, perhaps 'multi-block' is better and could be
re-used.
>
> Example:
>
> @@ -56,7 +62,7 @@ The four cells in order are:
> 4. Peripheral master for transfers on allocated channel
>
> Example:
> -
> +
No, no need to touch this.
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
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] PCI: qcom: add support to msm8996 PCIE controller
From: Rob Herring @ 2016-11-16 15:08 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov-NEYub+7Iv8PQT0dZR+AlfA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479219837-7868-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Nov 15, 2016 at 02:23:57PM +0000, Srinivas Kandagatla wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
s/pcie/PCIe/
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
s/pcie/PCIe/
> pipe clocks are only setup after the phy is powered on.
> It also adds ltssm_enable callback as it is very much different to other
> supported SOCs in the driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Stanimir Varbanov <svarbanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
> ---
>
> Changes since v4:
> - removed duplicate define spotted by Stan.
> - renamed halt register to remove msm8996 suggested by Stan.
> - dropped simple-pm-bus and runtime pm patches as these can
> potentially go into pm domain provider.
>
> .../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
> drivers/pci/host/pcie-qcom.c | 175 ++++++++++++++++++++-
> 2 files changed, 236 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> index 4059a6f..141d8c3 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -7,6 +7,7 @@
> - "qcom,pcie-ipq8064" for ipq8064
> - "qcom,pcie-apq8064" for apq8064
> - "qcom,pcie-apq8084" for apq8084
> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>
> - reg:
> Usage: required
> @@ -92,6 +93,17 @@
> - "aux" Auxiliary (AUX) clock
> - "bus_master" Master AXI clock
> - "bus_slave" Slave AXI clock
> +
> +- clock-names:
> + Usage: required for msm8996/apq8096
> + Value type: <stringlist>
> + Definition: Should contain the following entries
> + - "pipe" Pipe Clock driving internal logic.
> + - "aux" Auxiliary (AUX) clock.
> + - "cfg" Configuration clk.
> + - "bus_master" Master AXI clock.
> + - "bus_slave" Slave AXI clock.
> +
> - resets:
> Usage: required
> Value type: <prop-encoded-array>
> @@ -115,7 +127,7 @@
> - "core" Core reset
>
> - power-domains:
> - Usage: required for apq8084
> + Usage: required for apq8084 and msm8996/apq8096
> Value type: <prop-encoded-array>
> Definition: A phandle and power domain specifier pair to the
> power domain which is responsible for collapsing
> @@ -231,3 +243,56 @@
> pinctrl-0 = <&pcie0_pins_default>;
> pinctrl-names = "default";
> };
> +
> +* Example for apq8096:
Do you really need an example for every chip?
> +
> + pcie@608000{
> + compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
> + power-domains = <&gcc PCIE1_GDSC>;
> + bus-range = <0x00 0xff>;
> + num-lanes = <1>;
> +
> + reg = <0x00608000 0x2000>,
> + <0x0d000000 0xf1d>,
> + <0x0d000f20 0xa8>,
> + <0x0d100000 0x100000>;
> +
> + reg-names = "parf", "dbi", "elbi", "config";
> +
> + phys = <&pcie_phy 1>;
> + phy-names = "pciephy";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
> + <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
> +
> + interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
> + interrupt-names = "msi";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> + <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> + <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> + <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
> + pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
> +
> + vdda-1p8-supply = <&pm8994_l12>;
> + vdda-supply = <&pm8994_l28>;
> + linux,pci-domain = <1>;
> +
> + clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
> + <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
> +
> + clock-names = "pipe",
> + "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave";
> + };
--
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 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 15:06 UTC (permalink / raw)
To: Jerome Brunet
Cc: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479307890.17538.40.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > >
> > > There two kind of PHYs supporting eee, the one advertising eee by
> > > default (like realtek) and the one not advertising it (like
> > > micrel).
>
> This is just the default register value.
>
> >
> > I don't know too much about EEE. So maybe a dumb question. Does the
> > MAC need to be involved? Or is it just the PHY?
> >
> > If the MAC needs to be involved, the PHY should not be advertising
> > EEE
> > unless the MAC asks for it by calling phy_init_eee(). If this is
> > true,
> > maybe we need to change the realtek driver, and others in that class.
>
> As far I understand, the advertised capabilities are exchanged during
> the auto-negotiation.
>
> At this stage, if the advertisement is disabled (regarless of the
> actual support) on either side of the link, there will be no low power
> idle state on the Tx nor the Rx path.
>
> If the advertisement is enabled on both side but we don't call
> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
What i was trying to find out is, if the MAC needs to support EEE as
well as the PHY, what happens when the MAC does not support EEE, but
the PHYs do negotiate EEE? Does it break?
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 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 14:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161116132337.GD19962-g2DYL2Zd6BY@public.gmane.org>
On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> >
> > There two kind of PHYs supporting eee, the one advertising eee by
> > default (like realtek) and the one not advertising it (like
> > micrel).
This is just the default register value.
>
> I don't know too much about EEE. So maybe a dumb question. Does the
> MAC need to be involved? Or is it just the PHY?
>
> If the MAC needs to be involved, the PHY should not be advertising
> EEE
> unless the MAC asks for it by calling phy_init_eee(). If this is
> true,
> maybe we need to change the realtek driver, and others in that class.
As far I understand, the advertised capabilities are exchanged during
the auto-negotiation.
At this stage, if the advertisement is disabled (regarless of the
actual support) on either side of the link, there will be no low power
idle state on the Tx nor the Rx path.
If the advertisement is enabled on both side but we don't call
phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>
> 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: specifying order of /dev/mmcblk devices via device-tree?
From: Ulf Hansson @ 2016-11-16 14:45 UTC (permalink / raw)
To: Mark Rutland
Cc: Tim Harvey, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161028153755.GL5806@leverpostej>
On 28 October 2016 at 17:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I have an IMX6 board that has the following:
>> sdhc1: mmc0: sdio radio
>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>
>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>> registered as /dev/mmcblk1 so that permanent storage is the first
>> mmcblk device as I think this is more intuitive however currently
>> these get instanced in the order they appear in the imx6qdl.dtsi
>> device-tree configuration and are not able to be mapped the way I want
>> them in my dts file.
>>
>> Is there a way, or if not is there a desire for a way, to specify the
>> order of /dev/mmcblk devices via device-tree?
>
> As with many other devices, there is no standard way of controlling the
> Linux enumeration (and given the ID space is shared with other dynamic
> devices it's not something that could generally work).
>
> These should be refererd to by UUID if possible.
>
> If not, we could cosider adding a by-dt-path or something like that.
So does that mean you think using "DT aliases" would be okay? As
Javier pointed out, there have been some attempts [1] for that, but
they didn't make it.
Perhaps we need to re-consider, and if so please re-review the DT
bindings patch from that series.
Kind regards
Uffe
[1]
https://lkml.org/lkml/2016/4/29/610 or
http://www.spinics.net/lists/linux-mmc/msg36701.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-16 14:39 UTC (permalink / raw)
To: Rob Herring
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20161116133331.miem6us563uu62t7@rob-hp-laptop>
On 11/16/16 15:33, Rob Herring wrote:
>> +Optional properties
>> > + - reg: I2C address. If and only if present the driver node
>> > + should be placed into the i2c controller node where the
>> > + tfp410 i2c is connected to (the current implementation does
>> > + not yet support this).
> So this chip can work without programming I guess?
>
Yes. Just powering it up is enough for most application.
> reg should only be not present if I2C is not connected in the design. It
> can't be a function of what the driver supports. In otherwords, you
> can't be moving this node around based on when you add I2C control.
>
Ok, I'll try to implement a dummy i2c driver at the same time too. I can
not test anything related to it because I do not have a piece of HW with
tfp410 i2c wires connected, but it should not matter as long as I am
able to probe it as a i2c client.
Thanks,
Jyri
--
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: ethernet: faraday: To support device tree usage.
From: Andrew Lunn @ 2016-11-16 14:37 UTC (permalink / raw)
To: Greentime Hu; +Cc: netdev, devicetree
In-Reply-To: <CAEbi=3esyRi4cnUNf4uPKCQtyRekBRo81Frd=BSJy8qf=3uc+A@mail.gmail.com>
On Wed, Nov 16, 2016 at 10:26:52PM +0800, Greentime Hu wrote:
> On Wed, Nov 16, 2016 at 9:47 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Wed, Nov 16, 2016 at 04:43:15PM +0800, Greentime Hu wrote:
> >> To support device tree usage for ftmac100.
> >>
> >> Signed-off-by: Greentime Hu <green.hu@gmail.com>
> >> ---
> >> drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
> >> index dce5f7b..81dd9e1 100644
> >> --- a/drivers/net/ethernet/faraday/ftmac100.c
> >> +++ b/drivers/net/ethernet/faraday/ftmac100.c
> >> @@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> +static const struct of_device_id mac_of_ids[] = {
> >> + { .compatible = "andestech,atmac100" },
> >> + { }
> >
> > andestech is not in
> > Documentation/devicetree/bindings/vendor-prefixes.txt Please provide a
> > separate patch adding it.
> OK. I will provide another patch to add andestech.
>
> > Humm, why andestech? Why not something based around faraday
> > technology?
> It is because we use the same ftmac100 IP provided from faraday
> technology but I am now using it in andestech SoC.
Please make sure you get an acked-by: from the device tree
maintainers. They might want you to use faraday, since that is the
original IP provider. For example, all Synopsys licensed IP uses
"snps,XXX", not the SoC vendor with the license.
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/3] remoteproc: qcom: Encapsulate pvt data structure for q6v56 hexagon.
From: Avaneesh Kumar Dwivedi @ 2016-11-16 14:02 UTC (permalink / raw)
To: Rob Herring
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Ohad Ben-Cohen,
Mark Rutland, open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20161110203013.fphvzd4df3zvjdfi@rob-hp-laptop>
On 11/11/2016 2:00 AM, Rob Herring wrote:
> On Fri, Nov 04, 2016 at 07:30:54PM +0530, Avaneesh Kumar Dwivedi wrote:
>> Encapsulate resources specific to each version of hexagon chip to
>> device node to avoid conditional check for manipulation of those
>> resources in driver code.
>>
>> Signed-off-by: Avaneesh Kumar Dwivedi <akdwived-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 1 +
>> drivers/remoteproc/qcom_q6v5_pil.c | 137 ++++++++++++++++++---
>> 2 files changed, 120 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> index 57cb49e..cbc165c 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> @@ -8,6 +8,7 @@ on the Qualcomm Hexagon core.
>> Value type: <string>
>> Definition: must be one of:
>> "qcom,q6v5-pil"
>> + "qcom,q6v56-pil"
> Perhaps some explanation in the commit message about what these magic
> numbers mean?
"v56" represent class of hexagon chip, which again is
differentiated based on version number. Two
different MSM SOC may use same class of hexagon chip. example is as
below.
msm8974 q6v5 version 5.0.0
msm8916 q6v5 version 5.1.1
>
> 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 4/4] Update device tree Synopsys DW DMAC documentation
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
* Rename is_private to is-private as ordered by DT policy.
The change leaves the support for the old format.
* Add is-memcpu property, so it is possible to
enable memory-to-memory transfers support via DT.
* Add hw-llp property, so it is possible to enable
hardware multi block transfers support via DT.
Fix white spaces.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..d41d960 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -20,13 +20,19 @@ Required properties:
Deprecated properties:
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+- is_private: The device channels should be marked as private and not for by the
+ general purpose DMA channel allocator. False if not passed.
Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
-- is_private: The device channels should be marked as private and not for by the
+- is-private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- is-memcpu: The device channels do support memory-to-memory transfers. False
+ if not passed.
+- hw-llp: Multi block transfers supported by hardware per AHB master.
+ 0 (default): not supported, 1: supported.
Example:
@@ -56,7 +62,7 @@ The four cells in order are:
4. Peripheral master for transfers on allocated channel
Example:
-
+
serial@e0000000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xe0000000 0x1000>;
--
2.5.5
^ permalink raw reply related
* [PATCH 3/4] DW DMAC: add hw-llp property to device tree
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add hw-llp property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +++++
include/linux/platform_data/dma-dw.h | 4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..e3ff4ea 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = pdata->hw_llp[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index daeceac..2722e60 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -151,6 +151,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "hw-llp", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->hw_llp[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..5bc8124 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @hw_llp: Multi block transfers supported by hardware per AHB master.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char hw_llp[DW_DMA_MAX_NR_MASTERS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH 2/4] DW DMAC: add is-memcpu property to device tree
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Memory-to-memory dma transfers were disabled by default if we
used DT to cofigure DMAC.
Add is-memcpu property, so it became possible to enable
memory-to-memory transfers support via DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 4103f1d..daeceac 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -131,6 +131,9 @@ dw_dma_parse_dt(struct platform_device *pdev)
else if (of_property_read_bool(np, "is-private"))
pdata->is_private = true;
+ if (of_property_read_bool(np, "is-memcpu"))
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ permalink raw reply related
* [PATCH 1/4] DW DMAC: rename is_private property as ordered by DT policy
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Rename is_private to is-private as ordered by DT policy.
The change leaves the support for the old format.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..4103f1d 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -128,6 +128,8 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ else if (of_property_read_bool(np, "is-private"))
+ pdata->is_private = true;
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ 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