linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Paul Osmialowski <pawelo@king.net.pl>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] add devm_of_clk_get() and devm_of_clk_get_by_name() functions
Date: Thu, 1 Oct 2015 11:03:57 -0700	[thread overview]
Message-ID: <20151001180357.GG19319@codeaurora.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1510010943400.25759@localhost.localdomain>

On 10/01, Paul Osmialowski wrote:
> Hi Stephen,
> 
> On Wed, 30 Sep 2015, Stephen Boyd wrote:
> 
> > In the pinctrl node we would have
> > 
> >  	pinctrl {
> >  		compatible = "fsl,kenetis70-pinctrl";
> >  		reg = <0x40049000 0x2000>;
> >  		clocks = <&sim SIM_CLK_SCGC5_PORTA>, <&sim SIM_CLK_SCGC5_PORTB>;
> > 
> > 		uart_default: uart_default {
> > 			mux {
> > 				pins = "porta_3", "portb_2";
> > 				function = "uart";
> > 			};
> > 
> > 			rx {
> > 				bias-pull-pin-default;
> > 			};
> > 		};
> >  	};
> > 
> > And then in the uart node we would have
> > 
> > 	uart@f00000 {
> > 		compatible = "vendor,uart";
> > 		reg = <0xf00000 0x100>;
> > 		pinctrl-names = "default";
> > 		pinctrl-0 = <&uart_default>;
> > 	};
> > 
> 
> Seems like there's another thing I wanted to avoid. The correctness of 
> these pin strings will not be checked until the runtime. They need to 
> properly encode pin bank and pin number within the bank. No chances it can 
> be validated at .dtb build time. But I guess this is proper way for 
> generic pinctrl bindings. I mostly (but not completely) based my approach 
> on rockchip examples (e.g. rk3288) but it looks like they are not entirely 
> sane.

I don't see how it could be validated with the <&port pin
function config> binding either. Let's hope that people test
their code, including whatever dts files they produce.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-10-01 18:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24  8:03 [PATCH 0/1] add devm_of_clk_get() and devm_of_clk_get_by_name() functions Paul Osmialowski
2015-09-24  8:03 ` [PATCH 1/1] clk: " Paul Osmialowski
2015-09-28 23:13   ` Stephen Boyd
2015-09-28 23:05 ` [PATCH 0/1] " Stephen Boyd
2015-09-29  4:45   ` Paul Osmialowski
2015-09-30 22:04     ` Stephen Boyd
2015-10-01  7:52       ` Paul Osmialowski
2015-10-01 18:03         ` Stephen Boyd [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-09-30  7:46 Paul Osmialowski

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=20151001180357.GG19319@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=pawelo@king.net.pl \
    /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).