Re: mcp25xxfd driver questions

["Magnus Aagaard Sørensen" <mas@csselectronics.com>]

On 30-09-2020 09:27, Marc Kleine-Budde wrote:
> On 9/30/20 7:32 AM, Magnus Aagaard Sørensen wrote:
>> On 29-09-2020 15:46, Marc Kleine-Budde wrote:
>>> On 9/29/20 1:07 PM, Magnus Aagaard Sørensen wrote:
>>>> I'm evaluating the MCP2518FD, and have two questions to the driver.
>> I should clarify that we already have an older internal test board with
>> the chip working, using the driver by Martin Sperl. I'm evaluating the
>> possibilities to migrate to this driver in the future, since I can see
>> it is being mainline, but for now I mainly wish to use it on a new
>> internal test board.
> Ah, ok. More users are always welcome. Which SoC are you using?
We are controlling the test boards using a Raspberry Pi 4, so I assume 
it is a Broadcom BCM2711.
>>>> 1. I could not find any references to the GPIOs of the chip. Is it
>>>> correct that these are not exposed to the host system?
>>> ACK, gpio support is not implemented yet. Drop me a note, if you need it.
>> On the board I'm currently working on getting up and running, we have no
>> need for GPIOs or any of the other advanced features of the MCP2518FD.
>> On our older board, we do utilize the GPIO and oscillator output
>> functionality of the chip. It works for now with the old driver, so it
>> is not a priority. It would be nice to have this functionality in the
>> future for us.
> Bas Vermeulen (Cc'ed) is using the mainline driver (or an older version of it)
> and send a pull request for oscillator output
> (https://github.com/marckleinebudde/linux/pull/5). I did an initial review
> there. This is a good starting point if you want to contribute (or drop me a
> note for commercial support).
>
>>>> 2. When setting the oscillator frequency outside the
>>>> MCP25XXFD_SYSCLOCK_HZ_MIN and MCP25XXFD_SYSCLOCK_HZ_MAX range, the
>>>> frequency is compared to the max value scaled by the max PLL value. Is
>>>> the intention to compare with the min value? Currently, an external
>>>> oscillator of 4 MHz and a PLL value of 10, resulting in 40 MHz, is
>>>> treated as being too low.
>>> This is intended. I have no hardware with a 4MHz osc to test, so I decided to
>>> not support the 4MHz osc for now. If you design new hardware I suggest to use a
>>> 40MHz osc, as probably no one has tested the hardware thoroughly in the PLL
>>> mode. If you need 4MHz support, it can be added, given there is hardware.
>> I can provide some test information if needed, as I have internal
>> testing hardware with a 4 MHz oscillator already. Are there any specific
>> message sequences that needs to be tested?
> You have to take care of the PLL in the functions mcp25xxfd_chip_clock_enable(),
> mcp25xxfd_chip_softreset_check(), mcp25xxfd_chip_clock_init().
>
> The MCP25XXFD_REG_OSC_PLLEN bit has to be set and the MCP25XXFD_REG_OSC_PLLRDY
> bit has to be polled.
>
> I'm not sure what SPI speed you can use, when communicating with the mcp, if the
> PLL is not enabled. Maybe Thomas (Cc'ed) can answer this. I suspect you can only
> use 2MHZ (or rather 85% of it) if you have a 4 MHz OSC with PLL still disabled.
Thanks for the hints, I'll see if I can adapt it to our use case.
>> The chip will most likely not reach high loads with the setup we have in
>> mind, so I'll manually change the frequency check in the probe function
>> for now.
> This will probably not work, as the driver has to enable the PLL and the SPI
> clock has to be really slow.
>
>> It's great to hear the reasoning. Thanks for the hard work you and
>> others have put into this driver and the whole CAN system in linux.
> Thanks. I'm just standing on the shoulder of giants. This driver was and is
> great community work. First of all there was Martin's driver, which shows how a
> Linux driver for the chip can look. Then several tireless testers here and on
> github, direct and open communication with Microchip, and there are several
> $CUSTOMERs paying to get the driver mainline.
>
> regards,
> Marc

Regards, Magnus.