mach header files

[Arnd Bergmann]

On Friday 04 April 2014 15:42:37 Phil Edworthy wrote:
> 
> On 04 April 2014 16:31, Arnd wrote:
> > On Friday 04 April 2014 13:52:53 Phil Edworthy wrote:
> > > On 04 April 2014 14:24, Arnd wrote:
> > > > We still make the occasional exception for adding code in the mach-*
> > > > directory, but we are getting pretty close to the state where this
> > > > is not needed for new platforms, and all the existing uses are for
> > > > things that can eventually get cleaned up.
> > > > If you think you need an exception here, please explain what you
> > > > are doing, and we can see if there is a better way to do that already.
> > >
> > > Ok, that's what I suspected about the mach header files.
> > >
> > > I didn't realise about the expectation that there is no
> > > arch/arm/mach-* for new platforms. At the moment I have only a
> > > small amount of platform code:
> > > 1. SMP holding pen code (as there is no power control for the second
> > > core), though I have recently seen patches to provide a generic solution
> > > for this.
> > 
> > Proper platforms should not be using the holding pen, that is only
> > done on systems that don't have real hardware support for CPU
> > power management. Ideally you should be implementing PSCI in the
> > firmware, and then you won't need any code for SMP.
> > 
> > > 2. Firmware calls (via struct firmware_ops) for set_cpu_boot_addr
> > >  and cpu_boot. This falls back to directly accessing registers in
> > > the system control block, if the firmware fails. This is useful when
> > > developing the system when no firmware exists yet.
> > 
> > Same thing.
> Ok, something to look into. How the hardware will work is complicated
> by the fact that we don't have silicon for this device yet, just a
> simulator.  As for the firmware, I am not sure I will see that. Our
> customer is implementing it and responsible for creating the firmware 
> calls from Linux, hence the fall backs.

In that case, I would recommend that you just rely on PSCI in the
kernel and leave it up to your customer to either implement that
in their firmware, or provide kernel support for the interfaces
they want. If they have a good reason to need a different interface,
they can also send patches for that and argue for inclusion, but
that is not part of the base platform support you do.
 
> > > 3. A write to a system control register to switch the pl011 uart
> > > from DMA single requests, to DMA burst requests.
> > 
> > Do you need to do this at run-time, or is it something that could
> > be done in the bootloader before Linux starts up?
>
> I might be able to get it into the boot loader, but this is
> implemented by the customer. One question is whether it should
> be in the boot loader. The behaviour is specify to the Linux port,
> whereas the boot loader can be used for a number of different OS.

What is the impact for single-request vs burst request? Is it just
performance? You can add a DT property in the pl011 node to let
the device driver know which of the two modes was set up by the
boot loader, and implement both in the driver. Then anybody who
wants burst mode can set it in the boot loader and every OS will
be able to find out the mode from DT.

	Arnd