Linux-Clk Archive on lore.kernel.org
 help / color / Atom feed
From: Ezequiel Garcia <ezequiel@collabora.com>
To: "Kever Yang" <kever.yang@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>
Cc: "Mylène Josserand" <mylene.josserand@collabora.com>,
	linux@armlinux.org.uk, mturquette@baylibre.com, sboyd@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, kernel@collabora.com,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision
Date: Fri, 06 Mar 2020 07:30:56 -0300
Message-ID: <8f3ef079b0c96d65e5855a58efd6d8dc32cd32e7.camel@collabora.com> (raw)
In-Reply-To: <933e1ce3-68be-9e78-18a3-eb3d4e038cfb@rock-chips.com>

On Fri, 2020-03-06 at 10:44 +0800, Kever Yang wrote:
> Hi Ezequiel,
> 
> 
> On 2020/3/5 下午7:35, Ezequiel Garcia wrote:
> > (Adding Kever to the loop)
> > 
> > On Thu, 2020-03-05 at 08:32 -0300, Ezequiel Garcia wrote:
> > > On Thu, 2020-03-05 at 01:51 +0100, Heiko Stübner wrote:
> > > > Hi Ezequiel,
> > > > 
> > > > Am Donnerstag, 5. März 2020, 01:03:30 CET schrieb Ezequiel Garcia:
> > > > > Hi Heiko,
> > > > > 
> > > > > On Wed, 2020-03-04 at 11:59 +0100, Heiko Stübner wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Am Montag, 2. März 2020, 16:57:02 CET schrieb Mylène Josserand:
> > > > > > > Determine which revision of rk3288 by checking the HDMI version.
> > > > > > > According to the Rockchip BSP kernel, on rk3288w, the HDMI
> > > > > > > revision equals 0x1A which is not the case for the rk3288 [1].
> > > > > > > 
> > > > > > > As these SOC have some differences, the new function
> > > > > > > 'soc_is_rk3288w' will help us to know on which revision
> > > > > > > we are.
> > > > > > what happened to just having a different compatible in the dts?
> > > > > > Aka doing a
> > > > > > 
> > > > > > rk3288w.dtsi with
> > > > > > 
> > > > > > #include "rk3288.dtsi"
> > > > > > 
> > > > > > &cru {
> > > > > > 	compatible = "rockchip,rk3288w-cru";
> > > > > > }
> > > > > > 
> > > > > I guess you have something like this in mind:
> > > > > 
> > > > > static void __init rk3288_clk_init(struct device_node *np)
> > > > > {
> > > > >          __rk3288_clk_init(np, RK3288_SOC_REV_RK3288W);
> > > > > }
> > > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init);
> > > > > 
> > > > > static void __init rk3288w_clk_init(struct device_node *np)
> > > > > {
> > > > >          __rk3288_clk_init(np, RK3288_SOC_REV_RK3288);
> > > > > }
> > > > > CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288w-cru", rk3288w_clk_init);
> > > > > 
> > > > > And the rest is mostly untouched, except the revision is
> > > > > no longer queried and is now passed by the DT?
> > > > Essentially yes, but I guess I was more thinking along the lines of
> > > > the rk3188/rk3066a/rk3188a (drivers/clk/rockchip/clk-rk3188.c)
> > > > 
> > > > 
> > > > > This would be cleaner for the kernel, with the obvious
> > > > > drawback being that you now have to maintain
> > > > > another DTS.
> > > > Right now we would end up with the pretty minimal devicetree
> > > > having just that cru. So not very invasive.
> > > > 
> > > > 
> > > > > This could be an inconvenience. I believe
> > > > > RK3288W is meant as a direct replacement for RK3288,
> > > > > so folks building products would expect to just use
> > > > > RK3288W, and not really bother with passing a
> > > > > different DTS or what not.
> > > > Not sure I follow. As below, I don't think boards will magically switch
> > > > between soc variants, so a boards devicetree should just include
> > > > the variant - especially as I don't really know how many
> > > > additional new boards we will see with it (rk3288 being quite old itself).
> > > > 
> > > It's not about new boards, any company does sells some RK32888-based product,
> > > will eventually want to produce some more.
> > > 
> > > If I understand correctly, RK3288W is the SoC that Rockchip is now offering,
> > > and not RK3288 anymore.
> 
> No, the RK3288 will continue to supply to the legacy projects which may 
> have a long contract with Rockchip,
> 
> and RK3288W is the recommend to use in all new project.
> 

I guess this means that if a company not having a long contract
wants to keep producing an RK3288-based product, it will have to
resort to RK3288W.

And IIRC, it's meant to be a direct replacement.
 
> > > So, if you have to produce another batch of _the same RK3288_ product,
> > > you'll have to use RK3288W. In other words, they would "just switch"
> > > between SoC variants.
> > > 
> > > In fact, such a case motivates these patches :-)
> > > 
> > > > > > I somehow don't expect boards to just switch between soc variants
> > > > > > on the fly.
> > > > > > 
> > > > > While I agree they are nasty, quirks like this
> > > > > are not uncommon.
> > > > > 
> > > > > > Also, doing things in mach-rockchip is not very future-proof:
> > > > > > 
> > > > > There is actually no reason to keep this in mach-rockchip, right?
> > > > > 
> > > > > The quirk could be placed in other places. For instance,
> > > > > directly in the clock driver.
> > > > Mapping the hdmi controller inside the clock driver to read some "random"
> > > > register that hopefully indicates an (undocumented) distinction between soc
> > > > variants.
> > > > 
> > > > Somehow just having that minimal devicetree for the "w" sounds
> > > > way cleaner ;-) .
> 
> I agree with Heiko on this.
> 
> What Rockchip done is:
> 
> - kernel is using "rockchip,rk3288w" compatible to identify rk3288w, 
> which is clean in kernel;
> 
> - kernel evb dts do not have compatible "rockchip,rk3288w" for we would 
> like to identify it dynamic in bootloader;
> 
> - We use U-Boot to identify the rk3288w with HDMI reg value, and pass it 
> to kernel via modify the
> 
>     dtb pass to kernel, so that we can support all kind of rockchip 
> customer projects with any kind of rk3288;
> 
> - For upstream kernel, it make sense to add "rockchip,rk3288w" in board 
> dts for which using rk3288w SoC.
> 

So you proposing to move this revision detection code
from the kernel to all the bootloaders (U-Boot is not the
only one, right?).

I understand that bootloaders are maybe less strict
to quirks like this, but OTOH this approach seems like
just movint things around, plus requiring now to update
two components, instead of just one.

And also, are we sure the bootloaders maintainers
will accept the quirk?

Thanks,
Ezequiel

 




  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 15:57 [PATCH 0/2] ARM: Add Rockchip rk3288w support Mylène Josserand
2020-03-02 15:57 ` [PATCH 1/2] ARM: Rockchip: Handle rk3288/rk3288w revision Mylène Josserand
2020-03-04 10:59   ` Heiko Stübner
2020-03-05  0:03     ` Ezequiel Garcia
2020-03-05  0:51       ` Heiko Stübner
2020-03-05 11:32         ` Ezequiel Garcia
2020-03-05 11:35           ` Ezequiel Garcia
2020-03-06  2:44             ` Kever Yang
2020-03-06 10:30               ` Ezequiel Garcia [this message]
2020-03-06 10:45     ` Geert Uytterhoeven
2020-03-26 13:50       ` Mylene Josserand
2020-03-26 15:31         ` Geert Uytterhoeven
2020-03-27  6:20           ` Mylene Josserand
2020-03-02 15:57 ` [PATCH 2/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand
2020-03-04  5:34   ` kbuild test robot

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=8f3ef079b0c96d65e5855a58efd6d8dc32cd32e7.camel@collabora.com \
    --to=ezequiel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=kernel@collabora.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=mylene.josserand@collabora.com \
    --cc=sboyd@kernel.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: link

Linux-Clk Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-clk/0 linux-clk/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-clk linux-clk/ https://lore.kernel.org/linux-clk \
		linux-clk@vger.kernel.org
	public-inbox-index linux-clk

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-clk


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git