mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Osmialowski <pawelo@king.net.pl>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Osmialowski <pawelo@king.net.pl>
Subject: Re: [PATCH 0/1] add devm_of_clk_get() and devm_of_clk_get_by_name() functions
Date: Tue, 29 Sep 2015 06:45:24 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1509290611050.3931@localhost.localdomain> (raw)
In-Reply-To: <20150928230523.GR23081@codeaurora.org>

Hi Stephen,

Thanks for all of your comments.

On Mon, 28 Sep 2015, Stephen Boyd wrote:

> I'd say your binding is wrong. Either the container node
> "pinctrl" is a software concept that contains the two devices for
> port_a and port_b or there's only one pinctrl device that happens
> to span some number of 0x1000 size banks. The former would be
> written as so
> 
> 	pinctrl {
> 		compatible = "fsl,kenetis-pinctrl";
> 		reg = <0x40049000 0x2000>;
> 		clocks = <&sim SIM_CLK_SCGC5_PORTA>, <&sim SIM_CLK_SCGC5_PORTB>;
> 	};
>

I tried this and actually this looks similar to my first approach to this 
driver. I wasn't happy with the fact that pin banks are so loosely coupled 
with resources they use.

I thought that making pin controller a container for pin bank devices 
would create better coupling and simply look better in DT file.

With this first approach example pin definition would look like:

fsl,kinetis-pins = <PORT_A 0 1 &pcfg_pull_pin_default> ...

where the binding format is fsl,kinetis-pins = <bank pin function CONFIG>

&pcfg_pull_pin_default is defined as:

pcfg_pull_pin_default: pcfg-pull-pin-default {
	bias-pull-pin-default;
};

...and PORT_A would have to be defined as preprocessor macro in some 
header file:

#define PORT_A   0
#define PORT_B   1
#define PORT_C   2
#define PORT_D   3
#define PORT_E   4
#define PORT_F   5
#define PORT_NUM 6

That's another thing I'd want to avoid.

I wanted a DT file which driver could use to figure out how many pin banks 
there are, what clocks and IO ranges they use and how pins are associated 
with banks.

Now I see I pasted example from some old file (sorry for that), it differs 
in one small detail, so again:

pinctrl: pinctrl {
        compatible = "fsl,kinetis-pinctrl";
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;

        port_a: pin-bank@40049000 {
                compatible = "fsl,kinetis-pin-bank";
                reg = <0x40049000 0x1000>;
                clocks = <&sim SIM_CLK_SCGC5_PORTA>;
        };

        port_b: pin-bank@4004a000 {
                compatible = "fsl,kinetis-pin-bank";
                reg = <0x4004a000 0x1000>;
                clocks = <&sim SIM_CLK_SCGC5_PORTB>;
        };
...
};

Now, assuming use of of_find_node_by_phandle(), example pin definition 
would look like:

fsl,kinetis-pins = <&port_a 0 1 &pcfg_pull_pin_default> ...

Things are getting connected together, no preprocessor definitions, no 
extra header file. What can be wrong with this design?

I'll prepare second iteration with updated documentation (and other 
smaller cleanups) soon.

Thanks,
Paul

  reply	other threads:[~2015-09-29  4:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24  8:03 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 [this message]
2015-09-30 22:04     ` Stephen Boyd
2015-10-01  7:52       ` Paul Osmialowski
2015-10-01 18:03         ` Stephen Boyd
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=alpine.LNX.2.00.1509290611050.3931@localhost.localdomain \
    --to=pawelo@king.net.pl \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.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

all inboxes | Powered by JetHome®