2017-05-30 18:21 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@xxxxxxxxxxxxx>:
>> > +static const struct uniphier_tm_soc_data uniphier_pxs2_tm_data = {
>> > + .map_base = 0xe000,
>> > + .block_base = 0xe000,
>> > + .tmod_setup_addr = 0xe904,
>> > +};
>> > +
>> > +static const struct uniphier_tm_soc_data uniphier_ld20_tm_data = {
>> > + .map_base = 0xe000,
>> > + .block_base = 0xe800,
>> > + .tmod_setup_addr = 0xe938,
>>
>> Shouldn't these be in your device tree using the register properties?
>> I see at least the map base as possible to be done in DT.
True for simple-bus.
However, the combination of "simple-mfd" and "syscon"
seems a well established strategy when
registers are mixed/interleaved in a syscon block.
(For example, chip-control@ea0000 node of
arch/arm/boot/dts/berlin2.dtsi)
> I think so.
> However, the iomap of this device are included in sysctrl(simple-mfd),
> and I can't find the method to express offset from base-address of sysctrl
> on DT, instead of map_base, in resonable way.
>
> I think that mfd node has register property then the lower node of mfd,
> that is the thermal node, can't have register property.
>
> If the driver gets offset address from DT, I'll define new property
> like 'socionext,reg_offset' in the thermal node. But I'm not sure that.
socionext,uniphier-{pxs2,ld20}-thermal is an SoC-specific compatible string.
The internal-offset is included
in the HW-spec associated with the compatible.
I believe 'socionext,reg_offset' is pointless.
--
Best Regards
Masahiro Yamada
--
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
