Hi Geert,
On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote:
> > So I see what the mediatek is doing, but I can't seem to reproduce it.
> I
> > must be missing something.
>
> It's using CLK_OF_DECLARE_DRIVER(), which clears OF_POPULATED:
Yup, that's what I was missing.
Works now.
Hi Chris,
On Tue, Sep 18, 2018 at 5:52 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote:
> > > What do you see the .dtsi and .dts looking like?
> >
> > The part using CLK_OF_DECLARE() is not a platform driver. It does not
> > operate on a device (struct
Hi Geert,
On Tuesday, September 18, 2018 1, Geert Uytterhoeven wrote:
> > What do you see the .dtsi and .dts looking like?
>
> The part using CLK_OF_DECLARE() is not a platform driver. It does not
> operate on a device (struct platform_device), but on a device node
> (struct
> device_node).
Hi Chris,
On Tue, Sep 18, 2018 at 5:04 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018, Geert Uytterhoeven wrote:
> > Then the early init from CLK_OF_DECLARE() will just register the
> > early clocks, and cpg_mssr_probe() can take care of the remaining parts?
>
> What is not clear to me
Hi Geert,
On Tuesday, September 18, 2018, Geert Uytterhoeven wrote:
> Then the early init from CLK_OF_DECLARE() will just register the
> early clocks, and cpg_mssr_probe() can take care of the remaining parts?
What is not clear to me is what goes in DT
I will have this in .dtsi for
Hi Chris,
On Tue, Sep 18, 2018 at 1:55 PM Chris Brandt wrote:
> On Tuesday, September 18, 2018, linux-renesas-soc-ow...@vger.kernel.org wrote:
> > > I've coded this up and it works fine.
> >
> > While I don't doubt this works fine, your DT is no longer describing
> > hardware, but also software
Hi Geert,
On Tuesday, September 18, 2018, linux-renesas-soc-ow...@vger.kernel.org wrote:
> > I've coded this up and it works fine.
>
> While I don't doubt this works fine, your DT is no longer describing
> hardware, but also software policy.
>
> I think the proper solution, maximizing code
Hi Chris,
CC linux-clk
On Mon, Sep 17, 2018 at 8:57 PM Chris Brandt wrote:
> On Friday, September 14, 2018, Geert Uytterhoeven wrote:
> > > Just FYI, for the heck of it, I tried and hacked in registering the
> > > clock driver using CLK_OF_DECLARE since that happens before the
> > >
On Friday, September 14, 2018, Geert Uytterhoeven wrote:
> > Just FYI, for the heck of it, I tried and hacked in registering the
> > clock driver using CLK_OF_DECLARE since that happens before the
> > TIMER_OF_DECLARE timers are probed.
> >
> > But, I got this result:
> >
> > [0.00] Driver
Hi Chris,
On Thu, Sep 13, 2018 at 4:54 PM Chris Brandt wrote:
> On Thursday, September 13, 2018, Geert Uytterhoeven wrote:
> > > > I wonder they just didn't make a clock_initcall() and timer_initcall()
> > > > instead.
> > >
> > > What happens if you place the clk_init() before board_time_init()
Hi Daniel,
On Thu, Sep 13, 2018 at 3:17 PM Daniel Lezcano
wrote:
> On 11/09/2018 20:42, Chris Brandt wrote:
> > On Tuesday, September 11, 2018 1, Rob Herring wrote:
> >> Well before we get to initcalls, the kernel calls the arch specific
> >> time_init() which (on ARM) calls of_clk_init (for all
On 11/09/2018 20:42, Chris Brandt wrote:
> On Tuesday, September 11, 2018 1, Rob Herring wrote:
>> Well before we get to initcalls, the kernel calls the arch specific
>> time_init() which (on ARM) calls of_clk_init (for all the reasons
>> above) and then timer_probe(). When timer_probe returns, it
On Tuesday, September 11, 2018 1, Rob Herring wrote:
> Well before we get to initcalls, the kernel calls the arch specific
> time_init() which (on ARM) calls of_clk_init (for all the reasons
> above) and then timer_probe(). When timer_probe returns, it is
> expected that you have setup a
On Mon, Sep 10, 2018 at 12:20 PM Chris Brandt wrote:
>
> On Monday, September 10, 2018, Rob Herring wrote:
> > > The current OSTM driver uses TIMER_OF_DECLARE and that basically means
> > > it will never work with my new SoC.
> > >
> > > For now, can I change the driver to register a standard
On Monday, September 10, 2018, Rob Herring wrote:
> > The current OSTM driver uses TIMER_OF_DECLARE and that basically means
> > it will never work with my new SoC.
> >
> > For now, can I change the driver to register a standard platform driver
> > in subsys_initcall like the other Renesas timer
On Fri, Sep 7, 2018 at 10:16 AM Chris Brandt wrote:
>
> On Thursday, August 30, 2018, Daniel Lezcano wrote:
> > > AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
> > > IMHO it would be pointless, as it would be much easier to just switch to
> > real
> > > platform drivers.
>
On Thursday, August 30, 2018, Daniel Lezcano wrote:
> > AFAIK no attempt was done to support EPROBE_DEFER with *_OF_DECLARE.
> > IMHO it would be pointless, as it would be much easier to just switch to
> real
> > platform drivers.
>
> May be, may be not.
>
> From your point of view, the change
2018-08-30 11:16 GMT+02:00 Daniel Lezcano :
>
> [Added Arnd Bergmann, Bartosz Golaszewski and Mark Brown]
>
> On 30/08/2018 10:48, Geert Uytterhoeven wrote:
>> Hi Daniel,
>
> [ ... ]
>
>>> Yeah, I got this point. But it is the meaning of your sentence: "...
>>> which causes issues with complex
[Added Arnd Bergmann, Bartosz Golaszewski and Mark Brown]
On 30/08/2018 10:48, Geert Uytterhoeven wrote:
> Hi Daniel,
[ ... ]
>> Yeah, I got this point. But it is the meaning of your sentence: "...
>> which causes issues with complex dependencies.".
>>
>> It is ambiguous *what* causes the
Hi Daniel,
On Thu, Aug 30, 2018 at 10:37 AM Daniel Lezcano
wrote:
> On 30/08/2018 10:27, Geert Uytterhoeven wrote:
> > On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
> > wrote:
> >> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> >>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> >>>
On 30/08/2018 10:27, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
> wrote:
>> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
>>> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
>>> wrote:
On 29/08/2018 17:44, Chris Brandt wrote:
> On
Hi Daniel,
On Thu, Aug 30, 2018 at 10:09 AM Daniel Lezcano
wrote:
> On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> > On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> > wrote:
> >> On 29/08/2018 17:44, Chris Brandt wrote:
> >>> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> Can
On 30/08/2018 09:54, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
> wrote:
>> On 29/08/2018 17:44, Chris Brandt wrote:
>>> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
Can the boot constraints [1] solve this issue instead of the changes
Hi Daniel,
On Wed, Aug 29, 2018 at 6:26 PM Daniel Lezcano
wrote:
> On 29/08/2018 17:44, Chris Brandt wrote:
> > On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> >> Can the boot constraints [1] solve this issue instead of the changes you
> >> are proposing ?
> >>
> >> [1]
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> the boot order, it would be better.
>
> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> dependencies' [1]?
So I tried just returning -EPROBE_DEFER,
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>
> My concern is if we can avoid changing the TIMER_OF_DECLARE because of
> the boot order, it would be better.
>
> Can returning EPROBE_DEFER fix this issue? Or use the 'complex
> dependencies' [1]?
I'll try returning EPROBE_DEFER and see
On 29/08/2018 17:44, Chris Brandt wrote:
> On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
>> Can the boot constraints [1] solve this issue instead of the changes you
>> are proposing ?
>>
>> [1] https://lwn.net/Articles/747250/
>
> Thanks for the suggestion, but...
>
> I grepped for
On Wednesday, August 29, 2018 1, Daniel Lezcano wrote:
> Can the boot constraints [1] solve this issue instead of the changes you
> are proposing ?
>
> [1] https://lwn.net/Articles/747250/
Thanks for the suggestion, but...
I grepped for "boot_constraint" and it shows up nowhere in the current
On 29/08/2018 15:29, Chris Brandt wrote:
> The newer RZ/A clock control driver no longer registers all its clocks
> using DT, therefore the clocks required by this driver are no longer
> present at the beginning of boot.
>
> Because of this, TIMER_OF_DECLARE can no longer be used because this
>
29 matches
Mail list logo
