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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1AFB7C432BE for ; Mon, 2 Aug 2021 23:27:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F3D3C60E78 for ; Mon, 2 Aug 2021 23:27:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232614AbhHBX2H (ORCPT ); Mon, 2 Aug 2021 19:28:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232311AbhHBX2H (ORCPT ); Mon, 2 Aug 2021 19:28:07 -0400 Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5036C0613D5 for ; Mon, 2 Aug 2021 16:27:56 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id f27so4194984vsp.8 for ; Mon, 02 Aug 2021 16:27:56 -0700 (PDT) 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=QlzAmryyyeDSDQ1srUNZEgdUE1Lb18Ti4rrmaegWVkw=; b=Ajmr1ho9O5wL+Ew02Av/bUFYn8XmF5TlaNe9PnsD4qjKZxYPBh8Ge6NcYutRfxIzUc JzKbAgn+JG95Zms5Z5w0a2ZuyOjUQWCuyc9IxcYp61b9ECvW9FXLrqERM7GgSVg8cNHW zOJHKvgJHXFIZAc7W7wvYHcGLp3zh5CaIo49Ttue+NXQGnSzoEWNn5lQSeOtryypEVU7 B/RKTe48HxHJspuGTebmsxIS1Wg/+LaA22N5jp/iqCGfOvsWgWY2BRLf/F33Bivk3UBt 2+f/FYN/8cvKYlCMFXDkVTvCA/ocfTaDlhP7x+uxHc+w6C7WVl0L13Zk6bdrEHKgsX4C gC9A== 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=QlzAmryyyeDSDQ1srUNZEgdUE1Lb18Ti4rrmaegWVkw=; b=uOxI9PSMhT3DnpqVQbQPf3n2yezlZlTmc/XNZ2SO6Xq4AHITtDOci0mhiO4S7EP8tV DgWtot1RmZx41uMnxjUgXm3hXVB/DNb8GS7QBJPE+wUeKp5DVoPvxSyVLmxmCLpz3nYf sUp/P6odvdc6Mcw4XmlxUs9boMyibDvq1Nof//7s26Q5dNKLz5ZReqRdu7rbccosiCph il8S8nJ8hw/Guoogr4Opwwa6mns4UmHjTowTam6xEsT81hV8Le+dMXMp1dPmtj+BRfUP brqszgVBK7r88/dBWM6eWPbHEbYxvOn+3sqSuFTzgFMH+t+xkCLWd9RZDmeC+nzxerZ+ zzOA== X-Gm-Message-State: AOAM532TX3dVgQjnj3F/GZpI/0xkKJ7JCntvOBoysdzND+hTt7jtUZqr vFCO66JjDxQ9xrMJXfBtiMvgGFPZMbJSUk8PEZ4nHw== X-Google-Smtp-Source: ABdhPJzJ3U5wtXY2YCtx/k4DqUJTlrgpZ48cDKUw9DVG41O8Yu+2eqmJVsghdHYCgAijN2Q95YtCA/yFaRSlHV3vfbA= X-Received: by 2002:a67:f60e:: with SMTP id k14mr12216795vso.30.1627946875840; Mon, 02 Aug 2021 16:27:55 -0700 (PDT) MIME-Version: 1.0 References: <20210730144922.29111-1-semen.protsenko@linaro.org> <5e35b0a7-13aa-3c62-ca49-14af2fcb2a08@canonical.com> <13f166bb-7103-25d5-35a6-8ec53a1f1817@canonical.com> <2dacc205-04ce-c206-a393-50ba0d5aa1a7@canonical.com> In-Reply-To: <2dacc205-04ce-c206-a393-50ba0d5aa1a7@canonical.com> From: Sam Protsenko Date: Tue, 3 Aug 2021 02:27:44 +0300 Message-ID: Subject: Re: [PATCH 00/12] Add minimal support for Exynos850 SoC To: Krzysztof Kozlowski Cc: Sylwester Nawrocki , Chanwoo Choi , Linus Walleij , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Jiri Slaby , Greg Kroah-Hartman , Charles Keepax , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Linux Samsung SOC , "open list:SERIAL DRIVERS" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Sat, 31 Jul 2021 at 11:12, Krzysztof Kozlowski wrote: > > On 31/07/2021 09:29, Krzysztof Kozlowski wrote: > > On 30/07/2021 21:02, Sam Protsenko wrote: > >> Hi Krzysztof, > >> > >> On Fri, 30 Jul 2021 at 20:21, Krzysztof Kozlowski > >> wrote: > >>> > >>> On 30/07/2021 17:18, Krzysztof Kozlowski wrote: > >>>> On 30/07/2021 16:49, Sam Protsenko wrote: > >>>>> This patch series adds initial platform support for Samsung Exynos850 > >>>>> SoC [1]. With this patchset it's possible to run the kernel with BusyBox > >>>>> rootfs as a RAM disk. More advanced platform support (like MMC driver > >>>>> additions) will be added later. The idea is to keep the first submission > >>>>> minimal to ease the review, and then build up on top of that. > >>>>> > >>>>> [1] https://www.samsung.com/semiconductor/minisite/exynos/products/mobileprocessor/exynos-850/ > >>>>> > >>>> > >>>> Great work! > >>>> > >> > >> Thanks, Krzysztof! And thank you for reviewing the whole series. > >> > >>>> What's the SoC revision number (should be accessible via > >>>> /sys/bus/soc/devices/soc0/)? Recent wrap in numbering of Exynos chips > >>>> might bring confusion... > >> > >> # cat /sys/devices/soc0/revision > >> 0 > > > > soc_id but you're right it won't be set for unknown SoCs. You need to > > extend drivers/soc/samsung/exynos-chipid.c to parse new values (E3830000 > > for product ID) and maybe new register offsets (previous offset is 0x0, > > for 3830 is 0x10 I think). Also revision mask might change. > > > >>> Judging by vendor's sources it is quite confusing. It looks mostly like > >>> Exynos3830 but in few other cases it uses Exynos9 compatibles (Exynos9, > >>> Exynos9820). Only in few places there is Exynos850. Marketing department > >>> made it so confusing... The revision embedded in SoC would be very > >>> interesting. > >>> > >> > >> As I understand, this SoC is called Exynos850 everywhere now. > >> Exynos3830 is its old name, not used anymore. As you noticed from > >> patch #2, it shares some definitions with Exynos9 SoC, so I guess some > >> software is similar for both architectures. Not sure about hardware > >> though, never worked with Exynos9 CPUs. Anyway, I asked Samsung > >> representatives about naming, and it seems like we should stick to > >> "Exynos850" name, even in code. > > > > > > Since the chip identifies itself as E3830000, I would prefer naming > > matching real product ID instead of what is pushed by marketing or sales > > representatives. The marketing names don't have to follow any > > engineering rules, they can be changed and renamed. Sales follows rather > > money and corporate rules, not consistency for upstream project. > > On the other hand we have already two exceptions for naming > inconsistency - Exynos3250 identifies itself as 3472 (which is confusing > because 3250 is two core and there is a separate quad-core > Exyons3472...) and Exynos5800 is actually marketing name for a revision > of Exynos5422. Maybe indeed will be easier to go with the branded name > 850... > Well, chip engraving says "3830", but I was specifically told to stick to "850" in upstream kernel. I can presume there was some mix ups with this naming, and it might be the case it's better to stick to "850" exactly to avoid further confusion. Yes, I can see that EXYNOS3830_SOC_ID = 0xE3830000 in chipid driver, but we can return "EXYNOS850" string for that const, right? If you google "Exynos850" and "Exynos3830", it's obvious everybody uses the former, so I'd appreciate if we can stick to "850" in the end. > > Best regards, > Krzysztof 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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 52100C4338F for ; Mon, 2 Aug 2021 23:30:18 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 1D5BB60E78 for ; Mon, 2 Aug 2021 23:30:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D5BB60E78 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4iG3Q6PmyWDuIFN/isXn+SCAIYbHKsFOCTawC+mz8T0=; b=mPXdy0dH7V8cox WVUChJ3uGtFJd7e3of6nqEgKM12U/BVyEEAs+Sk4zgoFcPy+7XlB8VV+XVjDbdcdAczz1xJwWvvFC xBygQOlf2v9mOnAkX2R02WB9LpxSei7yLhTJsy0gNNA6wErIZJLnrtgiqvOAI/GCHZgkNvqjBwD1Y CU6tBWE1xwHg+oFv02wZSnLlyqiYQ1Ui0JsFIpBrDyrM7f+mty4sc1UcRl85bTmnXKy/panN8heXE Q+q4jbjIaAq4TBS6TUk16hDQgyP3KqsR7pQdlSzyNPRgWLYFiOpNX/PVqkR+5mGJT1o9GporxKW7z hf/FkI1dZWQ3g+v+i6Jw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAhLl-000ayg-Al; Mon, 02 Aug 2021 23:28:01 +0000 Received: from mail-vs1-xe36.google.com ([2607:f8b0:4864:20::e36]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAhLh-000ay6-5r for linux-arm-kernel@lists.infradead.org; Mon, 02 Aug 2021 23:27:58 +0000 Received: by mail-vs1-xe36.google.com with SMTP id e4so10442193vsr.13 for ; Mon, 02 Aug 2021 16:27:56 -0700 (PDT) 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=QlzAmryyyeDSDQ1srUNZEgdUE1Lb18Ti4rrmaegWVkw=; b=Ajmr1ho9O5wL+Ew02Av/bUFYn8XmF5TlaNe9PnsD4qjKZxYPBh8Ge6NcYutRfxIzUc JzKbAgn+JG95Zms5Z5w0a2ZuyOjUQWCuyc9IxcYp61b9ECvW9FXLrqERM7GgSVg8cNHW zOJHKvgJHXFIZAc7W7wvYHcGLp3zh5CaIo49Ttue+NXQGnSzoEWNn5lQSeOtryypEVU7 B/RKTe48HxHJspuGTebmsxIS1Wg/+LaA22N5jp/iqCGfOvsWgWY2BRLf/F33Bivk3UBt 2+f/FYN/8cvKYlCMFXDkVTvCA/ocfTaDlhP7x+uxHc+w6C7WVl0L13Zk6bdrEHKgsX4C gC9A== 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=QlzAmryyyeDSDQ1srUNZEgdUE1Lb18Ti4rrmaegWVkw=; b=TCNSzCbFzQ43DMgcnNweYmzXsspCImpNfNaVgvDAlBdwMd2TGrZ23poCekO3NPjQjL pOkR5qd4zkcjHAd0IBHTHIuyUl+6r802IoUSNhBvhcM99yUA3y/KawhjnQKLzof9vjK0 r6hOEBTvW7TZlSB7bHvFOZDUaByB2iLxKS80mslu6A2lfHHo2IIr9aHlj3dckuN8Cx5X ZXP9Rn2C+4irN+cWmdpHE5g1s+J19z4CSb7B5uo9LR18cHS/g/WjM43+IifwX781X36/ ite4L9SIzgPWshKv0qsOtFIYG6rNjMslwOnWroiwBhCng0+3bs3S5AupsRY5X8aIOUkU ahpQ== X-Gm-Message-State: AOAM533FgxkCN7Igx2zBL5dztTp29jj2zI/IvRvfV4H/KQxXtCd7J/ZD PcdCFxMjU7/APpNBF8S68sScAkm2N+414Ls4rHwZRg== X-Google-Smtp-Source: ABdhPJzJ3U5wtXY2YCtx/k4DqUJTlrgpZ48cDKUw9DVG41O8Yu+2eqmJVsghdHYCgAijN2Q95YtCA/yFaRSlHV3vfbA= X-Received: by 2002:a67:f60e:: with SMTP id k14mr12216795vso.30.1627946875840; Mon, 02 Aug 2021 16:27:55 -0700 (PDT) MIME-Version: 1.0 References: <20210730144922.29111-1-semen.protsenko@linaro.org> <5e35b0a7-13aa-3c62-ca49-14af2fcb2a08@canonical.com> <13f166bb-7103-25d5-35a6-8ec53a1f1817@canonical.com> <2dacc205-04ce-c206-a393-50ba0d5aa1a7@canonical.com> In-Reply-To: <2dacc205-04ce-c206-a393-50ba0d5aa1a7@canonical.com> From: Sam Protsenko Date: Tue, 3 Aug 2021 02:27:44 +0300 Message-ID: Subject: Re: [PATCH 00/12] Add minimal support for Exynos850 SoC To: Krzysztof Kozlowski Cc: Sylwester Nawrocki , Chanwoo Choi , Linus Walleij , Tomasz Figa , Rob Herring , Stephen Boyd , Michael Turquette , Jiri Slaby , Greg Kroah-Hartman , Charles Keepax , Ryu Euiyoul , Tom Gall , Sumit Semwal , John Stultz , Amit Pundir , devicetree , linux-arm Mailing List , linux-clk , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Linux Samsung SOC , "open list:SERIAL DRIVERS" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210802_162757_272670_EDD7DD58 X-CRM114-Status: GOOD ( 38.52 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 31 Jul 2021 at 11:12, Krzysztof Kozlowski wrote: > > On 31/07/2021 09:29, Krzysztof Kozlowski wrote: > > On 30/07/2021 21:02, Sam Protsenko wrote: > >> Hi Krzysztof, > >> > >> On Fri, 30 Jul 2021 at 20:21, Krzysztof Kozlowski > >> wrote: > >>> > >>> On 30/07/2021 17:18, Krzysztof Kozlowski wrote: > >>>> On 30/07/2021 16:49, Sam Protsenko wrote: > >>>>> This patch series adds initial platform support for Samsung Exynos850 > >>>>> SoC [1]. With this patchset it's possible to run the kernel with BusyBox > >>>>> rootfs as a RAM disk. More advanced platform support (like MMC driver > >>>>> additions) will be added later. The idea is to keep the first submission > >>>>> minimal to ease the review, and then build up on top of that. > >>>>> > >>>>> [1] https://www.samsung.com/semiconductor/minisite/exynos/products/mobileprocessor/exynos-850/ > >>>>> > >>>> > >>>> Great work! > >>>> > >> > >> Thanks, Krzysztof! And thank you for reviewing the whole series. > >> > >>>> What's the SoC revision number (should be accessible via > >>>> /sys/bus/soc/devices/soc0/)? Recent wrap in numbering of Exynos chips > >>>> might bring confusion... > >> > >> # cat /sys/devices/soc0/revision > >> 0 > > > > soc_id but you're right it won't be set for unknown SoCs. You need to > > extend drivers/soc/samsung/exynos-chipid.c to parse new values (E3830000 > > for product ID) and maybe new register offsets (previous offset is 0x0, > > for 3830 is 0x10 I think). Also revision mask might change. > > > >>> Judging by vendor's sources it is quite confusing. It looks mostly like > >>> Exynos3830 but in few other cases it uses Exynos9 compatibles (Exynos9, > >>> Exynos9820). Only in few places there is Exynos850. Marketing department > >>> made it so confusing... The revision embedded in SoC would be very > >>> interesting. > >>> > >> > >> As I understand, this SoC is called Exynos850 everywhere now. > >> Exynos3830 is its old name, not used anymore. As you noticed from > >> patch #2, it shares some definitions with Exynos9 SoC, so I guess some > >> software is similar for both architectures. Not sure about hardware > >> though, never worked with Exynos9 CPUs. Anyway, I asked Samsung > >> representatives about naming, and it seems like we should stick to > >> "Exynos850" name, even in code. > > > > > > Since the chip identifies itself as E3830000, I would prefer naming > > matching real product ID instead of what is pushed by marketing or sales > > representatives. The marketing names don't have to follow any > > engineering rules, they can be changed and renamed. Sales follows rather > > money and corporate rules, not consistency for upstream project. > > On the other hand we have already two exceptions for naming > inconsistency - Exynos3250 identifies itself as 3472 (which is confusing > because 3250 is two core and there is a separate quad-core > Exyons3472...) and Exynos5800 is actually marketing name for a revision > of Exynos5422. Maybe indeed will be easier to go with the branded name > 850... > Well, chip engraving says "3830", but I was specifically told to stick to "850" in upstream kernel. I can presume there was some mix ups with this naming, and it might be the case it's better to stick to "850" exactly to avoid further confusion. Yes, I can see that EXYNOS3830_SOC_ID = 0xE3830000 in chipid driver, but we can return "EXYNOS850" string for that const, right? If you google "Exynos850" and "Exynos3830", it's obvious everybody uses the former, so I'd appreciate if we can stick to "850" in the end. > > Best regards, > Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel