[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