On Mon, Dec 15, 2014 at 07:40:32AM +1000, Ben Skeggs wrote: > On Sat, Dec 13, 2014 at 6:42 PM, Andy Ritger <arit...@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 <skeg...@gmail.com> wrote: > >> > On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger <arit...@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.
Hmm, I'm not sure. Before all of this SOR crossbar complexity, I thought a connector implied a specific SOR? The path would be: multiple heads -> one SOR -> one connector The SOR_SET_CONTROL core channel method (0x00000200) (on >= GF119) has a head mask in bits 0-3, which is how you are supposed to tell the SOR what head(s) to listen to. At least, that is my understanding. > > 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? I think the driver has flexibility to choose, and the choice is relatively arbitrary, beyond satisfying the contraints described in the DCB. Thanks, - Andy > 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@lists.freedesktop.org > >> >> http://lists.freedesktop.org/mailman/listinfo/nouveau _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau