From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
Dong Aisheng <b29396@freescale.com>
Cc: linux-can@vger.kernel.org, wg@grandegger.com,
varkabhadram@gmail.com, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [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>
[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]
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 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
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: 55+ 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 ` Dong Aisheng
2014-11-05 7:58 ` 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 7:58 ` Dong Aisheng
2014-11-05 7:58 ` Dong Aisheng
2014-11-05 10:17 ` Marc Kleine-Budde
2014-11-05 10:17 ` Marc Kleine-Budde
2014-11-05 10:33 ` Dong Aisheng
2014-11-05 10:33 ` Dong Aisheng
2014-11-05 10:33 ` Dong Aisheng
2014-11-05 11:32 ` Marc Kleine-Budde
2014-11-05 11:32 ` Marc Kleine-Budde
2014-11-05 11:32 ` Dong Aisheng
2014-11-05 11:32 ` Dong Aisheng
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 7:58 ` Dong Aisheng
2014-11-05 7:58 ` Dong Aisheng
2014-11-05 9:39 ` Oliver Hartkopp
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 7:58 ` Dong Aisheng
2014-11-05 7:58 ` Dong Aisheng
2014-11-05 10:41 ` Marc Kleine-Budde
2014-11-05 10:41 ` Marc Kleine-Budde
2014-11-05 11:08 ` Oliver Hartkopp
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 10:12 ` Oliver Hartkopp
2014-11-05 11:26 ` Dong Aisheng
2014-11-05 11:26 ` Dong Aisheng
2014-11-05 11:26 ` Dong Aisheng
2014-11-05 13:10 ` Oliver Hartkopp
2014-11-05 13:10 ` Oliver Hartkopp
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 13:15 ` Oliver Hartkopp
2014-11-05 13:15 ` Oliver Hartkopp
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 12:47 ` Dong Aisheng
2014-11-05 13:19 ` Marc Kleine-Budde [this message]
2014-11-05 13:19 ` Marc Kleine-Budde
2014-11-05 13:46 ` Dong Aisheng
2014-11-05 13:46 ` Dong Aisheng
2014-11-05 13:46 ` Dong Aisheng
2014-11-05 14:35 ` Oliver Hartkopp
2014-11-05 14:35 ` Oliver Hartkopp
2014-11-05 11:35 ` Varka Bhadram
2014-11-05 11:35 ` Varka Bhadram
2014-11-05 11:36 ` Dong Aisheng
2014-11-05 11:36 ` Dong Aisheng
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=b29396@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=socketcan@hartkopp.net \
--cc=varkabhadram@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.