Re: [PATCH] RFC: fmc: Try to convert to GPIO descriptors

["Enrico Weigelt, metux IT consult" <lkml@xxxxxxxxx>]

On 06.06.19 16:41, Federico Vaga wrote:

Hi,

>> * am I'm correctly assuming that there can be different FMCs, which in
>>   turn can be deployed with different application specific bitfiles ?
> 
> yes

Ok, then - from LDM point of view - I'd prefer treating the FMC as kind
of an bus adapter. That "bus" would also employ fpga subsystem for the
bitfile deployment (maybe, pure fw-loader would also do ?) and then let
it do the logical probing. Sounds a bit cleaner to me than the mfd
approach.

> SDB is something that has been attached to FMC but actually is totally 
> unrelated. There were plans about it in the past but they have been abandon.

So, we can ignore it ?

> There are no relations between GPIO and FMC. GPIO usage is design specific, 
> and in particular specific to the carrier not the modules.

Now I'm confused. If the gpio's are design specific, means they're
implemented inside fpga ? But how exactly are they carrier specific ?
(by "carrier" you mean the adapter to pcie or vme ?)

>> * chardev: is some kinda /dev/mem for the fmc devices ?
>>   is it used by applications or just development ?
> 
> probably development. At least at CERN nobody uses it; it has been used to 
> hack around at the very beginning

So, not part of the uapi ? (IOW: could we drop it, w/o causing huge
pain ?)

>> * eeprom: should we introduce an actual eeprom device class ?
>>   several years ago, somebody was working on that, but don't know
>>   what happended it it:
>>   https://lore.kernel.org/patchwork/patch/436179/
> 
> I do not think is necessary. The kernel has support for I2C, it has support to 
> the FMC standard EEPROM. They are easy to configure

How does the fmc subsystem talk to these drivers ? Just had a quick look
on a few of them - these just provide access via sysfs, but haven't
found an internal API, where other drivers/subsystems talk to them
directly. Is that all done in userland ?

>> 'https://ohwr.org/project/fpga-config-space.git/': gnutls_handshake()
>> failed: Handshake failed
> 
> I can report the error, but as you can see that project is abandon. 

hmm, now only used internally ?

>> I guess the connection to the host is very FMC specific. Which
>> IO operations can we do here ? Just register read/write ?
> 
> It is not FMC specific. FMC is just a connector that you can use to extend a 
> PCI/VME/USB/ISA/SPI/... card

But there're different types (depending on which bus they're plugged
into), and these parts have to be type specific ?

> In principle there is only one correct EEPROM: 24C02. Any other eeprom is non-
> standard, so the operator must know what to do in that specific case.

Ok. From where is the eeprom accessed ? Userland or kernel ?

>> Not sure whether I really understood the whole, so I'll try to
>> summarize - correct me if I'm wrong:
>>
>> * each FMC carries an i2c eeprom with the SDB data, and potentially
>>   extra payload specific data (eg. sdbfs)
> 
> No.
> FMc Modules (plugged on FMC carriers) carry an I2C EEPROM with the "Platform
> Management FRU Information Storage Definition V1.0."

Ah, okay, so no sdb data.

>> * there may be different eeprom types (speaking different protocols)
> 
> According to the standard no. But since the standard is unclear, people 
> misunderstood this point, so it is possible to have different eeproms

Okay, so we practically have different types (even if that violates
the spec). Does that have to be supported ?

>> * this i2c eeprom is connected to an i2c controller on the carrier
> 
> Yes

So, the carrier forms an MFD which holds an bus adapter as well as
an i2c controller. I guess the fmc subsystem needs to parse/handle
the eeprom data (for probing, etc), correct ?

IMHO, the fmc carrier driver should instanciate an i2c controller
and an eeprom behind that. As an intermediate step, I'd imagine changing
the built in i2c functions to call into the standard i2c subsystem.

>> Are this standard i2c controllers that are already supported by the
>> i2c subsystem ?
> 
> There is not a standard I2C controller. It is a carrier design choice

Are some of them compatible w/ any already supported i2c controller ?

>> My question is whether the FMCs, besides the current bitfile in FPGA,
>> differ from host point of view. IOW: does the host need to care about
>> the actual FMC type, before we have an actual bitfile loaded ?
>> (maybe fpga specific upload protocols or check whether bitfile fits
>> that FMC ?)
> 
> It depends on the context. If your FPGA is empty and you want to load a new 
> configuration then you should check the type of FMC Module plugged in order to 
> avoid to "burn" it (really rare, but it could happen)

Understood. Is this already done automatically, or manually by the
operator ?

>>> Could be DeviceTree, ACPI descriptors, or another driver. There are plenty
>>> of possibilities. I have noticed that DeviceTree is extensively used in
>>> some context.
>>
>> So, this part isn't defined yet ?
> 
> It does not need to be defined. It is out of scope. How FPGA devices are 
> declare is a general problem, not and FMC problem

But somebody needs to start the probing process (however this actually
looks like) - finally needs not instanciate the platform devices with
the correct configuration. Does  subsystem already has some mechanisms
for that ?

>> How is that currrently handled ?
> 
> The way fmc-bus is designed, does not need to discover FPGA devices.

How then does the discovery ? Or is that purely application specific
and entirely handled in userspace ?

>> Could you put a dtb directly in the FPGA, at some defined address ?
> 
> In general yes. Why not?

Ok, than that's probably the way I would go.
Not sure whether we already have standard mechanisms for that.

> Well, I am suggesting to erase fmc-bus from the Linux kernel and to provide a 
> device_class for a standardized way to access that I2C EEPROM. I already have 
> the implementation; perhaps it needs some clean-up and for sure to be ported 
> to 5.x (I will do this job only if there is interest in removing/replacing the 
> current fmc subsystem).

Can you post what you've already got ?
I'd like to have a closer look at it.

Maybe it has some overlap w/ pstore or firmware flashing.

>> Do you happen to have some remote-accesible testbed for playground ?
> 
> Of course not :D
> CERN infrastructure is not freely accessible

How sad :(

I believe CERN could be one of the top candidates for setting up such
environments - not for this case, but also other Linux-supported
hardware. Do you happen to know some people there, with whom we could
have a talk about that ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287