Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

In message: Christoph Lameter writes: : On Thu, 23 Sep 2010, Christian Riesch wrote: : : > > > It implies clock tuning in userspace for a potential sub microsecond : > > > accurate clock. The clock accuracy will be limited by user space : > > > latencies and noise. You wont be able t

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

In message: Christoph Lameter writes: : On Thu, 23 Sep 2010, john stultz wrote: : > The design actually avoids most userland induced latency. : > : > 1) On the PTP hardware syncing point, the reference packet gets : > timestamped with the PTP hardware time on arrival. This allows the

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

In message: <20100827140205.ga3...@riccoc20.at.omicron.at> Richard Cochran writes: : On Fri, Aug 27, 2010 at 01:41:54PM +0100, Alan Cox wrote: : > > The master node in a PTP network probably takes its time from a : > > precise external time source, like GPS. The GPS provides a 1 PPS :

Re: Request review of device tree documentation

In message: <4c187013.5000...@firmworks.com> Mitch Bradley writes: : Mike Rapoport wrote: : > Mitch Bradley wrote: : >> Mike Rapoport wrote: : >>> Mitch Bradley wrote: : >>> : The second topic is the hypothetical use of OFW as a HAL. That will : not happen for several reasons

Re: Request review of device tree documentation

In message: <20100614124438.gf9...@yookeroo> David Gibson writes: : On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote: : [sni] : > > That's sort of a self-fulfilling prophecy.  If the OS doesn't trust the : > > firmware, there is no pressure for the firmware to "get it right

Re: [PATCH 6/6] of/device: populate platform_device (of_device) resource table on allocation

In message: <20100610165243.ga18...@oksana.dev.rtsoft.ru> Anton Vorontsov writes: : On Thu, Jun 10, 2010 at 10:01:40AM -0600, M. Warner Losh wrote: : [...] : > But this requires extra, bogus fields in the structure : : False. The [0] field isn't bogus, it has a defined

Re: [PATCH 6/6] of/device: populate platform_device (of_device) resource table on allocation

In message: <20100610154741.ga7...@oksana.dev.rtsoft.ru> Anton Vorontsov writes: : On Thu, Jun 10, 2010 at 09:13:57AM -0600, M. Warner Losh wrote: : [...] : > : >> I told you several ways of how to improve the code (based on : > : >> the ideas from drivers/ba

Re: [PATCH 6/6] of/device: populate platform_device (of_device) resource table on allocation

In message: Grant Likely writes: : On Thu, Jun 10, 2010 at 12:17 AM, Benjamin Herrenschmidt : wrote: : > : >> You just introduced an unnamed structure of device + resources, : >> it isn't declared anywhere but in the code itself (either via : >> &foo[1] or buf + sizeof(*foo)). : >> :

Re: [PATCH] powerpc: make the padding for the device tree a configurable option

In message: Timur Tabi writes: : I'm stuck between a rock and a hard place, it seems. No one is : willing to compromise on any of my ideas. It's hard to convince our : BSP developers that they should be pushing more code upstream when I : get so much resistance for a such a mundane

Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware

In message: Timur Tabi writes: : The initrd thing is a good idea, but it doesn't help non-Linux : operating systems. Then again, those OS's might not have any GPL : issues, so it could be a moot point. Most !linux systems are not GPL'd. They are BSDL, primarily, or some private lic

Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware

In message: <4baa4c8a.70...@freescale.com> Timur Tabi writes: : Most firmware is 8-12KB, so this will make for one ugly DTS. Plus, : there's the issue of distributing non-GPL firmware data inside a : DTS, which is GPL. Is there some reason that the firmware couldn't be loaded by ubo

Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef

In message: Grant Likely writes: : Word from Mitch is the device tree is network byte order. period. OpenFirmware defines the order to be big endian always, even on little endian processors. Warner ___ Linuxppc-dev mailing list Linuxppc-d

Re: [RFC] Clock binding

In message: <955e48b80908281105q60c057e8pfc16213f17da9...@mail.gmail.com> Stuart Yoder writes: : > Lets *not* do it on power.org.  I'd like to see the bindings used by : > more than just powerpc people, and power.org might become a bit of a : > mental barrier for non-powerpc folks.  ke

Re: [PATCH 10/10] mmc: Add OpenFirmware bindings for SDHCI driver

In message: <497c09d9.50...@genesi-usa.com> Matt Sealey writes: : Anton Vorontsov wrote: : > : > If unsure, say Y. : > : > +config MMC_SDHCI_OF : > + tristate "SDHCI support on OpenFirmware platforms" : > + depends on MMC_SDHCI && PPC_OF : > + help : > + This select

Re: Board level compatibility matching

I'd float a radical definition of 'compatible' here. If the generic code can handle it with just changes to the device tree, then it is compatible. And by generic code, I wouldn't suggest a twisty maze of ifdefs or special case hacks. I'm talking truly generic code that is table driven entirely

Re: [PATCH] of: i2c: improve last resort compatible entry selection

In message: <[EMAIL PROTECTED]> "Jon Smirl" <[EMAIL PROTECTED]> writes: : On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote: : > > : > > > : > > > > compatible = "atmel,24c32wp", "24c32", "eeprom"; : > > > > : > > > : > > : > : > : > > : > > > I know this is just an example; but