search for: i2c_index

...--git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 195ecb3..01ef97e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -5259,6 +5259,17 @@ fixup_legacy_connector(struct nvbios *bios) if (dcb->entry[i].i2c_index == 0xf) continue; + /* + * Ignore the I2C index for on-chip TV-out, as there + * are cards with bogus values (nv31m in bug 23212), + * and it's otherwise useless. + */ + if (dcb->entry[i].type == OUTPUT_TV && + dcb->entry[i].location == DCB_LOC_ON_CHIP) { +...

...nv_output_restore, - .mode_valid = nv_output_mode_valid, + .mode_valid = nv_output_lvds_mode_valid, .mode_fixup = nv_output_mode_fixup, .mode_set = nv_output_mode_set, .detect = nv_output_lvds_detect, @@ -707,6 +725,37 @@ static void nv_add_analog_output(ScrnInfoPtr pScrn, int i2c_index) pNv->analog_count++; } +static void nv_add_lvds_output(ScrnInfoPtr pScrn, int i2c_index) +{ + NVPtr pNv = NVPTR(pScrn); + xf86OutputPtr output; + NVOutputPrivatePtr nv_output; + char outputname[20]; + int crtc_mask = (1<<0) | (1<<1); + + sprintf(outputname, &quo...

--- drivers/gpu/drm/nouveau/nouveau_bios.c | 47 ++++++++++++++----------------- 1 files changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 5eec5ed..04ac564 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -181,43 +181,42 @@ struct methods { const char

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

...IOS init table 1 at offset 0xC546 (--) NOUVEAU(0): Parsing VBIOS init table 2 at offset 0xD32A (--) NOUVEAU(0): Parsing VBIOS init table 3 at offset 0xD44C (--) NOUVEAU(0): Parsing VBIOS init table 4 at offset 0xD67C (II) NOUVEAU(0): NV50DispPreInit is called. (--) NOUVEAU(0): DCB entry 0: type: 0, i2c_index: 0, heads: 3, bus: 0, or: 2 (II) NOUVEAU(0): I2C bus "DVI-0" initialized. (II) NOUVEAU(0): DAC-1 attached with index 0 to DVI-0 (--) NOUVEAU(0): DCB entry 1: type: 2, i2c_index: 0, heads: 3, bus: 0, or: 1 (II) NOUVEAU(0): SOR-0 attached with index 1 to DVI-0 (--) NOUVEAU(0): DCB entry 2:...

The patches contain some tidy-up work, and refactoring that has arisen as a by-product of my initial work on adding TV support to nv50. Joel Holdsworth (4): drm/nouveau: Removed unneeded include in nvc0_fence.c drm/nouveau: Replaced magic numbers with defines from nouveau_reg drm/nouveau: Replaced copy-pasted nv_wait with nv50_wait_dpms_ctrl helper drm/nouveau: Refactored encoder

...ers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1714,6 +1714,9 @@ nv50_sor_create(struct drm_connector *connector, struct dcb_output *dcbe) struct nv50_disp *disp = nv50_disp(encoder->dev); struct nvkm_i2c_aux *aux = nvkm_i2c_aux_find(i2c, dcbe->i2c_index); + u32 caps = nvif_rd32(&disp->disp->object, + 0x00640144 + (nv_encoder->or * 8)); + if (aux) { if (disp->disp->object.oclass < GF110_DISP) { /* HW has no support for address-only @@ -1727,13 +1730,17 @@ nv50_sor_create(struct drm_connector *connector, st...

...init table 4 at offset 0xD954 (EE) NOUVEAU(0): ========== unknown reg 0x00020000 ========== (EE) NOUVEAU(0): ========== unknown reg 0x00020004 ========== (EE) NOUVEAU(0): ========== unknown reg 0x00020074 ========== (II) NOUVEAU(0): NV50DispPreInit is called. (--) NOUVEAU(0): DCB entry 0: type: 0, i2c_index: 0, heads: 3, bus: 0, or: 2 (II) NOUVEAU(0): I2C bus "DVI-0" initialized. (II) NOUVEAU(0): DAC-1 attached with index 0 to DVI-0 (--) NOUVEAU(0): DCB entry 1: type: 2, i2c_index: 0, heads: 3, bus: 0, or: 1 (II) NOUVEAU(0): SOR-0 attached with index 1 to DVI-0 (--) NOUVEAU(0): DCB entry 2:...

From: Ville Syrjälä <ville.syrjala at linux.intel.com> We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: nouveau at lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM