From: Stephen Boyd <sboyd@codeaurora.org> To: Mike Turquette <mturquette@linaro.org> Cc: Saravana Kannan <skannan@codeaurora.org>, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers Date: Thu, 15 Aug 2013 18:31:19 -0700 [thread overview] Message-ID: <20130816013118.GC27999@codeaurora.org> (raw) In-Reply-To: <20130815050226.4443.39100@quantum> On 08/14, Mike Turquette wrote: > Quoting Stephen Boyd (2013-08-12 22:48:39) > > On 08/12, Mike Turquette wrote: > > > Quoting Stephen Boyd (2013-07-24 17:43:31) > > > > In similar fashion as of_regulator_match() add an of_clk_match() > > > > function that finds an initializes clock init_data structs from > > > > devicetree. Drivers should use this API to find clocks that their > > > > device is providing and then iterate over their match table > > > > registering the clocks with the init data parsed. > > > > > > > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > > > > > > Stephen, > > > > > > In general I like this approach. Writing real device drivers for clock > > > controllers is The Right Way and of_clk_match helps. > > > > > > Am I reading this correctly that the base register addresses/offsets for > > > the clock nodes still come from C files? For example I still see > > > pll8_desc defining reg stuff in drivers/clk/msm/gcc-8960.c. > > > > I think we may be able to put the registers in DT but I don't > > know why we need to do that if we're already matching up nodes > > with C structs. > > The reason to do so is to remove the per-clock data from the kernel > sources entirely. Separating logic and data. Ok. > > > It also made me want to introduce devm_of_iomap() > > which just seemed wrong (if you have a dev struct why can't you > > use devm_ioremap()). > > [snip] > > > > This is great for making the kernel DT-data-driven, but I > > couldn't find any other driver that was describing register level > > details in DT. > > Yeah, this sucks. Building a binding from a C struct is a bad idea. How > many permutations are there? Hopefully some clocks use the same bit > shifts and have reliable register offsets, with the only difference > being base address. If this is the case then a compatible string could > be done for each permutation assuming that number is low and manageable. In the multimedia controller almost every clock has a different register layout. Making a compatible string for each clock is pretty much what I've done if you consider that I match up the name of the node to a struct instead of matching a compatible string to a struct. In the global controller it's more sane, following a single register layout per compatible string. Remember though, all the single bit clocks (gates or what we call branches) have a completely random location for their on/off bit and status bit. > > > > > The good news is that newer clock controllers follow a standard > > and so we can specify one or two register properties and the type > > of clock and we're pretty much done. The software interface > > hasn't been randomized like on earlier controllers and bits > > within registers are always the same. > > This does not suck. Just for the sake of argument let's say that you > only had to deal with this new and improved register layout and not the > old (current) stuff. Do you still see a reason to match DT data up with > C struct data objects in the kernel? I would still need to match up frequency tables unless I figure out a way to put that in DT too. > > > We still have some clocks > > that are just on/off switches though and so we'll have to put > > register level details like which bit turns that clock on in DT > > (which I believe is not preferred/allowed?). I don't see any way > > to avoid that if we want it to be entirely DT driven. > > This is what I'm doing for the generic clock bindings. No one has > screamed over that stuff so I guess rules were meant to be broken. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v1 03/14] clk: Add of_clk_match() for device drivers Date: Thu, 15 Aug 2013 18:31:19 -0700 [thread overview] Message-ID: <20130816013118.GC27999@codeaurora.org> (raw) In-Reply-To: <20130815050226.4443.39100@quantum> On 08/14, Mike Turquette wrote: > Quoting Stephen Boyd (2013-08-12 22:48:39) > > On 08/12, Mike Turquette wrote: > > > Quoting Stephen Boyd (2013-07-24 17:43:31) > > > > In similar fashion as of_regulator_match() add an of_clk_match() > > > > function that finds an initializes clock init_data structs from > > > > devicetree. Drivers should use this API to find clocks that their > > > > device is providing and then iterate over their match table > > > > registering the clocks with the init data parsed. > > > > > > > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> > > > > > > Stephen, > > > > > > In general I like this approach. Writing real device drivers for clock > > > controllers is The Right Way and of_clk_match helps. > > > > > > Am I reading this correctly that the base register addresses/offsets for > > > the clock nodes still come from C files? For example I still see > > > pll8_desc defining reg stuff in drivers/clk/msm/gcc-8960.c. > > > > I think we may be able to put the registers in DT but I don't > > know why we need to do that if we're already matching up nodes > > with C structs. > > The reason to do so is to remove the per-clock data from the kernel > sources entirely. Separating logic and data. Ok. > > > It also made me want to introduce devm_of_iomap() > > which just seemed wrong (if you have a dev struct why can't you > > use devm_ioremap()). > > [snip] > > > > This is great for making the kernel DT-data-driven, but I > > couldn't find any other driver that was describing register level > > details in DT. > > Yeah, this sucks. Building a binding from a C struct is a bad idea. How > many permutations are there? Hopefully some clocks use the same bit > shifts and have reliable register offsets, with the only difference > being base address. If this is the case then a compatible string could > be done for each permutation assuming that number is low and manageable. In the multimedia controller almost every clock has a different register layout. Making a compatible string for each clock is pretty much what I've done if you consider that I match up the name of the node to a struct instead of matching a compatible string to a struct. In the global controller it's more sane, following a single register layout per compatible string. Remember though, all the single bit clocks (gates or what we call branches) have a completely random location for their on/off bit and status bit. > > > > > The good news is that newer clock controllers follow a standard > > and so we can specify one or two register properties and the type > > of clock and we're pretty much done. The software interface > > hasn't been randomized like on earlier controllers and bits > > within registers are always the same. > > This does not suck. Just for the sake of argument let's say that you > only had to deal with this new and improved register layout and not the > old (current) stuff. Do you still see a reason to match DT data up with > C struct data objects in the kernel? I would still need to match up frequency tables unless I figure out a way to put that in DT too. > > > We still have some clocks > > that are just on/off switches though and so we'll have to put > > register level details like which bit turns that clock on in DT > > (which I believe is not preferred/allowed?). I don't see any way > > to avoid that if we want it to be entirely DT driven. > > This is what I'm doing for the generic clock bindings. No one has > screamed over that stuff so I guess rules were meant to be broken. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2013-08-16 1:31 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-25 0:43 [PATCH v1 00/14] Add support for MSM's mmio clocks Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 01/14] clk: fixed-rate: Export clk_fixed_rate_register() Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-08-03 3:32 ` Mike Turquette 2013-08-03 3:32 ` Mike Turquette 2013-07-25 0:43 ` [PATCH v1 02/14] clk: Add of_init_clk_data() to parse common clock bindings Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 8:21 ` Tomasz Figa 2013-07-25 8:21 ` Tomasz Figa 2013-07-25 16:36 ` Stephen Boyd 2013-07-25 16:36 ` Stephen Boyd 2013-08-03 1:06 ` Mike Turquette 2013-08-03 1:06 ` Mike Turquette 2013-07-25 0:43 ` [PATCH v1 03/14] clk: Add of_clk_match() for device drivers Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 8:12 ` Tomasz Figa 2013-07-25 8:12 ` Tomasz Figa 2013-07-25 16:36 ` Stephen Boyd 2013-07-25 16:36 ` Stephen Boyd 2013-08-12 20:23 ` Mike Turquette 2013-08-12 20:23 ` Mike Turquette 2013-08-13 5:48 ` Stephen Boyd 2013-08-13 5:48 ` Stephen Boyd 2013-08-15 5:02 ` Mike Turquette 2013-08-15 5:02 ` Mike Turquette 2013-08-16 1:31 ` Stephen Boyd [this message] 2013-08-16 1:31 ` Stephen Boyd 2013-08-16 3:44 ` Mike Turquette 2013-08-16 3:44 ` Mike Turquette 2013-08-16 16:43 ` Kumar Gala 2013-08-16 16:43 ` Kumar Gala 2013-08-16 17:16 ` Kumar Gala 2013-08-16 17:16 ` Kumar Gala 2013-07-25 0:43 ` [PATCH v1 04/14] clk: Add set_rate_and_parent() op Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 8:26 ` Tomasz Figa 2013-07-25 8:26 ` Tomasz Figa 2013-07-25 8:26 ` Tomasz Figa 2013-07-25 16:45 ` Stephen Boyd 2013-07-25 16:45 ` Stephen Boyd 2013-08-09 5:32 ` Mike Turquette 2013-08-09 5:32 ` Mike Turquette 2013-08-09 9:11 ` James Hogan 2013-08-09 9:11 ` James Hogan 2013-08-09 9:11 ` James Hogan 2013-07-25 0:43 ` [PATCH v1 05/14] clk: msm: Add support for phase locked loops (PLLs) Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 8:29 ` Tomasz Figa 2013-07-25 8:29 ` Tomasz Figa 2013-07-25 16:37 ` Stephen Boyd 2013-07-25 16:37 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 06/14] clk: msm: Add support for root clock generators (RCGs) Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 07/14] clk: msm: Add support for branches/gate clocks Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 08/14] clk: msm: Add MSM clock driver Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 8:32 ` Tomasz Figa 2013-07-25 8:32 ` Tomasz Figa 2013-07-25 16:40 ` Stephen Boyd 2013-07-25 16:40 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 09/14] clk: msm: Add support for MSM8960's global clock controller (GCC) Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-08-08 17:00 ` Mark Rutland 2013-08-08 17:00 ` Mark Rutland 2013-08-08 17:00 ` Mark Rutland 2013-08-13 5:03 ` Stephen Boyd 2013-08-13 5:03 ` Stephen Boyd 2013-08-13 5:03 ` Stephen Boyd 2013-08-13 14:24 ` Mike Turquette 2013-08-13 14:24 ` Mike Turquette 2013-08-13 14:24 ` Mike Turquette 2013-08-13 18:42 ` Stephen Boyd 2013-08-13 18:42 ` Stephen Boyd 2013-08-13 18:42 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 10/14] clk: msm: Add support for MSM8960's multimedia clock controller (MMCC) Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-08-08 17:02 ` Mark Rutland 2013-08-08 17:02 ` Mark Rutland 2013-08-08 17:02 ` Mark Rutland 2013-07-25 0:43 ` [PATCH v1 11/14] ARM: dts: msm: Add MSM8960 GCC DT nodes Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 12/14] ARM: dts: msm: Add MSM8960 MMCC " Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 13/14] clk: msm: Add MSM8974 GCC data Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd 2013-07-25 0:43 ` [PATCH v1 14/14] ARM: dts: msm: Add clock entries for MSM8960 uart device Stephen Boyd 2013-07-25 0:43 ` Stephen Boyd
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=20130816013118.GC27999@codeaurora.org \ --to=sboyd@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mturquette@linaro.org \ --cc=skannan@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: linkBe 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.