From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core Date: Thu, 14 Nov 2013 11:53:51 +0100 Message-ID: <5284ABBF.3080802@samsung.com> References: <1384328457-5147-1-git-send-email-k.kozlowski@samsung.com> <1384328457-5147-2-git-send-email-k.kozlowski@samsung.com> <20131113131328.GF878@sirena.org.uk> <20131114102419.GE26614@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20131114102419.GE26614-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Brown , Kyungmin Park Cc: Krzysztof Kozlowski , MyungJoo Ham , Chanwoo Choi , Samuel Ortiz , Lee Jones , Anton Vorontsov , David Woodhouse , Liam Girdwood , Grant Likely , Rob Herring , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bartlomiej Zolnierkiewicz List-Id: devicetree@vger.kernel.org Hello, On 2013-11-14 11:24, Mark Brown wrote: > On Thu, Nov 14, 2013 at 10:33:22AM +0900, Kyungmin Park wrote: > > On Wed, Nov 13, 2013 at 10:13 PM, Mark Brown wrote: > > > > Are you *positive* this is a falling triggered IRQ? All the code to do > > > with spinning reading the GPIO state during handling makes it look like > > > this is in fact an active low interrupt and a lot of the code in here is > > > working around trying to handle that as the wrong kind of IRQ. > > > It's not work with level triggering. as wm8994, it requires edge > > triggering. previous time I send RFC patch to handle edge triggering > > at regmap. > > No, wm8994 is level triggered only - the edge triggering stuff there is > to work around some SoCs that could only support edge triggering and not > level triggering. Is this a similar issue or is there something else > going on, what's the differeence with a level triggered scheme? > > > >> +static int __init max14577_i2c_init(void) > > >> +{ > > >> + return i2c_add_driver(&max14577_i2c_driver); > > >> +} > > >> +subsys_initcall(max14577_i2c_init); > > > > Why not module_i2c_driver? > > > there's ordering issue, it should provide regulator which is used > > others before USB probe. if not, it failed to use USB. > > Other PMICs use also subsys_initcall for this reason. > > Modern systems should be able to use deferred probing to resolve these > dependencies, subsys_initcall() is mostly there for legacy reasons and > new systems ought to be able to move away from it. The main problem here is usb gadget subsystem, which simply doesn't support deferred probe yet. UDC driver (which uses those regulators) need to be initialized before usb gadget driver (i.e. mass storage or cdc ethernet) has been registered. Best regards -- Marek Szyprowski Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html