linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Marek Belisko <marek@goldelico.com>,
	robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	bcousson@baylibre.com, linux@arm.linux.org.uk,
	plagnioj@jcrosoft.com, grant.likely@linaro.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org, hns@goldelico.com,
	Paul Walmsley <paul@pwsan.com>, Tero Kristo <t-kristo@ti.com>
Subject: Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
Date: Thu, 13 Nov 2014 10:28:49 -0800	[thread overview]
Message-ID: <20141113182848.GQ26481@atomide.com> (raw)
In-Reply-To: <5464969F.30708@ti.com>

* Tomi Valkeinen <tomi.valkeinen@ti.com> [141113 03:33]:
> On 12/11/14 17:02, Tony Lindgren wrote:
> 
> >> And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
> >> places in the kernel. I wonder if adding a pinmux entry for it could
> >> cause some rather odd problems.
> > 
> > They can all use pinctrl-single no problem.
> 
> Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux,
> and we have code in mach-omap2 that also touch DEVCONF1, without any
> knowledge (and locking) between those...

Hmm yeah the McBSP clock mux could be racy as the mux register for
McBSP is treated as a clock. This register muxes the clock between
external pin and internal clock. Considering that this should be
selectable at board level as the external clock probably needs to be
used if level shifters are being used, it should be really handled by
pinctrl-single.

The other use for hsmmc.c and pdata-quirks.c for the one time mux for
MMC clock from the MMC clock pin. That can be done with pinctrl-single
from the MMC driver too for DT based booting.

Then we just have the save and restore of the registers for
off-idle.
 
> So _maybe_ that's not an issue, as the pinmux config we have here is
> fixed, and done once at boot time, and maybe the code in mach-omap2 that
> touch DEVCONF1 is also ran just once and not at the same time as the
> pinmux. But I don't know if that's so.

It seems we could just do a read-only check for McBSP in the clock
code for the mux register, or even completely drop that code from
cclock3xxx_data.c and start using the pinctrl for that mux.

Paul & Tero, got any comments here?

Regards,

Tony

  reply	other threads:[~2014-11-13 18:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-03 21:59 [PATCH 0/4] omapdss: Add video output support for gta04 board Marek Belisko
2014-11-03 21:59 ` [PATCH 1/4] video: omapdss: Add opa362 driver Marek Belisko
2014-11-12 13:57   ` Tomi Valkeinen
2014-11-12 14:04     ` Belisko Marek
2014-11-03 21:59 ` [PATCH 2/4] Documentation: DT: Add documentation for ti,opa362 bindings Marek Belisko
2014-11-12 14:00   ` Tomi Valkeinen
2014-11-03 21:59 ` [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output Marek Belisko
2014-11-10 23:30   ` Tony Lindgren
2014-11-11  7:41     ` Tomi Valkeinen
2014-11-11 15:00       ` Tony Lindgren
2014-11-03 21:59 ` [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register Marek Belisko
2014-11-10 23:36   ` Tony Lindgren
2014-11-12 21:02     ` Belisko Marek
2014-11-12 21:23       ` Tony Lindgren
2014-11-12 12:53   ` Tomi Valkeinen
2014-11-12 15:02     ` Tony Lindgren
2014-11-13 11:31       ` Tomi Valkeinen
2014-11-13 18:28         ` Tony Lindgren [this message]
2014-11-13 22:59           ` Paul Walmsley
2014-11-13 23:58             ` Tony Lindgren
2014-11-14  7:32               ` Tero Kristo
2014-11-14 18:01                 ` Tony Lindgren
2014-11-14 14:36               ` Grazvydas Ignotas
2014-11-14 15:58                 ` 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=20141113182848.GQ26481@atomide.com \
    --to=tony@atomide.com \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=hns@goldelico.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marek@goldelico.com \
    --cc=mark.rutland@arm.com \
    --cc=paul@pwsan.com \
    --cc=pawel.moll@arm.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=robh+dt@kernel.org \
    --cc=t-kristo@ti.com \
    --cc=tomi.valkeinen@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).