Re: Why is the deferred initcall patch not mainline?

2014-10-21 Thread Grant Likely
On Sat, Oct 18, 2014 at 9:11 AM, Bird, Tim tim.b...@sonymobile.com wrote: The answer is pretty easy, I think. I tried to mainline it once but failed, and didn't really try again. If it is being found useful, we should try to mainline it again, this time with more persistence. The reason

Re: Why is the deferred initcall patch not mainline?

2014-10-21 Thread Grant Likely
On Tue, Oct 21, 2014 at 1:52 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Sat, Oct 18, 2014 at 9:11 AM, Bird, Tim tim.b...@sonymobile.com wrote: The answer is pretty easy, I think. I tried to mainline it once but failed, and didn't really try again. If it is being found useful, we

Re: [PWM v9 1/3] PWM: Implement a generic PWM framework

2011-04-14 Thread Grant Likely
...@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [PATCH 0/5] RFC: KBUS messaging subsystem

2011-02-27 Thread Grant Likely
On Sun, Feb 27, 2011 at 06:11:43PM +, Tony Ibbs wrote: KBUS is a lightweight, Linux kernel mediated, message system, particularly intended for use in embedded environments. It is meant to be simple to use and understand. It is designed to provide predictable message delivery,

Re: [PATCH 0/5] RFC: KBUS messaging subsystem

2011-02-27 Thread Grant Likely
On Mon, Feb 28, 2011 at 12:48 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Sun, Feb 27, 2011 at 06:11:43PM +, Tony Ibbs wrote: KBUS is a lightweight, Linux kernel mediated, message system, particularly intended for use in embedded environments. It is meant to be simple to use

Re: [RFC][PATCH] KBUS messaging subsystem

2011-02-03 Thread Grant Likely
On Thu, Feb 3, 2011 at 10:04 AM, Tony Ibbs t...@kynesim.co.uk wrote: Apologies again for getting Grant's email address wrong on my initial email. On Tue, 1 Feb 2011 20:40:08 -0700 Grant Likely grant.lik...@secretlab.ca wrote: There are already a large number of communication channels

Re: [RFC][PATCH] KBUS messaging subsystem

2011-02-01 Thread Grant Likely
From: Tony Ibbs t...@kynesim.co.uk To: Linux-embedded linux-embedded@vger.kernel.org Cc: Grant Likely grant.lik...@secretlab.com, Tibs at home t...@tonyibbs.co.uk, Richard Watts r...@kynesim.co.uk Subject: [RFC][PATCH] KBUS messaging subsystem [...] We've got a working repository

Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface

2010-10-16 Thread Grant Likely
On Wed, Oct 6, 2010 at 12:48 PM, Bill Gatliff b...@billgatliff.com wrote: Hector: On Sat, Oct 2, 2010 at 7:25 AM, Hector Oron hector.o...@gmail.com wrote: Hello Bill, Thanks for trying (again) to get this in mainline. Are you planning to request a slot in the GIT at kernel.org to hold and

Re: [PWM 03/10] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API

2010-10-16 Thread Grant Likely
On Fri, Oct 01, 2010 at 10:17:44AM -0500, Bill Gatliff wrote: Signed-off-by: Bill Gatliff b...@billgatliff.com This patch needs a better description about what is going on here. If you're replacing an old driver, you must talk about what is changing and why. You cannot assume that a future

Re: [PWM 04/10] Implements PWM-based LED control

2010-10-16 Thread Grant Likely
On Fri, Oct 01, 2010 at 10:17:45AM -0500, Bill Gatliff wrote: Signed-off-by: Bill Gatliff b...@billgatliff.com Ditto on comment and patch title --- drivers/leds/Kconfig| 19 +++- drivers/leds/leds-pwm.c | 224 +++---

Re: [PWM 05/10] LED dim trigger based on PWM control of the LED

2010-10-16 Thread Grant Likely
On Fri, Oct 01, 2010 at 10:17:46AM -0500, Bill Gatliff wrote: Signed-off-by: Bill Gatliff b...@billgatliff.com Ditto on description Otherwise pretty straight forward. Looks okay to me. g. --- drivers/leds/ledtrig-dim.c | 96 1 files

Re: [PWM 06/10] Incorporate PWM API code into KBuild

2010-10-16 Thread Grant Likely
On Fri, Oct 01, 2010 at 10:17:47AM -0500, Bill Gatliff wrote: Signed-off-by: Bill Gatliff b...@billgatliff.com Ditto on description. --- drivers/Kconfig |2 ++ drivers/Makefile |2 ++ drivers/leds/Kconfig | 22 -- drivers/leds/Makefile |2 ++

Re: Linux Plumbers Embedded microconference

2010-10-15 Thread Grant Likely
On Fri, Oct 15, 2010 at 09:20:28AM -0700, Kevin Hilman wrote: Hi Grant, Do you have a draft agenda yet for the microconf? Specifically, I'd like to get a better feel for how much time we'll dedicate to each topic, and therefore be better prepared for the discussions. Working on it.

Re: Linux Plumbers Embedded microconference

2010-09-20 Thread Grant Likely
On Mon, Sep 20, 2010 at 10:14:43AM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: Here is my draft list: Kevin: How HWMOD is used to describe interconnections between internal SoC devices. For omap_hwmod, I would like Paul Walmsley (Cc'd) to lead

Re: [RFC] Kernel 'boot cache' to reduce boot time

2010-08-31 Thread Grant Likely
. BTW - I could see this tying into the flattened device tree work by Grant Likely. http://www.devicetree.org/Device_Tree_Usage g. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: Embedded topics at Linux Plumbers 2010

2010-07-08 Thread Grant Likely
Update: We've now released the official call for proposals: http://www.linuxplumbersconf.org/2010 Cheers, g. On Tue, Jul 6, 2010 at 1:56 PM, Grant Likely grant.lik...@secretlab.ca wrote: Hi all, I'm on the Linux Plumbers [1] planning committee this year, and I'm also heading up

Embedded topics at Linux Plumbers 2010

2010-07-06 Thread Grant Likely
free to email me. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: A better way to sequence driver initialization?

2010-04-10 Thread Grant Likely
On Sat, Apr 10, 2010 at 5:39 PM, Paul Mundt let...@linux-sh.org wrote: In cases where you can specifically note that dependencies, doing so will save you a world of pain. Despite that, it's simply not possible to do this as a free-for-all. Devices or busses that can tolerate multi-threaded

Re: xilinx_spi in linux-next

2010-02-04 Thread Grant Likely
lane ordering either being big or little endian, hence the driver using both io{read,write}32() and io{read,write}32be(), but the 'be' variants aren't implemented on all architectures. What's a driver author to do when trying to write portable code? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab

Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)

2010-01-21 Thread Grant Likely
as that is what it is designed for. You can also run a trivial script at boot to read /proc/devices and create the device nodes as described in chapter 3, page 47 of LDD3: http://lwn.net/images/pdf/LDD3/ch03.pdf g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-23 Thread Grant Likely
On Mon, Nov 23, 2009 at 7:12 AM, Bill Gatliff b...@billgatliff.com wrote: Grant Likely wrote: I'm talking about discrete controllable entities. At the extreme, I see discrete, single-pin GPIO as being a degenerate case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a single

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-23 Thread Grant Likely
On Mon, Nov 23, 2009 at 7:13 AM, Bill Gatliff b...@billgatliff.com wrote: Grant Likely wrote: But that *isn't* the primary purpose of the GPIO subsystem.  All that stuff is layered on top of the GPIO pin management code and doesn't really play into this debate. I don't understand you.  You

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-23 Thread Grant Likely
On Mon, Nov 23, 2009 at 8:29 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote: On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net wrote: Since *everything* boils down to one or more signal lines, your

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-20 Thread Grant Likely
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net wrote: On Friday 13 November 2009, Grant Likely wrote: I'm concerned about the approach taken here.  As I understand it, the PWM signals are very similar to GPIOs in that each PWM device controls an external signal line, just

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-20 Thread Grant Likely
On Tue, Nov 17, 2009 at 8:39 AM, Bill Gatliff b...@billgatliff.com wrote: Grant Likely wrote: Hi Bill On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff b...@billgatliff.com wrote: This series implements a Generic PWM Device API, including reference implementations for the Atmel PWMC device

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-20 Thread Grant Likely
it with GPIOs ... or, combine everything else with GPIOs too (like PWMs). But Grant talks about wanting such things, and if he can deliver it, more power to him. Just to be clear, I'm *not* talking about pin mux. I fully agree that is a different problem. g. -- Grant Likely, B.Sc., P.Eng. Secret

Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver

2009-10-09 Thread Grant Likely
On Thu, Oct 8, 2009 at 4:20 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Thu, Oct 08, 2009 at 09:48:50AM -0600, Grant Likely wrote: But the focus is still on creating pdata.  If a translator gets too big, then sure, split it into a separate file.  Until then, there I see no good

Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver

2009-10-09 Thread Grant Likely
On Fri, Oct 9, 2009 at 8:01 AM, Nate Case nc...@xes-inc.com wrote: On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote: For your future reference, patches that look at the device tree should also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can be reviewed and common mistakes

Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver

2009-10-09 Thread Grant Likely
, Wolfram's and your work things are going the right way. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver

2009-10-08 Thread Grant Likely
On Thu, Oct 8, 2009 at 9:10 AM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Thu, Oct 08, 2009 at 08:53:46AM -0600, Grant Likely wrote: [...] Please don't.  It is such a small amount of code, It's *always* a small amound of code, at a start. Then we get floppy disk drivers and the tty

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread Grant Likely
about the device registration order, and the drivers notifier callback will get called at the appropriate time. In your example case I could see the framebuffer driver deferring the final part of its initialization until the needed i2c device shows up. g. -- Grant Likely, B.Sc., P.Eng. Secret

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread Grant Likely
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Grant Likely wrote: http://patchwork.ozlabs.org/patch/24152/ I never actually pushed through and finished it because it turned out to be a non-issue for Ethernet devices in the end.  However, I can see the value

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-16 Thread Grant Likely
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokierja...@shareable.org wrote: Grant Likely wrote: On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote: Something which lets you specify a dependency in a one-line MODULE_INIT_PREREQS() macro would be much nicer. That would work

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-13 Thread Grant Likely
. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-04 Thread Grant Likely
On Tue, Jun 2, 2009 at 11:48 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote: One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform.  ie. On x86, PowerPC and Sparc

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-04 Thread Grant Likely
, and so on. No, not comprehensive; just common. It makes sense to spend the effort on the patterns and devices which are common. It may not cover everything, but it doesn't have to to be valuable. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-04 Thread Grant Likely
. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-02 Thread Grant Likely
and getting some of the arch maintainers together in a room might prove fruitful. Particularly if we are going to discuss how to make drivers work for device tree and standard platforms alike. josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-02 Thread Grant Likely
a lot of common mistakes. I also think the stuff in Documentation/powerpc/dts-bindings needs to be moved out to a common location. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message

Re: How to handle device drivers depending on another device.

2008-12-10 Thread Grant Likely
device is ready. Of course, if you're using loadable modules, then the dependencies should take care of things for you. For the bus infrastructure, yes, but not for the bus instances. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line

Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

2008-11-25 Thread Grant Likely
. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] phylib: make mdio-gpio work without OF (v2)

2008-11-05 Thread Grant Likely
is to write separate driver for OF which will be just wrapper for platform driver... Just like you suggested. More complex than necessary. Just give the driver 2 blocks of binding code; one for OF, one for non-OF. No need to split up the driver. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab

Re: [PATCH] phylib: make mdio-gpio work without OF (v2)

2008-11-04 Thread Grant Likely
and add another one creating the struct mdio_gpio_platform_data using OF specific functions? This is a very simple driver. There is no need to split it into two files. Have two sections of bus binding (OF and non-OF) is just fine. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd

Re: [PATCH] phylib: make mdio-gpio work without OF (v2)

2008-11-04 Thread Grant Likely
; +}; + +#endif /* __LINUX_MDIO_GPIO_H */ -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] phylib: make mdio-gpio work without OF

2008-10-31 Thread Grant Likely
#ifdef sections throughout the probe function, use one #ifdef block for the OF stuff and another for all the non-OF stuff. You can factor out any non-trivial common code blocks into shared helper functions. Otherwise, looking good. Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies

Re: [PATCH] phylib: add mdio-gpio bus driver (v3)

2008-10-29 Thread Grant Likely
On Wed, Oct 29, 2008 at 2:44 AM, Paulius Zaleckas [EMAIL PROTECTED] wrote: Grant Likely wrote: On Tue, Oct 28, 2008 at 5:31 AM, Paulius Zaleckas [EMAIL PROTECTED] wrote: Mike Frysinger wrote: On Tue, Oct 28, 2008 at 06:35, Paulius Zaleckas wrote: +config MDIO_GPIO + tristate Support

Re: [PATCH] phylib: add mdio-gpio bus driver (v2)

2008-10-28 Thread Grant Likely
On Tue, Oct 28, 2008 at 1:46 AM, Paulius Zaleckas [EMAIL PROTECTED] wrote: Grant Likely wrote: The IRQ array is fixed size. You can add it to the mdio_gpio_info structure and then just set the pointer here so that only one kzalloc is needed. It can be put in mdio_gpio_info, but please note

Re: [PATCH] phylib: add mdio-gpio bus driver (v3)

2008-10-28 Thread Grant Likely
bus binding to the existing driver. Most of the code can be shared. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: [PATCH] phylib: add mdio-gpio bus driver (v2)

2008-10-28 Thread Grant Likely
On Tue, Oct 28, 2008 at 9:17 AM, Russell King - ARM Linux [EMAIL PROTECTED] wrote: On Tue, Oct 28, 2008 at 07:08:06AM -0600, Grant Likely wrote: On Tue, Oct 28, 2008 at 1:46 AM, Paulius Zaleckas [EMAIL PROTECTED] wrote: Grant Likely wrote: The IRQ array is fixed size. You can add

Merge linuxppc-embedded with linuxppc-dev

2008-09-22 Thread Grant Likely
Jeremy, Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? I don't think we need two separate lists anymore and patches to linuxppc-embedded don't always get dealt with. Anyone have any objections to eliminating linuxppc-embedded? g. -- Grant Likely, B.Sc

Re: Merge linuxppc-embedded with linuxppc-dev

2008-09-22 Thread Grant Likely
On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 18:08, Grant Likely [EMAIL PROTECTED] wrote: Jeremy, Can we eliminate the linuxppc-embedded mailing list and merge it with linuxppc-dev? I don't think we need two separate lists anymore

ELBS mindshare

2008-09-17 Thread Grant Likely
Hey Behan, BTW, I was talking with a guy from TI last night (Mike Turquette; works on the OMAP) and I asked him my standard question about what he thinks about the state of building root filesystems for embedded systems. When he listed the toolkits he knows about and is interested in, ELBS was

Re: embedded rootfs utility

2008-08-14 Thread Grant Likely
before it would boot. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Flatten device tree PPC linu

2008-08-14 Thread Grant Likely
. It is a 2.6 thing for arch/powerpc. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging

2008-08-12 Thread Grant Likely
reason I could see wanting to do things this way is if you don't trust the console code to call your console driver, which I think is a pretty unlikely case. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded

Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging

2008-08-12 Thread Grant Likely
On Tue, Aug 12, 2008 at 06:30:54PM -0700, David VomLehn wrote: Grant Likely wrote: I'm not thrilled with this patch. It seems so much more straight forward in your special case, but it comes at the expense of making the code path more complex in every other case. I would much rather see