Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Monday 21 November 2011 14:16:04 David Daney wrote:
> On 11/21/2011 10:50 AM, Mike Frysinger wrote:
> > On Monday 21 November 2011 13:25:36 David Daney wrote:
> >> On 11/20/2011 03:22 PM, Mike Frysinger wrote:
> >>> On Friday 18 November 2011 14:37:44 David Daney wrote:
> >>>> +switch (w2(ehdr->e_machine)) {
> >>>> +default:
> >>>> +fprintf(stderr, "unrecognized e_machine %d %s\n",
> >>>> +w2(ehdr->e_machine), fname);
> >>>> +fail_file();
> >>>> +break;
> >>>> +case EM_386:
> >>>> +case EM_MIPS:
> >>>> +case EM_X86_64:
> >>>> +break;
> >>>> +} /* end switch */
> >>>
> >>> unlike recordmcount, this file doesn't do anything arch specific. so
> >>> let's just delete this and be done.
> >>
> >> Not really true at this point. We don't know the size or layout of the
> >> architecture specific exception table entries, likewise for
> >> CONFIG_ARCH_HAS_SORT_EXTABLE, we don't even know how to do the
> >> comparison.
> >
> > all of your code that i could see is based on "is it 32bit or is it
> > 64bit". there is no code that says "if it's x86, we need to do XXX".
>
> At this point there is no need. MIPS, i386 and x86_64 all store the key
> in the first word of a two word structure.
>
> If there were some architecture that didn't fit this model, we would
> have to create a special sorting function and select it (and perhaps
> other parameters as well) in that switch statement.
that's trivial to check:
sed -n '/^struct exception_table_entry/,/};/p'\
arch/*/include/asm/uaccess* include/asm-generic/uaccess.h
and indeed, the only arches that don't follow this model are the ones that
define ARCH_HAS_SORT_EXTABLE.
> > when i look in the kernel, we have common code behind
> > ARCH_HAS_SORT_EXTABLE. so you could easily do the same thing:
> >
> > scripts/sortextable.c:
> > #ifdef ARCH_HAS_SORT_EXTABLE
> >
> > switch (w2(ehdr->e_machine)) {
> >
> > default:
> > fprintf(stderr, "unrecognized e_machine %d %s\n",
> >
> > w2(ehdr->e_machine), fname);
> >
> > ... return a unique exit code like 77 ...
> > break;
> >
> > /* add arch sorting info here */
> > } /* end switch */
> >
> > #endif
> >
> > kernel/extable.c:
> > #if defined(ARCH_HAS_SORT_EXTABLE)&& !defined(ARCH_HAS_SORTED_EXTABLE)
> > void __init sort_main_extable(void)
> > {
> >
> > sort_extable(__start___ex_table, __stop___ex_table);
> >
> > }
> > #endif
>
> Yes, I am familiar with that code. One thing to keep in mind is that
> the compiler has access to struct exception_table_entry, and can easily
> figure out both how big the structure is *and* where the insn field is
> within the structure.
>
> This is not the case for the author of sortextable. Except for MIPS,
> MIPS64, i386 and x86_64, I know neither the size of struct
> exception_table_entry, nor the offset of its insn field.
a trivial sed/grep gets you the answer: they're all the same
> > this way all the people not doing unique stuff work out of the box. only
> > the people who are doing funky stuff need to extend things.
>
> I didn't want to include something like this that I cannot test. An
> unsorted (or improperly sorted) exception table is not necessarily
> something that will be noticeable by simply booting the kernel. Your
> only indication may be a panic or OOPS under rarely encountered conditions.
this is what linux-next is for :)
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Monday 21 November 2011 13:25:36 David Daney wrote:
> On 11/20/2011 03:22 PM, Mike Frysinger wrote:
> > On Friday 18 November 2011 14:37:44 David Daney wrote:
> >> + switch (w2(ehdr->e_machine)) {
> >> + default:
> >> + fprintf(stderr, "unrecognized e_machine %d %s\n",
> >> + w2(ehdr->e_machine), fname);
> >> + fail_file();
> >> + break;
> >> + case EM_386:
> >> + case EM_MIPS:
> >> + case EM_X86_64:
> >> + break;
> >> + } /* end switch */
> >
> > unlike recordmcount, this file doesn't do anything arch specific. so
> > let's just delete this and be done.
>
> Not really true at this point. We don't know the size or layout of the
> architecture specific exception table entries, likewise for
> CONFIG_ARCH_HAS_SORT_EXTABLE, we don't even know how to do the comparison.
all of your code that i could see is based on "is it 32bit or is it 64bit".
there is no code that says "if it's x86, we need to do XXX".
when i look in the kernel, we have common code behind ARCH_HAS_SORT_EXTABLE.
so you could easily do the same thing:
scripts/sortextable.c:
#ifdef ARCH_HAS_SORT_EXTABLE
switch (w2(ehdr->e_machine)) {
default:
fprintf(stderr, "unrecognized e_machine %d %s\n",
w2(ehdr->e_machine), fname);
... return a unique exit code like 77 ...
break;
/* add arch sorting info here */
} /* end switch */
#endif
kernel/extable.c:
#if defined(ARCH_HAS_SORT_EXTABLE) && !defined(ARCH_HAS_SORTED_EXTABLE)
void __init sort_main_extable(void)
{
sort_extable(__start___ex_table, __stop___ex_table);
}
#endif
this way all the people not doing unique stuff work out of the box. only the
people who are doing funky stuff need to extend things.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Friday 18 November 2011 14:37:44 David Daney wrote:
> --- /dev/null
> +++ b/scripts/sortextable.c
>
> +/*
> + * sortextable.c: Sort the kernel's exception table
> + *
> + * Copyright 2011 Cavium, Inc.
> + *
> + * Based on code taken from recortmcount.c which is:
seems like it'd be nice if the duplicate helper funcs were placed in a common
header file rather than copying & pasting between them.
> + switch (w2(ehdr->e_machine)) {
> + default:
> + fprintf(stderr, "unrecognized e_machine %d %s\n",
> + w2(ehdr->e_machine), fname);
> + fail_file();
> + break;
> + case EM_386:
> + case EM_MIPS:
> + case EM_X86_64:
> + break;
> + } /* end switch */
unlike recordmcount, this file doesn't do anything arch specific. so let's
just
delete this and be done.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH RFC 0/5] Speed booting by sorting exception tables at build time.
On Friday 18 November 2011 14:37:43 David Daney wrote: > I noticed when booting MIPS64 kernels that sorting of the main > __ex_table was taking a long time (2,692,220 cycles or 3.3 mS at > 800MHz to be exact). That is not too bad for real silicon > implementations, but when running on a slow simulator, it can be > significant. i've seen this perf hit in my simulation runs too > Here is more or less what I did: > > o A flag word is added to the kernel to indicate that the __ex_table > is already sorted. sort_main_extable() checks this and if it is > clear, returns without doing the sort. > > o I shamelessly stole code from recordmcount and created a new build > time helper program 'sortextable'. This is run on the final vmlinux > image, it sorts the table, and then clears the flag word. > > Potential areas for improvement: > > o Sort module exception tables too. > > o Get rit of the flag word, and assume that if an architecture supports > build time sorting, that it must have been done. > > o Add support for architectures other than MIPS and x86 i don't see much here that is arch-specific. why have a knob at all ? let's just jump in with both feet and do this for everyone :). -mike signature.asc Description: This is a digitally signed message part.
Re: [PWM v9 0/3] Implement a generic PWM framework
On Thu, Mar 31, 2011 at 23:59, Bill Gatliff wrote: > This patch series contains the ninth attempt at implementation of a > generic PWM device interface framework. Think gpiolib, but for > devices and pseudo-devices that generate pulse-wave-modulated outputs. i was made aware of the existing code in linux/pwm.h. seems that this framework should absorb that since there are already drivers built on top of it (i see a backlight, led, and input driver), and we dont want two frameworks doing exactly the same thing. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Speed up the symbols' resolution process V4
On Fri, May 13, 2011 at 03:01, Alessio Igor Bogani wrote: > I changed the "__" in "+". Could you test this, please? > http://git.kernel.org/?p=linux/kernel/git/abogani/linux-2.6.git;a=shortlog;h=refs/heads/ksym-sorted-v6 > Thanks a lot! seems to build & boot ok for me. cheers. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Speed up the symbols' resolution process V4
On Thu, May 12, 2011 at 05:10, Alessio Igor Bogani wrote: > 2011/5/11 Mike Frysinger: > [...] >> if you export _foo/foo, you'll get an error with the current code: >> /* EXPORT_SYMBOL(foo); */ >> .section ___ksymtab__foo,"a",@progbits >> ___ksymtab_foo: >> /* EXPORT_SYMBOL(_foo); */ >> .section ___ksymtab___foo,"a",@progbits >> ___ksymtab__foo: > [...] > > So I can suggest two possible solutions for section names: > > 1) As you suggested change "__" to "+" so > i.e. ___ksymtab+foo > > 2) Pick a more appropriate name: > i.e. ___ksym__foo > or > i.e. ___ksymsec__foo > > In fact these section names aren't a table of symbols (in ksymtab the > "tab" part stand for table, I suppose) so I think that name should be > changed accordingly (my patchset create a temporary section for every > symbol). > > Which do you prefer? i suggested the diff split char as i dont know how embedded the "ksymtab" section name is in the rest of the tree. but if changing that is an option, that'd work too. either works for me, so whichever is less effort for you. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Speed up the symbols' resolution process V4
On Wed, May 11, 2011 at 05:19, Alessio Igor Bogani wrote: >> name. so rather than "__", use "+". > > Sorry I don't think that is a good choice from a long term point of > view. What do you think to add MODULE_SYMBOL_PREFIX to section names > instead? In this way symbol and section names should always be > different also on symbol prefixed archs (which are blackfin and > h8300). that doesnt work. it simply delays the problem to another set of underscores. so with that change, local_bh_enable/_local_bh_enable work, but now send_remote_softirq/__send_remote_softirq fail: CC kernel/softirq.o nano /tmp/cconhYy1.s: Assembler messages: /tmp/cconhYy1.s:3664: Error: symbol `___ksymtab___send_remote_softirq' is already defined make[1]: *** [kernel/softirq.o] Error 1 so any option that involves using underscores as the separator will not work. pick something else, like "+" or "." or ... i dont see a problem with using these. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Speed up the symbols' resolution process V4
On Wed, May 11, 2011 at 11:25, Alessio Igor Bogani wrote: > 2011/5/11 Mike Frysinger: >>> Sorry I don't think that is a good choice from a long term point of >>> view. What do you think to add MODULE_SYMBOL_PREFIX to section names >>> instead? In this way symbol and section names should always be >>> different also on symbol prefixed archs (which are blackfin and >>> h8300). >> >> that doesnt work. it simply delays the problem to another set of >> underscores. so with that change, local_bh_enable/_local_bh_enable >> work, but now send_remote_softirq/__send_remote_softirq fail: > > In my opinion it should work. if I use SYMBOL_PREFIX + two underscore > for section name I should always obtain different names. > So if SYMBOL_PREFIX is "_" section name will be "___", if > SYMBOL_PREFIX is "__" section name will be "" and so on. i dont follow your logic. SYMBOL_PREFIX is simply an underscore for Blackfin, so you are not guaranteed unique names when you're only prefixing more underscores. the issue isnt with a symbol colliding with itself, the issue is with a symbol colliding with another symbol that has underscores added to its name. if you export _foo/foo, you'll get an error with the current code: /* EXPORT_SYMBOL(foo); */ .section___ksymtab__foo,"a",@progbits ___ksymtab_foo: /* EXPORT_SYMBOL(_foo); */ .section___ksymtab___foo,"a",@progbits ___ksymtab__foo: you can see how the first section and the last symbol collide by putting the symbol prefix along the lines of the separator, you delay it to __foo/foo: /* EXPORT_SYMBOL(foo); */ .section___ksymtab___foo,"a",@progbits ___ksymtab_foo: /* EXPORT_SYMBOL(__foo); */ .section___ksymtab_foo,"a",@progbits ___ksymtab___foo: the Blackfin toolchain puts the prefix before the ksymtab part while you're putting it after, so there is always a possibility of collision unless you pick a split char that doesnt include an underscore. >> CC kernel/softirq.o >> nano /tmp/cconhYy1.s: Assembler messages: >> /tmp/cconhYy1.s:3664: Error: symbol `___ksymtab___send_remote_softirq' >> is already defined >> make[1]: *** [kernel/softirq.o] Error 1 > > I'm a bit confused. I can build a kernel here: > $ make ARCH=blackfin CROSS_COMPILE="bfin-uclinux-" defconfig it's failing for me with current linux-next and the patch you posted previously. also, you dont need to set CROSS_COMPILE as that is the default value for ARCH=blackfin ... > Unfortunately I can't make skyeye emulator works to test the obtained > kernel image. skyeye is crap. the latest upstream gdb/sim code can boot a kernel, but if you aren't up-to-date with that, this binary i've been using locally should work too: http://blackfin.uclinux.org/uimages/bfin-elf-run $ bfin-elf-run --env operating --model bf537 --sirev 2 ./vmlinux earlyprintk=serial,uart0 console=ttyBF0 Linux version 2.6.39-rc7-ADI-2011R1-pre-00132-g9d91c9a (vapier@vapier-m) (gcc version 4.3.5 (ADI-trunk/git-ce854ee) ) #16 Wed May 11 11:55:28 EDT 2011 register early platform devices bootconsole [early_shadow0] enabled bootconsole [early_BFuart0] enabled early printk enabled on early_BFuart0 Limiting kernel memory to 56MB due to anomaly 05000263 Board Memory: 64MB Kernel Managed Memory: 64MB Memory map: fixedcode = 0x0400-0x0490 text = 0x1000-0x000f7f30 rodata= 0x000f7f30-0x001456ac . -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Speed up the symbols' resolution process V4
On Sat, Apr 16, 2011 at 09:26, Alessio Igor Bogani wrote: > In the first place I changed the code for place every symbol in a different > section (for example: "___ksymtab" sec "__" #sym) at compile time (this the > above mentioned trick!). Thus I request to the linker to sort and merge all > these sections into the appropriate ones (for example: "__ksymtab") at link > time using the linker scripts. Once all symbols are sorted we can use binary > search instead of the linear one. this breaks symbol prefixed arches (like Blackfin): CC kernel/softirq.o /tmp/ccp3A6LU.s: Assembler messages: /tmp/ccp3A6LU.s:3734: Error: symbol `___ksymtab__local_bh_enable' is already defined make[1]: *** [kernel/softirq.o] Error 1 this is because your new system of section naming happens to overlap actual symbol names and the gnu assembler does not allow you to declare a section and a symbol with the same name. might be better to pick a separator that cannot appear in a symbol name. so rather than "__", use "+". or some other funky char. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On Thu, May 5, 2011 at 16:25, Tim Bird wrote: > On 05/05/2011 12:27 PM, Mike Frysinger wrote: >> On Thu, May 5, 2011 at 15:12, Tim Bird wrote: >>> As for in-tree-ness - I thought the most recent message was to stay >>> out of tree until the refactoring was over. ;-) >> >> to be fair, does this have any relevance whatsoever to NEC parts ? >> istm that the hindrance here is NEC doing any actual work for >> mainline. even if there was no refactoring, i find it hard to believe >> that an NEC port would be posted. if it were actually something that >> could happen, then they should already be posting patches for *basic* >> review to get the pieces unrelated to the refactoring worked out. >> there's no reason this has to be done serially. > > Well, OK. I just don't want to lob bombs at NEC and then > have some poor soul over there get immediately rebuffed, due to > basic ARM churn. Maybe not having naviengine support upstream > is my fault, but Sony doesn't make the CPU, so it doesn't seem > like it should be my job to mainline the chip support. About > the only thing I have at my disposal is pressure not to buy > the chip (but this is harder to exercise than one might think.) i dont have any vested interest either way wrt NEC or ARM/XIP. i was just trying to highlight what i saw as a red herring. i think the axiom "post early & post often" holds just as true here. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On Thu, May 5, 2011 at 15:12, Tim Bird wrote: > On 05/05/2011 12:04 PM, Mike Frysinger wrote: >> On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote: >>> On Thu, 5 May 2011, Tim Bird wrote: >>>> On 05/05/2011 11:32 AM, David Woodhouse wrote: >>>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: >>>>>> On 05/05/2011 11:00 AM, Tim Bird wrote: >>>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it >>>>>>> >>>>>>> Sony uses this - a lot. Principally we're using this on a NEC >>>>>>> naviengine part, which is ARM11MPCore based, support for which >>>>>>> is (sadly) out of tree. >>>>> >>>>> If you're out of tree, you don't exist. >>>> >>>> Yeah - I know. I guess I should tell NEC we'll drop support >>>> for their chip and move to another one that supports XIP >>>> if they don't get their act together. If XIP survives... >>> >>> It is easy enough to keep it alive... as long as someone uses it of >>> course. >> >> i think David's point: >> ... someone uses it ... > > I should add that I tried to use XIP on omap (for research purposes), > but it was broken and I didn't have time to fix it. My bad. > If anyone is using XIP on in-tree platforms, I'd like to hear > about it. XIP on Blackfin should work right now, but that doesnt directly apply to the patch in question here. it does however imply that other pieces in the stack work (like the MTD/mm layers). > As for in-tree-ness - I thought the most recent message was to stay > out of tree until the refactoring was over. ;-) to be fair, does this have any relevance whatsoever to NEC parts ? istm that the hindrance here is NEC doing any actual work for mainline. even if there was no refactoring, i find it hard to believe that an NEC port would be posted. if it were actually something that could happen, then they should already be posting patches for *basic* review to get the pieces unrelated to the refactoring worked out. there's no reason this has to be done serially. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote: > On Thu, 5 May 2011, Tim Bird wrote: >> On 05/05/2011 11:32 AM, David Woodhouse wrote: >> > On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: >> >> On 05/05/2011 11:00 AM, Tim Bird wrote: >> >>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >> nearly no-one use it, only amop1, pxa and sa1100 implement it >> >>> >> >>> Sony uses this - a lot. Principally we're using this on a NEC >> >>> naviengine part, which is ARM11MPCore based, support for which >> >>> is (sadly) out of tree. >> > >> > If you're out of tree, you don't exist. >> >> Yeah - I know. I guess I should tell NEC we'll drop support >> for their chip and move to another one that supports XIP >> if they don't get their act together. If XIP survives... > > It is easy enough to keep it alive... as long as someone uses it of > course. i think David's point: ... someone uses it ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v8 1/3] PWM: Implement a generic PWM framework
On Wed, Mar 30, 2011 at 20:43, Bill Gatliff wrote: > On Wed, Mar 30, 2011 at 6:57 PM, Mike Frysinger wrote: >> On Sat, Mar 12, 2011 at 23:24, Bill Gatliff wrote: >>> +T: git git://git.billgatliff.com/pwm.git >> >> $ git clone git://git.billgatliff.com/pwm.git >> Cloning into pwm... >> fatal: The remote end hung up unexpectedly > > I just tried http://git.billgatliff.com/pwm.git, and that's working. > FWIW. I don't know why git:// has suddenly stopped working... seems to be working, albeit with significantly more overhead. i guess a one-off fetch is fine for now for me to play. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v8 1/3] PWM: Implement a generic PWM framework
On Wed, Mar 30, 2011 at 20:36, Mike Frysinger wrote: > On Wed, Mar 30, 2011 at 20:33, Bill Gatliff wrote: >> On Wed, Mar 30, 2011 at 6:57 PM, Mike Frysinger wrote: >>> On Sat, Mar 12, 2011 at 23:24, Bill Gatliff wrote: >>>> +T: git git://git.billgatliff.com/pwm.git >>> >>> $ git clone git://git.billgatliff.com/pwm.git >>> Cloning into pwm... >>> fatal: The remote end hung up unexpectedly >>> >>> :( >>> >>> why not get an account on kernel.org like everyone else and push your >>> tree there ? >> >> Tried that once, got no response. >> >> I'm open to trying again if you can direct me to the right place. > > i used this: > https://accounts.kernel.org/ > > make sure to mention your PWM framework ? in the mean time, you could easily use a free service like http://repo.or.cz/ ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v8 1/3] PWM: Implement a generic PWM framework
On Wed, Mar 30, 2011 at 20:33, Bill Gatliff wrote: > On Wed, Mar 30, 2011 at 6:57 PM, Mike Frysinger wrote: >> On Sat, Mar 12, 2011 at 23:24, Bill Gatliff wrote: >>> +T: git git://git.billgatliff.com/pwm.git >> >> $ git clone git://git.billgatliff.com/pwm.git >> Cloning into pwm... >> fatal: The remote end hung up unexpectedly >> >> :( >> >> why not get an account on kernel.org like everyone else and push your >> tree there ? > > Tried that once, got no response. > > I'm open to trying again if you can direct me to the right place. i used this: https://accounts.kernel.org/ make sure to mention your PWM framework ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v8 1/3] PWM: Implement a generic PWM framework
On Sat, Mar 12, 2011 at 23:24, Bill Gatliff wrote: > +T: git git://git.billgatliff.com/pwm.git $ git clone git://git.billgatliff.com/pwm.git Cloning into pwm... fatal: The remote end hung up unexpectedly :( why not get an account on kernel.org like everyone else and push your tree there ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SPI controller laying around...
On Tue, Mar 15, 2011 at 11:23, Jean-Francois Dagenais wrote: > I need to perform some tests and I am in need of any SPI controller I > could use through the standard SPI master framework of the kernel. > > I could perhaps hack the BIOS SPI for example (fool around with the chip > select and solder some wires to export to a bread board. Or I am sure my > workstation has one on the motherboard (dell vostro 430) for some odd > functionnality... but it's not enumerated and probed as an SPI master. > > Or maybe even old ethernet cards I have lying around which could be > hacked? > > Or a simple USB-SPI dongle? Anyone knows one that will just plain works > with the kernel? > > Any thoughts? if you have just 4 GPIOs, you can use the SPI bit banging bus -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v6 0/3] Implement a generic PWM framework
On Fri, Feb 25, 2011 at 21:38, Bill Gatliff wrote: > On Sun, Feb 20, 2011 at 9:35 PM, Bill Gatliff wrote: >> This patch series contains the sixth attempt at implementation of >> a generic PWM device interface framework. Think gpiolib, but for >> devices and pseudo-devices that generate pulse-wave-modulated outputs. > > Hearing no objections, does this mean that this code is finally ready > for a pull request? To whom do I send it? i'd start with akpm/lkml/linus and add yourself to MAINTAINERS for the pwm framework -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v5 1/3] PWM: Implement a generic PWM framework
On Sun, Feb 20, 2011 at 22:18, Bill Gatliff wrote:
> On Sun, Feb 20, 2011 at 4:46 PM, Mike Frysinger wrote:
>>> +static const struct attribute_group pwm_device_attr_group = {
>>> + .attrs = (struct attribute **) pwm_attrs,
>>> +};
>>
>> should attribute_group have its attrs member constified ?
>
> Isn't it already, given that the pwm_device_attr_group definition is const?
if it were already, you wouldnt need that cast
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v5 1/3] PWM: Implement a generic PWM framework
On Sun, Feb 20, 2011 at 19:38, Bill Gatliff wrote:
> On Sun, Feb 20, 2011 at 4:46 PM, Mike Frysinger wrote:
>>> +#ifdef MODULE
>>> +module_init(pwm_init);
>>> +module_exit(pwm_exit);
>>> +MODULE_LICENSE("GPL");
>>> +#else
>>> +postcore_initcall(pwm_init);
>>> +#endif
>>
>> i dont think you need this MODULE trickery. common code already takes
>> care of this for you, and it'd let you avoid a warning about pwm_exit
>> being unused.
>
> So the postcore_initcall() becomes equivalent to module_init() when I
> build as a module? That would make sense, but I had never thought
> about it before now...
correct, that's what linux/init.h does for people
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v5 1/3] PWM: Implement a generic PWM framework
On Sat, Feb 19, 2011 at 23:10, Bill Gatliff wrote:
> +void pwm_release(struct pwm_device *p)
> +{
> + mutex_lock(&device_list_mutex);
> +
> + if (!test_and_clear_bit(FLAG_REQUESTED, &p->flags)) {
> + BUG();
> + goto done;
> + }
shouldnt that BUG be a WARN ?
> +int pwm_set(struct pwm_device *p, unsigned long period_ns,
> + unsigned long duty_ns, int active_high)
> +{
> + struct pwm_config c = {
> + .config_mask = (BIT(PWM_CONFIG_PERIOD_TICKS)
> + | BIT(PWM_CONFIG_DUTY_TICKS)
> + | BIT(PWM_CONFIG_POLARITY)),
> + .period_ticks = pwm_ns_to_ticks(p, period_ns),
> + .duty_ticks = pwm_ns_to_ticks(p, duty_ns),
> + .polarity = active_high};
i think that brace needs to be uncuddled
> +static const struct attribute *pwm_attrs[] =
> +{
> + &dev_attr_tick_hz.attr,
cuddle up that brace
> +static const struct attribute_group pwm_device_attr_group = {
> + .attrs = (struct attribute **) pwm_attrs,
> +};
should attribute_group have its attrs member constified ?
> +static void __exit pwm_exit(void)
> +{
> + destroy_workqueue(pwm_handler_workqueue);
> + class_unregister(&pwm_class);
> +}
> +
> +#ifdef MODULE
> +module_init(pwm_init);
> +module_exit(pwm_exit);
> +MODULE_LICENSE("GPL");
> +#else
> +postcore_initcall(pwm_init);
> +#endif
i dont think you need this MODULE trickery. common code already takes
care of this for you, and it'd let you avoid a warning about pwm_exit
being unused.
postcore_initcall(pwm_init);
module_exit(pwm_exit);
MODULE_LICENSE("GPL");
also, no MODULE_{INFO,AUTHOR} ?
> +struct pwm_device {
> + struct pwm_device_ops *ops;
const ?
> +void pwm_callback(struct pwm_device *pwm);
> +int gpio_pwm_destroy(struct pwm_device *p);
seems a bit inconsistent ... sometimes you use "p", sometimes you use "pwm" ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v5 2/3] PWM: GPIO+hrtimer device emulation
On Sat, Feb 19, 2011 at 23:10, Bill Gatliff wrote: > +config ATMEL_PWMC > + tristate "Atmel AT32/AT91 PWMC support" > + depends on GENERIC_PWM && (AVR32 || ARCH_AT91SAM9263 || > ARCH_AT91SAM9RL || ARCH_AT91CAP9) > + help > + This option enables support under the generic PWM > + framework for PWMC peripheral channels found on > + certain Atmel microcontrollers. If unsure, say N. doesnt this belong in the atmel pwmc patch ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v5 3/3] PWM: Atmel PWMC driver
On Sat, Feb 19, 2011 at 23:10, Bill Gatliff wrote:
> +static inline void pwmc_writel(const struct atmel_pwmc *p, unsigned offset,
> u32 val)
> +static inline u32 pwmc_readl(const struct atmel_pwmc *p, unsigned offset)
> +static inline void pwmc_chan_writel(const struct pwm_device *p,
> + u32 offset, u32 val)
> +static inline u32 pwmc_chan_readl(const struct pwm_device *p, u32 offset)
> +static inline int __atmel_pwmc_is_on(struct pwm_device *p)
> +static inline void __atmel_pwmc_stop(struct pwm_device *p)
> +static inline void __atmel_pwmc_start(struct pwm_device *p)
> +static inline int __atmel_pwmc_config_polarity(struct pwm_device *p,
> + struct pwm_config *c)
> +static inline int __atmel_pwmc_config_duty_ticks(struct pwm_device *p,
> + struct pwm_config *c)
> +static inline int __atmel_pwmc_config_period_ticks(struct pwm_device *p,
> + struct pwm_config *c)
seems like a lot of unnecessary inlines. while the first two might
make sense since they're really just redirecting to the read/write i/o
api, the rest are quite a bit bigger.
> +static inline int __atmel_pwmc_config_polarity(struct pwm_device *p,
> + struct pwm_config *c)
> +static inline int __atmel_pwmc_config_duty_ticks(struct pwm_device *p,
> + struct pwm_config *c)
> +static inline int __atmel_pwmc_config_period_ticks(struct pwm_device *p,
> + struct pwm_config *c)
these funcs always return 0 and the callers never check the return
value, so i guess these should return void instead
> +static int atmel_pwmc_stop_sync(struct pwm_device *p)
> +{
> + struct atmel_pwmc *ap = pwm_get_drvdata(p);
> + int was_on = __atmel_pwmc_is_on(p);
> + int chan = p - &ap->p[0];
> + int ret;
> +
> + if (was_on) {
> + do {
> + init_completion(&ap->complete);
> + set_bit(FLAG_STOP, &p->flags);
> + pwmc_writel(ap, PWMC_IER, BIT(chan));
> +
> + dev_dbg(p->dev, "waiting on stop_sync
> completion...\n");
> +
> + ret =
> wait_for_completion_interruptible(&ap->complete);
> +
> + dev_dbg(p->dev, "stop_sync complete (%d)\n", ret);
> +
> + if (ret)
> + return ret;
> + } while (test_bit(FLAG_STOP, &p->flags));
> + }
> +
> + return was_on;
> +}
if you changed this to return immediately when !was_on, then you
wouldnt need to indent the entire block.
> + ap->iobase = ioremap_nocache(r->start, r->end - r->start + 1);
isnt there a resource_size helper ?
> + if (IS_ERR_OR_NULL(ap->iobase)) {
> + ret = -ENODEV;
> + goto err_ioremap;
> + }
i dont think any of the io funcs return PTR_ERR. they all return NULL
or a valid address.
> + for (chan = 0; chan < NCHAN; chan++) {
> + ap->p[chan].ops = &ap->ops;
> + pwm_set_drvdata(&ap->p[chan], ap);
> + ret = pwm_register(&ap->p[chan], &pdev->dev, chan);
> + if (ret)
> + goto err_pwm_register;
> + }
> +
> +err_pwm_register:
> + for (chan = 0; chan < chan; chan++) {
> + if (pwm_is_registered(&ap->p[chan]))
> + pwm_unregister(&ap->p[chan]);
> + }
if you wanted to be tricky, you could just have the unwind not change
the value of "chan".
while (--chan > 0)
pwm_unregister(&ap->p[chan]);
otherwise, the "chan < chan" test makes no sense in the for loop.
> +static int __devexit atmel_pwmc_remove(struct platform_device *pdev)
> +{
> + struct atmel_pwmc *ap = platform_get_drvdata(pdev);
> + int chan;
> +
> + for (chan = 0; chan < NCHAN; chan++)
> + if (pwm_is_registered(&ap->p[chan]))
> + pwm_unregister(&ap->p[chan]);
why do you test if it's registered ? the probe function will abort if
any do not register properly.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v4 2/3] PWM: GPIO+hrtimer device emulation
On Sat, Feb 12, 2011 at 23:28, Bill Gatliff wrote:
> On Sat, Feb 12, 2011 at 8:53 PM, Mike Frysinger wrote:
>> document the module name in the help ?
>
> Not sure what you are asking. Like this?
yes, but it seems to be more common to use a style like so:
config xxx
help
normal help text
To compile this driver as module, choose M here: the
module will be called gpio-pwm.
>>> +static struct pwm_device_ops gpio_pwm_device_ops = {
>>> + .config = gpio_pwm_config,
>>> + .config_nosleep = gpio_pwm_config_nosleep,
>>> + .request = gpio_pwm_request,
>>> +};
>>
>> is this struct not constified ? same for some of the other structs in
>> this file ...
>
> It isn't constified, but it should be. But if I do, I get lots of
> "discards qualifiers" warnings because const isn't used in the
> functions I pass these structures to. So I kind of have to leave it
> as-is, no?
it just means the pwm framework needs to be constified in the core code first :)
>> is that useful if they cant call any of the config funcs ?
>
> Users of gpio_pwm aren't supposed to call the config functions in
> gpio-pwm.c, they are supposed to invoke them indirectly via the
> regular PWM API (pwm.c).
hmm, i thought the configfs integration did more than just call the
create/destroy funcs. considering the common gpio code has sysfs
hooks for playing with gpios from userspace, perhaps there should be a
sysfs hook here too rather than requiring configfs ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM v4 2/3] PWM: GPIO+hrtimer device emulation
On Sat, Feb 12, 2011 at 21:15, Bill Gatliff wrote:
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> +config GPIO_PWM
> + tristate "GPIO+hrtimer PWM device emulation"
> + depends on GENERIC_PWM
> + help
> + This option enables code that emulates a single-channel
> + PWM device using a high-resolution timer and a GPIO
> + pin. The PWM framework allows you to create as many
> + of these devices as desired, subject to CPU overhead
> + and GPIO pin availability. If unsure, say N.
document the module name in the help ?
> --- /dev/null
> +++ b/drivers/pwm/gpio-pwm.c
> +#define DRIVER_NAME "gpio-pwm"
use KBUILD_MODNAME instead ?
> +static void gpio_pwm_work (struct work_struct *work)
no space before the "("
> +static struct pwm_device_ops gpio_pwm_device_ops = {
> + .config = gpio_pwm_config,
> + .config_nosleep = gpio_pwm_config_nosleep,
> + .request = gpio_pwm_request,
> +};
is this struct not constified ? same for some of the other structs in
this file ...
> + gp = kzalloc(sizeof(*gp), GFP_KERNEL);
> + if (IS_ERR_OR_NULL(gp))
i dont think the kmalloc funcs return a pointer error. it's either
NULL or it's a valid pointer. this comes up a few times ...
> +EXPORT_SYMBOL(gpio_pwm_create);
> +EXPORT_SYMBOL(gpio_pwm_destroy);
are people expected to call these directly ? is that useful if they
cant call any of the config funcs ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On Tue, Nov 9, 2010 at 12:17, Tim Bird wrote: > On 11/09/2010 03:19 AM, Mike Frysinger wrote: >> On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: >>> It was noted at the summit that several CE companies and embedded >>> projects will be using (or are already using) 2.6.35 for upcoming >>> products or releases. This includes Sony, Google, Meego, and Linaro. On >>> behalf of the CE Linux Forum and a number of consumer electronics >>> companies, projects and community developers, we therefore declare >>> 2.6.35 as a flag version of the kernel for embedded use. Several >>> companies will be investing in development, integration and testing of >>> this version. Entities wanting to do business with those companies would >>> therefore be well-advised to make sure their hardware, drivers and >>> enhancements work well with this version of the kernel. >> >> wouldnt it make more sense to piggy back the extensive work going into >> the "stable" tree ? many of the points you raise after all are the >> entire founding point of it. plus, all the main distros form around >> that, are spending time working on that, is marked as supported for 2 >> or 3 years, and there is already infrastructure/framework/process in >> place (sta...@kernel.org). >> >> so instead of picking arbitrary versions (like 2.6.35) and needlessly >> replicating the huge work load, simply declare these stable trees as >> the "flag" versions. that means today it'd be 2.6.32.y. > > The fact that this tree is already a year old, and not likely to be > brought forward for at least another 2 years is the reason we didn't > choose it this time. Most of the high-profile, active embedded projects > are already on 2.6.35. For companies looking to adopt a new base kernel > in the next 12 months, I don't want to have them start with a year-old > kernel. We did consider the utility of synchronizing with the enterprise > stable tree, but the timing just didn't work too well this time around. so you're suggesting this is a one-off choice. in the future, the "flag" versions will simply piggy the existing stable trees ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: > It was noted at the summit that several CE companies and embedded > projects will be using (or are already using) 2.6.35 for upcoming > products or releases. This includes Sony, Google, Meego, and Linaro. On > behalf of the CE Linux Forum and a number of consumer electronics > companies, projects and community developers, we therefore declare > 2.6.35 as a flag version of the kernel for embedded use. Several > companies will be investing in development, integration and testing of > this version. Entities wanting to do business with those companies would > therefore be well-advised to make sure their hardware, drivers and > enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the "stable" tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the "flag" versions. that means today it'd be 2.6.32.y. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb-skeleton.c - generates warning
On Sat, Oct 16, 2010 at 07:00, Andrew Worsley wrote: > Sorry if this is the wrong mailing list for this - I am writing a USB > driver (for an embedded system) modeled on the > drivers/usb/usb-skeleton.c you can find the correct list here: http://vger.kernel.org/vger-lists.html#linux-usb -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Information on XIP
On Wed, Jun 16, 2010 at 18:19, Tim Bird wrote: > I'd like to start collecting information about XIP on the > eLinux wiki. If you've done XIP for the kernel or for > user-space (application XIP), or know a good source of > information about this, please let me know. Blackfin linux + userspace XIP: http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:xip > I'm interested in putting together a basic tutorial about > XIP, and doing some benchmarking on an ARM platform. i believe the denk guys have done some benchmarking on ppc, so you might want to poke them if they arent on this list -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Pseudo-console for capture and redirection of console output
On Mon, Apr 12, 2010 at 02:35, David VomLehn wrote: > Provide functions for capturing console output for storage. The primary user > is likely to be embedded systems that don't have the storage for core dumps > but do have a need to log kernel panic information for later evaluation. It > offers two main areas of functionality: > > o It can maintain a circular log of console output so that kernel log > messages written before panic() was called can be retrieved to be > added to the failure log. > o A function can be registered to store output from printk() in a > persistent location, such as a reserved location in RAM. Then, > printk() can be used either directly, to print state information, or > indirectly, through standard functions like dump_stack() and > show_regs(). how is this any different from the already existing mtdoops driver ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
On Thu, Jan 21, 2010 at 15:57, Greg KH wrote: > On Thu, Jan 21, 2010 at 09:56:10PM +0100, Paul Chavent wrote: >> I'am working on an embedded gnu/linux system that allow to capture an >> ieee1394 stream. >> >> The system is compound of a kernel, a basic initrd >> (libc,libgcc,busybox,libdc1394,...) and my app. >> >> I use the new firewire stack. >> >> As my system is very minimalist, i tought to create the nodes in /dev at the >> moment of building my initrd. >> >> But when i needed to modify my kernel configuration, it has changed the >> major number of /dev/fw*. >> >> It's not really important for the definitive system (it will be >> freeze), but i wonder how to solve this issue for my future works ? >> >> I don't need hotplug, i just need to fill /dev at startup (coldplug). >> The target is an embedded device, so it should be easy to >> build/configure/install, and lightweight. >> >> For those reasons i don't want to use udev. > > Why, is udev somehow not "lightweight"? in comparison, it is absolutely not -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
On Mon, Dec 21, 2009 at 14:30, Wolfgang Denk wrote: > Andy wrote: >> Another big problem with U-Boot was the inability to update the >> bootloader from the Linux world. Instead the bootloader was treated >> special and had to be updated over USB with DFU (the exclusivity of it >> enforced by an ECC policy disconnected from Linux, meaning U-Boot had to >> write it in there). In Qi, the bootloader can be updated by a packaged >> update like anything else in the rootfs. > > Can you explain to me why it was not possible to update U-Boot from > Linux? I cannot imagine a reason for such a restriction. we do it all the time under the Blackfin port on nor/nand/spi flashes. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Thu, Dec 3, 2009 at 08:38, Kyungmin Park wrote: > On Thu, Dec 3, 2009 at 3:25 PM, Wolfgang Denk wrote: >> Aras Vaichas wrote: >>> Support for 2nd stage booting from NAND with newer filesystems such as >>> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small >>> footprint. >>> >>> TFTP server in a boot loader (U-boot or other). i.e. allows you to >>> push a firmware upgrade image to a device. I do know of a few of these >>> but they are not open sourced. >> >> U-Boot supports both TFTP (and NFS) downlod, and UBI/UBIFS. > > How about the TFTP over USB? It's required feature for no ethernet devices you'll have to be more specific if you want a real answer. U-Boot has USB Ethernet gadget support already. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Tue, Dec 1, 2009 at 18:47, Tim Birdwrote: > Hey embedded Linux developers... > > Are you itching to see some feature developed for embedded > Linux? Would you like to suggest that CELF spend their > money on some specific project? Would you like CELF to > sponsor a project you are working on? > > Well, now is your chance! This is the official announcement > of a new plan by CELF, called the "Open Project Proposal". i know your e-mail intro states "embedded Linux" as does the wiki, but i'm gonna take a stab anyways. does this apply to Linux only and not open source boot loaders (like U-Boot) ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Tue, Dec 1, 2009 at 18:47, Tim Bird wrote: > The CELF Open Project Proposal is a process whereby members > of the public submit to the CE Linux Forum ideas and > proposals for projects that they think should be worked on > to enhance embedded Linux. The plan is to solicit ideas for > our 2010 contract work projects. Areas of work can > include the Linux kernel, graphics systems, toolchain work, > or anything else that will help enhance Linux for use in > embedded systems. > > Each year, CELF spends money on contract work to improve > Linux for use in embedded systems. Some of the projects we > have sponsored in the past include Linux-tiny, DirectFB > enhancements, smem, and Squashfs mainlining. > > Usually, our process involves querying forum members about > their desires and building a project list from that. This > year, we are opening up the process and asking for your ideas > and proposals as well. maybe i missed it, but there doesnt seem to be too much emphasis on working with the respective projects and getting merged. that seems like one of the most important aspects of doing any enhancement work as anything not merged means it'll quickly be left behind and largely go to waste. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Generic PWM API implementation
On Fri, Nov 13, 2009 at 14:08, Grant Likely wrote: > On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff wrote: >> This series implements a Generic PWM Device API, including reference >> implementations for the Atmel PWMC device, an LED device, and an LED >> trigger. It is based on linux-2.6.27. > [...] >> The implementation of the Generic PWM Device API is structurally >> similar to the generic GPIO API, except that the PWM code uses >> platform bus_id strings instead of integers to identify target >> deviices. A configuration structure is also provided, both to >> facilitate atomic hardware state changes and so that the API can be >> extended in a source-code-compatible way to accomodate devices with >> features not anticipated by the current code. > > I'm concerned about the approach taken here. As I understand it, the > PWM signals are very similar to GPIOs in that each PWM device controls > an external signal line, just like GPIO lines. The difference being > that PWMs cannot do input, and has additional capabilities (can be > programmed with a signal; not just on/off/tristate). Actually, many > GPIOs have these properties too. I've got a part with output-only > gpios, and gpio devices that also have a PWM. > > What is the reason for bringing in an entirely new framework instead > of extending the GPIO API or gpiolib? I'm not too excited about > having two entirely different frameworks for what basically boils down > to "numbered signal pins". unifying resource management obviously makes sense so as to avoid conflicts, but i dont think the fact that one pin can be multi purpose means it should be entirely forced into the GPIO framework, nor do i see any real gain for doing so. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
On Mon, Oct 19, 2009 at 21:42, Bill Gatliff wrote:
> Mike Frysinger wrote:
>> On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
>>> #include
>>> +#include
>>
>> if there's going to be a bunch of new pwm related headers, perhaps a
>> subdir makes more sense: linux/pwm/xxx
>
> In general I don't have a problem with this. However, in this specific case
> would it make more sense to just fold pwm-led.h into pwm.h? There really
> isn't much to pwm-led.h.
since pwm-led.h is meant for platform data and for boards to include
it, keeping it separate makes sense to me. and once we start getting
more pwm based drivers that want to do headers of their own, having
linux/pwm/ for them would be nice.
as for the core pwm header, either linux/pwm.h or linux/pwm/pwm.h
would work i think.
>>> +static void
>>> +led_pwm_brightness_set(struct led_classdev *c,
>>> + enum led_brightness b)
>>> +{
>>> + struct led_pwm *led;
>>> + int percent;
>>> +
>>> + percent = (b * 100) / (LED_FULL - LED_OFF);
>>> + led = container_of(c, struct led_pwm, led);
>>
>> instead of using container_of() everywhere, why not add a helper macro
>> that turns a led_classev into a led_pwm
>
> That's just a personal style thing. As soon as I write a helper macro, I
> tend to forget how it works and then start mis-using it everywhere. But I
> don't have a problem with doing a helper.
>
> For better type-safety, would a helper inline-function be a better choice
> than a helper macro? Or would it make any difference?
an inline function might be better. it would also allow you to pass
in void* pointers though ...
>>> + if (!try_module_get(d->driver->owner))
>>> + return -ENODEV;
>>
>> is this really needed ?
>
> Not sure.
after looking at the other patches, i dont think it is. the core pwm
framework does the module_get for you when you register the driver.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
> --- /dev/null
> +++ b/drivers/pwm/atmel-pwm.c
> + const struct atmel_pwm *ap
> + = container_of(p->pwm, struct atmel_pwm, pwm);
make a helper ?
> + pr_debug("%s:%d sync_mask %x\n",
> + p->pwm->bus_id, p->chan, ap->sync_mask[p->chan]);
all of the pr_* funcs in this driver should be dev_* funcs
> +static int __init
> +atmel_pwmc_probe(struct platform_device *pdev)
__devinit
> + ap->clk = clk_get(&pdev->dev, "pwm_clk");
> + if (IS_ERR(ap->clk)) {
> + pr_info("%s: clk_get error %ld\n",
> + ap->pwm.bus_id, PTR_ERR(ap->clk));
> + ret = -ENODEV;
> + goto err_clk_get;
shouldnt it be:
ret = PTR_ERR(ap->clk);
> +static struct platform_driver atmel_pwm_driver = {
> + .driver = {
> + .name = "atmel_pwmc",
> + .owner = THIS_MODULE,
> + },
no need for .owner ?
> +static void atmel_pwm_exit(void)
__exit
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 5/5] Incorporate PWM API code into KBuild
On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote: > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -6,6 +6,8 @@ > # > > obj-y += gpio/ > +obj-$(CONFIG_GENERIC_PWM) += pwm/ > + > obj-$(CONFIG_PCI) += pci/ spurious new line > --- /dev/null > +++ b/drivers/pwm/Kconfig > + software controlled power-efficent backlights on LCD efficient > --- /dev/null > +++ b/drivers/pwm/Makefile > @@ -0,0 +1,7 @@ > +# > +# Makefile for pwm devices > +# > +obj-y := pwm.o > + > +obj-$(CONFIG_ATMEL_PWM) += atmel-pwm.o > +obj-$(CONFIG_GPIO_PWM) += gpio.o > \ No newline at end of file there should be a newline at the end of the file -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface
On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
> +A generic PWM device framework must accomodate the substantial
accommodate
> +be accomodated by the Generic PWM Device API framework.
accommodated
> +bus_id -- the plaintext name of the device. Users will bind to a
plain text
> +synchronize, unsynchronize -- (optional) Callbacks to
> +synchronize/unsynchronize channels.
perhaps use desynchronize instead ?
> --- /dev/null
> +++ b/drivers/pwm/pwm.c
> @@ -0,0 +1,692 @@
> +#define DEBUG 99
whoops again
> +int pwm_register(struct pwm_device *pwm)
> +{
> + p = kcalloc(pwm->nchan, sizeof(struct pwm_channel), GFP_KERNEL);
sizeof(*p)
> + pr_info("%s: %d channel%s\n", pwm->bus_id, pwm->nchan,
> + pwm->nchan > 1 ? "s" : "");
dev_info(pwm->dev, )
> +static struct pwm_device *
> +__pwm_find_device(const char *bus_id)
> +{
> + struct pwm_device *p;
> +
> + list_for_each_entry(p, &pwm_device_list, list)
> + {
cuddle that brace
> +struct pwm_channel *
> +pwm_request(const char *bus_id,
> + int chan,
> + const char *requester)
> +{
> + struct pwm_device *p;
> +
> + pr_debug("%s: %s:%d returns %p\n", __func__,
> + bus_id, chan, &p->channels[chan]);
> + pr_debug("%s: %s:%d returns NULL\n",
> +__func__, bus_id, chan);
dev_dbg(p->dev, );
> +void pwm_free(struct pwm_channel *p)
> +{
> + pr_debug("%s: %s:%d free\n",
> + __func__, p->pwm->bus_id, p->chan);
dev_dbg(p->dev, );
> +unsigned long pwm_ns_to_ticks(struct pwm_channel *p,
> + unsigned long nsecs)
> +{
> + unsigned long long ticks;
> +
> + ticks = nsecs;
> + ticks *= p->tick_hz;
> + do_div(ticks, 10);
> + return ticks;
> +}
> +EXPORT_SYMBOL(pwm_ns_to_ticks);
perhaps better as a static inline in the header ?
> +unsigned long pwm_ticks_to_ns(struct pwm_channel *p,
> + unsigned long ticks)
> +{
> + unsigned long long ns;
> +
> + if (!p->tick_hz)
> + return 0;
> +
> + ns = ticks;
> + ns *= 10UL;
> + do_div(ns, p->tick_hz);
> + return ns;
> +}
> +EXPORT_SYMBOL(pwm_ticks_to_ns);
this one too
> +static void
> +pwm_config_percent_to_ticks(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + if (c->config_mask & PWM_CONFIG_DUTY_PERCENT) {
> + if (c->config_mask & PWM_CONFIG_PERIOD_TICKS)
> + c->duty_ticks = c->period_ticks;
> + else
> + c->duty_ticks = p->period_ticks;
> +
> + c->duty_ticks *= c->duty_percent;
> + c->duty_ticks /= 100;
> + c->config_mask &= ~PWM_CONFIG_DUTY_PERCENT;
> + c->config_mask |= PWM_CONFIG_DUTY_TICKS;
> + }
> +}
if you returned when the mask doesnt match, then you wouldnt need to
indent the rest of the func
> +int pwm_config(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + int ret = 0;
> +
> + if (unlikely(!p->pwm->config)) {
> + pr_debug("%s: %s:%d has no config handler (-EINVAL)\n",
> + __func__, p->pwm->bus_id, p->chan);
dev_dbg(p->dev, );
> + switch (c->config_mask & (PWM_CONFIG_PERIOD_TICKS
> + | PWM_CONFIG_DUTY_TICKS)) {
> + case PWM_CONFIG_PERIOD_TICKS:
> + if (p->duty_ticks > c->period_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
> + case PWM_CONFIG_DUTY_TICKS:
> + if (p->period_ticks < c->duty_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
> + case PWM_CONFIG_DUTY_TICKS | PWM_CONFIG_PERIOD_TICKS:
> + if (c->duty_ticks > c->period_ticks) {
> + ret = -EINVAL;
> + goto err;
> + }
> + break;
unless i missed something, the first and third case is the same. so
probably better (compiled code wise) to write an if statement.
> + pr_debug("%s: config_mask %d period_ticks %lu duty_ticks %lu"
> + " polarity %d duty_ns %lu period_ns %lu duty_percent %d\n",
> + __func__, c->config_mask, c->period_ticks, c->duty_ticks,
> + c->polarity, c->duty_ns, c->period_ns, c->duty_percent);
dev_dbg(p->dev, );
> +int pwm_set_period_ns(struct pwm_channel *p,
> + unsigned long period_ns)
> +unsigned long pwm_get_period_ns(struct pwm_channel *p)
> +int pwm_set_duty_ns(struct pwm_channel *p,
> + unsigned long duty_ns)
> +unsigned long pwm_get_duty_ns(struct pwm_channel *p)
> +int pwm_set_duty_percent(struct pwm_channel *p,
> + int percent)
> +int
Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
> --- /dev/null
> +++ b/drivers/pwm/gpio.c
> @@ -0,0 +1,318 @@
> +#define DEBUG 99
whoops
> + pr_debug("%s:%d start, %lu ticks\n",
> + dev_name(p->pwm->dev), p->chan, p->duty_ticks);
you already have a struct device, so this is just odd. use dev_dbg()
instead and let it worry about dev_name() stuff. plus you're already
using dev_dbg() in the rest of the code, so i guess you just forgot
about this.
> + case PWM_CONFIG_START:
> + if (!hrtimer_active(&gp->t)) {
> + gpio_pwm_start(p);
> + }
dont really need those braces
> + struct gpio_pwm *gp = container_of(p->pwm, struct gpio_pwm, pwm);
helper macro for this ?
> +static int
> +gpio_pwm_config(struct pwm_channel *p,
> + struct pwm_channel_config *c)
> +{
> + struct gpio_pwm *gp = container_of(p->pwm, struct gpio_pwm, pwm);
> + int was_on = 0;
> +
> + if (p->pwm->config_nosleep) {
> + if (!p->pwm->config_nosleep(p, c))
> + return 0;
> + }
> +
> + might_sleep();
shouldnt this be above the config_n
> +static int __init
> +gpio_pwm_probe(struct platform_device *pdev)
__devinit
> +static struct platform_driver gpio_pwm_driver = {
> + .driver = {
> + .name = "gpio_pwm",
> + .owner = THIS_MODULE,
> + },
dont need the explicit .owner ?
> +static void gpio_pwm_exit(void)
__exit
> +MODULE_DESCRIPTION("PWM output using GPIO and an itimer");
itimer -> hrtimer ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
On Mon, Oct 19, 2009 at 16:32, Bill Gatliff wrote:
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -1,153 +1,167 @@
> -/*
> - * linux/drivers/leds-pwm.c
> - *
> - * simple PWM based LED control
> - *
> - * Copyright 2009 Luotao Fu @ Pengutronix (l...@pengutronix.de)
> - *
> - * based on leds-gpio.c by Raphael Assenat
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
this should not be removed. if you wanted to add your copyright line,
then that's fine, but the rest needs to stay.
> #include
> +#include
if there's going to be a bunch of new pwm related headers, perhaps a
subdir makes more sense: linux/pwm/xxx
> +static void
> +led_pwm_brightness_set(struct led_classdev *c,
> + enum led_brightness b)
> +{
> + struct led_pwm *led;
> + int percent;
> +
> + percent = (b * 100) / (LED_FULL - LED_OFF);
> + led = container_of(c, struct led_pwm, led);
instead of using container_of() everywhere, why not add a helper macro
that turns a led_classev into a led_pwm
> +static int __init
> +led_pwm_probe(struct platform_device *pdev)
probe functions are typical __devinit
> + if (!try_module_get(d->driver->owner))
> + return -ENODEV;
is this really needed ?
> -static int __devexit led_pwm_remove(struct platform_device *pdev)
> +static int
> +led_pwm_remove(struct platform_device *pdev)
looks like you lost the __devexit markings
> static struct platform_driver led_pwm_driver = {
> + .driver = {
> + .name = "leds-pwm",
> + .owner = THIS_MODULE,
> },
i dont think platform_drivers need to explicitly set their owner. i
thought that was all handled for you.
> --- /dev/null
> +++ b/include/linux/pwm-led.h
> @@ -0,0 +1,34 @@
> +#ifndef __LINUX_PWM_LED_H
> +#define __LINUX_PWM_LED_H
> +
> +/*
> + * include/linux/pwm-led.h
the ifdef protection typically goes after the header comment blob, not before
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] printk: provide a filtering macro for printk
On Wed, Sep 2, 2009 at 08:44, Marc Andre Tanner wrote:
> On Wed, Sep 02, 2009 at 07:25:43AM -0500, Bill Gatliff wrote:
>> Jamie Lokier wrote:
>> >Looks good, except that I think kernel style is to use "do {...} while
>> >(0)" rather than "({ ... })"
>>
>> And IIRC, there was some reason for the do{...} while(0) that made
>> other alternatives not work. So it might be more than just style at
>> issue.
>
> Do you remember the reason? I found the oposite to be ture, I actually
> started with the do { } while(0) construct but it failed in certain
> situations so I wrapped it with ({ }) and then later removed
> the now useless do { } while(0).
>
> By the way printk_once which is defined a few lines further down in
> kernel.h also uses ({ }).
>
> Anyway the next version of my patch will no longer need it.
it depends completely on how the macro is intended to be used. if you
want to maintain the "this macro has a return value", then you have to
use ({...}). if you want the macro to return a void, then you have to
use do{...}while(0).
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Wed, Sep 2, 2009 at 05:47, Marc Andre Tanner wrote:
> On Wed, Sep 02, 2009 at 05:11:12AM -0400, Mike Frysinger wrote:
>> On Wed, Sep 2, 2009 at 04:57, Marc Andre Tanner wrote:
>> > On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote:
>> >> On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote:
>> >> > This series adds a configuration option to selectively compile out
>> >> > printk message strings based on a verbosity level.
>> >> >
>> >> > This works by wrapping printk with a macro which evaluates to a
>> >> > constant if condition which the compiler will be able to optimize
>> >> > out.
>> >> >
>> >> > However because printk might be wrapped by a macro it no longer has
>> >> > a return value. This means that constructs like the following ones
>> >> > don't work:
>> >> >
>> >> > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...));
>> >> >
>> >> > some_random_variable = printk(...);
>> >> >
>> >> > Therefore printk_unfiltered is introduced which is just an alias
>> >> > to the standard printk function but not wrapped by a macro.
>> >>
>> >> why dont you return 0 if it gets optimized away ? then you wont have
>> >> to screw with external code at all and things "just work".
>> >
>> > This won't work because it would for example also return from functions
>> > which call printk but aren't checking for the return value (which is
>> > the common case).
>>
>> why would it matter ?
>>
>> ({
>> int __printk_ret = 0;
>> if (crazy stuff you're adding)
>> __printk_ret = printk(.);
>> __printk_ret;
>> })
>
> Yes I missunderstood your "return 0" statement in the first mail.
> The same effect could also be achieved by:
>
> ((crazy stuff) ? printk(...) : 0;
while true, i thought your (crazy stuff) pretty verbose and the
tertiary operator might get swallowed in the noise. not that it
matters that much to me as this is now a pure style choice ... your
patch, you pick.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Wed, Sep 2, 2009 at 04:57, Marc Andre Tanner wrote:
> On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote:
>> On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote:
>> > This series adds a configuration option to selectively compile out
>> > printk message strings based on a verbosity level.
>> >
>> > This works by wrapping printk with a macro which evaluates to a
>> > constant if condition which the compiler will be able to optimize
>> > out.
>> >
>> > However because printk might be wrapped by a macro it no longer has
>> > a return value. This means that constructs like the following ones
>> > don't work:
>> >
>> > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...));
>> >
>> > some_random_variable = printk(...);
>> >
>> > Therefore printk_unfiltered is introduced which is just an alias
>> > to the standard printk function but not wrapped by a macro.
>>
>> why dont you return 0 if it gets optimized away ? then you wont have
>> to screw with external code at all and things "just work".
>
> This won't work because it would for example also return from functions
> which call printk but aren't checking for the return value (which is
> the common case).
why would it matter ?
({
int __printk_ret = 0;
if (crazy stuff you're adding)
__printk_ret = printk(.);
__printk_ret;
})
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote: > This series adds a configuration option to selectively compile out > printk message strings based on a verbosity level. > > This works by wrapping printk with a macro which evaluates to a > constant if condition which the compiler will be able to optimize > out. > > However because printk might be wrapped by a macro it no longer has > a return value. This means that constructs like the following ones > don't work: > > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...)); > > some_random_variable = printk(...); > > Therefore printk_unfiltered is introduced which is just an alias > to the standard printk function but not wrapped by a macro. why dont you return 0 if it gets optimized away ? then you wont have to screw with external code at all and things "just work". -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel crashing and log buffers...
On Fri, Jun 26, 2009 at 13:42, David VomLehn wrote: > On Fri, Jun 26, 2009 at 10:39:50AM -0400, Robin Getz wrote: >> OK - so after a bit more digging into things (and a poke by Mike) - I think >> most of the stuff already exists. >> >> Normal run time issues: >> -- >> - MTD_OOPS - on 2007-06-28 this was added to Linus's tree: >> http://lkml.org/lkml/2007/6/18/234 >> CONFIG_MTD_OOPS >> tristate "Log panic/oops to an MTD buffer" > ... >> early boot issues: >> -- >> - CONFIG_EARLY_PRINTK >> - early printk just defined a console - and is supported by: >> alpha, blackfin, microblaze, mips, powerpc, sh, x86 >> - it's pretty trivial to support a memory based buffer - some >> archs already support it. >> >> I think this only leaves Wolfgang's desire for memory buffers from the >> bootloader to get (somehow) into the kernel's log buffer for syslog >> processing... >> >> Anyone else agree? > > Almost. A couple of us also want memory for "flight data record" FDR data > for doing continuous logging. This would, ideally, be either uncached or > cached > in such a way that data is guaranteed to be written to memory in the event of > a watchdog timer-induced system reset. can none of the existing mtd devices provide uncached ram ? otherwise, create a mtd map that simply calls data flush after every write. then the existing mtd stack can provide what you want. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] Pramfs: Write Protection
On Wed, Jun 17, 2009 at 12:58, Marco wrote: > Jared Hulbert wrote: >> > > +#if defined(CONFIG_ARM) || defined(CONFIG_M68K) || >> > > defined(CONFIG_H8300) || \ >> > > + ? ? ? defined(CONFIG_BLACKFIN) >> > > + ? ? ? /* >> > > + ? ? ? ?* FIXME: so far only these archs have flush_tlb_kernel_page(), >> > > + ? ? ? ?* for the rest just use flush_tlb_kernel_range(). Not ideal >> > > + ? ? ? ?* to use _range() because many archs just flush the whole TLB. >> > > + ? ? ? ?*/ >> > > + ? ? ? if (end <= start + PAGE_SIZE) >> > > + ? ? ? ? ? ? ? flush_tlb_kernel_page(start); >> > > + ? ? ? else >> > > +#endif >> > > + ? ? ? ? ? ? ? flush_tlb_kernel_range(start, end); >> > > +} >> > >> > Why not just fix flush_tlb_range()? >> > >> > If an arch has a flush_tlb_kernel_page() that works then it stands to >> > reason that the flush_tlb_kernel_range() shouldn't work with minimal >> > effort, no? >> >> flush_tlb_kernel_page() is a new one to me, it doesn't have any mention >> in Documentation/cachetlb.txt anyways. >> >> Many of the flush_tlb_kernel_range() implementations do ranged checks >> with tunables to determine whether it is more expensive to selectively >> flush vs just blowing the entire TLB away. >> >> Likewise, there is no reason why those 4 architectures can not just shove >> that if (end <= start + PAGE_SIZE) check in the beginning of their >> flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for >> those cases. Hiding this in generic code is definitely not the way to go. > > Ok I'll change that function at arch level and I'll remove the ifdef, I'll > call only flush_tlb_kernel_page(), but I'd like to know what is the opinion > of the arch maintainers to do that. considering Blackfin defines flush_tlb_kernel_page() to BUG(), i dont think we care what happens. we dont have a MMU, so all tlb funcs -> BUG(). presumably this code shouldnt have been compiled in the first place for us. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote: > James Bottomley wrote: >> We've got to the point where there are simply too many embedded >> architectures to invite all the arch maintainers to the kernel summit. >> So, this year, we thought we'd do embedded via topic driven invitations >> instead. So what we're looking for is a proposal to discuss the issues >> most affecting embedded architectures, or preview any features affecting >> the main kernel which embedded architectures might need ... or any other >> topics from embedded architectures which might need discussion or >> debate. > > Another issue that affects embedded architectures is drivers initialization > order. There are a lot of cases when you need the drivers to be initialized in > particular order, and current initcalls scheme does not allow fine grained > control for it. example: device configuration information stored in i2c eeprom (i.e. dimensions of attached framebuffer), but i2c is not available when framebuffer layer is setup. framebuffer driver has to be built as a module and loaded by userspace, or i2c information is read by bootloader and passed down to the kernel. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel crashing and log buffers...
On Thu, Jun 11, 2009 at 13:53, David VomLehn wrote: > On Wed, Jun 10, 2009 at 09:26:40PM -0400, Robin Getz wrote: >> On 17 Oct 2007, after much discussion and debate, Mike added add two new >> functions for reading the kernel log buffer (from kernel space). >> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0b15d04af3dd996035d8fa81fc849d049171f9c3 >> >> The intention was for them to be used by recovery/dump/debug code so the >> kernel log can be easily retrieved/parsed by the bootloader (or another >> kernel) in a crash scenario. >> >> I was going to push the arch specific recovery/dump/debug code that uses them >> upstream (yeah, it has been a little while - but anyway...) it was removed >> since then by Roel Kluin ... >> >> 21 Oct 2008: >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=acff181d3574244e651913df77332e897b88bff4 >> >> Before I ask Andrew to add it back, I thought I would make sure it was still >> a >> useful function, and did everything everyone wanted - and wasn't deemed >> unnecessary by a feature/function that I wasn't aware of - like the next >> thing... >> >> I saw the patch Grant sent recently - Add Alternative Log Buffer Support for >> printk Messages (in Nov2008 to the embedded list, and Jan 2009 to lkml) - but >> I couldn't find any followups - and it doesn't seem to be in Linus's tree. >> >> http://thread.gmane.org/gmane.linux.kernel.embedded/1358/focus=1373 >> >> http://lkml.org/lkml/2009/1/21/250 >> >> I can see the desire on Wolfgang & Grant's part - for not needing the copy >> from/to - (you never have to worry about crashing "nicely" - the kernel >> panics, but you still need to copy memory around - potentially causing all >> kinds of secondary issues - and masking the real reason the crash occurred). >> >> But for the majority of the case - the copy from/to would work much better >> than what we have in mainstream today... >> >> >> I would be interested in Paul and Russell - how have you solved this issue? >> (Or do your kernel's never crash? :) > > Our kernel does crash, so we have to do this. I had submitted a patch a > while ago that tweaks emit_log_char, but this was bounced, reasonably, > because it would be interferring with the great majority of people who > are not interested in capturing log output. The suggestion was made that > we do this with a console driver. I've recently got a version working, as > a module, but I've only started testing of the version integrated into the > kernel tree. Still, post early, post often, so I've appended a version > of the patch here to see if this seems to be the right direction. i guess there's two distinct crash types: early and late. your console driver seems like it should be able to handle the "late" variety ok (i.e. the kernel is up and running and at some point, it blows up). but it doesnt address the early crashes which is what we're currently looking for (i.e. kernel crash occurs before the serial console is up and running). i think extending this driver to include early printk support should address that ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Wed, Jun 3, 2009 at 23:11, David VomLehn (dvomlehn) wrote: > David Delaney has a proof-of-concept of an idea of his which was > presented at the last CELF, which is basically to put the kernel and > loadable kernel modules closely enough together that you can avoid the > use of long jumps. He sees a better than 1% improvement in performance, > which we've duplicated using a slightly different approach. This is nice > payback for little work and, though it doesn't help on all processors, > it helps on several. it would help on the Blackfin architecture. we compile all kernel modules with -mlong-call because of this issue. > The problem is: how do you allocate memory with the magical "close to > the kernel" attribute? We have something that adds a new ZONE_KERNEL > (this name has some problems, actually). It seems like a pretty good > solution if you look at zones as conceptually concentric usages, but > with the current zone implementation, each zone must be contiguous. So, > if we're talking about changing what zones are done, I'd like to throw > this into the pot. what do you do if the alloc fails ? return back to userspace with something like ENOMEM and have it retry with a module that was compiled with -mlong-call ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sources of entropy?
On Thu, Apr 2, 2009 at 07:45, Nicholas Mc Guire wrote: > On Tue, 24 Mar 2009, Robin Getz wrote: >> I'm just wondering what people using on standard embedded/headless/diskless >> targets (which do not have hw random number generators) as a source of >> entropy - since networking was removed as an entropy source circa 2.6.26 > > without claiming that this is actually usable at this point but a simple > source of entropy that looks quite good is simply to use the timer-counter/TSC > or what ever available. The attached trng.c has been tested on a few X86 > systems and produces remarkably good random numbers - this might be suitable > if you have no other sources available. unfortunately on Blackfin parts, the TSC (we call it "CYCLES" as that is the actual register name) is writable from userspace i have used this in the bootloader as a simple way of getting a little bit of entropy, but then i found that our system is too reliable in booting -- it tends to take the exact same amount of time to boot to a prompt -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ramfs/tmpfs for application partition
On Thu, Jan 15, 2009 at 11:43, Jacob Avraham wrote: > I have a system with 128M RAM and a flash partitioned so that 10M is > dedicated to initramfs image, > 6M to application partition. And another 6M for JFFS2. > As I have plenty of RAM, I'd like to have my application directory mounted on > RAM, from a pre-populated > filesystem that resides in the 6M application partition. > So basically I want to use the same mechanism as initramfs, but mounted on > /my/app/partition instead of root. > Does it make sense? How do I go about and do that? `mount -t tmpfs tmpfs /my/app/partition` ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 4, 2009 at 05:23, Leon Woestenberg wrote: > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt wrote: >> Let's look at the rationale presented so far in this thread: >> >>2 - Cross-compiling perl is hard. > > 2 is not hard. i dont know where you're getting this mythical version of perl, but anything beyond micro-perl is a pita. and micro-perl is practically worthless. maybe for kernel/ -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote: > This merges support for the previously DENX-only kernel feature of > specifying an alternative, "external" buffer for kernel printk > messages and their associated metadata. In addition, this ports > architecture support for this feature from arch/ppc to arch/powerpc. > > Signed-off-by: Grant Erickson <[EMAIL PROTECTED]> > --- > > When this option is enabled, an architecture- or machine-specific log > buffer is used for all printk messages. This allows entities such as > boot loaders (e.g. U-Boot) to place printk-compatible messages into > this buffer and for the kernel to coalesce them with its normal > messages. > this extended info should be part of the changelog and thus above the --- marker ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: make mdio-gpio work without OF (v2)
On Wed, Nov 5, 2008 at 03:11, David Brownell wrote: > On Tuesday 04 November 2008, Mike Frysinger wrote: >> > If indeed OF functions don't have declarations which are >> > available on all platforms, that might be worth fixing >> > to enable this approach to #ifdef elimination. >> >> OF is open firmware right ? no way there's going to be OF for every >> port that supports GPIO, so filling out the stubs in linux/of_gpio.h >> will need to be done. > > In which case the boolean "we don't have OF" would be "false" and > any code referencing the declared functions would be compiled out > (being dead code/data). So there would be no link-time references > to any OF routines... standard technique. i understand the compiler side just fine. my point is that the current linux/of_gpio.h only defines the OF structure and related prototypes when CONFIG_OF_GPIO is defined. so it needs updating first. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: make mdio-gpio work without OF (v2)
On Tue, Nov 4, 2008 at 23:45, David Brownell wrote: > On Tuesday 04 November 2008, Mike Frysinger wrote: >> > That's generally the preferred way to handle #ifdeffery. >> > But I could imagine OF isn't (yet?) set up to handle it. >> >> i agree completely with the inclination to do it all in C as you've >> suggested and let the compiler do dead code elimination, but that only >> works if the functions in question are defined everywhere (in other >> words, there's a linux/ api for it). i dont think that's the case for >> OF (which is what you were implying?) ... > > Only works if the functions are "declared" everywhere; > the stuff that's included in header files. > > A "definition" would be available at link time (except > for inlined functions, in headers). Actual C functions. > > If indeed OF functions don't have declarations which are > available on all platforms, that might be worth fixing > to enable this approach to #ifdef elimination. OF is open firmware right ? no way there's going to be OF for every port that supports GPIO, so filling out the stubs in linux/of_gpio.h will need to be done. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] [PWM] Generic PWM API implementation
On Tue, Nov 4, 2008 at 18:55, David Brownell wrote: > On Tuesday 04 November 2008, Bill Gatliff wrote: >> So, what's the next step? How do I advocate for getting >> this API into mainline? > > The number of backing implementations seemed a bit low ... > just one. And that's switching Atmel's dedicated PWM, but > not the other PWM driver in the tree (for PXA); so it's > not terrifically accessible. > > My rule of thumb is that it's not worth considering a > framework as being general enough until it's got three > fairly different backing implementations. Two is enough > to consider merging, especially with complicated drivers. every Blackfin processor so far has had dedicated PWM hardware in it, so a backend driver for that arch would show up ... > Plus the number of framework users is an issue. The > PWM led driver is a good demo for two basic features, > and it's useful: brightness (duty cycle beyond visual > perception) and blink rate (duty cycle easily seen with > the eye). But it's still only really one API customer, > even given that new LED trigger... there is an lcd driver or two in the tree (probably Blackfin specific) that uses the PWM hardware as an output to drive the hsync/vsync signals. and while LIRC is still out-of-tree for mainline, i wrote a driver using the PWM hardware as an input ... but there wasnt anything else Blackfin specific in said driver other than the PWM stuff ... i'm guessing you'd prefer to see those implemented before moving to mainline though ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: make mdio-gpio work without OF (v2)
On Tue, Nov 4, 2008 at 19:04, David Brownell wrote:
> On Tuesday 04 November 2008, Grant Likely wrote:
>> At this point, instead of #ifdeffing the function signature, I would
>> much rather see this generalized as something like
>> 'mdio_gpio_setup()'. Then move the OF and non-OF specific bits into
>> two new functions; mdio_ofgpio_probe() and mdio_gpio_probe(). The two
>> new functions should be placed with the appropriate bus binding in the
>> #ifdef/#else block at the bottom of the file.
>
> Or if possible something that creates a single #ifdef that
> ensures dead code elimination will remove the "other" branch,
> but ensures all platforms will build both versions:
>
>#ifdef OF
>#define using_oftrue
>#else
>#define using_offalse
>#endif
>
>...
>
>static int __init mdio_gpio_init(void)
>{
>if (using_of)
>return register mdio_ofgpio driver;
>else
>return register mdio_gpio driver;
>}
>subsys_initcall(mdio_gpio_init);
>
>...
>
> That's generally the preferred way to handle #ifdeffery.
> But I could imagine OF isn't (yet?) set up to handle it.
i agree completely with the inclination to do it all in C as you've
suggested and let the compiler do dead code elimination, but that only
works if the functions in question are defined everywhere (in other
words, there's a linux/ api for it). i dont think that's the case for
OF (which is what you were implying?) ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] [PWM] Generic PWM API implementation
On Tue, Nov 4, 2008 at 15:16, Bill Gatliff wrote:
> Mike Frysinger wrote:
>> On Wed, Oct 15, 2008 at 14:14, Bill Gatliff wrote:
>>> +int pwm_register(struct pwm_device *pwm)
>>> +{
>>> + struct pwm_channel *p;
>>> + int wchan;
>>> + int ret = 0;
>>
>> the initialization to 0 here isnt needed
>
> This is literally the only feedback I have received. I take that to mean that
> the code basically works as advertised, and nobody else has any problems with
> it
> (it continues to work fine for me here).
>
> So, what's the next step? How do I advocate for getting this API into
> mainline?
you looking to be maintainer ? if so, i imagine you start a git tree
(on kernel.org?) for people to pull from, post patches to mainline now
and indicate you'd ask for a 2.6.29 merge ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] phylib: make mdio-gpio work without OF
On Fri, Oct 31, 2008 at 12:49, Paulius Zaleckas wrote: > +#ifndef NO_IRQ > +#define NO_IRQ 0 > +#endif discussions elsewhere indicate this should die. -if (irq != NO_IRQ) +if (irq) -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: add mdio-gpio bus driver (v3)
On Tue, Oct 28, 2008 at 06:35, Paulius Zaleckas wrote: > +config MDIO_GPIO > + tristate "Support for GPIO bitbanged MDIO buses" > config MDIO_OF_GPIO >tristate "Support for GPIO lib-based bitbanged MDIO buses" seems to me these drivers have the same description ... > +++ b/include/linux/mdio-gpio.h > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA this is why short GPL notices are nice ... you dont end up with outdated contact information like this ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: add mdio-gpio bus driver (v2)
On Tue, Oct 28, 2008 at 04:30, Paulius Zaleckas wrote: > Mike Frysinger wrote: >> On Mon, Oct 27, 2008 at 06:53, Paulius Zaleckas wrote: >>> + if (gpio_request(bitbang->mdc, "mdc")) >>> + goto out_free_bitbang; >>> + >>> + if (gpio_request(bitbang->mdio, "mdio")) >>> + goto out_free_mdc; >> >> maybe include driver name and/or the platform id ? if you have >> multiple mdio-gpio's running at the same time, coordinating may get a >> little messy ... > > Well... this is mostly for debugging only... I don't like the idea > to add additional char[..] variable and use sprintf... > IMO this would be just a bloat... if realistically you'd only run one instance of this driver on a platform, then it'll probably be fine >>> + new_bus->name = "GPIO Bitbanged MII", >> >> platform id here too ? > > If you take a look one line below you would see that bus ID is formed > using platform id. Does this really need to be duplicated also in the > name? i guess if you can divine the differences from a populated /sys directory, it should be ok as well -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: add mdio-gpio bus driver (v2)
On Tue, Oct 28, 2008 at 03:37, Paulius Zaleckas wrote: > Mike Frysinger wrote: >> On Mon, Oct 27, 2008 at 06:53, Paulius Zaleckas wrote: >>> + new_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL); >> >> oh, and this should be kcalloc() > > Why? kcalloc() fills allocated memory with zeros and in this case it has > to be filled with -1... this is done by further for() routine. I don't > see the point to fill it with zeros before... i thought it was a call to kzalloc(). kcalloc() is better for arrays, but if you dont need the memory zero-ed first, it's a hard sell of proper style vs wasted performance. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: add mdio-gpio bus driver (v2)
On Mon, Oct 27, 2008 at 06:53, Paulius Zaleckas wrote: > + new_bus->irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL); oh, and this should be kcalloc() -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phylib: add mdio-gpio bus driver (v2)
On Mon, Oct 27, 2008 at 06:53, Paulius Zaleckas wrote:
> +config MDIO_GPIO
> + tristate "Support for GPIO bitbanged MDIO buses"
> + depends on MDIO_BITBANG && GENERIC_GPIO
> + help
> + Supports MDIO busses connected to GPIO.
please add a line stating the name of the module if it is built as such
> +static struct mdiobb_ops mdio_gpio_ops = {
> + .owner = THIS_MODULE,
> + .set_mdc = mdc,
> + .set_mdio_dir = mdio_dir,
> + .set_mdio_data = mdio,
> + .get_mdio_data = mdio_read,
> +};
shouldnt the function names match the gpio_ops ? things like "mdc"
and "mdio" are a little obscure ...
> +static int __devinit mdio_gpio_probe(struct platform_device *pdev)
> +{
> + struct mii_bus *new_bus;
> + struct mdio_gpio_info *bitbang;
> + struct mdio_gpio_platform_data *pdata;
> + int ret = -ENOMEM;
> + int i;
> +
> + pdata = pdev->dev.platform_data;
> + if (pdata == NULL)
> + goto out;
> +
> + bitbang = kzalloc(sizeof(struct mdio_gpio_info), GFP_KERNEL);
sizeof(*bitbang) tends to read better and be more resistant to bitrot
> + if (gpio_request(bitbang->mdc, "mdc"))
> + goto out_free_bitbang;
> +
> + if (gpio_request(bitbang->mdio, "mdio"))
> + goto out_free_mdc;
maybe include driver name and/or the platform id ? if you have
multiple mdio-gpio's running at the same time, coordinating may get a
little messy ...
> + new_bus->name = "GPIO Bitbanged MII",
platform id here too ?
> +static int mdio_gpio_init(void)
> +{
> + return platform_driver_register(&mdio_gpio_driver);
> +}
needs __init markings
> +static void mdio_gpio_exit(void)
> +{
> + platform_driver_unregister(&mdio_gpio_driver);
> +}
needs __exit markings
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] [PWM] Generic PWM API implementation
On Wed, Oct 15, 2008 at 14:14, Bill Gatliff wrote:
> +int pwm_register(struct pwm_device *pwm)
> +{
> + struct pwm_channel *p;
> + int wchan;
> + int ret = 0;
the initialization to 0 here isnt needed
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Thu, Oct 9, 2008 at 00:18, Bill Gatliff wrote: > Mike Frysinger wrote: >> if you'd seriously play with a Blackfin board, i think we can arrange that > > I'd seriously *love* to play with one, but I'm pretty strapped for time for > another couple of months. The only purpose it would serve near-term would be > to > prove out the input capabilities of a device that I probably wouldn't have > time > to write a driver for. :( i'll probably look at the Blackfin-pwm core soonish ... we already implemented a generic framework for it (look for "gptimers"), so it shouldnt take too much time to transition code for it. >> while true, hardware that can support PWM as both input/output would >> suffer from two frameworks. if there's ambiguity in behavior (using >> "get" in an output mode), then we can just stick it in the >> documentation and move on. the GPIO framework already has this >> behavior (set a pin to output and then try and read the data) and i >> dont recall it ever being an issue there. > > Good point. I think I'm sold on the idea now. > > We'd need a PWM_CONFIG_ to tell the hardware to switch to > "measurement mode" if such a mode is supported (suggestions for > welcomed). The config function would return an error if the measurement mode > wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, > perhaps? only part on Kconfig i think we'll need is each implementation selecting "GENERIC_PWM_INPUT" and "GENERIC_PWM_OUTPUT". are we looking towards having multiple master implementations being usable simultaneously ? otherwise, i dont think defining things in terms of "generating" and "measuring" is really needed ... "input" and "output" seems straightforward enough. > In output mode, the pwm_get_*() methods would return the driven values if the > device didn't support a (simultaneous) measurement mode, or cached values if > the > device's configuration registers were write-only. In measurement mode, they'd > return the measured values. the current generic core looks like it could handle this easily enough since we're working with an array of function pointers. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 23:46, Bill Gatliff wrote: > Mike Frysinger wrote: >>> Are you proposing that the API accommodate both input and output devices? >> >> i dont think we should preclude it from the outset. > > I don't think have a problem with that. At some point, I would need someone > with input/output hardware to test the input-specific parts, however. Hint, > hint. ;) if you'd seriously play with a Blackfin board, i think we can arrange that >> not really, but i see the existing code you've posted could already >> utilize some of the "get" functions ... > > Which parts? I don't really like keeping the period_ticks and duty_ticks > values > around, but in my case I have no choice--- unless I were to read the CPRE, > CPRD > and CDTY values from the hardware directly. Which could be what your proposed > "get" methods would do. sorry, i misread the led driver. too many structures! :) > But that still isn't PWM "input" the way you are describing, because my > hardware > wouldn't be _reading_ an incoming PWM: it would be just reporting back the > values that it was using to produce its output signal. Huge difference. > > I dunno, I'm still not sure that measuring the characteristics of an incoming > PWM signal isn't a different kind of device from one that produces PWM > signals, > at least conceptually. Which, in a way, makes it out of scope for the > proposed > API. Not saying I can't go along with the idea, I'm just not sure what a user > would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC > device. They certainly aren't going to get a measured value in return! while true, hardware that can support PWM as both input/output would suffer from two frameworks. if there's ambiguity in behavior (using "get" in an output mode), then we can just stick it in the documentation and move on. the GPIO framework already has this behavior (set a pin to output and then try and read the data) and i dont recall it ever being an issue there. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 22:23, Bill Gatliff wrote: > Mike Frysinger wrote: >> On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote: >>> This series proposes a "generic PWM" driver API. >> >> seems that the API is solely geared to handle PWM as an output signal. > > True. The peripherals I'm currently targeting are output-only devices, and > the > API reflects that. > >> what about input ? > > Well, the SAM9263 has timer/counters that could be used to measure PWM period > and duty cycle. But they are a different peripheral entirely. I haven't done > an exhaustive survey, but I'm not aware of any PWM-generating hardware that is > simultaneously PWM-measuring hardware as well. Seems like they are either one > or the other. the Blackfin timers/pwm's can flip between input and ouput based on the configuration register. everything else (pin/etc...) is unchanged. > Are you proposing that the API accommodate both input and output devices? i dont think we should preclude it from the outset. >> all the utility config functions lack "set" in their name. it's a >> little confusing as to whether the function is a get or set at first >> glance. rather than expecting drivers to poke directly into the >> structure, a set of "get" functions would work better (even if they're >> simply #define's that poke into the structure) and line up better with >> how the GPIO framework operates. > > Good point. > > Originally, I was thinking along the lines of a set-and-forget use case. Do > you > use "get" functionality much when generating PWM signals in your applications? not really, but i see the existing code you've posted could already utilize some of the "get" functions ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote: > This series proposes a "generic PWM" driver API. seems that the API is solely geared to handle PWM as an output signal. what about input ? all the utility config functions lack "set" in their name. it's a little confusing as to whether the function is a get or set at first glance. rather than expecting drivers to poke directly into the structure, a set of "get" functions would work better (even if they're simply #define's that poke into the structure) and line up better with how the GPIO framework operates. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PRAMFS with XIP support
On Tue, Oct 7, 2008 at 05:14, Marco Stornelli wrote: > I enjoyed to make a porting of pramfs to the kernel 2.6.26.5. In > addition, I made a patch to add execute-in-place support. You can > download the patches from the project site under "tracker/patches". If > you have comments and/or suggestions you can write to me an email :). why not submit it for inclusion to lkml ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local_save_flags(flags)
On Tue, Sep 23, 2008 at 21:15, Fundu wrote: >>> what about Non maskable interrupts ? disabling >>> interrupt won't have any effect on that right ? >> >> that really doesnt make sense by definition huh. >> non-maskable means >> they cant be masked. > > yeah thats the point. i should have elaborated more. > then there's no guarantee that your code wont be interrupted ? design your system properly and it wont be an issue > typically what NMI interrupt does a embedded system have ? it depends on the processor and the kernel configuration. i can tell you about the Blackfin processor, but i doubt you're using that. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local_save_flags(flags)
On Tue, Sep 23, 2008 at 16:01, Fundu wrote: >> > 2) so is disable interrupts twice is a problem, or just >> enabling them after they are disabled (which sounds like >> how it should be) a problem. >> >> both are a problem. the non-state saving version cannot be >> used >> recursively nor in parallel to the state-saving version. > > Much clear now, Thanks Mike! > > here's a follow up question. > > what about Non maskable interrupts ? disabling interrupt won't have any > effect on that right ? that really doesnt make sense by definition huh. non-maskable means they cant be masked. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge linuxppc-embedded with linuxppc-dev
On Mon, Sep 22, 2008 at 18:08, Grant Likely <[EMAIL PROTECTED]> wrote: > Jeremy, > > Can we eliminate the linuxppc-embedded mailing list and merge it with > linuxppc-dev? I don't think we need two separate lists anymore and > patches to linuxppc-embedded don't always get dealt with. > > Anyone have any objections to eliminating linuxppc-embedded? you sent this e-mail to "linux-embedded" instead of "linuxppc-embedded" -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local_save_flags(flags)
On Thu, Sep 18, 2008 at 18:45, Fundu wrote: >> that book explicitly covers your question. read chapter 2 >> where it >> covers these irq functions. > > as i said i'm reading the book and actully i did read that chapter. > > for me, here's the exact line that needs clarification, > In chapter 2, page 42 last paragraph(starts with "However, if ..." ) > > here's the code snippet he's talking about. > Point A: > local_irq_disable(); > /* critical section ...*/ > local_irq_enable(); > > > Author say, if irg are already disabled at Point A (see snippet above) then > local_irq_enable() creates an unpleasant side effect of re-enabling > interrupts rather than restoring interrupt state. this was the section i referred to ... but i guess it made perfect sense to me since i'm familiar with the details > 1) first what's the difference between re-enabling and restoring interrupt > state. many irq controllers have a global enable bit. you can restore the interrupt mask state without toggling that bit. > 2) so is disable interrupts twice a problem, or just enabling them when after > they are diabled (which sounds like how it should be ) a problem. both are a problem. the non-state saving version cannot be used recursively nor in parallel to the state-saving version. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local_save_flags(flags)
On Thu, Sep 18, 2008 at 18:05, Fundu wrote: >> you really should just read a book on the topic. LDD3 >> covers these >> intricacies (and a lot more), as does Essential Linux >> Device Drivers. > > i'm actually reading essential linux device drivers. And to get some > clarification i made the post. that book explicitly covers your question. read chapter 2 where it covers these irq functions. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local_save_flags(flags)
On Thu, Sep 18, 2008 at 17:09, Fundu wrote: >> turning off interrupts just masks them. the interrupt >> hardware should >> "latch" them and they fire when you reenable >> interrupts. >> >> You loose track of "how many" not if any >> happened... > > a follow up question, > why do we need to save the flags then ? if the interrupt hardware would > latch them ? > can we not just disable all interrupts ? you really should just read a book on the topic. LDD3 covers these intricacies (and a lot more), as does Essential Linux Device Drivers. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Remove more code when IP_MULTICAST=n
On Tue, Aug 19, 2008 at 9:00 AM, Thomas Petazzoni wrote:
> Index: linuxdev/include/linux/igmp.h
> +#define ip_check_mc(a, b, c, d) ({ 0; })
> +#define ip_mc_sf_allow(a, b, c, d) ({ 1; })
> +#define ip_mc_init_dev(a) ({ })
> +#define ip_mc_up(a) ({ })
> +#define ip_mc_down(a) ({ })
> +#define ip_mc_destroy_dev(a) ({ })
> +#define ip_mc_init_dev(a) ({ })
> +#define ip_mc_drop_socket(a) ({ })
i thought kernel headers in general use static inline stubs rather
than macros so that nested arguments get correct behavior (arg++).
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
On Fri, Aug 8, 2008 at 4:10 PM, Daniel Walker wrote: > On Fri, 2008-08-08 at 14:09 -0400, Mike Frysinger wrote: >> > I invite you to give some of the "plenty of >> > examples in the tree", you might surprise me.. >> >> look at all the new syscalls added without any userspace code in place >> (still) to use it. or Linus' recent printk modifier extension. or my >> printk extensions for extracting portions of the kernel log buffer. >> people usually submit interfaces with backend extesions, or the intent >> to use it is obvious. > > Syscalls and Userspace are unrelated .. You clearly can't add userspace > code to the kernel .. If you add a _kernel_ interface like David has > done you need at least one user of the interface.. Otherwise it's just > plain bloat inside the kernel which no one wants. > > Your changes for extracting part of the kernel log buffer (commit > 0b15d04af3dd996035d8fa81fc849d049171f9c3), > > with: > textdata bss dec hex filename > 4322000 386760 2592768 7301528 6f6998 vmlinux > without: > textdata bss dec hex filename > 4321876 386760 2592768 7301404 6f691c vmlinux > > Adds roughly 120bytes of bloat to my kernel, since 2007 .. What's the > point? I grepped for users , and there are none .. same sort of things as the point of David's code. early/crash scenarios for people to safely extract portions of the kernel log buffer for transmission/storage elsewhere. as was explained in the original thread behind the commit. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
On Fri, Aug 8, 2008 at 12:17 PM, Daniel Walker wrote: > On Fri, 2008-08-08 at 12:05 -0400, Mike Frysinger wrote: >> On Fri, Aug 8, 2008 at 11:55 AM, Daniel Walker wrote: >> > Another note, usually when submitting new interfaces like this you >> > should also submit the code that uses the interface .. In your case you >> > might not be able to do that, but it could never be accepted without at >> > least one user. >> >> i really doubt that. lack of existing tangible users makes it a >> harder case, but it certainly is not a "never" case. there is plenty >> of examples in the tree where things were merged without any users and >> the commit wouldnt be immediately leveraged. > > Well, I did say "usually" .. you said "usually people submit new interfaces", not "it is usually not accepted without at least one user". > I invite you to give some of the "plenty of > examples in the tree", you might surprise me.. look at all the new syscalls added without any userspace code in place (still) to use it. or Linus' recent printk modifier extension. or my printk extensions for extracting portions of the kernel log buffer. people usually submit interfaces with backend extesions, or the intent to use it is obvious. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
On Fri, Aug 8, 2008 at 11:55 AM, Daniel Walker wrote: > Another note, usually when submitting new interfaces like this you > should also submit the code that uses the interface .. In your case you > might not be able to do that, but it could never be accepted without at > least one user. i really doubt that. lack of existing tangible users makes it a harder case, but it certainly is not a "never" case. there is plenty of examples in the tree where things were merged without any users and the commit wouldnt be immediately leveraged. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
On Thu, Jul 17, 2008 at 4:13 PM, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > Here is the update against current Linus tree, > rolled up into one patch. > > James Bottomley suggested a different naming scheme: > instead of swapping parts (.text.head -> .head.text), > prepend .kernel to our special section names. > This patch implements his idea. > > ppc and v850 are dropped per comments from arch people. > parisc and x86 had minor fixes. x86 fix added proper > executable bits to a section: > > -.section ".text.head" > +.section ".kernel.text.head","ax",@progbits > > Does arch/m68k/kernel/sun3-head.S need the same fix? > > The patch is run-tested on x86_64. > > I would like to ask arch maintainers to ACK/NAK this patch, > and Andrew to act accordingly. the Blackfin piece is just one line and shouldnt be a problem from our side. thanks. btw, arch maintainers have an alias "[EMAIL PROTECTED]" ... but it doesnt appear to be in MAINTAINERS ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
On Tue, Jul 1, 2008 at 8:08 PM, Denys Vlasenko wrote: > On Wednesday 02 July 2008 00:58, Mike Frysinger wrote: >> On Tue, Jul 1, 2008 at 8:35 PM, Denys Vlasenko wrote: >> > The purpose of this patch is to make kernel buildable >> > with "gcc -ffunction-sections -fdata-sections". >> > This patch fixes blackfin architecture. >> >> the comment right above what you changed says it already works for >> Blackfin. so you arent fixing it at all. >> >/* This gets done first, so the glob doesn't suck it in */ >> >. = ALIGN(32); >> > - *(.data.cacheline_aligned) >> > + *(.cacheline_aligned.data) > > This may pull in an unrelated data object named "cacheline_aligned" > (say, a static variable in a driver). If that variable is not > itself aligned to the cacheline size, it will mess up alignment of all > objects in .data.cacheline_aligned which follow. Not good. > > To be safe from such weird and hard to debug problems > it's better to not use names like .data. at all. > I just uniformly renamed al such "special sections" > in the kernel to .X.data you're right of course ... i obviously hadnt thought of this. please however still abstract this stuff into the common header. i just tested the current Blackfin kernel and it does build/link/run fine with -ffunction-sections/-fdata-sections. however, --gc-sections still causes crashes (but this is because all of the .init.setup sections are flagged as unused). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
On Tue, Jul 1, 2008 at 8:35 PM, Denys Vlasenko wrote: > The purpose of this patch is to make kernel buildable > with "gcc -ffunction-sections -fdata-sections". > This patch fixes blackfin architecture. the comment right above what you changed says it already works for Blackfin. so you arent fixing it at all. >/* This gets done first, so the glob doesn't suck it in */ >. = ALIGN(32); > - *(.data.cacheline_aligned) > + *(.cacheline_aligned.data) ive built Blackfin kernels with function/data sections a long time ago ... but iirc, there were toolchain problems, so i havent pursued it since. if you're going to muck with names, you might as well do it right the first time: move the names into asm-generic/vmlinux.lds.h so we dont have to worry about this kind of churn again. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: modules.dep and depmod.pl
On Fri, Jun 13, 2008 at 7:33 PM, Linus Walleij wrote: > what are other embedded developers experience with using the > script "depmod.pl" from BusyBox to create > installdir/lib/modules//modules.dep > during compile-time? it's used in the uClinux distribution and works fine for me. only had problems when there are multiple kernel versions, but never had a problem with a single. > Is there anyone beside me who would like to see this integrated > into scripts/ in the kernel to get some default modules.dep for > a read-only rootfs also when doing cross compilation, or am I > totally going down the wrong lane here? seems like a worthwhile step to me -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 9:25 PM, Rob Landley wrote: > He recently converted Battle for Wesnoth to use something called "scons" as > its build system, and apparently the resulting make stuff was 1/17th the size > of the original. probably because scons has ~1/17th the functionality of autotools. seriously, it's terrible. funny you should mention it in a thread about cross-compiling seeing as how it doesnt have a chance of supporting it (has hard enough time supporting native builds). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote: > Mike Frysinger wrote: >>> Er, is that GPL or LGPL code that you're modifying? If so, you *have* to >>> push those code changes out (make them available to others), whether you >>> think people will be interested or not! >> >> umm, not really. only if (1) he gives a binary to someone and (2) >> they ask him for the source. if he doesnt distribute or no one asks, >> he doesnt have to do squat. > > This is closer to correct, but missing some important details. > > Start the GPL compliance tutorial/flameware in 3, 2, 1... yeah, i really dont think licensing things belong here. sorry for following up. how about this policy: if you want to make a statement, go pay a lawyer. but that statement still shouldnt be made here ;). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote: > David VomLehn wrote: >> Amen, brother. I'm fortunate in that I work for an organization that is >> quite good about enforcing code reviews, specifically, the QA organization >> is empowered to reject changes that do not have code review notes. I also >> have a fairly broad scope, so I'm in on code reviews for a number of open >> source components. At each such review, one of my criteria is whether the >> change is suitable for pushing back to the appropriate community. This is >> not necessarily a short-term way to make friends, but the long-term effects >> will be good both for the company and for the open source community in >> general. >> >> Now, if we can only get the time to actually push all the backlogged fixes >> out... > > Er, is that GPL or LGPL code that you're modifying? If so, you *have* to > push those code changes out (make them available to others), whether you > think people will be interested or not! umm, not really. only if (1) he gives a binary to someone and (2) they ask him for the source. if he doesnt distribute or no one asks, he doesnt have to do squat. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel boot problem on IXP422 Rev. A
On Thu, Jun 12, 2008 at 5:28 PM, Glenn Henshaw wrote: > On 12-Jun-08, at 4:04 PM, Mike Frysinger wrote: >> On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote: >>> we currently try to boot a 2.6.21 kernel >> >> time to upgrade > > Wrong answer!!! not really > Many embedded devices can't upgrade kernels easily because of customer > and there are plenty of *wrong* reasons that people are using old kernels. > Often developers not working in the embedded space don't understand this > reality. if i'm not classified as an embedded developer, then i dont know what one is :P > Helpful responses on what does/does not work would be more appreciated. i gave a realistic one and i sent him to the right place -- the arm kernel mailing lists -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel boot problem on IXP422 Rev. A
On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote: > we currently try to boot a 2.6.21 kernel time to upgrade > on a custom IXP422 based board. you'll have better luck asking on the arm kernel mailing lists. they process this stuff every day. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 2:29 PM, Josh Boyer wrote: > On Thu, Jun 12, 2008 at 12:05 PM, Mike Frysinger wrote: >> On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote: >>> On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote: >>>> Rob Landley wrote: >>>> > However, having one or more full-time engineers devoted to debugging >>>> > cross-compile issues is quite a high price to pay too. Moore's law >>>> > really >>>> > doesn't help that one. >>>> > >>>> > I'm not saying either solution is perfect, I'm just saying the "build >>>> > under >>>> > emulation" approach is a viable alternative that gets more attractive as >>>> > time >>>> > passes, both because of ongoing development on emulators and because of >>>> > Moore's law on the hardware. >>>> >>>> I agree with much that you have said, Rob, and I understand the argument >>>> for getting the most gain from the least resources, but I have a >>>> philosophical >>>> problem with working around the cross-compilation problems instead of >>>> fixing >>>> them in the upstream packages (or in the autoconf system itself). >>>> >>>> Once someone fixes the cross-compilation issues for a package, they usually >>>> stay fixed, if the fixes are mainlined. >>> >>> I don't think that's true, unfortunately. Autoconf makes it _easy_ to do >>> the wrong thing, and people will often introduce new problems. >>> >>> If we just made people write portable code and proper Makefiles, it >>> would be less of an issue :) >> >> people cant even write proper *native* makefiles. mtd-utils for example ;). > > What's wrong with it? I'll fix it. is [EMAIL PROTECTED] not the place to post ? that's where i sent the first fix yesterday ... not that i'm subscribed since i dont have a direct interest in mtd development ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 1:14 PM, Bill Gatliff wrote: > Paul Mundt wrote: >> Yes, that's the easy case. It's things like perl that are the corner >> cases, and my objection comes from the fact that people think we ought to >> not have the kernel depend on perl rather than just fixing the package >> itself. Autoconf/libtool damage is an entirely different problem :-) > > At first glance, it seems like checkincludes.pl could be duplicated by egrep | > uniq | wc vs. egrep | wc. Not quite sure what checkversion.pl is trying to > do. > > The namespace.pl script looks optional, as does export_report.pl. > > So maybe we could _reduce_ dependency on perl, if there's any advantage to > gain > by doing so. But the kernel build machinery isn't dependent on very many > other > systems (just tcl, bash and gcc-core), so I don't really see the point unless > you could completely eliminate perl. And I don't see how you might do *that* > without dragging in a bunch of stuff to replace it, thereby increasing the > number of dependencies. the idea is to keep perl from being required to build the kernel itself. tcl is not required in this case either. if you want to use crazy languages to optional things above and beyond, then no one is going to complain (and if they do, well screw them). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 12:31 PM, Paul Mundt wrote: > On Thu, Jun 12, 2008 at 11:28:10AM -0500, Bill Gatliff wrote: >> > If you opt to cross-compile, having to deal with those >> > sorts of things is the price you pay. >> >> >> If the build system derives from autoconf, then a hacked-up config.cache (or >> equivalent command-line args) often solves problems for me. Just give the >> cache >> the answers that it would otherwise have to get by running code on the target >> machine. >> >> That's how emdebian is doing a bunch of their stuff, and I have to admit >> that it >> works pretty darned well. It's also handy for configuration management, >> since >> the cache file itself is plaintext and therefore >> svn/git/bzr/cvs/...-friendly. > > Yes, that's the easy case. It's things like perl that are the corner > cases, and my objection comes from the fact that people think we ought to > not have the kernel depend on perl rather than just fixing the package > itself. Autoconf/libtool damage is an entirely different problem :-) of the core packages, perl and openssl tend to be heavily damaged. openssl because it depends on perl instead of a real build system. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 12:08 PM, David Woodhouse wrote: > On Thu, 2008-06-12 at 12:05 -0400, Mike Frysinger wrote: >> people cant even write proper *native* makefiles. mtd-utils for >> example ;). > > Criticism in 'diff -u' form preferred :) i sent via `git-send-email` yesterday to the mtd lists ... either it got silently dropped, or someone hates me -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote: > On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote: >> Rob Landley wrote: >> > However, having one or more full-time engineers devoted to debugging >> > cross-compile issues is quite a high price to pay too. Moore's law really >> > doesn't help that one. >> > >> > I'm not saying either solution is perfect, I'm just saying the "build under >> > emulation" approach is a viable alternative that gets more attractive as >> > time >> > passes, both because of ongoing development on emulators and because of >> > Moore's law on the hardware. >> >> I agree with much that you have said, Rob, and I understand the argument >> for getting the most gain from the least resources, but I have a >> philosophical >> problem with working around the cross-compilation problems instead of fixing >> them in the upstream packages (or in the autoconf system itself). >> >> Once someone fixes the cross-compilation issues for a package, they usually >> stay fixed, if the fixes are mainlined. > > I don't think that's true, unfortunately. Autoconf makes it _easy_ to do > the wrong thing, and people will often introduce new problems. > > If we just made people write portable code and proper Makefiles, it > would be less of an issue :) people cant even write proper *native* makefiles. mtd-utils for example ;). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initramfs size limitation
On Tue, Jun 3, 2008 at 4:59 PM, Rob Landley wrote: > On Sunday 01 June 2008 19:25:11 Mike Frysinger wrote: >> On Sun, Jun 1, 2008 at 8:03 PM, Rob Landley wrote: >> > fact it would be really nice if qemu grew blackfin support because >> > messing >> >> i imagine it would be ... too bad qemu lacks real documentation > > Actually there was documentation on the old stuff if you knew where to dig it > up (a good starting point was Fabrice's old usenix paper and then I had some > links I'd collected from there) yes, but spotiness doesnt help > but they just ripped out the old code > generator in favor of a new one > (See http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00011.html ) so > there's not much point in going there right now. (Hopefully they'll have a > 1.0 release within our lifetimes.) i'm aware the tcg stuff exists, but that's about it. only hope for new ports atm is to contract a qemu guy. not that the qemu guys would mind. thanks for the link. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initramfs size limitation
On Sun, Jun 1, 2008 at 8:03 PM, Rob Landley wrote: > On Saturday 31 May 2008 07:44:14 Phil Wilshire wrote: >> I hope this is the right place and the right sort of question. >> >> I work closely with the Blackfin systems and they have now integrated >> the initramfs generation into their system build. The result is great >> the root fs is ready to run from the page cache. > > Is it possible to get blackfin working with a vanilla gcc release yet, or do > you still need out-of-tree patches? (I have a blackfin board I got at OLS, > but it needs a toolchain I can't reproduce.) there's plenty of usable binaries available > fact it would be really nice if qemu grew blackfin support because messing i imagine it would be ... too bad qemu lacks real documentation >> There is one problem that I can see that may be more serious for >> embedded users. >> As far as I can tell the initramfs filesystem is not restricted in size. >> You can keep writing files until it uses all available memory. > > Yup. There have intermittently been patches to make rootfs be tmpfs instead > of ramfs, the most recent of which I remember was: > http://lkml.org/lkml/2007/7/13/354 it wouldnt matter. tmpfs on NOMMU doesnt support any of the options like MMU. look at mm/tiny-shmem.c and init/Kconfig. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some embedded topics
On Thu, May 29, 2008 at 1:31 PM, Rob Landley wrote: > On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote: >> On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote: >> > On Tuesday 27 May 2008 17:31:42 T Ziomek wrote: >> >> If I understand correctly David is talking about logging some trace-like >> >> info (so it exists before a HW watchdog expires), and having it >> >> somewhere "safe" from being disturbed by a HW reset. >> > >> > The standard way of doing this is to use the mem= kernel command line >> > parameter to tell the system it has less memory than it does, and using >> > what's left as a ramdisk. Years ago I saw some userspace thing running >> > as root mmap() /dev/mem (or whatever they're calling it these days) and >> > log to it. In theory you could even set the dmesg buffer up at the end >> > of physical memory with a smallish kernel patch, make it big, and set the >> > kernel to doing verbose printks. >> > >> > The trick is A) knowing the absolute physical address at which your debug >> > buffer lives so you can find it after the reboot, B) convincing the >> > system to do something useful with it on reboot rather than just >> > overwriting it with fresh log data. >> >> how about the fact that when the core resets, the memory controller is >> often reset as well ? that external memory is going to degrade. or >> do we just bite our thumb and weather the few random bit errors ? >> -mike > > Mostly it isn't a problem because DRAM lasts longer than you think it does: > http://www.securityfocus.com/brief/686 ive read that article before and i'm aware of real degradation times. it also points out that "the colder the better" which certainly doesnt line up with many realistic cases of machines sitting in hot rooms or in closests. working off of "well it should be fine most of the time" isnt nearly as good as "this always works", and all it takes is 1 or 2 bits to be corrupt to significantly change the meaning of a cpu state dump ... but as long as things are prefaced this way and people are aware ... it's better than nothing > Your memory controller init has to go out of its way to screw it up with a > memory test or some such. (That said, some of 'em do...) as soon as the memory controller stops refreshing, it's a problem. > This of course assumes you have spare ram for a while second kernel to sit > around and do nothing until you pass control to it to fetch your diagnostics. > Most embedded systems don't. if you communicate the kernel log buffer pointer to u-boot, then you can just read that directly. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
