[PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Christian Costa]

---
 rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
index 500cea9..e006dbe 100644
--- a/rnndb/memory/nvc0_pbfb.xml
+++ b/rnndb/memory/nvc0_pbfb.xml
@@ -49,23 +49,54 @@
 			Most bitfields are unknown.
 			</doc>
 		<bitfield high="7" low="0" name="RP">
-			<doc> RAS# precharge. </doc>
+			<doc> RAS# Precharge. </doc>
 		</bitfield>
 		<bitfield high="15" low="8" name="RAS">
-			<doc>Activate to precharge delay. </doc>
+			<doc> Activate to precharge delay. </doc>
 		</bitfield>
 		<bitfield high="23" low="16" name="RFC">
 			<doc> Refresh to activate delay. </doc>
 		</bitfield>
 		<bitfield high="31" low="24" name="RC">
-			<doc> Row cycle time. </doc>
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+	</reg32>
+
+	<reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
+		<doc> This, and the next 6 regs, are all related to memtimings.
+			A good place to read might be http://www.tweakers.fr/timings.html .
+			Most bitfields are unknown.
+			</doc>
+		<bitfield high="7" low="0" name="tRC">
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+		<bitfield high="15" low="8" name="tRFC">
+			<doc> Refresh to activate delay. </doc>
+		</bitfield>
+		<bitfield high="23" low="17" name="tRAS">
+			<doc> Activate to precharge delay. </doc>
+		</bitfield>
+		<bitfield high="31" low="24" name="tRCD">
+			<doc> RAS# to CAS# Delay. </doc>
 		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
+		<bitfield high="3" low="0" name="tCL">
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+		<bitfield high="13" low="7" name="tCWL">
+			<doc> CAS# Write Latency. </doc>
+		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
+		<bitfield high="15" low="8" name="tWTR">
+			<doc> Write To Read delay. </doc>
+		</bitfield>
+		<bitfield high="23" low="15" name="tWR">
+			<doc> Write Recovery time. </doc>
+		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">
-- 
1.9.1

[PATCH envytools] docs: Fix some spelling and remove some trailing spaces.

[Christian Costa]

---
 docs/hw/fifo/intro.rst | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/docs/hw/fifo/intro.rst b/docs/hw/fifo/intro.rst
index 8b1d69d..0e023bf 100644
--- a/docs/hw/fifo/intro.rst
+++ b/docs/hw/fifo/intro.rst
@@ -10,7 +10,7 @@ FIFO overview
 Introduction
 ============
 
-Commands to most of the engines are sent through a special engine caled PFIFO.
+Commands to most of the engines are sent through a special engine called PFIFO.
 PFIFO maintains multiple fully independent command queues, known as "channels"
 or "FIFO"s. Each channel is controlled through a "channel control area", which
 is a region of MMIO [pre-NVC0] or VRAM [NVC0+]. PFIFO intercepts all accesses
@@ -40,11 +40,11 @@ The engines that PFIFO controls on NV04:NVC0 are:
 == ========== =========================== =================================================== 
 Id Present on Name                        Description                                        
 == ========== =========================== =================================================== 
-0  all        SOFTWARE                    Not really an engine, causes interrupt for each    
-                                          command, can be used to execute driver functions   
-                                          in sync with other commands.                       
-1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.          
-2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.  
+0  all        SOFTWARE                    Not really an engine, causes interrupt for each
+                                          command, can be used to execute driver functions
+                                          in sync with other commands.
+1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
+2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
    NVA0:NVAA
 3  NV40:NV84  :ref:`PME <me-fifo>`        VPE motion estimation engine.
 4  NV41:NV84  :ref:`PVP1 <pvp1>`          VPE microcoded vector processor.
@@ -64,10 +64,10 @@ The engines that PFIFO controls on NVC0- are:
 ===== ========== =========================== =================================================== 
 Id    Present on Name                        Description                                        
 ===== ========== =========================== =================================================== 
-1f    all        SOFTWARE                    Not really an engine, causes interrupt for each    
-                                             command, can be used to execute driver functions   
-                                             in sync with other commands.                       
-0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.          
+1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
+                                             command, can be used to execute driver functions
+                                             in sync with other commands.
+0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
 1     all        :ref:`PVDEC <pvdec>`        falcon-based microcoded video decoder.
 2     all        :ref:`PPPP <pppp>`          falcon-based video post-processor.
 3     all        :ref:`PVLD <pvld>`          falcon-based variable length decoder.
@@ -93,7 +93,7 @@ The PFIFO can be split into roughly 4 pieces:
 - PFIFO puller: executes the commands, passes them to the proper engine,
   or to the driver.
 - PFIFO switcher: ticks out the time slices for the channels and saves /
-  restores the state of the channel between PFIFO registers and RAMFC
+  restores the state of the channels between PFIFO registers and RAMFC
   memory.
 
 A channel consists of the following:
@@ -133,7 +133,7 @@ is being submitted. See :ref:`nv03-pfifo-dma` for details.
 
 NV04 PFIFO greatly enhanced the DMA mode and made it controllable directly
 through the channel control area. Thus, commands can now be submitted by
-multiple applications simultanously, without coordination with each other
+multiple applications simultaneously, without coordination with each other
 and without kernel's help. DMA mode is described in :ref:`fifo-dma-pusher`.
 
 NV50 introduced IB mode. IB mode is a modified version of DMA mode that,
@@ -143,8 +143,8 @@ to stitch together parts of multiple memory areas into a single command stream
 memory written by earlier commands. IB mode is described along with DMA mode in
 :ref:`fifo-dma-pusher`.
 
-NVC0 rearchitected the whole PFIFO, made it possible to have up to 3 channels
-executing simultanously, and introduced a new DMA packet format.
+NVC0 rearchitectured the whole PFIFO, made it possible to have up to 3 channels
+executing simultaneously, and introduced a new DMA packet format.
 
 The commands, as stored in CACHE, are tuples of:
 
@@ -180,12 +180,12 @@ and engine-specific documentation.
 
 Pre-NV1A, PFIFO treats everything as little-endian. NV1A introduced big-endian
 mode, which affects pushbuffer/IB reads and semaphores. On NV1A:NV50 cards,
-the endian can be selected per channel via big_endian flag. On NV50+ cards,
+the endianness can be selected per channel via the big_endian flag. On NV50+ cards,
 PFIFO endianness is a global switch.
 
 .. todo:: look for NVC0 PFIFO endian switch
 
 The channel control area endianness is not affected by the big_endian flag or
-NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endian switch.
+NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endianness switch.
 
 .. todo:: is it still true for NVC0, with VRAM-backed channel control area?
-- 
1.9.1

Re: [PATCH envytools] docs: Fix some spelling and remove some trailing spaces.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   docs/hw/fifo/intro.rst | 32 ++++++++++++++++----------------
>   1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/docs/hw/fifo/intro.rst b/docs/hw/fifo/intro.rst
> index 8b1d69d..0e023bf 100644
> --- a/docs/hw/fifo/intro.rst
> +++ b/docs/hw/fifo/intro.rst
> @@ -10,7 +10,7 @@ FIFO overview
>   Introduction
>   ============
>   
> -Commands to most of the engines are sent through a special engine caled PFIFO.
> +Commands to most of the engines are sent through a special engine called PFIFO.
>   PFIFO maintains multiple fully independent command queues, known as "channels"
>   or "FIFO"s. Each channel is controlled through a "channel control area", which
>   is a region of MMIO [pre-NVC0] or VRAM [NVC0+]. PFIFO intercepts all accesses
> @@ -40,11 +40,11 @@ The engines that PFIFO controls on NV04:NVC0 are:
>   == ========== =========================== ===================================================
>   Id Present on Name                        Description
>   == ========== =========================== ===================================================
> -0  all        SOFTWARE                    Not really an engine, causes interrupt for each
> -                                          command, can be used to execute driver functions
> -                                          in sync with other commands.
> -1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> -2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
> +0  all        SOFTWARE                    Not really an engine, causes interrupt for each
> +                                          command, can be used to execute driver functions
> +                                          in sync with other commands.
> +1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> +2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
>      NVA0:NVAA
>   3  NV40:NV84  :ref:`PME <me-fifo>`        VPE motion estimation engine.
>   4  NV41:NV84  :ref:`PVP1 <pvp1>`          VPE microcoded vector processor.
> @@ -64,10 +64,10 @@ The engines that PFIFO controls on NVC0- are:
>   ===== ========== =========================== ===================================================
>   Id    Present on Name                        Description
>   ===== ========== =========================== ===================================================
> -1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
> -                                             command, can be used to execute driver functions
> -                                             in sync with other commands.
> -0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> +1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
> +                                             command, can be used to execute driver functions
> +                                             in sync with other commands.
> +0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
>   1     all        :ref:`PVDEC <pvdec>`        falcon-based microcoded video decoder.
>   2     all        :ref:`PPPP <pppp>`          falcon-based video post-processor.
>   3     all        :ref:`PVLD <pvld>`          falcon-based variable length decoder.
> @@ -93,7 +93,7 @@ The PFIFO can be split into roughly 4 pieces:
>   - PFIFO puller: executes the commands, passes them to the proper engine,
>     or to the driver.
>   - PFIFO switcher: ticks out the time slices for the channels and saves /
> -  restores the state of the channel between PFIFO registers and RAMFC
> +  restores the state of the channels between PFIFO registers and RAMFC
>     memory.
>   
>   A channel consists of the following:
> @@ -133,7 +133,7 @@ is being submitted. See :ref:`nv03-pfifo-dma` for details.
>   
>   NV04 PFIFO greatly enhanced the DMA mode and made it controllable directly
>   through the channel control area. Thus, commands can now be submitted by
> -multiple applications simultanously, without coordination with each other
> +multiple applications simultaneously, without coordination with each other
>   and without kernel's help. DMA mode is described in :ref:`fifo-dma-pusher`.
>   
>   NV50 introduced IB mode. IB mode is a modified version of DMA mode that,
> @@ -143,8 +143,8 @@ to stitch together parts of multiple memory areas into a single command stream
>   memory written by earlier commands. IB mode is described along with DMA mode in
>   :ref:`fifo-dma-pusher`.
>   
> -NVC0 rearchitected the whole PFIFO, made it possible to have up to 3 channels
> -executing simultanously, and introduced a new DMA packet format.
> +NVC0 rearchitectured the whole PFIFO, made it possible to have up to 3 channels
> +executing simultaneously, and introduced a new DMA packet format.
>   
>   The commands, as stored in CACHE, are tuples of:
>   
> @@ -180,12 +180,12 @@ and engine-specific documentation.
>   
>   Pre-NV1A, PFIFO treats everything as little-endian. NV1A introduced big-endian
>   mode, which affects pushbuffer/IB reads and semaphores. On NV1A:NV50 cards,
> -the endian can be selected per channel via big_endian flag. On NV50+ cards,
> +the endianness can be selected per channel via the big_endian flag. On NV50+ cards,
>   PFIFO endianness is a global switch.
>   
>   .. todo:: look for NVC0 PFIFO endian switch
>   
>   The channel control area endianness is not affected by the big_endian flag or
> -NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endian switch.
> +NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endianness switch.
>   
>   .. todo:: is it still true for NVC0, with VRAM-backed channel control area?

Looks good, I'll push it soon!

[PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

- Sort commands by name for easier update
- Make more readable
- Remove no more existing commands
---
 nva/README | 83 +++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 44 insertions(+), 39 deletions(-)

diff --git a/nva/README b/nva/README
index 625ea7c..d4347c5 100644
--- a/nva/README
+++ b/nva/README
@@ -3,7 +3,7 @@ registers.
 
 WARNING: these tools *can* and *will* hang your machine if you don't know
 what you're doing. Hardware destruction is likely also possible, although
-no incidents are known to have happened yet. In most cases it's also not
+no incident are known to have happened yet. In most cases it's also not
 recommended to use these tools while a driver is active for a given card.
 
 All programs except nvalist take an optional -c <card number> parameter.
@@ -13,43 +13,48 @@ by the nvalist program.
 
 The programs are:
 
-nvalist: prints a list of cards
-
-nvapeek <address> [<byte count>]: reads 32-bit MMIO register at <address>.
-If byte count is also given, reads all registers in range [address, address
-+ byte count).
-
-nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO accesses
-
-nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register at
-<address>.
-
-nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
-
-nvawatch [-t] <address>: reads MMIO register at <address> in a loop, prints
-the value every time it changes. If -t is specified, prints a timestamp
-and diff from the previous timestamp before the value. Never quits, needs
-to be manually aborted.
-
-nvahammer <address> <value>: like nvapoke, but repeats the write in
-an infinite loop. Needs to be manually aborted.
-
-nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
-method given as parameter and writes it to stdout. Method can be PROM or
-PRAMIN. If method is not given, defaults to something sensible.
-
-nvafuzz <address> [<byte count>]: writes random values to a register or
-a register range in an infinite loop. Needs to be manually aborted.
-
-nvascan [-as] <address> [<byte count>]: for each register in a range:
-read it, write 0xffffffff, read it, write 0, read it, write back the
-original value. Helpful to see the valid values for registers. If -s option
-is passed, does a slow scan - waits and reads PMC.ID register between scans
-to recover from errors caused by invalid register accesses. If -a option
-is passed, does a cross-test on all registers in the range to detect aliased
-addresses [not particularly reliable].
-
-nvatiming: attempts to measure what frequency various units of the card are
-running at by using misc tricks.
+nvafuzz <address> [<byte count>]
+    Writes random values to a register or
+    a register range in an infinite loop. Needs to be manually aborted.
+
+nvagetbios [-s <extraction method>]
+    Extracts the card's VBIOS using the
+    method given as parameter and writes it to stdout. Method can be PROM or
+    PRAMIN. If method is not given, defaults to something sensible.
+
+nvahammer <address> <value>
+    Like nvapoke, but repeats the write in
+    an infinite loop. Needs to be manually aborted.
+
+nvalist
+    Prints a list of cards
+
+nvapeek <address> [<byte count>]
+    Reads 32-bit MMIO register at <address>.
+    If byte count is also given, reads all registers in range [address, address
+    + byte count).
+
+nvapoke <address> <value>
+    Writes a 32-bit <value> to the MMIO register at
+    <address>.
+
+nvascan [-as] <address> [<byte count>]
+    For each register in a range:
+    read it, write 0xffffffff, read it, write 0, read it, write back the
+    original value. Helpful to see the valid values for registers. If -s option
+    is passed, does a slow scan - waits and reads PMC.ID register between scans
+    to recover from errors caused by invalid register accesses. If -a option
+    is passed, does a cross-test on all registers in the range to detect aliased
+    addresses [not particularly reliable].
+
+nvatiming
+    Attempts to measure what frequency various units of the card are
+    running at by using misc tricks.
+
+nvawatch [-t] <address>
+    Reads MMIO register at <address> in a loop, prints
+    the value every time it changes. If -t is specified, prints a timestamp
+    and diff from the previous timestamp before the value. Never quits, needs
+    to be manually aborted.
 
 [XXX: document the remaining tools]
-- 
1.9.1

Re: [PATCH envytools] nva: Clean up nva tools doc

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> - Sort commands by name for easier update
> - Make more readable
> - Remove no more existing commands
> ---
>   nva/README | 83 +++++++++++++++++++++++++++++++++-----------------------------
>   1 file changed, 44 insertions(+), 39 deletions(-)
>
> diff --git a/nva/README b/nva/README
> index 625ea7c..d4347c5 100644
> --- a/nva/README
> +++ b/nva/README
> @@ -3,7 +3,7 @@ registers.
>   
>   WARNING: these tools *can* and *will* hang your machine if you don't know
>   what you're doing. Hardware destruction is likely also possible, although
> -no incidents are known to have happened yet. In most cases it's also not
> +no incident are known to have happened yet. In most cases it's also not
IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could 
give us
a more definitive answer on this :)
>   recommended to use these tools while a driver is active for a given card.
>   
>   All programs except nvalist take an optional -c <card number> parameter.
> @@ -13,43 +13,48 @@ by the nvalist program.
>   
>   The programs are:
>   
> -nvalist: prints a list of cards
> -
> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at <address>.
> -If byte count is also given, reads all registers in range [address, address
> -+ byte count).
> -
> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO accesses
> -
> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register at
> -<address>.
> -
> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
> -
> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop, prints
> -the value every time it changes. If -t is specified, prints a timestamp
> -and diff from the previous timestamp before the value. Never quits, needs
> -to be manually aborted.
> -
> -nvahammer <address> <value>: like nvapoke, but repeats the write in
> -an infinite loop. Needs to be manually aborted.
> -
> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
> -method given as parameter and writes it to stdout. Method can be PROM or
> -PRAMIN. If method is not given, defaults to something sensible.
> -
> -nvafuzz <address> [<byte count>]: writes random values to a register or
> -a register range in an infinite loop. Needs to be manually aborted.
> -
> -nvascan [-as] <address> [<byte count>]: for each register in a range:
> -read it, write 0xffffffff, read it, write 0, read it, write back the
> -original value. Helpful to see the valid values for registers. If -s option
> -is passed, does a slow scan - waits and reads PMC.ID register between scans
> -to recover from errors caused by invalid register accesses. If -a option
> -is passed, does a cross-test on all registers in the range to detect aliased
> -addresses [not particularly reliable].
> -
> -nvatiming: attempts to measure what frequency various units of the card are
> -running at by using misc tricks.
> +nvafuzz <address> [<byte count>]
> +    Writes random values to a register or
> +    a register range in an infinite loop. Needs to be manually aborted.
> +
> +nvagetbios [-s <extraction method>]
> +    Extracts the card's VBIOS using the
> +    method given as parameter and writes it to stdout. Method can be PROM or
> +    PRAMIN. If method is not given, defaults to something sensible.
> +
> +nvahammer <address> <value>
> +    Like nvapoke, but repeats the write in
> +    an infinite loop. Needs to be manually aborted.
> +
> +nvalist
> +    Prints a list of cards
> +
> +nvapeek <address> [<byte count>]
> +    Reads 32-bit MMIO register at <address>.
> +    If byte count is also given, reads all registers in range [address, address
> +    + byte count).
> +
> +nvapoke <address> <value>
> +    Writes a 32-bit <value> to the MMIO register at
> +    <address>.
> +
> +nvascan [-as] <address> [<byte count>]
> +    For each register in a range:
> +    read it, write 0xffffffff, read it, write 0, read it, write back the
> +    original value. Helpful to see the valid values for registers. If -s option
> +    is passed, does a slow scan - waits and reads PMC.ID register between scans
> +    to recover from errors caused by invalid register accesses. If -a option
> +    is passed, does a cross-test on all registers in the range to detect aliased
> +    addresses [not particularly reliable].
> +
> +nvatiming
> +    Attempts to measure what frequency various units of the card are
> +    running at by using misc tricks.
> +
> +nvawatch [-t] <address>
> +    Reads MMIO register at <address> in a loop, prints
> +    the value every time it changes. If -t is specified, prints a timestamp
> +    and diff from the previous timestamp before the value. Never quits, needs
> +    to be manually aborted.
>   
>   [XXX: document the remaining tools]
Did you fix some spelling mistakes in while changing the order? I 
already suck at
comparing lines that are one on top of the other, so I don't even want 
to try checking!

Re: [PATCH envytools] nva: Clean up nva tools doc

[Ilia Mirkin]

On Mon, Aug 25, 2014 at 6:35 PM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
> On 25/08/2014 20:58, Christian Costa wrote:
>>
>> - Sort commands by name for easier update
>> - Make more readable
>> - Remove no more existing commands
>> ---
>>   nva/README | 83
>> +++++++++++++++++++++++++++++++++-----------------------------
>>   1 file changed, 44 insertions(+), 39 deletions(-)
>>
>> diff --git a/nva/README b/nva/README
>> index 625ea7c..d4347c5 100644
>> --- a/nva/README
>> +++ b/nva/README
>> @@ -3,7 +3,7 @@ registers.
>>     WARNING: these tools *can* and *will* hang your machine if you don't
>> know
>>   what you're doing. Hardware destruction is likely also possible,
>> although
>> -no incidents are known to have happened yet. In most cases it's also not
>> +no incident are known to have happened yet. In most cases it's also not
>
> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could give
> us
> a more definitive answer on this :)

Without being definitive, I believe the old way was fine. The new way,
however, is not. You could, alternatively say, "although no incident
is known to have happened yet" -- pretty sure that'd be correct too.

>
>>   recommended to use these tools while a driver is active for a given
>> card.
>>     All programs except nvalist take an optional -c <card number>
>> parameter.
>> @@ -13,43 +13,48 @@ by the nvalist program.
>>     The programs are:
>>   -nvalist: prints a list of cards
>> -
>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at
>> <address>.
>> -If byte count is also given, reads all registers in range [address,
>> address
>> -+ byte count).
>> -
>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO
>> accesses
>> -
>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register
>> at
>> -<address>.
>> -
>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>> -
>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop,
>> prints
>> -the value every time it changes. If -t is specified, prints a timestamp
>> -and diff from the previous timestamp before the value. Never quits, needs
>> -to be manually aborted.
>> -
>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>> -an infinite loop. Needs to be manually aborted.
>> -
>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
>> -method given as parameter and writes it to stdout. Method can be PROM or
>> -PRAMIN. If method is not given, defaults to something sensible.
>> -
>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>> -a register range in an infinite loop. Needs to be manually aborted.
>> -
>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>> -original value. Helpful to see the valid values for registers. If -s
>> option
>> -is passed, does a slow scan - waits and reads PMC.ID register between
>> scans
>> -to recover from errors caused by invalid register accesses. If -a option
>> -is passed, does a cross-test on all registers in the range to detect
>> aliased
>> -addresses [not particularly reliable].
>> -
>> -nvatiming: attempts to measure what frequency various units of the card
>> are
>> -running at by using misc tricks.
>> +nvafuzz <address> [<byte count>]
>> +    Writes random values to a register or
>> +    a register range in an infinite loop. Needs to be manually aborted.
>> +
>> +nvagetbios [-s <extraction method>]
>> +    Extracts the card's VBIOS using the
>> +    method given as parameter and writes it to stdout. Method can be PROM
>> or
>> +    PRAMIN. If method is not given, defaults to something sensible.
>> +
>> +nvahammer <address> <value>
>> +    Like nvapoke, but repeats the write in
>> +    an infinite loop. Needs to be manually aborted.
>> +
>> +nvalist
>> +    Prints a list of cards
>> +
>> +nvapeek <address> [<byte count>]
>> +    Reads 32-bit MMIO register at <address>.
>> +    If byte count is also given, reads all registers in range [address,
>> address
>> +    + byte count).
>> +
>> +nvapoke <address> <value>
>> +    Writes a 32-bit <value> to the MMIO register at
>> +    <address>.
>> +
>> +nvascan [-as] <address> [<byte count>]
>> +    For each register in a range:
>> +    read it, write 0xffffffff, read it, write 0, read it, write back the
>> +    original value. Helpful to see the valid values for registers. If -s
>> option
>> +    is passed, does a slow scan - waits and reads PMC.ID register between
>> scans
>> +    to recover from errors caused by invalid register accesses. If -a
>> option
>> +    is passed, does a cross-test on all registers in the range to detect
>> aliased
>> +    addresses [not particularly reliable].
>> +
>> +nvatiming
>> +    Attempts to measure what frequency various units of the card are
>> +    running at by using misc tricks.
>> +
>> +nvawatch [-t] <address>
>> +    Reads MMIO register at <address> in a loop, prints
>> +    the value every time it changes. If -t is specified, prints a
>> timestamp
>> +    and diff from the previous timestamp before the value. Never quits,
>> needs
>> +    to be manually aborted.
>>     [XXX: document the remaining tools]
>
> Did you fix some spelling mistakes in while changing the order? I already
> suck at
> comparing lines that are one on top of the other, so I don't even want to
> try checking!
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

Le 26/08/2014 00:55, Ilia Mirkin a écrit :
> On Mon, Aug 25, 2014 at 6:35 PM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
>> On 25/08/2014 20:58, Christian Costa wrote:
>>> - Sort commands by name for easier update
>>> - Make more readable
>>> - Remove no more existing commands
>>> ---
>>>    nva/README | 83
>>> +++++++++++++++++++++++++++++++++-----------------------------
>>>    1 file changed, 44 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/nva/README b/nva/README
>>> index 625ea7c..d4347c5 100644
>>> --- a/nva/README
>>> +++ b/nva/README
>>> @@ -3,7 +3,7 @@ registers.
>>>      WARNING: these tools *can* and *will* hang your machine if you don't
>>> know
>>>    what you're doing. Hardware destruction is likely also possible,
>>> although
>>> -no incidents are known to have happened yet. In most cases it's also not
>>> +no incident are known to have happened yet. In most cases it's also not
>> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could give
>> us
>> a more definitive answer on this :)
> Without being definitive, I believe the old way was fine. The new way,
> however, is not. You could, alternatively say, "although no incident
> is known to have happened yet" -- pretty sure that'd be correct too.
Oh. I intended to write "no incident is known" but forgot to change "are".
I'Il resend a patch with old way. Now, you're pointing out, I remember 
this is correct.
>
>>>    recommended to use these tools while a driver is active for a given
>>> card.
>>>      All programs except nvalist take an optional -c <card number>
>>> parameter.
>>> @@ -13,43 +13,48 @@ by the nvalist program.
>>>      The programs are:
>>>    -nvalist: prints a list of cards
>>> -
>>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at
>>> <address>.
>>> -If byte count is also given, reads all registers in range [address,
>>> address
>>> -+ byte count).
>>> -
>>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO
>>> accesses
>>> -
>>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register
>>> at
>>> -<address>.
>>> -
>>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>>> -
>>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop,
>>> prints
>>> -the value every time it changes. If -t is specified, prints a timestamp
>>> -and diff from the previous timestamp before the value. Never quits, needs
>>> -to be manually aborted.
>>> -
>>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>>> -an infinite loop. Needs to be manually aborted.
>>> -
>>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
>>> -method given as parameter and writes it to stdout. Method can be PROM or
>>> -PRAMIN. If method is not given, defaults to something sensible.
>>> -
>>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>>> -a register range in an infinite loop. Needs to be manually aborted.
>>> -
>>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>>> -original value. Helpful to see the valid values for registers. If -s
>>> option
>>> -is passed, does a slow scan - waits and reads PMC.ID register between
>>> scans
>>> -to recover from errors caused by invalid register accesses. If -a option
>>> -is passed, does a cross-test on all registers in the range to detect
>>> aliased
>>> -addresses [not particularly reliable].
>>> -
>>> -nvatiming: attempts to measure what frequency various units of the card
>>> are
>>> -running at by using misc tricks.
>>> +nvafuzz <address> [<byte count>]
>>> +    Writes random values to a register or
>>> +    a register range in an infinite loop. Needs to be manually aborted.
>>> +
>>> +nvagetbios [-s <extraction method>]
>>> +    Extracts the card's VBIOS using the
>>> +    method given as parameter and writes it to stdout. Method can be PROM
>>> or
>>> +    PRAMIN. If method is not given, defaults to something sensible.
>>> +
>>> +nvahammer <address> <value>
>>> +    Like nvapoke, but repeats the write in
>>> +    an infinite loop. Needs to be manually aborted.
>>> +
>>> +nvalist
>>> +    Prints a list of cards
>>> +
>>> +nvapeek <address> [<byte count>]
>>> +    Reads 32-bit MMIO register at <address>.
>>> +    If byte count is also given, reads all registers in range [address,
>>> address
>>> +    + byte count).
>>> +
>>> +nvapoke <address> <value>
>>> +    Writes a 32-bit <value> to the MMIO register at
>>> +    <address>.
>>> +
>>> +nvascan [-as] <address> [<byte count>]
>>> +    For each register in a range:
>>> +    read it, write 0xffffffff, read it, write 0, read it, write back the
>>> +    original value. Helpful to see the valid values for registers. If -s
>>> option
>>> +    is passed, does a slow scan - waits and reads PMC.ID register between
>>> scans
>>> +    to recover from errors caused by invalid register accesses. If -a
>>> option
>>> +    is passed, does a cross-test on all registers in the range to detect
>>> aliased
>>> +    addresses [not particularly reliable].
>>> +
>>> +nvatiming
>>> +    Attempts to measure what frequency various units of the card are
>>> +    running at by using misc tricks.
>>> +
>>> +nvawatch [-t] <address>
>>> +    Reads MMIO register at <address> in a loop, prints
>>> +    the value every time it changes. If -t is specified, prints a
>>> timestamp
>>> +    and diff from the previous timestamp before the value. Never quits,
>>> needs
>>> +    to be manually aborted.
>>>      [XXX: document the remaining tools]
>> Did you fix some spelling mistakes in while changing the order? I already
>> suck at
>> comparing lines that are one on top of the other, so I don't even want to
>> try checking!
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Re: [PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

Le 26/08/2014 00:35, Martin Peres a écrit :
> On 25/08/2014 20:58, Christian Costa wrote:
>> - Sort commands by name for easier update
>> - Make more readable
>> - Remove no more existing commands
>> ---
>>   nva/README | 83 
>> +++++++++++++++++++++++++++++++++-----------------------------
>>   1 file changed, 44 insertions(+), 39 deletions(-)
>>
>> diff --git a/nva/README b/nva/README
>> index 625ea7c..d4347c5 100644
>> --- a/nva/README
>> +++ b/nva/README
>> @@ -3,7 +3,7 @@ registers.
>>     WARNING: these tools *can* and *will* hang your machine if you 
>> don't know
>>   what you're doing. Hardware destruction is likely also possible, 
>> although
>> -no incidents are known to have happened yet. In most cases it's also 
>> not
>> +no incident are known to have happened yet. In most cases it's also not
> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could 
> give us
> a more definitive answer on this :)
Ok. I'll resend a patch after confirmation if needed.
>>   recommended to use these tools while a driver is active for a given 
>> card.
>>     All programs except nvalist take an optional -c <card number> 
>> parameter.
>> @@ -13,43 +13,48 @@ by the nvalist program.
>>     The programs are:
>>   -nvalist: prints a list of cards
>> -
>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at 
>> <address>.
>> -If byte count is also given, reads all registers in range [address, 
>> address
>> -+ byte count).
>> -
>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO 
>> accesses
>> -
>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO 
>> register at
>> -<address>.
>> -
>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>> -
>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop, 
>> prints
>> -the value every time it changes. If -t is specified, prints a timestamp
>> -and diff from the previous timestamp before the value. Never quits, 
>> needs
>> -to be manually aborted.
>> -
>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>> -an infinite loop. Needs to be manually aborted.
>> -
>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using 
>> the
>> -method given as parameter and writes it to stdout. Method can be 
>> PROM or
>> -PRAMIN. If method is not given, defaults to something sensible.
>> -
>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>> -a register range in an infinite loop. Needs to be manually aborted.
>> -
>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>> -original value. Helpful to see the valid values for registers. If -s 
>> option
>> -is passed, does a slow scan - waits and reads PMC.ID register 
>> between scans
>> -to recover from errors caused by invalid register accesses. If -a 
>> option
>> -is passed, does a cross-test on all registers in the range to detect 
>> aliased
>> -addresses [not particularly reliable].
>> -
>> -nvatiming: attempts to measure what frequency various units of the 
>> card are
>> -running at by using misc tricks.
>> +nvafuzz <address> [<byte count>]
>> +    Writes random values to a register or
>> +    a register range in an infinite loop. Needs to be manually aborted.
>> +
>> +nvagetbios [-s <extraction method>]
>> +    Extracts the card's VBIOS using the
>> +    method given as parameter and writes it to stdout. Method can be 
>> PROM or
>> +    PRAMIN. If method is not given, defaults to something sensible.
>> +
>> +nvahammer <address> <value>
>> +    Like nvapoke, but repeats the write in
>> +    an infinite loop. Needs to be manually aborted.
>> +
>> +nvalist
>> +    Prints a list of cards
>> +
>> +nvapeek <address> [<byte count>]
>> +    Reads 32-bit MMIO register at <address>.
>> +    If byte count is also given, reads all registers in range 
>> [address, address
>> +    + byte count).
>> +
>> +nvapoke <address> <value>
>> +    Writes a 32-bit <value> to the MMIO register at
>> +    <address>.
>> +
>> +nvascan [-as] <address> [<byte count>]
>> +    For each register in a range:
>> +    read it, write 0xffffffff, read it, write 0, read it, write back 
>> the
>> +    original value. Helpful to see the valid values for registers. 
>> If -s option
>> +    is passed, does a slow scan - waits and reads PMC.ID register 
>> between scans
>> +    to recover from errors caused by invalid register accesses. If 
>> -a option
>> +    is passed, does a cross-test on all registers in the range to 
>> detect aliased
>> +    addresses [not particularly reliable].
>> +
>> +nvatiming
>> +    Attempts to measure what frequency various units of the card are
>> +    running at by using misc tricks.
>> +
>> +nvawatch [-t] <address>
>> +    Reads MMIO register at <address> in a loop, prints
>> +    the value every time it changes. If -t is specified, prints a 
>> timestamp o
>> +    and diff from the previous timestamp before the value. Never 
>> quits, needs
>> +    to be manually aborted.
>>     [XXX: document the remaining tools]
> Did you fix some spelling mistakes in while changing the order? I 
> already suck at
> comparing lines that are one on top of the other, so I don't even want 
> to try checking!
No. Only "incidents" in this patch.

[PATCH envytools] nvbios: Return an error if mem train subentries is above the limit to avoid stack corruption.

[Christian Costa]

---
 nvbios/mem.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/nvbios/mem.c b/nvbios/mem.c
index 911ce5c..2c8a929 100644
--- a/nvbios/mem.c
+++ b/nvbios/mem.c
@@ -111,6 +111,10 @@ envy_bios_parse_mem_train (struct envy_bios *bios) {
 		struct envy_bios_mem_train_entry *entry = &mt->entries[i];
 		entry->offset = mt->offset + mt->hlen + ((mt->rlen + mt->subentries * mt->subentrylen) * i);
 		err |= bios_u8(bios, entry->offset, &entry->u00);
+		if (mt->subentries > sizeof(entry->subentry)) {
+			ENVY_BIOS_ERR("Error when parsing mem train: subentries = %d > %lu\n", mt->subentries, sizeof(entry->subentry));
+			return -EFAULT;
+		}
 		int j;
 		for (j = 0; j < mt->subentries; j++) {
 			err |= bios_u8(bios, entry->offset+j+1, &entry->subentry[j]);
-- 
1.9.1

[PATCH envytools] nvbios: Write missing null terminating byte.

[Christian Costa]

---
 nvbios/nvbios.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
index 4fc667b..7bb768a 100644
--- a/nvbios/nvbios.c
+++ b/nvbios/nvbios.c
@@ -797,9 +797,9 @@ void find_strap(char *filename) {
 
 	path = (char*) malloc(base_length + strlen(strap_filename)+1);
 	strncpy(path, filename, base_length);
-	strncpy(path+base_length, strap_filename, strlen(strap_filename));
+	strncpy(path+base_length, strap_filename, strlen(strap_filename)+1);
 
-	if(!set_strap_from_file(path))
+	if (!set_strap_from_file(path))
 		printf("Strap register found in '%s'\n", path);
 
 	free(path);
-- 
1.9.1

Re: [PATCH envytools] nvbios: Write missing null terminating byte.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   nvbios/nvbios.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
> index 4fc667b..7bb768a 100644
> --- a/nvbios/nvbios.c
> +++ b/nvbios/nvbios.c
> @@ -797,9 +797,9 @@ void find_strap(char *filename) {
>   
>   	path = (char*) malloc(base_length + strlen(strap_filename)+1);
>   	strncpy(path, filename, base_length);
> -	strncpy(path+base_length, strap_filename, strlen(strap_filename));
> +	strncpy(path+base_length, strap_filename, strlen(strap_filename)+1);
>   
> -	if(!set_strap_from_file(path))
> +	if (!set_strap_from_file(path))
>   		printf("Strap register found in '%s'\n", path);
>   
>   	free(path);
Looks good

[PATCH envytools] nvbios: Check if HWEA entry length == -1.

[Christian Costa]

---
 nvbios/bios.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/nvbios/bios.c b/nvbios/bios.c
index fac3840..ca8c54e 100644
--- a/nvbios/bios.c
+++ b/nvbios/bios.c
@@ -276,9 +276,14 @@ int envy_bios_parse (struct envy_bios *bios) {
 					pos += 4;
 					if (entry.type > 1)
 						ENVY_BIOS_WARN("Unknown HWEA entry type %d\n", entry.type);
+					if (entry.len == (uint32_t)-1) {
+						/* Maybe this should be treated as for length == 0 */
+						ENVY_BIOS_ERR("Invalid HWEA entry length %d\n", entry.len);
+						break;
+					}
 				} else {
 					entry.base = word & 0x1fffffc;
-					entry.type = word&3;
+					entry.type = word & 3;
 					switch (entry.type) {
 						case 0:
 						case 1:
-- 
1.9.1

[PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Christian Costa]

---
 nvbios/info.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/nvbios/info.c b/nvbios/info.c
index 87a33d8..6b8d209 100644
--- a/nvbios/info.c
+++ b/nvbios/info.c
@@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
 			bios->chipset_name = "G72";
 			break;
 		case 0x0573:
+			if (!bios->parts) {
+				ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");
+				break;
+			}
 			/* yeah, ain't this one hilarious... */
 			if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
 				bios->chipset = 0x63;
-- 
1.9.1

Re: [PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Ilia Mirkin]

On Mon, Aug 25, 2014 at 2:58 PM, Christian Costa <titan.costa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> ---
>  nvbios/info.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/nvbios/info.c b/nvbios/info.c
> index 87a33d8..6b8d209 100644
> --- a/nvbios/info.c
> +++ b/nvbios/info.c
> @@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
>                         bios->chipset_name = "G72";
>                         break;
>                 case 0x0573:
> +                       if (!bios->parts) {
> +                               ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");

parts

> +                               break;
> +                       }
>                         /* yeah, ain't this one hilarious... */
>                         if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
>                                 bios->chipset = 0x63;
> --
> 1.9.1
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Christian Costa]

Le 25/08/2014 21:09, Ilia Mirkin a écrit :
> On Mon, Aug 25, 2014 at 2:58 PM, Christian Costa <titan.costa@gmail.com> wrote:
>> ---
>>   nvbios/info.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/nvbios/info.c b/nvbios/info.c
>> index 87a33d8..6b8d209 100644
>> --- a/nvbios/info.c
>> +++ b/nvbios/info.c
>> @@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
>>                          bios->chipset_name = "G72";
>>                          break;
>>                  case 0x0573:
>> +                       if (!bios->parts) {
>> +                               ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");
> parts
Ok. I'll a resend a patch. Thanks!
>
>> +                               break;
>> +                       }
>>                          /* yeah, ain't this one hilarious... */
>>                          if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
>>                                  bios->chipset = 0x63;
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
>   1 file changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
> index 500cea9..e006dbe 100644
> --- a/rnndb/memory/nvc0_pbfb.xml
> +++ b/rnndb/memory/nvc0_pbfb.xml
> @@ -49,23 +49,54 @@
>   			Most bitfields are unknown.
>   			</doc>
>   		<bitfield high="7" low="0" name="RP">
> -			<doc> RAS# precharge. </doc>
> +			<doc> RAS# Precharge. </doc>
>   		</bitfield>
>   		<bitfield high="15" low="8" name="RAS">
> -			<doc>Activate to precharge delay. </doc>
> +			<doc> Activate to precharge delay. </doc>
>   		</bitfield>
>   		<bitfield high="23" low="16" name="RFC">
>   			<doc> Refresh to activate delay. </doc>
>   		</bitfield>
>   		<bitfield high="31" low="24" name="RC">
> -			<doc> Row cycle time. </doc>
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +	</reg32>
> +
> +	<reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
> +		<doc> This, and the next 6 regs, are all related to memtimings.
> +			A good place to read might be http://www.tweakers.fr/timings.html .
> +			Most bitfields are unknown.
> +			</doc>
> +		<bitfield high="7" low="0" name="tRC">
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +		<bitfield high="15" low="8" name="tRFC">
> +			<doc> Refresh to activate delay. </doc>
> +		</bitfield>
> +		<bitfield high="23" low="17" name="tRAS">
> +			<doc> Activate to precharge delay. </doc>
> +		</bitfield>
> +		<bitfield high="31" low="24" name="tRCD">
> +			<doc> RAS# to CAS# Delay. </doc>
>   		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
> +		<bitfield high="3" low="0" name="tCL">
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +		<bitfield high="13" low="7" name="tCWL">
> +			<doc> CAS# Write Latency. </doc>
> +		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
> +		<bitfield high="15" low="8" name="tWTR">
> +			<doc> Write To Read delay. </doc>
> +		</bitfield>
> +		<bitfield high="23" low="15" name="tWR">
> +			<doc> Write Recovery time. </doc>
> +		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">

Thanks for the patch but where did you get this knowledge? By comparing 
with nv50 and the vbios table?

Re: [PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Christian Costa]

Le 26/08/2014 00:30, Martin Peres a écrit :
> On 25/08/2014 20:58, Christian Costa wrote:
>> ---
>>   rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
>>   1 file changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
>> index 500cea9..e006dbe 100644
>> --- a/rnndb/memory/nvc0_pbfb.xml
>> +++ b/rnndb/memory/nvc0_pbfb.xml
>> @@ -49,23 +49,54 @@
>>               Most bitfields are unknown.
>>               </doc>
>>           <bitfield high="7" low="0" name="RP">
>> -            <doc> RAS# precharge. </doc>
>> +            <doc> RAS# Precharge. </doc>
>>           </bitfield>
>>           <bitfield high="15" low="8" name="RAS">
>> -            <doc>Activate to precharge delay. </doc>
>> +            <doc> Activate to precharge delay. </doc>
>>           </bitfield>
>>           <bitfield high="23" low="16" name="RFC">
>>               <doc> Refresh to activate delay. </doc>
>>           </bitfield>
>>           <bitfield high="31" low="24" name="RC">
>> -            <doc> Row cycle time. </doc>
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +    </reg32>
>> +
>> +    <reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
>> +        <doc> This, and the next 6 regs, are all related to memtimings.
>> +            A good place to read might be 
>> http://www.tweakers.fr/timings.html .
>> +            Most bitfields are unknown.
>> +            </doc>
>> +        <bitfield high="7" low="0" name="tRC">
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +        <bitfield high="15" low="8" name="tRFC">
>> +            <doc> Refresh to activate delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="23" low="17" name="tRAS">
>> +            <doc> Activate to precharge delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="31" low="24" name="tRCD">
>> +            <doc> RAS# to CAS# Delay. </doc>
>>           </bitfield>
>>       </reg32>
>>         <reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
>> +        <bitfield high="3" low="0" name="tCL">
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +        <bitfield high="13" low="7" name="tCWL">
>> +            <doc> CAS# Write Latency. </doc>
>> +        </bitfield>
>>       </reg32>
>>         <reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
>> +        <bitfield high="15" low="8" name="tWTR">
>> +            <doc> Write To Read delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="23" low="15" name="tWR">
>> +            <doc> Write Recovery time. </doc>
>> +        </bitfield>
>>       </reg32>
>>         <reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">
>
> Thanks for the patch but where did you get this knowledge? By 
> comparing with nv50 and the vbios table?

It's based on the code in nvbios.c:

                         reg_100220 = (tRCD << 24 | (tRAS&0x7f) << 17 | 
tRFC << 8 | tRC);
                         reg_100224 = 0x4c << 24 | (tUNK_11&0x0f) << 20 
| (tCWL << 7) | (tCL & 0x0f);
                         reg_100228 = 0x44000011 | tWR << 16 | tWTR << 8;
                         reg_10022c = tUNK_20 << 9 | tUNK_13;
                         reg_100230 = 0x42e00069 | tUNK_12 << 15;

                         printf("Registers: 290: 0x%08x 0x%08x 0x%08x 
0x%08x\n",
                         reg_100220, reg_100224,
                         reg_100228, reg_10022c);
                         printf("           2a0: 0x%08x 0x%08x 0x%08x 
0x%08x\n",
                         reg_100230, reg_100234,
                         reg_100238, reg_10023c);