[PATCH v3] Terasic DE0-Nano-SoC: add support

[Tim Sander]

On Monday 01 February 2016 19:31:53 Trent Piepho wrote:
> On Mon, 2016-02-01 at 15:07 +0100, Tim Sander wrote:
> 
> > v3: forgot to amend my changes in v2.
> > 
> > +
> > +static int socfpga_console_init(void)
> > +{
> > +       if (!of_machine_is_compatible("altr,socfpga-cyclone5"))
> > +               return 0;
> 
> 
> Seems like this should be a board specific check instead of a generic
> one, since it's programming board specific phy timing values to a board
> specific PHY.
I am not sure, but as outlined below i think this is also due to the 
compatible string of the coresponding dts within the linux kernel.
At least i first tried a more specific dts compatible string and that failed 
to boot.
> 
> > +
> > +       if (IS_ENABLED(CONFIG_PHYLIB))
> > +               phy_register_fixup_for_uid(PHY_ID_KSZ9021,
> > MICREL_PHY_ID_MASK, phy_fixup);
 +
> > +       return 0;
> > +}
> 
> 
> 
> > +
> > +static inline void ledon(int led)
> > +{
> > +       u32 val;
> > +
> > +       val = readl(0xFF709000);
> > +       val |= 1 << (led + 24);
> > +       writel(val, 0xFF709000);
> 
> 
> There a macro CYCLONE5_GPIO1_BASE that could be used instead of
> 0xFF709000.
> 
> 
> > +
> > +       val = readl(0xFF709004);
> > +       val |= 1 << (led + 24);
> > +       writel(val, 0xFF709004);
> > +}
> > +
> > +static inline void ledoff(int led)
> > +{
> > +       u32 val;
> > +
> > +       val = readl(0xFF709000);
> > +       val &= ~(1 << (led + 24));
> > +       writel(val, 0xFF709000);
> > +
> > +       val = readl(0xFF709004);
> > +       val &= ~(1 << (led + 24));
> > +       writel(val, 0xFF709004);
> > +}
> 
> 
> 
> 
> > +#include <arm/socfpga_cyclone5_de0_nano_soc.dts>
> > +#include "socfpga.dtsi"
> > +
> > +/ {
> > +       model = "Terasic DE0-Nano-SoC (Atlas)";
> > +       compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> 
> 
> Wouldn't the right thing to do here be to have a compatible entry for
> this board type?  Like the existing "terasic,sockit" or something more
> specific.
Well the problem at this point is that due to the boardspecs the compatible 
string has to be AFAIK the same as the one used in the linux kernel. 
Unfortunatly the coresponding dts file also has no more specific compatible 
string.

Best regards
Tim