Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756894AbbEUWBb (ORCPT ); Thu, 21 May 2015 18:01:31 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57660 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755414AbbEUWBY (ORCPT ); Thu, 21 May 2015 18:01:24 -0400 Message-ID: <555E559F.8040403@suse.de> Date: Fri, 22 May 2015 00:01:03 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Organization: SUSE Linux GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Maxime Coquelin CC: Kamil Lulko , Rob Herring , Arnd Bergmann , Mark Rutland , "linux-doc@vger.kernel.org" , Linus Walleij , Will Deacon , Stefan Agner , Nikolay Borisov , Peter Meerwald , Lee Jones , Linux-Arch , Daniel Thompson , Russell King , Pawel Moll , Jonathan Corbet , Jiri Slaby , Daniel Lezcano , Chanwoo Choi , Andy Shevchenko , Antti Palosaari , Geert Uytterhoeven , "linux-serial@vger.kernel.org" , =?UTF-8?B?VXdlIEtsZWluZS1Lw7ZuaWc=?= , "devicetree@vger.kernel.org" , Kees Cook , Mauro Carvalho Chehab , Rusty Russell , "linux-gpio@vger.kernel.org" , Kumar Gala , Thomas Gleixner , Ian Campbell , Nicolae Rosia , "linux-arm-kernel@lists.infradead.org" , Michal Marek , Paul Bolle , Peter Hurley , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Philipp Zabel , Greg Kroah-Hartman , Joe Perches , Tejun Heo , Andrew Morton , "David S. Miller" , Vladimir Zapolskiy Subject: Re: [PATCH v8 07/16] drivers: reset: Add STM32 reset driver References: <1431158038-3813-1-git-send-email-mcoquelin.stm32@gmail.com> <1431158038-3813-8-git-send-email-mcoquelin.stm32@gmail.com> <555D1C7D.1060205@suse.de> <555E1CC4.9090605@suse.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2646 Lines: 60 Am 21.05.2015 um 21:57 schrieb Maxime Coquelin: > 2015-05-21 19:58 GMT+02:00 Andreas Färber : >> Actually, I've updated a timer implementation of mine to invoke a reset >> controller similar to how you do in the STM32 clocksource patch, but no >> reset controller is getting returned. >> >> It seems to me, you are working around that by simply ignoring the error >> in the timer code and not doing a reset then, so the STM32 timer does in >> fact _not_ depend on the reset controller? What happened to your efforts >> of making the reset controller usable for the timer? In my case, my >> timer is originally in reset state and needs to be deasserted, so I >> can't just ignore it. > > Indeed, I made the reset optionnal in the clocksource patch since v3. > Rob and Arnd said a lot of platform relies on such things are done by > the bootloader [0]. > I decided to deassert timers reset at bootloader stage, and make it > optionnal in clocksource driver. > I made it optionnal in case we decide one day to move reset > initialization before timer are initialized. > > Note that for now, I still use your bootloader. > I have done the changes to reset the timers in the afboot-stm32. > That's the reason why I asked you under which licence it is delivered > few months ago. Sorry, too many mails... The stm32 one is GPL-2.0, as parts of it were derived from a U-Boot fork. (Personally I prefer GPL-2.0+; fm4 and xmc4000 are MIT/X11.) > I can share you the patch if you want, even if I understand it is more > about the concept that you are reluctant. > > On my side, I plan to move to U-Boot soon, as Kamil Lulko added STM32 > support in mainline [1]. You're free to use any bootloader you like, but you will find it difficult to build in USB etc. drivers given the sheer size of U-Boot. That was my motivation for writing the tiny one. ;) > In case of U-Boot, the timer reset should be de-asserted when jumping > into the Kernel, as Rob mentionned [0]. Thanks, I've updated the xmc4000 one accordingly and can do the same for stm32. But you are right that I consider that an ugly workaround, although on the other hand my earlyprintk patches also depend on the bootloader setting up GPIOs and UART. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/