Re: [PATCH] arm64: dts: r8a7795: Correct SATA device size to 2MiB

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

 



Hi Geert,

On Tue, Mar 21, 2017 at 6:30 PM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> Hi Magnus,
>
> On Tue, Mar 21, 2017 at 8:17 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>> On Mon, Mar 20, 2017 at 7:57 PM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>>> On Mon, Mar 20, 2017 at 9:49 AM, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
>>>> --- 0001/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> +++ work/arch/arm64/boot/dts/renesas/r8a7795.dtsi       2017-03-20 17:41:36.390607110 +0900
>>>> @@ -1209,7 +1209,7 @@
>>>>
>>>>                 sata: sata@ee300000 {
>>>>                         compatible = "renesas,sata-r8a7795";
>>>> -                       reg = <0 0xee300000 0 0x1fff>;
>>>> +                       reg = <0 0xee300000 0 0x200000>;
>>>
>>> While the datasheet does mention the 2 MiB area, it also says no (write)
>>> access should be made to registers not listed in the table, while these are
>>> all covered by the existing area?
>>
>> That bit about not writing to non-listed registers seems like just
>> common sense to me, but perhaps there is more to the story than just
>
> Sure.
>
>> that? Like you say it is probably possible to use the driver with the
>> existing 8K-1 size, but in my mind we should use window sizes defined
>> in the data sheet for DT?
>
> The 2 MiB window size is a lot larger than needed to cover all documented
> rregisters. Either there are more undocumented registers, or the hardware
> engineers were lazy and just decoded the full 2 MiB block.

Yeah, and on top of that it looks to me like the size is not aligned
to the offset either. I would expect a 2MiB block to be aligned to a
2MiB boundary...

>>> BTW, what about the Reference Clock Source Select Register, which lies
>>> in a further undocumented area?
>>
>> Yeah, no idea. This would be good task for the I/O or Core group to
>
> SATA is I/O.

For sure, however I wonder how the external clock register REFSEL is
supposed to be handled. It looks like an external hardware block
somehow.

>> figure out how to handle. I'm surprised that the SATA DT device nodes
>> with the strange and incorrect 0x1fff size got merged upstream without
>> anyone thinking about that register that you are mentioning. Seems
>> like supporting that should be part of SATA development for R-Car
>> Gen3?
>
> Probably it was just an oversight. I almost missed it myself when
> reviewing your patch.

Probably yes.

> The register is not present (not documented) on R-Car H1 and Gen2.
> The IP core is derived from SH-Navi2G (sh7775), but no datasheet.

On R-Car Gen3 there seem to be a chance that random glue hardware for
other devices may also be present in the 0xe65exxxx range however
documentations seem to be lacking...

/ magnus



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux