From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1124C47082 for ; Fri, 4 Jun 2021 02:33:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD3236140A for ; Fri, 4 Jun 2021 02:33:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229835AbhFDCfh (ORCPT ); Thu, 3 Jun 2021 22:35:37 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:36382 "EHLO mail-wm1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229697AbhFDCfh (ORCPT ); Thu, 3 Jun 2021 22:35:37 -0400 Received: by mail-wm1-f54.google.com with SMTP id n17-20020a7bc5d10000b0290169edfadac9so6976942wmk.1; Thu, 03 Jun 2021 19:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XfVLX4YtEZs428uaQPfb/mY1tDAn6l5ncSwMdycpblI=; b=p5drJ8OPu0/hfTaQXi2OyrCV3UE0/bcH3ckTmA6EC2x2//1neicrguJZw+egplGj7e cbrQ9OpDwX1uZqU9IGP7ncGktMXUx4UviQhIeb20d06j/E5NfmU1+gfXjEag7tXpmj+I i2uG7BIAYtnWU4xdCU0QenmkqC2pTBAEcWq0SuNYcncS1waJTJcR4CZZZqIqul4845tD wlf1Kv9hg49UzNfmMHyN5Geif4mqiUUMBRTbyMWtjpNgrIrS5Npb17wxil5Gpc4cXEhd ye7CeseV4uBnq37kFnGOz1WtIqvJPs60R9aq1HK4S3jxjF2K6Udk3uDqLlPin73no4HA VOUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XfVLX4YtEZs428uaQPfb/mY1tDAn6l5ncSwMdycpblI=; b=SBkL2COSfKlZFpjcGMv8S+RHT9FDsxae/CUdu4s/D3Jwha4KjF+G5hdZ5Nq3s0DhSr 3enptNbtycsTRCseJrHCoFHzLJCzea60XWnEN87N5YAGE4hDPlj9DlQvnw6AKLVcPEIy ICpVHVHOVRfsg1x9AvrNuF0PQN03CqkEpA5ku0kSsZHe5koS4qpQXSg3YyCfmO0RcWdY hSAjTjt2Nd8z16Bnu9ksghvSrY+brB1tplbKyw6iOpihFSTAZOg4HEu5CYhz2hdTB+vz 9Vja0hNYD7+lF/CpxIadlFgw7qITye/YPyZ5D6FBMEUewyGUAgAdSSlbikOZngiLo3Xq Kn5Q== X-Gm-Message-State: AOAM530krPNVFTINSuSHok7K2pt7kYY9iwlLtjele2fnsfJKQDgPJR/y T3mea1cMVk7OANWT+H+IfPqqiVqBoUj1GYML2tE= X-Google-Smtp-Source: ABdhPJxmpIfDqZXuShm76OqWvHKkOU4l5zonimZqTYUKsjU+Sqv/oJyOxy/U8P1238Okoxuj2H3MGCtE1stmFsOfTU4= X-Received: by 2002:a05:600c:2054:: with SMTP id p20mr843886wmg.175.1622773970471; Thu, 03 Jun 2021 19:32:50 -0700 (PDT) MIME-Version: 1.0 References: <20210521124946.3617862-1-vkoul@kernel.org> In-Reply-To: From: Rob Clark Date: Thu, 3 Jun 2021 19:36:42 -0700 Message-ID: Subject: Re: [Freedreno] [RFC PATCH 00/13] drm/msm: Add Display Stream Compression Support To: Vinod Koul Cc: Jeffrey Hugo , DTML , Jonathan Marek , David Airlie , MSM , lkml , Abhinav Kumar , Bjorn Andersson , Rob Herring , "open list:DRM PANEL DRIVERS" , Daniel Vetter , Dmitry Baryshkov , freedreno Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Wed, Jun 2, 2021 at 4:01 AM Vinod Koul wrote: > > On 27-05-21, 16:30, Rob Clark wrote: > > On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo wrote: > > > On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote: > > > > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops. > > > The ACPI assumes the entire MDSS (including DSI parts) and GPU is one > > > device, and ultimately handled by one driver. That driver needs to > > > get a value from UEFI (set by the bootloader) that is the "panel id". > > > Then the driver calls into ACPI (I think its _ROM, but I might be > > > mistaken, doing this from memory) with that id. It gets back a binary > > > blob which is mostly an xml file (format is publicly documented) that > > > contains the panel timings and such. > > > > tbh, I kinda suspect that having a single "gpu" device (which also > > includes venus, in addition to display, IIRC) in the ACPI tables is a > > windowsism, trying to make things look to userspace like a single "GPU > > card" in the x86 world.. but either way, I think the ACPI tables on > > the windows arm laptops which use dsi->bridge->edp is too much of a > > lost cause to even consider here. Possibly ACPI boot on these devices > > would be more feasible on newer devices which have direct eDP out of > > the SoC without requiring external bridge/panel glue. > > yeah that is always a very different world. although it might make sense > to use information in tables and try to deduce information about the > system can be helpful... > > > I'd worry more about what makes sense in a DT world, when it comes to > > DT bindings. > > And do you have thoughts on that..? Only that I wouldn't get too hung up on existing snapdragon ACPI tables.. not sure if there is prior art as far as ACPI tables for this on x86 systems, if so that *might* be a thing to consider, but otherwise it does sound a bit like we want less qcom specific bindings here. But other than that I'll leave it to folks who spend more time thinking about bindings.. left to my own devices I'd come up with a point solution and go back to working on mesa, so that probably isn't the opinion you want to follow ;-) BR, -R From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2271C47096 for ; Fri, 4 Jun 2021 02:32:54 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7455461407 for ; Fri, 4 Jun 2021 02:32:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7455461407 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AE1B26F566; Fri, 4 Jun 2021 02:32:53 +0000 (UTC) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by gabe.freedesktop.org (Postfix) with ESMTPS id E45186F565; Fri, 4 Jun 2021 02:32:51 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id v206-20020a1cded70000b02901a586d3fa23so473729wmg.4; Thu, 03 Jun 2021 19:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XfVLX4YtEZs428uaQPfb/mY1tDAn6l5ncSwMdycpblI=; b=p5drJ8OPu0/hfTaQXi2OyrCV3UE0/bcH3ckTmA6EC2x2//1neicrguJZw+egplGj7e cbrQ9OpDwX1uZqU9IGP7ncGktMXUx4UviQhIeb20d06j/E5NfmU1+gfXjEag7tXpmj+I i2uG7BIAYtnWU4xdCU0QenmkqC2pTBAEcWq0SuNYcncS1waJTJcR4CZZZqIqul4845tD wlf1Kv9hg49UzNfmMHyN5Geif4mqiUUMBRTbyMWtjpNgrIrS5Npb17wxil5Gpc4cXEhd ye7CeseV4uBnq37kFnGOz1WtIqvJPs60R9aq1HK4S3jxjF2K6Udk3uDqLlPin73no4HA VOUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XfVLX4YtEZs428uaQPfb/mY1tDAn6l5ncSwMdycpblI=; b=M5fqAk0cLQxvghFMoBHmiEApZkTeY9L+xFEnvvasdmMN0Jtzp2mFC5pPTJW81slH/D 8H3pdpDcaHqZgCEvSCYGP9vGhD7Xo3xRy8OQ+VfH1hzWkggymWUAtav5tBHUw+q0/dkX u/KQJz5DJlm4ZfMf1wik+WxZ2qPI7s6R4KG+UtNMWc/3rDUAzNmPmgSkxsk03VcSkI6y eqHTGliOS+xyYZUgdxMS7sEZ4XUdadsvvAQc1FK0j1sMz+4EeTJbS/3589gshKA62xZE ysmgqbdP8q8+lxlNQbS14fKIIwP7/w4O4+Hbw5o+Qe/PlbzJB4eR1I7QiZ0Mr9MCpGMe oY+A== X-Gm-Message-State: AOAM531o+oSwzpf7UZSYrb1FKIqByRY53e7KVy5fHIdpIFE2yTQqWluH LnodIYhiRIe7X7EIIGRHigtgs0GSZqYGiFxcNak= X-Google-Smtp-Source: ABdhPJxmpIfDqZXuShm76OqWvHKkOU4l5zonimZqTYUKsjU+Sqv/oJyOxy/U8P1238Okoxuj2H3MGCtE1stmFsOfTU4= X-Received: by 2002:a05:600c:2054:: with SMTP id p20mr843886wmg.175.1622773970471; Thu, 03 Jun 2021 19:32:50 -0700 (PDT) MIME-Version: 1.0 References: <20210521124946.3617862-1-vkoul@kernel.org> In-Reply-To: From: Rob Clark Date: Thu, 3 Jun 2021 19:36:42 -0700 Message-ID: Subject: Re: [Freedreno] [RFC PATCH 00/13] drm/msm: Add Display Stream Compression Support To: Vinod Koul Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , Jonathan Marek , Jeffrey Hugo , David Airlie , MSM , lkml , Abhinav Kumar , Bjorn Andersson , Rob Herring , "open list:DRM PANEL DRIVERS" , Dmitry Baryshkov , freedreno Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jun 2, 2021 at 4:01 AM Vinod Koul wrote: > > On 27-05-21, 16:30, Rob Clark wrote: > > On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo wrote: > > > On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote: > > > > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops. > > > The ACPI assumes the entire MDSS (including DSI parts) and GPU is one > > > device, and ultimately handled by one driver. That driver needs to > > > get a value from UEFI (set by the bootloader) that is the "panel id". > > > Then the driver calls into ACPI (I think its _ROM, but I might be > > > mistaken, doing this from memory) with that id. It gets back a binary > > > blob which is mostly an xml file (format is publicly documented) that > > > contains the panel timings and such. > > > > tbh, I kinda suspect that having a single "gpu" device (which also > > includes venus, in addition to display, IIRC) in the ACPI tables is a > > windowsism, trying to make things look to userspace like a single "GPU > > card" in the x86 world.. but either way, I think the ACPI tables on > > the windows arm laptops which use dsi->bridge->edp is too much of a > > lost cause to even consider here. Possibly ACPI boot on these devices > > would be more feasible on newer devices which have direct eDP out of > > the SoC without requiring external bridge/panel glue. > > yeah that is always a very different world. although it might make sense > to use information in tables and try to deduce information about the > system can be helpful... > > > I'd worry more about what makes sense in a DT world, when it comes to > > DT bindings. > > And do you have thoughts on that..? Only that I wouldn't get too hung up on existing snapdragon ACPI tables.. not sure if there is prior art as far as ACPI tables for this on x86 systems, if so that *might* be a thing to consider, but otherwise it does sound a bit like we want less qcom specific bindings here. But other than that I'll leave it to folks who spend more time thinking about bindings.. left to my own devices I'd come up with a point solution and go back to working on mesa, so that probably isn't the opinion you want to follow ;-) BR, -R