From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Dong Aisheng <b29396@freescale.com>
Cc: linux-can@vger.kernel.org, wg@grandegger.com,
socketcan@hartkopp.net, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, mark.rutland@arm.com,
varkabhadram@gmail.com
Subject: Re: [PATCH v4 2/2] can: m_can: add Bosch M_CAN controller support
Date: Tue, 15 Jul 2014 11:21:57 +0200 [thread overview]
Message-ID: <53C4F2B5.7050704@pengutronix.de> (raw)
In-Reply-To: <20140715090719.GA3374@shlinux1.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 4205 bytes --]
On 07/15/2014 11:07 AM, Dong Aisheng wrote:
> On Tue, Jul 15, 2014 at 10:46:32AM +0200, Marc Kleine-Budde wrote:
>> On 07/15/2014 10:26 AM, Dong Aisheng wrote:
>>>>>>> +static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
>>>>>>> + u32 rxfs)
>>>>>>> +{
>>>>>>> + struct m_can_priv *priv = netdev_priv(dev);
>>>>>>> + u32 flags, fgi;
>>>>>>> +
>>>>>>> + /* calculate the fifo get index for where to read data */
>>>>>>> + fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
>>>>>>> + flags = m_can_fifo_read(priv, fgi, 0x0);
>>>>>> ^^^
>>>>>>
>>>>>> Can you introduce an enum for the offsets, please adjust the signature
>>>>>> of m_can_fifo_read() accordingly.
>>>>>>
>>>>>
>>>>> I wonder enum may not be suitable.
>>>>> The Rx Buffer and FIFO Element is as follows:
>>>>> 31 24 23 16 15 8 7 0
>>>>> R0 ESI XTD RTR ID[28:0]
>>>>
>>>> M_CAN_FIFO_ID
>>>>
>>>>> R1 ANMF FIDX[6:0] res EDL BRS DLC[3:0] RXTS[15:0]
>>>>
>>>> M_CAN_FIFO_DLC
>>>>
>>>>> R2 DB3[7:0] DB2[7:0] DB1[7:0] DB0[7:0]
>>>>> R3 DB7[7:0] DB6[7:0] DB5[7:0] DB4[7:0]
>>>>
>>>> M_CAN_FIFO_DATA0
>>>> M_CAN_FIFO_DATA1
>>>>
>>>
>>> You mean as follows?
>>> enum m_can_fifo {
>>> M_CAN_FIFO_ID = 0,
>>> M_CAN_FIFO_DLC,
>> = 0x4,
>>> M_CAN_FIFO_DATA0,
>> = 0x8,
>>> M_CAN_FIFO_DATA1,
>> = 0xc,
>>> };
>>>
>>> static inline u32 m_can_fifo_read(const struct m_can_priv *priv,
>>> u32 fgi, enum m_can_fifo fifo)
>>> {
>>> return readl(priv->mram_base + priv->mcfg[MRAM_RXF0].off +
>>> fgi * RXF0_ELEMENT_SIZE + fifo * 0x4);
>>> }
>>
>> without the * 0x4
>>
>>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
>>>
>>> The problem is when adding long frames support, it becomes:
>>> enum m_can_fifo {
>>> M_CAN_FIFO_ID = 0,
>>> M_CAN_FIFO_DLC,
>>> M_CAN_FIFO_DATA0,
>>> M_CAN_FIFO_DATA1,
>>> ....
>>> M_CAN_FIFO_DATA15,
>>> };
>>
>> #define M_CAN_FIFO_DATA(n)
>> (enum m_can_fifo)(M_CAN_FIFO_DATA_0 + (n) << 2)
>>
>
> This is a bit strange using and we may still have to define other M_CAN_FIFO_DATAx
> to avoid the enum value exceeds the defined range.
> enum m_can_fifo {
> M_CAN_FIFO_ID = 0,
> M_CAN_FIFO_DLC = 0x4,
> M_CAN_FIFO_DATA0 = 0x8,
> M_CAN_FIFO_DATA1 = 0xc,
> ....
> M_CAN_FIFO_DATA15 = 0xc,
> };
>
> However, actually we will not use them at all after introducing M_CAN_FIFO_DATA(n).
> If that, why we still need define them in enum?
>
> Comparing to this way, why not simply just do as follows:
> #define M_CAN_FIFO_ID 0x0
> #define M_CAN_FIFO_DLC 0x4
> #define M_CAN_FIFO_DATA(n) (0x8 + (n) << 2)
>
> What do you think?
Looks good.
>
>>> But it's useless because we may not use enum to read fifo data anymore.
>>> It's not suitable to read fifo one by one:
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA0);
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA1);
>>> ..
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA15);
>>>
>>>
>>> Instead, we may read data according to real dlc value within a for loop like:
>>> #define M_CAN_FIFO(n) (n * 0x4)
>>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO(0));
>>> dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO(1));
>>> for (i = 0; dlc > 0; dlc -= 0x4, i++) {
>>> ....
>>> data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO(i + 2));
>>> }
>>
>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
>> dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
>> for (i = 0; i <= dlc; i++)
>> data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i));
>
> Does it work?
> The dlc is in bytes while m_can_fifo_read is read in words.
Doh! probably not :) But should work with something like this:
int len = DIV_ROUND_UP(dlc, 4);
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: 242 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 v4 2/2] can: m_can: add Bosch M_CAN controller support
Date: Tue, 15 Jul 2014 11:21:57 +0200 [thread overview]
Message-ID: <53C4F2B5.7050704@pengutronix.de> (raw)
In-Reply-To: <20140715090719.GA3374@shlinux1.ap.freescale.net>
On 07/15/2014 11:07 AM, Dong Aisheng wrote:
> On Tue, Jul 15, 2014 at 10:46:32AM +0200, Marc Kleine-Budde wrote:
>> On 07/15/2014 10:26 AM, Dong Aisheng wrote:
>>>>>>> +static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
>>>>>>> + u32 rxfs)
>>>>>>> +{
>>>>>>> + struct m_can_priv *priv = netdev_priv(dev);
>>>>>>> + u32 flags, fgi;
>>>>>>> +
>>>>>>> + /* calculate the fifo get index for where to read data */
>>>>>>> + fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
>>>>>>> + flags = m_can_fifo_read(priv, fgi, 0x0);
>>>>>> ^^^
>>>>>>
>>>>>> Can you introduce an enum for the offsets, please adjust the signature
>>>>>> of m_can_fifo_read() accordingly.
>>>>>>
>>>>>
>>>>> I wonder enum may not be suitable.
>>>>> The Rx Buffer and FIFO Element is as follows:
>>>>> 31 24 23 16 15 8 7 0
>>>>> R0 ESI XTD RTR ID[28:0]
>>>>
>>>> M_CAN_FIFO_ID
>>>>
>>>>> R1 ANMF FIDX[6:0] res EDL BRS DLC[3:0] RXTS[15:0]
>>>>
>>>> M_CAN_FIFO_DLC
>>>>
>>>>> R2 DB3[7:0] DB2[7:0] DB1[7:0] DB0[7:0]
>>>>> R3 DB7[7:0] DB6[7:0] DB5[7:0] DB4[7:0]
>>>>
>>>> M_CAN_FIFO_DATA0
>>>> M_CAN_FIFO_DATA1
>>>>
>>>
>>> You mean as follows?
>>> enum m_can_fifo {
>>> M_CAN_FIFO_ID = 0,
>>> M_CAN_FIFO_DLC,
>> = 0x4,
>>> M_CAN_FIFO_DATA0,
>> = 0x8,
>>> M_CAN_FIFO_DATA1,
>> = 0xc,
>>> };
>>>
>>> static inline u32 m_can_fifo_read(const struct m_can_priv *priv,
>>> u32 fgi, enum m_can_fifo fifo)
>>> {
>>> return readl(priv->mram_base + priv->mcfg[MRAM_RXF0].off +
>>> fgi * RXF0_ELEMENT_SIZE + fifo * 0x4);
>>> }
>>
>> without the * 0x4
>>
>>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
>>>
>>> The problem is when adding long frames support, it becomes:
>>> enum m_can_fifo {
>>> M_CAN_FIFO_ID = 0,
>>> M_CAN_FIFO_DLC,
>>> M_CAN_FIFO_DATA0,
>>> M_CAN_FIFO_DATA1,
>>> ....
>>> M_CAN_FIFO_DATA15,
>>> };
>>
>> #define M_CAN_FIFO_DATA(n)
>> (enum m_can_fifo)(M_CAN_FIFO_DATA_0 + (n) << 2)
>>
>
> This is a bit strange using and we may still have to define other M_CAN_FIFO_DATAx
> to avoid the enum value exceeds the defined range.
> enum m_can_fifo {
> M_CAN_FIFO_ID = 0,
> M_CAN_FIFO_DLC = 0x4,
> M_CAN_FIFO_DATA0 = 0x8,
> M_CAN_FIFO_DATA1 = 0xc,
> ....
> M_CAN_FIFO_DATA15 = 0xc,
> };
>
> However, actually we will not use them at all after introducing M_CAN_FIFO_DATA(n).
> If that, why we still need define them in enum?
>
> Comparing to this way, why not simply just do as follows:
> #define M_CAN_FIFO_ID 0x0
> #define M_CAN_FIFO_DLC 0x4
> #define M_CAN_FIFO_DATA(n) (0x8 + (n) << 2)
>
> What do you think?
Looks good.
>
>>> But it's useless because we may not use enum to read fifo data anymore.
>>> It's not suitable to read fifo one by one:
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA0);
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA1);
>>> ..
>>> m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA15);
>>>
>>>
>>> Instead, we may read data according to real dlc value within a for loop like:
>>> #define M_CAN_FIFO(n) (n * 0x4)
>>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO(0));
>>> dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO(1));
>>> for (i = 0; dlc > 0; dlc -= 0x4, i++) {
>>> ....
>>> data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO(i + 2));
>>> }
>>
>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
>> dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
>> for (i = 0; i <= dlc; i++)
>> data[i] = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i));
>
> Does it work?
> The dlc is in bytes while m_can_fifo_read is read in words.
Doh! probably not :) But should work with something like this:
int len = DIV_ROUND_UP(dlc, 4);
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: 242 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140715/0265cfa9/attachment.sig>
next prev parent reply other threads:[~2014-07-15 9:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-14 11:40 [PATCH v4 1/2] can: m_can: add device tree binding documentation Dong Aisheng
2014-07-14 11:40 ` Dong Aisheng
2014-07-14 11:40 ` [PATCH v4 2/2] can: m_can: add Bosch M_CAN controller support Dong Aisheng
2014-07-14 11:40 ` Dong Aisheng
2014-07-14 12:13 ` Marc Kleine-Budde
2014-07-14 12:13 ` Marc Kleine-Budde
2014-07-15 3:33 ` Dong Aisheng
2014-07-15 3:33 ` Dong Aisheng
2014-07-15 7:29 ` Marc Kleine-Budde
2014-07-15 7:29 ` Marc Kleine-Budde
2014-07-15 8:26 ` Dong Aisheng
2014-07-15 8:26 ` Dong Aisheng
2014-07-15 8:46 ` Marc Kleine-Budde
2014-07-15 8:46 ` Marc Kleine-Budde
2014-07-15 9:07 ` Dong Aisheng
2014-07-15 9:07 ` Dong Aisheng
2014-07-15 9:21 ` Marc Kleine-Budde [this message]
2014-07-15 9:21 ` Marc Kleine-Budde
2014-07-15 10:40 ` Dong Aisheng
2014-07-15 10:40 ` Dong Aisheng
2014-07-14 12:47 ` Varka Bhadram
2014-07-14 12:47 ` Varka Bhadram
2014-07-14 13:01 ` Marc Kleine-Budde
2014-07-14 13:01 ` Marc Kleine-Budde
2014-07-14 13:15 ` Varka Bhadram
2014-07-14 13:15 ` Varka Bhadram
2014-07-15 6:28 ` Dong Aisheng
2014-07-15 6:28 ` Dong Aisheng
2014-07-15 6:27 ` Dong Aisheng
2014-07-15 6:27 ` Dong Aisheng
2014-07-15 6:56 ` Varka Bhadram
2014-07-15 6:56 ` Varka Bhadram
2014-07-15 7:10 ` Marc Kleine-Budde
2014-07-15 7:10 ` Marc Kleine-Budde
2014-07-15 7:15 ` Varka Bhadram
2014-07-15 7:15 ` Varka Bhadram
2014-07-15 7:14 ` Dong Aisheng
2014-07-15 7:14 ` Dong Aisheng
2014-07-15 7:20 ` Varka Bhadram
2014-07-15 7:20 ` Varka Bhadram
2014-07-14 11:52 ` [PATCH v4 1/2] can: m_can: add device tree binding documentation Marc Kleine-Budde
2014-07-14 11:52 ` Marc Kleine-Budde
2014-07-15 2:26 ` Dong Aisheng
2014-07-15 2:26 ` 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=53C4F2B5.7050704@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=b29396@freescale.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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.