[Cbe-oss-dev] Cell internal registers access

[Benjamin Herrenschmidt]

> The problem is that we don't know which of the functional units will
> show up in future CPUs, so it would be good not to rely on the
> same set to be present as on Cell BE.

That's not a problem. My idea was to expose each unit separately as you
have seen, and thus if a given unit is not present, the function can
just return NULL. If there are variations in the future on the type of
units and stuff, we could locate the code for dealing with some of this
in that file.

> If that scheme doesn't work out for the FIR, we might need to come
> up with something different, as you said. Do you already know which
> areas you need to touch?

Well, for the FIRs there is pretty much at least one in every unit. 

> I already learned that for the oprofile code, we will need to
> make significant changes to the the way that the IIC (interrupt.c)
> handling works, since that needs to be acknowledged in per-chip
> registers and is using external exception with some special bits
> set instead of the 0xf00 performance monitor exception.

Dodgy... I'll have to have a look at that too anyway.

 .../...

> > In fact, I'm tempted to also provide lower level BE<->thread mapping
> > routines in there for the few cases that might be interested.
> 
> Yes, that is probably the best we can do. For the interrupt stuff
> in particular, we have so far only used the per-SMT-thread data
> (source, prio and generation), so it was an actual mapping between
> smp_processor_id() and iomem area, which will not really fit
> in your approach.

It could too. Some areas are per thread some are per BE. I think this
"module" should build internally the list of BE's and threads and have
the logic to know what unit is shared at what level. I'm still thinking
about some of the details there. I suppose I'll come up with something
tomorrow and we can discuss from there.

> The advantage of ibm,interrupt-server#s is that it is the only one that
> is really mentioned in OpenPAPR or any of the referenced documents.

Yup.

> Well, the problem is that we still don't have a conclusion what an
> identifier for one 'cell be' should be in general. I still think
> it should be a platform independant concept of a node with (potentially)
> more than once processors, and SOC bus and at the same time not
> need to be a NUMA node on its own.

I wouldn't go too far right now in generalising things. Let's do
something that works for us and then maybe see if it's worth
generalising. Note that I don't see why it couldn't be a numa node of
it's own ...

Ben