On Wed, 13 May 2009, Wolfram Sang wrote:
> > diff --git a/include/linux/leds.h b/include/linux/leds.h
> > index 376fe07..66e7d75 100644
> > --- a/include/linux/leds.h
> > +++ b/include/linux/leds.h
> > @@ -141,9 +141,14 @@ struct gpio_led {
> > const char *name;
> > const char *default_trig
uot; that can be set to "on",
"off", or "keep". The default if the property isn't present is off.
Signed-off-by: Trent Piepho
Acked-by: Grant Likely
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 17 -
drivers/leds/leds-
On Mon, 6 Apr 2009, Sean MacLennan wrote:
> Now that leds-gpio is a proper OF platform driver, the Warp can use
> the leds-gpio driver rather than the old out-of-kernel driver.
>
> One side-effect is the leds-gpio driver always turns the leds off
> while the old driver left them alone. So we have t
On Sun, 11 Jan 2009, Richard Purdie wrote:
> On Sat, 2009-01-10 at 21:43 -0800, Trent Piepho wrote:
> > On Sun, 11 Jan 2009, Richard Purdie wrote:
> > > On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote:
> > > > The LED tree makes more sense for wha
On Sun, 11 Jan 2009, Richard Purdie wrote:
> On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote:
> > The LED tree makes more sense for what's left I think. There was a
> > openfirmware gpio patch, but that's already gone in. What's left only
> > touches l
On Fri, 9 Jan 2009, Richard Purdie wrote:
> On Fri, 2009-01-09 at 12:37 -0800, Trent Piepho wrote:
> > On Fri, 9 Jan 2009, Richard Purdie wrote:
> > > for the LED tree updates for 2.6.29. This includes some new drivers,
> > > bugfixes and a core improvem
2.6.28 is out, can my existing patches be accepted?
[2/2] POWERPC/fsl-pci: Set relaxed ordering on prefetchable ranges
http://patchwork.ozlabs.org/patch/14546/
[1/2] POWERPC/fsl-pci: Better ATMU setup
http://patchwork.ozlabs.org/patch/14544/
[5/5] powerpc: booke: Allow larger CAM sizes than 256
On Tue, 16 Dec 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-15 at 17:11 -0800, Trent Piepho wrote:
>> Shame, as it provides a huge speed up. I suppose an alternative would be
>> to map the chip twice at different physical addresses, by just configuring
>> the chip s
lowed one memory range of each type. And if you
want the range at a PCI address above 32 bits you must make it
prefetchable.
Signed-off-by: Trent Piepho
---
arch/powerpc/sysdev/fsl_pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pc
abilities allowed a
powerpc pci_controller is neither subset nor a superset of the abilities of
a Freescale PCIe controller. Thankfully, the most useful bits are in the
intersection of the two abilities.
Signed-off-by: Trent Piepho
---
arch/powerpc/sysdev/fsl_pci.c | 104
On Tue, 16 Dec 2008, Paul Mackerras wrote:
> Trent Piepho writes:
>> The MTD system supports operation where a direct mapped flash chip is
>> mapped twice. The normal mapping is a standard ioremap(), which is
>> non-cached and guarded on powerpc. The second mapping is used
On Mon, 15 Dec 2008, Josh Boyer wrote:
>
> Did you actually change anything in this version when compared to the
> version you sent out last week? If not, is there a reason you sent it
> again without flagging it as a resend?
I sent it out last week? I'm trying to tie up loose ends before I leav
nything in the cache. But this could be fixed.
Signed-off-by: Trent Piepho
---
arch/powerpc/include/asm/cacheflush.h |2 ++
arch/powerpc/kernel/misc_32.S | 21 +
drivers/mtd/maps/physmap_of.c | 20
3 files changed, 43 insertions(
ss can use mmap() on them to map the PCI BAR into its
address space. Because each process get it's own address space, you could
have multiple processes which have mapped a total of more than 4 GB. But
this is for userspace processes, not the kernel. The kernel only gets one
address space.
>
On Fri, 12 Dec 2008, Anton Vorontsov wrote:
> On Fri, Dec 12, 2008 at 11:59:13AM -0500, Steven A. Falco wrote:
>> What do you think about having a mechanism to specify that some
>> SPI slaves have a chip select, while others don't have to have a
>> chip select managed by the SPI subsystem?
>
> Um..
On Fri, 12 Dec 2008, Kumar Gala wrote:
> On Dec 12, 2008, at 3:04 AM, Trent Piepho wrote:
>> On Thu, 11 Dec 2008, Kumar Gala wrote:
>> > On Dec 11, 2008, at 10:07 PM, Trent Piepho wrote:
>> > > On Thu, 11 Dec 2008, Kumar Gala wrote:
>> > > > The 36
On Thu, 11 Dec 2008, Kumar Gala wrote:
> On Dec 11, 2008, at 10:07 PM, Trent Piepho wrote:
>> On Thu, 11 Dec 2008, Kumar Gala wrote:
>> > On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote:
>> > > In the system, the total PCI address needed is about 3GB, so I want
On Thu, 11 Dec 2008, Kumar Gala wrote:
> On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote:
>> In the system, the total PCI address needed is about 3GB, so I want to know
>> how to support it in linux. mpc8548 has 36-bit real address, and can
>> support 32GB PCIE address space, but in linux, the
constant to set it to. Yet despite
these shortcomings it remains more popular.
Signed-off-by: Trent Piepho
---
drivers/leds/leds-gpio.c | 15 +++
include/linux/leds.h |7 +--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b
t;default-state" property gains a new
allowable setting "keep".
Signed-off-by: Trent Piepho
Acked-by: Grant Likely
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 16
drivers/leds/leds-gpio.c| 12
igned-off-by: Trent Piepho
Acked-by: Grant Likely
Acked-by: Sean MacLennan
CC: devicetree-disc...@ozlabs.org
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 46 -
drivers/leds/Kconfig| 21 ++-
drivers/leds/leds-gpio.c|
tate" that controls this. The OpenFirmware binding uses a
property named "default-state" that can be set to "on" or "off". The
default if the property isn't present is off.
Signed-off-by: Trent Piepho
Acked-by: Grant Likely
---
Documentation/powerp
On Wed, 10 Dec 2008, Anton Vorontsov wrote:
>> +gpio_direction_output(led_dat->gpio, led_dat->active_low);
>
> This can fail (yeah, the original code didn't check return value
> either).
I've added a check.
>> +unsigned int flags;
>
> I think it would be better to use `enum of_gpi
On Wed, 10 Dec 2008, Josh Boyer wrote:
> On Thu, 11 Dec 2008 10:46:28 +1100
>>> +#ifdef CONFIG_PCI
>>> +extern unsigned int ppc_pci_flags;
>>> +#define ppc_pci_set_flags(flags) ppc_pci_flags = (flags)
>>> +#define ppc_pci_add_flags(flags) ppc_pci_flags |= (flags)
>>> +#define ppc_pci_flag_is_set(fl
On Thu, 11 Dec 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-12-10 at 11:33 -0800, Trent Piepho wrote:
>> On Wed, 10 Dec 2008, Benjamin Herrenschmidt wrote:
>>> This changes the logic so that instead, the PTE now contains
>>> _PAGE_COHERENT for all normal RAM pag
On Wed, 10 Dec 2008, Benjamin Herrenschmidt wrote:
> This changes the logic so that instead, the PTE now contains
> _PAGE_COHERENT for all normal RAM pages tha have I = 0. The hash
> code clears it if the feature bit is not set.
Why not check the feature bit when the PTE is made and unset _PAGE_CO
tate" that controls this. The OpenFirmware binding uses a
property named "default-state" that can be set to "on" or "off". The
default if the property isn't present is off.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Grant Likely <
constant to set it to. Yet despite
these shortcomings it remains more popular.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
drivers/leds/leds-gpio.c | 15 +++
include/linux/leds.h |7 +--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/driver
ltiple LEDs
per device.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: Sean MacLennan <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 46 -
drivers/leds/Kconfig
t;default-state" property gains a new
allowable setting "keep".
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 16
drivers/leds/leds-gpio.c
On Wed, 10 Dec 2008, Liu Yu wrote:
> KVM on E500 platform currently utilize TLB1 entries without bothering host,
> that is using unused TLB1 entries.
>
> So, KVM needs to read tlbcam_index and num_tlbcam_entries to know exactly
> which TLB1 entry is unused.
Do you need really need num_tlbcam_entri
On Wed, 3 Dec 2008, Richard Purdie wrote:
> On Sun, 2008-11-23 at 13:31 +0100, Pavel Machek wrote:
>> On Thu 2008-11-20 17:05:56, Trent Piepho wrote:
>>> I thought of that, but it ends up being more complex. Instead of just
>>> using:
>>> static const str
ages
to be used, which combined with the limited number of TLB1 pages available,
will result in very little memory getting mapped. So alignments less than
64 MB probably aren't very useful anyway.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig
ry to have four CAM entries.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig| 16
arch/powerpc/mm/fsl_booke_mmu.c |6 +-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kc
converted to use an array, it will be easier to make the number of
CAMs configurable.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/mm/fsl_booke_mmu.c | 79 +++---
1 files changed, 31 insertions(+), 48 deletions(-)
diff --git a/arch/powe
mpler than a
global initialized during kernel boot from assembly.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_fsl_booke.S |4
arch/powerpc/mm/fsl_booke_mmu.c |1 -
arch/powerpc/mm/mmu_decl.h |2 --
3 files changed, 0 insertions
, so let's use it.
The definition of the struct gets moved to a header, so that asm-offsets.c
can include it.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/asm-offsets.c|8
arch/powerpc/kernel/head_fsl_booke.S |2 +-
arch/powerpc/mm/fsl_
On Tue, 2 Dec 2008, Kumar Gala wrote:
> Added 85xx specifc smp_ops structure. We use ePAPR style boot release
> and the MPIC for IPIs at this point.
>
> Additionally added routines for secondary cpu entry and initializtion.
>
> @@ -740,6 +750,9 @@ finish_tlb_load:
> #else
> rlwimi r12, r11,
nything in the cache. But this could be fixed.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Should this go in via powerpc tree or mtd?
arch/powerpc/include/asm/cacheflush.h |2 ++
arch/powerpc/kernel/misc_32.S | 21 +
drivers/mtd/maps/physmap_of.c
On Tue, 2 Dec 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-12-02 at 01:36 -0600, Kumar Gala wrote:
>
>>> #define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \
>>> CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \
>>> - CPU_FTR_UNIFIED_ID_CACHE)
>>> + CPU_FTR_
On Wed, 3 Dec 2008, Sean MacLennan wrote:
>> Yes, I would recommend to do it this way if possible. A small NOR for
>> U-Boot and environment and everything else in NAND. This makes things
>> much easier. But I understand that this is sometimes a problem with
>> space (2 FLASH chips) and costs.
>
>
On Tue, 2 Dec 2008, Nathan Lynch wrote:
> Apart from barriers (or lack thereof), the fact that __cpu_up gives up
> after a more-or-less arbitrary period seems... well, arbitrary. If we
> get to "Processor X is stuck" then something is seriously wrong:
> there's either a kernel bug or a platform is
On Mon, 1 Dec 2008, Scott Wood wrote:
> Trent Piepho wrote:
>> U-boot could pass in "bus-frequency" to let software know the speed of the
>> I2C bus from Linux. Seems like a standard property for bus nodes.
>
> clock-frequency is standard, though it should
On Mon, 1 Dec 2008, Andr? Schwarz wrote:
> Timur Tabi wrote:
>> Trent Piepho wrote:
>>
>>
>> > Seems like it should keep the clock registers at what u-boot set them
>> > too.
>> >
>>
>> Or we could have U-Boot put the i2c clock fre
On Thu, 27 Nov 2008, Andre Schwarz wrote:
> Timur Tabi schrieb:
>> On Thu, Nov 27, 2008 at 9:00 AM, Andre Schwarz
>> <[EMAIL PROTECTED]> wrote:
>>
>>> All,
>>>
>>> is anybody working on some improvements regarding configurable I2C
>>> frequency inside the i2c-mpc driver ?
>>>
>>> If not - would any
On Thu, 27 Nov 2008, Anton Vorontsov wrote:
> This function is alike to the simple of_get_gpio(), but accepts new
> argument: flags. This new function will be used by the drivers that
> need to retrieve additional GPIO information, such as active-low flag.
>
> Signed-off-by: Anton Vorontsov <[EMAIL
On Thu, 27 Nov 2008, Paul Mackerras wrote:
> Anton Vorontsov writes:
>
>> Can we apply it? Paul, Benjamin?
>>
>> The patchwork url for this patch is:
>> http://patchwork.ozlabs.org/patch/6650/
>>
>>
>> Thanks!
>>
>>> drivers/mtd/nand/fsl_upm.c |2 +-
>>> drivers/net/fs_enet/fs_ene
On Mon, 24 Nov 2008, Morrison, Tom wrote:
> Running 2.6.23.25 kernel...
>
> I have an external watchdog timer that is going off - and pulsing into
> the MCP0 of the 8572E. I get the printk indicating that the MCP0 went
> off - the problem is - how do I clear the condition that caused this
> because
On Sat, 22 Nov 2008, Milton Miller wrote:
> On Thu Nov 20 at 06:14:30 EST in 2008, Trent Piepho wrote:
>> - li r7,0
>> - lis r6,PAGE_OFFSET at h
>> - ori r6,r6,PAGE_OFFSET at l
>> - rlwimi r6,r7,0,20,31
>> +
On Mon, 17 Nov 2008, Richard Purdie wrote:
> On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
>> +if (template->keep_state)
>> +state = !!gpio_get_value(led_dat->gpio) ^ led_dat->active_low;
>> +else
>> +
e
didn't clear them, this code does.
The same when the page of KERNELBASE is found; we don't need to use asm to
mask the lower 12 bits off.
In the code that computes the address to rfi from, don't hard code the
offset to 24 bytes, but have the assembler figure that out for us.
Signed-o
It's 1MB, not 512KB. Newer U-Boots will fix this entry, but that's no
reason to have the wrong value in the dts.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8572ds.dts |2 +-
1 files chang
On Tue, 18 Nov 2008, Michael Ellerman wrote:
> On Mon, 2008-11-17 at 14:22 -0800, Trent Piepho wrote:
>> On Mon, 17 Nov 2008, Kumar Gala wrote:
>>> On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
>>>
>>>> It's over a dozen lines of output and doesn
On Mon, 17 Nov 2008, Kumar Gala wrote:
> On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
>
>> It's over a dozen lines of output and doesn't appear to provide any useful
>> information. Even after looking at the code, I'm in the dark about what
>> "sco
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about what
"score 299, offset 250" means.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/smp-tbsync
nd fixes the table of contents.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Kumar Gala <[EMAIL PROTECTED]>
---
Maybe this should go in 2.6.28, since it fixes a doc bug and before
anyone modifies the version of the docs that should have been deleted.
Documenta
t any
flags present from the gpio_spec.
The default (and currently only) of_gpio_chip xlate method,
of_gpio_simple_xlate(), is modified to do this.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: Anton Vorontsov <[EMAIL PROTECTED]&g
being
accessible to the network.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
Acked-by: Andy Fleming <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 249541
device with
the right ID. The platform device's driver data is the mii_bus structure,
which the SerDes setup code can use to lock the current bus.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
CC: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.
On Tue, 28 Oct 2008, Nate Case wrote:
> Some SGMII PHYs don't auto-negotiate correctly with the TBI+SerDes
> interface on the mpc85xx processors. Check for the "sgmii-aneg-disable"
> device tree flag and skip enabling auto-negotiation on the TBI
> side if present. Full duplex 1000 Mbit/s will be
On Thu, 30 Oct 2008, Peter Korsgaard wrote:
>>>>>> "Trent" == Trent Piepho <[EMAIL PROTECTED]> writes:
> Trent> On Tue, 23 Sep 2008, Peter Korsgaard wrote:
> >> +- compatible : "fsl,-gpio" followed by "fsl,mpc8349-gpio" for
>
On Tue, 28 Oct 2008, Anton Vorontsov wrote:
> On Fri, Oct 24, 2008 at 04:08:58PM -0700, Trent Piepho wrote:
>> + * @flags: if non-NUll flags are returned here
>
> NULL, not NUll.
Thanks, fixed.
>> + const void *gpio_spec, unsigned int *flags)
>
> W
On Tue, 23 Sep 2008, Peter Korsgaard wrote:
> +- compatible : "fsl,-gpio" followed by "fsl,mpc8349-gpio" for
> + 83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
Why have the three different compatible settings when the code doesn't do
anything different?
> +#define MPC8XXX_GPI
t;default-state" property gains a new
allowable setting "keep".
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 16
drivers/leds/leds-gpio.c| 12
include/linux/leds
tate"
that controls this. The OpenFirmware binding uses a property named
"default-state" that can be set to "on" or "off". The default the property
isn't present is off.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentatio
ltiple LEDs
per device.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 46 -
drivers/leds/Kconfig| 21 ++-
drivers/leds/leds-gpio.c| 230 ++-
3 files change
t any
flags present from the gpio_spec.
The default (and currently only) of_gpio_chip xlate method,
of_gpio_simple_xlate(), is modified to do this.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
drivers/mtd/nand/fsl_upm.c |2 +-
drivers/net/fs_enet/fs_enet-main.c
This series of patches adds support for OpenFirmware bindings for GPIO based
LEDs.
I last posted a version of this in July but discussion of the OF binding
details didn't seem to be going anywhere.
I've since been contacted by some people who are actually using the previous
patches and have been
On Wed, 9 Jul 2008, Kumar Gala wrote:
> Moved Freescale SoC related bindings out of booting-without-of.txt and into
> their own files.
>
> Signed-off-by: Kumar Gala
> ---
>
> We need to resolve some conflicts in cpm.txt and qe.txt but that will be a
> followup patch.
>
> - k
>
> Documentation/po
st to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <[EMAIL P
On Fri, 1 Aug 2008, Jon Smirl wrote:
> I don't like the third choice. Keep a simple Linux driver for i2c and
> the platform, and then move all of the messy code into uboot. BTW,
> the messy code is about 10 lines. It's going to take more than 10
> lines to hide those 10 lines.
It's not being _mov
On Fri, 1 Aug 2008, Timur Tabi wrote:
> On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
>
> > The real problem, which kept me from making a patch to do this months ago,
> > is that the source clock that the I2C freq divider applies to is different
On Thu, 31 Jul 2008, Jon Smirl wrote:
> > Here's my idea:
> >
> > [EMAIL PROTECTED] {
> > compatible = "fsl-i2c";
> > bus-frequency = <10>;
> >
> > /* Either */
> > source-clock-frequency = <0>;
> > /* OR *
On Thu, 31 Jul 2008, Timur Tabi wrote:
> Wolfgang Grandegger wrote:
>
> > U-Boot does not (yet) use the FDT and it has therefore to use that ugly
> > code to derive the I2C input clock frequency. I think its completely
> > legal to put that hardware specific information into the FDT and get rid
> >
On Thu, 31 Jul 2008, Grant Likely wrote:
> >> I'm a bit confused. The frequency of the I2C source clock and the real I2C
> >> clock frequency are two different things. The first one is common for all
> >> I2C devices, the second can be different. What properties would you like to
> >> use for defi
On Thu, 31 Jul 2008, Grant Likely wrote:
> On Thu, Jul 31, 2008 at 09:54:48PM +0200, Wolfgang Grandegger wrote:
> > Thinking more about it, it would be best to add the property
> > "i2c-clock-divider" to the soc node and implement fsl_get_i2c_freq() in
> > a similar way:
> >
> > [EMAIL PROT
On Thu, 31 Jul 2008, Jon Smirl wrote:
> As for the source clock, how about creating a new global like
> ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
> right clock value into the variable. For mpc8 get it from uboot.
> mpc5200 can easily compute it from ppc_proc_freq and
On Thu, 31 Jul 2008, Timur Tabi wrote:
> Jon Smirl wrote:
>
> > Aren't the tables in the manual there just to make it easy for a human
> > to pick out the line they want? For a computer you'd program the
> > formula that was used to create the tables.
>
> Actually, the tables in the manuals are jus
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
>> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
>>> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
>>> [...]
>>>>>>> +- functio
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> [...]
> +- function : (optional) This parameter, if present, is a string
> + defining the function of the LED. It can be used to put the LED
> + under software control, e.g.
On Sat, 26 Jul 2008, Grant Likely wrote:
> On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote:
>> Add bindings to support LEDs defined as of_platform devices in addition to
>> the existing bindings for platform devices.
>
>> +- gpios : Should specify the LED G
st to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <[EMAIL P
On Sun, 27 Jul 2008, Stephen Rothwell wrote:
> On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <[EMAIL PROTECTED]> wrote:
>> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote:
>>> The default_trigger fields of struct gpio_led and thus struct led_classdev
&g
On Fri, 25 Jul 2008, Anton Vorontsov wrote:
>
> The name seems a bit unfortunate though, because one could read the
> function as it gets gpio flags only (though, we might implement
> this instead, but this way average driver will end up with parsing
> gpios = <> twice).
It is kind of a confusing
ltiple LEDs
per device.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 44 -
drivers/leds/Kconfig| 21 ++-
drivers/leds/leds-gpio.c| 225 ++-
3 files change
st to prevent such code from being added, to
prevent warnings if -Wwrite-strings is used and when assigned from a
constant string other than a string literal (which produces a warning under
current kernel compiler flags), and for general good coding practices.
Signed-off-by: Trent Piepho <[EMAIL P
Here are my patches for the OF bindings. The first is just a tiny change to
the leds code to silence a warning. The second is the real patch.
The leds-gpio driver gets two sub-options in Kconfig, one for platform
device support and one for openfirmware platform device support.
There is support
On Wed, 23 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 21, 2008 at 02:12:20PM -0700, Trent Piepho wrote:
>> On Mon, 21 Jul 2008, Anton Vorontsov wrote:
>>> On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
>>>> It doesn't look like you have a
On Mon, 21 Jul 2008, Anton Vorontsov wrote:
> On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
>> It doesn't look like you have any way to unset the active low flag. What if
>> I unload the leds-gpio driver (or another gpio user) and then try to use the
>>
On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> +int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
> + const void *gpio_spec)
> +{
> + if (gpio[1] & PX_GPIO_FLAG_ACTIVE_LOW)
> + px_gc->active_low |= pin2mask(*gpio);
You have a race here. What if px_
On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
>> Basically what I did then in my patch then, refactor leds-gpio so most of
>> it is shared and there is a block of code that does platform binding and
>> an
On Thu, 17 Jul 2008, Grant Likely wrote:
> Alternately, I would also be okay with a scheme where all LED nodes
> have a common parent and an of_platform driver would bind against the
> parent node; not the individual children. Then the leds-gpio driver
> could be refactored to have both platform a
On Thu, 17 Jul 2008, Anton Vorontsov wrote:
> On Wed, Jul 16, 2008 at 10:13:06PM -0700, Trent Piepho wrote:
>> Ok, how about adding code the existing leds-gpio driver so that it can
>> creates
>> LEDs from of_platform devices too?
>
> Few comments below.
>
>>
on Wed, 16 Jul 2008, Grant Likely wrote:
> On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
>> On Tue, 15 Jul 2008, Anton Vorontsov wrote:
>>> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
>>> is not much code can be shared betwee
On Tue, 15 Jul 2008, Richard Purdie wrote:
> On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
>>> Spell out openfirmware :). I initially had no idea "of == openfirmware"
>>> and I suspect others won't either...
>>
>> This would be unusually long name, that is
>>
>> $ find . -iname '*openfi
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
> Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
> is not much code can be shared between the two drivers (both are mostly
> driver bindings anyway).
Why can't this driver use the existing gpio-led driver? Basically, do
something l
On Tue, 17 Jun 2008, Scott Wood wrote:
Sam Ravnborg wrote:
In general when you select a symbol that has dependencies you are almost
always on the wrong track.
more specific options should make sure that they never select it when the
dependencies aren't met.
Sure, in theory that would work
On Wed, 4 Jun 2008, Nick Piggin wrote:
> On Wednesday 04 June 2008 07:44, Trent Piepho wrote:
>> On Tue, 3 Jun 2008, Matthew Wilcox wrote:
>
>>> I don't understand why you keep talking about DMA. Are you talking
>>> about ordering between readX() and DMA? PC
On Tue, 3 Jun 2008, Matthew Wilcox wrote:
On Tue, Jun 03, 2008 at 12:57:56PM -0700, Trent Piepho wrote:
On Tue, 3 Jun 2008, Matthew Wilcox wrote:
On Tue, Jun 03, 2008 at 11:47:00AM -0700, Trent Piepho wrote:
On Tue, 3 Jun 2008, Linus Torvalds wrote:
On Tue, 3 Jun 2008, Nick Piggin wrote
On Tue, 3 Jun 2008, Matthew Wilcox wrote:
On Tue, Jun 03, 2008 at 12:43:21PM -0700, Trent Piepho wrote:
IOW, there are four ways one can defined endianness/swapping:
1) Little-endian
2) Big-endian
3) Native-endian aka non-byte-swapping
4) Foreign-endian aka byte-swapping
1 and 2 are by far the
1 - 100 of 119 matches
Mail list logo
