Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752666AbbF3Uo5 (ORCPT ); Tue, 30 Jun 2015 16:44:57 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:55939 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbbF3Uou (ORCPT ); Tue, 30 Jun 2015 16:44:50 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Paul Osmialowski , Greg Kroah-Hartman , Ian Campbell , Jiri Slaby , Kumar Gala , Linus Walleij , Mark Rutland , Michael Turquette , Pawel Moll , Rob Herring , Russell King , Stephen Boyd , Vinod Koul , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, linux-serial@vger.kernel.org, devicetree@vger.kernel.org, dmaengine@vger.kernel.org, Nicolas Pitre , Sergei Poselenov , Paul Bolle , Jingchang Lu , Yuri Tikhonov , Rob Herring , Geert Uytterhoeven , Uwe Kleine-Koenig , Alexander Potashev , Frank Li , Thomas Gleixner , Anson Huang Subject: Re: [PATCH v2 4/9] arm: twr-k70f120m: timer driver for Kinetis SoC Date: Tue, 30 Jun 2015 22:43:52 +0200 Message-ID: <2939807.q7WvOoYzDX@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1435667250-28299-5-git-send-email-pawelo@king.net.pl> References: <1435667250-28299-1-git-send-email-pawelo@king.net.pl> <1435667250-28299-5-git-send-email-pawelo@king.net.pl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:nWUlM7dI+h56IsCohoU20aJD6Wenkp5ka7TPboIfbrKeu7XexhX IE2b4L9hx3ChLLXO3stBiLTu8udDg2aDsgx3xxOPEd+4pDmpZ0cV/36a6yuVhRbwuIXMRge AN8/Cs0ISMNcyTFmg180FxdPfa/t36m4eInGzRTawG65bMJRmrovvxUl5OGWOQic7Q8ACu1 dFGIc3kOoDyhQVkFeCGug== X-UI-Out-Filterresults: notjunk:1;V01:K0:9oqVR9z4ww8=:t9Hu/KBBCiSiNehQNqaZTX pZLWmIODH6y2xISyMu1GcQ78fNjsvpbh0Wsh1qwdwz0j1puMVf0sAoGYQBRLE1Btm3aIF5zKf Bv8PC+ysHDgFJ5plIFaUgqm4Ldi5ToneitPYK2eqczoXqqNp6rufQPiuexKLk2gbws1MccNS2 dCw7tG48+gJfaYbq2UORNrWAc+gS6wvYJhDLGWyILGa4V3hMAkqAItcRhoWySYUHBaRoDWoTz v8XUC9/Dbscy45hGBW/9SKGcanAy7NvCrhmOV79TPyqh5+beKT0cY6HiNZ9C+UZn28Qrvthqw zEhJDvr/JwjjYTaw4cC7Cy5F9cU5hXABEIYD2XR/NgVfCcINo/fQdnQl2N8Lhq6r80o+OeVmr by876MDuR9osYEw8o3UtkK8vLk/v92N/wGKYL6oYmz3FFqA0qBj8em+llhSbN7vLK+voR9gjn AOXbvUjwo0xzjDP8ZWPAueY9NjQWVhHDop3iPslqqNriJJ6fALOnLTAFv9ghLr92befpfWEML qpnyzHVLcYLa3qFEoA212stWkNtjyGPyZfNnj0ZwmbfM0Ok8zNs2h2+ZZX1GY0MVk4IvMa6JR rVaSmPq7u3/fF88wgjVJXYQ53fnKf13P2C5er3tYxvzCziyyVpOX11DlAUUI7LEQRczRmDml1 nEY3gwrhHeCnra/t7sZOTybuRgz3/eqDTHLpu72EsuuFZ6w== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2988 Lines: 98 On Tuesday 30 June 2015 14:27:25 Paul Osmialowski wrote: > +Example: > + > +aliases { > + pit0 = &pit0; > + pit1 = &pit1; > + pit2 = &pit2; > + pit3 = &pit3; > +}; > + > +pit@40037000 { > + compatible = "fsl,kinetis-pit-timer"; > + reg = <0x40037000 0x100>; > + clocks = <&mcg_pclk_gate 5 23>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; All the subnodes seem to fall inside of the device's own register area, so I think it would be nicer to use a specific 'ranges' property that only translates the registers in question. > / { > + aliases { > + pit0 = &pit0; > + pit1 = &pit1; > + pit2 = &pit2; > + pit3 = &pit3; > + }; > + > soc { > + pit@40037000 { > + compatible = "fsl,kinetis-pit-timer"; > + reg = <0x40037000 0x100>; > + clocks = <&mcg_pclk_gate 5 23>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + pit0: timer@40037100 { > + reg = <0x40037100 0x10>; > + interrupts = <68>; > + status = "disabled"; > + }; I don't think it's necessary to have both an alias and a label here. What do you use the alias for? > + > +#define KINETIS_PITMCR_PTR(base, reg) \ > + (&(((struct kinetis_pit_mcr_regs *)(base))->reg)) > +#define KINETIS_PITMCR_RD(be, base, reg) \ > + ((be) ? ioread32be(KINETIS_PITMCR_PTR(base, reg)) \ > + : ioread32(KINETIS_PITMCR_PTR(base, reg))) > +#define KINETIS_PITMCR_WR(be, base, reg, val) do { \ > + if (be) \ > + iowrite32be((val), KINETIS_PITMCR_PTR(base, reg)); \ > + else \ > + iowrite32((val), KINETIS_PITMCR_PTR(base, reg)); \ > + } while (0) These should really be written as inline functions. Can you explain why you need to deal with a big-endian version of this hardware? Can you configure the endianess of this register block and just set it to one of the two at boot time? > +#define KINETIS_PIT_PTR(base, reg) \ > + (&(((struct kinetis_pit_channel_regs *)(base))->reg)) > +#define KINETIS_PIT_RD(be, base, reg) \ > + ((be) ? ioread32be(KINETIS_PIT_PTR(base, reg)) \ > + : ioread32(KINETIS_PIT_PTR(base, reg))) > +#define KINETIS_PIT_WR(be, base, reg, val) do { \ > + if (be) \ > + iowrite32be((val), KINETIS_PIT_PTR(base, reg)); \ > + else \ > + iowrite32((val), KINETIS_PIT_PTR(base, reg)); \ > + } while (0) > +#define KINETIS_PIT_SET(be, base, reg, mask) \ > + KINETIS_PIT_WR(be, base, reg, \ > + KINETIS_PIT_RD(be, base, reg) | (mask)) > +#define KINETIS_PIT_RESET(be, base, reg, mask) \ > + KINETIS_PIT_WR(be, base, reg, \ > + KINETIS_PIT_RD(be, base, reg) & (~(mask))) Functions again. Also, just pass a pointer to your own data structure into the function, instead of the 'be' and 'base' values. The 'set' and 'reset' functions look like they need a spinlock to avoid races. Arnd -- 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/