| Message ID | 1415349914-9145-3-git-send-email-b29396@freescale.com |
|---|---|
| State | Awaiting Upstream, archived |
| Delegated to: | David Miller |
| Headers | show |
On Fri, Nov 07, 2014 at 11:30:38AM +0100, Marc Kleine-Budde wrote: > On 11/07/2014 09:45 AM, Dong Aisheng wrote: > > The M_CAN message RAM is usually equipped with a parity or ECC functionality. > > But RAM cells suffer a hardware reset and can therefore hold arbitrary > > content at startup - including parity and/or ECC bits. > > > > To prevent the M_CAN controller detecting checksum errors when reading > > potentially uninitialized TX message RAM content to transmit CAN > > frames the TX message RAM has to be written with (any kind of) initial > > data. > > > > Signed-off-by: Dong Aisheng <b29396@freescale.com> > > --- > > ChangeLog: > > v3-v4: > > * initialize the entire Message RAM in use instead of only 8 bytes > > since this is a valid and needed initialization process. > > Patch title also changed. > > --- > > drivers/net/can/m_can/m_can.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c > > index eee1533..de742d0 100644 > > --- a/drivers/net/can/m_can/m_can.c > > +++ b/drivers/net/can/m_can/m_can.c > > @@ -1114,7 +1114,7 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > > struct resource *res; > > void __iomem *addr; > > u32 out_val[MRAM_CFG_LEN]; > > - int ret; > > + int i, start, end, ret; > > > > /* message ram could be shared */ > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram"); > > @@ -1165,6 +1165,15 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > > priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num, > > priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num); > > > > + /* initialize the entire Message RAM in use to avoid possible > > + * ECC/parity checksum errors when reading an uninitialized buffer > > + */ > > + start = priv->mcfg[MRAM_SIDF].off; > > + end = priv->mcfg[MRAM_TXB].off + > > + priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE; > > + for (i = start; i < end; i += 4) > > + writel(0x0, priv->mram_base + i); > > Can we access the mram without turning on the clock? > Yes, we can. Since it's CPU access, it seems it does not depend on M_CAN clocks. What i see from M_CAN subsystem block diagram of MX6SX, it requires CPU clock which should always be enabled. Regards Dong Aisheng > 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 | > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/07/2014 09:45 AM, Dong Aisheng wrote: > The M_CAN message RAM is usually equipped with a parity or ECC functionality. > But RAM cells suffer a hardware reset and can therefore hold arbitrary > content at startup - including parity and/or ECC bits. > > To prevent the M_CAN controller detecting checksum errors when reading > potentially uninitialized TX message RAM content to transmit CAN > frames the TX message RAM has to be written with (any kind of) initial > data. > > Signed-off-by: Dong Aisheng <b29396@freescale.com> > --- > ChangeLog: > v3-v4: > * initialize the entire Message RAM in use instead of only 8 bytes > since this is a valid and needed initialization process. > Patch title also changed. > --- > drivers/net/can/m_can/m_can.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c > index eee1533..de742d0 100644 > --- a/drivers/net/can/m_can/m_can.c > +++ b/drivers/net/can/m_can/m_can.c > @@ -1114,7 +1114,7 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > struct resource *res; > void __iomem *addr; > u32 out_val[MRAM_CFG_LEN]; > - int ret; > + int i, start, end, ret; > > /* message ram could be shared */ > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram"); > @@ -1165,6 +1165,15 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num, > priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num); > > + /* initialize the entire Message RAM in use to avoid possible > + * ECC/parity checksum errors when reading an uninitialized buffer > + */ > + start = priv->mcfg[MRAM_SIDF].off; > + end = priv->mcfg[MRAM_TXB].off + > + priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE; > + for (i = start; i < end; i += 4) > + writel(0x0, priv->mram_base + i); Can we access the mram without turning on the clock? Marc
Thanks! Hopefully we can manage to push the patch series via can/master ;-) Regards, Oliver On 07.11.2014 09:45, Dong Aisheng wrote: > The M_CAN message RAM is usually equipped with a parity or ECC functionality. > But RAM cells suffer a hardware reset and can therefore hold arbitrary > content at startup - including parity and/or ECC bits. > > To prevent the M_CAN controller detecting checksum errors when reading > potentially uninitialized TX message RAM content to transmit CAN > frames the TX message RAM has to be written with (any kind of) initial > data. > > Signed-off-by: Dong Aisheng <b29396@freescale.com> > --- > ChangeLog: > v3-v4: > * initialize the entire Message RAM in use instead of only 8 bytes > since this is a valid and needed initialization process. > Patch title also changed. > --- > drivers/net/can/m_can/m_can.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c > index eee1533..de742d0 100644 > --- a/drivers/net/can/m_can/m_can.c > +++ b/drivers/net/can/m_can/m_can.c > @@ -1114,7 +1114,7 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > struct resource *res; > void __iomem *addr; > u32 out_val[MRAM_CFG_LEN]; > - int ret; > + int i, start, end, ret; > > /* message ram could be shared */ > res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram"); > @@ -1165,6 +1165,15 @@ static int m_can_of_parse_mram(struct platform_device *pdev, > priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num, > priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num); > > + /* initialize the entire Message RAM in use to avoid possible > + * ECC/parity checksum errors when reading an uninitialized buffer > + */ > + start = priv->mcfg[MRAM_SIDF].off; > + end = priv->mcfg[MRAM_TXB].off + > + priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE; > + for (i = start; i < end; i += 4) > + writel(0x0, priv->mram_base + i); > + > return 0; > } > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c index eee1533..de742d0 100644 --- a/drivers/net/can/m_can/m_can.c +++ b/drivers/net/can/m_can/m_can.c @@ -1114,7 +1114,7 @@ static int m_can_of_parse_mram(struct platform_device *pdev, struct resource *res; void __iomem *addr; u32 out_val[MRAM_CFG_LEN]; - int ret; + int i, start, end, ret; /* message ram could be shared */ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "message_ram"); @@ -1165,6 +1165,15 @@ static int m_can_of_parse_mram(struct platform_device *pdev, priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num, priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num); + /* initialize the entire Message RAM in use to avoid possible + * ECC/parity checksum errors when reading an uninitialized buffer + */ + start = priv->mcfg[MRAM_SIDF].off; + end = priv->mcfg[MRAM_TXB].off + + priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE; + for (i = start; i < end; i += 4) + writel(0x0, priv->mram_base + i); + return 0; }
The M_CAN message RAM is usually equipped with a parity or ECC functionality. But RAM cells suffer a hardware reset and can therefore hold arbitrary content at startup - including parity and/or ECC bits. To prevent the M_CAN controller detecting checksum errors when reading potentially uninitialized TX message RAM content to transmit CAN frames the TX message RAM has to be written with (any kind of) initial data. Signed-off-by: Dong Aisheng <b29396@freescale.com> --- ChangeLog: v3-v4: * initialize the entire Message RAM in use instead of only 8 bytes since this is a valid and needed initialization process. Patch title also changed. --- drivers/net/can/m_can/m_can.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)