Re: mcp25xxfd driver questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux