Messages in this thread | | | From | "Vivek Yadav" <> | Subject | RE: [PATCH 4/7] can: mcan: enable peripheral clk to access mram | Date | Wed, 9 Nov 2022 15:25:01 +0530 |
| |
> -----Original Message----- > From: Marc Kleine-Budde <mkl@pengutronix.de> > Sent: 25 October 2022 13:14 > To: Vivek Yadav <vivek.2311@samsung.com> > Cc: rcsekar@samsung.com; 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-can@vger.kernel.org; > netdev@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 4/7] can: mcan: enable peripheral clk to access mram > > On 21.10.2022 15:28:30, Vivek Yadav wrote: > > When we try to access the mcan message ram addresses, make sure hclk > > is not gated by any other drivers or disabled. Enable the clock (hclk) > > before accessing the mram and disable it after that. > > > > This is required in case if by-default hclk is gated. > > From my point of view it makes no sense to init the RAM during probe. > Can you move the init_ram into the m_can_chip_config() function? The > clocks should be enabled then. > As per my understanding, we should not remove message ram init from probe because if message ram init failed then there will be no Storing of Tx/Rx messages onto message ram, so it's better to confirm write operations onto message ram before CAN communication.
So we can kept init_ram in the probe function only, but we will shift init_ram into m_can_dev_setup function by the time clks are already enabled. > Marc > Thanks for the review. > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://protect2.fireeye.com/v1/url?k=fc7bf79b- > 9c996ac6-fc7a7cd4-000babd9f1ba-3024ea0d5d83d168&q=1&e=87d053cd- > e4ab-41e4-a21b- > c348747c0ce5&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 |
| |