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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 235DDCA9EA0 for ; Tue, 22 Oct 2019 15:36:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E6C732084B for ; Tue, 22 Oct 2019 15:36:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731601AbfJVPgy (ORCPT ); Tue, 22 Oct 2019 11:36:54 -0400 Received: from muru.com ([72.249.23.125]:38904 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731450AbfJVPgy (ORCPT ); Tue, 22 Oct 2019 11:36:54 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id EF18F80FA; Tue, 22 Oct 2019 15:37:27 +0000 (UTC) Date: Tue, 22 Oct 2019 08:36:50 -0700 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: Rob Herring , David Airlie , Daniel Vetter , Mark Rutland , =?utf-8?Q?Beno=C3=AEt?= Cousson , dri-devel , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-omap , Discussions about the Letux Kernel , kernel@pyra-handheld.com Subject: Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings Message-ID: <20191022153650.GL5610@atomide.com> References: <20191021172557.GB5610@atomide.com> <20191022150202.GJ5610@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org * H. Nikolaus Schaller [191022 15:12]: > Hm. How should that work? Some SoC have the sgx544 as single > core and others as dual core. This imho does not fit into > the "img,sgx544-$revision" scheme which could be matched to. Well don't you have then just two separate child nodes, one for each core with their own register range? That is assuming they're really separate instances.. > But maybe we do it the same as with the timer for the moment, > i.e. keep it in some unpublished patch set. Yeah makes sense to me until things get sorted out. > At the moment I have more problems understanding how the yaml > thing works. I understand and fully support the overall goal, > but it is quite difficult to get a start here. And there do not > seem to be tools or scripts to help converting from old style > text format (even if not perfect, this would be helpful) and > I have no yaml editor that helps keeping the indentation > correct. So this slows down a v2 a little bit. Sounds handy to me :) Regards, Tony