On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs <skeggsb at gmail.com> wrote:> On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger <aritger at nvidia.com> wrote: >> Hi, > Hey Andy, > >> >> The VBIOS on GM20x GPUs uses a slightly updated version of the DCB. >> I've posted an updated DCB spec here: >> >> ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html >> >> You can diff it against the previous version: >> >> ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html >> >> to see what changed (sorry for having to diff html files). The biggest >> differences are Serial Output Resource (SOR) assignment, and the updated >> Communications Control Block layout. > Thanks for the heads-up on the update. The SOR assignment changes > explain some things I noticed when bringing up the GM204 you guys sent > me :)One question I have on making proper use of this is how should the RM determine which DCB entry (and hence, the correct pad macro) to use based on the SorSetControl index from the supervisor? Thanks, Ben.> > Ben. > >> >> I hope that is helpful, >> - Andy >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Dec 10, 2014 at 07:46:16AM +1000, Ben Skeggs wrote:> On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > > On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger <aritger at nvidia.com> wrote: > >> Hi, > > Hey Andy, > > > >> > >> The VBIOS on GM20x GPUs uses a slightly updated version of the DCB. > >> I've posted an updated DCB spec here: > >> > >> ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html > >> > >> You can diff it against the previous version: > >> > >> ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html > >> > >> to see what changed (sorry for having to diff html files). The biggest > >> differences are Serial Output Resource (SOR) assignment, and the updated > >> Communications Control Block layout. > > Thanks for the heads-up on the update. The SOR assignment changes > > explain some things I noticed when bringing up the GM204 you guys sent > > me :) > One question I have on making proper use of this is how should the RM > determine which DCB entry (and hence, the correct pad macro) to use > based on the SorSetControl index from the supervisor?Hi Ben. Yes, this is a little confusing. I had to review for myself and consult with one of our VBIOS experts. Below is my understanding. You probably know most of this already, so sorry for stating anything obvious. Terminology: SOR: Serial Output Resource. What is used to drive LVDS, TMDS, and DisplayPort. GM20x has four SORs. SOR Sublink: An individual link within an SOR. Each SOR has two links (SOR LinkA and SOR LinkB, per SOR). Macro: Receives signal from one or two SOR sublinks, and transmits to a connector. GM20x has four Macros. Macro Link (aka Pad Link): An individual link within a Macro. The first three Macros have two Macro Links each, and the fourth has one Macro Link. The Macro Links are labeled A - G. In GM20x, we added an "SOR Crossbar" between the SORs and the Macros, such that any SOR Sublink can drive any Macro Link. The registers to control the SOR Crossbar are 0x00612308+(i)*128: #define NV_PDISP_CLK_REM_LINK_CTRL(i) (0x00612308+(i)*128) /* RW-4A */ #define NV_PDISP_CLK_REM_LINK_CTRL__SIZE_1 7 /* */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND 3:0 /* RWIVF */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_INIT 0x00000000 /* RWI-V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_NONE 0x00000000 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR0 0x00000001 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR1 0x00000002 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR2 0x00000003 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR3 0x00000004 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR 4:4 /* RWIVF */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_INIT 0x00000000 /* RWI-V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_PRIMARY 0x00000000 /* RW--V */ #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_SECONDARY 0x00000001 /* RW--V */ The index (i) is the Macro Link number (0 through 6). You can direct the Macro Link to listen to one of the four SORs, and either LinkA (SOR_PRIMARY) or LinkB (SOR_SECONDARY) of the selected SOR. Note the default Macro Link to SOR Sublink assignment is NONE, so you'll need to program NV_PDISP_CLK_REM_LINK_CTRL to drive any SORs not set up by the VBIOS. Looking at the DCB spec, bits 24-27 in the Display Path Information entry will indicate which Macro the entry is talking about: For Internal and External DFPs we can use any of the available SORs but the Pad Macro is fixed per Device Entry. Bit 0 = Pad Macro 0 (Pad Links A and B) Bit 1 = Pad Macro 1 (Pad Links C and D) Bit 2 = Pad Macro 2 (Pad Links E and F) Bit 3 = Pad Macro 3 (Pad Link G) (AIUI, only one bit will be set per entry) And then bits 4-5 in the the DFP Specific Information table indicate which Macro Link(s) (aka Pad Link(s)) within the Macro the entry is talking about: For DCB 4.1: For TMDS/LVDS/DP this field describes which links of the Pad Macro are routed to the connector on the board. Bit 0: Pad Link 0 Bit 1: Pad Link 1 The SorSetControl index, as used in the supervisor interrupt, indicates one of the four SORs, and you can refer to the SOR Crossbar configuration to determine which Macro Link(s) are listening to the SOR Links of that SOR. From the Macro Links, you should be able to correlate to DCB entries. For an example topology, our reference GTX 980 board has the following layout: * Pad links A+B and DAC1 are connected to the DVI-I connector * Link C (Macro 1 Pad Link 0) is connected to the HDMI-A connector * Link D (Macro 1 Pad Link 1) is connected to a DP connector * Link E (Macro 2 Pad Link 0) is connected to a DP connector * Link F (Macro 2 Pad Link 1) is connected to a DP connector Except for DP multi-stream, one SOR should be used to drive a connector. The setup sequence would normally be: * Decide which connectors you want to drive. * Check which link (links for duallink-DVI) to use with that connector, per the DCB. * Assign an unused SOR to those link(s) via the NV_PDISP_CLK_REM_LINK_CTRL registers. * Use SorSetControl to attach a head to that SOR. I hope that makes sense. Thanks, - Andy> Thanks, > Ben. > > > > > Ben. > > > >> > >> I hope that is helpful, > >> - Andy > >> > >> _______________________________________________ > >> Nouveau mailing list > >> Nouveau at lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/nouveau
On Sat, Dec 13, 2014 at 6:42 PM, Andy Ritger <aritger at nvidia.com> wrote:> On Wed, Dec 10, 2014 at 07:46:16AM +1000, Ben Skeggs wrote: >> On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs <skeggsb at gmail.com> wrote: >> > On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger <aritger at nvidia.com> wrote: >> >> Hi, >> > Hey Andy, >> > >> >> >> >> The VBIOS on GM20x GPUs uses a slightly updated version of the DCB. >> >> I've posted an updated DCB spec here: >> >> >> >> ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html >> >> >> >> You can diff it against the previous version: >> >> >> >> ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html >> >> >> >> to see what changed (sorry for having to diff html files). The biggest >> >> differences are Serial Output Resource (SOR) assignment, and the updated >> >> Communications Control Block layout. >> > Thanks for the heads-up on the update. The SOR assignment changes >> > explain some things I noticed when bringing up the GM204 you guys sent >> > me :) >> One question I have on making proper use of this is how should the RM >> determine which DCB entry (and hence, the correct pad macro) to use >> based on the SorSetControl index from the supervisor? > > Hi Ben. > > Yes, this is a little confusing. I had to review for myself and consult > with one of our VBIOS experts. > > Below is my understanding. You probably know most of this already, > so sorry for stating anything obvious. > > Terminology: > > SOR: Serial Output Resource. What is used to drive LVDS, TMDS, and > DisplayPort. GM20x has four SORs. > > SOR Sublink: An individual link within an SOR. Each SOR has two links > (SOR LinkA and SOR LinkB, per SOR). > > Macro: Receives signal from one or two SOR sublinks, and transmits to > a connector. GM20x has four Macros. > > Macro Link (aka Pad Link): An individual link within a Macro. The first > three Macros have two Macro Links each, and the fourth has one > Macro Link. The Macro Links are labeled A - G. > > In GM20x, we added an "SOR Crossbar" between the SORs and the Macros, > such that any SOR Sublink can drive any Macro Link. > > The registers to control the SOR Crossbar are 0x00612308+(i)*128: > > #define NV_PDISP_CLK_REM_LINK_CTRL(i) (0x00612308+(i)*128) /* RW-4A */ > #define NV_PDISP_CLK_REM_LINK_CTRL__SIZE_1 7 /* */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND 3:0 /* RWIVF */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_INIT 0x00000000 /* RWI-V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_NONE 0x00000000 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR0 0x00000001 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR1 0x00000002 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR2 0x00000003 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR3 0x00000004 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR 4:4 /* RWIVF */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_INIT 0x00000000 /* RWI-V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_PRIMARY 0x00000000 /* RW--V */ > #define NV_PDISP_CLK_REM_LINK_CTRL_FRONTEND_SOR_SECONDARY 0x00000001 /* RW--V */ > > The index (i) is the Macro Link number (0 through 6). You can direct > the Macro Link to listen to one of the four SORs, and either LinkA > (SOR_PRIMARY) or LinkB (SOR_SECONDARY) of the selected SOR. > > Note the default Macro Link to SOR Sublink assignment is NONE, so you'll need > to program NV_PDISP_CLK_REM_LINK_CTRL to drive any SORs not set up by > the VBIOS. > > Looking at the DCB spec, bits 24-27 in the Display Path Information > entry will indicate which Macro the entry is talking about: > > For Internal and External DFPs we can use any of the available SORs > but the Pad Macro is fixed per Device Entry. > Bit 0 = Pad Macro 0 (Pad Links A and B) > Bit 1 = Pad Macro 1 (Pad Links C and D) > Bit 2 = Pad Macro 2 (Pad Links E and F) > Bit 3 = Pad Macro 3 (Pad Link G) > > (AIUI, only one bit will be set per entry) > > And then bits 4-5 in the the DFP Specific Information table indicate > which Macro Link(s) (aka Pad Link(s)) within the Macro the entry is > talking about: > > For DCB 4.1: For TMDS/LVDS/DP this field describes which links of > the Pad Macro are routed to the connector on the board. > Bit 0: Pad Link 0 > Bit 1: Pad Link 1 > > The SorSetControl index, as used in the supervisor interrupt, indicates > one of the four SORs, and you can refer to the SOR Crossbar configuration > to determine which Macro Link(s) are listening to the SOR Links of > that SOR. From the Macro Links, you should be able to correlate to > DCB entries. > > For an example topology, our reference GTX 980 board has the following layout: > > * Pad links A+B and DAC1 are connected to the DVI-I connector > * Link C (Macro 1 Pad Link 0) is connected to the HDMI-A connector > * Link D (Macro 1 Pad Link 1) is connected to a DP connector > * Link E (Macro 2 Pad Link 0) is connected to a DP connector > * Link F (Macro 2 Pad Link 1) is connected to a DP connector > > Except for DP multi-stream, one SOR should be used to drive a connector.Hm, is this true? I've not looked at MST on GM204 yet, but earlier Keplers it was still one SOR but multiple heads attached to it.> > The setup sequence would normally be: > * Decide which connectors you want to drive. > * Check which link (links for duallink-DVI) to use with that connector, per the DCB.It's this step I was unsure of. The only information channel we currently have between the "user" side of display and the supervisor is what can be pushed through core channel methods. I guess a more explicit way to phrase what I was wanting to know is: Are there any additional methods for the user of core to configure the sor->macro routing, or is this something that is up to the driver to implement however it sees fit? Thanks again! Ben.> * Assign an unused SOR to those link(s) via the NV_PDISP_CLK_REM_LINK_CTRL registers. > * Use SorSetControl to attach a head to that SOR. > > I hope that makes sense. > > Thanks, > - Andy > > >> Thanks, >> Ben. >> >> > >> > Ben. >> > >> >> >> >> I hope that is helpful, >> >> - Andy >> >> >> >> _______________________________________________ >> >> Nouveau mailing list >> >> Nouveau at lists.freedesktop.org >> >> http://lists.freedesktop.org/mailman/listinfo/nouveau