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.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 32027C54E8E for ; Tue, 12 May 2020 02:09:48 +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 0666D2071A for ; Tue, 12 May 2020 02:09:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qiwqdiuL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0666D2071A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dLjqwSYe9hVMWAlsAdFyhadx1jT55A2LqqYqXNCz+n4=; b=qiwqdiuL1KHvuj pDU8HdpzJuTEsKP9nkzO8u4eZhPjoIglxtoY5g9scNfTcRYd7yX5b1r+gB4omTMII25RxWVVc+wBo OI90b++gF2sR1sdWhl9qeZWCfEKllYPIqxrUwaXVpGIvcxInz1lkk9UOWJAz1Lsf1WUGVHT2cEn/J tDd0Ayw17ByMRcnHE9EuLcE98bqyn/ILcFRE9zS1gDxlEolO6VIpabIiYoYZQ2iCsrQxogAIjKwDS 7Jcq+w53gyYz6B/i5i2uMGQIPhYd6nsTC7KE/YLvI1r+bO94CZh5XMofh7TqRcj9uXxmwBNUMiwb8 gGkDjFPIVJq2zyRAeUEQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYKMd-0004a0-EU; Tue, 12 May 2020 02:09:47 +0000 Received: from mail-ot1-f66.google.com ([209.85.210.66]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYKMa-0004Zf-C0 for linux-arm-kernel@lists.infradead.org; Tue, 12 May 2020 02:09:45 +0000 Received: by mail-ot1-f66.google.com with SMTP id m33so9309751otc.5 for ; Mon, 11 May 2020 19:09:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=hx2GPWhJqt9kxObM/JXtvxzVEbR5wT0H4fhgwGryEc8=; b=gs9fdCbDveVGASQ5VeD1P3+yRgrR8MxGlN1UwMAUP/DeCdOhIRhjR+uHVxphi+qnfz APUcEErYy0PjZ2lKG+0V8fl4q7HqBnM3ynr42hogRg/Zn3ADwJlJQivB8sSEw1dv1C2m Ivy2YG7kVJ4rTexHsBb5go7VwN1hJItSa23iJVQEDaKR6rgx8josv+IielUh7g5m3hza 2akD4h9iyQNCxALncczt2St3R69hzZPZh81BwhiyF5cToeqSRyPT2r+dsfz2ceDGr3dY OqRZNwTLbdTpiP6jicXzvz+TBIHhz5UO0qZFKnOgiEyoJOLQ4BoZNTBzzs10IlaHeQeC bblA== X-Gm-Message-State: AGi0PuYyQVMIMxH7ylAf5yuvWDh8+e5zFNPopnmj67WEbKf6gHfYoeIp 1rRUXpy2KN17sbyYpdIylFx+4V4= X-Google-Smtp-Source: APiQypKIirFNWU90d1Ffrh4CEIScFhMrBN5Ab2uVt6ZLzmIl26jkrZYjHyZQwqCfgrroO/ir5KlD9g== X-Received: by 2002:a9d:5f04:: with SMTP id f4mr16523087oti.154.1589249383244; Mon, 11 May 2020 19:09:43 -0700 (PDT) Received: from rob-hp-laptop (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id t22sm5101089oij.2.2020.05.11.19.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2020 19:09:42 -0700 (PDT) Received: (nullmailer pid 12354 invoked by uid 1000); Tue, 12 May 2020 02:09:41 -0000 Date: Mon, 11 May 2020 21:09:41 -0500 From: Rob Herring To: Tomi Valkeinen , kernel@collabora.com, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, jason@lakedaemon.net, laurent.pinchart@ideasonboard.com Subject: Re: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml Message-ID: <20200512020941.GA2002@bogus> References: <20200428092048.14939-1-ricardo.canuelo@collabora.com> <3e377c73-25a3-a7b3-0604-41c54d70039e@ti.com> <20200506155320.GC15206@pendragon.ideasonboard.com> <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200511_190944_407607_1A2FC716 X-CRM114-Status: GOOD ( 28.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Ca=F1uelo wrote: > Hi Rob, > = > What's your opinion on this? > = > Some context: It's about bindings that define signed integer properties > with range checks that go below and above zero. The schema checker fails > because, apparently, it interprets every cell value as an uint32, which > makes the range check fail for negative numbers. The real fix is dtc needs to carry the sign thru to the yaml output = format. In the mean time, perhaps the schema should have an unsigned = range for signed types. Rob > = > On mi=E9 06-05-2020 18:53:20, Laurent Pinchart wrote: > > Hi Tomi, > > = > > On Tue, Apr 28, 2020 at 12:49:28PM +0300, Tomi Valkeinen wrote: > > > On 28/04/2020 12:20, Ricardo Ca=F1uelo wrote: > > > = > > > > 2) The definition of ti,deskew in the original binding seems to be > > > > tailored to the current driver and the way it's defined may not be = very > > > > DT-friendly. > > > > = > > > > This parameter maps to a 3-bit field in a hardware register that= takes > > > > a value from 0 to 7, so the [-4, 3] range described for this wou= ld map > > > > to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111. > > > > = > > > > Then, the driver parses the parameter (unsigned) and casts it to= a > > > > signed integer to get a number in the [-4, 3] range. > > > = > > > Interestingly the current example has ti,deskew =3D <4>... > > > = > > > > A vendor-specific property must have a type definition in json-s= chema, > > > > so if I translate the original bindings semantics directly, I sh= ould > > > > define ti,deskew as an int32, but this makes dt_binding_check fa= il if > > > > the property has a negative value in the example because of the > > > > internal representation of cells as unsigned integers: > > > > = > > > > ti,deskew:0:0: 4294967293 is greater than the maximum of 2147= 483647 > > > = > > > I don't quite understand this. We cannot have negative numbers in dts= files? Or we can, but = > > > dt_binding_check doesn't handle them correctly? Or that int32 is not = supported in yaml bindings? > > > = > > > > So I can think of two solutions to this: > > > > = > > > > a) Keep the ti,deskew property as an uint32 and document the val= id > > > > range ([-4, 3]) in the property description (this is what this p= atch > > > > does currently). > > > > = > > > > b) Redefine this property to be closer to the datasheet descript= ion > > > > (ie. unsigned integers from 0 to 7) and adapt the driver accordi= ngly. > > > > This would also let us define its range properly using minimum a= nd > > > > maximum properties for it. > > > > = > > > > I think (b) is the right thing to do but I want to know your > > > > opinion. Besides, I don't have this hardware at hand and if I up= dated > > > > the driver I wouldn't be able to test it. > > > = > > > I don't think anyone has used deskew property, so I guess changing it= is not out of the question. > > > = > > > Laurent, did you have a board that needs deskew when you added it to = tfp410? > > = > > I didn't if I remember correctly, I just mapped it to the hardware > > features. The hardware register indeed takes a value between 0 and 7, > > and that is mapped to [-4,3] x t(STEP). I don't mind either option. > > = > > -- = > > Regards, > > = > > Laurent Pinchart > = > I haven't found any examples of yaml bindings defining signed integer > properties such as this, what's the norm in this case? Do you agree with > any of the proposed solutions? Do you have a better suggestion? > = > Thanks, > Ricardo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 1BDD5C47255 for ; Tue, 12 May 2020 02:09:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E4EE32071A for ; Tue, 12 May 2020 02:09:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589249384; bh=0MRX231pJXN62Nn/nv9a7n9XhUP8EeaHeOBX/OsWQ6c=; h=Date:From:To:Subject:References:In-Reply-To:List-ID:From; b=v767jStU+8cpMDA2BKge/w4w3xDIsKvv7CNmpMjD/jNjPY3k/h1SQp5r4TPO7UopH 0fuj9ghJDd4+rmLVeXDueyGdJFKn65e4o/IecljU9/uXUCHk56dLDNF2A2TKV8y6HZ hNV4v83Nvmf3M/eQda88+iq8uEXs+Hbnv5rAXrZg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727892AbgELCJo (ORCPT ); Mon, 11 May 2020 22:09:44 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:46977 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727886AbgELCJo (ORCPT ); Mon, 11 May 2020 22:09:44 -0400 Received: by mail-ot1-f65.google.com with SMTP id z25so9270673otq.13 for ; Mon, 11 May 2020 19:09:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=hx2GPWhJqt9kxObM/JXtvxzVEbR5wT0H4fhgwGryEc8=; b=HyjqD9QbWqjQXRILb26O11S/DUplBl+FqSojJScKSJvOiFLDNSELp8D+GwamDBCKe2 tsfHHQob3Cj6IoDOal8nt7dOLwhp3tWMNlQd4sRC5u6oh39Ncxjq5X/LWBGWeBC67siJ iM8+zSd8zZpjNxJwFQCsIEzJF+WrM23xsBpc3RCpJnHZuzX0RGqloGleM99Y5BDmWqDS wNMXZ0w9ameaKmr7ILVmlEjji+ODoTaeDnnxnmR1ai7wbT7mvNc3jLQTKqrp4SlkRtCZ aQJTcvBr97B2QANtpWVMmsZBBATbN8knzf3Nk8BfD1n9HIuSAgBPnOtT4s7Dl9NuFPqA YQwg== X-Gm-Message-State: AGi0PuZWsu2/KTdSKgLeUGLJYE3t3c1/B0uTSRQoeMSMLJamsONABEvZ RL96FPykgbvs6ogjB+QNAw== X-Google-Smtp-Source: APiQypKIirFNWU90d1Ffrh4CEIScFhMrBN5Ab2uVt6ZLzmIl26jkrZYjHyZQwqCfgrroO/ir5KlD9g== X-Received: by 2002:a9d:5f04:: with SMTP id f4mr16523087oti.154.1589249383244; Mon, 11 May 2020 19:09:43 -0700 (PDT) Received: from rob-hp-laptop (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id t22sm5101089oij.2.2020.05.11.19.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2020 19:09:42 -0700 (PDT) Received: (nullmailer pid 12354 invoked by uid 1000); Tue, 12 May 2020 02:09:41 -0000 Date: Mon, 11 May 2020 21:09:41 -0500 From: Rob Herring To: Tomi Valkeinen , kernel@collabora.com, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, jason@lakedaemon.net, laurent.pinchart@ideasonboard.com Subject: Re: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml Message-ID: <20200512020941.GA2002@bogus> References: <20200428092048.14939-1-ricardo.canuelo@collabora.com> <3e377c73-25a3-a7b3-0604-41c54d70039e@ti.com> <20200506155320.GC15206@pendragon.ideasonboard.com> <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Cañuelo wrote: > Hi Rob, > > What's your opinion on this? > > Some context: It's about bindings that define signed integer properties > with range checks that go below and above zero. The schema checker fails > because, apparently, it interprets every cell value as an uint32, which > makes the range check fail for negative numbers. The real fix is dtc needs to carry the sign thru to the yaml output format. In the mean time, perhaps the schema should have an unsigned range for signed types. Rob > > On mié 06-05-2020 18:53:20, Laurent Pinchart wrote: > > Hi Tomi, > > > > On Tue, Apr 28, 2020 at 12:49:28PM +0300, Tomi Valkeinen wrote: > > > On 28/04/2020 12:20, Ricardo Cañuelo wrote: > > > > > > > 2) The definition of ti,deskew in the original binding seems to be > > > > tailored to the current driver and the way it's defined may not be very > > > > DT-friendly. > > > > > > > > This parameter maps to a 3-bit field in a hardware register that takes > > > > a value from 0 to 7, so the [-4, 3] range described for this would map > > > > to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111. > > > > > > > > Then, the driver parses the parameter (unsigned) and casts it to a > > > > signed integer to get a number in the [-4, 3] range. > > > > > > Interestingly the current example has ti,deskew = <4>... > > > > > > > A vendor-specific property must have a type definition in json-schema, > > > > so if I translate the original bindings semantics directly, I should > > > > define ti,deskew as an int32, but this makes dt_binding_check fail if > > > > the property has a negative value in the example because of the > > > > internal representation of cells as unsigned integers: > > > > > > > > ti,deskew:0:0: 4294967293 is greater than the maximum of 2147483647 > > > > > > I don't quite understand this. We cannot have negative numbers in dts files? Or we can, but > > > dt_binding_check doesn't handle them correctly? Or that int32 is not supported in yaml bindings? > > > > > > > So I can think of two solutions to this: > > > > > > > > a) Keep the ti,deskew property as an uint32 and document the valid > > > > range ([-4, 3]) in the property description (this is what this patch > > > > does currently). > > > > > > > > b) Redefine this property to be closer to the datasheet description > > > > (ie. unsigned integers from 0 to 7) and adapt the driver accordingly. > > > > This would also let us define its range properly using minimum and > > > > maximum properties for it. > > > > > > > > I think (b) is the right thing to do but I want to know your > > > > opinion. Besides, I don't have this hardware at hand and if I updated > > > > the driver I wouldn't be able to test it. > > > > > > I don't think anyone has used deskew property, so I guess changing it is not out of the question. > > > > > > Laurent, did you have a board that needs deskew when you added it to tfp410? > > > > I didn't if I remember correctly, I just mapped it to the hardware > > features. The hardware register indeed takes a value between 0 and 7, > > and that is mapped to [-4,3] x t(STEP). I don't mind either option. > > > > -- > > Regards, > > > > Laurent Pinchart > > I haven't found any examples of yaml bindings defining signed integer > properties such as this, what's the norm in this case? Do you agree with > any of the proposed solutions? Do you have a better suggestion? > > Thanks, > Ricardo 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.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 D935AC54E8D for ; Tue, 12 May 2020 02:09:45 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 B45AF2071A for ; Tue, 12 May 2020 02:09:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B45AF2071A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 94FE56E037; Tue, 12 May 2020 02:09:44 +0000 (UTC) Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0E45F6E037 for ; Tue, 12 May 2020 02:09:43 +0000 (UTC) Received: by mail-ot1-f66.google.com with SMTP id 63so1915150oto.8 for ; Mon, 11 May 2020 19:09:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=hx2GPWhJqt9kxObM/JXtvxzVEbR5wT0H4fhgwGryEc8=; b=O/vGt9NfyKba89idN+q8mwW6yuSa7wSvu0UJoJxrB1AM+k2RwLrN/2AsJaz31itG6r UxS6WUz3mciyKqOEvq8TbYFGlCkS0jyBFy/DAQiyBg39VZisz727FigVyzNZOHsfmjwk ReKUbjPWIreeOqeEjl1aRV0yZU7Qs9j669XPW13n4s9FDjAcXrfYgj4zal08naogFo7y VUh7u3+s1Tp26AFBOGQAE+5mc3223x6dqoeOtqkf0t7AzaSDZURYTvcqoL6/B3A2de69 aFt4nZyHvHr764xyzvTFObsFO2RPTQ/L8/A+ip9YYCc1gimycBIwf2+EfvHhNq/Qv0gk UH3w== X-Gm-Message-State: AGi0PuZbBkcGt4eeGVW278hB7n4kLzoOC4B5J1WatN4Bb3VnQjMw7xv9 ytjCvlS7p+djc0zw3yFHvw== X-Google-Smtp-Source: APiQypKIirFNWU90d1Ffrh4CEIScFhMrBN5Ab2uVt6ZLzmIl26jkrZYjHyZQwqCfgrroO/ir5KlD9g== X-Received: by 2002:a9d:5f04:: with SMTP id f4mr16523087oti.154.1589249383244; Mon, 11 May 2020 19:09:43 -0700 (PDT) Received: from rob-hp-laptop (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id t22sm5101089oij.2.2020.05.11.19.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2020 19:09:42 -0700 (PDT) Received: (nullmailer pid 12354 invoked by uid 1000); Tue, 12 May 2020 02:09:41 -0000 Date: Mon, 11 May 2020 21:09:41 -0500 From: Rob Herring To: Tomi Valkeinen , kernel@collabora.com, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, jason@lakedaemon.net, laurent.pinchart@ideasonboard.com Subject: Re: [RFC PATCH] dt-bindings: display: ti,tfp410.txt: convert to yaml Message-ID: <20200512020941.GA2002@bogus> References: <20200428092048.14939-1-ricardo.canuelo@collabora.com> <3e377c73-25a3-a7b3-0604-41c54d70039e@ti.com> <20200506155320.GC15206@pendragon.ideasonboard.com> <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200511145911.2yv3aepofxqwdsju@rcn-XPS-13-9360> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Ca=F1uelo wrote: > Hi Rob, > = > What's your opinion on this? > = > Some context: It's about bindings that define signed integer properties > with range checks that go below and above zero. The schema checker fails > because, apparently, it interprets every cell value as an uint32, which > makes the range check fail for negative numbers. The real fix is dtc needs to carry the sign thru to the yaml output = format. In the mean time, perhaps the schema should have an unsigned = range for signed types. Rob > = > On mi=E9 06-05-2020 18:53:20, Laurent Pinchart wrote: > > Hi Tomi, > > = > > On Tue, Apr 28, 2020 at 12:49:28PM +0300, Tomi Valkeinen wrote: > > > On 28/04/2020 12:20, Ricardo Ca=F1uelo wrote: > > > = > > > > 2) The definition of ti,deskew in the original binding seems to be > > > > tailored to the current driver and the way it's defined may not be = very > > > > DT-friendly. > > > > = > > > > This parameter maps to a 3-bit field in a hardware register that= takes > > > > a value from 0 to 7, so the [-4, 3] range described for this wou= ld map > > > > to [000, 111]: -4 -> 000, -3 -> 001, -2 -> 010, ... 3 -> 111. > > > > = > > > > Then, the driver parses the parameter (unsigned) and casts it to= a > > > > signed integer to get a number in the [-4, 3] range. > > > = > > > Interestingly the current example has ti,deskew =3D <4>... > > > = > > > > A vendor-specific property must have a type definition in json-s= chema, > > > > so if I translate the original bindings semantics directly, I sh= ould > > > > define ti,deskew as an int32, but this makes dt_binding_check fa= il if > > > > the property has a negative value in the example because of the > > > > internal representation of cells as unsigned integers: > > > > = > > > > ti,deskew:0:0: 4294967293 is greater than the maximum of 2147= 483647 > > > = > > > I don't quite understand this. We cannot have negative numbers in dts= files? Or we can, but = > > > dt_binding_check doesn't handle them correctly? Or that int32 is not = supported in yaml bindings? > > > = > > > > So I can think of two solutions to this: > > > > = > > > > a) Keep the ti,deskew property as an uint32 and document the val= id > > > > range ([-4, 3]) in the property description (this is what this p= atch > > > > does currently). > > > > = > > > > b) Redefine this property to be closer to the datasheet descript= ion > > > > (ie. unsigned integers from 0 to 7) and adapt the driver accordi= ngly. > > > > This would also let us define its range properly using minimum a= nd > > > > maximum properties for it. > > > > = > > > > I think (b) is the right thing to do but I want to know your > > > > opinion. Besides, I don't have this hardware at hand and if I up= dated > > > > the driver I wouldn't be able to test it. > > > = > > > I don't think anyone has used deskew property, so I guess changing it= is not out of the question. > > > = > > > Laurent, did you have a board that needs deskew when you added it to = tfp410? > > = > > I didn't if I remember correctly, I just mapped it to the hardware > > features. The hardware register indeed takes a value between 0 and 7, > > and that is mapped to [-4,3] x t(STEP). I don't mind either option. > > = > > -- = > > Regards, > > = > > Laurent Pinchart > = > I haven't found any examples of yaml bindings defining signed integer > properties such as this, what's the norm in this case? Do you agree with > any of the proposed solutions? Do you have a better suggestion? > = > Thanks, > Ricardo _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel