search for: nv_arch

The nv31m in bug 23212 claims its TV-out and LVDS are in the same connector. Ignore it completely as it's otherwise useless. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c

..."vpll: n %d m %d log2p %d\n", pv->N1, pv->M1, pv->log2P); - nouveau_calc_arb(dev, vclk, fb->bits_per_pixel, &arb_burst, &arb_fifo_lwm); - - regp->CRTC[NV_CIO_CRE_FF_INDEX] = arb_burst; - regp->CRTC[NV_CIO_CRE_FFLWM__INDEX] = arb_fifo_lwm & 0xff; - if (nv_arch(dev) >= NV_30) - regp->CRTC[NV_CIO_CRE_47] = arb_fifo_lwm >> 8; - nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset); } @@ -775,10 +765,12 @@ nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, struct drm_framebuffer *old_fb) { struct nouveau_crtc *n...

On 26/09/13 23:37, Pavel Roskin wrote: > Hello! > > I have spent some time on the issue. I'm not sure it's a nouveau bug. > I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. > > GRUB actually uses graphic mode on my card. That mode is supported by > simplefb. However, the resource conflict happens regardless of whether > simplefb is enabled.

...= 0x100, + NOUVEAU_REG_DEBUG_VGAATTR = 0x200, +}; + +#define NV_REG_DEBUG(type, dev, fmt, arg...) do { \ + if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_##type) \ + NV_PRINTK(KERN_DEBUG, dev, "%s: " fmt, __func__, ##arg); \ +} while (0) + static inline enum nouveau_card_type nv_arch(struct drm_device *dev) { diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.h b/drivers/gpu/drm/nouveau/nouveau_hw.h index 129345e..a1880c4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_hw.h +++ b/drivers/gpu/drm/nouveau/nouveau_hw.h @@ -59,14 +59,14 @@ static inline uint32_t nvReadMC(struct drm_dev...

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

...ttributes +}; + +int nouveau_thermal_init(struct drm_device *dev) +{ + struct drm_nouveau_private *dev_priv = dev->dev_private; + int err; + + nouveau_thermal_i2c_create(dev); + + if (dev_priv->chipset >= 0x84) + dev_priv->get_gpu_temperature = nouveau_thermal_g84_read_temp; + else if (nv_arch(dev) == NV_50) + dev_priv->get_gpu_temperature = nouveau_thermal_nv50_read_temp; + else if (nv_arch(dev) == NV_40) + dev_priv->get_gpu_temperature = nouveau_thermal_nv40_read_temp; + + if (dev_priv->get_gpu_temperature) { + dev_priv->hwmon_dev = hwmon_device_register(&dev->pde...

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

...e_unneeded_entities --device-c --gen_c_file_name "/tmp/tmpxft_00007040_00000000-4_cuda_id_test.cudafe1.c" --stub_file_name "/tmp/tmpxft_00007040_00000000-4_cuda_id_test.cudafe1.stub.c" --gen_device_file_name "/tmp/tmpxft_00007040_00000000-4_cuda_id_test.cudafe1.gpu" --nv_arch "compute_35" --gen_module_id_file --module_id_file_name "/tmp/tmpxft_00007040_00000000-3_cuda_id_test.module_id" --include_file_name "tmpxft_00007040_00000000-2_cuda_id_test.fatbin.c" "/tmp/tmpxft_00007040_00000000-9_cuda_id_test.cpp1.ii" #$ gcc -std=c++11 -...

...nvidiafb doesn't report that the resource is busy, it reports unsupported hardware, which is true. Old patch: nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref] nvidiafb: cannot request PCI regions New patch: nvidiafb: Device ID: 10de0ffc nvidiafb: unknown NV_ARCH I'll send the patch to x86 at kernel.org, it's clearly not an nvidia issue. -- Regards, Pavel Roskin

Hi Pavel On Fri, Oct 4, 2013 at 12:10 AM, Pavel Roskin <proski at gnu.org> wrote: > Hi David, > > On Thu, 3 Oct 2013 00:19:56 +0200 > David Herrmann <dh.herrmann at gmail.com> wrote: > >> >> And your PCI-BAR adjustment doesn't change >> >> anything either, sorry. >> > >> > I simply tried another approach to pacify the

...nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref] dm-busy-noadjust:nvidiafb: cannot request PCI regions dm-nobusy-adjust:nvidiafb_setup START dm-nobusy-adjust:nvidiafb_probe START dm-nobusy-adjust:nvidiafb: Device ID: 10de0ffc dm-nobusy-adjust:nvidiafb: unknown NV_ARCH dm-nobusy-noadjust:nvidiafb_setup START dm-nobusy-noadjust:nvidiafb_probe START dm-nobusy-noadjust:nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref] dm-nobusy-noadjust:nvidiafb: cannot request PCI regions The error comes from pci_request_regions() called in dri...

...s busy, it reports > unsupported hardware, which is true. > > Old patch: > nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff > 64bit pref] > nvidiafb: cannot request PCI regions > > New patch: > nvidiafb: Device ID: 10de0ffc > nvidiafb: unknown NV_ARCH > > I'll send the patch to x86 at kernel.org, it's clearly not an nvidia issue. > > -- > Regards, > Pavel Roskin

--- src/drmmode_display.c | 29 +++++++++++++++++-- src/nouveau_hw.h | 17 +++++++++++ src/nv_cursor.c | 74 ++++++++++++++++++++++++------------------------ src/nv_proto.h | 2 + 4 files changed, 82 insertions(+), 40 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index f2fe0e8..7acddf1 100644 --- a/src/drmmode_display.c +++

...xc0000000-0xd7ffffff] [ 5.377443] pci 0000:00:03.0: PCI bridge to [bus 02] [ 5.382465] pcieport 0000:00:02.0: enabling device (0140 -> 0143) [ 5.388761] nvidiafb 0000:01:00.0: enabling device (0140 -> 0143) [ 5.394962] nvidiafb: Device ID: 10de0614 [ 5.399065] nvidiafb: unknown NV_ARCH [ 5.403220] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 5.410108] armada38x-rtc f10a3800.rtc: setting system clock to 2018-01-21 13:19:33 UTC (1516540773) [ 5.419360] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 5.428629] cfg80211: Loaded...