Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1310828

Re: [PATCH v3 04/13] clk: at91: make IRQ optional and register them later

From Stephen Boyd <sboyd@codeaurora.org>
Newsgroups linux.kernel
Subject Re: [PATCH v3 04/13] clk: at91: make IRQ optional and register them later
Date 2016-01-16 02:30 +0100
Message-ID <qRnQK-5LG-21@gated-at.bofh.it> (permalink)
References <qC21Q-5zk-21@gated-at.bofh.it> <qC2bw-5CT-15@gated-at.bofh.it> <qR1ZU-7KT-5@gated-at.bofh.it> <qR91o-49P-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 01/15, Boris Brezillon wrote:
> Hi Stephen,
> 
> On Thu, 14 Jan 2016 18:02:37 -0800
> Stephen Boyd <sboyd@codeaurora.org> wrote:
> > 
> > Is there any way to get the irq into this probe function without
> > getting a clk pointer and then unwrapping it to get an irq
> > value out of the clk_hw wrapper structure? That's a pretty
> > convoluted design.
> 
> Not sure I get what you're suggesting, but the only solution I see to
> avoid this "get main clk pointer dance" would be to have a global
> variable storing the clk_main instance (or a list of clk_main
> instances).
> The thing is, I'd like to avoid adding new global variables in this
> clk drivers as much as possible. Moreover, the core is already taking
> care of keeping the list of all registered clks, with their associated
> of_node, so, is there a real point in creating a duplicated association
> list in this driver too?

Ok I have to admit I'm a little confused. I thought we were
getting the irq from the clkmain structure so that we could
request it here in the probe function. But we're really assigning
the irq so that we can enable/disable/free it later on?

So my new question is if we can register the clocks at the same
time as the "platform device" (really a clock) probes. The
correct design was probably to have pmc be a big platform device
and have it register clocks that it knows exist inside it based
on the compatible string. And it would also know which irqs (or
enforce some ordering of irqs) to assign to which clocks.

It looks like we totally missed that though.... so now we have
many DT nodes that are also platform devices. So if we can do it
at the same time as irq requests then we're good and the clk_hw
structure is in the same scope. If not, then we should probably
just let of_clk_hw_get_from_provider() happen (and it needs to
happen for other reasons anyway) and call it a day.

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

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: [PATCH v3 04/13] clk: at91: make IRQ optional and register them  later Stephen Boyd <sboyd@codeaurora.org> - 2016-01-16 02:30 +0100
  Re: [PATCH v3 04/13] clk: at91: make IRQ optional and register them  later Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-01-16 13:50 +0100
    Re: [PATCH v3 04/13] clk: at91: make IRQ optional and register them  later Stephen Boyd <sboyd@codeaurora.org> - 2016-01-20 23:10 +0100

csiph-web