[PATCH linux 14/15] drivers/fsi: Rename slave to cfam
Christopher Bostic
christopher.lee.bostic at gmail.com
Fri Oct 7 05:50:55 AEDT 2016
On Thu, Oct 6, 2016 at 1:58 AM, Jeremy Kerr <jk at ozlabs.org> wrote:
> Hi Chris,
>
>> Suggested changes to the patch set so far as provided by Jeremy Kerr.
>> Rename slave to cfam to distinguish between the slave engine and its
>> containing cfam.
>
> I'm still not 100% on that. As is my understanding, a (hardware) CFAM
> contains multiple slaves, and that not what `struct fsi_slave`
> represents (it's a single slave).
One other thing that would make a cfam struct that is separate from the
slave engine useful is the fact that there are several different hardware
quirks for which the only way for firmware to know what to do is to check
the cfam type.
P8, P9, zNEW cfam types
* Controlling master's MATRB bit encoding is different versus other cfams.
This is not a function of the master type, only cfam type.
I'd propose something like:
uint32_t cfam->decode_matrb(master->matrb) possibly.
* Any master that has cascaded masters downstream must set its
MSIEP registers differently than if there was no cascaded master.
This is to work around a known hardware bug in interrupt signaling.
The only way to determine this is to see if downstream cfam is a type
that has a cascaded master. Again independent of a controlling
master's type.
bool cfam->has_cascaded_master(master->cfam);
Several cfam engine device drivers have to work around known
hardware bugs on specific hardware. There are cases where
the same hardware engine (id and version same) behaves differently
on two different cfam types:
* IOU mailbox engine has same engine id, version number but
has different behavior on a CFAM-S type versus an IOU type.
This would require some form of fsi client query of cfam type
or initialization of some op.
* The P9 iic boe engine did not have its version ID incremented
from P8 even though there are differences in the command
register set. There is no way for the iic driver to know which
engine its on unless it knows the cfam type.
The IMD iic engine with the same engine ID and version will
have differences in iic clocks due to differences in cfam
type. The iic bus clock is derived from the parent fsi master
clock which is divided down differently on different cfam types.
In order for iic driver to know what frequency its buses are
operating at has to know the cfam type.
>
>
> Jeremy
More information about the openbmc
mailing list