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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CFDD2E77173 for ; Mon, 9 Dec 2024 10:26:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=u10Z7RsJ3SrsFacDql6F0JSeqSx6z9qL6lroTSMFehA=; b=WGnUdLq3J0bamqRIAiSYg/V+cO il6HCsp6rX2rtyo6Yjux1jm4U09UpEBj3X8xTS5CzPCy6hK4kzdd9jNQgKp4LvfqPFkyOqEZmrTJj Uc4OPJqqxUDx1QxIADCPU+1uY17evlyYXJeqses6iIl3ciNup9PZe61WRTTdm4UhG8Egla7W8XnoL 08172Od5IgWHGsTt8DUZUjylqulj7Pkbot8nWnZ4OCfqq3fQmvHIjpUUZcu63E2zKqcQEty0XBHEe HCN1BcxfqvA92ur9B6W5AHl1Xzzi86VhUNTyeO+liUzhchNctTrcXGrFF9usozzWXD/s18WhEJTls G5yoJJsw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tKayS-00000007HTv-1qFm; Mon, 09 Dec 2024 10:26:44 +0000 Received: from bali.collaboradmins.com ([148.251.105.195]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tKabv-00000007Ca1-1Yrq; Mon, 09 Dec 2024 10:03:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1733738604; bh=uxDhJyLY3sygy6QpU5RBbCWc5T7HouoogqahrUoEgVQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qIiERnIv919/ESyVCG3CtCp2T2qIXTi3k40L/ZXlh5p7nfHQZ7Yk+8lR6/xjB6wVE 3AkTXm61EaKoSdY9cBflFmGUoz/kE1gc0EP45KxaSUT+b/lND0VeAnOUwjnuGAa6OT LyN2sB3DdfIzAlWtQqHzzqnN1Wwg0lrGiW2hHKA0a0sNcuzVp3IdA/9vL/KOZH5dbR 3o60pvkY6uXerlXMK0djbTSxzTSQarvHIyZ7FCt01xA7ka7HJ+4q2iI4sMfY8CN+tz uijQPuSyo9iuEeuzA3R3fc8X2pJhm/vMP6Lm/Wj0SPwjUtMq+1+GJGQArr4oNnl+YO 9FVZFihrAB3cA== Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by bali.collaboradmins.com (Postfix) with ESMTPSA id 2474717E3625; Mon, 9 Dec 2024 11:03:24 +0100 (CET) Message-ID: Date: Mon, 9 Dec 2024 11:03:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] MT8516/MT8167 dtsi fixes To: Val Packett Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , Fabien Parent , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org References: <20241204190524.21862-1-val@packett.cool> <7bf536a5-30c1-43d8-9ea3-3aaea65c6b0a@collabora.com> From: AngeloGioacchino Del Regno Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241209_020327_578028_A2BBED61 X-CRM114-Status: GOOD ( 31.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Il 07/12/24 04:11, Val Packett ha scritto: > > On Thu, Dec 5 2024 at 01:27:01 PM +01:00:00, AngeloGioacchino Del Regno > wrote: >>> I strongly suggest you to also send one that achieves basic boot with UART console >> as a first step for upstreaming your board, and then go for incremental changes >> everytime you get a new feature working. > > Wanted to get the PMIC in first but sure, could try splitting out the initial > version without the PMIC. > We all want to get XYZ in first, but then, you'll see that sometimes having at least something will help you justify other changes.... If there's nothing upstream, understanding your changes becomes increasingly difficult (depending on the nature of those changes, of course) - so... just take the advice: sending the initial DT will help you later in the process ;-) > Oh! One dts/dtsi question: pretty much all MTK devices so far have all pinctrl > configurations defined per-device. But on this SoC, pin assignments have their > "canonical" function in the pin name e.g.: MT8167_PIN_58_SDA0__FUNC_SDA0_0 and on > this device they are used as-is. Would it be fine to place these default pinctrl > configs for SD/MMC, I2C etc. in the SoC dtsi? > No, because even though this is the default on many boards, it's still something board specific, as other boards may define different functions. Please define that in your board DT. >>> Generally, if the patches are only simple additions, you could send the original >> patches without any author variation (and fixing that MT6392_IRQ_numbers enum >> in the original ones because lower case please!) and then your patches on top >> with your additions. > > Right, I was mostly unsure if the email workflow supported just sending someone > else's patches, but I guess that was silly - of course git-send-email should do the > right thing! > >> The upstream driver just gained support for configuring the display paths >> entirely in the devicetree as those are obviously device specific. >> >> You can make use of that for upstreaming your tablet after adding the display >> nodes (and bindings, if required) as if you go for the default configuration >> that's probably not going to work because it's for the pumpkin boards which >> will most probably have a different display pipeline compared to your board. > > The pipeline seems to be the same.. The pumpkin board was brought up with DSI as > well, the main pipeline I can find in the Android source is the same (+ PWM). > > I am still struggling to get it to work though: DSI command mode configuration gets > acknowledged fine, but in burst mode, the vblank never arrives. Tried fiddling with > various things (CMDQ or not, mutex as vblank source since there was an Android > commit doing that, etc.), nothing helped. > DSI command mode is not supported upstream - only video mode... and that's why you can't get your display to work. There's no WDMA driver... Convert it to video mode and it's gonna work just perfect :-) P.S.: Also check if your mmsys+mutex configuration is correct! >>> By the way, is anyone familiar with PSCI cpuidle/hot-unplug issues on >>> Mediatek Android devices from around this time? [..] >> >> I did have some issues with an older bootloader on the Xperia M5 smartphone >> and would even lock up at boot, because on the old firmwares the power >> domains for the CPUs are not managed automatically by FW. > > Interesting, thanks for the pointer! > > In the Android kernel sources I could find though, there are no CPU domains in the > mtk-scpsys-mt8167 driver, and the only references I could even find to the related > register bits are from code that *reads* the status of the CPU power domains to > make decisions about sleep states (only_one_cpu_online in mtk_idle). Trying to add > those to the driver anyway, did not succeed so far. > Downstream, you will find references to "mtcmos" (or anyway cpu mtcmos) - that's how power domains are called there (I think. At least, in older downstream kernels that's how they're called - and that's the "real" hw name btw). Cheers, Angelo > ~val > > >