[Nouveau] DCB 4.1 spec update
Andy Ritger
aritger at nvidia.com
Mon Dec 15 09:45:39 PST 2014
On Mon, Dec 15, 2014 at 07:40:32AM +1000, Ben Skeggs wrote:
> 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.
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 at lists.freedesktop.org
> >> >> http://lists.freedesktop.org/mailman/listinfo/nouveau
More information about the Nouveau
mailing list