Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3085558pxb; Fri, 4 Feb 2022 00:30:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJzxjhQrmPVD9Y4uhIUpjSYHwdB6yUUOxFAcDwdR/PYcH4yNf0T49SuLHN+P2XX64jOlneYp X-Received: by 2002:a17:907:7f1c:: with SMTP id qf28mr1506369ejc.94.1643963459725; Fri, 04 Feb 2022 00:30:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643963459; cv=none; d=google.com; s=arc-20160816; b=JiEYKVhQOedYeoylmiTOGCpETs1tswFiXVbxcsPICyjBUwL0el31ep3dVS1leUauxD xikSTw3Qdq2f8ZV8W3mou4p2B7o6jwkPgB/pUk9Iv/8Cdxw91981RclZba08r8YprolG jOBwAD3Z65xrRPouuMsj0ftN3WGlH7BLwH7RhnyqLjKcfHAWwduFWfOljO3rwoOIxNz5 8uW8MJG2p6qi464Jf8wBW6FcYMTFlcwogRWKi+ssflngtWkh3SILQ2mWabf8Vacqohpm h97ylc47LAJZrLaXCWrhvuctwOUM0ii9z1+b8rSSI+tLL77byU65R+y4I8O4CDtE83rY J+LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:sender:hmm_source_type:hmm_attache_num :hmm_source_ip; bh=sohNudfTbgB3caNcWvmuerZQGVlAzgF9jbg2nb1RaZs=; b=IfvohT0e1O5YDnPa+G+ORScn8C5lbYgu4Mfp5nSfLV/tziEv0bvAKpiJbY7iGbM8kc kQpvgX8cQZSdpQZpP1WCjg94p13XONHpFHjIi9Izfcz3eEIryBhPmkNWbw9uS95Do2d2 Hg/Q9bbS5ObVb8t9Agcd4xJDTVXdL6muHvVHKO01ri2UwhJ061h+jcdb3rzW+jFl1lgQ wlmsjfPFO8eS/xsTmgAOdyz8HeInnTvV9N3TVA0stn8sS0VuVwQXOYJfZWaBe05/KUuO a8iWdUPBkou9J5gIKh8kjw6Uwhto7xL2pTym/MhgdzsaVUNCp28etjzZCOXMr1Iq/jMS QeuQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e27si756977ejl.395.2022.02.04.00.30.33; Fri, 04 Feb 2022 00:30:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351778AbiBCPrY (ORCPT + 99 others); Thu, 3 Feb 2022 10:47:24 -0500 Received: from ptr.189.cn ([183.61.185.101]:11376 "EHLO 189.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1344963AbiBCPrW (ORCPT ); Thu, 3 Feb 2022 10:47:22 -0500 HMM_SOURCE_IP: 10.64.8.41:58618.813769924 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.242.206.180 (unknown [10.64.8.41]) by 189.cn (HERMES) with SMTP id 2E9991001AF; Thu, 3 Feb 2022 23:47:18 +0800 (CST) Received: from ([114.242.206.180]) by gateway-151646-dep-b7fbf7d79-9vctg with ESMTP id 03f015533ad84bf7b23a2b34974ce730 for maxime@cerno.tech; Thu, 03 Feb 2022 23:47:20 CST X-Transaction-ID: 03f015533ad84bf7b23a2b34974ce730 X-Real-From: 15330273260@189.cn X-Receive-IP: 114.242.206.180 X-MEDUSA-Status: 0 Sender: 15330273260@189.cn Message-ID: <57805e19-285a-76d3-16e3-09a3eb7a9540@189.cn> Date: Thu, 3 Feb 2022 23:47:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller Content-Language: en-US To: Maxime Ripard Cc: Dan Carpenter , Lucas Stach , Maarten Lankhorst , Roland Scheidegger , Zack Rusin , Christian Gmeiner , David Airlie , Daniel Vetter , Rob Herring , Thomas Bogendoerfer , Krzysztof Kozlowski , Andrey Zhizhikin , Sam Ravnborg , suijingfeng , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Randy Dunlap References: <20220203082546.3099-1-15330273260@189.cn> <20220203082546.3099-2-15330273260@189.cn> <20220203085851.yqstkfgt4dz7rcnw@houat> From: Sui Jingfeng <15330273260@189.cn> In-Reply-To: <20220203085851.yqstkfgt4dz7rcnw@houat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/2/3 16:58, Maxime Ripard wrote: >> diff --git a/drivers/gpu/drm/lsdc/Kconfig b/drivers/gpu/drm/lsdc/Kconfig >> new file mode 100644 >> index 000000000000..7ed1b0fdbe1b >> --- /dev/null >> +++ b/drivers/gpu/drm/lsdc/Kconfig >> @@ -0,0 +1,38 @@ >> +config DRM_LSDC >> + tristate "DRM Support for loongson's display controller" >> + depends on DRM && PCI >> + depends on MACH_LOONGSON64 || LOONGARCH || MIPS || COMPILE_TEST >> + select OF >> + select CMA if HAVE_DMA_CONTIGUOUS >> + select DMA_CMA if HAVE_DMA_CONTIGUOUS >> + select DRM_KMS_HELPER >> + select DRM_KMS_FB_HELPER >> + select DRM_GEM_CMA_HELPER >> + select VIDEOMODE_HELPERS >> + select BACKLIGHT_PWM if CPU_LOONGSON2K >> + select I2C_GPIO if CPU_LOONGSON2K >> + select I2C_LS2X if CPU_LOONGSON2K >> + default m >> + help >> + This is a KMS driver for the display controller in the LS7A1000 >> + bridge chip and LS2K1000 SoC. The display controller has two >> + display pipes and it is a PCI device. >> + When using this driver on LS2K1000/LS2K0500 SoC, its framebuffer >> + is located at system memory. >> + If "M" is selected, the module will be called lsdc. >> + >> + If in doubt, say "Y". >> + >> +config DRM_LSDC_VRAM_DRIVER >> + bool "vram helper based device driver support" >> + depends on DRM_LSDC >> + select DRM_VRAM_HELPER >> + default y >> + help >> + When using this driver on LS7A1000 + LS3A3000/LS3A4000/LS3A5000 >> + platform, the LS7A1000 bridge chip has dedicated video RAM. Using >> + "lsdc.use_vram_helper=1" in the kernel command line will enable >> + this driver mode and then the framebuffer will be located at the >> + VRAM at the price of losing PRIME support. >> + >> + If in doubt, say "Y". > This doesn't sound right. The driver should make the proper decision > depending on the platform, not the user or the distribution. The LS7A1000 north bridge chip has dedicated video RAM, but the DC in LS7A1000 can also scanout from the system memory directly like a display controller in a SoC does. In fact, this display controller is envolved from early product of Loongson 2H SoC. This driver still works even if the downstream PC board manufacturer doesn't solder a video RAM on the mother board. The lsdc_should_vram_helper_based() function in lsdc_drv.c will examine if the DC device node contain a use_vram_helper property at driver loading time. If there is no use_vram_helper property, CMA helper based DRM driver will be used. Doing this way allow the user using "lsdc.use_vram_helper=0" override the default behavior even through there is a "use_vram_helper;" property in the DTS. In short, It is intend to let the command line passed from kernel has higher priority than the device tree. Otherwise the end user can not switch different driver mode through the kernel command line once the DC device node contain "use_vram_helper;" property. This driver's author already made the decision by the time when the patch is sent out, even through this**may not proper. The CMA helper based driver will be used by default, if the DC device node contain "use_vram_helper;" then VRAM based driver will be used. This is my initial intention.