From: Andrew Lunn <andrew@lunn.ch>
To: Franklin S Cooper Jr <fcooper@ti.com>
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
wg@grandegger.com, mkl@pengutronix.de
Subject: Re: CAN-FD Transceiver Limitations
Date: Thu, 29 Jun 2017 16:21:42 +0200 [thread overview]
Message-ID: <20170629142142.GF9244@lunn.ch> (raw)
In-Reply-To: <de1f6343-4b28-4a5f-c6df-4e54c09fcce2@ti.com>
On Wed, Jun 28, 2017 at 05:14:42PM -0500, Franklin S Cooper Jr wrote:
> Hi All,
>
> The various CAN transceivers I've seen that support CAN-FD appear to be
> fairly limited in terms of their supported max speed. I've seen some
> transceivers that only support upto 2 Mbps while others support up to 5
> Mbps. This is a problem when the SoC's CAN IP can support even higher
> values than the transceiver.
>
> Ideally I would think the MCAN driver should at the very least know what
> the maximum speed supported by the transceiver it is connected to.
> Therefore, either throwing an error if a request for a speed above the
> transceiver capability or lower the requested speed to what ever the
> transceiver is capability of doing.
Hi Franklin
> In either case I do not know if it makes sense to add a DT property
> within the MCAN driver or create another subnode that contains this
> information. For example I see some ethernet drivers support
> "fixed-link" subnode which is trying to solve a similar issue.
Hi Franklin
I would say fixed-link is trying to solve a different issue. You use
fixed-link when you don't have a PHY connected to the Ethernet MAC. A
MAC driver will normally tell the PHY driver what speeds its supports,
and ask the PHY to negotiate a speed both the MAC and PHY supports
with the peer device. The MAC then gets told of the resulting speed.
If this PHY does not exist, you cannot ask it to perform auto-neg, you
have no idea what the peer is capable of. Hence you add a virtual PHY
using fixed-link, which always returns the same speed. This works
because if you don't have a PHY, the MAC is generally connected to
another MAC on the same board, typically an Ethernet switch. Hence the
speed is a board property and fixed.
You appear to have a different issue. I don't know the CAN
subsystem. Is the transceiver part of the model? Is there an API
between the CAN-MAC and the CAN-transceiver? It sounds like you need
to add an API call from the MAC driver to the transceiver driver to
ask it what it is capable of. I don't see this as being a DT property.
The transceiver should know its own capabilities. And you have to
think about non-DT systems, e.g. CAN devices on USB dongles.
Andrew
next prev parent reply other threads:[~2017-06-29 14:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 22:14 CAN-FD Transceiver Limitations Franklin S Cooper Jr
2017-06-29 14:21 ` Andrew Lunn [this message]
2017-06-29 14:49 ` Franklin S Cooper Jr
2017-06-29 15:41 ` Andrew Lunn
2017-06-29 16:36 ` Franklin S Cooper Jr
2017-06-29 17:19 ` Andrew Lunn
2017-06-29 22:36 ` Kurt Van Dijck
[not found] ` <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>
2017-06-29 23:14 ` Franklin S Cooper Jr
[not found] ` <d5c2e2f2-8b74-58e1-0cc8-727ba39bd14c-l0cyMroinI0@public.gmane.org>
2017-06-30 8:09 ` Kurt Van Dijck
[not found] ` <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>
2017-06-30 17:51 ` Franklin S Cooper Jr
2017-07-10 14:58 ` 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=20170629142142.GF9244@lunn.ch \
--to=andrew@lunn.ch \
--cc=fcooper@ti.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=wg@grandegger.com \
/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;
as well as URLs for NNTP newsgroup(s).