From: Tony Lindgren <tony@atomide.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: Adam Ford <aford173@gmail.com>,
bcousson@baylibre.com, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, linux-omap@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"H. Nikolaus Schaller" <hns@goldelico.com>
Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage
Date: Mon, 16 Jan 2023 18:56:24 +0200 [thread overview]
Message-ID: <Y8WBuKt6mw6TN1Cp@atomide.com> (raw)
In-Reply-To: <20230116173922.585904bf@aktux>
* Andreas Kemnade <andreas@kemnade.info> [230116 16:39]:
> On Mon, 16 Jan 2023 16:51:57 +0200
> Tony Lindgren <tony@atomide.com> wrote:
>
> > Hi,
> >
> > * Adam Ford <aford173@gmail.com> [230116 14:16]:
> > > Would it make sense to make this default in the omap3.dtsi file and
> > > enable them in the individual boards that need it?
> >
> > In general disabling the unused devices by default for omaps will break
> > the power management. The disabled devices are completely ignored by the
> > kernel, and the devices are left to whatever the bootloader state might
> > be.
> >
> hmm, shouldn't ti-sysc keep things disabled in most cases? It is still a bit
> known because there is no status = "disabled" in the target-module@xxx node.
Oh right, if the child device is tagged disabled (instead of the the parent
ti-sysc tagged disabled) the module should get idled just fine as long as the
module related quirks are implemented for ti-sysc.c.
But still, I'd rather not start tagging devices disabled by default and then
re-enabling everywhere since we never needed it before. It just adds a lot
of pointless status tinkering, see commit 12afc0cf8121 ("ARM: dts: Drop
pointless status changing for am3 musb").
So considering things, IMO it's best to set only the child device with
status disabled, and set it at the board specific dts file in this case.
Also note that the dma channels could be freed with /delete-property/ at the
board specific dts file even for devices that are usable if not really
needed.
Regards,
Tony
next prev parent reply other threads:[~2023-01-16 17:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 21:11 [PATCH] ARM: dts: gta04: fix excess dma channel usage Andreas Kemnade
2023-01-16 14:16 ` Adam Ford
2023-01-16 14:51 ` Tony Lindgren
2023-01-16 15:29 ` H. Nikolaus Schaller
2023-01-16 17:00 ` Tony Lindgren
2023-01-16 16:39 ` Andreas Kemnade
2023-01-16 16:56 ` Tony Lindgren [this message]
2023-01-16 17:00 ` Adam Ford
2023-01-16 17:08 ` Tony Lindgren
2023-01-19 7:30 ` Tony Lindgren
2023-01-22 9:08 ` Andreas Kemnade
2024-11-07 9:35 ` Andreas Kemnade
2023-03-27 8:13 ` Tony Lindgren
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=Y8WBuKt6mw6TN1Cp@atomide.com \
--to=tony@atomide.com \
--cc=aford173@gmail.com \
--cc=andreas@kemnade.info \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=hns@goldelico.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh+dt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox