[Skiboot] [PATCH] Add in new OPAL call to flush the L2 and L3 caches.
npiggin at gmail.com
Wed Nov 14 21:13:41 AEDT 2018
On Wed, 14 Nov 2018 18:16:10 +1100
Alistair Popple <alistair at popple.id.au> wrote:
> > >> I'd say it should be fairly straightforward to do the purge in the
> > >> npu2 creset(). If the current NPU driver in linux expects to get
> > >> OPAL_SUCCESS when it does an NPU reset you might be screwed though.
> > >
> > > We don't do anything special here in Linux for the NPU so I'd assume it
> > > would work as well as it does for everything else. Alexey you were
> > > hooking up these resets for pass-through do you know if returning
> > > OPAL_PCI_POLL would work in your call paths?
> > GPUs are reset from pnv_pci_reset_secondary_bus()+pnv_eeh_bridge_reset()
> > which does wait for opal_pci_poll(); in skiboot it is phb4_hreset() and
> > this could be the place for the cache purge thingy but I cannot easily
> > figure out this state machine in skiboot :-/
> Nobody can :-)
> Anyway it looks like that deals with a return code of OPAL_PCI_POLL so we
> should be ok to do the cache purge as part of the reset. I guess knowing this
> I don't feel too strongly either way with respect to implementing this as a
> standalone opal call vs. part of the GPU reset sequence. Alexey/Nick did
> either of you have a preference?
I would like to do it as part of the reset for this case, if
that doesn't cause anybody a whole lot more work.
I think having facility to flush caches and various other hardware
knobs is neat in its own right for testing and possibly debugging
or even workarounds. So I wouldn't say no to these types of OPAL
calls, but I feel like as a GPU memory coherency correctness step,
it fits in the GPU reset.
As the person not writing any code or using the APIs, I'm happy for
Rashmica and others to decide though :)
More information about the Skiboot