From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751263AbdEaQ3F (ORCPT ); Wed, 31 May 2017 12:29:05 -0400 Received: from mx08-00252a01.pphosted.com ([91.207.212.211]:41453 "EHLO mx08-00252a01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238AbdEaQ3B (ORCPT ); Wed, 31 May 2017 12:29:01 -0400 Subject: Re: CLK_OF_DECLARE advice required To: Stefan Wahren , Stephen Warren Cc: Michael Turquette , Stephen Boyd , "linux-kernel@vger.kernel.org" , linux-rpi-kernel , linux-clk@vger.kernel.org References: <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org> <0794f430-9761-c855-9a89-13d9871c5831@i2se.com> From: Phil Elwell Message-ID: <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org> Date: Wed, 31 May 2017 17:28:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0794f430-9761-c855-9a89-13d9871c5831@i2se.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-31_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705310299 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/05/2017 16:58, Stefan Wahren wrote: > Am 31.05.2017 um 17:27 schrieb Stephen Warren: >> On 05/30/2017 06:23 AM, Phil Elwell wrote: >>> Hi, >>> >>> I've run into a problem using the fixed-factor clock on Raspberry Pi >>> and I'd >>> like some advice before I submit a patch. >>> >>> Some context: the aim is to use a standard UART and some external >>> circuitry >>> as a MIDI interface. This would be straightforward except that Linux >>> doesn't >>> recognise the required 31.25KHz as a valid UART baud rate. Rhe >>> workaround is >>> to declare the UART clock such that the reported rate differs from >>> the actual >>> rate. If one sets the reported rate to be (actual*38400)/31250 then >>> requesting a 38400 baud rate will result in an actual 31250 baud signal. >> >> This sounds like the wrong approach. Forcing the port to use a >> different clock rate than the user requests would prevent anyone from >> using that port for its standard purpose; it'd turn what should be a >> runtime decision into a compile-time decision. >> >> Are you sure there's no way to simply select the correct baud rate on >> the port? I see plenty of references to configuring custom baud rates >> under Linux when I search Google, e.g.: >> >>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux >>> >> "How to set a custom baud rate on Linux?" >> >>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html >> "Re: Terminal interface and non-standard baudrates" >> > > I remember this gist from Peter Hurley: > > https://gist.github.com/peterhurley/fbace59b55d87306a5b8 Thank you, Stephen and Stephan. Stephen - the clock scaling is applied by a DT overlay so it effectively a runtime setting, but I take your point about the elegance of the solution. Stefan - anybaud looks promising, although I would have preferred for users to continue to use the existing user-space tools - kernel changes can be deployed more easily. For my edification, can you pretend for a moment that the application was a valid one and answer any of my original questions?: 1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably avoid this problem, but further initialisation order dependencies may require more drivers to be initialised early. 2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not return any indication of success? If it did, and if the OF_POPULATED flag was only set after successful initialisation then the normal retrying of a deferred probe would also avoid this problem. 3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it? Thanks, Phil