Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Rob Herring]

On Thu, Jan 25, 2018 at 04:35:20PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> > 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > > > 
> > > > The same die is packaged differently, come with different co-packaged
> > > > DRAM or shipped with different SDK; and then made many model names: F23,
> > > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > > > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > > functionality hidden on the QFN88 models (except DRAM interface not
> > > > exported), it's not clever to differentiate them. So I will use suniv as
> > > > common name of all these SoCs.
> > > 
> > > Where is that suniv prefix coming from?
> > 
> > The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK 
> > and 
> > "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> 
> Do you have a link to that BSP?
> 
> > > You should really answer two questions here:
> > >   - Are you able to predict whether you'll find an SoC part of that
> > > family in the future that derives a bit and will need a compatible
> > > of its own?
> > >   - Are you able to predict which quirks we'll need along the way to
> > > support all the SoCs you've listed there?
> > > 
> > > If you can't answer yes to both these questions, with a 100%
> > > certainty, then you'll need a SoC name in the compatible.
> > > 
> > > Which doesn't prevent you from sharing as much as possible the DT like
> > > we did between the A10s and the A13 for example.
> > 
> > So the suniv-f1c100s.dtsi will still be kept empty and all peripherals 
> > known 
> > should go through suniv.dtsi.
> 
> Sorry if I wasn't really clear. You can totally keep the current DT
> structure if that makes sense (and judging by what you're saying, it
> does.), but the compatibles should have the SoC name in it.

In case it's not clear, the compatible strings and any new bindings need 
to be documented.

Rob

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Rob Herring]

On Thu, Jan 25, 2018 at 04:35:20PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> > 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > > > 
> > > > The same die is packaged differently, come with different co-packaged
> > > > DRAM or shipped with different SDK; and then made many model names: F23,
> > > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > > > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > > functionality hidden on the QFN88 models (except DRAM interface not
> > > > exported), it's not clever to differentiate them. So I will use suniv as
> > > > common name of all these SoCs.
> > > 
> > > Where is that suniv prefix coming from?
> > 
> > The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK 
> > and 
> > "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> 
> Do you have a link to that BSP?
> 
> > > You should really answer two questions here:
> > >   - Are you able to predict whether you'll find an SoC part of that
> > > family in the future that derives a bit and will need a compatible
> > > of its own?
> > >   - Are you able to predict which quirks we'll need along the way to
> > > support all the SoCs you've listed there?
> > > 
> > > If you can't answer yes to both these questions, with a 100%
> > > certainty, then you'll need a SoC name in the compatible.
> > > 
> > > Which doesn't prevent you from sharing as much as possible the DT like
> > > we did between the A10s and the A13 for example.
> > 
> > So the suniv-f1c100s.dtsi will still be kept empty and all peripherals 
> > known 
> > should go through suniv.dtsi.
> 
> Sorry if I wasn't really clear. You can totally keep the current DT
> structure if that makes sense (and judging by what you're saying, it
> does.), but the compatibles should have the SoC name in it.

In case it's not clear, the compatible strings and any new bindings need 
to be documented.

Rob

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

在 2018年1月25日星期四 CST 下午11:35:20，Maxime Ripard 写道：
> Hi,
> 
> On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> > 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > 
> > > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9
> > > > SoC.
> > > > 
> > > > The same die is packaged differently, come with different co-packaged
> > > > DRAM or shipped with different SDK; and then made many model names:
> > > > F23,
> > > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs
> > > > all
> > > > share a common feature set and are packaged similarly (eLQFP128 for
> > > > SoCs
> > > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > > functionality hidden on the QFN88 models (except DRAM interface not
> > > > exported), it's not clever to differentiate them. So I will use suniv
> > > > as
> > > > common name of all these SoCs.
> > > 
> > > Where is that suniv prefix coming from?
> > 
> > The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK
> > and "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> 
> Do you have a link to that BSP?

https://pan.baidu.com/s/1rar5YtI

There's Melis (F1C100s) and Linux (F1C600) BSP.

> 
> > > You should really answer two questions here:
> > >   - Are you able to predict whether you'll find an SoC part of that
> > >   
> > > family in the future that derives a bit and will need a compatible
> > > of its own?
> > >   
> > >   - Are you able to predict which quirks we'll need along the way to
> > >   
> > > support all the SoCs you've listed there?
> > > 
> > > If you can't answer yes to both these questions, with a 100%
> > > certainty, then you'll need a SoC name in the compatible.
> > > 
> > > Which doesn't prevent you from sharing as much as possible the DT like
> > > we did between the A10s and the A13 for example.
> > 
> > So the suniv-f1c100s.dtsi will still be kept empty and all peripherals
> > known should go through suniv.dtsi.
> 
> Sorry if I wasn't really clear. You can totally keep the current DT
> structure if that makes sense (and judging by what you're saying, it
> does.), but the compatibles should have the SoC name in it.
> 
> Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

在 2018年1月25日星期四 CST 下午11:35:20，Maxime Ripard 写道：
> Hi,
> 
> On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> > 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > 
> > > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9
> > > > SoC.
> > > > 
> > > > The same die is packaged differently, come with different co-packaged
> > > > DRAM or shipped with different SDK; and then made many model names:
> > > > F23,
> > > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs
> > > > all
> > > > share a common feature set and are packaged similarly (eLQFP128 for
> > > > SoCs
> > > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > > functionality hidden on the QFN88 models (except DRAM interface not
> > > > exported), it's not clever to differentiate them. So I will use suniv
> > > > as
> > > > common name of all these SoCs.
> > > 
> > > Where is that suniv prefix coming from?
> > 
> > The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK
> > and "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> 
> Do you have a link to that BSP?

https://pan.baidu.com/s/1rar5YtI

There's Melis (F1C100s) and Linux (F1C600) BSP.

> 
> > > You should really answer two questions here:
> > >   - Are you able to predict whether you'll find an SoC part of that
> > >   
> > > family in the future that derives a bit and will need a compatible
> > > of its own?
> > >   
> > >   - Are you able to predict which quirks we'll need along the way to
> > >   
> > > support all the SoCs you've listed there?
> > > 
> > > If you can't answer yes to both these questions, with a 100%
> > > certainty, then you'll need a SoC name in the compatible.
> > > 
> > > Which doesn't prevent you from sharing as much as possible the DT like
> > > we did between the A10s and the A13 for example.
> > 
> > So the suniv-f1c100s.dtsi will still be kept empty and all peripherals
> > known should go through suniv.dtsi.
> 
> Sorry if I wasn't really clear. You can totally keep the current DT
> structure if that makes sense (and judging by what you're saying, it
> does.), but the compatibles should have the SoC name in it.
> 
> Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

On Thu, Jan 25, 2018 at 11:38:04PM +0800, Icenowy Zheng wrote:
> >On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> >> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> >> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> >> > > This is the RFC initial patchset for the "new" Allwinner SUNIV
> >ARM9 SoC.
> >> > > 
> >> > > The same die is packaged differently, come with different
> >co-packaged
> >> > > DRAM or shipped with different SDK; and then made many model
> >names: F23,
> >> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These
> >SoCs all
> >> > > share a common feature set and are packaged similarly (eLQFP128
> >for SoCs
> >> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> >> > > functionality hidden on the QFN88 models (except DRAM interface
> >not
> >> > > exported), it's not clever to differentiate them. So I will use
> >suniv as
> >> > > common name of all these SoCs.
> >> > 
> >> > Where is that suniv prefix coming from?
> >> 
> >> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis
> >SDK and 
> >> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> >
> >Do you have a link to that BSP?
> 
> I have it on the Baidu Pan. Is it acceptable?

Yep, it's not crazy fast but it works :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

On Thu, Jan 25, 2018 at 11:38:04PM +0800, Icenowy Zheng wrote:
> >On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> >> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> >> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> >> > > This is the RFC initial patchset for the "new" Allwinner SUNIV
> >ARM9 SoC.
> >> > > 
> >> > > The same die is packaged differently, come with different
> >co-packaged
> >> > > DRAM or shipped with different SDK; and then made many model
> >names: F23,
> >> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These
> >SoCs all
> >> > > share a common feature set and are packaged similarly (eLQFP128
> >for SoCs
> >> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> >> > > functionality hidden on the QFN88 models (except DRAM interface
> >not
> >> > > exported), it's not clever to differentiate them. So I will use
> >suniv as
> >> > > common name of all these SoCs.
> >> > 
> >> > Where is that suniv prefix coming from?
> >> 
> >> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis
> >SDK and 
> >> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
> >
> >Do you have a link to that BSP?
> 
> I have it on the Baidu Pan. Is it acceptable?

Yep, it's not crazy fast but it works :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

于 2018年1月25日 GMT+08:00 下午11:35:20, Maxime Ripard 
 写到:
>Hi,
>
>On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
>> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
>> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
>> > > This is the RFC initial patchset for the "new" Allwinner SUNIV
>ARM9 SoC.
>> > > 
>> > > The same die is packaged differently, come with different
>co-packaged
>> > > DRAM or shipped with different SDK; and then made many model
>names: F23,
>> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These
>SoCs all
>> > > share a common feature set and are packaged similarly (eLQFP128
>for SoCs
>> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
>> > > functionality hidden on the QFN88 models (except DRAM interface
>not
>> > > exported), it's not clever to differentiate them. So I will use
>suniv as
>> > > common name of all these SoCs.
>> > 
>> > Where is that suniv prefix coming from?
>> 
>> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis
>SDK and 
>> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
>
>Do you have a link to that BSP?

I have it on the Baidu Pan. Is it acceptable?

>
>> > You should really answer two questions here:
>> >   - Are you able to predict whether you'll find an SoC part of that
>> > family in the future that derives a bit and will need a
>compatible
>> > of its own?
>> >   - Are you able to predict which quirks we'll need along the way
>to
>> > support all the SoCs you've listed there?
>> > 
>> > If you can't answer yes to both these questions, with a 100%
>> > certainty, then you'll need a SoC name in the compatible.
>> > 
>> > Which doesn't prevent you from sharing as much as possible the DT
>like
>> > we did between the A10s and the A13 for example.
>> 
>> So the suniv-f1c100s.dtsi will still be kept empty and all
>peripherals known 
>> should go through suniv.dtsi.
>
>Sorry if I wasn't really clear. You can totally keep the current DT
>structure if that makes sense (and judging by what you're saying, it
>does.), but the compatibles should have the SoC name in it.

Okay.

>
>Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

于 2018年1月25日 GMT+08:00 下午11:35:20, Maxime Ripard 
 写到:
>Hi,
>
>On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
>> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
>> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
>> > > This is the RFC initial patchset for the "new" Allwinner SUNIV
>ARM9 SoC.
>> > > 
>> > > The same die is packaged differently, come with different
>co-packaged
>> > > DRAM or shipped with different SDK; and then made many model
>names: F23,
>> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These
>SoCs all
>> > > share a common feature set and are packaged similarly (eLQFP128
>for SoCs
>> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
>> > > functionality hidden on the QFN88 models (except DRAM interface
>not
>> > > exported), it's not clever to differentiate them. So I will use
>suniv as
>> > > common name of all these SoCs.
>> > 
>> > Where is that suniv prefix coming from?
>> 
>> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis
>SDK and 
>> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)
>
>Do you have a link to that BSP?

I have it on the Baidu Pan. Is it acceptable?

>
>> > You should really answer two questions here:
>> >   - Are you able to predict whether you'll find an SoC part of that
>> > family in the future that derives a bit and will need a
>compatible
>> > of its own?
>> >   - Are you able to predict which quirks we'll need along the way
>to
>> > support all the SoCs you've listed there?
>> > 
>> > If you can't answer yes to both these questions, with a 100%
>> > certainty, then you'll need a SoC name in the compatible.
>> > 
>> > Which doesn't prevent you from sharing as much as possible the DT
>like
>> > we did between the A10s and the A13 for example.
>> 
>> So the suniv-f1c100s.dtsi will still be kept empty and all
>peripherals known 
>> should go through suniv.dtsi.
>
>Sorry if I wasn't really clear. You can totally keep the current DT
>structure if that makes sense (and judging by what you're saying, it
>does.), but the compatibles should have the SoC name in it.

Okay.

>
>Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

Hi,

On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > > 
> > > The same die is packaged differently, come with different co-packaged
> > > DRAM or shipped with different SDK; and then made many model names: F23,
> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > functionality hidden on the QFN88 models (except DRAM interface not
> > > exported), it's not clever to differentiate them. So I will use suniv as
> > > common name of all these SoCs.
> > 
> > Where is that suniv prefix coming from?
> 
> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK and 
> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)

Do you have a link to that BSP?

> > You should really answer two questions here:
> >   - Are you able to predict whether you'll find an SoC part of that
> > family in the future that derives a bit and will need a compatible
> > of its own?
> >   - Are you able to predict which quirks we'll need along the way to
> > support all the SoCs you've listed there?
> > 
> > If you can't answer yes to both these questions, with a 100%
> > certainty, then you'll need a SoC name in the compatible.
> > 
> > Which doesn't prevent you from sharing as much as possible the DT like
> > we did between the A10s and the A13 for example.
> 
> So the suniv-f1c100s.dtsi will still be kept empty and all peripherals known 
> should go through suniv.dtsi.

Sorry if I wasn't really clear. You can totally keep the current DT
structure if that makes sense (and judging by what you're saying, it
does.), but the compatibles should have the SoC name in it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

Hi,

On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> 在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > > 
> > > The same die is packaged differently, come with different co-packaged
> > > DRAM or shipped with different SDK; and then made many model names: F23,
> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > functionality hidden on the QFN88 models (except DRAM interface not
> > > exported), it's not clever to differentiate them. So I will use suniv as
> > > common name of all these SoCs.
> > 
> > Where is that suniv prefix coming from?
> 
> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK and 
> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)

Do you have a link to that BSP?

> > You should really answer two questions here:
> >   - Are you able to predict whether you'll find an SoC part of that
> > family in the future that derives a bit and will need a compatible
> > of its own?
> >   - Are you able to predict which quirks we'll need along the way to
> > support all the SoCs you've listed there?
> > 
> > If you can't answer yes to both these questions, with a 100%
> > certainty, then you'll need a SoC name in the compatible.
> > 
> > Which doesn't prevent you from sharing as much as possible the DT like
> > we did between the A10s and the A13 for example.
> 
> So the suniv-f1c100s.dtsi will still be kept empty and all peripherals known 
> should go through suniv.dtsi.

Sorry if I wasn't really clear. You can totally keep the current DT
structure if that makes sense (and judging by what you're saying, it
does.), but the compatibles should have the SoC name in it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > 
> > The same die is packaged differently, come with different co-packaged
> > DRAM or shipped with different SDK; and then made many model names: F23,
> > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > functionality hidden on the QFN88 models (except DRAM interface not
> > exported), it's not clever to differentiate them. So I will use suniv as
> > common name of all these SoCs.
> 
> Where is that suniv prefix coming from?

The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK and 
"arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)

> 
> And you need to have a SoC in all your compatibles. This isn't about
> being clever or not, this is just a matter of being able to accurately
> read in a crystal ball. Or maybe it's just the same, in which case,
> I'd really like to have a course :)

Okay. I will choose to use f1c100s in my next patchset, as it's where
it's developed. (Although I mainly refered F1C600 BSP and document)

> 
> You should really answer two questions here:
>   - Are you able to predict whether you'll find an SoC part of that
> family in the future that derives a bit and will need a compatible
> of its own?
>   - Are you able to predict which quirks we'll need along the way to
> support all the SoCs you've listed there?
> 
> If you can't answer yes to both these questions, with a 100%
> certainty, then you'll need a SoC name in the compatible.
> 
> Which doesn't prevent you from sharing as much as possible the DT like
> we did between the A10s and the A13 for example.

So the suniv-f1c100s.dtsi will still be kept empty and all peripherals known 
should go through suniv.dtsi.

> 
> Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

在 2018年1月22日星期一 CST 下午8:14:35，Maxime Ripard 写道：
> On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > 
> > The same die is packaged differently, come with different co-packaged
> > DRAM or shipped with different SDK; and then made many model names: F23,
> > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > functionality hidden on the QFN88 models (except DRAM interface not
> > exported), it's not clever to differentiate them. So I will use suniv as
> > common name of all these SoCs.
> 
> Where is that suniv prefix coming from?

The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK and 
"arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)

> 
> And you need to have a SoC in all your compatibles. This isn't about
> being clever or not, this is just a matter of being able to accurately
> read in a crystal ball. Or maybe it's just the same, in which case,
> I'd really like to have a course :)

Okay. I will choose to use f1c100s in my next patchset, as it's where
it's developed. (Although I mainly refered F1C600 BSP and document)

> 
> You should really answer two questions here:
>   - Are you able to predict whether you'll find an SoC part of that
> family in the future that derives a bit and will need a compatible
> of its own?
>   - Are you able to predict which quirks we'll need along the way to
> support all the SoCs you've listed there?
> 
> If you can't answer yes to both these questions, with a 100%
> certainty, then you'll need a SoC name in the compatible.
> 
> Which doesn't prevent you from sharing as much as possible the DT like
> we did between the A10s and the A13 for example.

So the suniv-f1c100s.dtsi will still be kept empty and all peripherals known 
should go through suniv.dtsi.

> 
> Maxime

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> 
> The same die is packaged differently, come with different co-packaged
> DRAM or shipped with different SDK; and then made many model names: F23,
> F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> share a common feature set and are packaged similarly (eLQFP128 for SoCs
> without co-packaged DRAM, QFN88 for with DRAM). As their's no
> functionality hidden on the QFN88 models (except DRAM interface not
> exported), it's not clever to differentiate them. So I will use suniv as
> common name of all these SoCs.

Where is that suniv prefix coming from?

And you need to have a SoC in all your compatibles. This isn't about
being clever or not, this is just a matter of being able to accurately
read in a crystal ball. Or maybe it's just the same, in which case,
I'd really like to have a course :)

You should really answer two questions here:
  - Are you able to predict whether you'll find an SoC part of that
family in the future that derives a bit and will need a compatible
of its own?
  - Are you able to predict which quirks we'll need along the way to
support all the SoCs you've listed there?

If you can't answer yes to both these questions, with a 100%
certainty, then you'll need a SoC name in the compatible.

Which doesn't prevent you from sharing as much as possible the DT like
we did between the A10s and the A13 for example.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Maxime Ripard]

On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> 
> The same die is packaged differently, come with different co-packaged
> DRAM or shipped with different SDK; and then made many model names: F23,
> F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> share a common feature set and are packaged similarly (eLQFP128 for SoCs
> without co-packaged DRAM, QFN88 for with DRAM). As their's no
> functionality hidden on the QFN88 models (except DRAM interface not
> exported), it's not clever to differentiate them. So I will use suniv as
> common name of all these SoCs.

Where is that suniv prefix coming from?

And you need to have a SoC in all your compatibles. This isn't about
being clever or not, this is just a matter of being able to accurately
read in a crystal ball. Or maybe it's just the same, in which case,
I'd really like to have a course :)

You should really answer two questions here:
  - Are you able to predict whether you'll find an SoC part of that
family in the future that derives a bit and will need a compatible
of its own?
  - Are you able to predict which quirks we'll need along the way to
support all the SoCs you've listed there?

If you can't answer yes to both these questions, with a 100%
certainty, then you'll need a SoC name in the compatible.

Which doesn't prevent you from sharing as much as possible the DT like
we did between the A10s and the A13 for example.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.

The same die is packaged differently, come with different co-packaged
DRAM or shipped with different SDK; and then made many model names: F23,
F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
share a common feature set and are packaged similarly (eLQFP128 for SoCs
without co-packaged DRAM, QFN88 for with DRAM). As their's no
functionality hidden on the QFN88 models (except DRAM interface not
exported), it's not clever to differentiate them. So I will use suniv as
common name of all these SoCs.

As it's the first not ARMv7+ Allwinner SoC to get supported, this
patchset firstly made CONFIG_ARCH_SUNXI a common config item, and let
selectable CONFIG_ARCH_SUNXI_V{5,7} to internally select it. This makes
reusing most work possible. This is PATCH 1~2.

The ARM9 has neither GIC nor arch_timer, like the sun4i/5i Cortex-A8
SoCs. So adapt the IRQ and timer driver used by sun4i/5i to support
suniv. This is PATCH 3~5.

Then it's the common way to support a new SoC -- pinctrl, CCU and
initial DT.

Icenowy Zheng (9):
  ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner
SoCs
  ARM: sunxi: add Allwinner ARMv5 SoCs
  irqchip/sun4i: add support for suniv interrupt controller
  clocksource: sun4i: add a compatible for suniv
  clocksource/drivers/sun4i: register as sched_clock on suniv
  pinctrl: sunxi: add support for suniv (newer F-series SoCs)
  clk: sunxi-ng: add support for suniv SoC
  ARM: dts: suniv: add initial DTSI file for suniv and F1C100s
  ARM: suniv: f1c100s: add device tree for Lichee Pi Nano

 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts |  27 ++
 arch/arm/boot/dts/suniv-f1c100s.dtsi  |   6 +
 arch/arm/boot/dts/suniv.dtsi  | 157 +++
 arch/arm/configs/multi_v7_defconfig   |   2 +-
 arch/arm/configs/sunxi_defconfig  |   2 +-
 arch/arm/mach-sunxi/Kconfig   |  27 +-
 arch/arm/mach-sunxi/Makefile  |   3 +-
 arch/arm/mach-sunxi/sunxi_v5.c|  22 +
 drivers/clk/sunxi-ng/Kconfig  |   5 +
 drivers/clk/sunxi-ng/Makefile |   1 +
 drivers/clk/sunxi-ng/ccu-suniv.c  | 536 ++
 drivers/clk/sunxi-ng/ccu-suniv.h  |  34 ++
 drivers/clocksource/sun4i_timer.c |   5 +-
 drivers/irqchip/irq-sun4i.c   |  43 +-
 drivers/pinctrl/sunxi/Kconfig |   4 +
 drivers/pinctrl/sunxi/Makefile|   1 +
 drivers/pinctrl/sunxi/pinctrl-suniv.c | 417 +
 include/dt-bindings/clock/suniv-ccu.h |  69 +++
 include/dt-bindings/reset/suniv-ccu.h |  37 ++
 20 files changed, 1389 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
 create mode 100644 arch/arm/boot/dts/suniv-f1c100s.dtsi
 create mode 100644 arch/arm/boot/dts/suniv.dtsi
 create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-suniv.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-suniv.h
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-suniv.c
 create mode 100644 include/dt-bindings/clock/suniv-ccu.h
 create mode 100644 include/dt-bindings/reset/suniv-ccu.h

-- 
2.14.2

[RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9 SoC

[Icenowy Zheng]

This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.

The same die is packaged differently, come with different co-packaged
DRAM or shipped with different SDK; and then made many model names: F23,
F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
share a common feature set and are packaged similarly (eLQFP128 for SoCs
without co-packaged DRAM, QFN88 for with DRAM). As their's no
functionality hidden on the QFN88 models (except DRAM interface not
exported), it's not clever to differentiate them. So I will use suniv as
common name of all these SoCs.

As it's the first not ARMv7+ Allwinner SoC to get supported, this
patchset firstly made CONFIG_ARCH_SUNXI a common config item, and let
selectable CONFIG_ARCH_SUNXI_V{5,7} to internally select it. This makes
reusing most work possible. This is PATCH 1~2.

The ARM9 has neither GIC nor arch_timer, like the sun4i/5i Cortex-A8
SoCs. So adapt the IRQ and timer driver used by sun4i/5i to support
suniv. This is PATCH 3~5.

Then it's the common way to support a new SoC -- pinctrl, CCU and
initial DT.

Icenowy Zheng (9):
  ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner
SoCs
  ARM: sunxi: add Allwinner ARMv5 SoCs
  irqchip/sun4i: add support for suniv interrupt controller
  clocksource: sun4i: add a compatible for suniv
  clocksource/drivers/sun4i: register as sched_clock on suniv
  pinctrl: sunxi: add support for suniv (newer F-series SoCs)
  clk: sunxi-ng: add support for suniv SoC
  ARM: dts: suniv: add initial DTSI file for suniv and F1C100s
  ARM: suniv: f1c100s: add device tree for Lichee Pi Nano

 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts |  27 ++
 arch/arm/boot/dts/suniv-f1c100s.dtsi  |   6 +
 arch/arm/boot/dts/suniv.dtsi  | 157 +++
 arch/arm/configs/multi_v7_defconfig   |   2 +-
 arch/arm/configs/sunxi_defconfig  |   2 +-
 arch/arm/mach-sunxi/Kconfig   |  27 +-
 arch/arm/mach-sunxi/Makefile  |   3 +-
 arch/arm/mach-sunxi/sunxi_v5.c|  22 +
 drivers/clk/sunxi-ng/Kconfig  |   5 +
 drivers/clk/sunxi-ng/Makefile |   1 +
 drivers/clk/sunxi-ng/ccu-suniv.c  | 536 ++
 drivers/clk/sunxi-ng/ccu-suniv.h  |  34 ++
 drivers/clocksource/sun4i_timer.c |   5 +-
 drivers/irqchip/irq-sun4i.c   |  43 +-
 drivers/pinctrl/sunxi/Kconfig |   4 +
 drivers/pinctrl/sunxi/Makefile|   1 +
 drivers/pinctrl/sunxi/pinctrl-suniv.c | 417 +
 include/dt-bindings/clock/suniv-ccu.h |  69 +++
 include/dt-bindings/reset/suniv-ccu.h |  37 ++
 20 files changed, 1389 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
 create mode 100644 arch/arm/boot/dts/suniv-f1c100s.dtsi
 create mode 100644 arch/arm/boot/dts/suniv.dtsi
 create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-suniv.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-suniv.h
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-suniv.c
 create mode 100644 include/dt-bindings/clock/suniv-ccu.h
 create mode 100644 include/dt-bindings/reset/suniv-ccu.h

-- 
2.14.2