From: mkl@pengutronix.de (Marc Kleine-Budde)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/4] can: m_can: update to support CAN FD features
Date: Wed, 05 Nov 2014 14:19:22 +0100 [thread overview]
Message-ID: <545A23DA.7030303@pengutronix.de> (raw)
In-Reply-To: <545A21AD.5040608@hartkopp.net>
On 11/05/2014 02:10 PM, Oliver Hartkopp wrote:
> On 05.11.2014 12:26, Dong Aisheng wrote:
>> On Wed, Nov 05, 2014 at 11:12:24AM +0100, Oliver Hartkopp wrote:
>>> On 05.11.2014 08:58, Dong Aisheng wrote:
>
>
>>> Unfortunately No. Here it becomes complicated due to the fact that
>>> the revision 3.0.x does not support per-frame switching for FD/BRS
>>> ...
>>
>> I'm not sure i got your point.
>> From m_can spec, it allows switch CAN mode by setting CMR bit.
>>
>> Bits 11:10 CMR[1:0]: CAN Mode Request
>> A change of the CAN operation mode is requested by writing to this bit
>> field. After change to the
>> requested operation mode the bit field is reset to ?00? and the status
>> flags FDBS and FDO are set
>> accordingly. In case the requested CAN operation mode is not enabled,
>> the value written to CMR is
>> retained until it is overwritten by the next mode change request. In
>> case CME = ?01?/?10?/?11? a
>> change to CAN operation according to ISO 11898-1 is always possible.
>> Default is CAN operation
>> according to ISO11898-1.
>> 00 unchanged
>> 01 Request CAN FD operation
>> 10 Request CAN FD operation with bit rate switching
>> 11 Request CAN operation according ISO11898-1
>>
>> So what's the difference between this function and the per-frame
>> switching
>> you mentioned?
>>
>>>
>>> When (priv->can.ctrlmode & CAN_CTRLMODE_FD) is true this *only*
>>> tells us, that the controller is _capable_ to send either CAN or CAN
>>> FD frames.
>>>
>>> It does not configure the controller into one of these specific
>>> settings!
>>>
>>> Additionally: AFAIK when writing to the CCCR you have to make sure
>>> that there's currently no ongoing transfer.
>>>
>>
>> I don't know about it before.
>> By searching m_can user manual v302 again, i still did not find this
>> limitation. Can you point me if you know where it is?
>>
>> BTW, since we only use one Tx Buffer for transmission currently, so we
>> should not meet that case that CAN mode is switched during transfer.
>> So the issue you concern may not happen.
>
> Yes. You are right. Having a FIFO with a size of 1 will help here :-)
Errrr....sorry...no.
Taking an easy route here but making it x times harder to extend the
driver to make use of the FIFO is not an option.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141105/d1e64e16/attachment-0001.sig>
next prev parent reply other threads:[~2014-11-05 13:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 7:58 [PATCH V2 1/4] can: m_can: update to support CAN FD features Dong Aisheng
2014-11-05 7:58 ` [PATCH V2 2/4] can: m_can: workaround for transmit data less than 4 bytes Dong Aisheng
2014-11-05 10:17 ` Marc Kleine-Budde
2014-11-05 10:33 ` Dong Aisheng
2014-11-05 11:32 ` Marc Kleine-Budde
2014-11-05 11:32 ` Dong Aisheng
2014-11-05 7:58 ` [PATCH V1 3/4] can: add can_is_canfd_skb() API Dong Aisheng
2014-11-05 9:39 ` Oliver Hartkopp
2014-11-05 7:58 ` [PATCH V1 4/4] can: m_can: allow to send std frame on CAN FD mode Dong Aisheng
2014-11-05 10:41 ` Marc Kleine-Budde
2014-11-05 11:08 ` Oliver Hartkopp
2014-11-05 10:12 ` [PATCH V2 1/4] can: m_can: update to support CAN FD features Oliver Hartkopp
2014-11-05 11:26 ` Dong Aisheng
2014-11-05 13:10 ` Oliver Hartkopp
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 13:15 ` Oliver Hartkopp
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 13:19 ` Marc Kleine-Budde [this message]
2014-11-05 13:46 ` Dong Aisheng
2014-11-05 14:35 ` Oliver Hartkopp
2014-11-05 11:35 ` Varka Bhadram
2014-11-05 11:36 ` Dong Aisheng
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=545A23DA.7030303@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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).