> It would be convenient if you could teach your mailer to attach these as
> text/plain or text/x-patch.
I can try not using Gmail.
> but the hal function mesa_7i65 does both reading and writing in one go.
I did originally start with two functions and then combined them.
However, I think there is a problem that SPI devices can't be read
without writing to them, and the Hostmot2 "Read" cycle simply reads
the values in all the registers it has been told to. An SPI read (as I
understand it) is clocked through on the "write" data strobe.
I am not at all expert on SPI though, and might be wrong.
It would be possible, I assume, to add a third "echo" tram
registration type to Hostmot2, which might be the only way to make
this work.
(Currently Hostmot2 has a bunch of variables mapped to contiguous
memory that are written out to their allocated Mesa card registers in
a lump, and a second set which read back the same way.
The Mesa firmware has a tranlation RAM also contiguous in register
space which remaps to individual function registers. The idea is that
this removes half the overhead in parallel and PCI writes because no
register address data needs to be sent. )
> The implementation I'd imagined involved mesa_7i65 and other bspi
> drivers defining *NO* hal functions. Instead, they would register
> function pointers with the hostmot2 driver to call at the appropriate
> times (when processing a read or preparing a write). This would
> require a modification to comp, which currently always rejects a
> component with no functions.
Does it also need to allow function pointers in comp, which I
accidentally might have introduced and you took out again?
Interesting idea. I can see how it might work. Let me ponder it and
see if it works better.
> It seems like this should be 'return r;' at the end, or maybe 'return
> -1' in the 'if', so that the caller can determine that a failure has
> occurred.
Yes, I will fix that.
> The return value from EXTRA_SETUP should be a negative errno value like
> -EINVAL. This value will ultimately be used to look up the error
> message to display from insmod. As written, 1 error will be reported as
> 'Operation not permitted' and 2 errors as 'No such file or directory',
OK, that's clearly silly, and I will fix it.
> Avoid unnecessary whitespace changes.
The hard part is working out what whitespace to put back in to fix it :-)
(I assume --whitespace, reset then git-am is the way to go.)
>> + HM2_DBG("Parameter = %s\n", token);
> Not sure whether this should be included or whether it was just a
> debugging thing that could just be dropped.
I tend to use HM2_PRINT for debugging, as it saves messing about with
rtapi_set_msg_level. This was deliberate so that comp writers get to
see what config data is being written, and if it matches the samples
in the datasheets. There are lots of other, similar statements
scattered throughout Hm2 and they are useful. That one probably needs
to be a little more descriptive though.
> It's great to have documentation to go with the code. I would
> personally split this part into a "section 3" (programming APIs) manpage
> but this is an excellent start.
OK, that seems sensible.
> The docs might benefit from a note about the load order of the modules,
> which if I understand the code is something like
> loadrt hostmot2
> loadrt hm2_pci
> loadrt mesa_7i65 # or other SPI driver
> Perhaps this could go near here (since just specifying a num_bspis won't
> *do* anything but take away GPIOs)?
Yes. That seems sensible.
Just as a warning, little or none of this is going to happen
particularly quickly as I am going away for a couple of weeks. I will
look at this further on my return. Not only will I be away from my
machines, I am likely to be out of sight of land...
--
atp
"Torque wrenches are for the obedience of fools and the guidance of wise men"
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
