Re: [PATCH v2] ARM: realview: basic device tree implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, May 29, 2014 at 12:10 PM, Sebastian Hesselbarth
<sebastian.hesselbarth@xxxxxxxxx> wrote:
> On 05/29/2014 11:44 AM, Linus Walleij wrote:

>> Hmmmm well I want to see that code before I believe it ... but
>> I get what you mean.
>
> Well, the register set on Berlin I was thinking about tackles pinctrl,
> padmux, clock, reset and some other freaky stuff I cannot recall. The
> mess in it is that there is no order you can apply to split it up into
> separate nodes. Moreover, the next SoC has some registers just shoved
> into it, moving some other registers.

Berlin hardware engineers seem to be hellbent on complicating
your life.

> The way we will go for it on Berlin is now:
>
> (a) have a single node for the whole chip-ctrl register set
> (b) register clk driver on it (early, as it provides timer clk)
> (c) register one chip-ctrl driver on it that will
>     (d) reserve the iomap,
>     (e) register a regmap-mmio,
>     (f) register platform_devices for {pinctrl,reset,...} that will
>         use regmap-mmio and read their properties from the single
>         node

OK makes perfect sense actually.

> The individual drivers should stay in their respective drivers/ folder,
> but (c) needs a good home. It would have been mach-foo in the past, and
> could be drivers/soc now. In (f), I tend to just lookup regmap by name,
> no DT involved at all.

OK

> BTW, syscon is of no use here at all, once it registers itself as a
> driver for the node, there will be no other drivers registered. That
> would at least require (again subsystem driven) dummy-nodes for
> pinctrl, clk, reset.

Yeah that sucks, we need something more flexible no question
about that.

Will the chipctrl driver be as generic as syscon or a
Berlin-specific thing?

> Also, using some of_xlate as we already have for clk, gpio, pinctrl ...
> would put an end to syscon's syscon_get_regmap_from_{foo,bar,baz,...}
> that gets a new helper every cycle.

This part I don't understand but I guess I will understand it
when I see the code.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux