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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4AE1AC433F5 for ; Wed, 5 Jan 2022 10:49:41 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id EA26E835FC; Wed, 5 Jan 2022 11:49:38 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="Xsezc0Ax"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D56D9835EA; Wed, 5 Jan 2022 11:49:37 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id B2630835EA for ; Wed, 5 Jan 2022 11:49:34 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 0E61F22239; Wed, 5 Jan 2022 11:49:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1641379774; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fgzEFgQu0L8oj8N85Zgdj7mKPb7LFnDWmpol/Gy0wFs=; b=Xsezc0Ax13B1s86r5KrUVL7Ub1B+eOPN5cmebtoZ4hsmOX0rKnVsveLlgBSs07suFJOBDf /a+Z5CwQ+ZdQzA6IoEIJKI42vweVqlPHed157et1xKxsGyLgxH9XFfyjIsIsvNf75oJ2N4 uqLvjEveX97HM5QwA0bkjygSJnZBD3E= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Jan 2022 11:49:33 +0100 From: Michael Walle To: Eugen.Hristev@microchip.com Cc: hs@denx.de, u-boot@lists.denx.de Subject: Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c In-Reply-To: <08d16a59-e1f5-6e1e-1392-31f5e0cafb80@microchip.com> References: <20220104184359.315440-1-eugen.hristev@microchip.com> <20220105100448.1420182-1-michael@walle.cc> <08d16a59-e1f5-6e1e-1392-31f5e0cafb80@microchip.com> User-Agent: Roundcube Webmail/1.4.12 Message-ID: <908a94ecb12c0177b2b2f903daf298b4@walle.cc> X-Sender: michael@walle.cc X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Am 2022-01-05 11:37, schrieb Eugen.Hristev@microchip.com: > On 1/5/22 12:04 PM, Michael Walle wrote: >> Hi, >> >>> Add compatible and data platform struct for sama7g5 SoC. >>> >>> Signed-off-by: Eugen Hristev >>> --- >>> drivers/i2c/at91_i2c.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c >>> index 6b4c0e4804..400a3786ca 100644 >>> --- a/drivers/i2c/at91_i2c.c >>> +++ b/drivers/i2c/at91_i2c.c >>> @@ -305,6 +305,11 @@ static const struct at91_i2c_pdata >>> sama5d2_config = { >>> .clk_offset = 3, >>> }; >>> >>> +static const struct at91_i2c_pdata sama7g5_config = { >>> + .clk_max_div = 7, >>> + .clk_offset = 3, >>> +}; >>> + >>> static const struct udevice_id at91_i2c_ids[] = { >>> { .compatible = "atmel,at91rm9200-i2c", .data = >>> (long)&at91rm9200_config }, >>> { .compatible = "atmel,at91sam9260-i2c", .data = >>> (long)&at91sam9260_config }, >>> @@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = { >>> { .compatible = "atmel,at91sam9x5-i2c", .data = >>> (long)&at91sam9x5_config }, >>> { .compatible = "atmel,sama5d4-i2c", .data = (long)&sama5d4_config >>> }, >>> { .compatible = "atmel,sama5d2-i2c", .data = (long)&sama5d2_config >>> }, >>> +{ .compatible = "microchip,sama7g5-i2c", .data = >>> (long)&sama7g5_config }, >> >> I see that this compatible string is is also used in the linux >> device tree, but there is no dt binding for it in linux. Could you >> add it, so the binding is approved by Rob? > > I can, for sure, but the current binding format is txt. I am not sure > if > we have to convert to yaml first, in which case it would be a little > more difficult than just adding a new compatible string. > The current DT node in Linux is also compatible with sam9x60, and this > string is already in the Linux binding file. > I could add the sam9x60 compatible instead, and it will still work, as > 9x60 type of i2c is the same as in sama7g5. > You think this option would be better for now ? It's at least better than adding an undocumented string. But TBH, this looks like "what can I do to avoid converting the dt binding to yaml". Which eventually has to be done anyway, so now might be a good opportunity for that :) But looking at sama7g5_config above again, will that also be the correct values for the generic sam9x60? -michael