From: Stephen Warren <swarren@wwwdotorg.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Thomas Abraham <thomas.abraham@linaro.org>,
Tomasz Figa <tomasz.figa@gmail.com>,
Tomasz Figa <t.figa@samsung.com>,
Kukjin Kim <kgene.kim@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Prathyush <prathyush.k@samsung.com>,
Prashanth G <prashanth.g@samsung.com>,
Olof Johansson <olofj@chromium.org>,
Simon Glass <sjg@chromium.org>,
Katie Roberts-Hoffman <katierh@chromium.org>,
Jaehoon Chung <jh80.chung@samsung.com>,
Seungwon Jeon <tgih.jun@samsung.com>,
Will Newton <will.newton@gmail.com>
Subject: Re: State of pinctrl and exynos5250?
Date: Thu, 07 Mar 2013 15:38:53 -0700 [thread overview]
Message-ID: <513916FD.3050906@wwwdotorg.org> (raw)
In-Reply-To: <CAD=FV=V0x9kz9BhHnJUT6FUN6u2n9NMZX0mCJZEmaFxXObx3Mg@mail.gmail.com>
On 03/07/2013 09:27 AM, Doug Anderson wrote:
> +the proper address for Will. Sorry...
>
>
> On Thu, Mar 7, 2013 at 8:13 AM, Doug Anderson <dianders@chromium.org
> <mailto:dianders@chromium.org>> wrote:
>
> Linus,
>
> +dw_mmc folks and Stephen Warren : for context here, we are discussing
> device tree bindings for pinmux for dw_mmc. The issue at hand is
> whether they belong under the slot node or under the top-level device
> node.
There's no need for dynamic pin-muxing for MMC AFAIK, so I'd expect a
single pinctrl state "default" to exist that covers any/all requirements
of both slots' pinmux configuration.
> On Wed, Mar 6, 2013 at 11:57 PM, Linus Walleij
> <linus.walleij@linaro.org <mailto:linus.walleij@linaro.org>> wrote:
> > I don't quite understand the above. Is it such that there is one
> device,
> > with two slots, and in the device model you have represented this
> > two-slot device with a single struct device?
>
> Yes, that's the issue. That's dw_mmc that has been in the kernel for
> a bit of time now (looks like Jan 2011) and has had a single struct
> device for as long as I've been looking at it.
>
> Relevant links for convenience:
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/dw_mmc.c
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos5250.dtsi#n243
> *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/cros5250-common.dtsi#n92
>
>
> > Have you considered just registering one device for each slot?
> >
> > That would make things quite a lot simpler, just a single pinctrl
> > handle per device, right?
>
> I don't know why the original decision was made to just have one
> struct device. ...that would be a pretty big code change at this
> point, I think.
>
> ...I think the most important issue at hand is the device tree
> bindings for pinmux on this device. It sounds like you are in
> agreement that the best thing is to have a pinmux specified per-slot.
> If the code is a bit awkward now (due to not having a struct device
> per slot) then that's just something we have to live with.
>
>
> -Doug
>
>
next prev parent reply other threads:[~2013-03-07 22:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-02 0:19 State of pinctrl and exynos5250? Doug Anderson
2013-03-02 11:48 ` Tomasz Figa
2013-03-04 14:04 ` Thomas Abraham
2013-03-05 23:50 ` Doug Anderson
2013-03-06 0:01 ` Thomas Abraham
2013-03-06 1:06 ` Doug Anderson
2013-03-05 23:29 ` Doug Anderson
2013-03-05 23:49 ` Thomas Abraham
2013-03-06 1:00 ` Doug Anderson
2013-03-07 7:57 ` Linus Walleij
2013-03-07 16:13 ` Doug Anderson
[not found] ` <CAD=FV=V0x9kz9BhHnJUT6FUN6u2n9NMZX0mCJZEmaFxXObx3Mg@mail.gmail.com>
2013-03-07 22:38 ` Stephen Warren [this message]
2013-03-08 2:04 ` Linus Walleij
2013-03-08 4:55 ` Doug Anderson
2013-03-05 23:56 ` Kukjin Kim
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=513916FD.3050906@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=dianders@chromium.org \
--cc=jh80.chung@samsung.com \
--cc=katierh@chromium.org \
--cc=kgene.kim@samsung.com \
--cc=linus.walleij@linaro.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=olofj@chromium.org \
--cc=prashanth.g@samsung.com \
--cc=prathyush.k@samsung.com \
--cc=sjg@chromium.org \
--cc=t.figa@samsung.com \
--cc=tgih.jun@samsung.com \
--cc=thomas.abraham@linaro.org \
--cc=tomasz.figa@gmail.com \
--cc=will.newton@gmail.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.