Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp10748711imu; Thu, 6 Dec 2018 06:14:15 -0800 (PST) X-Google-Smtp-Source: AFSGD/U71kawy6wsapDVVVb28R3Ycpp97woB/a8VNTeRKX5xiv/aBihwHw1qmTDsiz0GqnqukCN+ X-Received: by 2002:a63:1b48:: with SMTP id b8mr23178249pgm.187.1544105655565; Thu, 06 Dec 2018 06:14:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544105655; cv=none; d=google.com; s=arc-20160816; b=zC79957uwZNHhdxIzrng2+9SSc5dluKYqudQ9VQvJxKGsfNm1+sp7t2sCvlVyNDesI /95QlZUhaxi286AX4MsPp/hz/M9dliNdURatooi3l6EBCdcDo9v8uLdtcx3dJpl8DBvc BSomdt8ro+LdyYKNwT5xGtvxDxjcCFrwmNIGVqRK7OuTCkQ3mYuMPaJYmey1fVY4nho3 aW/XBVJ4WESxn5ny/HNpazlx0TfvcdG7TUA0HTk9sU8G8rh+iJKxLWZGuj2gOnRAQgar MCOV37R5aZ2ifofDBOPxrMu6gvtxq7V9EngNyOjthRPDVKGaq+ESrCcfYoZtznDwOXbG pSnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date; bh=cHlo0w7tSaw6qulyyLZrDw4039FYEEek2+uLl+wK9No=; b=li+2M7wHR2sS3wx9YbO/dx9IU0lnl2A4co8f80xOC+3TYgAcETmLGzGTksei2CLjpf meWMaGs6mEBxu5BW3AAFi49o6BBFkqv3+6NUSuUEBN5lgHCJfTH6TdJG8Pm/7KI7RF47 26W1rmCSC8HNZVrp4ws0FYTzYWHwib6/E/GG7QH7R2hywRx2LUC/fMhiAv2p2AyLpr5T CEy0FDmlnV1USfMH3KmVXN8TxyaHu24wdwyfYgQKdHK/D0QNSQA+hl/rYNox8C8aA570 nPZBXePcGJxs3sNbyEAGGiWC4xxr+e12rSlMs/FzUoxdZLC0EhnZuWKXD99dRHKuCAkG 8/NQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l17si375083pfd.236.2018.12.06.06.14.00; Thu, 06 Dec 2018 06:14:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729759AbeLFOKT (ORCPT + 99 others); Thu, 6 Dec 2018 09:10:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729140AbeLFOKQ (ORCPT ); Thu, 6 Dec 2018 09:10:16 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6C053308ED4B; Thu, 6 Dec 2018 14:10:16 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4C0235FC38; Thu, 6 Dec 2018 14:10:16 +0000 (UTC) Received: from zmail25.collab.prod.int.phx2.redhat.com (zmail25.collab.prod.int.phx2.redhat.com [10.5.83.31]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 23BDC3F600; Thu, 6 Dec 2018 14:10:16 +0000 (UTC) Date: Thu, 6 Dec 2018 09:10:15 -0500 (EST) From: Frediano Ziglio To: Gerd Hoffmann Cc: dri-devel@lists.freedesktop.org, David Airlie , David Airlie , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" , open list , "open list:DRM DRIVER FOR QXL VIRTUAL GPU" Message-ID: <621894308.48603466.1544105415949.JavaMail.zimbra@redhat.com> In-Reply-To: <20181206134933.krvdvoz52lkpewb5@sirius.home.kraxel.org> References: <20181206103352.20587-1-kraxel@redhat.com> <207905511.48580418.1544093965441.JavaMail.zimbra@redhat.com> <20181206114217.vog4fgae73us437u@sirius.home.kraxel.org> <1902655248.48590444.1544100790071.JavaMail.zimbra@redhat.com> <20181206134933.krvdvoz52lkpewb5@sirius.home.kraxel.org> Subject: Re: [Spice-devel] [PATCH] drm/qxl: use qxl_num_crtc directly MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.33.32.16, 10.4.195.9] Thread-Topic: drm/qxl: use qxl_num_crtc directly Thread-Index: PNogfT/N1orZKoCW2mQLaGGRRqs83Q== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Thu, 06 Dec 2018 14:10:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On Thu, Dec 06, 2018 at 07:53:10AM -0500, Frediano Ziglio wrote: > > > > > > On Thu, Dec 06, 2018 at 05:59:25AM -0500, Frediano Ziglio wrote: > > > > > > > > > > Just use qxl_num_crtc directly everywhere instead of using > > > > > qdev->monitors_config->max_allowed. Drops pointless indirection > > > > > and also is less confusing. > > > > > > > > > > > > > To me is MORE confusing, why comparing number of something with > > > > another number? Previously code was comparing number of monitors > > > > with number of monitors, not number of CRTs with number of > > > > monitors. > > > > > > Yes, spice/qxl and drm/kms use slightly different terminology. > > > > > > drm crtc == qxl monitor. > > > drm framebuffer == qxl surface. > > > > > > You need to know that anyway when looking at the qxl ksm code. We > > > have function names like qxl_crtc_update_monitors_config(). I fail > > > to see why that is a problem ... > > > > > > cheers, > > > Gerd > > > > I don't see any problem too but you are explaining to me > > why your rationale "and also is less confusing" does not > > stand. > > Well, it's less confusing because it takes away an indirection (not > because of the naming). > It does not confuse me. > qdev->monitors_config->max_allowed is effectively set by a module > parameter. So using the module parameter variable qxl_num_crtc > directly is better IMO. The kernel doesn't need to dereference pointers > each time it needs the value, and when reading the code you don't have > to trace where and why qdev->monitors_config->max_allowed is set. > That should go to the commit message! With that the patch is fine for me. Maybe there's no much point on reusing the same structure used inside QXLRom/QXLRam but this is OT for this patch. > cheers, > Gerd > > Frediano