Hi Niklas,
On Fri, Jan 5, 2018 at 1:24 PM, Niklas Söderlund
<niklas.soderlund@xxxxxxxxxxxx> wrote:
> On 2018-01-05 09:47:11 +0100, Geert Uytterhoeven wrote:
>> On Thu, Jan 4, 2018 at 10:31 PM, Niklas Söderlund
>> <niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
>> > To be able to read fused calibration values from hardware the size of
>> > the register resource of TSC1 needs to be incremented to cover one more
>> > register which holds the information if the calibration values have been
>> > fused or not.
>> >
>> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
>>
>> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>>
>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > @@ -2385,7 +2385,7 @@
>> >
>> > tsc: thermal@e6198000 {
>> > compatible = "renesas,r8a7795-thermal";
>> > - reg = <0 0xe6198000 0 0x68>,
>> > + reg = <0 0xe6198000 0 0x6c>,
>>
>> Perhaps we should just make it 0x100?
>> I'd be very surprised if that would be smaller than the granularity of the
>> address decoder circuitry.
>
> I have no problem with making it 0x100, looking at r8a7795.dtsi it seems
> we are mixing what we do today. For example the i2c nodes are defined
> with a precise size less then 0x100 while the USB-DMAC nodes uses a size
> of 0x100 while the size in the documentation is less then 0x100. Maybe
> we should define how we should handle cases like this and update the
> existing DT files?
>
> Do you think I should make all thermal registers 0x100 and not just TSC1
> and resend?
I think that makes sense.
Granularities below PAGE_SIZE can't be enforced well anyway
(Hi, gpio5/6/7 virtualization!).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
