* [PATCH] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C
From: Vivien Didelot @ 2017-01-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, kernel, Andrey Smirnov, Shawn Guo, Rob Herring,
Mark Rutland, Russell King, Sascha Hauer, Stefan Agner,
devicetree, andrew, Vivien Didelot, Nikita Yushchenko, cphealy
The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
chips. Add an "eeprom-length" property to allow access from ethtool.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index fbedb7bb3628..6a45bd24ffe6 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -71,6 +71,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 0>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
@@ -128,6 +129,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 1>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Steve Longerbeam @ 2017-01-12 23:40 UTC (permalink / raw)
To: Tim Harvey, Steve Longerbeam
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
Russell King - ARM Linux, mchehab, Hans Verkuil, Nick Dyer,
markus.heiser, Philipp Zabel, laurent.pinchart+renesas, bparrot,
geert, Arnd Bergmann, Sudip Mukherjee, minghsiu.tsai, Tiffany Lin,
Jean-Christophe TROTIN, Simon Horman
In-Reply-To: <CAJ+vNU1ci=fbeemJcBGCAk40PETdcov7Fm112F5FePL9SR4cFQ@mail.gmail.com>
On 01/12/2017 11:37 AM, Tim Harvey wrote:
> On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>> Add pinctrl groups for both GPT input capture channels.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> index 967c3b8..495709f 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> @@ -457,6 +457,18 @@
>> >;
>> };
>>
>> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
>> + >;
>> + };
>> +
>> pinctrl_spdif: spdifgrp {
>> fsl,pins = <
>> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
>> --
> Steve,
>
> These are not used anywhere.
Yes, maybe I should just remove this patch for now. I'm only keeping it
because eventually it will be needed to support i.MX6 input capture.
Steve
^ permalink raw reply
* Re: [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Florian Fainelli @ 2017-01-13 0:07 UTC (permalink / raw)
To: Jon Mason, Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484236210-16067-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 01/12/2017 07:50 AM, Jon Mason wrote:
> The range size for axi is 0x2 bytes too small, as the QSPI needs
> 0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
> been observed with this shortcoming, but fixing it for correctness.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Applied to devicetree/fixes thanks Jon.
--
Florian
--
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 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-13 0:17 UTC (permalink / raw)
To: Wolfram Sang; +Cc: peda, robh+dt, mark.rutland, linux-i2c, devicetree
In-Reply-To: <20170112191514.dpusqnbqahayx6j3@ninjato>
On 13/01/2017 03:15, Wolfram Sang wrote:
> On Mon, Jan 09, 2017 at 05:02:54PM +0800, Phil Reid wrote:
>> Various muxes can aggregate multiple interrupts from each i2c bus.
>> All of the muxes with interrupt support combine the active low irq lines
>> using an internal 'and' function and generate a combined active low
>> output. The muxes do provide the ability to read a control register to
>> determine which irq is active. By making the mux an irq controller isr
>> latency can potentially be reduced by reading the status register and
>> then only calling the registered isr on that bus segment.
>>
>> As there is no irq masking on the mux irq are disabled until irq_unmask is
>> called at least once.
>>
>> Signed-off-by: Phil Reid <preid@electromag.com.au>
>
> Is the ack from Peda here forgotten or still missing?
>
> @peda: Once you are happy, do you want to take these patches via your
> shiny new mux-tree or do you prefer if I pick them?
>
G'day Wolfram,
I think he was hoping someone else would have a look at it based on this
feedback.
On 2017-01-04 15:13, Peter Rosin wrote:
> Irqs are not my strong point, I would prefer if someone else also had
> a look. And there are some comments below...
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCHv5 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2017-01-13 0:38 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Russell King, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez
In-Reply-To: <1484142403-11556-1-git-send-email-amelie.delaunay-qxv4g6HH51o@public.gmane.org>
On 11/01/2017 at 14:46:43 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/rtc/Kconfig | 11 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-stm32.c | 727 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 739 insertions(+)
> create mode 100644 drivers/rtc/rtc-stm32.c
>
This didn't apply cleanly, please check rtc-next. I don't think I made
any mistake as the issue was only in Kconfig. You probably based your
patches on 4.9 instead of 4.10-rc1.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCHv3 2/8] dt-bindings: document the STM32 RTC bindings
From: Alexandre Belloni @ 2017-01-13 0:39 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Russell King, rtc-linux, devicetree,
linux-arm-kernel, linux-kernel, Gabriel Fernandez
In-Reply-To: <1483623809-29937-3-git-send-email-amelie.delaunay@st.com>
On 05/01/2017 at 14:43:23 +0100, Amelie Delaunay wrote :
> This patch adds documentation of device tree bindings for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
From: Kevin Hilman @ 2017-01-13 0:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482319894-656-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
> MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
> the Tx path). The problem seems to come from the phy Rx path, entering the
> LPI state.
>
> Disabling EEE advertisement on the phy prevent this feature to be
> negociated with the link partner and solve the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>
> This patch is based on Linus recent master branch [0]
> This patch depends on the series [1] which has been merged in this branch.
>
> 0: ba6d973f78eb ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 1: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
> Fix integration of eee-broken-modes
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..d8933e9e9a5a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -147,6 +147,18 @@
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + eee-broken-1000t;
> + };
> + };
There's already an MDIO node in the meson-gx.dtsi (using the same
compatible), shouldn't you just override that and add the new
properties?
What would make things easier is if the names were like Martin used in
his reset patch, so that when I merge them together it's not a major
conflict.
Thanks,
Kevin
[1] https://patchwork.kernel.org/patch/9459409/
--
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 v20 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2017-01-13 1:27 UTC (permalink / raw)
To: Rob Herring, Jassi Brar, Matthias Brugger
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
YT Shen, Daoyuan Huang, Damon Chu, Josh-YC Liu, Glory Hung,
Jiaguang Zhang, Dennis-YC Hsieh
In-Reply-To: <1483499169-16329-1-git-send-email-hs.liao@mediatek.com>
On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.10-rc2.
>
> Changes since v19:
> - rebase to v4.10-rc2
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> mailbox: mediatek: Add Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> soc: mediatek: Add Mediatek CMDQ helper
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 596 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 12 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 75 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 174 ++++++
> 10 files changed, 1233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comments on CMDQ v20?
Thanks.
HS
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Daniel Kurtz @ 2017-01-13 2:30 UTC (permalink / raw)
Cc: Dawei Chien, Javi Merino, Daniel Kurtz, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Matthias Brugger, Hans Verkuil,
Mauro Carvalho Chehab, Tiffany Lin, CK Hu, Andrew-CT Chen,
Sascha Hauer, Minghsiu Tsai, Yong Wu, Chunfeng Yun,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency. Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.
[0] Documentation/thermal/power_allocator.txt
According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map@0 {
trip = <&target>;
cooling-device = <&cpu0 0 0>;
- contribution = <1024>;
+ contribution = <3072>;
};
map@1 {
trip = <&target>;
cooling-device = <&cpu2 0 0>;
- contribution = <2048>;
+ contribution = <1024>;
};
};
};
--
2.11.0.390.gc69c2f50cf-goog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2017-01-13 3:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, robh+dt@kernel.org,
kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170112220536.GP17126@codeaurora.org>
> Subject: Re: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
>
> > > > +
> > > > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> > >
> > > All these should be const char * const unless something is wrong.
> >
> > If changed to 'const char * const', it vill has argument type mismatch
> > error, as imx_clk_* wrapper function has argument type 'const char *'.
>
> Hmm that's unfortunate.
>
> >
> > >
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > + clk_prepare_enable(clks[clks_init_on[i]]);
> > >
> > > Critical clocks?
> >
> > Yes, these clocks must be always on.
> >
> > >
> > > > +
> > > > + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
> > >
> > > The phy driver can't enable these?
> >
> > The reason why we enable these two clks here is in below commit commit
> > a5120e89e7e187a91852896f586876c7a2030804
> > Author: Peter Chen <peter.chen@freescale.com>
> > Date: Fri Jan 18 10:38:05 2013 +0800
> > ARM i.MX6: change mxs usbphy clock usage
> >
>
> So can we mark these clks with CLK_IS_CRITICAL flag then instead?
> Or are they disabled out of the bootloader?
>
Sure, using 'CLK_IS_CRITICAL' should be ok for clks_init_on clocks. But for USBPHY*_GATE, it is
only enabled when CONIG_USB_MXC_PHY is true. And another concern is if we need to add CLK_IS_CRITICAL
flag to clks_init_on clocks, we may need to add new wrapper function to register these critical clock. It is not very good.
> >
> > > > + }
> > > > +
> > > > + /* Lower the AHB clock rate before changing the clock source. */
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> > > > +
> > > > + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL],
> > > clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > clks[IMX6SLL_CLK_PERIPH_CLK2]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE],
> > > clks[IMX6SLL_CLK_PLL2_BUS]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > > +clks[IMX6SLL_CLK_PERIPH_PRE]);
> > > > +
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
> > >
> > > assigned-clocks for rates now? Or perhaps we shouldn't be exposing
> > > these as clks if they have some sort of complicated rate sequence
> > > switch that we can't guarantee with the clk_ops we have today.
> >
> > These clks will be used by some peripherals, so we need to expose these
> clocks.
> > And the above parent and rate swith sequence is not very easy to be
> > handled in assigned-clocks, So we leave it in this place.
> >
>
> How do we guarantee that the rate switch doesn't happen later on, requiring
> this coordinated sequence of clk operations?
>
This clock sequence is used for increasing the AXI and AHB bus clock rate. In normal
use, it is very rarely that we need to change them again. If we really need to change
AXI and AHB bus clock later, a similar sequence must be used to do this.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Matt Ranostay @ 2017-01-13 3:12 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Rob Herring, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Liam Breck
In-Reply-To: <CAPDyKFpm_B0aSQ2sY6yz9eYGzp1sokLVt0uk5K-9UkU=gYOOEw@mail.gmail.com>
On Thu, Jan 12, 2017 at 7:57 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 12 January 2017 at 05:43, Matt Ranostay <matt@ranostay.consulting> wrote:
>> On Wed, Jan 11, 2017 at 2:55 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> On 9 January 2017 at 05:53, Matt Ranostay <matt@ranostay.consulting> wrote:
>>>> On Fri, Dec 30, 2016 at 12:05 AM, Linus Walleij
>>>> <linus.walleij@linaro.org> wrote:
>>>>> On Mon, Dec 19, 2016 at 1:01 AM, Matt Ranostay <matt@ranostay.consulting> wrote:
>>>>>
>>>>>> * SD8787 has a "powerdown" line, and CW1200 has a "powerup" line.. I
>>>>>> know this is a simple logic inversion.
>>>>>
>>>>> If this is a GPIO line, the GPIO subsystem can flag a line for
>>>>> inverted logic. GPIO_ACTIVE_LOW from device tree for example.
>>>>
>>>> Slight ping on Ulf on this thread :).
>>>
>>> Thanks, sorry for the delay!
>>>
>>>>
>>>> I do understand the inverted logic flag but that doesn't help if there
>>>> are different logic states between various chipsets.
>>>
>>> For cw1200 (I looked at code from an old ST-Ericsson vendor tree), the
>>> sequence is as follows:
>>>
>>> 1) Enable clock/power to the card/chip.
>>> 2) Assert GPIO pin. I assume this also can be done before the
>>> clock/power is enabled.
>>> 3) Wait some time (~50ms).
>>> 4) De-assert GPIO pin.
>>> 5) Wait some time (~20ms)
>>> 6) Assert GPIO pin.
>>> 7) Wait some time (~32ms).
>>>
>>> At power off, the GPIO pin is de-asserted and of course also the
>>> clock/power is disabled. Just to make sure we have all the relevant
>>> logic.
>>>
>>> Looking at mmc pwrseq simple, perhaps we can extend this to deal with
>>> GPIOs that needs to be *toggled*, as this is not just reset GPIOs.
>>> Then we also need to deal with the delays in-between the toggling.
>>
>> Wouldn't we need to have a per chip function for each device
>> supported? As well document gpios? I suspect we'd need an array of
>
> I was hoping to avoid this, but the more I look at it, it seems inevitable.
>
>> gpios defined in device tree since different devices will likely have
>> various numbers of pins to toggle
>
> Maybe we can think of a clever way to combine cw1200 with your case?
> Perhaps a "mmc pwrseq toggle". :-) If not, please go ahead an repost a
> device specific mmc pwrseq for your case.
I think the best solution for now. We can merge the two solutions
latter down the road.
Thanks,
Matt
>
> I realize this would be a good opportunity for me to work on enabling
> support for cw1200 on ux500, but as the implementation of the
> clock/power control also needs to be up-streamed, I am quite far from
> being done.
>
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: Gautham R Shenoy @ 2017-01-13 3:44 UTC (permalink / raw)
To: Balbir Singh
Cc: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, Oliver O'Halloran,
linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
mark.rutland
In-Reply-To: <20170112094733.GC3006@localhost.localdomain>
On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
> > functions and variables had power9 in their names while some others
> > had arch300.
> >
>
> I would prefer power9 to arch300
>
I don't have a strong preference for arch300 vs power9, will change it
to power9 if that looks better.
--
Thanks and Regards
gautham.
^ permalink raw reply
* Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: Oliver O'Halloran @ 2017-01-13 3:46 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Balbir Singh, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, linuxppc-dev, linux-kernel,
linux-pm, devicetree, Rob Herring, mark.rutland
In-Reply-To: <20170113034418.GA10844@in.ibm.com>
On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy
<ego@linux.vnet.ibm.com> wrote:
> On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
>> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
>> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>> >
>> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
>> > functions and variables had power9 in their names while some others
>> > had arch300.
>> >
>>
>> I would prefer power9 to arch300
>>
>
>
> I don't have a strong preference for arch300 vs power9, will change it
> to power9 if that looks better.
Personally I think we should be as descriptive as possible and use
power_9_arch_300_the_bikeshed_is_red_dammit.
Oliver
^ permalink raw reply
* RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 4:28 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
dan.j.williams@intel.com, michal.simek@xilinx.com,
Soren Brinkmann, moritz.fischer@ettus.com,
laurent.pinchart@ideasonboard.com, luis@debethencourt.com,
Jose.Abreu@synopsys.com, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20170110062349.GY3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > Add channel idle state to ensure that dma descriptor is not
> > submitted when VDMA engine is in progress.
>
> any reason why you want to make your own varible and not use the HW to
> query
> as done earlier. It is not clear to me why that is removed from description
We need to poll for a bit in the status register to know the dma state.
We are currently doing that in the driver hot path
To avoid this using own variables.
Regards,
Kedar.
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-13 4:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-kernel, linux-sunxi,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linus Walleij, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai
In-Reply-To: <20170112174122.iqzrcyytfefqspwq@lukather>
13.01.2017, 01:41, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> On Fri, Jan 13, 2017 at 01:31:41AM +0800, Icenowy Zheng wrote:
>> 2017年1月13日 01:19于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>> >
>> > On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
>> > > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > > >> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> > > >>> V3s has a similar but cut-down CCU to H3.
>> > > >>>
>> > > >>> Add support for it.
>> > > >>>
>> > > >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> > > >>
>> > > >> It looks like there's nothing different but the clocks that you
>> > > >> register with the H3, please just use the H3 driver.
>> > > >
>> > > > Nope.
>> > > >
>> > > > It has a different PLL (PLL_ISP) at different address, and some
>> > > > different muxes.
>> > >
>> > > Forgot to mention the missing of PLL_DE and related misses.
>> >
>> > Those are not conflicting, it's just a slightly different set of
>> > clocks.
>>
>> If saying so, we can have only one ccu driver, and make every ccu
>> register different set ;-)
>>
>> V3s itself is a totally different SoC with H3.
>>
>> The relationship of V3s and H3 can be farther than the relationship
>> of A33 and H3😃
>
> A33 and H3 are an entirely different story. The H3 and A33 have
> conflicting clocks (ie same clocks with different parameters). This is
> not your case.
I think V3s and H3 has also conflicting clocks, e.g. CLK_DE.
The mux of CLK_DE in V3s is PLL_PERIPHx2 and PLL_VIDEO, but on H3
it's PLL_PERIPHx2 and PLL_DE (V3s lacks PLL_DE).
(What I say that there's a PLL missing means that there will also be mux
changes... I think you can understand this... sorry.)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Matt Ranostay (2):
devicetree: document vmmc-supply and mmc-pwrseq options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
drivers/mmc/core/Kconfig | 10 ++++++++++
drivers/mmc/core/Makefile | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, Matt Ranostay
In-Reply-To: <20170113052218.10534-1-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
---
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+ for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree
Cc: tony, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052218.10534-1-matt@ranostay.consulting>
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
drivers/mmc/core/Kconfig | 10 ++++++++++
drivers/mmc/core/Makefile | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:24 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Linux Kernel,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Tony Lindgren, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052218.10534-3-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
Er crap seems how the main patch file got dropped out. Resubmitting in
a minute... sorry!
>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> drivers/mmc/core/Kconfig | 10 ++++++++++
> drivers/mmc/core/Makefile | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
> This driver can also be built as a module. If so, the module
> will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> + tristate "HW reset support for SD8787 BT + Wifi module"
> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> + help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
> config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
> mmc_core-$(CONFIG_OF) += pwrseq.o
> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
* [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, Matt Ranostay
In-Reply-To: <20170113052937.12538-1-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++++++++++++++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index 000000000000..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+ for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree
Cc: tony, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052937.12538-1-matt@ranostay.consulting>
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
drivers/mmc/core/Kconfig | 10 ++++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index 000000000000..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson <ulf.hansson@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+
+#include <linux/mmc/host.h>
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_drvdata(pdev, pwrseq);
+
+ return mmc_pwrseq_register(&pwrseq->pwrseq);
+}
+
+static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
+
+ mmc_pwrseq_unregister(&pwrseq->pwrseq);
+
+ return 0;
+}
+
+static struct platform_driver mmc_pwrseq_sd8787_driver = {
+ .probe = mmc_pwrseq_sd8787_probe,
+ .remove = mmc_pwrseq_sd8787_remove,
+ .driver = {
+ .name = "pwrseq_sd8787",
+ .of_match_table = mmc_pwrseq_sd8787_of_match,
+ },
+};
+
+module_platform_driver(mmc_pwrseq_sd8787_driver);
+MODULE_LICENSE("GPL v2");
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Vinod Koul @ 2017-01-13 5:29 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: mark.rutland@arm.com, moritz.fischer@ettus.com,
devicetree@vger.kernel.org, michal.simek@xilinx.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, Soren Brinkmann,
luis@debethencourt.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, Jose.Abreu@synopsys.com,
linux-arm-kernel@lists.infradead.org,
laurent.pinchart@ideasonboard.com
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A666658@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
> >
> > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > Add channel idle state to ensure that dma descriptor is not
> > > submitted when VDMA engine is in progress.
> >
> > any reason why you want to make your own varible and not use the HW to
> > query
> > as done earlier. It is not clear to me why that is removed from description
>
> We need to poll for a bit in the status register to know the dma state.
> We are currently doing that in the driver hot path
> To avoid this using own variables.
It would be worthwhile to document these, down the line people may not
remeber the motivation
--
~Vinod
^ permalink raw reply
* RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 5:32 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
Soren Brinkmann,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf@public.gmane.org,
Jose.Abreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170113052939.GP3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > Hi Vinod,
> >
> > Thanks for the review...
> > >
> > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > > Add channel idle state to ensure that dma descriptor is not
> > > > submitted when VDMA engine is in progress.
> > >
> > > any reason why you want to make your own varible and not use the HW
> > > to query as done earlier. It is not clear to me why that is removed
> > > from description
> >
> > We need to poll for a bit in the status register to know the dma state.
> > We are currently doing that in the driver hot path To avoid this using
> > own variables.
>
> It would be worthwhile to document these, down the line people may not
> remeber the motivation
Sure will add comments during the variable initialization
In the driver...
Regards,
Kedar.
>
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox