search for: sors

...signment 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. >...

...s 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? Thanks, Ben. > > Ben. > >> >> I hope that is helpful, >> - Andy >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedeskto...

...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 Resourc...

I have one fixed effect, sor, with two levels. I have eight lots and three wafers from each lot. I have included the data below. I would like to fit a mixed model that estimates a covariance parameter for wafer, which is nested in lot, and two covariance parameters for lot, one for each level of sor. The following command fits the model that I want, except for it estimates the correlation

https://bugs.freedesktop.org/show_bug.cgi?id=89272 Bug ID: 89272 Summary: GM206 does not recognize attached hdmi monitor Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hi Ben, still _assuming_ it's an issue of the card I thought about why it works with the NVIDIA binary driver. And I can image they're just trying to do an identity-mapping first and if that doesn't work (e.g. the particular SOR is already in use by another macro link) they just pick the next suitable one. So the case would be that the NVIDIA binary driver always assignes the only

On 2018-02-05 02:39, Ben Skeggs wrote: > On 5 February 2018 at 11:37, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 5 February 2018 at 11:22, Danilo Krummrich >> <danilokrummrich at dk-develop.de> wrote: >>> On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link >>> 'G' (outp index 7) causes failures: >>> >>> [

https://bugs.freedesktop.org/show_bug.cgi?id=60680 Priority: medium Bug ID: 60680 Assignee: nouveau at lists.freedesktop.org Summary: HDMI is connected and has mode, TV says "no signal" QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter:

<adding nouveau-devel to the Cc> Hi Ben, On 02-03-16 04:23, Ben Skeggs wrote: > On 03/01/2016 09:37 PM, Hans de Goede wrote: <snip> >> Ok, I've but an mmiotrace of the blob starting with a monitor connected >> to the troubesome connector here: >> >> https://fedorapeople.org/~jwrdegoede/mmiotrace.log.xz >> >> And a demmio-ed version (with

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar routing should be possible, such that any SOR sublink can drive any macro link. Unfortunately, there's at least one card where some SOR sublinks being connected to a particular macro link are causing failures. To work around this issue, supply a quirk for such cards which prevents a dynamic mapping of SOR sublink and macro link

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar routing should be possible, such that any SOR sublink can drive any macro link. Unfortunately, there's at least one card where some SOR sublinks being connected to a particular macro link are causing failures. To work around this issue, supply a quirk for such cards which prevents a dynamic mapping of SOR sublink and macro link

The values are already stored on chipset specific basis in the ctor. Make the most of them and simplify the code further by using a temporary variable to avoid code duplication. Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- Found this patch laying around in a local branch. While the it does not reduce the number of lines, I believe that it makes the code is alot more

The tegra driver uses empty implementations for its encoders. Replace the code with the generic simple encoder. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/tegra/drm.h | 2 -- drivers/gpu/drm/tegra/dsi.c | 10 +++------- drivers/gpu/drm/tegra/hdmi.c | 9 +++------ drivers/gpu/drm/tegra/output.c | 6 +----- drivers/gpu/drm/tegra/rgb.c | 8

On Mon, Feb 5, 2018 at 12:19 PM, Danilo Krummrich <danilokrummrich at dk-develop.de> wrote: > On 2018-02-05 02:39, Ben Skeggs wrote: >> >> On 5 February 2018 at 11:37, Ben Skeggs <skeggsb at gmail.com> wrote: >>> >>> On 5 February 2018 at 11:22, Danilo Krummrich >>> <danilokrummrich at dk-develop.de> wrote: >>>>

On 5 February 2018 at 11:22, Danilo Krummrich <danilokrummrich at dk-develop.de> wrote: > On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link > 'G' (outp index 7) causes failures: > > [ 6.712111] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 61c880 [ IBUS ] > [ 6.724888] nouveau 0000:01:00.0: disp: intr24 80000000 > [ 8.716668]

Dear r-help, I have a matrix, suppose, 10x10, and I need the matrix 5x5, having in each cell a mean value of the cells from the initial matrix. Please, point me to a function in R, which can help me doing that. Digging the documentation and mail archives didn't give me a result. Thank you. --- Best regards, Vladimir mailto:wl at eimb.ru

On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link 'G' (outp index 7) causes failures: [ 6.712111] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 61c880 [ IBUS ] [ 6.724888] nouveau 0000:01:00.0: disp: intr24 80000000 [ 8.716668] nouveau 0000:01:00.0: DRM: base-0: timeout [ 10.716679] nouveau 0000:01:00.0: DRM: base-1: timeout [ 63.511862] nouveau

On 5 February 2018 at 11:37, Ben Skeggs <skeggsb at gmail.com> wrote: > On 5 February 2018 at 11:22, Danilo Krummrich > <danilokrummrich at dk-develop.de> wrote: >> On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link >> 'G' (outp index 7) causes failures: >> >> [ 6.712111] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at

http://bugs.freedesktop.org/show_bug.cgi?id=27398 Summary: displayport: x server does not draw anything on ThinkPad T410 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo:

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware