From: "Magnus Aagaard Sørensen" <mas@csselectronics.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Subject: Re: mcp25xxfd driver questions
Date: Wed, 30 Sep 2020 07:32:25 +0200 [thread overview]
Message-ID: <1ee0af54-cdd6-4dc7-1956-e302bec716ff@csselectronics.com> (raw)
In-Reply-To: <66662c88-aa9a-325d-8152-c5befbfafa2a@pengutronix.de>
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.
>> 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.
>> 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?
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.
> Hope that helps.
>
> regards,
> Marc
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.
Regards, Magnus.
next prev parent reply other threads:[~2020-09-30 5:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 11:07 mcp25xxfd driver questions Magnus Aagaard Sørensen
2020-09-29 13:46 ` Marc Kleine-Budde
2020-09-30 5:32 ` Magnus Aagaard Sørensen [this message]
2020-09-30 7:27 ` Marc Kleine-Budde
2020-09-30 10:11 ` Magnus Aagaard Sørensen
2020-09-30 10:34 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ee0af54-cdd6-4dc7-1956-e302bec716ff@csselectronics.com \
--to=mas@csselectronics.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox