* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-18 10:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080718062937.GA10988@secretlab.ca>
On Fri, Jul 18, 2008 at 12:29:37AM -0600, Grant Likely wrote:
> On Mon, Jul 14, 2008 at 12:45:55PM +0100, Mark Brown wrote:
> > On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
> > This configuration is also exposed via a sysfs file, including some of
> > the configurability. Exposing the information via sysfs isn't a
> > particular problem but allowing it to be written to without going
> > through ALSA seems wrong.
> All the written bit does is trigger the keyclick event. It doesn't
> adjust the parameters in any way.
That should be OK for now but we ought to work out a way of doing this
via an ALSA control so it can be standardised over the devices that
support it. I can't see anything suitable currently, though.
> > > +#if defined(CONFIG_SND_SOC_OF)
> > > + /* Tell the of_soc helper about this codec */
> > > + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> > > + spi->dev.archdata.of_node);
> > > +#endif
> > CONFIG_SND_SOC_OF could be a module - this needs to also check for it
> > being a module.
> Doesn't #if defined() match on both static and module selection?
Sadly not.
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Chirag Jog @ 2008-07-18 10:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-rt-users, Josh Triplett, Steven Rostedt, linuxppc-dev,
Nivedita Singhvi, Timothy R. Chavez, Thomas Gleixner, paulmck,
linux.kernel
In-Reply-To: <1216325671.7740.359.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2008-07-18 06:14:31]:
>
> > 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.
>
With the original patch, the pending batch does get flushed
in a non-preemptable region.
I am resending the original with just adding the necesary comments.
-Thanks,
Chirag
Signed-Off-By: Chirag <chirag@linux.vnet.ibm.com>
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-18 10:08:00.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-18 10:09:54.000000000 +0530
@@ -38,7 +38,6 @@
* include/asm-powerpc/tlb.h file -- tgall
*/
DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
struct pte_freelist_batch
@@ -48,7 +47,7 @@
pgtable_free_t tables[0];
};
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
+DEFINE_PER_CPU_LOCKED(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
#define PTE_FREELIST_SIZE \
@@ -92,24 +91,21 @@
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
- /*
- * This is safe since tlb_gather_mmu has disabled preemption.
- * tlb->cpu is set by tlb_gather_mmu as well.
- */
+ int cpu;
cpumask_t local_cpumask = cpumask_of_cpu(tlb->cpu);
- struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
+ struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpus_equal(tlb->mm->cpu_vm_mask, local_cpumask)) {
pgtable_free(pgf);
- return;
+ goto cleanup;
}
if (*batchp == NULL) {
*batchp = (struct pte_freelist_batch *)__get_free_page(GFP_ATOMIC);
if (*batchp == NULL) {
pgtable_free_now(pgf);
- return;
+ goto cleanup;
}
(*batchp)->index = 0;
}
@@ -118,6 +114,9 @@
pte_free_submit(*batchp);
*batchp = NULL;
}
+
+ cleanup:
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/*
@@ -253,13 +252,15 @@
void pte_free_finish(void)
{
- /* This is safe since tlb_gather_mmu has disabled preemption */
- struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
+ int cpu;
+ struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
- if (*batchp == NULL)
- return;
- pte_free_submit(*batchp);
- *batchp = NULL;
+ if (*batchp) {
+ pte_free_submit(*batchp);
+ *batchp = NULL;
+ }
+
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/**
Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
===================================================================
--- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-18 10:08:00.000000000 +0530
+++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-18 10:31:02.000000000 +0530
@@ -40,18 +40,20 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
- struct ppc64_tlb_batch *tlbbatch = &__get_cpu_var(ppc64_tlb_batch);
+ /* Disable preemption to ensure the pending TLB batch is flushed
+ * before a potential context switch
+ */
+ struct ppc64_tlb_batch *tlbbatch = &get_cpu_var(ppc64_tlb_batch);
/* If there's a TLB batch pending, then we must flush it because the
* pages are going to be freed and we really don't want to have a CPU
* access a freed page because it has a stale TLB
*/
if (tlbbatch->index) {
- preempt_disable();
__flush_tlb_pending(tlbbatch);
- preempt_enable();
}
+ put_cpu_var(ppc64_tlb_batch);
pte_free_finish();
}
Index: linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/platforms/pseries/iommu.c 2008-07-17 14:47:30.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c 2008-07-18 10:09:54.000000000 +0530
@@ -124,7 +124,7 @@
}
}
-static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
+static DEFINE_PER_CPU_LOCKED(u64 *, tce_page) = NULL;
static void tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
long npages, unsigned long uaddr,
@@ -135,12 +135,13 @@
u64 *tcep;
u64 rpn;
long l, limit;
+ int cpu;
if (npages == 1)
return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
direction);
- tcep = __get_cpu_var(tce_page);
+ tcep = get_cpu_var_locked(tce_page, &cpu);
/* This is safe to do since interrupts are off when we're called
* from iommu_alloc{,_sg}()
@@ -148,10 +149,13 @@
if (!tcep) {
tcep = (u64 *)__get_free_page(GFP_ATOMIC);
/* If allocation fails, fall back to the loop implementation */
- if (!tcep)
+ if (!tcep) {
+ put_cpu_var_locked(tce_page, cpu);
return tce_build_pSeriesLP(tbl, tcenum, npages,
uaddr, direction);
- __get_cpu_var(tce_page) = tcep;
+ }
+
+ per_cpu_var_locked(tce_page, cpu) = tcep;
}
rpn = (virt_to_abs(uaddr)) >> TCE_SHIFT;
@@ -188,6 +192,8 @@
printk("\ttce[0] val = 0x%lx\n", tcep[0]);
show_stack(current, (unsigned long *)__get_SP());
}
+
+ put_cpu_var_locked(tce_page, cpu);
}
static void tce_free_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-18 10:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080718071720.GA2174@secretlab.ca>
On Fri, Jul 18, 2008 at 01:17:20AM -0600, Grant Likely wrote:
> Okay, I've changed my mind. :-) I'll back off a bit from this extreme and
> call it:
> sound/soc/fsl/soc-of-simple.c
> Does that sound okay? If non-freescale chips decide to use it then it
> can be moved out of the freescale director.
Fine by me - you could add an of directory but I don't mind either way
so long as the people actually using the code are happy.
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-18 10:05 UTC (permalink / raw)
To: Trent Piepho; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <Pine.LNX.4.64.0807171807420.29856@t2.domain.actdsltmp>
On Fri, Jul 18, 2008 at 02:20:42AM -0700, Trent Piepho wrote:
> 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
> >> 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).
>
> I'm sorry, I never saw those emails. Were they all to linuxppc-dev? I hate
> reading that list, gmane, marc, and lkml.org don't archive it and
> mail-archive.com isn't nearly as nice.
Usually I use this archive: http://ozlabs.org/pipermail/linuxppc-dev/
> Is this the last version?
> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg18355.html
No, this is v2 or something. The last version is the same as the current
one:
http://ozlabs.org/pipermail/linuxppc-dev/2008-July/059156.html
> Why did you get rid of "linux,default-trigger"
Nobody liked it, even I myself. ;-)
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056943.html
Later I tried to use aliases for default-trigger.
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057244.html
But after "i2c vs. cell-index vs. aliases" discussion I decided to
remove this stuff completely until I find something better (or
somebody will purpose).
As for linux,default-brightness... we don't need this since now we
have default-on trigger.
> and the active-low property?
Active-low can be coded inside the gpios = <>, via flags cell. And GPIO
controller can transparently support active-low GPIO states (i.e. just
like IRQ controllers automatically setting up IRQ trigger types based
on information from the device tree).
I implemented active-low flags for pixis gpio controller, but it is easy
to do this for any controller, when needed. Here is example:
diff --git a/arch/powerpc/platforms/86xx/pixis_gpio.c b/arch/powerpc/platforms/86xx/pixis_gpio.c
new file mode 100644
index 0000000..85254f9
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/pixis_gpio.c
@@ -0,0 +1,141 @@
+/*
+ * PIXIS GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+
+#define PIXIS_GPIO_PINS 8
+
+struct px_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* mask for active-low pins */
+ u8 active_low;
+};
+
+static inline struct px_gpio_chip *
+to_px_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct px_gpio_chip, mm_gc);
+}
+
+static inline u8 pin2mask(unsigned int pin)
+{
+ return 1 << (PIXIS_GPIO_PINS - 1 - pin);
+}
+
+static int px_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct px_gpio_chip *px_gc = to_px_gpio_chip(mm_gc);
+ u8 __iomem *regs = mm_gc->regs;
+
+ return (in_8(regs) ^ px_gc->active_low) & pin2mask(gpio);
+}
+
+static void px_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct px_gpio_chip *px_gc = to_px_gpio_chip(mm_gc);
+ u8 __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+ u8 val_mask = val ? pin2mask(gpio) : 0;
+
+ spin_lock_irqsave(&px_gc->lock, flags);
+
+ if ((val_mask ^ px_gc->active_low) & pin2mask(gpio))
+ setbits8(regs, pin2mask(gpio));
+ else
+ clrbits8(regs, pin2mask(gpio));
+
+ spin_unlock_irqrestore(&px_gc->lock, flags);
+}
+
+static int px_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ return 0;
+}
+
+static int px_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ px_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+#define PX_GPIO_FLAG_ACTIVE_LOW (1 << 0)
+
+int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
+ const void *gpio_spec)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(&of_gc->gc);
+ struct px_gpio_chip *px_gc = to_px_gpio_chip(mm_gc);
+ const u32 *gpio = gpio_spec;
+
+ if (*gpio > of_gc->gc.ngpio)
+ return -EINVAL;
+
+ if (gpio[1] & PX_GPIO_FLAG_ACTIVE_LOW)
+ px_gc->active_low |= pin2mask(*gpio);
+
+ return *gpio;
+}
+
+static int __init pixis_gpio_init(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,fpga-pixis-gpio-bank") {
+ int ret;
+ struct px_gpio_chip *px_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ px_gc = kzalloc(sizeof(*px_gc), GFP_KERNEL);
+ if (!px_gc) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&px_gc->lock);
+
+ mm_gc = &px_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ of_gc->gpio_cells = 2;
+ of_gc->xlate = px_gpio_xlate;
+ gc->ngpio = PIXIS_GPIO_PINS;
+ gc->direction_input = px_gpio_dir_in;
+ gc->direction_output = px_gpio_dir_out;
+ gc->get = px_gpio_get;
+ gc->set = px_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+ continue;
+err:
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(px_gc);
+ /* try others anyway */
+ }
+ return 0;
+}
+arch_initcall(pixis_gpio_init);
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-18 9:58 UTC (permalink / raw)
To: Grant Likely; +Cc: Liam Girdwood, alsa-devel, timur, linuxppc-dev
In-Reply-To: <20080717233153.GA8187@secretlab.ca>
On Thu, Jul 17, 2008 at 05:31:53PM -0600, Grant Likely wrote:
> On Sat, Jul 12, 2008 at 06:36:10PM +0100, Mark Brown wrote:
> > /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.
Sparse (or sparsely used) register maps are pretty common - in practice
it's not been a problem to just have a cache that covers everything and
only gets read, the amount of data involved is rarely that large in the
context of what you need to store the audio you're working with.
^ permalink raw reply
* Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
From: Laurent Pinchart @ 2008-07-18 9:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Jeff Garzik, Vitaly Bordug, netdev
In-Reply-To: <20080626175523.54728d07@vitb.ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Thursday 26 June 2008, Vitaly Bordug wrote:
> On Thu, 26 Jun 2008 13:21:23 +0200
> Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
>
> > > There should be no dependencies. When the OF GPIO support is not
> > > selected linux/of_gpio.h will define of_get_gpio() as a stub, so the
> > > fs_enet driver will fall back to the legacy binding.
> >
> > Have we reached a consensus on which tree the patch should go to ?
> I think it should go through powerpc tree, not seeing too much
> netdev-generic stuff in here. If noone will object, Kumar will pick it up I
> guess...
Kumar, could you pick it up ? I'd like to see this in 2.6.27.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Trent Piepho @ 2008-07-18 9:20 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie
In-Reply-To: <20080717234201.GA15745@polina.dev.rtsoft.ru>
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
>> 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).
I'm sorry, I never saw those emails. Were they all to linuxppc-dev? I hate
reading that list, gmane, marc, and lkml.org don't archive it and
mail-archive.com isn't nearly as nice.
Is this the last version?
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg18355.html
Why did you get rid of "linux,default-trigger" and the active-low property?
I couldn't find any discussion about this. When I first saw your current
patch I was going to add them, but I see you already had them and then
removed them.
I'd like to replace my "led-hack" stg patch with this, but I need
default-trigger to do that. I don't need active-low or default-brightness,
but they seem like a good idea. Actually, if you look closely at the patch
I posted, you'll see I had modified the existing leds-gpio driver to add a
default-brightness feature, though I don't need it anymore. The requirement
changed from having an led on during kernel boot to having it flash. I
have another hack for that, since there is no way to pass parameters to a
trigger.
>> 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.
Ok, I used that. It's like the new way partitions are defined in NOR flash
OF bindings. My first example was more like the old way. The led name can
come from a label property or if there is none then the node name is used.
I don't think you can have colons or spaces in node names. I don't have a
default trigger property, but I'd really like to have that. I could add an
active low flag too. Maybe compatible should be "gpio-leds", since you can
define more than one?
The patch is done and works for me. One can select platform device and/or
of_platform device support via Kconfig. I'll port it to the git kernel and
post it soon.
^ permalink raw reply
* Re: Videomode 800x480
From: Alex_SYS @ 2008-07-18 8:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <m24p6o352u.fsf@ohwell.denx.de>
Hello, I`m on the embedded version, and have madee in qconf "framebuffer
console" with fbdev!
I`m sorry, but I don`t have the file "XModeMap" in my target! I have no X
Running!
Detlev Zundel wrote:
>
> Hi Alex,
>
>> Hello, the physical settings for sync are made by U-Boot and working!
>> But in Lunux when I use 800x480, the screen is well, but the Kernel
>> crashes
>> at Bootup!
>> Using 800x600 works!
>> Now I need only "Dummy" settings, that I can tell Linux I would like
>> 800x480
>> and the Kernel doesn`t crash!
>> I don`t know exactly why the Kernel crashes, I know only that the modedB
>> 800x600 and so on work!
>> I will try your settings immediately!
>
> Your keymap seems to be broken. Try to include this in your ~/.Xmodmap
> file:
>
> keycode 10 = 1 period
>
> Cheers
> Detlev
>
> --
> error compiling committee.c: too many arguments to function
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Videomode-800x480-tp18470632p18525123.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-18 8:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <48803D3C.5020608@coritel.it>
In our implimentation we have 9MB sdram which we want our application to
directly access 3 MB at a time due to following reasons :-
1. We dont want our application to make a read call and copy to user 3 MB
and go for context switching ?
2. We thought mmap could be a better solution to this as only one thread
will act upon it and also we planed to have a circular buffer in the kernel
having 3 frame of 3 MB size of the total 9MB ,each time we will block on
read and get the read index and copy the frame of data for user application
to process . We want our kernel circular buffer shared
3. In order to avoid switching we are going for circular buffer mapping to
user space .
4. Now we want our 9MB SDRAM to point to the kernel circular buffer we want
our circular buffer to be mapped to continues paged so that we could map it
to user space.
Now my concern is How can i map SDRAM one to one to circular buffer of such
a huge size ????
My idea is that i will ioreamp SDRAM and do memcpy_toio() when ever i am
writing to the the circular buffer which is dma allocated and pages are set
reserved . and read the frame from user space .
I may be totally wrong in the idea thats why i need your experience and
suggession in this matter .
I hope i have answered to your concern including shiva's.
----- Misbah <><
Marco Stornelli wrote:
>
> Misbah khan ha scritto:
>> This i am not very sure with :-
>> Can we allocate 9MB using vmalloc and assure it to be low memory and not
>> highmem ?
>
> Why do you need only low memory? And why do you need to allocate memory?
> If I understood correctly you need only to "ioremap" a chunk of memory.
>
>> can we ioremap 9 MB SDRAM to kernel virtual ?
>
> Yep.
>
>> can we use vmalloc and do mmap to that allocated memory ,if the pages are
>> not continues then is it going to concern mapping to user space ?
>
> The "contiguous" problem is related only to DMA operations.
>
>>
>> ---Misbah <><
>>
>>
>>
>> Arnd Bergmann wrote:
>>> On Thursday 17 July 2008, Misbah khan wrote:
>>>> I need to allocate 9 MB of memory in to the kernel space which i need
>>>> to
>>>> mmap for the application to access.
>>>>
>>>> I need to know what could be the best possible way of doing the same.
>>>>
>>> If you don't need the memory to be physically contiguous, you can use
>>> vmalloc to get the memory, but then you need to use remap_vmalloc_range
>>> for mapping the memory into a user address space.
>>>
>>> Arnd <><
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>
>
>
> --
> Marco Stornelli
> Embedded Software Engineer
> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
> http://www.coritel.it
>
> marco.stornelli@coritel.it
> +39 06 72582838
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18525063.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Calling the kernel from a mini-bootloader
From: Guillaume Dargaud @ 2008-07-18 8:43 UTC (permalink / raw)
To: ppcdev
In-Reply-To: <93c791ba2d4ce372589da84acd14a15c@bga.com>
Hello Milton and David, thanks t=for the answers.
> This is a very reasonable approach, and is quite similar to what
> I do.
Makes me feel better !!!
> You actually have a few choices. You can put just the loaded
> data, or you can put the elf file and parse the header in your
> boot loader.
I cannot do that for memory constrains. I have 4Mb in the flash for the
kernel and only a few Kb for the eprom of the bootloader. Also the idea is
to sometimes update the kernel but basically never the bootloader.
> After seeing the advantages, I would keep the elf
> header. One big advantage of keeping the elf header is you can
> see how much data will be zeroed for bss when the kernel starts.
> Another choice is rather than loading the kernel, build a zImage
> of some kind (see the code in arch/powerpc/boot). This way the
> kernel code and static data is compressed. I often see a 3-fold
> reduction in size. You can also attach an initrd, should you
> decide to use initramfs later. More o this below.
I'm not too familiar with the sequence of events that unfolds when the
kernel start.
The JTAG debugger copies the kernel at a given address. A program dumps a
copy of that address range in flash. A bootloader does the reverse and
launches it, so it shouldn't really matter what form the kernel takes, as
long as the original _did_ work.
> Ahh ... you are still on ppc. Please note that we just merged
> the removal of arch/ppc, everyone needs to use powerpc now. The
Yes, my code works on the ML405, now I'm just trying to get it to work on
our custom board... I haven't been able to follow closely the PPC/PowerPC
change but it got me worried so I stopped updating at 2.6.15. I'm using the
Xilinx git tree because I rely on a lot of their drivers, so I don't know if
the change will be seemless. From the change of xparameters.h to and
entirely different device description method, I'd say I'm not ready to take
the jump.
Any Xilinx user care to comment on that ?
And I'm supposed to release the alpha version of our code today !!!
> good news is: its easier to state the requirements, and its
Hmmm...
> easier to share the code in vmlinux. The bad news is you have to
> follow the rules for passing data to the kernel. Its not hard.
> We have defined a data structure that is parsed to become a tree
> of data describing the machine, and based the contents on open
> firmware. We call this the flattened device tree.
Our firmware is custom VHDL code. I'll go ask the 'tronics guy if it fits
open firmware requirements, but I'd be surprised.
> Please read Documentation/powerpc/booting-without-of for more
Will do. Last update is 2005. Is this still relevant ?
> I will point out the minimal rom image I did for qemu where the
> device tree is linked into the assembly, the kernel elf file is
> already loaded, but I had to copy the nvram data serially into
> ram and then poke the memory size and initrd location into the
> device tree.
Maybe I can just use an elementary approach like that: have the bootloader
write a single byte with the jumper positions somewhere in RAM, and then
have the kernel read it to use for the Mac address. With the flat addressing
it could work if there aren't built-in securities.
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re:Re: hang on "booting the kernel ...."
From: Joachim Meyer @ 2008-07-18 8:34 UTC (permalink / raw)
To: wsz_422; +Cc: linuxppc-embedded
Hi
If it wasn't the command line, I don't know what it could be. I had the wrong command line at my ml310, so I thought this could be the reason. I'm myself just beginning with both, Linux and FPGA. But I know you don't need to set the Baudrate when you use the UARTlite, so "console=ttyUL0 root=/dev/ram rw ip=off" would do it. But this isn't responsible for you Problem.
Sorry I can't help you.
Greez
Jogi
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
^ permalink raw reply
* Linux not booting on MPC8313ERDB
From: Vijay Nikam @ 2008-07-18 8:28 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am trying to port everything (u-boot-nand.bin, uImage(kernel), jffs2
and dtb) on NAND of MPC8313ERDB board ...
I loaded u-boot-nand.bin to boot the board from NAND and it is
successful ... but the problem is in loading kernel ... the kernel
version and location is detected properly and it starts loading it but
at mounting file system it gives Magic bit mask error and finally says
kernel panic and wait for reboot ...
Could any one please provide some information to proceed ... thank you
Kind Regards,
Vijay Nikam
^ permalink raw reply
* Problem creating the ML403 project using Xilinx tool
From: Naresh Bhat @ 2008-07-18 7:21 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
Hi Guys,
I have tried to create the ML403 project using the
"ml403_emb_ref_ppc_81.zip" from Xilinx website.
I have used the toold EDK10.SP2 and ISE10.1SP4.
Problem:
When I am creating the base system builder project. I am able to see the
UART and Ethernet..etc devices "XPS" like XPS_UART, XPS_ETHERNET,
XPS_ETHERNETLITE.
How can I get the actual devices like EMAC0 on PLB bus with different
options like
NO DMA, Scattered DMA?
--
Naresh Bhat
[-- Attachment #2: Type: text/html, Size: 546 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-18 7:17 UTC (permalink / raw)
To: linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080714171632.GH25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 06:16:33PM +0100, Mark Brown wrote:
> On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote:
>
> > I'm okay with that. How about fsl/mpc5200-of-machine.c for now?
> > (only the mpc5200 i2s driver uses it at the moment). It can always be
> > renamed if other folks want to use it for other chips.
>
> That seems reasonable so long as you're happy with it, though it does
> seem to be going to the other extreme in terms of broadness :)
Okay, I've changed my mind. :-) I'll back off a bit from this extreme and
call it:
sound/soc/fsl/soc-of-simple.c
Does that sound okay? If non-freescale chips decide to use it then it
can be moved out of the freescale director.
Cheers,
g.
^ permalink raw reply
* Re: hang on "booting the kernel ...."
From: Joachim Meyer @ 2008-07-18 7:16 UTC (permalink / raw)
To: wsz_422; +Cc: linuxppc-embedded
Hi
Perhaps you have the wrong entry in the kernel config at:
Platform options=AD>
Initial kernel command string=AD>
It should be "(console=3DttyUL0 ............)".=20
Greez
Jogi
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ihre Messenger, Communities und E-Mails jetzt in einem Programm!
WEB.DE MultiMessenger http://www.produkte.web.de/messenger/=3Fdid=3D3071
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Marco Stornelli @ 2008-07-18 6:50 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <18522535.post@talk.nabble.com>
Misbah khan ha scritto:
> This i am not very sure with :-
> Can we allocate 9MB using vmalloc and assure it to be low memory and not
> highmem ?
Why do you need only low memory? And why do you need to allocate memory?
If I understood correctly you need only to "ioremap" a chunk of memory.
> can we ioremap 9 MB SDRAM to kernel virtual ?
Yep.
> can we use vmalloc and do mmap to that allocated memory ,if the pages are
> not continues then is it going to concern mapping to user space ?
The "contiguous" problem is related only to DMA operations.
>
> ---Misbah <><
>
>
>
> Arnd Bergmann wrote:
>> On Thursday 17 July 2008, Misbah khan wrote:
>>> I need to allocate 9 MB of memory in to the kernel space which i need to
>>> mmap for the application to access.
>>>
>>> I need to know what could be the best possible way of doing the same.
>>>
>> If you don't need the memory to be physically contiguous, you can use
>> vmalloc to get the memory, but then you need to use remap_vmalloc_range
>> for mapping the memory into a user address space.
>>
>> Arnd <><
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-18 6:29 UTC (permalink / raw)
To: linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080714114554.GA25448@sirena.org.uk>
On Mon, Jul 14, 2008 at 12:45:55PM +0100, Mark Brown wrote:
> On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
>
> > ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
> > v1 API, so I don't expect it to get merged as-is, but I want to get it
> > out there for review.
>
> This looks basically good - most of the issues below are nitpicky.
>
> > + /* Configure PLL */
> > + pval = 1;
> > + jval = (fsref == 44100) ? 7 : 8;
> > + dval = (fsref == 44100) ? 5264 : 1920;
> > + qval = 0;
> > + reg = 0x8000 | qval << 11 | pval << 8 | jval << 2;
> > + aic26_reg_write(codec, AIC26_REG_PLL_PROG1, reg);
> > + reg = dval << 2;
> > + aic26_reg_write(codec, AIC26_REG_PLL_PROG2, reg);
>
> Does the PLL configuration not depend on the input clock frequency? You
> have a set_sysclk() method to configure the MCLK supplied but the driver
> never appears to reference the value anywhere.
Yes, this should be done better. I'm working on making this better, but
I'm hoping it is okay to have that as follow-on patches.
> > + /* Power up CODEC */
> > + aic26_reg_write(codec, AIC26_REG_POWER_CTRL, 0);
>
> As discussed this should probably just be removed from hw_params().
done
> > +static int aic26_set_fmt(struct snd_soc_codec_dai *codec_dai, unsigned int fmt)
> > +{
>
> > + /* interface format */
> > + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> > + case SND_SOC_DAIFMT_I2S: aic26->datfm = AIC26_DATFM_I2S; break;
> > + case SND_SOC_DAIFMT_DSP_A: aic26->datfm = AIC26_DATFM_DSP; break;
> > + case SND_SOC_DAIFMT_RIGHT_J: aic26->datfm = AIC26_DATFM_RIGHTJ; break;
> > + case SND_SOC_DAIFMT_LEFT_J: aic26->datfm = AIC26_DATFM_LEFTJ; break;
> > + default: dev_dbg(&aic26->spi->dev, "bad format\n"); return -EINVAL;
> > + }
>
> I'm having a hard time liking this indentation style. It's not an
> obstacle to merging but it doesn't really help legibility - there's not
> enough white space and once you have a non-standard line like the
> default: one.
Cleaned up.
> > +static const char *aic26_capture_src_text[] = {"Mic", "Aux"};
> > +static const struct soc_enum aic26_capture_src_enum =
> > + SOC_ENUM_SINGLE(AIC26_REG_AUDIO_CTRL1, 12,2, aic26_capture_src_text);
>
> checkpatch complains about the 12,2 here and a bunch of other stuff -
> ALSA is generally very strict about that.
Originally, that had been to keep the line under 80 chars, but some of
the names have changed since then to make it no longer necessary. I'll
clean up the checkpatch stuff.
>
> > + SOC_SINGLE("Keyclick activate", AIC26_REG_AUDIO_CTRL2, 15, 0x1, 0),
> > + SOC_SINGLE("Keyclick amplitude", AIC26_REG_AUDIO_CTRL2, 12, 0x7, 0),
> > + SOC_SINGLE("Keyclick frequency", AIC26_REG_AUDIO_CTRL2, 8, 0x7, 0),
> > + SOC_SINGLE("Keyclick period", AIC26_REG_AUDIO_CTRL2, 4, 0xf, 0),
>
> This configuration is also exposed via a sysfs file, including some of
> the configurability. Exposing the information via sysfs isn't a
> particular problem but allowing it to be written to without going
> through ALSA seems wrong.
All the written bit does is trigger the keyclick event. It doesn't
adjust the parameters in any way.
> > +static ssize_t aic26_regs_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
>
> As discussed this is replicating the existing codec register display
> sysfs file.
removed
> > +#if defined(CONFIG_SND_SOC_OF)
> > + /* Tell the of_soc helper about this codec */
> > + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> > + spi->dev.archdata.of_node);
> > +#endif
>
> CONFIG_SND_SOC_OF could be a module - this needs to also check for it
> being a module.
Doesn't #if defined() match on both static and module selection?
> > +#define AIC26_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
> > + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\
> > + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\
> > + SNDRV_PCM_RATE_48000)
> > +#define AIC26_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE |\
> > + SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE)
>
> These are usually kept in the driver code.
fixed.
Thanks,
g.
^ permalink raw reply
* jumping to code in RAM in a MPC55xx
From: Tehn Yit Chin @ 2008-07-18 6:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
Hi,
This question is not directly related to linux, but a question on how to
execute code from.
My test code is as follows..
void ram(unsigned int cat) __attribute__ ((section(".ram_code")));
void ram1(void) __attribute__ ((section(".ram_code")));
void flash(void) __attribute__ ((section(".text")));
void flash1(unsigned int y) __attribute__ ((section(".text")));
void ram(unsigned int cat)
{
unsigned int abc;
abc += 12;
abc += cat;
}
void ram1(void)
{
ram(123);
}
void flash1(unsigned int y)
{
unsigned int x;
x = x + y;
}
void flash(void)
{
unsigned int def;
def += 12;
asm (" bel ram1\n\t");
}
I have the section .ram_code mapped into the internal SRAM of the MPC55xx,
which starts at 0x40000000. Code in .text are mapped into MPC55xx's internal
FLASH, starting at 0x00000000.
When I attempt to link the code together, I get the error
U:\src\applications\comms/fatdog.c(35,1): relocation truncated to fit:
R_PPC_REL24 against symbol `ram1' defined in .ram_code section in
U:\src\applications\comms\fatdog.o
I googled the error and I think it means that the ram1() is too far away and
the branch address has been truncated to fit into the binary.
Other than assembler bel instruction, I have also tried bl, b and bea and
all of them gave the same link error.
I was wondering if anyone can give some insight on how I can get the MPC55xx
to branch between FLASH and SRAM?
Many thanks,
Tehn Yit Chin
[-- Attachment #2: Type: text/html, Size: 1857 bytes --]
^ permalink raw reply
* Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
From: Mohan Kumar M @ 2008-07-18 5:32 UTC (permalink / raw)
To: benh; +Cc: ppcdev, paulus, miltonm
In-Reply-To: <1216325187.7740.353.camel@pasglop>
Benjamin Herrenschmidt wrote:
> 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 !
>
Hi,
Oops, I missed out the detailed change description. Thanks Ben for
pointing this.
Here is a change summary from v2 to v3:
PATCH 1:
The difference is relocs.c is moved to arch/powerpc/boot from arch/powerpc/
PATCH 2:
Relocation build support is now 90% integrated with kernel build
process. Earlier one has to run separately different make to build
vmlinux.reloc image. Required linker scripts are moved to
arch/powerpc/boot from arch/powerpc
PATCH 3:
The difference is reloc_apply.S is moved to arch/powerpc/boot from
arch/powerpc/
PATCH 4:
Enough care is taken when creating bolted mapping for kdump kernel. Now
it creates bolted mapping from 32MB to of size "crash kernel size" in
case of crash kernel.
Regards,
Mohan.
^ permalink raw reply
* Re: [PATCH v3] leds: implement OpenFirmare GPIO LED driver
From: Grant Likely @ 2008-07-18 5:09 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Richard Purdie,
Trent Piepho
In-Reply-To: <20080717234201.GA15745@polina.dev.rtsoft.ru>
On Fri, Jul 18, 2008 at 03:42:01AM +0400, Anton Vorontsov wrote:
>
<lots of legitimate frustration snipped>
> 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. ;-)
Okay. Thank you for all your work; it is *much* appreciated. I'm sorry
that these things didn't come up earlier and I feel your pain. :-)
Trent, I'd be happy to help and do what I can to expedite getting of
gpio-leds support merged in the .27 window.
> > 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.
If we choose that all gpio-leds will have a common parent, then I'd
still argue for the compatible property to be on the parent node because
all the children are homogeneous.
g.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Misbah khan @ 2008-07-18 4:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200807170956.52101.arnd@arndb.de>
This i am not very sure with :-
Can we allocate 9MB using vmalloc and assure it to be low memory and not
highmem ?
can we ioremap 9 MB SDRAM to kernel virtual ?
can we use vmalloc and do mmap to that allocated memory ,if the pages are
not continues then is it going to concern mapping to user space ?
---Misbah <><
Arnd Bergmann wrote:
>
> On Thursday 17 July 2008, Misbah khan wrote:
>> I need to allocate 9 MB of memory in to the kernel space which i need to
>> mmap for the application to access.
>>
>> I need to know what could be the best possible way of doing the same.
>>
>
> If you don't need the memory to be physically contiguous, you can use
> vmalloc to get the memory, but then you need to use remap_vmalloc_range
> for mapping the memory into a user address space.
>
> Arnd <><
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/how-to-allocate-9MB-of-memory-in-kernel---tp18503022p18522535.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Grant Likely @ 2008-07-18 4:44 UTC (permalink / raw)
To: Anton Vorontsov, linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080718033512.GC18748@yookeroo.seuss>
On Fri, Jul 18, 2008 at 01:35:12PM +1000, David Gibson wrote:
> 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).
On the other hand; it's just LEDs. I think a single scheme is enough.
:-)
g.
^ permalink raw reply
* Re: hang on "booting the kernel ...."
From: Jon Smirl @ 2008-07-18 3:26 UTC (permalink / raw)
To: wsz_422; +Cc: linuxppc-embedded
In-Reply-To: <11945316.455961216349028828.JavaMail.coremail@bj126app95.126.com>
On 7/17/08, wsz_422 <wsz_422@126.com> wrote:
>
> 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!
Most likely is that the root name in your device tree doesn't match a
name that has been compiled into the kernel.
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Calling the kernel from a mini-bootloader
From: David Gibson @ 2008-07-18 3:47 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, Guillaume Dargaud
In-Reply-To: <93c791ba2d4ce372589da84acd14a15c@bga.com>
On Thu, Jul 17, 2008 at 11:14:11AM -0500, Milton Miller wrote:
> On Thu Jul 17 at 23:22:28 EST in 2008, Guillaume Dargaud wrote:
[snip]
>> Maybe the main() of the kernel can receive argv/argc the usual way,
>> and I
>> just need to call "0x400000(argc, argv);" but I have no idea if that
>> works.
>
> Ahh ... you are still on ppc. Please note that we just merged
> the removal of arch/ppc, everyone needs to use powerpc now. The
> good news is: its easier to state the requirements, and its
> easier to share the code in vmlinux. The bad news is you have to
> follow the rules for passing data to the kernel. Its not hard.
> We have defined a data structure that is parsed to become a tree
> of data describing the machine, and based the contents on open
> firmware. We call this the flattened device tree.
Your firmware doesn't have to deal with this though, although it can.
It's perfectly acceptable - in fact I'd mildly recommend it over doing
this in the firmware - to instead have the kernel's zImage wrapper
supply the flattened device tree, folding information it needs to get
from the firmware into it.
--
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