On Thu, Jun 17, 2010 at 9:39 PM, Matt Turner <matts...@gmail.com> wrote: > I'm working on modesetting, and I'm kind of unsure how to proceed. > > My repository is here (ignore all the commit dates): > http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary > > I've filled out struct drm_crtc_funcs in glint_crtc.c, except for > cursor_{set,move} (I think I can ignore them for the time being, > right?), and think filling out drm_crtc_helper_funcs is probably the > next step. Locally, I've implemented glint_crtc_dpms, since it gets > called by various other drm_crtc_helper_funcs.
You can ignore the cursor stuff for now. drm_crtc_helper_funcs is the next logical step. You also need to fill in the encoder and connector bits. Based on a brief look at the glint ddx, it looks like you can get away with a DAC (encoder) and VGA (connector). It looks like some cards support flat panels, but you can tackle that later. > > I'm unsure what mode_fixup is, exactly. Alex tells me on IRC that it's > for scaling, which is what the radeon driver does with it. > nv04_crtc.c:nv_crtc_mode_fixup and nv50_crtc.c:nv50_crtc_mode_fixup do > nothing except returning true though. Why? > intel_display.c:intel_crtc_mode_fixup looks like it checks some clocks > or something. I'm not sure what needs to happen in this function, so > please give hints as to what my driver should be doing here. Both crtcs and encoders have a fixup function. The function is just a chance for the driver to make any changes it needs to the mode to handle certain situations like scaling. Both the crtcs and the encoders have a chance to fixup the mode. This lets you work around hw limitations for example. If a particular encoder and crtc combination has a problem with the proposed mode, it can either fix it up if possible, or return false in which case the modeset would fail. For now it's safe to just return true. > > The biggest piece of implementing drm_crtc_helper_funcs is mode_set. > I've got drivers/video/pm3fb.c in the kernel for reference and the > -glint DDX, so I think I can figure out how to program the clocks, but > trying to figure out the other things that need to happen in mode_set > are getting me. The intel driver's intel_crtc_mode_set is an example > of a function that needs to be split for clarity (600 lines). The > radeon driver's radeon_crtc_mode_set is pretty clear, and calls > radeon_mode_set_base which looks like it's setting up the scanout > buffer for fbcon. Since I haven't done memory management yet, a nudge > in the the right direction here would be nice as well. Take a look at drm_crtc_helper_set_mode() in drm_crtc_helper.c. That function gives you the modeset flow and how the driver hooks are used. You'll need some basic memory management in order to allocate a framebuffer to point your crtc at. The abstraction looks like: buffer -> crtc -> encoder -> connector in your case it would be: vram -> crtc -> DAC -> VGA Modesetting is basically broken down into 3 parts: 1. prepare 2. modeset 3. commit Both crtcs and encoders have to fill in those functions. Prepare allows the driver to do anything special it needs before setting the mode. Most drivers just call the dpms function and turn off the crtc or encoder. Modeset does the actual mode set. In the crtc case it sets the crtc timing, the pixel clock (pll), and the crtc base (offset in vram where the crtc scans out from). In the encoder case, it sets up the encoder for mode set; e.g., crtc routing (send crtc0 data to DAC2, etc.), encoder format setup, etc. For a DAC there's no usually much to be done; generally DACs are just on or off, so you could just have an empty encoder modeset function and then turning it off and on in the dpms hook which would be called by the prepare/commit hooks. Commit allows the driver to do something special after modeset. Most drivers just call the dpms function and turn the encoder or crtc on. > > Also, at what point do I need to setup encoders/connectors? It looks > like some of these functions are being called by functions in > drm_crtc_helper_funcs. You'll need to set them up before you can set modes. > > For both my ability to understand, and for the latter part of the > project, the documentation and tutorial/guides, I'd like to make as > small and incremental changes as possible. Ideally, add a few > functions, be able to see some new growth in the driver. Is there any > milestone I can hit here before going all the way to framebuffer > console? It'd be nice to be able to verify functions like > glint_crtc_load_lut or glint_crtc_dpms work correctly before I add a > bunch more code that depends on them. Might be useful to implement something like radeontool; a little C-app that you can use to mmap the register BAR and manually bang on regs. Then try stuff with with the ddx loaded and see how it reacts. It also may be helpful to break up the ddx init (equivalent to the kms crtc and encoder modeset functions combined) and adjust frame (equivalent to the kms crtc set base function) functions into logical parts that would map to the kms abstractions. Looking at Permedia3Init() in the ddx you have roughly the following ordering (although things are a bit mixed up): - set the crtc timing - calculate and set the pll - dac/flat panel setup Alex ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
