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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 CD999C432C3 for ; Mon, 2 Dec 2019 11:21:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A398F20833 for ; Mon, 2 Dec 2019 11:21:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pQkNeClT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727354AbfLBLV1 (ORCPT ); Mon, 2 Dec 2019 06:21:27 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:42889 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726276AbfLBLV1 (ORCPT ); Mon, 2 Dec 2019 06:21:27 -0500 Received: by mail-lf1-f68.google.com with SMTP id y19so27618506lfl.9 for ; Mon, 02 Dec 2019 03:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yzQY8ysi3fT6Co4/MqtHPbj4fPY/+U/ENbweS9dY9nE=; b=pQkNeClTp2cf5DYqzAKqS48zGZdNUDqc9VZ7tpoKCvLUMnWKlkari52Nb79LdNPm8E WTOtoAFWCysbP4teqhLKD5GSMyi4zP1zomk2lES0NPpsDpSq6qk5X4Y9PA9/7IiCkthS EPGhZxblrCf4u9372E1KKSmCVy/x+2XnKll7AfnCQyoPi/xcuM62orWhXrqdwqDxpAIk xTahI+RAIZI7t8z889baVqjk6B+tztSHvaTWDDGP9ow8cc3HRHbHdhJkdACksUPCxfc8 z27dcPZ6YJfUJ20E0eF0C0Z4pYhqRhMAyyn4RnNjSECWwEimYpST9CdhWXEVNjntMyBx 0egw== 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=yzQY8ysi3fT6Co4/MqtHPbj4fPY/+U/ENbweS9dY9nE=; b=j4R/Mw9uVWN2/TVHD+Rf9lsoQhR4xIinFlcdaToxupZEPRMZZO10vF/a3OYPB3lyHD 0mQsKK+5yMxUb3mjr9ciRYYKSflcF0qUxOmiTfSte9BMUhAgfmZ2ZzejCro8SrD2GmfM E5vfhZTVSZIlUYYHiVYf4saG97dwCEI/bdktaExSBdru1FIQN0vBTdLmNduopjBWkHbO H3SBzCDgfPOSEDUVsamAumdqKqIfoYTO6+bZNIz4BxeIl0XnEsxVbEaWTmVDuFMShd6M /XuCZb1wrGTKmKBWzcIdAMGXP2IblTsKXqyXiexNL2XGxDuNrBquJ0tqgAMEmmPEIacY 6jFQ== X-Gm-Message-State: APjAAAWfMFW/Snk6O+EPa11VKIKp1o95rabmeO8KnSBravx27T3kBpg3 ys0yaEFUgcn7GMvm+gnp6PwupTtmSBf2eliZWfQdSrJursVWvQ== X-Google-Smtp-Source: APXvYqxizDsV6syxLFSpMOqZGIeczavEByhmdDXOVDNV4RRu+SUnOftHbEdPa0gGND2j61UuSk/iw7O6dhtfU4+t6Zk= X-Received: by 2002:a19:f701:: with SMTP id z1mr37022370lfe.133.1575285684598; Mon, 02 Dec 2019 03:21:24 -0800 (PST) MIME-Version: 1.0 References: <20191129185836.2789-1-hdegoede@redhat.com> <20191129185836.2789-3-hdegoede@redhat.com> In-Reply-To: <20191129185836.2789-3-hdegoede@redhat.com> From: Linus Walleij Date: Mon, 2 Dec 2019 12:21:13 +0100 Message-ID: Subject: Re: [PATCH 2/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT To: Hans de Goede Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Mika Westerberg , Andy Shevchenko , Bartosz Golaszewski , intel-gfx , "open list:DRM PANEL DRIVERS" , "open list:GPIO SUBSYSTEM" , ACPI Devel Maling List Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Archived-At: List-Archive: List-Post: Hi Hans, thank you for your patch! On Fri, Nov 29, 2019 at 7:58 PM Hans de Goede wrote: > - /* GPIO Desc for CRC based Panel control */ > + /* GPIO Desc for panel and backlight control */ > struct gpio_desc *gpio_panel; > + struct gpio_desc *gpio_backlight; I think what happens here is that you reimplement drivers/video/backlight/gpio_backlight.c The existing power control GPIO also reimplements drivers/regulator/fixed.c in a sense but I am under the impression that x86 in general and ACPI in particular has a problem with the regulator subsystem so I am uncertain about that one. When I look at the code I get more confused because nominally panels should have their own drivers in drivers/gpu/drm/panel/* especially DSI panels, and the panels control their own GPIOs or regulators for power and backlight. I was under the impression that Heikki's and Dmitry's recent additions to software nodes would make it possible to actually spawn devices like the GPIO backlight and/or fixed regulator and put references to them so that the drivers can pick them up from the respective frameworks and manage them? Maybe I misunderstood things here though, I am a bit under the impression that elder DRM drivers are considered "elder gods" and do not need to use separate panel drivers, backlight abstraction etc, and in that case just go ahead, I guess. But I suspect some separation would help the day the i915 driver wants to reuse some really complex DSI panel from drivers/gpu/drm/panel/* though. Yours, Linus Walleij