[PATCH linux 2/4] drivers/fsi: FSI master initialization

Christopher Bostic christopher.lee.bostic at gmail.com
Thu Aug 4 05:02:18 AEST 2016


On Wed, Aug 3, 2016 at 1:07 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> On Wed, Aug 03, 2016 at 12:15:46PM -0500, Christopher Bostic wrote:
>> >> +struct primaster prim;
>> >
>> > Why are we statically allocating this? What happens if my system has
>> > two fsi masters in it?
>> >
>>
>> FSI hardware, as it exists presently, does not allow for more than one
>> master on a given bus.   There must be a first master in the chain to
>> initiate communications, here its called 'primary' master.   There can
>> be other masters downstream but that function is not planned for
>> addition to the core function.  That's an extended capability.
>>
>
> Typically designs are BMC -> P8 -- Cascade --> P8, but is there any
> reason why we cannot attach multiple P8s directly onto the BMC?  With
> SoftFSI you would just need to dedicate an extra set of GPIOs, so it
> seems very reasonable to do.  Thus, it would effectively create 2
> independent buses each with their own master.  Having a single variable
> doesn't allow this, does it?
>
> --
> Patrick Williams

Its all in how we decide to group the functionality.  Existing FSI
hardware on FSP-2 has a single primary master which can have 64 links.
  If we dedicate another set of GPIOs those would just be considered
another link on the existing single primary master - or so I had
assumed we would look at it.   Each FSI link being a SDA and clock
generic I/O line.   I don't see any advantages to having multiple
primary masters with a single link each but maybe there is and I'm
just not seeing it.  Let me know.

Regarding BMC -> P8 -- Cascade -> P8 that function will be in place
after core function is provided.  That topology has a primary FSI
master with a hub master chained downstream which wouldn't require
more than the single primary master as exists right now.


More information about the openbmc mailing list