From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79C08C433DF for ; Sat, 8 Aug 2020 22:00:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5057C206C3 for ; Sat, 8 Aug 2020 22:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726009AbgHHWAj (ORCPT ); Sat, 8 Aug 2020 18:00:39 -0400 Received: from foss.arm.com ([217.140.110.172]:43926 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725950AbgHHWAj (ORCPT ); Sat, 8 Aug 2020 18:00:39 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5ACF7D6E; Sat, 8 Aug 2020 15:00:38 -0700 (PDT) Received: from [10.57.35.143] (unknown [10.57.35.143]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 79C243F7D8; Sat, 8 Aug 2020 15:00:37 -0700 (PDT) Subject: Re: [PATCH v2 2/2] rockchip: rk3328: Add support for FriendlyARM NanoPi R2S To: David Bauer , linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org References: <20200730232054.286381-1-mail@david-bauer.net> <20200730232054.286381-2-mail@david-bauer.net> <685c3ab2-5f51-1fc2-622d-4d9785d7074b@david-bauer.net> From: Robin Murphy Message-ID: Date: Sat, 8 Aug 2020 23:00:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <685c3ab2-5f51-1fc2-622d-4d9785d7074b@david-bauer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 2020-08-06 07:57, David Bauer wrote: > Hi Robin, > > thanks for your review. Only adressing some non-formal comments below. > > On 8/3/20 12:01 AM, Robin Murphy wrote: >> >> This seems to match the schematic, however in practice the GPIO seems to have a mind of its own and not respond to the LED settings - are we missing something with the pinctrl perhaps? > > Hmm, this is strange. It works fine on my unit (with the current OpenWrt release). Can you test this and report back? It seems like somehow that particular GPIO doesn't get configured properly and is still in its default out-of-reset state as an input. Poking the GPIO from sysfs works as expected, and in fact just unbinding and rebinding the leds-gpio driver also manages to kick things into shape. Clearly there's some subtle driver-level issue, but at least it's not a DT problem :) >>> +            label = "nanopi-r2s:green:lan"; >>> +        }; >>> + >>> +        wan { >>> +            gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_HIGH>; >>> +            label = "nanopi-r2s:green:wan"; >>> +        }; >>> +    }; >>> + >>> +    gpio_keys { >>> +        compatible = "gpio-keys-polled"; >> >> Does this need to be polled? I would have thought regular interrupt-based gpio-keys should work, to avoid the overhead of polling for something (relatively) incredibly rare, but perhaps I'm wrong :/ > > To be honest, I've missed that this is still polled. I've had this set to polled mode, as I've > had some issues (were to dumb) to get the pinmux going. I'll switch this to interrupt triggered and report back. > >> >>> +        poll-interval = <100>; >>> + >>> +        pinctrl-names = "default"; >>> +        pinctrl-0 = <&button_pins>; >>> + >>> +        reset { >>> +            label = "Reset Button"; >>> +            gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>; >>> +            linux,code = ; >>> +            debounce-interval = <50>; >>> +        }; >>> +    }; >>> +}; >>> + >>> +&cpu0 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu1 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu2 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu3 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&gmac2io { >>> +    assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>; >>> +    assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>; >>> +    clock_in_out = "input"; >>> +    phy-supply = <&vcc_io>; >>> +    phy-handle = <&rtl8211e>; >>> +    phy-mode = "rgmii"; >>> +    pinctrl-names = "default"; >>> +    pinctrl-0 = <&rgmiim1_pins>; >>> +    snps,aal; >> >> Is this needed over and above the txpbl fix present in the main DTSI? I forget exactly where all those discussions ended up, but if it matters here then it probably matters for all RK3328 boards. > > It seems to matter, as otherwise forwards from LAN to WAN will result in tx_fifo errors. On second look it's already present in half the existing RK3328 DTs (including the one I wrote, ahem...), so probably does deserve promoting into the DTSI. >>> +    snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; >>> +    snps,reset-active-low; >>> +    snps,reset-delays-us = <0 10000 50000>; >> >> Since you're describing the phy already, you can convert these to generic reset specifiers on the phy node itself (shame we don't have an interrupt wired up, oh well...) > > Yup, I've forgotten that there's reset-gpio bindings for the PHY itself. > >> >>> +    tx_delay = <0x24>; >>> +    rx_delay = <0x18>; >>> +    status = "okay"; >>> + >>> +    mdio { >>> +        compatible = "snps,dwmac-mdio"; >>> +        #address-cells = <1>; >>> +        #size-cells = <0>; >>> + >>> +        rtl8211e: ethernet-phy@0 { >>> +            reg = <0>; >> >> Is that right? The schematic says the phy is strapped for address 1 (although 0 probably does manage to work since it should be interpreted as a broadcast address). > > I'll test this. > >> >>> +        }; >>> +    }; >>> +}; >>> + >>> +&i2c1 { >>> +    status = "okay"; >>> + >>> +    rk805: rk805@18 { >>> +        compatible = "rockchip,rk805"; >>> +        reg = <0x18>; >>> +        interrupt-parent = <&gpio2>; >>> +        interrupts = <6 IRQ_TYPE_LEVEL_LOW>; >> >> The schematic says GPIO1_D0 for this. > > You are right, I'll fix this. > >>> + >> >> It shouldn't hurt to enable PWM2 from the outset to make mucking about with the fan easier. > > I've seen reports of people having Fans on their NanoPi R2S, my unit does not have such Yeah, mine came with the version 2 heatsink/fan fitted, although upon investigation it turns out the PWM is next to useless (something's off with rise times in the external MOSFET switching setup) and the fan connector may as well just be treated as GPIO-controlled anyway. >>> +&sdmmc { >>> +    bus-width = <4>; >>> +    cap-mmc-highspeed; >>> +    cap-sd-highspeed; >> >> How about UHS modes, since we have the requisite I/O voltage support? > > I'll look into this. FWIW SDR104 seems to be working fine for me, with the PMIC interrupt corrected so as not to break the regulator. >> >>> +    disable-wp; >> >> I believe this property is only meant for full-size MMC/SD sockets where write-protect functionality is expected but somehow broken. For micro-SD sockets the SoC pin should be hard-wired to write-enable anyway and thus it shouldn't need to be stated. > > Thanks for this explanation, I'll remove and re-test. Actually I think I was mistaken there - having double-checked the binding definition and datasheet it looks like RK3328 doesn't expose the WP function on any pin at all, so by the letter of the binding this *should* be specified for correctness (since we don't necessarily know for sure that the controller's internal WP line isn't left floating). Sorry for the confusion. Cheers, Robin. >> >>> +    max-frequency = <150000000>; >> >> This is in the DTSI already. >> >>> +    pinctrl-names = "default"; >>> +    pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>; >>> +    vmmc-supply = <&vcc_sd>; >>> +    vqmmc-supply = <&vcc_sdio>; >>> +    status = "okay"; >>> +}; >>> + >>> +&tsadc { >>> +    rockchip,hw-tshut-mode = <0>; >>> +    rockchip,hw-tshut-polarity = <0>; >>> +    status = "okay"; >>> +}; >>> + >>> +&uart2 { >>> +    status = "okay"; >>> +}; >>> + >>> +&u2phy { >>> +    status = "okay"; >>> + >>> +    u2phy_host: host-port { >> >> Just reference this by label directly, rather than as a child node here (especially since redefining the existing label is a bit confusing). >> >>> +        status = "okay"; >>> +    }; >>> +}; >> >> No reason not to enable the OTG port either - I've hacked that in with g_serial for a cheeky console while powering the board from my laptop and it works fine. > > Ouch, I've completely missed the micro-USB port is wired up to the OTG port. > > I'll follow up with a v3 in the coming days. Thanks for your feedback! > > Best wishes > David > >> >> Cheers, >> Robin. >> >>> + >>> +&usb_host0_ehci { >>> +    status = "okay"; >>> +}; >>> + >>> +&usb_host0_ohci { >>> +    status = "okay"; >>> +}; >>> > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH v2 2/2] rockchip: rk3328: Add support for FriendlyARM NanoPi R2S Date: Sat, 8 Aug 2020 23:00:35 +0100 Message-ID: References: <20200730232054.286381-1-mail@david-bauer.net> <20200730232054.286381-2-mail@david-bauer.net> <685c3ab2-5f51-1fc2-622d-4d9785d7074b@david-bauer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <685c3ab2-5f51-1fc2-622d-4d9785d7074b-YgwEh8z+B+JYon68uE86FQ@public.gmane.org> Content-Language: en-GB Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Bauer , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-rockchip.vger.kernel.org On 2020-08-06 07:57, David Bauer wrote: > Hi Robin, > > thanks for your review. Only adressing some non-formal comments below. > > On 8/3/20 12:01 AM, Robin Murphy wrote: >> >> This seems to match the schematic, however in practice the GPIO seems to have a mind of its own and not respond to the LED settings - are we missing something with the pinctrl perhaps? > > Hmm, this is strange. It works fine on my unit (with the current OpenWrt release). Can you test this and report back? It seems like somehow that particular GPIO doesn't get configured properly and is still in its default out-of-reset state as an input. Poking the GPIO from sysfs works as expected, and in fact just unbinding and rebinding the leds-gpio driver also manages to kick things into shape. Clearly there's some subtle driver-level issue, but at least it's not a DT problem :) >>> +            label = "nanopi-r2s:green:lan"; >>> +        }; >>> + >>> +        wan { >>> +            gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_HIGH>; >>> +            label = "nanopi-r2s:green:wan"; >>> +        }; >>> +    }; >>> + >>> +    gpio_keys { >>> +        compatible = "gpio-keys-polled"; >> >> Does this need to be polled? I would have thought regular interrupt-based gpio-keys should work, to avoid the overhead of polling for something (relatively) incredibly rare, but perhaps I'm wrong :/ > > To be honest, I've missed that this is still polled. I've had this set to polled mode, as I've > had some issues (were to dumb) to get the pinmux going. I'll switch this to interrupt triggered and report back. > >> >>> +        poll-interval = <100>; >>> + >>> +        pinctrl-names = "default"; >>> +        pinctrl-0 = <&button_pins>; >>> + >>> +        reset { >>> +            label = "Reset Button"; >>> +            gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>; >>> +            linux,code = ; >>> +            debounce-interval = <50>; >>> +        }; >>> +    }; >>> +}; >>> + >>> +&cpu0 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu1 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu2 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&cpu3 { >>> +    cpu-supply = <&vdd_arm>; >>> +}; >>> + >>> +&gmac2io { >>> +    assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>; >>> +    assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>; >>> +    clock_in_out = "input"; >>> +    phy-supply = <&vcc_io>; >>> +    phy-handle = <&rtl8211e>; >>> +    phy-mode = "rgmii"; >>> +    pinctrl-names = "default"; >>> +    pinctrl-0 = <&rgmiim1_pins>; >>> +    snps,aal; >> >> Is this needed over and above the txpbl fix present in the main DTSI? I forget exactly where all those discussions ended up, but if it matters here then it probably matters for all RK3328 boards. > > It seems to matter, as otherwise forwards from LAN to WAN will result in tx_fifo errors. On second look it's already present in half the existing RK3328 DTs (including the one I wrote, ahem...), so probably does deserve promoting into the DTSI. >>> +    snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; >>> +    snps,reset-active-low; >>> +    snps,reset-delays-us = <0 10000 50000>; >> >> Since you're describing the phy already, you can convert these to generic reset specifiers on the phy node itself (shame we don't have an interrupt wired up, oh well...) > > Yup, I've forgotten that there's reset-gpio bindings for the PHY itself. > >> >>> +    tx_delay = <0x24>; >>> +    rx_delay = <0x18>; >>> +    status = "okay"; >>> + >>> +    mdio { >>> +        compatible = "snps,dwmac-mdio"; >>> +        #address-cells = <1>; >>> +        #size-cells = <0>; >>> + >>> +        rtl8211e: ethernet-phy@0 { >>> +            reg = <0>; >> >> Is that right? The schematic says the phy is strapped for address 1 (although 0 probably does manage to work since it should be interpreted as a broadcast address). > > I'll test this. > >> >>> +        }; >>> +    }; >>> +}; >>> + >>> +&i2c1 { >>> +    status = "okay"; >>> + >>> +    rk805: rk805@18 { >>> +        compatible = "rockchip,rk805"; >>> +        reg = <0x18>; >>> +        interrupt-parent = <&gpio2>; >>> +        interrupts = <6 IRQ_TYPE_LEVEL_LOW>; >> >> The schematic says GPIO1_D0 for this. > > You are right, I'll fix this. > >>> + >> >> It shouldn't hurt to enable PWM2 from the outset to make mucking about with the fan easier. > > I've seen reports of people having Fans on their NanoPi R2S, my unit does not have such Yeah, mine came with the version 2 heatsink/fan fitted, although upon investigation it turns out the PWM is next to useless (something's off with rise times in the external MOSFET switching setup) and the fan connector may as well just be treated as GPIO-controlled anyway. >>> +&sdmmc { >>> +    bus-width = <4>; >>> +    cap-mmc-highspeed; >>> +    cap-sd-highspeed; >> >> How about UHS modes, since we have the requisite I/O voltage support? > > I'll look into this. FWIW SDR104 seems to be working fine for me, with the PMIC interrupt corrected so as not to break the regulator. >> >>> +    disable-wp; >> >> I believe this property is only meant for full-size MMC/SD sockets where write-protect functionality is expected but somehow broken. For micro-SD sockets the SoC pin should be hard-wired to write-enable anyway and thus it shouldn't need to be stated. > > Thanks for this explanation, I'll remove and re-test. Actually I think I was mistaken there - having double-checked the binding definition and datasheet it looks like RK3328 doesn't expose the WP function on any pin at all, so by the letter of the binding this *should* be specified for correctness (since we don't necessarily know for sure that the controller's internal WP line isn't left floating). Sorry for the confusion. Cheers, Robin. >> >>> +    max-frequency = <150000000>; >> >> This is in the DTSI already. >> >>> +    pinctrl-names = "default"; >>> +    pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>; >>> +    vmmc-supply = <&vcc_sd>; >>> +    vqmmc-supply = <&vcc_sdio>; >>> +    status = "okay"; >>> +}; >>> + >>> +&tsadc { >>> +    rockchip,hw-tshut-mode = <0>; >>> +    rockchip,hw-tshut-polarity = <0>; >>> +    status = "okay"; >>> +}; >>> + >>> +&uart2 { >>> +    status = "okay"; >>> +}; >>> + >>> +&u2phy { >>> +    status = "okay"; >>> + >>> +    u2phy_host: host-port { >> >> Just reference this by label directly, rather than as a child node here (especially since redefining the existing label is a bit confusing). >> >>> +        status = "okay"; >>> +    }; >>> +}; >> >> No reason not to enable the OTG port either - I've hacked that in with g_serial for a cheeky console while powering the board from my laptop and it works fine. > > Ouch, I've completely missed the micro-USB port is wired up to the OTG port. > > I'll follow up with a v3 in the coming days. Thanks for your feedback! > > Best wishes > David > >> >> Cheers, >> Robin. >> >>> + >>> +&usb_host0_ehci { >>> +    status = "okay"; >>> +}; >>> + >>> +&usb_host0_ohci { >>> +    status = "okay"; >>> +}; >>> > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABF6DC433DF for ; Sat, 8 Aug 2020 22:03:28 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 57E38206C3 for ; Sat, 8 Aug 2020 22:03:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bYS8ufYa" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57E38206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7sZJ+AzH7IMMadFqQvQyYLQAD+AKm8xWk62ZPClzOtc=; b=bYS8ufYaJrX5zwDZCXHahdZYY lX5hp87Mq0Pi17vKndaGSzcSfSIEw2IsELtySgkTWL9X37qgiV7mMWfLwXOs21awjjByNd0pVRmYa ywrjD0orDyq3s2+SzZijIctcmoktXutlvE/TkaDj62wBfojVzJV8GiuAj+qqIcrzhu6sjyeWJH+oK Nu8BmnZYxfkqXoiiuvro2//QdAwawG0KoIcuL+gsu5gT600tpDth72Dl3fOHcforWQsAIwZOy83Yp MapioaBi3CtlR7dLh9Sjhfnbva6I7jZbMwkO9+sU0JwaJkJyvmHToOACeXm5vnu9NItORB6EjVgCU MvTiqZKEg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k4WtW-00033F-Qz; Sat, 08 Aug 2020 22:00:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k4WtU-00032m-0a; Sat, 08 Aug 2020 22:00:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5ACF7D6E; Sat, 8 Aug 2020 15:00:38 -0700 (PDT) Received: from [10.57.35.143] (unknown [10.57.35.143]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 79C243F7D8; Sat, 8 Aug 2020 15:00:37 -0700 (PDT) Subject: Re: [PATCH v2 2/2] rockchip: rk3328: Add support for FriendlyARM NanoPi R2S To: David Bauer , linux-arm-kernel@lists.infradead.org References: <20200730232054.286381-1-mail@david-bauer.net> <20200730232054.286381-2-mail@david-bauer.net> <685c3ab2-5f51-1fc2-622d-4d9785d7074b@david-bauer.net> From: Robin Murphy Message-ID: Date: Sat, 8 Aug 2020 23:00:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <685c3ab2-5f51-1fc2-622d-4d9785d7074b@david-bauer.net> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200808_180048_190651_2B7A7F13 X-CRM114-Status: GOOD ( 37.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gMjAyMC0wOC0wNiAwNzo1NywgRGF2aWQgQmF1ZXIgd3JvdGU6Cj4gSGkgUm9iaW4sCj4gCj4g dGhhbmtzIGZvciB5b3VyIHJldmlldy4gT25seSBhZHJlc3Npbmcgc29tZSBub24tZm9ybWFsIGNv bW1lbnRzIGJlbG93Lgo+IAo+IE9uIDgvMy8yMCAxMjowMSBBTSwgUm9iaW4gTXVycGh5IHdyb3Rl Ogo+Pgo+PiBUaGlzIHNlZW1zIHRvIG1hdGNoIHRoZSBzY2hlbWF0aWMsIGhvd2V2ZXIgaW4gcHJh Y3RpY2UgdGhlIEdQSU8gc2VlbXMgdG8gaGF2ZSBhIG1pbmQgb2YgaXRzIG93biBhbmQgbm90IHJl c3BvbmQgdG8gdGhlIExFRCBzZXR0aW5ncyAtIGFyZSB3ZSBtaXNzaW5nIHNvbWV0aGluZyB3aXRo IHRoZSBwaW5jdHJsIHBlcmhhcHM/Cj4gCj4gSG1tLCB0aGlzIGlzIHN0cmFuZ2UuIEl0IHdvcmtz IGZpbmUgb24gbXkgdW5pdCAod2l0aCB0aGUgY3VycmVudCBPcGVuV3J0IHJlbGVhc2UpLiBDYW4g eW91IHRlc3QgdGhpcyBhbmQgcmVwb3J0IGJhY2s/CgpJdCBzZWVtcyBsaWtlIHNvbWVob3cgdGhh dCBwYXJ0aWN1bGFyIEdQSU8gZG9lc24ndCBnZXQgY29uZmlndXJlZCAKcHJvcGVybHkgYW5kIGlz IHN0aWxsIGluIGl0cyBkZWZhdWx0IG91dC1vZi1yZXNldCBzdGF0ZSBhcyBhbiBpbnB1dC4gClBv a2luZyB0aGUgR1BJTyBmcm9tIHN5c2ZzIHdvcmtzIGFzIGV4cGVjdGVkLCBhbmQgaW4gZmFjdCBq dXN0IHVuYmluZGluZyAKYW5kIHJlYmluZGluZyB0aGUgbGVkcy1ncGlvIGRyaXZlciBhbHNvIG1h bmFnZXMgdG8ga2ljayB0aGluZ3MgaW50byAKc2hhcGUuIENsZWFybHkgdGhlcmUncyBzb21lIHN1 YnRsZSBkcml2ZXItbGV2ZWwgaXNzdWUsIGJ1dCBhdCBsZWFzdCBpdCdzIApub3QgYSBEVCBwcm9i bGVtIDopCgo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbGFiZWwgPSAibmFub3BpLXIyczpn cmVlbjpsYW4iOwo+Pj4gK8KgwqDCoMKgwqDCoMKgIH07Cj4+PiArCj4+PiArwqDCoMKgwqDCoMKg wqAgd2FuIHsKPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGdwaW9zID0gPCZncGlvMiBSS19Q QzIgR1BJT19BQ1RJVkVfSElHSD47Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBsYWJlbCA9 ICJuYW5vcGktcjJzOmdyZWVuOndhbiI7Cj4+PiArwqDCoMKgwqDCoMKgwqAgfTsKPj4+ICvCoMKg wqAgfTsKPj4+ICsKPj4+ICvCoMKgwqAgZ3Bpb19rZXlzIHsKPj4+ICvCoMKgwqDCoMKgwqDCoCBj b21wYXRpYmxlID0gImdwaW8ta2V5cy1wb2xsZWQiOwo+Pgo+PiBEb2VzIHRoaXMgbmVlZCB0byBi ZSBwb2xsZWQ/IEkgd291bGQgaGF2ZSB0aG91Z2h0IHJlZ3VsYXIgaW50ZXJydXB0LWJhc2VkIGdw aW8ta2V5cyBzaG91bGQgd29yaywgdG8gYXZvaWQgdGhlIG92ZXJoZWFkIG9mIHBvbGxpbmcgZm9y IHNvbWV0aGluZyAocmVsYXRpdmVseSkgaW5jcmVkaWJseSByYXJlLCBidXQgcGVyaGFwcyBJJ20g d3JvbmcgOi8KPiAKPiBUbyBiZSBob25lc3QsIEkndmUgbWlzc2VkIHRoYXQgdGhpcyBpcyBzdGls bCBwb2xsZWQuIEkndmUgaGFkIHRoaXMgc2V0IHRvIHBvbGxlZCBtb2RlLCBhcyBJJ3ZlCj4gaGFk IHNvbWUgaXNzdWVzICh3ZXJlIHRvIGR1bWIpIHRvIGdldCB0aGUgcGlubXV4IGdvaW5nLiBJJ2xs IHN3aXRjaCB0aGlzIHRvIGludGVycnVwdCB0cmlnZ2VyZWQgYW5kIHJlcG9ydCBiYWNrLgo+IAo+ Pgo+Pj4gK8KgwqDCoMKgwqDCoMKgIHBvbGwtaW50ZXJ2YWwgPSA8MTAwPjsKPj4+ICsKPj4+ICvC oMKgwqDCoMKgwqDCoCBwaW5jdHJsLW5hbWVzID0gImRlZmF1bHQiOwo+Pj4gK8KgwqDCoMKgwqDC oMKgIHBpbmN0cmwtMCA9IDwmYnV0dG9uX3BpbnM+Owo+Pj4gKwo+Pj4gK8KgwqDCoMKgwqDCoMKg IHJlc2V0IHsKPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxhYmVsID0gIlJlc2V0IEJ1dHRv biI7Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBncGlvcyA9IDwmZ3BpbzAgUktfUEEwIEdQ SU9fQUNUSVZFX0xPVz47Cj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBsaW51eCxjb2RlID0g PEtFWV9SRVNUQVJUPjsKPj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRlYm91bmNlLWludGVy dmFsID0gPDUwPjsKPj4+ICvCoMKgwqDCoMKgwqDCoCB9Owo+Pj4gK8KgwqDCoCB9Owo+Pj4gK307 Cj4+PiArCj4+PiArJmNwdTAgewo+Pj4gK8KgwqDCoCBjcHUtc3VwcGx5ID0gPCZ2ZGRfYXJtPjsK Pj4+ICt9Owo+Pj4gKwo+Pj4gKyZjcHUxIHsKPj4+ICvCoMKgwqAgY3B1LXN1cHBseSA9IDwmdmRk X2FybT47Cj4+PiArfTsKPj4+ICsKPj4+ICsmY3B1MiB7Cj4+PiArwqDCoMKgIGNwdS1zdXBwbHkg PSA8JnZkZF9hcm0+Owo+Pj4gK307Cj4+PiArCj4+PiArJmNwdTMgewo+Pj4gK8KgwqDCoCBjcHUt c3VwcGx5ID0gPCZ2ZGRfYXJtPjsKPj4+ICt9Owo+Pj4gKwo+Pj4gKyZnbWFjMmlvIHsKPj4+ICvC oMKgwqAgYXNzaWduZWQtY2xvY2tzID0gPCZjcnUgU0NMS19NQUMySU8+LCA8JmNydSBTQ0xLX01B QzJJT19FWFQ+Owo+Pj4gK8KgwqDCoCBhc3NpZ25lZC1jbG9jay1wYXJlbnRzID0gPCZnbWFjX2Ns a2luPiwgPCZnbWFjX2Nsa2luPjsKPj4+ICvCoMKgwqAgY2xvY2tfaW5fb3V0ID0gImlucHV0IjsK Pj4+ICvCoMKgwqAgcGh5LXN1cHBseSA9IDwmdmNjX2lvPjsKPj4+ICvCoMKgwqAgcGh5LWhhbmRs ZSA9IDwmcnRsODIxMWU+Owo+Pj4gK8KgwqDCoCBwaHktbW9kZSA9ICJyZ21paSI7Cj4+PiArwqDC oMKgIHBpbmN0cmwtbmFtZXMgPSAiZGVmYXVsdCI7Cj4+PiArwqDCoMKgIHBpbmN0cmwtMCA9IDwm cmdtaWltMV9waW5zPjsKPj4+ICvCoMKgwqAgc25wcyxhYWw7Cj4+Cj4+IElzIHRoaXMgbmVlZGVk IG92ZXIgYW5kIGFib3ZlIHRoZSB0eHBibCBmaXggcHJlc2VudCBpbiB0aGUgbWFpbiBEVFNJPyBJ IGZvcmdldCBleGFjdGx5IHdoZXJlIGFsbCB0aG9zZSBkaXNjdXNzaW9ucyBlbmRlZCB1cCwgYnV0 IGlmIGl0IG1hdHRlcnMgaGVyZSB0aGVuIGl0IHByb2JhYmx5IG1hdHRlcnMgZm9yIGFsbCBSSzMz MjggYm9hcmRzLgo+IAo+IEl0IHNlZW1zIHRvIG1hdHRlciwgYXMgb3RoZXJ3aXNlIGZvcndhcmRz IGZyb20gTEFOIHRvIFdBTiB3aWxsIHJlc3VsdCBpbiB0eF9maWZvIGVycm9ycy4KCk9uIHNlY29u ZCBsb29rIGl0J3MgYWxyZWFkeSBwcmVzZW50IGluIGhhbGYgdGhlIGV4aXN0aW5nIFJLMzMyOCBE VHMgCihpbmNsdWRpbmcgdGhlIG9uZSBJIHdyb3RlLCBhaGVtLi4uKSwgc28gcHJvYmFibHkgZG9l cyBkZXNlcnZlIHByb21vdGluZyAKaW50byB0aGUgRFRTSS4KCj4+PiArwqDCoMKgIHNucHMscmVz ZXQtZ3BpbyA9IDwmZ3BpbzEgUktfUEMyIEdQSU9fQUNUSVZFX0xPVz47Cj4+PiArwqDCoMKgIHNu cHMscmVzZXQtYWN0aXZlLWxvdzsKPj4+ICvCoMKgwqAgc25wcyxyZXNldC1kZWxheXMtdXMgPSA8 MCAxMDAwMCA1MDAwMD47Cj4+Cj4+IFNpbmNlIHlvdSdyZSBkZXNjcmliaW5nIHRoZSBwaHkgYWxy ZWFkeSwgeW91IGNhbiBjb252ZXJ0IHRoZXNlIHRvIGdlbmVyaWMgcmVzZXQgc3BlY2lmaWVycyBv biB0aGUgcGh5IG5vZGUgaXRzZWxmIChzaGFtZSB3ZSBkb24ndCBoYXZlIGFuIGludGVycnVwdCB3 aXJlZCB1cCwgb2ggd2VsbC4uLikKPiAKPiBZdXAsIEkndmUgZm9yZ290dGVuIHRoYXQgdGhlcmUn cyByZXNldC1ncGlvIGJpbmRpbmdzIGZvciB0aGUgUEhZIGl0c2VsZi4KPiAKPj4KPj4+ICvCoMKg wqAgdHhfZGVsYXkgPSA8MHgyND47Cj4+PiArwqDCoMKgIHJ4X2RlbGF5ID0gPDB4MTg+Owo+Pj4g K8KgwqDCoCBzdGF0dXMgPSAib2theSI7Cj4+PiArCj4+PiArwqDCoMKgIG1kaW8gewo+Pj4gK8Kg wqDCoMKgwqDCoMKgIGNvbXBhdGlibGUgPSAic25wcyxkd21hYy1tZGlvIjsKPj4+ICvCoMKgwqDC oMKgwqDCoCAjYWRkcmVzcy1jZWxscyA9IDwxPjsKPj4+ICvCoMKgwqDCoMKgwqDCoCAjc2l6ZS1j ZWxscyA9IDwwPjsKPj4+ICsKPj4+ICvCoMKgwqDCoMKgwqDCoCBydGw4MjExZTogZXRoZXJuZXQt cGh5QDAgewo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVnID0gPDA+Owo+Pgo+PiBJcyB0 aGF0IHJpZ2h0PyBUaGUgc2NoZW1hdGljIHNheXMgdGhlIHBoeSBpcyBzdHJhcHBlZCBmb3IgYWRk cmVzcyAxIChhbHRob3VnaCAwIHByb2JhYmx5IGRvZXMgbWFuYWdlIHRvIHdvcmsgc2luY2UgaXQg c2hvdWxkIGJlIGludGVycHJldGVkIGFzIGEgYnJvYWRjYXN0IGFkZHJlc3MpLgo+IAo+IEknbGwg dGVzdCB0aGlzLgo+IAo+Pgo+Pj4gK8KgwqDCoMKgwqDCoMKgIH07Cj4+PiArwqDCoMKgIH07Cj4+ PiArfTsKPj4+ICsKPj4+ICsmaTJjMSB7Cj4+PiArwqDCoMKgIHN0YXR1cyA9ICJva2F5IjsKPj4+ ICsKPj4+ICvCoMKgwqAgcms4MDU6IHJrODA1QDE4IHsKPj4+ICvCoMKgwqDCoMKgwqDCoCBjb21w YXRpYmxlID0gInJvY2tjaGlwLHJrODA1IjsKPj4+ICvCoMKgwqDCoMKgwqDCoCByZWcgPSA8MHgx OD47Cj4+PiArwqDCoMKgwqDCoMKgwqAgaW50ZXJydXB0LXBhcmVudCA9IDwmZ3BpbzI+Owo+Pj4g K8KgwqDCoMKgwqDCoMKgIGludGVycnVwdHMgPSA8NiBJUlFfVFlQRV9MRVZFTF9MT1c+Owo+Pgo+ PiBUaGUgc2NoZW1hdGljIHNheXMgR1BJTzFfRDAgZm9yIHRoaXMuCj4gCj4gWW91IGFyZSByaWdo dCwgSSdsbCBmaXggdGhpcy4KPiAKPj4+ICsKPj4KPj4gSXQgc2hvdWxkbid0IGh1cnQgdG8gZW5h YmxlIFBXTTIgZnJvbSB0aGUgb3V0c2V0IHRvIG1ha2UgbXVja2luZyBhYm91dCB3aXRoIHRoZSBm YW4gZWFzaWVyLgo+IAo+IEkndmUgc2VlbiByZXBvcnRzIG9mIHBlb3BsZSBoYXZpbmcgRmFucyBv biB0aGVpciBOYW5vUGkgUjJTLCBteSB1bml0IGRvZXMgbm90IGhhdmUgc3VjaAoKWWVhaCwgbWlu ZSBjYW1lIHdpdGggdGhlIHZlcnNpb24gMiBoZWF0c2luay9mYW4gZml0dGVkLCBhbHRob3VnaCB1 cG9uIAppbnZlc3RpZ2F0aW9uIGl0IHR1cm5zIG91dCB0aGUgUFdNIGlzIG5leHQgdG8gdXNlbGVz cyAoc29tZXRoaW5nJ3Mgb2ZmIAp3aXRoIHJpc2UgdGltZXMgaW4gdGhlIGV4dGVybmFsIE1PU0ZF VCBzd2l0Y2hpbmcgc2V0dXApIGFuZCB0aGUgZmFuIApjb25uZWN0b3IgbWF5IGFzIHdlbGwganVz dCBiZSB0cmVhdGVkIGFzIEdQSU8tY29udHJvbGxlZCBhbnl3YXkuCgo+Pj4gKyZzZG1tYyB7Cj4+ PiArwqDCoMKgIGJ1cy13aWR0aCA9IDw0PjsKPj4+ICvCoMKgwqAgY2FwLW1tYy1oaWdoc3BlZWQ7 Cj4+PiArwqDCoMKgIGNhcC1zZC1oaWdoc3BlZWQ7Cj4+Cj4+IEhvdyBhYm91dCBVSFMgbW9kZXMs IHNpbmNlIHdlIGhhdmUgdGhlIHJlcXVpc2l0ZSBJL08gdm9sdGFnZSBzdXBwb3J0Pwo+IAo+IEkn bGwgbG9vayBpbnRvIHRoaXMuCgpGV0lXIFNEUjEwNCBzZWVtcyB0byBiZSB3b3JraW5nIGZpbmUg Zm9yIG1lLCB3aXRoIHRoZSBQTUlDIGludGVycnVwdCAKY29ycmVjdGVkIHNvIGFzIG5vdCB0byBi cmVhayB0aGUgcmVndWxhdG9yLgoKPj4KPj4+ICvCoMKgwqAgZGlzYWJsZS13cDsKPj4KPj4gSSBi ZWxpZXZlIHRoaXMgcHJvcGVydHkgaXMgb25seSBtZWFudCBmb3IgZnVsbC1zaXplIE1NQy9TRCBz b2NrZXRzIHdoZXJlIHdyaXRlLXByb3RlY3QgZnVuY3Rpb25hbGl0eSBpcyBleHBlY3RlZCBidXQg c29tZWhvdyBicm9rZW4uIEZvciBtaWNyby1TRCBzb2NrZXRzIHRoZSBTb0MgcGluIHNob3VsZCBi ZSBoYXJkLXdpcmVkIHRvIHdyaXRlLWVuYWJsZSBhbnl3YXkgYW5kIHRodXMgaXQgc2hvdWxkbid0 IG5lZWQgdG8gYmUgc3RhdGVkLgo+IAo+IFRoYW5rcyBmb3IgdGhpcyBleHBsYW5hdGlvbiwgSSds bCByZW1vdmUgYW5kIHJlLXRlc3QuCgpBY3R1YWxseSBJIHRoaW5rIEkgd2FzIG1pc3Rha2VuIHRo ZXJlIC0gaGF2aW5nIGRvdWJsZS1jaGVja2VkIHRoZSAKYmluZGluZyBkZWZpbml0aW9uIGFuZCBk YXRhc2hlZXQgaXQgbG9va3MgbGlrZSBSSzMzMjggZG9lc24ndCBleHBvc2UgdGhlIApXUCBmdW5j dGlvbiBvbiBhbnkgcGluIGF0IGFsbCwgc28gYnkgdGhlIGxldHRlciBvZiB0aGUgYmluZGluZyB0 aGlzIAoqc2hvdWxkKiBiZSBzcGVjaWZpZWQgZm9yIGNvcnJlY3RuZXNzIChzaW5jZSB3ZSBkb24n dCBuZWNlc3NhcmlseSBrbm93IApmb3Igc3VyZSB0aGF0IHRoZSBjb250cm9sbGVyJ3MgaW50ZXJu YWwgV1AgbGluZSBpc24ndCBsZWZ0IGZsb2F0aW5nKS4gClNvcnJ5IGZvciB0aGUgY29uZnVzaW9u LgoKQ2hlZXJzLApSb2Jpbi4KCj4+Cj4+PiArwqDCoMKgIG1heC1mcmVxdWVuY3kgPSA8MTUwMDAw MDAwPjsKPj4KPj4gVGhpcyBpcyBpbiB0aGUgRFRTSSBhbHJlYWR5Lgo+Pgo+Pj4gK8KgwqDCoCBw aW5jdHJsLW5hbWVzID0gImRlZmF1bHQiOwo+Pj4gK8KgwqDCoCBwaW5jdHJsLTAgPSA8JnNkbW1j MF9jbGsgJnNkbW1jMF9jbWQgJnNkbW1jMF9kZWN0biAmc2RtbWMwX2J1czQ+Owo+Pj4gK8KgwqDC oCB2bW1jLXN1cHBseSA9IDwmdmNjX3NkPjsKPj4+ICvCoMKgwqAgdnFtbWMtc3VwcGx5ID0gPCZ2 Y2Nfc2Rpbz47Cj4+PiArwqDCoMKgIHN0YXR1cyA9ICJva2F5IjsKPj4+ICt9Owo+Pj4gKwo+Pj4g KyZ0c2FkYyB7Cj4+PiArwqDCoMKgIHJvY2tjaGlwLGh3LXRzaHV0LW1vZGUgPSA8MD47Cj4+PiAr wqDCoMKgIHJvY2tjaGlwLGh3LXRzaHV0LXBvbGFyaXR5ID0gPDA+Owo+Pj4gK8KgwqDCoCBzdGF0 dXMgPSAib2theSI7Cj4+PiArfTsKPj4+ICsKPj4+ICsmdWFydDIgewo+Pj4gK8KgwqDCoCBzdGF0 dXMgPSAib2theSI7Cj4+PiArfTsKPj4+ICsKPj4+ICsmdTJwaHkgewo+Pj4gK8KgwqDCoCBzdGF0 dXMgPSAib2theSI7Cj4+PiArCj4+PiArwqDCoMKgIHUycGh5X2hvc3Q6IGhvc3QtcG9ydCB7Cj4+ Cj4+IEp1c3QgcmVmZXJlbmNlIHRoaXMgYnkgbGFiZWwgZGlyZWN0bHksIHJhdGhlciB0aGFuIGFz IGEgY2hpbGQgbm9kZSBoZXJlIChlc3BlY2lhbGx5IHNpbmNlIHJlZGVmaW5pbmcgdGhlIGV4aXN0 aW5nIGxhYmVsIGlzIGEgYml0IGNvbmZ1c2luZykuCj4+Cj4+PiArwqDCoMKgwqDCoMKgwqAgc3Rh dHVzID0gIm9rYXkiOwo+Pj4gK8KgwqDCoCB9Owo+Pj4gK307Cj4+Cj4+IE5vIHJlYXNvbiBub3Qg dG8gZW5hYmxlIHRoZSBPVEcgcG9ydCBlaXRoZXIgLSBJJ3ZlIGhhY2tlZCB0aGF0IGluIHdpdGgg Z19zZXJpYWwgZm9yIGEgY2hlZWt5IGNvbnNvbGUgd2hpbGUgcG93ZXJpbmcgdGhlIGJvYXJkIGZy b20gbXkgbGFwdG9wIGFuZCBpdCB3b3JrcyBmaW5lLgo+IAo+IE91Y2gsIEkndmUgY29tcGxldGVs eSBtaXNzZWQgdGhlIG1pY3JvLVVTQiBwb3J0IGlzIHdpcmVkIHVwIHRvIHRoZSBPVEcgcG9ydC4K PiAKPiBJJ2xsIGZvbGxvdyB1cCB3aXRoIGEgdjMgaW4gdGhlIGNvbWluZyBkYXlzLiBUaGFua3Mg Zm9yIHlvdXIgZmVlZGJhY2shCj4gCj4gQmVzdCB3aXNoZXMKPiBEYXZpZAo+IAo+Pgo+PiBDaGVl cnMsCj4+IFJvYmluLgo+Pgo+Pj4gKwo+Pj4gKyZ1c2JfaG9zdDBfZWhjaSB7Cj4+PiArwqDCoMKg IHN0YXR1cyA9ICJva2F5IjsKPj4+ICt9Owo+Pj4gKwo+Pj4gKyZ1c2JfaG9zdDBfb2hjaSB7Cj4+ PiArwqDCoMKgIHN0YXR1cyA9ICJva2F5IjsKPj4+ICt9Owo+Pj4KPiAKPiAKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFp bGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlz dHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK