* Re: [PATCH v3 5/6] dt-bindings: interconnect: Add interconnect-opp-table property
From: Rob Herring @ 2019-07-22 23:39 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Mark Rutland, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Rafael J. Wysocki, vincent.guittot, seansw,
daidavid1, Rajendra Nayak, sibis, bjorn.andersson, evgreen,
kernel-team, linux-pm, devicetree, linux-kernel
In-Reply-To: <20190703011020.151615-6-saravanak@google.com>
On Tue, Jul 02, 2019 at 06:10:19PM -0700, Saravana Kannan wrote:
> Add support for listing bandwidth OPP tables for each interconnect path
> listed using the interconnects property.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> .../devicetree/bindings/interconnect/interconnect.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> index 6f5d23a605b7..fc5b75b76a2c 100644
> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -55,10 +55,18 @@ interconnect-names : List of interconnect path name strings sorted in the same
> * dma-mem: Path from the device to the main memory of
> the system
>
> +interconnect-opp-table: List of phandles to OPP tables (bandwidth OPP tables)
> + that specify the OPPs for the interconnect paths listed
> + in the interconnects property. This property can only
> + point to OPP tables that belong to the device and are
> + listed in the device's operating-points-v2 property.
> +
IMO, there's no need for this property. Which OPP is which should be
defined already as part of the device's binding. That's enough for the
driver to know which OPP applies to the interconnect.
> Example:
>
> sdhci@7864000 {
> + operating-points-v2 = <&sdhc_opp_table>, <&sdhc_mem_opp_table>;
> ...
> interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
> interconnect-names = "sdhc-mem";
> + interconnect-opp-table = <&sdhc_mem_opp_table>;
> };
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
^ permalink raw reply
* Re: [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend
From: Dmitry Osipenko @ 2019-07-22 23:35 UTC (permalink / raw)
To: Marc Zyngier, Sowjanya Komatineni
Cc: thierry.reding, jonathanh, tglx, jason, linus.walleij, stefan,
mark.rutland, pdeschrijver, pgaikwad, sboyd, linux-clk,
linux-gpio, jckuo, josephl, talho, linux-tegra, linux-kernel,
mperttunen, spatra, robh+dt, devicetree
In-Reply-To: <20190722193838.0d7cd2ad@why>
22.07.2019 21:38, Marc Zyngier пишет:
> On Mon, 22 Jul 2019 09:21:21 -0700
> Sowjanya Komatineni <skomatineni@nvidia.com> wrote:
>
>> On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
>>> 22.07.2019 13:13, Marc Zyngier пишет:
>>>> On 22/07/2019 10:54, Dmitry Osipenko wrote:
>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>> Tegra210 platforms use sc7 entry firmware to program Tegra LP0/SC7 entry
>>>>>> sequence and sc7 entry firmware is run from COP/BPMP-Lite.
>>>>>>
>>>>>> So, COP/BPMP-Lite still need IRQ function to finish SC7 suspend sequence
>>>>>> for Tegra210.
>>>>>>
>>>>>> This patch has fix for leaving the COP IRQ enabled for Tegra210 during
>>>>>> interrupt controller suspend operation.
>>>>>>
>>>>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>> ---
>>>>>> drivers/irqchip/irq-tegra.c | 20 ++++++++++++++++++--
>>>>>> 1 file changed, 18 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/irqchip/irq-tegra.c b/drivers/irqchip/irq-tegra.c
>>>>>> index e1f771c72fc4..851f88cef508 100644
>>>>>> --- a/drivers/irqchip/irq-tegra.c
>>>>>> +++ b/drivers/irqchip/irq-tegra.c
>>>>>> @@ -44,6 +44,7 @@ static unsigned int num_ictlrs;
>>>>>>
>>>>>> struct tegra_ictlr_soc {
>>>>>> unsigned int num_ictlrs;
>>>>>> + bool supports_sc7;
>>>>>> };
>>>>>>
>>>>>> static const struct tegra_ictlr_soc tegra20_ictlr_soc = {
>>>>>> @@ -56,6 +57,7 @@ static const struct tegra_ictlr_soc tegra30_ictlr_soc = {
>>>>>>
>>>>>> static const struct tegra_ictlr_soc tegra210_ictlr_soc = {
>>>>>> .num_ictlrs = 6,
>>>>>> + .supports_sc7 = true,
>>>>>> };
>>>>>>
>>>>>> static const struct of_device_id ictlr_matches[] = {
>>>>>> @@ -67,6 +69,7 @@ static const struct of_device_id ictlr_matches[] = {
>>>>>>
>>>>>> struct tegra_ictlr_info {
>>>>>> void __iomem *base[TEGRA_MAX_NUM_ICTLRS];
>>>>>> + const struct tegra_ictlr_soc *soc;
>>>>>> #ifdef CONFIG_PM_SLEEP
>>>>>> u32 cop_ier[TEGRA_MAX_NUM_ICTLRS];
>>>>>> u32 cop_iep[TEGRA_MAX_NUM_ICTLRS];
>>>>>> @@ -147,8 +150,20 @@ static int tegra_ictlr_suspend(void)
>>>>>> lic->cop_ier[i] = readl_relaxed(ictlr + ICTLR_COP_IER);
>>>>>> lic->cop_iep[i] = readl_relaxed(ictlr + ICTLR_COP_IEP_CLASS);
>>>>>>
>>>>>> - /* Disable COP interrupts */
>>>>>> - writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>>> + /*
>>>>>> + * AVP/COP/BPMP-Lite is the Tegra boot processor.
>>>>>> + *
>>>>>> + * Tegra210 system suspend flow uses sc7entry firmware which
>>>>>> + * is executed by COP/BPMP and it includes disabling COP IRQ,
>>>>>> + * clamping CPU rail, turning off VDD_CPU, and preparing the
>>>>>> + * system to go to SC7/LP0.
>>>>>> + *
>>>>>> + * COP/BPMP wakes up when COP IRQ is triggered and runs
>>>>>> + * sc7entry-firmware. So need to keep COP interrupt enabled.
>>>>>> + */
>>>>>> + if (!lic->soc->supports_sc7)
>>>>>> + /* Disable COP interrupts if SC7 is not supported */
>>>>> All Tegra SoCs support SC7, hence the 'supports_sc7' and the comment
>>>>> doesn't sound correct to me. Something like 'firmware_sc7' should suit
>>>>> better here.
>>>> If what you're saying is true, then the whole patch is wrong, and the
>>>> SC7 property should come from DT.
>>> It should be safe to assume that all of existing Tegra210 devices use
>>> the firmware for SC7, hence I wouldn't say that the patch is entirely
>>> wrong. To me it's not entirely correct.
>>
>> Yes, all existing Tegra210 platforms uses sc7 entry firmware for SC7 and
>> AVP/COP IRQ need to be kept enabled as during suspend ATF triggers IRQ
>> to COP for SC7 entry fw execution.
Okay, as I already wrote before, it looks to me that a more proper
solution should be to just remove everything related to COP from this
driver instead of adding custom quirks for T210.
The disabling / restoring of COP interrupts should be relevant only for
the multimedia firmware on older Tegra SoCs. That firmware won't be ever
supported in the upstream simply because NVIDIA abandoned the support
for older hardware in the downstream and because it is not possible due
to some legal weirdness (IIUC). The only variant for upstream is
reverse-engineering of hardware (not the firmware BLOB) and writing
proper opensource drivers for the upstream kernel, which we're already
doing and have success to a some extent.
> That's not the question. Dmitry says that the SC7 support is not a
> property of the SoC, but mostly a platform decision on whether the
> firmware supports SC7 or not.
>
> To me, that's a clear indication that this should not be hardcoded in
> the driver, but instead obtained dynamically, via DT or otherwise.
We already have an nvidia,suspend-mode property in the device-tree of
the Power Management Controller node (all Tegra SoCs) which defines what
suspending type is supported by a particular board.
>>>>>> + writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
>>>>> Secondly, I'm also not sure why COP interrupts need to be disabled for
>>>>> pre-T210 at all, since COP is unused. This looks to me like it was
>>>>> cut-n-pasted from downstream kernel without a good reason and could be
>>>>> simply removed.
>>>> Please verify that this is actually the case. Tegra-2 definitely needed
>>>> some level of poking, and I'm not keen on changing anything there until
>>>> you (or someone else) has verified it on actual HW (see e307cc8941fc).
>>> Tested on Tegra20 and Tegra30, LP1 suspend-resume works perfectly fine
>>> with all COP bits removed from the driver.
>>>
>>> AFAIK, the reason why downstream needed that disabling is that it uses
>>> proprietary firmware which is running on the COP and that firmware is
>>> usually a BLOB audio/video DEC-ENC driver which doesn't cleanup
>>> interrupts after itself. That firmware is not applicable for the
>>> upstream kernel, hence there is no need to care about it.
>>>
>>>> Joseph, can you please shed some light here?
>>
>> SC7 entry flow uses 3rd party ATF (arm-trusted FW) blob which is the
>> one that actually loads SC7 entry firmware and triggers IRQ to
>> AVP/COP which causes COP to wakeup and run SC7 entry FW.
>>
>> So when SC7 support is enabled, IRQ need to be kept enabled and when
>> SC7 FW starts execution, it will disable COP IRQ.
>
> This looks like a lot of undocumented assumptions on what firmware
> does, as well as what firmware *is*. What I gather from this thread is
> that there is at least two versions of firmware (a "proprietary
> firmware" for "downstream kernels", and another one for mainline), and
> that they do different things.
>
> Given that we cannot know what people actually run, I don't think we
> can safely remove anything unless this gets tested on the full spectrum
> of HW/FW combination.
I'm not sure whether multiple firmware variations exist in the wild for
Tegra210. Maybe Sowjanya or somebody else from NVIDIA could clarify. I
think there should be some efforts in regards to a fully opensource
firmware on Tegra210, but I'm not following it and have no idea about
the status.
You're right that there are multiple variants of suspend-resuming flow
on Tegra SoCs. The older 32bit Tegra SoC generations have a variety of
options in regards to suspend-resuming, including firmware-less variants
on platforms that are having kernel running in secure mode (dev boards,
most of Tegra20 consumer devices) and Trusted-Foundations firmware
variant for insecure platforms (consumer devices). And yes, vendor
firmware creates a lot of headache in regards to bringing support into
upstream because it usually does a lot of odd undocumented things which
may also vary depending on a firmware version (bootloader, etc) and it
also usually difficult to replace it with an opensource alternative due
to a crypto signing.
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
From: Rob Herring @ 2019-07-22 23:35 UTC (permalink / raw)
To: Saravana Kannan
Cc: Sibi Sankar, Georgi Djakov, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Vincent Guittot,
Sweeney, Sean, daidavid1, Rajendra Nayak, Bjorn Andersson,
Evan Green, Android Kernel Team, Linux PM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML
In-Reply-To: <CAGETcx9KSqvyzbM-S8LvBObkNBt38K683Ljm8nNQuhxk7MuvAg@mail.gmail.com>
On Tue, Jul 16, 2019 at 11:58:08AM -0700, Saravana Kannan wrote:
> On Tue, Jul 16, 2019 at 10:25 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> >
> > Hey Saravana,
> >
> > https://patchwork.kernel.org/patch/10850815/
> > There was already a discussion ^^ on how bandwidth bindings were to be
> > named.
>
> Yes, I'm aware of that series. That series is trying to define a BW
> mapping for an existing frequency OPP table. This patch is NOT about
> adding a mapping to an existing table. This patch is about adding the
> notion of BW OPP tables where BW is the "key" instead of "frequency".
>
> So let's not mixed up these two series.
Maybe different reasons, but in the end we'd end up with 2 bandwidth
properties. We need to sort out how they'd overlap/coexist.
The same comment in that series about defining a standard unit suffix
also applies to this one.
Rob
^ permalink raw reply
* Re: [PATCH v8 3/5] arm64: dts: qcom: Add Lenovo Miix 630
From: Bjorn Andersson @ 2019-07-22 23:34 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: agross, benjamin.tissoires, dmitry.torokhov, jikos, hdegoede,
lee.jones, xnox, robh+dt, mark.rutland, linux-input, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <20190621145450.38741-1-jeffrey.l.hugo@gmail.com>
On Fri 21 Jun 07:54 PDT 2019, Jeffrey Hugo wrote:
> This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> functionality includes USB (host), microSD-card, keyboard, and trackpad.
>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Applied patch 3-5
Thanks,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/msm8998-clamshell.dtsi | 240 ++++++++++++++++++
> .../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 +++
> 3 files changed, 271 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 21d548f02d39..c3e4307bcbd4 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8998-lenovo-miix-630.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8998-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> new file mode 100644
> index 000000000000..9682d4dd7496
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
> +
> +/*
> + * Common include for MSM8998 clamshell devices, ie the Lenovo Miix 630,
> + * Asus NovaGo TP370QL, and HP Envy x2. All three devices are basically the
> + * same, with differences in peripherals.
> + */
> +
> +#include "msm8998.dtsi"
> +#include "pm8998.dtsi"
> +#include "pm8005.dtsi"
> +
> +/ {
> + chosen {
> + };
> +
> + vph_pwr: vph-pwr-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&qusb2phy {
> + status = "okay";
> +
> + vdda-pll-supply = <&vreg_l12a_1p8>;
> + vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
> +};
> +
> +&rpm_requests {
> + pm8998-regulators {
> + compatible = "qcom,rpm-pm8998-regulators";
> +
> + vdd_s1-supply = <&vph_pwr>;
> + vdd_s2-supply = <&vph_pwr>;
> + vdd_s3-supply = <&vph_pwr>;
> + vdd_s4-supply = <&vph_pwr>;
> + vdd_s5-supply = <&vph_pwr>;
> + vdd_s6-supply = <&vph_pwr>;
> + vdd_s7-supply = <&vph_pwr>;
> + vdd_s8-supply = <&vph_pwr>;
> + vdd_s9-supply = <&vph_pwr>;
> + vdd_s10-supply = <&vph_pwr>;
> + vdd_s11-supply = <&vph_pwr>;
> + vdd_s12-supply = <&vph_pwr>;
> + vdd_s13-supply = <&vph_pwr>;
> + vdd_l1_l27-supply = <&vreg_s7a_1p025>;
> + vdd_l2_l8_l17-supply = <&vreg_s3a_1p35>;
> + vdd_l3_l11-supply = <&vreg_s7a_1p025>;
> + vdd_l4_l5-supply = <&vreg_s7a_1p025>;
> + vdd_l6-supply = <&vreg_s5a_2p04>;
> + vdd_l7_l12_l14_l15-supply = <&vreg_s5a_2p04>;
> + vdd_l9-supply = <&vph_pwr>;
> + vdd_l10_l23_l25-supply = <&vph_pwr>;
> + vdd_l13_l19_l21-supply = <&vph_pwr>;
> + vdd_l16_l28-supply = <&vph_pwr>;
> + vdd_l18_l22-supply = <&vph_pwr>;
> + vdd_l20_l24-supply = <&vph_pwr>;
> + vdd_l26-supply = <&vreg_s3a_1p35>;
> + vdd_lvs1_lvs2-supply = <&vreg_s4a_1p8>;
> +
> + vreg_s3a_1p35: s3 {
> + regulator-min-microvolt = <1352000>;
> + regulator-max-microvolt = <1352000>;
> + };
> + vreg_s4a_1p8: s4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-allow-set-load;
> + };
> + vreg_s5a_2p04: s5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <2040000>;
> + };
> + vreg_s7a_1p025: s7 {
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <1028000>;
> + };
> + vreg_l1a_0p875: l1 {
> + regulator-min-microvolt = <880000>;
> + regulator-max-microvolt = <880000>;
> + regulator-allow-set-load;
> + };
> + vreg_l2a_1p2: l2 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-allow-set-load;
> + };
> + vreg_l3a_1p0: l3 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> + vreg_l5a_0p8: l5 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <800000>;
> + };
> + vreg_l6a_1p8: l6 {
> + regulator-min-microvolt = <1808000>;
> + regulator-max-microvolt = <1808000>;
> + };
> + vreg_l7a_1p8: l7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> + vreg_l8a_1p2: l8 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + vreg_l9a_1p8: l9 {
> + regulator-min-microvolt = <1808000>;
> + regulator-max-microvolt = <2960000>;
> + };
> + vreg_l10a_1p8: l10 {
> + regulator-min-microvolt = <1808000>;
> + regulator-max-microvolt = <2960000>;
> + };
> + vreg_l11a_1p0: l11 {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> + vreg_l12a_1p8: l12 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> + vreg_l13a_2p95: l13 {
> + regulator-min-microvolt = <1808000>;
> + regulator-max-microvolt = <2960000>;
> + };
> + vreg_l14a_1p88: l14 {
> + regulator-min-microvolt = <1880000>;
> + regulator-max-microvolt = <1880000>;
> + };
> + vreg_15a_1p8: l15 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> + vreg_l16a_2p7: l16 {
> + regulator-min-microvolt = <2704000>;
> + regulator-max-microvolt = <2704000>;
> + };
> + vreg_l17a_1p3: l17 {
> + regulator-min-microvolt = <1304000>;
> + regulator-max-microvolt = <1304000>;
> + };
> + vreg_l18a_2p7: l18 {
> + regulator-min-microvolt = <2704000>;
> + regulator-max-microvolt = <2704000>;
> + };
> + vreg_l19a_3p0: l19 {
> + regulator-min-microvolt = <3008000>;
> + regulator-max-microvolt = <3008000>;
> + };
> + vreg_l20a_2p95: l20 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-allow-set-load;
> + };
> + vreg_l21a_2p95: l21 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-allow-set-load;
> + regulator-system-load = <800000>;
> + };
> + vreg_l22a_2p85: l22 {
> + regulator-min-microvolt = <2864000>;
> + regulator-max-microvolt = <2864000>;
> + };
> + vreg_l23a_3p3: l23 {
> + regulator-min-microvolt = <3312000>;
> + regulator-max-microvolt = <3312000>;
> + };
> + vreg_l24a_3p075: l24 {
> + regulator-min-microvolt = <3088000>;
> + regulator-max-microvolt = <3088000>;
> + };
> + vreg_l25a_3p3: l25 {
> + regulator-min-microvolt = <3104000>;
> + regulator-max-microvolt = <3312000>;
> + };
> + vreg_l26a_1p2: l26 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + vreg_l28_3p0: l28 {
> + regulator-min-microvolt = <3008000>;
> + regulator-max-microvolt = <3008000>;
> + };
> +
> + vreg_lvs1a_1p8: lvs1 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vreg_lvs2a_1p8: lvs2 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + };
> +};
> +
> +&tlmm {
> + gpio-reserved-ranges = <0 4>, <81 4>;
> +
> + touchpad: touchpad {
> + config {
> + pins = "gpio123";
> + bias-pull-up; /* pull up */
> + };
> + };
> +};
> +
> +&sdhc2 {
> + status = "okay";
> +
> + vmmc-supply = <&vreg_l21a_2p95>;
> + vqmmc-supply = <&vreg_l13a_2p95>;
> +
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
> + pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off &sdc2_cd_off>;
> +};
> +
> +&usb3 {
> + status = "okay";
> +};
> +
> +&usb3_dwc3 {
> + dr_mode = "host"; /* Force to host until we have Type-C hooked up */
> +};
> +
> +&usb3phy {
> + status = "okay";
> +
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l2a_1p2>;
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> new file mode 100644
> index 000000000000..407c6a32911c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2019, Jeffrey Hugo. All rights reserved. */
> +
> +/dts-v1/;
> +
> +#include "msm8998-clamshell.dtsi"
> +
> +/ {
> + model = "Lenovo Miix 630";
> + compatible = "lenovo,miix-630", "qcom,msm8998";
> +};
> +
> +&blsp1_i2c6 {
> + status = "okay";
> +
> + keyboard@3a {
> + compatible = "hid-over-i2c";
> + interrupt-parent = <&tlmm>;
> + interrupts = <0x79 IRQ_TYPE_LEVEL_LOW>;
> + reg = <0x3a>;
> + hid-descr-addr = <0x0001>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&touchpad>;
> + };
> +};
> +
> +&sdhc2 {
> + cd-gpios = <&tlmm 95 GPIO_ACTIVE_HIGH>;
> +};
> --
> 2.17.1
>
^ permalink raw reply
* Re: [RESEND PATCH 1/3] dt-bindings: power: Add power domain binding for i.mx8m family
From: Rob Herring @ 2019-07-22 23:09 UTC (permalink / raw)
To: Jacky Bai
Cc: l.stach@pengutronix.de, shawnguo@kernel.org, festevam@gmail.com,
Leonard Crestez, Aisheng Dong, Peng Fan,
devicetree@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de
In-Reply-To: <20190702100832.29718-2-ping.bai@nxp.com>
On Tue, Jul 02, 2019 at 10:03:41AM +0000, Jacky Bai wrote:
> Add the binding doc of power domain for i.MX8M SOC family.
>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> ---
> .../bindings/power/fsl,imx8m-genpd.txt | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
>
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
> new file mode 100644
> index 000000000000..a92a7103de38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
> @@ -0,0 +1,46 @@
> +Device Tree Bindings for Freescale i.MX8M Generic Power Domain
> +==============================================================
> +The binding for the i.MX8M Generic power Domain[1].
> +
> +[1] Documentation/devicetree/bindings/power/power_domain.txt
> +
> +Required properties:
> +
> + - compatible: should be of:
> + - "fsl,imx8m-power-domain"
> + - #power-domain-cells: Number of cells in a PM domain Specifier, must be 0
> + - domain-index: should be the domain index number need to pass to TF-A
> + - domain-name: the name of this pm domain
> +
> +Optional properties:
> + - clocks: a number of phandles to clocks that need to be enabled during
> + domain power-up sequence to ensure reset propagation into devices
> + located inside this power domain
Isn't that firmware's problem?
> + - power-supply: Power supply used to power the domain
> + - parent-domains: the phandle to the parent power domain
> +
> +example:
> + vpu_g1_pd: vpug1-pd {
What's this a child of?
Use generic node names.
> + compatible = "fsl,imx8mm-pm-domain";
> + #power-domain-cells = <0>;
I'm usually not a fan when I see a single domain per provider. Why can't
you have firmware be a single provider with multiple domains?
> + domain-index = <6>;
Don't create your own index properties.
> + domain-name = "vpu_g1";
Not a standard name. Why do you need this? (Hint: we'd already have a
standard name if you did.)
> + parent-domains = <&vpumix_pd>;
We already have a standard way to do this.
> + clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>;
> + };
> +
> +
> +Specifying Power domain for IP modules
> +======================================
> +
> +IP cores belonging to a power domain should contain a 'power-domains'
> +property that is a phandle for PGC node representing the domain.
> +
> +Example of a device that is part of the vpu_g1 power domain:
> + vpu_g1: vpu_g1@38300000 {
video-codec@...
> + /* ... */
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "irq_hantro";
> + /* ... */
> + power-domains = <&vpu_g1_pd>;
> + };
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH 1/6] ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec
From: Rob Herring @ 2019-07-22 22:59 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: mark.rutland, devicetree, alsa-devel, bgoswami, lgirdwood, vkoul,
broonie, srini
In-Reply-To: <20190702080920.22623-2-srinivas.kandagatla@linaro.org>
On Tue, Jul 02, 2019 at 09:09:15AM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for wcd9340/wcd9341 audio codec which can
> support both SLIMbus and I2S/I2C interface.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../bindings/sound/qcom,wcd934x.txt | 188 ++++++++++++++++++
> 1 file changed, 188 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd934x.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.txt b/Documentation/devicetree/bindings/sound/qcom,wcd934x.txt
> new file mode 100644
> index 000000000000..2b48c98b5b7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.txt
> @@ -0,0 +1,188 @@
> +QCOM WCD9340/9341 Codec Bindings
> +
> +Qualcomm WCD9340/WCD9341 Codec is a standalone Hi-Fi audio codec IC, supports
> +Qualcomm Technologies, Inc. (QTI) multimedia solutions, including
> +the MSM8996, MSM8976, and MSM8956 chipsets. It has in-built
> +Soundwire controller, interrupt mux. It supports both I2S/I2C and
> +SLIMbus audio interfaces.
> +
> +Required properties with SLIMbus Interface:
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: For SLIMbus interface it should be "slimMID,PID",
> + textual representation of Manufacturer ID, Product Code,
> + shall be in lower case hexadecimal with leading zeroes
> + suppressed. Refer to slimbus/bus.txt for details.
> + Should be:
> + "slim217,250" for SDM845/SDA845 SoCs with SLIMbus.
> +
> +- reg
> + Usage: required
> + Value type: <u32 u32>
> + Definition: Should be ('Device index', 'Instance ID')
> +
> +- interrupts
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Interrupts via WCD INTR1 and INTR2 pins
Example only has 1 irq.
> +
> +- interrupt-names:
> + Usage: required
> + Value type: <String array>
> + Definition: Interrupt names of WCD INTR1 and INTR2
> + Should be: "intr1", "intr2"
> +
> +- reset-gpios:
> + Usage: required
> + Value type: <String Array>
Really?
> + Definition: Reset gpio line
> +
> +- slim-ifc-dev:
> + Usage: required
> + Value type: <phandle>
> + Definition: SLIM interface device
> +
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: See clock-bindings.txt section "consumers". List of
> + three clock specifiers for mclk, mclk2 and slimbus clock.
> +
> +- clock-names:
> + Usage: required
> + Value type: <string>
> + Definition: Must contain "mclk", "mclk2" and "slimbus" strings.
> +
> +- vdd-buck-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V buck supply
> +
> +- vdd-buck-sido-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V SIDO buck supply
> +
> +- vdd-rx-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V rx supply
> +
> +- vdd-tx-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V tx supply
> +
> +- vdd-vbat-supply:
> + Usage: Optional
> + Value type: <phandle>
> + Definition: Should contain a reference to the vbat supply
> +
> +- vdd-micbias-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the micbias supply
> +
> +- vdd-io-supply:
> + Usage: required
> + Value type: <phandle>
> + Definition: Should contain a reference to the 1.8V io supply
> +
> +- qcom,micbias1-lvl:
> + Usage: required
> + Value type: <u32>
> + Definition: Should be voltage in milli Volts for micbias1 output
> + Supported values are in inbetween 1800mV-2850mV
> +
> +- qcom,micbias2-lvl:
> + Usage: required
> + Value type: <u32>
> + Definition: Should be voltage in milli Volts for micbias2 output
> + Supported values are in inbetween 1800mV-2850mV
> +
> +- qcom,micbias3-lvl:
> + Usage: required
> + Value type: <u32>
> + Definition: Should be voltage in milli Volts for micbias3 output
> + Supported values are in inbetween 1800mV-2850mV
> +
> +- qcom,micbias4-lvl:
> + Usage: required
> + Value type: <u32>
> + Definition: Should be voltage in milli Volts for micbias4 output
> + Supported values are in inbetween 1800mV-2850mV
> +
> +- clock-output-names:
> + Usage: required
> + Value type: <string>
> + Definition: Should be the "mclk", corresponding to name
> + of the clk output.
> +
> +- clock-frequency:
> + Usage: required
> + Definition: Indicating the frequency of mclk output.
> +
> +- interrupt-controller:
> + Usage: required
> + Definition: Indicating that this is a interrupt controller
> +
> +- #interrupt-cells:
> + Usage: required
> + Value type: <int>
> + Definition: should be 1
> +
> +- #clock-cells:
> + Usage: required
> + Value type: <int>
> + Definition: should be 0, as there is only one clock out supported.
> +
> +#sound-dai-cells
> + Usage: required
> + Value type: <u32>
> + Definition: Must be 1
> +
> +Example:
> +
> +wcd9340: audio-codec@1{
> + compatible = "slim217,250";
> + reg = <1 0>;
> + reset-gpios = <&tlmm 64 0>;
> + slim-ifc-dev = <&wcd9340_ifd>;
> + vdd-buck-supply = <&vreg_s4a_1p8>;
> + vdd-buck-sido-supply = <&vreg_s4a_1p8>;
> + vdd-tx-supply = <&vreg_s4a_1p8>;
> + vdd-rx-supply = <&vreg_s4a_1p8>;
> + vdd-io-supply = <&vreg_s4a_1p8>;
> + qcom,micbias1-lvl = <1800>;
> + qcom,micbias2-lvl = <1800>;
> + qcom,micbias3-lvl = <1800>;
> + qcom,micbias4-lvl = <1800>;
> +
> + interrupt-parent = <&tlmm>;
> + interrupts = <54 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "intr1";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + #clock-cells = <0>;
> + clock-frequency = <9600000>;
> + clock-output-names = "mclk";
> + #sound-dai-cells = <1>;
> +
> + pinctrl@42 {
> + compatible = "qcom,wcd9340-pinctrl";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&wcdpinctrl 0 0 5>;
> + reg = <0x42 0x2>;
> + ...
> + };
> +
> + soundwire@c85{
Child nodes need documenting.
> + compatible = "qcom,soundwire-v1.3.0";
> + reg = <0xc85 0x40>;
> + ...
> + };
> +};
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH 1/6] ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec
From: Rob Herring @ 2019-07-22 22:55 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, alsa-devel, bgoswami, lgirdwood, vkoul,
Srinivas Kandagatla, srini
In-Reply-To: <20190702140252.GO2793@sirena.org.uk>
On Tue, Jul 02, 2019 at 03:02:52PM +0100, Mark Brown wrote:
> On Tue, Jul 02, 2019 at 09:09:15AM +0100, Srinivas Kandagatla wrote:
>
> > +- qcom,micbias1-lvl:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: Should be voltage in milli Volts for micbias1 output
>
> milivolts
And a unit suffix in the property name.
>
> > + Supported values are in inbetween 1800mV-2850mV
>
> in between
^ permalink raw reply
* Re: [PATCH 1/3] bindings: rtc: add bindings for MT2712 RTC
From: Rob Herring @ 2019-07-22 22:51 UTC (permalink / raw)
Cc: Alexandre Belloni, Rob Herring, Matthias Brugger,
Alessandro Zummo, Mark Rutland, linux-rtc, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, srv_heupstream,
YT Shen, Eddie Huang, Yingjoe Chen, Flora Fu, Sean Wang, Ran Bi
In-Reply-To: <20190702032120.16539-2-ran.bi@mediatek.com>
On Tue, 2 Jul 2019 11:21:18 +0800, Ran Bi wrote:
> Document the binding for MT2712 RTC implemented by rtc-mt2712.
>
> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
> ---
> .../devicetree/bindings/rtc/rtc-mt2712.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: soc: Add Aspeed XDMA engine binding documentation
From: Rob Herring @ 2019-07-22 22:43 UTC (permalink / raw)
Cc: linux-aspeed, linux-kernel, arnd, robh+dt, mark.rutland,
devicetree, joel, eduval, Eddie James
In-Reply-To: <1562010839-1113-2-git-send-email-eajames@linux.ibm.com>
On Mon, 1 Jul 2019 14:53:52 -0500, Eddie James wrote:
> Document the bindings.
>
> Reviewed-by: Andrew Jeffrey <andrew@aj.id.au>
> Signed-off-by: Eddie James <eajames@linux.ibm.com>
> ---
> .../devicetree/bindings/soc/aspeed/xdma.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/aspeed/xdma.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] hwmon: Remove ads1015 driver
From: Rob Herring @ 2019-07-22 22:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Cameron, devicetree, linux-hwmon, linux-kernel,
linux-iio, Dirk Eibach
In-Reply-To: <1562004758-13025-1-git-send-email-linux@roeck-us.net>
On Mon, Jul 01, 2019 at 11:12:38AM -0700, Guenter Roeck wrote:
> A driver for ADS1015 with more functionality is available in the iio
> subsystem.
>
> Remove the hwmon driver as duplicate. If the chip is used for hardware
> monitoring, the iio->hwmon bridge should be used.
>
> Cc: Dirk Eibach <eibach@gdsys.de>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Current plan is to queue this removal for v5.4 (not v5.3) in the hwmon
> tree.
>
> .../devicetree/bindings/hwmon/ads1015.txt | 73 -----
> .../devicetree/bindings/iio/adc/ads1015.txt | 73 +++++
I assume no change or I should review it again?
Acked-by: Rob Herring <robh@kernel.org>
> Documentation/hwmon/ads1015.rst | 90 ------
> Documentation/hwmon/index.rst | 1 -
> MAINTAINERS | 8 -
> drivers/hwmon/Kconfig | 10 -
> drivers/hwmon/Makefile | 1 -
> drivers/hwmon/ads1015.c | 324 ---------------------
> drivers/iio/adc/Kconfig | 2 +-
> 9 files changed, 74 insertions(+), 508 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/hwmon/ads1015.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/ads1015.txt
> delete mode 100644 Documentation/hwmon/ads1015.rst
> delete mode 100644 drivers/hwmon/ads1015.c
^ permalink raw reply
* [RFC] dt-bindings: net: phy: Add subnode for LED configuration
From: Matthias Kaehlcke @ 2019-07-22 22:37 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
The LED behavior of some Ethernet PHYs is configurable. Add an
optional 'leds' subnode with a child node for each LED to be
configured. The binding aims to be compatible with the common
LED binding (see devicetree/bindings/leds/common.txt).
A LED can be configured to be 'on' when a link with a certain speed
is active, or to blink on RX/TX activity. For the configuration to
be effective it needs to be supported by the hardware and the
corresponding PHY driver.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
This RFC is a follow up of the discussion on "[PATCH v2 6/7]
dt-bindings: net: realtek: Add property to configure LED mode"
(https://lore.kernel.org/patchwork/patch/1097185/).
For now posting as RFC to get a basic agreement on the bindings
before proceding with the implementation in phylib and a specific
driver.
---
Documentation/devicetree/bindings/net/phy.txt | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 9b9e5b1765dd..ad495d3abbbb 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -46,6 +46,25 @@ Optional Properties:
Mark the corresponding energy efficient ethernet mode as broken and
request the ethernet to stop advertising it.
+- leds: A sub-node which is a container of only LED nodes. Each child
+ node represents a PHY LED.
+
+ Required properties for LED child nodes:
+ - reg: The ID number of the LED, typically corresponds to a hardware ID.
+
+ Optional properties for child nodes:
+ - label: The label for this LED. If omitted, the label is taken from the node
+ name (excluding the unit address). It has to uniquely identify a device,
+ i.e. no other LED class device can be assigned the same label.
+
+ - linux,default-trigger: This parameter, if present, is a string defining
+ the trigger assigned to the LED. Current triggers are:
+ "phy_link_10m_active" - LED will be on when a 10Mb/s link is active
+ "phy_link_100m_active" - LED will be on when a 100Mb/s link is active
+ "phy_link_1g_active" - LED will be on when a 1Gb/s link is active
+ "phy_link_10g_active" - LED will be on when a 10Gb/s link is active
+ "phy_activity" - LED will blink when data is received or transmitted
+
- phy-is-integrated: If set, indicates that the PHY is integrated into the same
physical package as the Ethernet MAC. If needed, muxers should be configured
to ensure the integrated PHY is used. The absence of this property indicates
@@ -76,4 +95,18 @@ ethernet-phy@0 {
reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
reset-assert-us = <1000>;
reset-deassert-us = <2000>;
+
+ leds {
+ led@0 {
+ reg = <0>;
+ label = "ethphy0:left:green";
+ linux,default-trigger = "phy_link_1g_active";
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "ethphy0:right:amber";
+ linux,default-trigger = "phy_activity";
+ };
+ };
};
--
2.22.0.657.g960e92d24f-goog
^ permalink raw reply related
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-07-22 22:30 UTC (permalink / raw)
To: Stephen Boyd
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
Rob Herring, linux-nvdimm, Frank Rowand, Knut Omang,
Kieran Bingham, wfg-VuQAYsv1563Yd54FQh9/CA, Joel Stanley,
David Rientjes, Jeff Dike, Dan Carpenter, devicetree,
linux-kbuild
In-Reply-To: <20190722200347.261D3218C9-+nuXSHJNwjE76Z2rM5mHXA@public.gmane.org>
On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Quoting Brendan Higgins (2019-07-18 17:08:34)
> > On Thu, Jul 18, 2019 at 12:22:33PM -0700, Brendan Higgins wrote:
> >
> > I started poking around with your suggestion while we are waiting. A
> > couple early observations:
> >
> > 1) It is actually easier to do than I previously thought and will probably
> > help with getting more of the planned TAP output stuff working.
> >
> > That being said, this is still a pretty substantial undertaking and
> > will likely take *at least* a week to implement and properly review.
> > Assuming everything goes extremely well (no unexpected issues on my
> > end, very responsive reviewers, etc).
> >
> > 2) It *will* eliminate the need for kunit_stream.
> >
> > 3) ...but, it *will not* eliminate the need for string_stream.
> >
> > Based on my early observations, I do think it is worth doing, but I
> > don't think it is worth trying to make it in this patchset (unless I
> > have already missed the window, or it is going to be open for a while):
>
> The merge window is over. Typically code needs to be settled a few weeks
> before it opens (i.e. around -rc4 or -rc5) for most maintainers to pick
> up patches for the next merge window.
Yeah, it closed on Sunday, right?
I thought we might be able to squeak in since it was *mostly* settled,
and Shuah sent me an email two weeks ago which I interpreted to mean
she was still willing to take it.
In any case, it doesn't matter now.
> > I do think it will make things much cleaner, but I don't think it will
> > achieve your desired goal of getting rid of an unstructured
> > {kunit|string}_stream style interface; it just adds a layer on top of it
> > that makes it harder to misuse.
>
> Ok.
>
> >
> > I attached a patch of what I have so far at the end of this email so you
> > can see what I am talking about. And of course, if you agree with my
> > assessment, so we can start working on it as a future patch.
> >
> > A couple things in regard to the patch I attached:
> >
> > 1) I wrote it pretty quickly so there are almost definitely mistakes.
> > You should consider it RFC. I did verify it compiles though.
> >
> > 2) Also, I did use kunit_stream in writing it: all occurences should be
> > pretty easy to replace with string_stream; nevertheless, the reason
> > for this is just to make it easier to play with the current APIs. I
> > wanted to have something working before I went through a big tedious
> > refactoring. So sorry if it causes any confusion.
> >
> > 3) I also based the patch on all the KUnit patches I have queued up
> > (includes things like mocking and such) since I want to see how this
> > serialization thing will work with mocks and matchers and things like
> > that.
>
> Great!
>
> >
> > From 53d475d3d56afcf92b452c6d347dbedfa1a17d34 Mon Sep 17 00:00:00 2001
> > From: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Date: Thu, 18 Jul 2019 16:08:52 -0700
> > Subject: [PATCH v1] DO NOT MERGE: started playing around with the
> > serialization api
> >
> > ---
> > include/kunit/assert.h | 130 ++++++++++++++++++++++++++++++
> > include/kunit/mock.h | 4 +
> > kunit/Makefile | 3 +-
> > kunit/assert.c | 179 +++++++++++++++++++++++++++++++++++++++++
> > kunit/mock.c | 6 +-
> > 5 files changed, 318 insertions(+), 4 deletions(-)
> > create mode 100644 include/kunit/assert.h
> > create mode 100644 kunit/assert.c
> >
> > diff --git a/include/kunit/assert.h b/include/kunit/assert.h
> > new file mode 100644
> > index 0000000000000..e054fdff4642f
> > --- /dev/null
> > +++ b/include/kunit/assert.h
> > @@ -0,0 +1,130 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Assertion and expectation serialization API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > + */
> > +
> > +#ifndef _KUNIT_ASSERT_H
> > +#define _KUNIT_ASSERT_H
> > +
> > +#include <kunit/test.h>
> > +#include <kunit/mock.h>
> > +
> > +enum kunit_assert_type {
> > + KUNIT_ASSERTION,
> > + KUNIT_EXPECTATION,
> > +};
> > +
> > +struct kunit_assert {
> > + enum kunit_assert_type type;
> > + const char *line;
> > + const char *file;
> > + struct va_format message;
> > + void (*format)(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
>
> Would passing in the test help too?
Yeah, it would probably be good to put one in `struct kunit_assert`.
> > +};
> > +
> > +void kunit_base_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +void kunit_assert_print_msg(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_unary_assert {
> > + struct kunit_assert assert;
> > + const char *condition;
> > + bool expected_true;
> > +};
> > +
> > +void kunit_unary_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_ptr_not_err_assert {
> > + struct kunit_assert assert;
> > + const char *text;
> > + void *value;
> > +};
> > +
> > +void kunit_ptr_not_err_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_binary_assert {
> > + struct kunit_assert assert;
> > + const char *operation;
> > + const char *left_text;
> > + long long left_value;
> > + const char *right_text;
> > + long long right_value;
> > +};
> > +
> > +void kunit_binary_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_binary_ptr_assert {
> > + struct kunit_assert assert;
> > + const char *operation;
> > + const char *left_text;
> > + void *left_value;
> > + const char *right_text;
> > + void *right_value;
> > +};
> > +
> > +void kunit_binary_ptr_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_binary_str_assert {
> > + struct kunit_assert assert;
> > + const char *operation;
> > + const char *left_text;
> > + const char *left_value;
> > + const char *right_text;
> > + const char *right_value;
> > +};
> > +
> > +void kunit_binary_str_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_mock_assert {
> > + struct kunit_assert assert;
> > +};
> > +
> > +struct kunit_mock_no_expectations {
> > + struct kunit_mock_assert assert;
> > +};
>
> What's the purpose of making a wrapper struct with no other members?
> Just to make a different struct for some sort of type checking? I guess
> it's OK but I don't think it will be very useful in practice.
Yeah, just for typing purposes. I don't mind integrating this into the
current patchset and then deciding if we want it or not.
> > +
> > +struct kunit_mock_declaration {
> > + const char *function_name;
> > + const char **type_names;
> > + const void **params;
> > + int len;
> > +};
> > +
> > +void kunit_mock_declaration_format(struct kunit_mock_declaration *declaration,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_matcher_result {
> > + struct kunit_assert assert;
> > +};
> > +
> > +struct kunit_mock_failed_match {
> > + struct list_head node;
> > + const char *expectation_text;
> > + struct kunit_matcher_result *matcher_list;
>
> Minor nitpick: this code could use some const sprinkling.
Will do.
> > + size_t matcher_list_len;
> > +};
> > +
> > +void kunit_mock_failed_match_format(struct kunit_mock_failed_match *match,
> > + struct kunit_stream *stream);
> > +
> > +struct kunit_mock_no_match {
> > + struct kunit_mock_assert assert;
> > + struct kunit_mock_declaration declaration;
> > + struct list_head failed_match_list;
> > +};
> > +
> > +void kunit_mock_no_match_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream);
> > +
> > +#endif /* _KUNIT_ASSERT_H */
> > diff --git a/kunit/assert.c b/kunit/assert.c
> > new file mode 100644
> > index 0000000000000..75bb6922a994e
> > --- /dev/null
> > +++ b/kunit/assert.c
> > @@ -0,0 +1,179 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Assertion and expectation serialization API.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > + */
> > +#include <kunit/assert.h>
> > +
> > +void kunit_base_assert_format(struct kunit_assert *assert,
> > + struct kunit_stream *stream)
> > +{
> > + const char *expect_or_assert;
> > +
> > + if (assert->type == KUNIT_EXPECTATION)
> > + expect_or_assert = "EXPECTATION";
> > + else
> > + expect_or_assert = "ASSERTION";
>
> Make this is a switch statement so we can have the compiler complain if
> an enum is missing.
Nice call! I didn't know the compiler warned about that. Will fix.
> > +
> > + kunit_stream_add(stream, "%s FAILED at %s:%s\n",
> > + expect_or_assert, assert->file, assert->line);
> > +}
> > +
> > +void kunit_assert_print_msg(struct kunit_assert *assert,
> > + struct kunit_stream *stream)
> > +{
> > + if (assert->message.fmt)
> > + kunit_stream_add(stream, "\n%pV", &assert->message);
> > +}
> > +
> [...]
> > +
> > +void kunit_mock_failed_match_format(struct kunit_mock_failed_match *match,
> > + struct kunit_stream *stream)
> > +{
> > + struct kunit_matcher_result *result;
> > + size_t i;
> > +
> > + kunit_stream_add(stream,
> > + "Tried expectation: %s, but\n",
> > + match->expectation_text);
> > + for (i = 0; i < match->matcher_list_len; i++) {
> > + result = &match->matcher_list[i];
> > + kunit_stream_add(stream, "\t");
> > + result->assert.format(&result->assert, stream);
> > + kunit_stream_add(stream, "\n");
> > + }
>
> What's the calling context of the assertions and expectations? I still
> don't like the fact that string stream needs to allocate buffers and
> throw them into a list somewhere because the calling context matters
> there.
The calling context is the same as before, which is anywhere.
> I'd prefer we just wrote directly to the console/log via printk
> instead. That way things are simple because we use the existing
> buffering path of printk, but maybe there's some benefit to the string
> stream that I don't see? Right now it looks like it builds a string and
> then dumps it to printk so I'm sort of lost what the benefit is over
> just writing directly with printk.
It's just buffering it so the whole string gets printed uninterrupted.
If we were to print out piecemeal to printk, couldn't we have another
call to printk come in causing it to garble the KUnit message we are
in the middle of printing?
> Maybe it's this part that you wrote up above?
>
> > > Nevertheless, I think the debate over the usefulness of the
> > > string_stream and kunit_stream are separate topics. Even if we made
> > > kunit_stream more structured, I am pretty sure I would want to use
> > > string_stream or some variation for constructing the message.
>
> Why do we need string_stream to construct the message? Can't we just
> print it as we process it?
See preceding comment.
^ permalink raw reply
* Re: [PATCH 3/3] MIPS: qi_lb60: Move MMC configuration to devicetree
From: Paul Burton @ 2019-07-22 22:30 UTC (permalink / raw)
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Ulf Hansson, Linus Walleij, devicetree@vger.kernel.org,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mmc@vger.kernel.org, Paul Cercueil
In-Reply-To: <20190125200927.21045-3-paul@crapouillou.net>
Hello,
Paul Cercueil wrote:
> Move the MMC configuration from the board C file to devicetree.
>
> The 'power' GPIO was removed and instead the vmmc regulator is used,
> to follow the changes introduced in the jz4740-mmc driver.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply
* Re: [PATCH 2/2] MIPS: dts: ingenic: Add 'cpus' node
From: Paul Burton @ 2019-07-22 22:28 UTC (permalink / raw)
To: Paul Cercueil
Cc: Ralf Baechle, James Hogan, Rob Herring, Mark Rutland, od@zcrc.me,
linux-mips@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190722175548.18434-2-paul@crapouillou.net>
Hi Paul,
On Mon, Jul 22, 2019 at 01:55:48PM -0400, Paul Cercueil wrote:
> Add 'cpus' node to the jz4740.dtsi, jz4770.dtsi, jz4780.dtsi files.
What's the motivation for this?
If it's to silence the "cacheinfo: Unable to detect cache hierarchy"
messages, does commit b8bea8a5e5d9 ("mips: fix cacheinfo") from
mips-fixes work for you instead?
I'm not seeing much point listing cache setup in DT when we already
detect it from cop0 anyway.
Thanks,
Paul
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> arch/mips/boot/dts/ingenic/jz4740.dtsi | 19 +++++++++++
> arch/mips/boot/dts/ingenic/jz4770.dtsi | 29 ++++++++++++++++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 47 ++++++++++++++++++++++++++
> 3 files changed, 95 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> index 2beb78a62b7d..14d777dae87d 100644
> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> @@ -6,6 +6,25 @@
> #size-cells = <1>;
> compatible = "ingenic,jz4740";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-d0";
> + reg = <0>;
> + clocks = <&cgu JZ4740_CLK_CCLK>;
> + clock-names = "cpu";
> +
> + i-cache-size = <0x4000>;
> + i-cache-block-size = <32>;
> +
> + d-cache-size = <0x4000>;
> + d-cache-block-size = <32>;
> + };
> + };
> +
> cpuintc: interrupt-controller {
> #address-cells = <0>;
> #interrupt-cells = <1>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> index 49ede6c14ff3..83ee526fbe10 100644
> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> @@ -7,6 +7,35 @@
> #size-cells = <1>;
> compatible = "ingenic,jz4770";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-d1";
> + reg = <0>;
> + clocks = <&cgu JZ4770_CLK_CCLK>;
> + clock-names = "cpu";
> +
> + i-cache-size = <0x4000>;
> + i-cache-block-size = <32>;
> +
> + d-cache-size = <0x4000>;
> + d-cache-block-size = <32>;
> +
> + next-level-cache = <&L2_cache>;
> +
> + L2_cache: cache-controller {
> + compatible = "cache";
> + cache-unified;
> + cache-level = <2>;
> + cache-size = <0x40000>;
> + cache-block-size = <32>;
> + };
> + };
> + };
> +
> cpuintc: interrupt-controller {
> #address-cells = <0>;
> #interrupt-cells = <1>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index b03cdec56de9..3339b37101c0 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -7,6 +7,53 @@
> #size-cells = <1>;
> compatible = "ingenic,jz4780";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-e1";
> + reg = <0>;
> +
> + clocks = <&cgu JZ4780_CLK_CPU>;
> + clock-names = "cpu";
> +
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <32>;
> +
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <32>;
> +
> + next-level-cache = <&L2_cache>;
> +
> + L2_cache: l2-cache {
> + compatible = "cache";
> + cache-unified;
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-block-size = <32>;
> + };
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-e1";
> + reg = <1>;
> +
> + clocks = <&cgu JZ4780_CLK_CORE1>;
> + clock-names = "cpu";
> +
> + i-cache-size = <0x8000>;
> + i-cache-block-size = <32>;
> +
> + d-cache-size = <0x8000>;
> + d-cache-block-size = <32>;
> +
> + next-level-cache = <&L2_cache>;
> + };
> + };
> +
> cpuintc: interrupt-controller {
> #address-cells = <0>;
> #interrupt-cells = <1>;
> --
> 2.21.0.593.g511ec345e18
>
^ permalink raw reply
* Re: [PATCH v5 2/4] dt-bindings: thermal: nvme: Add binding documentation
From: Rob Herring @ 2019-07-22 22:16 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-nvme, linux-pm, devicetree, Zhang Rui, Eduardo Valentin,
Daniel Lezcano, Keith Busch, Jens Axboe, Christoph Hellwig,
Sagi Grimberg, Minwoo Im, Kenneth Heitke, Chaitanya Kulkarni
In-Reply-To: <1561990354-4084-3-git-send-email-akinobu.mita@gmail.com>
On Mon, Jul 01, 2019 at 11:12:32PM +0900, Akinobu Mita wrote:
> Add thermal binding documentation for NVMe temperature sensor.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Keith Busch <kbusch@kernel.org>
> Cc: Jens Axboe <axboe@fb.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Sagi Grimberg <sagi@grimberg.me>
> Cc: Minwoo Im <minwoo.im.dev@gmail.com>
> Cc: Kenneth Heitke <kenneth.heitke@intel.com>
> Cc: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> * v5
> - New patch
>
> Documentation/devicetree/bindings/thermal/nvme.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/nvme.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/nvme.txt b/Documentation/devicetree/bindings/thermal/nvme.txt
> new file mode 100644
> index 0000000..60b90de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/nvme.txt
> @@ -0,0 +1,56 @@
> +Binding for NVMe temperature sensor
> +
> +An NVMe controller reports up to nine temperature values in the SMART / Health
> +log.
> +
> +Required properties:
> +- reg: A five-cell address encoded as (phys.hi phys.mid phys.lo size.hi
> + size.lo). phys.hi should contain the device's BDF (Bus/Device/Function)
> + as 0b00000000 bbbbbbbb dddddfff 00000000. The other cells should be zero.
> + See also Documentation/devicetree/bindings/pci/pci.txt
> +
> +- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description.
> + In the thermal-sensors property, the sensor ID 0 for composite temperature,
> + 1 through 8 for NVMe temperature sensor N.
> +
> +Example:
> +
> +&pcie0 {
> + ...
> + nvme: nvme@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + nvmetemp: nvmetemp {
> + reg = <0x0000 0 0 0 0>; /* DEVFN = 0x00 (0:0) */
I'm not sure this is really valid PCI addressing as the parent has the
same address.
> + #thermal-sensor-cells = <1>;
Can't you just put this in the parent? Is this really a separate
addressable device from the parent?
> + };
> + };
> +};
> +
> +&thermal_zones {
> + nvme_thermal: nvme {
> + polling-delay-passive = <2000>; /* milliseconds */
> + polling-delay = <0>; /* asynchronous event driven */
> +
> + /* sensor ID */
> + thermal-sensors = <&nvmetemp 0>;
> +
> + trips {
> + nvme_alert0: nvme_alert0 {
> + temperature = <80000>; /* millicelsius */
> + hysteresis = <2000>; /* millicelsius */
> + type = "passive";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <&nvme_alert0>;
> + cooling-device =
> + <&fan0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC 07/11] dt-bindings: media: meson-ao-cec: add SM1 compatible
From: Rob Herring @ 2019-07-22 22:11 UTC (permalink / raw)
Cc: jbrunet, khilman, linux-media, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel, Neil Armstrong
In-Reply-To: <20190701104705.18271-8-narmstrong@baylibre.com>
On Mon, 1 Jul 2019 12:47:01 +0200, Neil Armstrong wrote:
> Add AO-CEC compatible string for the Amlogic SM1 SoC family,
> a derivate of the G12A AO-CECB controller.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/media/meson-ao-cec.txt | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC 05/11] dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
From: Rob Herring @ 2019-07-22 22:10 UTC (permalink / raw)
Cc: jbrunet, khilman, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, Neil Armstrong
In-Reply-To: <20190701104705.18271-6-narmstrong@baylibre.com>
On Mon, 1 Jul 2019 12:46:59 +0200, Neil Armstrong wrote:
> Add the Amlogic SM1 Compatible for the clk-measurer IP.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 03/12] dt-binding: gce: add binding for gce client reg property
From: Rob Herring @ 2019-07-22 22:09 UTC (permalink / raw)
To: Bibby Hsieh
Cc: Jassi Brar, Matthias Brugger, CK HU, Daniel Kurtz, Sascha Hauer,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
srv_heupstream, Sascha Hauer, Philipp Zabel, Nicolas Boichat,
YT Shen, Daoyuan Huang, Jiaguang Zhang, Dennis-YC Hsieh,
Houlong Wei, ginny.chen
In-Reply-To: <20190701074842.15401-4-bibby.hsieh@mediatek.com>
On Mon, Jul 01, 2019 at 03:48:33PM +0800, Bibby Hsieh wrote:
> cmdq driver provide a function that get the relationship
> of sub system number from device node for client.
> add specification for #subsys-cells, mediatek,gce-client-reg.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> .../devicetree/bindings/mailbox/mtk-gce.txt | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> index 1f7f8f2a3f49..d48282d6b02d 100644
> --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> @@ -21,12 +21,21 @@ Required properties:
> priority: Priority of GCE thread.
> atomic_exec: GCE processing continuous packets of commands in atomic
> way.
> +- #subsys-cells: Should be 3.
You don't need this if it is always 3 and/or is always a single phandle.
> + <&phandle subsys_number start_offset size>
> + phandle: Label name of a gce node.
> + subsys_number: specify the sub-system id which is corresponding
> + to the register address.
> + start_offset: the start offset of register address that GCE can access.
> + size: the total size of register address that GCE can access.
>
> Required properties for a client device:
> - mboxes: Client use mailbox to communicate with GCE, it should have this
> property and list of phandle, mailbox specifiers.
> -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding
> - to the register address.
> +Optional properties for a client device:
> +- mediatek,gce-client-reg: Specify the sub-system id which is corresponding
> + to the register address, it should have this property and list of phandle,
> + sub-system specifiers.
>
> Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
> or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids.
> @@ -40,6 +49,7 @@ Example:
> clocks = <&infracfg CLK_INFRA_GCE>;
> clock-names = "gce";
> #mbox-cells = <3>;
> + #subsys-cells = <3>;
> };
>
> Example for a client device:
> @@ -48,9 +58,9 @@ Example for a client device:
> compatible = "mediatek,mt8173-mmsys";
> mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST 1>,
> <&gce 1 CMDQ_THR_PRIO_LOWEST 1>;
> - mediatek,gce-subsys = <SUBSYS_1400XXXX>;
> mutex-event-eof = <CMDQ_EVENT_MUTEX0_STREAM_EOF
> CMDQ_EVENT_MUTEX1_STREAM_EOF>;
> -
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>,
> + <&gce SUBSYS_1401XXXX 0x2000 0x100>;
> ...
> };
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH v2 10/11] dt-bindings: mmc: arasan: Document 'xlnx,zynqmp-8.9a' controller
From: Rob Herring @ 2019-07-22 22:06 UTC (permalink / raw)
Cc: ulf.hansson, robh+dt, mark.rutland, heiko, michal.simek,
adrian.hunter, christoph.muellner, philipp.tomsich, viresh.kumar,
scott.branden, ayaka, kernel, tony.xie, rajan.vaja, jolly.shah,
nava.manne, mdf, manish.narani, olof, linux-mmc, devicetree,
linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <1561958991-21935-11-git-send-email-manish.narani@xilinx.com>
On Mon, 1 Jul 2019 10:59:50 +0530, Manish Narani wrote:
> Add documentation for 'xlnx,zynqmp-8.9a' SDHCI controller and optional
> properties followed by example.
>
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> .../devicetree/bindings/mmc/arasan,sdhci.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/11] dt-bindings: mmc: arasan: Add optional properties for Arasan SDHCI
From: Rob Herring @ 2019-07-22 22:01 UTC (permalink / raw)
To: Manish Narani
Cc: ulf.hansson, mark.rutland, heiko, michal.simek, adrian.hunter,
christoph.muellner, philipp.tomsich, viresh.kumar, scott.branden,
ayaka, kernel, tony.xie, rajan.vaja, jolly.shah, nava.manne, mdf,
olof, linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <1561958991-21935-8-git-send-email-manish.narani@xilinx.com>
On Mon, Jul 01, 2019 at 10:59:47AM +0530, Manish Narani wrote:
> Add optional propeties for Arasan SDHCI which are used to set clk delays
> for different speed modes in the controller.
>
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 7c79496..7425d52 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -49,6 +49,21 @@ Optional Properties:
> properly. Test mode can be used to force the controller to function.
> - xlnx,int-clock-stable-broken: when present, the controller always reports
> that the internal clock is stable even when it is not.
> + - clk-phase-legacy: Input/Output Clock Delay pair in degrees for Legacy Mode.
> + - clk-phase-mmc-hs: Input/Output Clock Delay pair degrees for MMC HS.
> + - clk-phase-sd-hs: Input/Output Clock Delay pair in degrees for SD HS.
> + - clk-phase-uhs-sdr12: Input/Output Clock Delay pair in degrees for SDR12.
> + - clk-phase-uhs-sdr25: Input/Output Clock Delay pair in degrees for SDR25.
> + - clk-phase-uhs-sdr50: Input/Output Clock Delay pair in degrees for SDR50.
> + - clk-phase-uhs-sdr104: Input/Output Clock Delay pair in degrees for SDR104.
> + - clk-phase-uhs-ddr50: Input/Output Clock Delay pair in degrees for SD DDR50.
> + - clk-phase-mmc-ddr52: Input/Output Clock Delay pair in degrees for MMC DDR52.
> + - clk-phase-mmc-hs200: Input/Output Clock Delay pair in degrees for MMC HS200.
> + - clk-phase-mmc-hs400: Input/Output Clock Delay pair in degrees for MMC HS400.
Either these need vendor prefixes or be added as common properties if
that makes sense.
Rob
> +
> + Above mentioned are the clock (phase) delays which are to be configured in the
> + controller while switching to particular speed mode. If not specified, driver
> + will configure the default value defined for particular mode in it.
>
> Example:
> sdhci@e0100000 {
> --
> 2.1.1
>
^ permalink raw reply
* Re: [PATCH v2 05/11] dt-bindings: mmc: arasan: Update Documentation for the input clock
From: Rob Herring @ 2019-07-22 21:56 UTC (permalink / raw)
To: Manish Narani
Cc: ulf.hansson, mark.rutland, heiko, michal.simek, adrian.hunter,
christoph.muellner, philipp.tomsich, viresh.kumar, scott.branden,
ayaka, kernel, tony.xie, rajan.vaja, jolly.shah, nava.manne, mdf,
olof, linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <1561958991-21935-6-git-send-email-manish.narani@xilinx.com>
On Mon, Jul 01, 2019 at 10:59:45AM +0530, Manish Narani wrote:
> Add documentation for an optional input clock which is essentially used
> in sampling the input data coming from the card.
>
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 15c6397..7c79496 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -23,10 +23,10 @@ Required Properties:
> - reg: From mmc bindings: Register location and length.
> - clocks: From clock bindings: Handles to clock inputs.
> - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
> - Apart from these two there is one more optional clock which
> - is "clk_sdcard". This clock represents output clock from
> - controller and card. This must be specified when #clock-cells
> - is specified.
> + Apart from these two there are two more optional clocks which
> + are "clk_sdcard" and "clk_sample". These two clocks represent
> + output and input clocks between controller and card. These
> + must be specified when #clock-cells is specified.
> - interrupts: Interrupt specifier
>
> Required Properties for "arasan,sdhci-5.1":
> @@ -40,9 +40,9 @@ Optional Properties:
> - clock-output-names: If specified, this will be the name of the card clock
> which will be exposed by this device. Required if #clock-cells is
> specified.
> - - #clock-cells: If specified this should be the value <0>. With this
> - property in place we will export one clock representing the Card
> - Clock. This clock is expected to be consumed by our PHY. You must also
> + - #clock-cells: If specified this should be the value <0> or <1>. With this
> + property in place we will export one or two clocks representing the Card
> + Clock. These clocks are expected to be consumed by our PHY. You must also
What are the 2 clocks?
> specify
> - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> the CD line is not connected properly, and the line is not connected
> --
> 2.1.1
>
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
From: Rob Herring @ 2019-07-22 21:54 UTC (permalink / raw)
To: Manish Narani
Cc: ulf.hansson, mark.rutland, heiko, michal.simek, adrian.hunter,
christoph.muellner, philipp.tomsich, viresh.kumar, scott.branden,
ayaka, kernel, tony.xie, rajan.vaja, jolly.shah, nava.manne, mdf,
olof, linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <1561958991-21935-2-git-send-email-manish.narani@xilinx.com>
On Mon, Jul 01, 2019 at 10:59:41AM +0530, Manish Narani wrote:
> The clock handling is to be updated in the Arasan SDHCI. As the
> 'devm_clk_register' is deprecated in the clock framework, this needs to
> specify one more clock named 'clk_sdcard' to get the clock in the driver
> via 'devm_clk_get()'. This clock represents the clock from controller to
> the card.
Please explain why in terms of the binding, not some driver calls.
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 1edbb04..15c6397 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -23,6 +23,10 @@ Required Properties:
> - reg: From mmc bindings: Register location and length.
> - clocks: From clock bindings: Handles to clock inputs.
> - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
> + Apart from these two there is one more optional clock which
> + is "clk_sdcard". This clock represents output clock from
> + controller and card. This must be specified when #clock-cells
> + is specified.
> - interrupts: Interrupt specifier
>
> Required Properties for "arasan,sdhci-5.1":
> @@ -36,9 +40,10 @@ Optional Properties:
> - clock-output-names: If specified, this will be the name of the card clock
> which will be exposed by this device. Required if #clock-cells is
> specified.
> - - #clock-cells: If specified this should be the value <0>. With this property
> - in place we will export a clock representing the Card Clock. This clock
> - is expected to be consumed by our PHY. You must also specify
> + - #clock-cells: If specified this should be the value <0>. With this
> + property in place we will export one clock representing the Card
> + Clock. This clock is expected to be consumed by our PHY. You must also
> + specify
specify what?
The 3rd clock input I assume? This statement means any existing users
with 2 clock inputs and #clock-cells are in error now. Is that correct?
> - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> the CD line is not connected properly, and the line is not connected
> properly. Test mode can be used to force the controller to function.
> @@ -70,8 +75,8 @@ Example:
> compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
> reg = <0x0 0xfe330000 0x0 0x10000>;
> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>;
> - clock-names = "clk_xin", "clk_ahb";
> + clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>, <&sdhci 0>;
> + clock-names = "clk_xin", "clk_ahb", "clk_sdcard";
> arasan,soc-ctl-syscon = <&grf>;
> assigned-clocks = <&cru SCLK_EMMC>;
> assigned-clock-rates = <200000000>;
> --
> 2.1.1
>
^ permalink raw reply
* Re: [PATCH 3/5] dt: bindings: add mt7621-pll dt binding documentation
From: Stephen Boyd @ 2019-07-22 21:51 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK, open list:MIPS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:STAGING SUBSYSTEM, open list
Cc: Michael Turquette, Rob Herring, Mark Rutland, Ralf Baechle,
Paul Burton, James Hogan, John Crispin, Greg Kroah-Hartman,
Weijie Gao, NeilBrown, Chuanhong Guo
In-Reply-To: <20190709182018.23193-4-gch981213@gmail.com>
Quoting Chuanhong Guo (2019-07-09 11:20:16)
> This commit adds device tree binding documentation for MT7621
> PLL controller.
>
> Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
> ---
> .../bindings/clock/mediatek,mt7621-pll.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
> new file mode 100644
> index 000000000000..05c15062cd20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
> @@ -0,0 +1,19 @@
> +Binding for Mediatek MT7621 PLL controller
> +
> +The PLL controller provides the 2 main clocks of the SoC: CPU and BUS.
> +
> +Required Properties:
> +- compatible: has to be "mediatek,mt7621-pll"
> +- #clock-cells: has to be one
> +
> +Optional properties:
> +- clock-output-names: should be "cpu", "bus"
> +
> +Example:
> + pll {
> + compatible = "mediatek,mt7621-pll", "syscon";
Why is this a syscon and not just part of some larger mt7621 clk
provider node?
> +
> + #clock-cells = <1>;
> + clock-output-names = "cpu", "bus";
> + };
> +
^ permalink raw reply
* Re: [PATCH 2/5] MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices
From: Stephen Boyd @ 2019-07-22 21:50 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK, open list:MIPS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:STAGING SUBSYSTEM, open list
Cc: Michael Turquette, Rob Herring, Mark Rutland, Ralf Baechle,
Paul Burton, James Hogan, John Crispin, Greg Kroah-Hartman,
Weijie Gao, NeilBrown, Chuanhong Guo
In-Reply-To: <20190709182018.23193-3-gch981213@gmail.com>
Quoting Chuanhong Guo (2019-07-09 11:20:15)
> For a long time the mt7621 uses a fixed cpu clock which causes a problem
> if the cpu frequency is not 880MHz.
>
> This patch fixes the cpu clock calculation and adds the cpu/bus clkdev
> which will be used in dts.
>
> Ported from OpenWrt:
> c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
>
> Signed-off-by: Weijie Gao <hackpascal@gmail.com>
> Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
[...]
> diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
> index 9415be0d57b8..31158b88bcb6 100644
> --- a/arch/mips/ralink/mt7621.c
> +++ b/arch/mips/ralink/mt7621.c
> @@ -7,22 +7,22 @@
>
> #include <linux/kernel.h>
> #include <linux/init.h>
> +#include <linux/clk.h>
Is this include used?
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <dt-bindings/clock/mt7621-clk.h>
>
> #include <asm/mipsregs.h>
> #include <asm/smp-ops.h>
> #include <asm/mips-cps.h>
> #include <asm/mach-ralink/ralink_regs.h>
> #include <asm/mach-ralink/mt7621.h>
> +#include <asm/time.h>
>
> #include <pinmux.h>
>
> #include "common.h"
>
> -#define SYSC_REG_SYSCFG 0x10
> -#define SYSC_REG_CPLL_CLKCFG0 0x2c
> -#define SYSC_REG_CUR_CLK_STS 0x44
> -#define CPU_CLK_SEL (BIT(30) | BIT(31))
> -
> #define MT7621_GPIO_MODE_UART1 1
> #define MT7621_GPIO_MODE_I2C 2
> #define MT7621_GPIO_MODE_UART3_MASK 0x3
> @@ -108,49 +108,89 @@ static struct rt2880_pmx_group mt7621_pinmux_data[] = {
> { 0 }
> };
>
> +static struct clk *clks[MT7621_CLK_MAX];
> +static struct clk_onecell_data clk_data = {
> + .clks = clks,
> + .clk_num = ARRAY_SIZE(clks),
> +};
> +
> phys_addr_t mips_cpc_default_phys_base(void)
> {
> panic("Cannot detect cpc address");
> }
>
> +static struct clk *__init mt7621_add_sys_clkdev(
> + const char *id, unsigned long rate)
> +{
> + struct clk *clk;
> + int err;
> +
> + clk = clk_register_fixed_rate(NULL, id, NULL, 0, rate);
> + if (IS_ERR(clk))
> + panic("failed to allocate %s clock structure", id);
> +
> + err = clk_register_clkdev(clk, id, NULL);
What's the need to use clkdev? i.e. why can't we just use clk_get() with
proper DT definitions and by passing in the right device pointer?
> + if (err)
> + panic("unable to register %s clock device", id);
> +
> + return clk;
> +}
> +
> void __init ralink_clk_init(void)
> {
> - int cpu_fdiv = 0;
> - int cpu_ffrac = 0;
> - int fbdiv = 0;
> - u32 clk_sts, syscfg;
> - u8 clk_sel = 0, xtal_mode;
> - u32 cpu_clk;
> + const static u32 prediv_tbl[] = {0, 1, 2, 2};
> + u32 syscfg, xtal_sel, clkcfg, clk_sel, curclk, ffiv, ffrac;
> + u32 pll, prediv, fbdiv;
> + u32 xtal_clk, cpu_clk, bus_clk;
> +
> + syscfg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
> + xtal_sel = (syscfg >> XTAL_MODE_SEL_SHIFT) & XTAL_MODE_SEL_MASK;
>
> - if ((rt_sysc_r32(SYSC_REG_CPLL_CLKCFG0) & CPU_CLK_SEL) != 0)
> - clk_sel = 1;
> + clkcfg = rt_sysc_r32(SYSC_REG_CLKCFG0);
> + clk_sel = (clkcfg >> CPU_CLK_SEL_SHIFT) & CPU_CLK_SEL_MASK;
> +
> + curclk = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
> + ffiv = (curclk >> CUR_CPU_FDIV_SHIFT) & CUR_CPU_FDIV_MASK;
> + ffrac = (curclk >> CUR_CPU_FFRAC_SHIFT) & CUR_CPU_FFRAC_MASK;
> +
> + if (xtal_sel <= 2)
> + xtal_clk = 20 * 1000 * 1000;
> + else if (xtal_sel <= 5)
> + xtal_clk = 40 * 1000 * 1000;
> + else
> + xtal_clk = 25 * 1000 * 1000;
>
> switch (clk_sel) {
> case 0:
> - clk_sts = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
> - cpu_fdiv = ((clk_sts >> 8) & 0x1F);
> - cpu_ffrac = (clk_sts & 0x1F);
> - cpu_clk = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
> + cpu_clk = 500 * 1000 * 1000;
> break;
> -
> case 1:
> - fbdiv = ((rt_sysc_r32(0x648) >> 4) & 0x7F) + 1;
> - syscfg = rt_sysc_r32(SYSC_REG_SYSCFG);
> - xtal_mode = (syscfg >> 6) & 0x7;
> - if (xtal_mode >= 6) {
> - /* 25Mhz Xtal */
> - cpu_clk = 25 * fbdiv * 1000 * 1000;
> - } else if (xtal_mode >= 3) {
> - /* 40Mhz Xtal */
> - cpu_clk = 40 * fbdiv * 1000 * 1000;
> - } else {
> - /* 20Mhz Xtal */
> - cpu_clk = 20 * fbdiv * 1000 * 1000;
> - }
> + pll = rt_memc_r32(MEMC_REG_CPU_PLL);
> + fbdiv = (pll >> CPU_PLL_FBDIV_SHIFT) & CPU_PLL_FBDIV_MASK;
> + prediv = (pll >> CPU_PLL_PREDIV_SHIFT) & CPU_PLL_PREDIV_MASK;
> + cpu_clk = ((fbdiv + 1) * xtal_clk) >> prediv_tbl[prediv];
> break;
> + default:
> + cpu_clk = xtal_clk;
> }
> +
> + cpu_clk = cpu_clk / ffiv * ffrac;
> + bus_clk = cpu_clk / 4;
> +
> + clks[MT7621_CLK_CPU] = mt7621_add_sys_clkdev("cpu", cpu_clk);
> + clks[MT7621_CLK_BUS] = mt7621_add_sys_clkdev("bus", bus_clk);
> +
> + pr_info("CPU Clock: %dMHz\n", cpu_clk / 1000000);
> + mips_hpt_frequency = cpu_clk / 2;
There are a few changes here. Probably the patch should be split up a
bit more to only do one thing at a time, instead of assign
mips_hpt_frequency, change the calculation code, and change the way clks
are provided on this platform.
> }
>
> +static void __init mt7621_clocks_init_dt(struct device_node *np)
> +{
> + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> +}
> +
> +CLK_OF_DECLARE(mt7621_clk, "mediatek,mt7621-pll", mt7621_clocks_init_dt);
> +
> void __init ralink_of_remap(void)
> {
> rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
> diff --git a/arch/mips/ralink/timer-gic.c b/arch/mips/ralink/timer-gic.c
> index 944fbe0fc741..9bbaa37a0da1 100644
> --- a/arch/mips/ralink/timer-gic.c
> +++ b/arch/mips/ralink/timer-gic.c
> @@ -9,14 +9,14 @@
>
> #include <linux/of.h>
> #include <linux/clk-provider.h>
> -#include <linux/clocksource.h>
> +#include <asm/time.h>
>
> #include "common.h"
>
> void __init plat_time_init(void)
> {
> ralink_of_remap();
> -
> + ralink_clk_init();
Why can't everything flow from CLK_OF_DECLARE() for a particular node?
Even better would be to make a device driver instead of using
CLK_OF_DECLARE(), but either way this doesn't look necessary to make a
direct function call here.
> of_clk_init(NULL);
> timer_probe();
> }
^ permalink raw reply
* Re: [PATCH 3/3] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
From: Paul Walmsley @ 2019-07-22 21:48 UTC (permalink / raw)
To: Yash Shah, davem
Cc: sagar.kadam, robh+dt, netdev, devicetree, linux-kernel,
linux-riscv, mark.rutland, palmer, aou, nicolas.ferre, ynezz,
sachin.ghadi, andrew
In-Reply-To: <1563534631-15897-3-git-send-email-yash.shah@sifive.com>
On Fri, 19 Jul 2019, Yash Shah wrote:
> DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added
>
> Signed-off-by: Yash Shah <yash.shah@sifive.com>
Thanks, queuing this one for v5.3-rc with Andrew's suggested change to
change phy1 to phy0.
Am assuming patches 1 and 2 will go in via -net.
- Paul
^ 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