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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 B2608C388F3 for ; Tue, 1 Oct 2019 05:07:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 890D621783 for ; Tue, 1 Oct 2019 05:07:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="wYQnXQJ1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731123AbfJAFH3 (ORCPT ); Tue, 1 Oct 2019 01:07:29 -0400 Received: from lelv0143.ext.ti.com ([198.47.23.248]:40510 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbfJAFH2 (ORCPT ); Tue, 1 Oct 2019 01:07:28 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id x91579HI123814; Tue, 1 Oct 2019 00:07:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1569906429; bh=noXDxeYUUM74ghwgtc9meLrez0A25pS+/YPUPz/R6GQ=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=wYQnXQJ1eGweNGaMBSOsoiMDDRVJa0dl8PX5hIgjA78oyr9y01o+foZcUytgIR6G+ Gqu+OLpn9+63PkP8MyCfSPkYjMM0Lgfuy3Hds71AQWTN11mZOigA02FCpmgy0TiqsG 3k8w56MIoTbRq9/mR3yL2ZmtlRm4jaOQXOFbQ0dc= Received: from DLEE103.ent.ti.com (dlee103.ent.ti.com [157.170.170.33]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x91579E2057589 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 1 Oct 2019 00:07:09 -0500 Received: from DLEE101.ent.ti.com (157.170.170.31) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 1 Oct 2019 00:06:58 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Tue, 1 Oct 2019 00:06:58 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id x91576QY023304; Tue, 1 Oct 2019 00:07:06 -0500 Subject: Re: [PATCH] drm/omap: Migrate minimum FCK/PCK ratio from Kconfig to dts To: Tero Kristo , Adam Ford CC: "H. Nikolaus Schaller" , Tony Lindgren , Linux-OMAP , Adam Ford , =?UTF-8?Q?Beno=c3=aet_Cousson?= , dri-devel , devicetree , Linux Kernel Mailing List References: <20190510194229.20628-1-aford173@gmail.com> <845055e2-8182-de74-2077-629fdf50ac6c@ti.com> <854f6130-c8a8-81cb-aa76-4830f218ae54@ti.com> <0473526e-df0a-94a5-5c22-debd0084ab16@ti.com> <36369388-e9c8-22cd-8c19-e2bdf2d0389b@ti.com> <23eba53a-9304-2ceb-d97e-01891ec0b3ed@ti.com> <04306a5e-f9be-35a4-1aa1-5795d780e289@ti.com> <3777f1b1-2d9a-334b-b9e7-99dfda2ae29b@ti.com> <6cd7c9f0-cb26-588b-dfd1-faf462732549@ti.com> From: Tomi Valkeinen Message-ID: Date: Tue, 1 Oct 2019 08:07:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6cd7c9f0-cb26-588b-dfd1-faf462732549@ti.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/09/2019 20:48, Tero Kristo wrote: > Hmmh, after some testing, it seems there is bad stuff happening with the > divider clock implementation, I am re-working it as of now. Basically > what is wrong is that with a divider max value of say 16, the driver > attempts to craft the max value into a mask, but this ends up being > 0x1f. If the max value is 15, it ends up into 0xf which is correct. Ok, that explains the max not working. It doesn't explain the other issue, where the TRM says the max div is 32, but it does not work. But taking the max div from the old SoCs, 16, is not correct either, as it seems that dividers up to 31 work ok. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki