All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-usb@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Felipe Balbi <balbi@kernel.org>,
	Peter Ujfalusi <peter.ujfalusi@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	linux-mmc@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF
Date: Tue, 22 Mar 2022 18:36:46 +0200	[thread overview]
Message-ID: <20220322163646.GD297526@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <20220321215416.236250-1-jmkrzyszt@gmail.com>

Hi,

On Mon, Mar 21, 2022 at 10:54:16PM +0100, Janusz Krzysztofik wrote:
> In preparation for conversion of OMAP1 clocks to common clock framework,
> identify users of those clocks which don't call clk_prepare/unprepare()
> and update them to call clk_prepare_enable/clk_disable_unprepare() instead
> of just clk_enable/disable(), as required by CCF implementation of clock
> API.
> 
> v2: update still a few more OMAP specific drivers missed in v1,
>   - call clk_prepare/unprepare() just after/before clk_get/put() where it
>     can make more sense than merging prepare/unprepare with enable/disable.

Something is still broken. When doing kexec (using CCF kernel), the
kexec'ed kernel now hangs early (on 770):

[    0.853912] MUX: initialized W4_USB_PUEN
[    0.858001] MUX: initialized V6_USB0_TXD
[    0.862060] MUX: initialized W5_USB0_SE0
[    0.866210] MUX: initialized Y5_USB0_RCV
[    0.870269] MUX: initialized AA9_USB0_VP
[    0.874389] MUX: initialized R9_USB0_VM
[    0.878356] USB: hmc 16, usb0 6 wires (dev), Mini-AB on usb0
[    0.886230] initcall customize_machine+0x0/0x30 returned 0 after 29296 usecs
[    0.893707] calling  init_atags_procfs+0x0/0xe8 @ 1
[    0.898864] initcall init_atags_procfs+0x0/0xe8 returned 0 after 0 usecs
[    0.905883] calling  exceptions_init+0x0/0x8c @ 1
[    0.910797] initcall exceptions_init+0x0/0x8c returned 0 after 0 usecs
[    0.917602] calling  omap_init+0x0/0xc @ 1
[    0.922393] initcall omap_init+0x0/0xc returned 0 after 9765 usecs
[    0.928863] calling  omap1_init_devices+0x0/0x2c @ 1
[    2.568664] random: fast init done

Probably something is now disabled that has been previously always
enabled by default/bootloader. I'll try adding some printk()s to see
the exact place where it hangs...

A.

WARNING: multiple messages have this Message-ID (diff)
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Cc: alsa-devel@alsa-project.org, Felipe Balbi <balbi@kernel.org>,
	Paul Walmsley <paul@pwsan.com>, Arnd Bergmann <arnd@arndb.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>,
	linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-omap@vger.kernel.org,
	Peter Ujfalusi <peter.ujfalusi@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF
Date: Tue, 22 Mar 2022 18:36:46 +0200	[thread overview]
Message-ID: <20220322163646.GD297526@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <20220321215416.236250-1-jmkrzyszt@gmail.com>

Hi,

On Mon, Mar 21, 2022 at 10:54:16PM +0100, Janusz Krzysztofik wrote:
> In preparation for conversion of OMAP1 clocks to common clock framework,
> identify users of those clocks which don't call clk_prepare/unprepare()
> and update them to call clk_prepare_enable/clk_disable_unprepare() instead
> of just clk_enable/disable(), as required by CCF implementation of clock
> API.
> 
> v2: update still a few more OMAP specific drivers missed in v1,
>   - call clk_prepare/unprepare() just after/before clk_get/put() where it
>     can make more sense than merging prepare/unprepare with enable/disable.

Something is still broken. When doing kexec (using CCF kernel), the
kexec'ed kernel now hangs early (on 770):

[    0.853912] MUX: initialized W4_USB_PUEN
[    0.858001] MUX: initialized V6_USB0_TXD
[    0.862060] MUX: initialized W5_USB0_SE0
[    0.866210] MUX: initialized Y5_USB0_RCV
[    0.870269] MUX: initialized AA9_USB0_VP
[    0.874389] MUX: initialized R9_USB0_VM
[    0.878356] USB: hmc 16, usb0 6 wires (dev), Mini-AB on usb0
[    0.886230] initcall customize_machine+0x0/0x30 returned 0 after 29296 usecs
[    0.893707] calling  init_atags_procfs+0x0/0xe8 @ 1
[    0.898864] initcall init_atags_procfs+0x0/0xe8 returned 0 after 0 usecs
[    0.905883] calling  exceptions_init+0x0/0x8c @ 1
[    0.910797] initcall exceptions_init+0x0/0x8c returned 0 after 0 usecs
[    0.917602] calling  omap_init+0x0/0xc @ 1
[    0.922393] initcall omap_init+0x0/0xc returned 0 after 9765 usecs
[    0.928863] calling  omap1_init_devices+0x0/0x2c @ 1
[    2.568664] random: fast init done

Probably something is now disabled that has been previously always
enabled by default/bootloader. I'll try adding some printk()s to see
the exact place where it hangs...

A.

WARNING: multiple messages have this Message-ID (diff)
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-usb@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Felipe Balbi <balbi@kernel.org>,
	Peter Ujfalusi <peter.ujfalusi@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	linux-mmc@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF
Date: Tue, 22 Mar 2022 18:36:46 +0200	[thread overview]
Message-ID: <20220322163646.GD297526@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <20220321215416.236250-1-jmkrzyszt@gmail.com>

Hi,

On Mon, Mar 21, 2022 at 10:54:16PM +0100, Janusz Krzysztofik wrote:
> In preparation for conversion of OMAP1 clocks to common clock framework,
> identify users of those clocks which don't call clk_prepare/unprepare()
> and update them to call clk_prepare_enable/clk_disable_unprepare() instead
> of just clk_enable/disable(), as required by CCF implementation of clock
> API.
> 
> v2: update still a few more OMAP specific drivers missed in v1,
>   - call clk_prepare/unprepare() just after/before clk_get/put() where it
>     can make more sense than merging prepare/unprepare with enable/disable.

Something is still broken. When doing kexec (using CCF kernel), the
kexec'ed kernel now hangs early (on 770):

[    0.853912] MUX: initialized W4_USB_PUEN
[    0.858001] MUX: initialized V6_USB0_TXD
[    0.862060] MUX: initialized W5_USB0_SE0
[    0.866210] MUX: initialized Y5_USB0_RCV
[    0.870269] MUX: initialized AA9_USB0_VP
[    0.874389] MUX: initialized R9_USB0_VM
[    0.878356] USB: hmc 16, usb0 6 wires (dev), Mini-AB on usb0
[    0.886230] initcall customize_machine+0x0/0x30 returned 0 after 29296 usecs
[    0.893707] calling  init_atags_procfs+0x0/0xe8 @ 1
[    0.898864] initcall init_atags_procfs+0x0/0xe8 returned 0 after 0 usecs
[    0.905883] calling  exceptions_init+0x0/0x8c @ 1
[    0.910797] initcall exceptions_init+0x0/0x8c returned 0 after 0 usecs
[    0.917602] calling  omap_init+0x0/0xc @ 1
[    0.922393] initcall omap_init+0x0/0xc returned 0 after 9765 usecs
[    0.928863] calling  omap1_init_devices+0x0/0x2c @ 1
[    2.568664] random: fast init done

Probably something is now disabled that has been previously always
enabled by default/bootloader. I'll try adding some printk()s to see
the exact place where it hangs...

A.

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

  parent reply	other threads:[~2022-03-22 16:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 23:33 [RFC RFT PATCH 0/4] ARM: OMAP1: clock: Convert to CCF Janusz Krzysztofik
2022-03-10 23:33 ` Janusz Krzysztofik
2022-03-10 23:33 ` [RFC PATCH 1/4] ARM: OMAP1: clock: Remove unused code Janusz Krzysztofik
2022-03-10 23:33   ` Janusz Krzysztofik
2022-03-10 23:33 ` [RFC PATCH 2/4] ARM: OMAP1: clock: Remove noop code Janusz Krzysztofik
2022-03-10 23:33   ` Janusz Krzysztofik
2022-03-21 21:54   ` [PATCH v2] ARM: OMAP1: Prepare for conversion of OMAP1 clocks to CCF Janusz Krzysztofik
2022-03-21 21:54     ` Janusz Krzysztofik
2022-03-21 21:54     ` Janusz Krzysztofik
2022-03-22 12:02     ` Mark Brown
2022-03-22 12:02       ` Mark Brown
2022-03-22 12:02       ` Mark Brown
2022-03-22 16:36     ` Aaro Koskinen [this message]
2022-03-22 16:36       ` Aaro Koskinen
2022-03-22 16:36       ` Aaro Koskinen
2022-03-22 19:07       ` Aaro Koskinen
2022-03-22 19:07         ` Aaro Koskinen
2022-03-22 19:07         ` Aaro Koskinen
2022-03-26 21:17         ` Janusz Krzysztofik
2022-03-26 21:17           ` Janusz Krzysztofik
2022-03-26 21:17           ` Janusz Krzysztofik
2022-04-06 13:21           ` Aaro Koskinen
2022-04-06 13:21             ` Aaro Koskinen
2022-04-06 13:21             ` Aaro Koskinen
2022-04-06 18:48             ` Janusz Krzysztofik
2022-04-06 18:48               ` Janusz Krzysztofik
2022-04-06 18:48               ` Janusz Krzysztofik
2022-04-06 20:00               ` Aaro Koskinen
2022-04-06 20:00                 ` Aaro Koskinen
2022-04-06 20:00                 ` Aaro Koskinen
2022-03-31  9:19     ` Ulf Hansson
2022-03-31  9:19       ` Ulf Hansson
2022-03-31  9:19       ` Ulf Hansson
2022-03-31 18:29       ` Janusz Krzysztofik
2022-03-31 18:29         ` Janusz Krzysztofik
2022-03-31 18:29         ` Janusz Krzysztofik
2022-03-10 23:33 ` [RFC PATCH 3/4] " Janusz Krzysztofik
2022-03-10 23:33   ` Janusz Krzysztofik
2022-03-10 23:33 ` [RFC RFT PATCH 4/4] ARM: OMAP1: clock: Convert " Janusz Krzysztofik
2022-03-10 23:33   ` Janusz Krzysztofik
2022-03-12  8:14 ` [RFC RFT PATCH 0/4] " Tony Lindgren
2022-03-12  8:14   ` Tony Lindgren
2022-03-19 18:49   ` Aaro Koskinen
2022-03-19 18:49     ` Aaro Koskinen
2022-03-19 21:21     ` Aaro Koskinen
2022-03-19 21:21       ` Aaro Koskinen
2022-03-20  0:15       ` Janusz Krzysztofik
2022-03-20  0:15         ` Janusz Krzysztofik
2022-03-21  8:01   ` Arnd Bergmann
2022-03-21  8:01     ` Arnd Bergmann

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=20220322163646.GD297526@darkstar.musicnaut.iki.fi \
    --to=aaro.koskinen@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=balbi@kernel.org \
    --cc=broonie@kernel.org \
    --cc=deller@gmx.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jmkrzyszt@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=peter.ujfalusi@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tony@atomide.com \
    --cc=ulf.hansson@linaro.org \
    /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.