* RE: 82xx performance
From: Rune Torgersen @ 2008-07-17 19:54 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <200807172143.57576.arnd@arndb.de>
Arnd Bergmann wrote:
> So again, nothing conclusive. I'm running out of ideas.
Is the syscall path different or the same on ppc and powerpc?
Any differences in the task switching, irq handling or page fault
handling?
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Trent Piepho @ 2008-07-17 20:01 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <20080717135542.GA15503@polina.dev.rtsoft.ru>
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.
>
>> I've made a patch to do this and it works ok. The code added to leds-gpio is
>> about half what was involved in Anton's new driver.
>
> This isn't true.
Your new driver was 194 lines, not counting docs or Kconfig. My patch
added about 104 lines to the existing leds-gpio driver. So yes, about half
the code.
>> There is still one of_platform device per led because of how the bindings work
>> (but that could be changed with new bindings), but there are zero extra
>> platform devices created.
>
> You didn't count extra platform driver. You can't #ifdef it. The only way
> you can avoid this is creating leds-gpio-base.c or something, and place the
> helper functions there.
I guess, in terms of compiled size, the combined platform + of_platform
driver is bigger than the of_platform only driver. Though it's much
smaller than having both the platform only and of_platform only drivers.
In terms of source code, there's less with the combined driver.
I don't see why the combined leds-gpio driver can't have an ifdef for the
platform part. All the platform driver specific code is already in one
contiguous block. In fact, I just did it and it works fine. My LEDs from
the dts were created and the LED I have as a platform device wasn't, as
expected. Here's the patch, pretty simple:
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -108,2 +108,3 @@ static int create_gpio_led(struct gpio_led *cur_led,
+#ifdef CONFIG_LEDS_GPIO_PLATFORM
static int gpio_led_probe(struct platform_device *pdev)
@@ -222,2 +223,3 @@ module_init(gpio_led_init);
module_exit(gpio_led_exit);
+#endif /* CONFIG_LEDS_GPIO_PLATFORM */
>> +static int create_gpio_led(struct gpio_led *cur_led,
>
> The create_gpio_led() interface is also quite weird, since it implies that
> we have to pass two GPIO LED "handles": struct gpio_led_data (that we
> allocated) and temporary struct gpio_led. And this helper function will
> just assign things from one struct to another, and then will register the
> led.
It creates a "thing" from a template passed a pointer to a struct. This is
very common, there must be hundreds of functions in the kernel that work
this way. The difference is instead of allocating and returning the
created thing, you pass it a blank pre-allocated thing to fill in and
register. I know there is other code that works this way too. It's
usually used, like it is here, so you can allocate a bunch of things at
once and then register them one at a time.
> With OF driver I don't need "struct gpio_led". Only the platform driver
> need this so platforms could pass gpio led info through it, while with OF
> we're getting all information from the device tree.
The struct gpio_led is just used to pass the stats to the led creation
function. It doesn't stick around. You could use local variables for the
gpio and name and pass them to the create led function. Bundling them into
a struct is an tiny change that lets more code be shared.
>> +/* #ifdef CONFIG_LEDS_GPIO_OF */
>
> Heh.
Obviously the OF binding code should be conditional, selectable from
kconfig if the platform has OF support. It's all in one contiguous block
and that shows where the ifdef would go. I didn't think it was necessary
to include the obvious kconfig patch.
^ permalink raw reply
* Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
From: Benjamin Herrenschmidt @ 2008-07-17 20:06 UTC (permalink / raw)
To: mohan; +Cc: ppcdev, paulus, miltonm
In-Reply-To: <20080717184055.GB25070@in.ibm.com>
On Fri, 2008-07-18 at 00:10 +0530, Mohan Kumar M wrote:
> Extract list of relocation offsets
>
> Extract list of offsets in the vmlinux file for which the relocation
> delta has to be patched. Currently only following type of relocation
> types are considered: R_PPC64_ADDR16_HI, R_PPC64_TOC and R_PPC64_ADDR64
>
> The offsets are sorted according to the relocation type and this
> information is appended to the normal vmlinux file by using the patch
> relocation_build.patch
Please, provide an indication of what changed since the previous
version of the patch to make the reviewer's life easier !
Thanks,
Ben.
^ permalink raw reply
* Re: increase lowmem value for ppc
From: Siva Prasad @ 2008-07-17 20:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.2286.1216296226.2883.linuxppc-embedded@ozlabs.org>
Marco Stornelli wrote:
> Upgrading to a 2.6.x kernel may solve the problem, but it needs a lot
of=20
> effort. Does 2.6.x kernel support 2G physical memory?
>=20
It's the same. Some architecture have 36-bit addressing, but I don't=20
know if the latest kernel has the support for this feature for powerpc.
>=20
I think recently there were some patches with 2.6.26-rcx to support
36-bit addressing and changed the addressing to phys_addr_t type from
unsigned long, and few other changed. I think this should be available
starting 2.6.26 version.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Benjamin Herrenschmidt @ 2008-07-17 20:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Roland Dreier, Peter Altevogt, cbe-oss-dev,
Hans Boettiger
In-Reply-To: <200807171653.29946.arnd@arndb.de>
On Thu, 2008-07-17 at 16:53 +0200, Arnd Bergmann wrote:
>
> Peter and Hans were involved in the discussion that led to the
> decision
> to change step 3 from per-transfer default to always weak ordering.
> I think they verified that this is safe for all the peripherals that
> we
> have on the QS21 and QS22 blades (tg3, ehci, mthca, mptsas), but that
> doesn't mean that it is safe in general, so I guess you are right that
> we should not make it the default in the kernel for Cell systems.
> Hans, can you confirm this?
I'm surprised with tg3. We need to make sure that updates to the
hw status block are properly ordered vs writes to the ring, among
other things.
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Benjamin Herrenschmidt @ 2008-07-17 20:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Roland Dreier, Peter Altevogt, cbe-oss-dev,
Hans Boettiger
In-Reply-To: <200807171653.29946.arnd@arndb.de>
> Ok, this makes sense. I've followed the bit down in the specification,
> and now it seems like we can't just set relaxed ordering in the IOMMU
> but should use the value that comes from the PCIe device.
>
> The flow of the order bit in this machine is as follows:
>
> 1. The device can select relaxed (weak) or non-relaxed (strong) ordering
> for a DMA transfer. PCI-X is always strong, DMAx can be configured globally,
> and PCIe is device specific.
> 2. The PCIe root complex can override the order bit and force it to strong
> ordering (which we don't).
> 3. The PLB5-to-C3PO bridge can override the bit and force it to weak or
> strong or leave it alone (we force it to weak).
> 4. The IOMMU can force the bit to weak on a per-page base (we don't without
> the patch, but do with the patch).
>
> Peter and Hans were involved in the discussion that led to the decision
> to change step 3 from per-transfer default to always weak ordering.
> I think they verified that this is safe for all the peripherals that we
> have on the QS21 and QS22 blades (tg3, ehci, mthca, mptsas), but that
> doesn't mean that it is safe in general, so I guess you are right that
> we should not make it the default in the kernel for Cell systems.
> Hans, can you confirm this?
In the meantime, send a patch that defaults to strong with explicit
weak, we can easily fixup after that.
Ben.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Siva Prasad @ 2008-07-17 20:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.2280.1216290829.2883.linuxppc-embedded@ozlabs.org>
Misbah,
May be I am missing some thing. I am sure you looked at the obvious.
Is there any reason why you are not using blocked read in application
pthread (a separate thread if necessary), so that driver provides that
value back to the application. Isn't that the right way to implement?
- Siva
Misbah khan <misbah_khan@engineer.com> wrote:
In have a sdram of size 9MB which i would map to kernel space (ioremap
would
do that ) the whole 9 MB kernel virtual memory i need to map to the
application , the application would read when driver has complited
writing
and vice versa this implimentation would be in a circular buffer type.
The
size of my RAM is 128 MB=20
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Trent Piepho @ 2008-07-17 20:18 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <fa686aa40807171105m22dda41dqb334dd5f7b2634d8@mail.gmail.com>
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 and of_platform bus
> bindings.
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
another block that does of_platform binding.
I didn't change the OF platform binding syntax so as not to complicate the
example, but that's easy to do. Something like:
leds {
compatible = "gpio-led";
gpios = <&mpc8572 6 0
&mpc8572 7 0>;
labels = "red", "green";
};
Or like this, which needs a little more code to parse:
leds {
compatible = "gpio-led";
led@6 {
gpios = <&mpc8572 6 0>;
label = "red";
};
led@7 {
gpios = <&mpc8572 7 0>;
label = "green";
};
};
I like the first better. It follows the example from the docs about how
devices with multiple gpios should work too.
^ permalink raw reply
* RE: linux boot sequence
From: Siva Prasad @ 2008-07-17 20:21 UTC (permalink / raw)
To: Rami WEHBI; +Cc: linuxppc-embedded
In-Reply-To: <D3C541E264C021479BFB60B3B790C0FB49742D@etoilenoire.STARWARS.local>
Rami,
I am copy pasting a portion of my dts file. Here I am mentioning 2GB of =
memory. However, U-Boot can update this automatically, as u-boot is OF =
aware.
memory {
device_type =3D "memory";
reg =3D <00000000 80000000>;
};
What is the boot loader you are using?
With the latest kernels you should be on arch/powerpc, not arch/ppc. I =
am not sure about the support for your PPC405 in powerpc.
- Siva
-----Original Message-----
From: Rami WEHBI [mailto:rwehbi@wirecom-tech.com]=20
Sent: Thursday, July 17, 2008 5:42 AM
To: Siva Prasad
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: linux boot sequence
Hello Siva,
I am using the 2.6.23 kernel and the target is the ppc405.=20
Using the booting-without-of.txt, and in searching in the kernel code I =
found that the devices_info are passed as parameters (memory size is the =
parameter I am searching for) by calling the function =
"find_bootinfo(void)" in /arch/ppc/kernel/setup.c
This function initializes send the pointer to linux on the device info =
as following (line 345):
Rec =3D (struct bi_record *) =
_ALIGN((ulong)__bss_start+(1<<20)-1,(1<<20));
What is this address stand for ???=20
Rami,
-----Message d'origine-----
De : linuxppc-embedded-bounces+rami.wehbi=3Dwirecom-tech.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+rami.wehbi=3Dwirecom-tech.com@ozlabs.or=
g] De la part de Siva Prasad
Envoy=E9 : mercredi 16 juillet 2008 20:46
=C0 : Rami WEHBI
Cc : linuxppc-embedded@ozlabs.org
Objet : RE: linux boot sequence
Rami,
Please make sure to copy the list as well.
OF - Open firmware. I am not sure which version of Linux kernel you are =
using, and which boot loader. Lately it is all OF based, however it is =
supported in the form of device tree blob/structure. For more =
information read booting-without-of.txt in Documentation/powerpc.
U-Boot updates the detected memory in the dtb you loaded, so that when =
kernel reads it, correct information is provided.
There is no auto-detect option in kernel. You need to write your own =
code at the exact location it needs to identify the size of memory. =
Typically this is passed to the kernel either through DTB or kernel =
arguments.
Good Luck.
- Siva
-----Original Message-----
From: Rami WEHBI [mailto:rwehbi@wirecom-tech.com]
Sent: Monday, July 14, 2008 11:47 PM
To: Siva Prasad
Subject: RE: linux boot sequence
what is the OF dtb ??? And how does the bootloader update it ???
How can I do to set the autodetect option in the kernel ???
Best Regards,
Rami,
-----Message d'origine-----
De : Siva Prasad [mailto:sprasad@bivio.net]=20
Envoy=E9 : vendredi 11 juillet 2008 23:01
=C0 : Rami WEHBI
Cc : linuxppc-embedded@ozlabs.org
Objet : linux boot sequence
Well!... You can pass the size as part of the OF memory=3D<>.
Typically your boot loader should detect the amount of memory on the =
system and update the OF dtb to reflect the available memory.
You may also tweak the kernel yourself to autodetect, instead of reading =
from the OF. How ever, I would recommend the previous approach.
- Siva
Date: Fri, 11 Jul 2008 08:34:54 +0200
From: "Rami WEHBI" <rwehbi@wirecom-tech.com>
Subject: linux boot sequence
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
=09
<D3C541E264C021479BFB60B3B790C0FB497014@etoilenoire.STARWARS.local>
Content-Type: text/plain; charset=3D"iso-8859-1"
Hi all,
=20
I am using the ppc405 and I would like to know, how does linux on =
this architect detect the available memory size in details !!!
is it a parameter passed to linux at startup by the boot loader =
??
is it an automatic detection ?? what are the steps to accomplish =
this job then ???
=20
Best regards to all,
=20
Rami
=20
Rami WEHBI =09
Recherche & D?veloppement =09
T?l : +33 2 36 56 86 00=09
Fax : +33 2 36 56 86 01=09
www.wirecom-tech.com=09
<http://www.wirecom-tech.com> =09
WIRECOM Technologies
135, Rue Jacques Charles
45166 Olivet
=09
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Benjamin Herrenschmidt @ 2008-07-17 20:14 UTC (permalink / raw)
To: Chirag Jog
Cc: linux-rt-users, Josh Triplett, Steven Rostedt, linuxppc-dev,
Nivedita Singhvi, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <20080717125645.GN20277@linux.vnet.ibm.com>
> All these operations are done assuming that tlb_gather_mmu disables
> preemption and tlb_finish_mmu enables preemption again.
> This is not true for -rt.
> For x86, none of the code paths between tlb_gather_mmu and
> tlb_finish_mmu access any per_cpu variables.
> But this is not true for powerpc64 as we can see.
>
> One way could be to make tlb_gather_mmu disable preemption as it does
> in mainline but only for powerpc.
> Although i am not sure, if this is the right step ahead.
>
> I am attaching a patch below for the same.
> I have left out the tce bits, as they are fine.
>
> Note: I haven't extensively tested the patch
A better option is to make sure that a context switch does the right
thing, flushing the pending batch. I think that's already the case,
which means that your original patch may work, but that needs to
be double-checked and commented properly.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: indicate oprofile counters to use while in compat mode
From: Torez Smith @ 2008-07-17 20:42 UTC (permalink / raw)
To: paulus, linuxppc-dev
Description:
While running on a system with new hardware and a kernel where the
cpu_specs[] table does not recognize the new hardware, the identify_cpu()
routine will select the default case as it searches through cpu_specs[]
in an attempt to match the real PVR. Once the default case is selected,
non of the oprofile counters and/or fields have been set up or defined.
When identify_cpu() is called once more with the logical PVR, some of
the cpu specific fields are replaced with the exception of the oprofile
related ones. However, in the case where we have actually taken the
default case while searching for the real PVR, we need to tell
oprofile that we are now running in compatibility mode so it can pick up
the correct counters. We do this by setting the oprofile_cpu_type field
to be that taken from the cpu_specs[] for the cpu we are now emulating.
This change will detect that we are now altering the real PVR and determine
if we also need to update the oprofile_cpu_type field.
Testing:
Tested on Power 5++ in compatibility mode by editing out the pvr_value for
Power5++ inside cpu_specs[] so the kernel did not match the first time
through, and, was forced to take the default case. Verified fields for
"the_cpu_spec" were set up as expected.
Signed-off-by: Torez Smith lnxtorez@linux.vnet.ibm.com
Patch:
+++++++++++++++++++++
diff -uprN -X powerpc.orig/Documentation/dontdiff powerpc.orig/arch/powerpc/kernel/cputable.c powerpc/arch/powerpc/kernel/cputable.c
--- powerpc.orig/arch/powerpc/kernel/cputable.c 2008-07-15 18:19:19.000000000 -0500
+++ powerpc/arch/powerpc/kernel/cputable.c 2008-07-16 11:46:09.000000000 -0500
@@ -355,6 +355,7 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power5+",
.platform = "power5+",
},
{ /* Power6 */
@@ -386,6 +387,7 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power6",
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -397,6 +399,7 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
+ .oprofile_cpu_type = "ppc64/compat-power7",
.platform = "power7",
},
{ /* Power7 */
@@ -1629,6 +1632,23 @@ struct cpu_spec * __init identify_cpu(un
t->cpu_setup = s->cpu_setup;
t->cpu_restore = s->cpu_restore;
t->platform = s->platform;
+ /*
+ * If we have passed through this logic once
+ * before and have pulled the default case
+ * because the real PVR was not found inside
+ * cpu_specs[], then we are possibly running in
+ * compatibility mode. In that case, let the
+ * oprofiler know which set of compatibility
+ * counters to pull from by making sure the
+ * oprofile_cpu_type string is set to that of
+ * compatibility mode. If the oprofile_cpu_type
+ * already has a value, then we are possibly
+ * overriding a real PVR with a logical one, and,
+ * in that case, keep the current value for
+ * oprofile_cpu_type.
+ */
+ if (t->oprofile_cpu_type == NULL)
+ t->oprofile_cpu_type = s->oprofile_cpu_type;
} else
*t = *s;
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Grant Likely @ 2008-07-17 20:49 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807171302190.27902@t2.domain.actdsltmp>
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> 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 and of_platform bus
> > bindings.
>
> 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
> another block that does of_platform binding.
Yes
> I didn't change the OF platform binding syntax so as not to complicate the
> example, but that's easy to do. Something like:
>
> leds {
> compatible = "gpio-led";
> gpios = <&mpc8572 6 0
> &mpc8572 7 0>;
> labels = "red", "green";
> };
>
> Or like this, which needs a little more code to parse:
>
> leds {
> compatible = "gpio-led";
> led@6 {
> gpios = <&mpc8572 6 0>;
> label = "red";
> };
> led@7 {
> gpios = <&mpc8572 7 0>;
> label = "green";
> };
> };
I kind of like the second option better, because there is less chance
of doing bad stuff if the gpio specifier was buggered up; but I'm cool
with either.
However, if the second option is chosen then something like the following
might be better as it eliminates the meaningless @<number> specifier.
leds {
compatible = "gpio-led";
red {
gpios = <&mpc8572 6 0>;
};
green {
gpios = <&mpc8572 7 0>;
};
};
Cheers,
g.
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Nate Case @ 2008-07-17 21:29 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Richard Purdie, linux-kernel, Stephen Rothwell
In-Reply-To: <20080715151917.GA30607@polina.dev.rtsoft.ru>
On Tue, 2008-07-15 at 19:19 +0400, Anton Vorontsov wrote:
> + led->cdev.name = of_get_property(np, "label", NULL);
> + if (!led->cdev.name)
> + led->cdev.name = dev_name(&ofdev->dev);
How about also supporting a "trigger" property which would set
cdev.default_trigger in the same manner? It would be useful for boards
to be able to specify this in the device tree (e.g., if a certain LED is
meant to be used as a "heartbeat").
--
Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* Re: 82xx performance
From: Arnd Bergmann @ 2008-07-17 21:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04B34E18@ismail.innsys.innovsys.com>
On Thursday 17 July 2008, Rune Torgersen wrote:
> Arnd Bergmann wrote:
> > So again, nothing conclusive. I'm running out of ideas.
>
> Is the syscall path different or the same on ppc and powerpc?
> Any differences in the task switching, irq handling or page fault
> handling?
>
It's all different in suble ways, but those changes should only
show up in the system time accounting, not user time accounting.
One change that I would expect to show up in user space performance
is different TLB management, in a way that causes increased flushing
and reloading of page table entries. I don't have the slightest
idea if or in what ways that has changed. Maybe Ben has a clue
about this.
Arnd <><
^ permalink raw reply
* [PATCH]: Freescale UCC_GETH Half Duplex
From: Russell McGuire @ 2008-07-17 22:01 UTC (permalink / raw)
To: 'Kim Phillips'; +Cc: chuck, linuxppc-embedded
In-Reply-To: <20080717120155.efdef031.kim.phillips@freescale.com>
All,
This fix is for UCC_GETH, in the manual only TWO modes allow half duplex
setting, and this is for MII and RMII. All other modes are disallowed
because it is not supported in the Freescale MAC interface, and will throw
the QE engines into unknown states.
For all other modes other than MII and RMII, this doesn't mean that half
duplex doesn't work, it just means the bit can't be set, apparently <though
unclear in the manual>?, in Gigabit modes, like RGMII and GMII the MAC will
auto-detect if half duplex is in effect. Hence why we leave it set to dull
duplex.
Signed-off-by: Russell McGuire <rmcguire@videopresence.com>
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9a38dfe..5900847 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1533,10 +1698,17 @@ static void adjust_link(struct net_device *dev)
* If not, we operate in half-duplex mode. */
if (phydev->duplex != ugeth->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FDX);
- else
- tempval |= MACCFG2_FDX;
+ /* Can only set half duplex for these two modes!! */
+ if ((ugeth->phy_interface == PHY_INTERFACE_MODE_MII)
||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RMII))
{
+ if (!(phydev->duplex))
+ tempval &= ~(MACCFG2_FDX);
+ else
+ tempval |= MACCFG2_FDX;
+ } else {
+ /* Always set for other modes */
+ tempval |= MACCFG2_FDX;
+ }
ugeth->oldduplex = phydev->duplex;
}
^ permalink raw reply related
* [PATCH v3] elf loader support for auxvec base platform string
From: Nathan Lynch @ 2008-07-17 22:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, linux-kernel, roland, linuxppc-dev
In-Reply-To: <20080717000951.5f8cab37.akpm@linux-foundation.org>
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Added comment explaining ELF_BASE_PLATFORM.
fs/binfmt_elf.c | 28 ++++++++++++++++++++++++++++
include/linux/auxvec.h | 5 ++++-
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d48ff5f..d8a7cc0 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,15 @@ static int padzero(unsigned long elf_bss)
#define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
#endif
+#ifndef ELF_BASE_PLATFORM
+/*
+ * AT_BASE_PLATFORM indicates the "real" hardware/microarchitecture.
+ * If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
+ * will be copied to the user stack in the same manner as AT_PLATFORM.
+ */
+#define ELF_BASE_PLATFORM NULL
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -142,7 +151,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
elf_addr_t __user *envp;
elf_addr_t __user *sp;
elf_addr_t __user *u_platform;
+ elf_addr_t __user *u_base_platform;
const char *k_platform = ELF_PLATFORM;
+ const char *k_base_platform = ELF_BASE_PLATFORM;
int items;
elf_addr_t *elf_info;
int ei_index = 0;
@@ -172,6 +183,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
return -EFAULT;
}
+ /*
+ * If this architecture has a "base" platform capability
+ * string, copy it to userspace.
+ */
+ u_base_platform = NULL;
+ if (k_base_platform) {
+ size_t len = strlen(k_base_platform) + 1;
+
+ u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
+ if (__copy_to_user(u_base_platform, k_base_platform, len))
+ return -EFAULT;
+ }
+
/* Create the ELF interpreter info */
elf_info = (elf_addr_t *)current->mm->saved_auxv;
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
@@ -208,6 +232,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
}
+ if (k_base_platform) {
+ NEW_AUX_ENT(AT_BASE_PLATFORM,
+ (elf_addr_t)(unsigned long)u_base_platform);
+ }
if (bprm->interp_flags & BINPRM_FLAGS_EXECFD) {
NEW_AUX_ENT(AT_EXECFD, bprm->interp_data);
}
diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
index ad89545..1adc61d 100644
--- a/include/linux/auxvec.h
+++ b/include/linux/auxvec.h
@@ -26,8 +26,11 @@
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_BASE_PLATFORM 38 /* string identifying real platform, may
+ * differ from AT_PLATFORM. */
+
#ifdef __KERNEL__
-#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table */
+#define AT_VECTOR_SIZE_BASE (14 + 3) /* NEW_AUX_ENT entries in auxiliary table */
#endif
#endif /* _LINUX_AUXVEC_H */
--
1.5.6.2
^ permalink raw reply related
* Re: [patch 2.6.26-rc3] spi: make spi_board_info.modalias a char array
From: Grant Likely @ 2008-07-17 22:33 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <200805231031.25919.david-b@pacbell.net>
David, are you going to pick up this and the other SPI of support
patches (linked below)? Or should I push them through my tree? (I'm
assuming that all the comments are addressed and they are ready to be
merged).
http://patchwork.ozlabs.org/linuxppc/patch?id=19597
http://patchwork.ozlabs.org/linuxppc/patch?id=19601
http://patchwork.ozlabs.org/linuxppc/patch?id=19602
Thanks,
g.
On Fri, May 23, 2008 at 11:31 AM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 21 May 2008, Andrew Morton wrote:
>> On Wed, 21 May 2008 17:04:56 -0700 David Brownell <david-b@pacbell.net> wrote:
>>
>> > From: Grant Likely <grant.likely@secretlab.ca>
>> > ...
>> > - proxy->modalias = chip->modalias;
>> > + strncpy(proxy->modalias, chip->modalias, KOBJ_NAME_LEN);
>> > ...
>>
>> a) strncpy() doesn't null-terminate the dest if it overran. strlcpy() does.
>>
>> b) Given the uncertainly over the state of existing code, perhaps we
>> should have an explicit check for overflows here, with a WARN_ON()?
>>
>> c) I think it's better to use sizeof() in the strlcpy() rather than
>> duplicating the array size - it's a little more robust in the face
>> of future changes and it is more obviously-correct (don't need to go
>> elsewhere to check the size of the destination).
>
> Good points. I usually try to use sizeof() myself, for exactly
> that reason. Updated version (below) uses strlcpy, sizeof, WARN_ON.
>
>
>> d) KOBJ_NAME_LEN no longer exists in linux-next. I'm not sure where
>> it went - Greg and Kay have been up to their usual tricks.
>
> Yeech. Replacing symbols with inline constants isn't good when
> the constant is what ensures various fields are the same size.
>
> BTW -- four comments on one line is pretty good even for you. ;)
>
> - Dave
>
>
> ========= CUT HERE
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Currently, 'modalias' in the spi_device structure is a 'const char *'.
> The spi_new_device() function fills in the modalias value from a passed
> in spi_board_info data block. Since it is a pointer copy, the new
> spi_device remains dependent on the spi_board_info structure after the
> new spi_device is registered (no other fields in spi_device directly
> depend on the spi_board_info structure; all of the other data is copied).
>
> This causes a problem when dynamically propulating the list of attached
> SPI devices. For example, in arch/powerpc, the list of SPI devices can
> be populated from data in the device tree. With the current code, the
> device tree adapter must kmalloc() a new spi_board_info structure for
> each new SPI device it finds in the device tree, and there is no simple
> mechanism in place for keeping track of these allocations.
>
> This patch changes modalias from a 'const char *' to a fixed char array.
> By copying the modalias string instead of referencing it, the dependency
> on the spi_board_info structure is eliminated and an outside caller does
> not need to maintain a separate spi_board_info allocation for each device.
>
> If searched through the code to the best of my ability for any references
> to modalias which may be affected by this change and haven't found anything.
> It has been tested with the lite5200b platform in arch/powerpc.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> [ cope with linux-next changes: KOBJ_NAME_LEN obliterated, etc ]
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> drivers/spi/spi.c | 4 +++-
> include/linux/spi/spi.h | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> --- a/drivers/spi/spi.c 2008-05-22 10:57:21.000000000 -0700
> +++ b/drivers/spi/spi.c 2008-05-22 18:56:16.000000000 -0700
> @@ -218,6 +218,8 @@ struct spi_device *spi_new_device(struct
> if (!spi_master_get(master))
> return NULL;
>
> + WARN_ON(strlen(chip->modalias) >= sizeof(proxy->modalias));
> +
> proxy = kzalloc(sizeof *proxy, GFP_KERNEL);
> if (!proxy) {
> dev_err(dev, "can't alloc dev for cs%d\n",
> @@ -229,7 +231,7 @@ struct spi_device *spi_new_device(struct
> proxy->max_speed_hz = chip->max_speed_hz;
> proxy->mode = chip->mode;
> proxy->irq = chip->irq;
> - proxy->modalias = chip->modalias;
> + strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
>
> snprintf(proxy->dev.bus_id, sizeof proxy->dev.bus_id,
> "%s.%u", master->dev.bus_id,
> --- a/include/linux/spi/spi.h 2008-05-22 10:57:21.000000000 -0700
> +++ b/include/linux/spi/spi.h 2008-05-23 10:21:41.000000000 -0700
> @@ -82,7 +82,7 @@ struct spi_device {
> int irq;
> void *controller_state;
> void *controller_data;
> - const char *modalias;
> + char modalias[32];
>
> /*
> * likely need more hooks for more protocol options affecting how
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: Andrew Morton @ 2008-07-17 22:42 UTC (permalink / raw)
To: Nathan Lynch; +Cc: John Reiser, linux-kernel, linuxppc-dev, torvalds, roland
In-Reply-To: <20080717221932.GL9594@localdomain>
On Thu, 17 Jul 2008 17:19:32 -0500
Nathan Lynch <ntl@pobox.com> wrote:
> Some IBM POWER-based platforms have the ability to run in a
> mode which mostly appears to the OS as a different processor from the
> actual hardware. For example, a Power6 system may appear to be a
> Power5+, which makes the AT_PLATFORM value "power5+". This means that
> programs are restricted to the ISA supported by Power5+;
> Power6-specific instructions are treated as illegal.
>
> However, some applications (virtual machines, optimized libraries) can
> benefit from knowledge of the underlying CPU model. A new aux vector
> entry, AT_BASE_PLATFORM, will denote the actual hardware. For
> example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
> will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
> that AT_PLATFORM indicates the instruction set supported, while
> AT_BASE_PLATFORM indicates the underlying microarchitecture.
>
> If the architecture has defined ELF_BASE_PLATFORM, copy that value to
> the user stack in the same manner as ELF_PLATFORM.
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> ---
>
> Added comment explaining ELF_BASE_PLATFORM.
>
> fs/binfmt_elf.c | 28 ++++++++++++++++++++++++++++
> include/linux/auxvec.h | 5 ++++-
> 2 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index d48ff5f..d8a7cc0 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -131,6 +131,15 @@ static int padzero(unsigned long elf_bss)
> #define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
> #endif
>
> +#ifndef ELF_BASE_PLATFORM
> +/*
> + * AT_BASE_PLATFORM indicates the "real" hardware/microarchitecture.
> + * If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
> + * will be copied to the user stack in the same manner as AT_PLATFORM.
> + */
> +#define ELF_BASE_PLATFORM NULL
> +#endif
> +
> static int
> create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> unsigned long load_addr, unsigned long interp_load_addr)
> @@ -142,7 +151,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> elf_addr_t __user *envp;
> elf_addr_t __user *sp;
> elf_addr_t __user *u_platform;
> + elf_addr_t __user *u_base_platform;
> const char *k_platform = ELF_PLATFORM;
> + const char *k_base_platform = ELF_BASE_PLATFORM;
> int items;
> elf_addr_t *elf_info;
> int ei_index = 0;
> @@ -172,6 +183,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> return -EFAULT;
> }
>
> + /*
> + * If this architecture has a "base" platform capability
> + * string, copy it to userspace.
> + */
> + u_base_platform = NULL;
> + if (k_base_platform) {
> + size_t len = strlen(k_base_platform) + 1;
> +
> + u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
> + if (__copy_to_user(u_base_platform, k_base_platform, len))
> + return -EFAULT;
> + }
> +
> /* Create the ELF interpreter info */
> elf_info = (elf_addr_t *)current->mm->saved_auxv;
> /* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
> @@ -208,6 +232,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> NEW_AUX_ENT(AT_PLATFORM,
> (elf_addr_t)(unsigned long)u_platform);
> }
> + if (k_base_platform) {
> + NEW_AUX_ENT(AT_BASE_PLATFORM,
> + (elf_addr_t)(unsigned long)u_base_platform);
> + }
> if (bprm->interp_flags & BINPRM_FLAGS_EXECFD) {
> NEW_AUX_ENT(AT_EXECFD, bprm->interp_data);
> }
> diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
> index ad89545..1adc61d 100644
> --- a/include/linux/auxvec.h
> +++ b/include/linux/auxvec.h
> @@ -26,8 +26,11 @@
>
> #define AT_SECURE 23 /* secure mode boolean */
>
> +#define AT_BASE_PLATFORM 38 /* string identifying real platform, may
> + * differ from AT_PLATFORM. */
> +
> #ifdef __KERNEL__
> -#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table */
> +#define AT_VECTOR_SIZE_BASE (14 + 3) /* NEW_AUX_ENT entries in auxiliary table */
> #endif
>
> #endif /* _LINUX_AUXVEC_H */
OK.
But it conflicts directly with the already-queued
execve-filename-document-and-export-via-auxiliary-vector.patch (which
various potential reviewers blithely deleted - don't come complaining
to me!):
From: John Reiser <jreiser@BitWagon.com>
The Linux kernel puts the filename argument of execve() into the
new address space. Many developers are surprised to learn this.
Those who know and could use it, object "But it's not documented."
Those who want to use it dislike the expression
(char *)(1+ strlen(env[-1+ n_env]) + env[-1+ n_env])
because it requires locating the last original environment variable,
and assumes that the filename follows the characters.
This patch documents the insertion of the filename, and makes it easier to
find by adding a new tag AT_EXECFN in the ElfXX_auxv_t; see <elf.h>.
In many cases readlink("/proc/self/exe",) gives the same answer. But if all
the original pages get unmapped, then the kernel erases the symlink for
/proc/self/exe. This can happen when a program decompressor does a good job
of cleaning up after uncompressing directly to memory, so that the address
space of the target program looks the same as if compression had never
happened. One example is http://upx.sourceforge.net .
One notable use of the underlying concept (what path containED the executable)
is glibc expanding $ORIGIN in DT_RUNPATH. In practice for the near term, it
may be a good idea for user-mode code to use both /proc/self/exe and AT_EXECFN
as fall-back methods for each other. /proc/self/exe can fail due to
unmapping, AT_EXECFN can fail because it won't be present on non-new systems.
The auxvec or {AT_EXECFN}.d_val also can get overwritten, although in nearly
all cases this would be the result of a bug.
The runtime cost is one NEW_AUX_ENT using two words of stack space. The
underlying value is maintained already as bprm->exec; setup_arg_pages() in
fs/exec.c slides it for stack_shift, etc.
Signed-off-by: John Reiser <jreiser@BitWagon.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/binfmt_elf.c | 1 +
include/linux/auxvec.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff -puN fs/binfmt_elf.c~execve-filename-document-and-export-via-auxiliary-vector fs/binfmt_elf.c
--- a/fs/binfmt_elf.c~execve-filename-document-and-export-via-auxiliary-vector
+++ a/fs/binfmt_elf.c
@@ -204,6 +204,7 @@ create_elf_tables(struct linux_binprm *b
NEW_AUX_ENT(AT_GID, tsk->gid);
NEW_AUX_ENT(AT_EGID, tsk->egid);
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
+ NEW_AUX_ENT(AT_EXECFN, bprm->exec);
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
diff -puN include/linux/auxvec.h~execve-filename-document-and-export-via-auxiliary-vector include/linux/auxvec.h
--- a/include/linux/auxvec.h~execve-filename-document-and-export-via-auxiliary-vector
+++ a/include/linux/auxvec.h
@@ -26,8 +26,10 @@
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_EXECFN 31 /* filename of program */
#ifdef __KERNEL__
-#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table */
+#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
+ /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */
#endif
#endif /* _LINUX_AUXVEC_H */
_
^ permalink raw reply
* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-17 23:31 UTC (permalink / raw)
To: Liam Girdwood, linuxppc-dev, alsa-devel, timur
In-Reply-To: <20080712173609.GA6523@sirena.org.uk>
On Sat, Jul 12, 2008 at 06:36:10PM +0100, Mark Brown wrote:
> On Sat, Jul 12, 2008 at 12:00:18AM -0600, Grant Likely wrote:
> It wouldn't be the only driver not to implement PLL configuration in
> this way so that's probably be OK for an initial merge. What's expected
> for PLL configuration is that you implement the DAI set_pll() operation
> in the codec driver, allowing machine drivers to configure the PLL when
> they wish.
okay
> The power configuration should be fixed, though. Normally drivers
> either fully implement DAPM (including set_bias_level()) or power
> everything in the codec up when the driver is loaded. At the minute
> what the driver is doing appears to be powering the codec up in both
> _hw_params() and _probe() but never powering anything down - if that is
> the case then probably all you need to do is remove the extra power up
> from hw_params(), giving you the simple option.
done
> > Hmmm, I haven't been able to find this; either in the code or on a live
> > running system. Where is the common reg dump implemented.
>
> /sys/bus/platform/devices/soc-audio/codec_reg
Yikes. The AIC26 has registers all over the place and most of them are
empty. The codec_reg attribute handling means I need to maintain a
cache of the entire register file; not just the part that is actually
used. Oh well; I can work around it.
Thanks,
g.
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-17 23:42 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807171302190.27902@t2.domain.actdsltmp>
On Thu, Jul 17, 2008 at 01:18:18PM -0700, Trent Piepho wrote:
> 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 and of_platform bus
> > bindings.
>
> 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
> another block that does of_platform binding.
Ok. I must admit I'm quite burned out with OF gpio-leds. I was posting the
bindings since April, probably four or five times. Last time a week ago,
IIRC.
During the months I received just a few replies, one from Grant ("Looks
good to me."), few from Segher (with a lot of criticism, that I much
appreciated and tried to fix all spotted issues), and one from Laurent
(about active-low LEDs).
Of course, I know we're all busy etc and we don't always read or reply to
RFCs, so don't get me wrong, I'm not blaming or something. It just would be
great if all these ideas would be spoken up a bit earlier, i.e. not in the
middle of the merge window... But yes, we have what we have.
And the true thing is that I tend to agree with all your comments, and I
strongly believe that the issues you pointed out should be fixed prior to
merging. But I'm tired of these leds, they aren't _that_ interesting,
btw. ;-)
So..
Trent, I encourage you to collect your patch snippets into complete patch,
and post it so it could slip into 2.6.27 (the bad thing is that your
approach involves changes to the existing drivers, not just adding new
driver that could slip even into -rc9).
That is, I have a bunch of patches in my stg queue on which I can work
with more fun, so I'm somewhat glad that somebody will take care of the
notorious OF GPIO LEDs. ;-)
For what it's worth:
> I didn't change the OF platform binding syntax so as not to complicate the
> example, but that's easy to do. Something like:
>
> leds {
> compatible = "gpio-led";
> gpios = <&mpc8572 6 0
> &mpc8572 7 0>;
> labels = "red", "green";
> };
>
I don't like this.
> Or like this, which needs a little more code to parse:
>
> leds {
> compatible = "gpio-led";
> led@6 {
> gpios = <&mpc8572 6 0>;
> label = "red";
> };
> led@7 {
> gpios = <&mpc8572 7 0>;
> label = "green";
> };
> };
I like this. Or better what Grant suggested, i.e. move label to node
name.
> I like the first better. It follows the example from the docs about how
> devices with multiple gpios should work too.
IMO, each LED is a device. So, I would rather define compatible = <> for
each led.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: John Reiser @ 2008-07-17 23:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev, Nathan Lynch, torvalds, roland
In-Reply-To: <20080717154218.8981035c.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Thu, 17 Jul 2008 17:19:32 -0500
> Nathan Lynch <ntl@pobox.com> wrote:
>
>
>> [snip]
>> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
[snip]
> OK.
>
> But it conflicts directly with the already-queued
> execve-filename-document-and-export-via-auxiliary-vector.patch
[snip]
It seems to me that most of the patch conflicts are mechanical
and could be merged mechanically.
However I believe that the documentation change to this comment is important:
-----
> #ifdef __KERNEL__
> -#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table */
> +#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
> + /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */
> #endif
-----
I scratched my head for a while to figure out that AT_NOTELF also was
a subtraction as far as AT_VECTOR_SIZE_BASE was concerned.
--
John Reiser, jreiser@BitWagon.com
^ permalink raw reply
* Re: [2.6 patch] powerpc/boot/Makefile: change spaces to tabs
From: David Gibson @ 2008-07-18 1:47 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20080717181854.GB18326@cs181140183.pp.htv.fi>
On Thu, Jul 17, 2008 at 09:18:54PM +0300, Adrian Bunk wrote:
> For C code spaces versus tabs is just a religious issue,
> but for Makefiles it actually matters.
>
> This patch fixes he following errors:
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:166: *** missing separator. Stop.
> /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/Makefile:171: *** missing separator. Stop.
>
> Since this was inside an ifdef DTC_GENPARSER it was not a problem unless
> someone wanted to regenerate the shipped generated files.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Oops, embarrasing mistake there.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* hang on "booting the kernel ...."
From: wsz_422 @ 2008-07-18 2:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
Hello!
When I boot the kerenl which was compiled by myself on the ML403,but it hang on "booting the kernel ",the prompt information is as follow:
Linux
uncompressing the kernel ....done
Now booting the kernel
and then there is nothing .
The linux code I used is linux-2.6-xlix,the version is 2.6.22.And I use the uartlite IP.And use the XMD to download the kernel,the command is dow zImage.elf,con.
I don't know what the problem is.Can you give me a help? Thanks you!
[-- Attachment #2: Type: text/html, Size: 1043 bytes --]
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: David Gibson @ 2008-07-18 3:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080717150715.GD31932@secretlab.ca>
On Thu, Jul 17, 2008 at 09:07:15AM -0600, Grant Likely wrote:
> On Thu, Jul 17, 2008 at 03:07:30PM +0400, Anton Vorontsov wrote:
> > On Thu, Jul 17, 2008 at 07:59:03AM +0200, Segher Boessenkool wrote:
> > > What would be the parent node of this, btw?
> >
> > This is tricky question. Personally I place them inside the gpio
> > controller node that is responsible for the LED. But I think placing the
> > led nodes at top level would be also fine (maybe with "leds { }" node as
> > a parent for all board's LEDs. What would you suggest for a "best
> > practice"?
>
> I like this idea (a 'leds' parent node). They aren't really children
> of the GPIO node or any other device/bus in the system. Putting them
> under a dedicated 'leds' node would make them easy to find and would
> have the added advantage of making it easier to have a single driver
> instance manage the whole lot.
Hmm. Putting them under the gpio seems reasonable to me. The gpio
lines are the LEDs' "bus" to the limited extent that they have any bus
at all.
This brings us back to the issue we also have with DCR controlled
devices. Possibly we should have two ways of representing these
connections: for "pure" GPIO-only or DCR-only devices, they appear
under the relevant controller with the addresses encoded with 'reg'.
For devices on other busses which also have a few GPIO lines / DCR
registers, they would appear on the other bus with 'gpios' or
'dcr-reg' properties (or some new, generalized 'other-bus-reg'
property).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [2.6 patch] powerpc/boot/dtc-src/dtc-lexer.l: add %option noinput
From: David Gibson @ 2008-07-18 3:43 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20080717181949.GC18326@cs181140183.pp.htv.fi>
On Thu, Jul 17, 2008 at 09:19:49PM +0300, Adrian Bunk wrote:
> gcc 4.3 correctly determines that input() is unused and gives the
> following warning:
>
> <-- snip -->
>
> ...
> HOSTCC arch/powerpc/boot/dtc-src/dtc-lexer.lex.o
> dtc-lexer.lex.c:1436: warning: ‘input’ defined but not used
> ...
>
> <-- snip -->
>
> Fix it by adding %option noinput to
> arch/powerpc/boot/dtc-src/dtc-lexer.l and
> regeneration of arch/powerpc/boot/dtc-src/dtc-lexer.lex.c_shipped.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Uh.. that should be fixed in dtc upstream. It's probably time we
updated the in-kernel dtc from upstream anyway.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox