devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-clk@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCHv3 0/9] RK3588 Clock and Reset Support
Date: Thu, 2 Feb 2023 14:10:06 +0800	[thread overview]
Message-ID: <f3415e9d-ae8d-201b-a9d7-07d3e9bd3bf3@suse.com> (raw)
In-Reply-To: <20221121182836.kwkbnonulcwfzbg4@mercury.elektranox.org>



On 2022/11/22 02:28, Sebastian Reichel wrote:
> Hi Qu,
> 
> On Mon, Nov 21, 2022 at 04:52:22PM +0800, Qu Wenruo wrote:
>> On 2022/10/18 23:13, Sebastian Reichel wrote:
>>> This has been part of a bigger patchset adding basic rk3588 support.
>>> Since that gets more and more out of hand, I'm now sending patches
>>> for each subsystem as individual patchset.
>>
>> Awesome work! Thanks for the work to bring upstream support for RK3588.
>>
>> This upstream work is especially important since the vendor kernel has so
>> many weird things and is never properly tested using newer tool chains.
>>
>> But considering the support has been split into different patchset, is there
>> a git repo that I can fetch all the patches and test it on my Rock5B board?
> 
> try linux-next + https://lore.kernel.org/all/20221121175814.68927-1-sebastian.reichel@collabora.com/
> 
> It should boot, but that's about it. For Rock 5B there is not even
> ethernet support, since that needs PCIe. Ideally the DT series makes
> it in time for the 6.2 merge window.
> 
> Alternatively my working branch (I rebase that!) is available here:
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588
> It adds PMIC, thermal and cpufrequency support.

Sorry for the late reply, finally got my extra rock5b to do experiments.
(The existing one is now a VM host for 24x7 fstests runs)

[TEST REPORT]
Yes, I got the expected-to-work parts working:

- ttyS2 (serial@feb50000)
   Both earlycon and later initialized console.

- eMMC (mmc@fe2e0000)
   The rootfs read write seems fine.

   The latest code seems to have sdmmc, but ironically I don't have
   any sdcard at hand right now...

[PCIE ENABLEMENT]
Personally speaking, I can not care less about things like GMAC (Rock5B 
uses r8125), nor USB (PCIE rules them all) nor graphics (serial is good 
neough).

Thus I'm trying to see if I can re-use the rk3568 pcie drivers.

It looks like unlike RK3399, this time we need PHY for PCIE, and it is 
already done in rk3568 pcie controller, and the core AIX->PCIE is done 
by the designware core, thus it looks feasible to reuse the driver?

But I can be totally wrong, since I'm really just a newbie in arm world.

Any hint on the PCIE bus bringup? Or what I can help for the PCIE bringup?

I know RK3588S seems to cut the PCIE3 lanes completely, and droped one 
PCIE2.0 lane, but I don't know the address for the cut one...

[VENDOR KERNEL PCIE BUG]
Another thing I noticed with vendor (5.10.x) kernel is, the PCIE link up 
is unreliable, causing random reset.
Maybe the incoming upstream bring up can fix it?

Thanks,
Qu

> 
> -- Sebastian

  reply	other threads:[~2023-02-02  6:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 15:13 [PATCHv3 0/9] RK3588 Clock and Reset Support Sebastian Reichel
2022-10-18 15:13 ` [PATCHv3 1/9] dt-bindings: clock: add rk3588 clock definitions Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 2/9] dt-bindings: reset: add rk3588 reset definitions Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 3/9] dt-bindings: clock: add rk3588 cru bindings Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 4/9] clk: rockchip: add register offset of the cores select parent Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 5/9] clk: rockchip: add pll type for RK3588 Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 6/9] clk: rockchip: clk-cpu: add mux setting for cpu change frequency Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 7/9] clk: rockchip: simplify rockchip_clk_add_lookup Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 8/9] clk: rockchip: add lookup table support Sebastian Reichel
2022-10-18 15:14 ` [PATCHv3 9/9] clk: rockchip: add clock controller for the RK3588 Sebastian Reichel
2022-11-07 18:16 ` [PATCHv3 0/9] RK3588 Clock and Reset Support Sebastian Reichel
2022-11-15 11:10 ` Heiko Stuebner
2022-11-21  8:52 ` Qu Wenruo
2022-11-21 18:28   ` Sebastian Reichel
2023-02-02  6:10     ` Qu Wenruo [this message]
2023-02-03  1:34       ` Qu Wenruo

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=f3415e9d-ae8d-201b-a9d7-07d3e9bd3bf3@suse.com \
    --to=wqu@suse.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).