All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vivek Yadav" <vivek.2311@samsung.com>
To: "'Marc Kleine-Budde'" <mkl@pengutronix.de>
Cc: <rcsekar@samsung.com>, <krzysztof.kozlowski+dt@linaro.org>,
	<wg@grandegger.com>, <davem@davemloft.net>, <edumazet@google.com>,
	<kuba@kernel.org>, <pabeni@redhat.com>,
	<pankaj.dubey@samsung.com>, <ravi.patel@samsung.com>,
	<alim.akhtar@samsung.com>, <linux-fsd@tesla.com>,
	<robh+dt@kernel.org>, <linux-can@vger.kernel.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-samsung-soc@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<aswani.reddy@samsung.com>, <sriranjani.p@samsung.com>
Subject: RE: RE: [PATCH v3 1/2] can: m_can: Move mram init to mcan device setup
Date: Thu, 1 Dec 2022 09:40:50 +0530	[thread overview]
Message-ID: <01f901d9053a$f138bdd0$d3aa3970$@samsung.com> (raw)
In-Reply-To: <20221124145405.d67cb6xmoiqfdsq3@pengutronix.de>



> -----Original Message-----
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Sent: 24 November 2022 20:24
> To: Vivek Yadav <vivek.2311@samsung.com>
> Cc: rcsekar@samsung.com; krzysztof.kozlowski+dt@linaro.org;
> wg@grandegger.com; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; pankaj.dubey@samsung.com;
> ravi.patel@samsung.com; alim.akhtar@samsung.com; linux-fsd@tesla.com;
> robh+dt@kernel.org; linux-can@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; devicetree@vger.kernel.org;
> aswani.reddy@samsung.com; sriranjani.p@samsung.com
> Subject: Re: RE: [PATCH v3 1/2] can: m_can: Move mram init to mcan device
> setup
> 
> On 24.11.2022 14:36:48, Vivek Yadav wrote:
> > > Why not call the RAM init directly from m_can_chip_config()?
> > >
> > m_can_chip_config function is called from m_can open.
> >
> > Configuring RAM init every time we open the CAN instance is not
> > needed, I think only once during the probe is enough.
> 
> That probably depends on you power management. If I add a regulator to
> power the external tcan4x5x chip and power it up during open(), I need to
> initialize the RAM.
> 
Thanks for the clarification,
There is one doubt for which I need clarity if I add ram init in m_can_chip_config.

In the current implementation, m_can_ram_init is added in the probe and m_can_class_resume function.
If I add the ram init function in chip_config which is getting called from m_can_start, then m_can_init_ram will be called two times, once in resume and next from m_can_start also.

Can we add ram init inside the m_can_open function itself?
Because it is independent of m_can resume functionality.

> > If message RAM init failed then fifo Transmit and receive will fail
> > and there will be no communication. So there is no point to "open and
> > Configure CAN chip".
> 
> For mmio devices the RAM init will probably not fail. There are return values
> and error checking for the SPI attached devices. Where the SPI
> communication will fail. However if this is problem, I assume the chip will not
> be detected in the first place.
> 
> > From my understanding it's better to keep RAM init inside the probe
> > and if there is a failure happened goes to CAN probe failure.
> 
> Marc
> 
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   |
> https://protect2.fireeye.com/v1/url?k=2053d9ab-7fc8e0b4-205252e4-
> 000babdfecba-a8c309c53e3358f5&q=1&e=c0cfd0e2-a422-4821-a49d-
> 113cfa4da9cb&u=https%3A%2F%2Fwww.pengutronix.de%2F  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


WARNING: multiple messages have this Message-ID (diff)
From: "Vivek Yadav" <vivek.2311@samsung.com>
To: "'Marc Kleine-Budde'" <mkl@pengutronix.de>
Cc: <rcsekar@samsung.com>, <krzysztof.kozlowski+dt@linaro.org>,
	<wg@grandegger.com>, <davem@davemloft.net>, <edumazet@google.com>,
	<kuba@kernel.org>, <pabeni@redhat.com>,
	<pankaj.dubey@samsung.com>, <ravi.patel@samsung.com>,
	<alim.akhtar@samsung.com>, <linux-fsd@tesla.com>,
	<robh+dt@kernel.org>, <linux-can@vger.kernel.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-samsung-soc@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<aswani.reddy@samsung.com>, <sriranjani.p@samsung.com>
Subject: RE: RE: [PATCH v3 1/2] can: m_can: Move mram init to mcan device setup
Date: Thu, 1 Dec 2022 09:40:50 +0530	[thread overview]
Message-ID: <01f901d9053a$f138bdd0$d3aa3970$@samsung.com> (raw)
In-Reply-To: <20221124145405.d67cb6xmoiqfdsq3@pengutronix.de>



> -----Original Message-----
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Sent: 24 November 2022 20:24
> To: Vivek Yadav <vivek.2311@samsung.com>
> Cc: rcsekar@samsung.com; krzysztof.kozlowski+dt@linaro.org;
> wg@grandegger.com; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; pankaj.dubey@samsung.com;
> ravi.patel@samsung.com; alim.akhtar@samsung.com; linux-fsd@tesla.com;
> robh+dt@kernel.org; linux-can@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; devicetree@vger.kernel.org;
> aswani.reddy@samsung.com; sriranjani.p@samsung.com
> Subject: Re: RE: [PATCH v3 1/2] can: m_can: Move mram init to mcan device
> setup
> 
> On 24.11.2022 14:36:48, Vivek Yadav wrote:
> > > Why not call the RAM init directly from m_can_chip_config()?
> > >
> > m_can_chip_config function is called from m_can open.
> >
> > Configuring RAM init every time we open the CAN instance is not
> > needed, I think only once during the probe is enough.
> 
> That probably depends on you power management. If I add a regulator to
> power the external tcan4x5x chip and power it up during open(), I need to
> initialize the RAM.
> 
Thanks for the clarification,
There is one doubt for which I need clarity if I add ram init in m_can_chip_config.

In the current implementation, m_can_ram_init is added in the probe and m_can_class_resume function.
If I add the ram init function in chip_config which is getting called from m_can_start, then m_can_init_ram will be called two times, once in resume and next from m_can_start also.

Can we add ram init inside the m_can_open function itself?
Because it is independent of m_can resume functionality.

> > If message RAM init failed then fifo Transmit and receive will fail
> > and there will be no communication. So there is no point to "open and
> > Configure CAN chip".
> 
> For mmio devices the RAM init will probably not fail. There are return values
> and error checking for the SPI attached devices. Where the SPI
> communication will fail. However if this is problem, I assume the chip will not
> be detected in the first place.
> 
> > From my understanding it's better to keep RAM init inside the probe
> > and if there is a failure happened goes to CAN probe failure.
> 
> Marc
> 
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   |
> https://protect2.fireeye.com/v1/url?k=2053d9ab-7fc8e0b4-205252e4-
> 000babdfecba-a8c309c53e3358f5&q=1&e=c0cfd0e2-a422-4821-a49d-
> 113cfa4da9cb&u=https%3A%2F%2Fwww.pengutronix.de%2F  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-01  4:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20221122105017epcas5p269e97219d3ebe2eaf37fa428a7275f35@epcas5p2.samsung.com>
2022-11-22 10:54 ` [PATCH v3 0/2] can: mcan: Add MCAN support for FSD SoC Vivek Yadav
2022-11-22 10:54   ` Vivek Yadav
2022-11-22 10:54   ` [PATCH v3 1/2] can: m_can: Move mram init to mcan device setup Vivek Yadav
2022-11-22 10:54     ` Vivek Yadav
2022-11-23 22:41     ` Marc Kleine-Budde
2022-11-23 22:41       ` Marc Kleine-Budde
2022-11-24  9:06       ` Vivek Yadav
2022-11-24  9:06         ` Vivek Yadav
2022-11-24 14:54         ` Marc Kleine-Budde
2022-11-24 14:54           ` Marc Kleine-Budde
2022-12-01  4:10           ` Vivek Yadav [this message]
2022-12-01  4:10             ` Vivek Yadav
2022-12-02 15:04             ` Marc Kleine-Budde
2022-12-02 15:04               ` Marc Kleine-Budde
2022-11-22 10:54   ` [PATCH v3 2/2] arm64: dts: fsd: Add MCAN device node Vivek Yadav
2022-11-22 10:54     ` Vivek Yadav
2022-11-23  8:38     ` Krzysztof Kozlowski
2022-11-23  8:38       ` Krzysztof Kozlowski
2022-12-06  8:26     ` Pankaj Dubey
2022-12-06  8:26       ` Pankaj Dubey

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='01f901d9053a$f138bdd0$d3aa3970$@samsung.com' \
    --to=vivek.2311@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=aswani.reddy@samsung.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-fsd@tesla.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pankaj.dubey@samsung.com \
    --cc=ravi.patel@samsung.com \
    --cc=rcsekar@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=sriranjani.p@samsung.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.