From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: "Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "Jonathan Hunter" <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, "Michał Mirosław" <mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>, "David Heidelberg" <david-W22tF5X+A20@public.gmane.org>, "Peter Geis" <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "Stephen Warren" <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>, "Nicolas Chauvet" <kwizart-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "Pedro Ângelo" <pangelo-yxaQD43p5Qo@public.gmane.org>, "Matt Merhar" <mattmerhar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org>, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v2 1/6] ARM: tegra: Add device-tree for Acer Iconia Tab A500 Date: Tue, 7 Apr 2020 12:41:09 +0200 [thread overview] Message-ID: <20200407104109.GC1720957@ulmo> (raw) In-Reply-To: <20200406194110.21283-2-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [-- Attachment #1: Type: text/plain, Size: 3611 bytes --] On Mon, Apr 06, 2020 at 10:41:05PM +0300, Dmitry Osipenko wrote: [...] > diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts [...] > + host1x@50000000 { > + dc@54200000 { > + rgb { > + status = "okay"; > + nvidia,panel = <&panel>; > + > + port@0 { > + lvds_output: endpoint { > + remote-endpoint = <&lvds_encoder_input>; > + bus-width = <18>; > + }; > + }; > + }; > + }; This seems a little strange to me, though, admittedly, I've never worked with these types of bridges before, so I may be misunderstanding this. I was under the impression that we could obtain the panel by traversing an OF graph, so that we didn't have to have that extra nvidia,panel property. As it is, you seem to describe two different paths, one that goes from the RGB output to the panel directly, and another that goes from the RGB output to the LVDS encoder and then to the panel. It doesn't seem to me like a direct link from RGB output to panel does actually exist in this setup. [...] > + pwm: pwm@7000a000 { > + status = "okay"; > + power-supply = <&vdd_3v3_sys>; > + }; I don't see power-supply defined as a property for the PWM controller. Why do you need this? [...] > + sdhci@c8000000 { > + status = "okay"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + max-frequency = <25000000>; > + keep-power-in-suspend; > + bus-width = <4>; > + non-removable; > + > + mmc-pwrseq = <&brcm_wifi_pwrseq>; > + vmmc-supply = <&vdd_3v3_sys>; > + vqmmc-supply = <&vdd_3v3_sys>; > + > + /* Azurewave AW-NH611 BCM4329 */ > + WiFi@1 { I think these names are supposed to be lowercase. > + reg = <1>; > + compatible = "brcm,bcm4329-fmac"; > + interrupt-parent = <&gpio>; > + interrupts = <TEGRA_GPIO(S, 0) IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "host-wake"; > + }; > + }; [...] > + clocks { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + clk32k_in: clock@0 { > + compatible = "fixed-clock"; > + reg = <0>; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + clock-output-names = "tps658621-out32k"; > + }; > + > + rtc_32k_wifi: clock@1 { > + compatible = "fixed-clock"; > + reg = <1>; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + clock-output-names = "kk3270032"; > + }; > + }; Are these clocks going to the PMIC and RTC, or are they generated by the chips? If they are generated by the chips, which sounds like they might be, wouldn't it be better to represent them as children of the corresponding chips? There's probably no infrastructure to do this, so maybe that would be overkill. But for clarity it might be worth documenting here where exactly these clocks come from. [...] > + memory-controller@7000f400 { > + nvidia,use-ram-code; > + > + emc-tables@elpida-8gb { I don't think unit-addresses are supposed to be freeform text like above. These should always reflect the value of the "reg" property, though in this case we don't have one... > + nvidia,ram-code = <0>; In retrospect it might have been better to just reuse the reg property for this. I think in this case it might be best to reflect the RAM code in the unit-address. At least that way we conceptually get things right since it's the RAM code that selects which of these tables is used, much like a register, I2C slave address, or SPI chip select would select which of the subdevices are targetted. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com> To: Dmitry Osipenko <digetx@gmail.com> Cc: "Rob Herring" <robh+dt@kernel.org>, "Jonathan Hunter" <jonathanh@nvidia.com>, "Michał Mirosław" <mirq-linux@rere.qmqm.pl>, "David Heidelberg" <david@ixit.cz>, "Peter Geis" <pgwipeout@gmail.com>, "Stephen Warren" <swarren@wwwdotorg.org>, "Nicolas Chauvet" <kwizart@gmail.com>, "Pedro Ângelo" <pangelo@void.io>, "Matt Merhar" <mattmerhar@protonmail.com>, linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/6] ARM: tegra: Add device-tree for Acer Iconia Tab A500 Date: Tue, 7 Apr 2020 12:41:09 +0200 [thread overview] Message-ID: <20200407104109.GC1720957@ulmo> (raw) In-Reply-To: <20200406194110.21283-2-digetx@gmail.com> [-- Attachment #1: Type: text/plain, Size: 3611 bytes --] On Mon, Apr 06, 2020 at 10:41:05PM +0300, Dmitry Osipenko wrote: [...] > diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts [...] > + host1x@50000000 { > + dc@54200000 { > + rgb { > + status = "okay"; > + nvidia,panel = <&panel>; > + > + port@0 { > + lvds_output: endpoint { > + remote-endpoint = <&lvds_encoder_input>; > + bus-width = <18>; > + }; > + }; > + }; > + }; This seems a little strange to me, though, admittedly, I've never worked with these types of bridges before, so I may be misunderstanding this. I was under the impression that we could obtain the panel by traversing an OF graph, so that we didn't have to have that extra nvidia,panel property. As it is, you seem to describe two different paths, one that goes from the RGB output to the panel directly, and another that goes from the RGB output to the LVDS encoder and then to the panel. It doesn't seem to me like a direct link from RGB output to panel does actually exist in this setup. [...] > + pwm: pwm@7000a000 { > + status = "okay"; > + power-supply = <&vdd_3v3_sys>; > + }; I don't see power-supply defined as a property for the PWM controller. Why do you need this? [...] > + sdhci@c8000000 { > + status = "okay"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + max-frequency = <25000000>; > + keep-power-in-suspend; > + bus-width = <4>; > + non-removable; > + > + mmc-pwrseq = <&brcm_wifi_pwrseq>; > + vmmc-supply = <&vdd_3v3_sys>; > + vqmmc-supply = <&vdd_3v3_sys>; > + > + /* Azurewave AW-NH611 BCM4329 */ > + WiFi@1 { I think these names are supposed to be lowercase. > + reg = <1>; > + compatible = "brcm,bcm4329-fmac"; > + interrupt-parent = <&gpio>; > + interrupts = <TEGRA_GPIO(S, 0) IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "host-wake"; > + }; > + }; [...] > + clocks { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + clk32k_in: clock@0 { > + compatible = "fixed-clock"; > + reg = <0>; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + clock-output-names = "tps658621-out32k"; > + }; > + > + rtc_32k_wifi: clock@1 { > + compatible = "fixed-clock"; > + reg = <1>; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + clock-output-names = "kk3270032"; > + }; > + }; Are these clocks going to the PMIC and RTC, or are they generated by the chips? If they are generated by the chips, which sounds like they might be, wouldn't it be better to represent them as children of the corresponding chips? There's probably no infrastructure to do this, so maybe that would be overkill. But for clarity it might be worth documenting here where exactly these clocks come from. [...] > + memory-controller@7000f400 { > + nvidia,use-ram-code; > + > + emc-tables@elpida-8gb { I don't think unit-addresses are supposed to be freeform text like above. These should always reflect the value of the "reg" property, though in this case we don't have one... > + nvidia,ram-code = <0>; In retrospect it might have been better to just reuse the reg property for this. I think in this case it might be best to reflect the RAM code in the unit-address. At least that way we conceptually get things right since it's the RAM code that selects which of these tables is used, much like a register, I2C slave address, or SPI chip select would select which of the subdevices are targetted. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-04-07 10:41 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-06 19:41 [PATCH v2 0/6] Support NVIDIA Tegra-based Acer A500 and Nexus 7 devices Dmitry Osipenko 2020-04-06 19:41 ` Dmitry Osipenko 2020-04-06 19:41 ` [PATCH v2 3/6] dt-bindings: Add vendor prefix for Acer Inc Dmitry Osipenko 2020-04-06 19:41 ` [PATCH v2 4/6] dt-bindings: ARM: tegra: Add Acer Iconia Tab A500 Dmitry Osipenko 2020-04-06 19:41 ` [PATCH v2 5/6] dt-bindings: ARM: tegra: Add ASUS Google Nexus 7 Dmitry Osipenko [not found] ` <20200406194110.21283-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-04-06 19:41 ` [PATCH v2 1/6] ARM: tegra: Add device-tree for Acer Iconia Tab A500 Dmitry Osipenko 2020-04-06 19:41 ` Dmitry Osipenko [not found] ` <20200406194110.21283-2-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-04-07 10:41 ` Thierry Reding [this message] 2020-04-07 10:41 ` Thierry Reding 2020-04-07 16:23 ` Dmitry Osipenko 2020-04-07 16:23 ` Dmitry Osipenko 2020-04-06 19:41 ` [PATCH v2 2/6] ARM: tegra: Add device-tree for ASUS Google Nexus 7 Dmitry Osipenko 2020-04-06 19:41 ` Dmitry Osipenko [not found] ` <20200406194110.21283-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-04-07 10:50 ` Thierry Reding 2020-04-07 10:50 ` Thierry Reding 2020-04-06 19:41 ` [PATCH v2 6/6] ARM: tegra_defconfig: Enable options useful for Nexus 7 and Acer A500 Dmitry Osipenko 2020-04-06 19:41 ` Dmitry Osipenko [not found] ` <20200406194110.21283-7-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-04-07 10:08 ` Thierry Reding 2020-04-07 10:08 ` Thierry Reding 2020-04-07 16:38 ` Dmitry Osipenko 2020-04-07 16:38 ` Dmitry Osipenko [not found] ` <70ad6fd6-9603-a114-2d0f-608110b68c0b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-04-08 0:37 ` Peter Geis 2020-04-08 0:37 ` Peter Geis [not found] ` <CAMdYzYr76GUEEXgKippfCJDTU1L+A0UXTyO_B14vkOxVp_pijw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2020-04-08 14:40 ` Dmitry Osipenko 2020-04-08 14:40 ` Dmitry Osipenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200407104109.GC1720957@ulmo \ --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \ --cc=david-W22tF5X+A20@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=kwizart-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mattmerhar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org \ --cc=mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org \ --cc=pangelo-yxaQD43p5Qo@public.gmane.org \ --cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.