[dev-4.7 patch 5/5] arch/arm: introduce support for Mallanox evb aspeed 2500 config and dts flavors

[Vadim Pasternak]

> -----Original Message-----
> From: joel.stan at gmail.com [mailto:joel.stan at gmail.com] On Behalf Of Joel
> Stanley
> Sent: Wednesday, August 17, 2016 8:49 AM
> To: Vadim Pasternak <vadimp at mellanox.com>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Jiri Pirko
> <jiri at mellanox.com>; Michael Shych <michaelsh at mellanox.com>
> Subject: Re: [dev-4.7 patch 5/5] arch/arm: introduce support for Mallanox evb
> aspeed 2500 config and dts flavors
> 
> On Wed, Aug 17, 2016 at 3:01 PM, Vadim Pasternak <vadimp at mellanox.com>
> wrote:
> >> > diff --git a/arch/arm/boot/dts/aspeed-g5-mlx.dtsi
> >> > b/arch/arm/boot/dts/aspeed-g5-mlx.dtsi
> >> > new file mode 100644
> >> > index 0000000..0f4cce9
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/aspeed-g5-mlx.dtsi
> >> > @@ -0,0 +1,429 @@
> >> > +#include "skeleton.dtsi"
> >> > +
> >> > +/ {
> >> > +       model = "Aspeed BMC";
> >> > +       compatible = "aspeed,ast2500";
> >> > +       #address-cells = <1>;
> >> > +       #size-cells = <1>;
> >> > +       interrupt-parent = <&vic>;
> >> > +
> >>
> >> This looks to be a copy of the existing aspeed-g5.dtsi. You should
> >> include that in your .dts file instead of duplicating it.
> >
> > We have in this file peci, jtag, pwm and we are adding now usb.
> 
> You can add these devices to the aspeed-g5.dtsi and set them to disabled so the
> other systems ignore the extra devices.
> 
> You can then set them to enabled with status = "okay" in your .dts as you have
> done with i2c, etc.
> 
> > We also wanted to change interrupt level sensitivity to LEVEL_HIGH.
> > Currently, using aspeed-g5 we are getting all interrupts  as edge. According to
> datasheet most should be level. Possibly this is a reason of I2C failure (which we
> experienced also with 4.7).
> 
> IIRC the irq driver doesn't have support for specifying the interrupt as edge or
> level. This is an enhancement that needs to be made to the driver before you
> can specify it in the device tree.
> 
> >> > diff --git a/arch/arm/configs/mlx_bmc_defconfig
> >> > b/arch/arm/configs/mlx_bmc_defconfig
> >> > new file mode 100644
> >> > index 0000000..b381dc5
> >> > --- /dev/null
> >> > +++ b/arch/arm/configs/mlx_bmc_defconfig
> >>
> >> Upstream do not like adding many defconfigs. We have one for the
> >> ast2500 and one for the ast2400 series. I suggest adding options to
> >> the aspeed_g5_defconfig.
> >
> > We have a big gap between aspeed_g5_defconfig and our flavor of that (LED,
> SWITCHDEV). Also we would like to get rid of using JFFS2 and move to UBI.
> > Would it be possible to add all that to aspeed_g5_defconfig?
> 
> There are two ways you can configure the kernel. One is to have the defconfig in
> the kernel tree that is a superset of the requirements for all systems.
> 
> The other is to have a kernel configuration specific to your board in the yocto
> tree. This option allows everyone to build a smaller kernel that meets the needs
> of their BMC. This is the option that the existing boards currently support.
> 
> No matter which option you chose, I suggest sending a patch to
> aspeed_g5_defconfig that enables all of the the functionality you use.
> This way I can test that it builds correctly when modifying the kernel.
> 
> > By the way, I see that in 4.7 upstream you already added some minimal stuff
> for Aspeed SoC.
> > Do you have some plan regarding upstream other stuff to kernel?
> 
> Yes. I intend to merge all of the drivers upstream.
> 
> > When you think it could happen?
> 
> We have watchdog and irq controller in 4.8.
> 
> 4.9 will have clocksource, gpio and pinmux.
> 
> Brendan is working on i2c which I hope will be ready in time for inclusion in 4.9.
> 
> We also have bt, clock, mtd and vuart drivers that need review and submission. I
> hope to get as many as possible into 4.9.
> 
> > And are you going to submit upstream all Aspeed files together or you are
> planning to do it in some particular order?
> 
> As each of the drivers are going to different maintainers, they do not have any
> dependency on each other. They can go up when they are ready.
> 

Great,
Thank you very much for your detailed answers.
I'll re-work the patches according to your comment and re-submit them.

As I understand you don't need peci, jtag, pwm, usb at the moment.
Could we submit these module for upstream review after your approval by ourselves?

What about RTC and SPI stuff?

> Cheers,
> 
> Joel

Cheers,
Vadim.