[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160729074800.44b8860cc0a3d2dfcdde32ce@free.fr>
Date: Fri, 29 Jul 2016 07:48:00 +0200
From: Jean-Francois Moine <moinejf@...e.fr>
To: Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc: Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
Mike Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...eaurora.org>,
devicetree@...r.kernel.org,
Andre Przywara <andre.przywara@....com>,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
On Thu, 28 Jul 2016 22:07:05 +0200
Maxime Ripard <maxime.ripard@...e-electrons.com> wrote:
> > > Let me know what you think,
> >
> > I don't see the interest to have common code for 32bits and 64bits.
> > The clock driver of a SoC will never evolve, so, it is simpler to
> > copy the source common with the H3 into a clean A64 clock driver.
>
> I'm not sure why 32 bits vs 64 bits matters here. We're going to share
> a significant number of drivers already between armv7 and armv8, like
> MMC, EMAC, I2C, and so on.
>
> And I expect to share the data in other SoCs for the A10, A13 and A20
> for example, or A23/A33, which have a lot of clocks in common too.
The interest of your sunxi-ng approach is that the clocks of each SoC
is described in one file. Here you are mixing 2 SoCs in the same source
file. The advantage is lost.
--
Ken ar c'hentaƱ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
Powered by blists - more mailing lists