Hi all,
This is the new Blackfin patch for kernel 2.6.14. Mainly includes
arch/Blackfin and include/asm-blackfin files. We decided not to put in
all the drivers for this version.
Here is the patch URL:
http://blackfin.uclinux.org/frs/download.php/606/bfin4kernel-2.6.14.patch
. Please reiview and merge it into the kernel. Thank you very much.
Luke Yang
[email protected]
ADI Inc.
On Tue, Nov 01, 2005 at 05:28:30PM +0800, Luke Yang wrote:
> Hi all,
Hi,
> This is the new Blackfin patch for kernel 2.6.14. Mainly includes
> arch/Blackfin and include/asm-blackfin files. We decided not to put in
> all the drivers for this version.
>
> Here is the patch URL:
> http://blackfin.uclinux.org/frs/download.php/606/bfin4kernel-2.6.14.patch
> . Please reiview and merge it into the kernel. Thank you very much.
some comments:
- the changes to the toplevel Makefile should go to
arch/blackfin/kernel/Makefile
- please use drivers/Kconfig
- include/asm-blackfin/pci.h contains some ^M characters
- please replace "extern inline" and "extern __inline__" with
"static inline"
- CONFIG_CLEAN_COMPILE=n is not a good choice for a defconfig
> Luke Yang
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi,
Thank you for your reivew. I change those files and updated the patch:
http://blackfin.uclinux.org/frs/download.php/607/bfin_r2_4kernel-2.6.14.patch
Regards,
Luke
On 11/2/05, Adrian Bunk <[email protected]> wrote:
> On Tue, Nov 01, 2005 at 05:28:30PM +0800, Luke Yang wrote:
>
> > Hi all,
>
> Hi,
>
> > This is the new Blackfin patch for kernel 2.6.14. Mainly includes
> > arch/Blackfin and include/asm-blackfin files. We decided not to put in
> > all the drivers for this version.
> >
> > Here is the patch URL:
> > http://blackfin.uclinux.org/frs/download.php/606/bfin4kernel-2.6.14.patch
> > . Please reiview and merge it into the kernel. Thank you very much.
>
> some comments:
> - the changes to the toplevel Makefile should go to
> arch/blackfin/kernel/Makefile
> - please use drivers/Kconfig
> - include/asm-blackfin/pci.h contains some ^M characters
> - please replace "extern inline" and "extern __inline__" with
> "static inline"
> - CONFIG_CLEAN_COMPILE=n is not a good choice for a defconfig
>
> > Luke Yang
>
> cu
> Adrian
>
> --
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
> "Only a promise," Lao Er said.
> Pearl S. Buck - Dragon Seed
>
>
Hi,
Does this patch has the chance to be merged? Is anyone reivewing or
merging it? Anything I can help? Just want to make sure... Thanks a
lot!
Luke Yang
On 11/2/05, Luke Yang <[email protected]> wrote:
> Hi,
>
> Thank you for your reivew. I change those files and updated the patch:
>
> http://blackfin.uclinux.org/frs/download.php/607/bfin_r2_4kernel-2.6.14.patch
>
> Regards,
> Luke
>
>
> On 11/2/05, Adrian Bunk <[email protected]> wrote:
> > On Tue, Nov 01, 2005 at 05:28:30PM +0800, Luke Yang wrote:
> >
> > > Hi all,
> >
> > Hi,
> >
> > > This is the new Blackfin patch for kernel 2.6.14. Mainly includes
> > > arch/Blackfin and include/asm-blackfin files. We decided not to put in
> > > all the drivers for this version.
> > >
> > > Here is the patch URL:
> > > http://blackfin.uclinux.org/frs/download.php/606/bfin4kernel-2.6.14.patch
> > > . Please reiview and merge it into the kernel. Thank you very much.
> >
> > some comments:
> > - the changes to the toplevel Makefile should go to
> > arch/blackfin/kernel/Makefile
> > - please use drivers/Kconfig
> > - include/asm-blackfin/pci.h contains some ^M characters
> > - please replace "extern inline" and "extern __inline__" with
> > "static inline"
> > - CONFIG_CLEAN_COMPILE=n is not a good choice for a defconfig
> >
> > > Luke Yang
> >
> > cu
> > Adrian
> >
> > --
> >
> > "Is there not promise of rain?" Ling Tan asked suddenly out
> > of the darkness. There had been need of rain for many days.
> > "Only a promise," Lao Er said.
> > Pearl S. Buck - Dragon Seed
> >
> >
>
On Fri, Nov 04, 2005 at 12:59:14PM +0800, Luke Yang wrote:
> Hi,
>
> Does this patch has the chance to be merged? Is anyone reivewing or
> merging it? Anything I can help? Just want to make sure... Thanks a
> lot!
Your patch is 43 thousand lines long. Please break it up into the
different logical chunks, and document them, and add a signed-off-by:
line, and send them to the proper places/people, as it is documented in
the file, Documentation/SubmittingPatches.
thanks,
greg k-h
But this patch only includes the arch files for Blackfin. Do I have
to break it into smaller chunks? It is hard to break it...
On 11/5/05, Greg KH <[email protected]> wrote:
> On Fri, Nov 04, 2005 at 12:59:14PM +0800, Luke Yang wrote:
> > Hi,
> >
> > Does this patch has the chance to be merged? Is anyone reivewing or
> > merging it? Anything I can help? Just want to make sure... Thanks a
> > lot!
>
> Your patch is 43 thousand lines long. Please break it up into the
> different logical chunks, and document them, and add a signed-off-by:
> line, and send them to the proper places/people, as it is documented in
> the file, Documentation/SubmittingPatches.
>
> thanks,
>
> greg k-h
>
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
On Mon, Nov 07, 2005 at 02:58:03PM +0800, Luke Yang wrote:
> But this patch only includes the arch files for Blackfin. Do I have
> to break it into smaller chunks? It is hard to break it...
Is there some reason this patch should not follow the documented
process? Do you want it to be reviewed by people? Accepted into the
main kernel tree? If so, I suggest you do the proper thing.
If you have questions as to the specific ways to do this, please let us
know.
thanks,
greg k-h
Greg KH <[email protected]> wrote:
>
> On Mon, Nov 07, 2005 at 02:58:03PM +0800, Luke Yang wrote:
> > But this patch only includes the arch files for Blackfin. Do I have
> > to break it into smaller chunks? It is hard to break it...
>
> Is there some reason this patch should not follow the documented
> process? Do you want it to be reviewed by people? Accepted into the
> main kernel tree? If so, I suggest you do the proper thing.
We've taken arch patches in a single hit before. It's not such a bad thing.
A basic requirement should be "it should all compile before and after the
patch". That's pretty hard to do in this case if it's split up.
That being said, a 1.6MB patch is a bit hard to review, mainly because it
doesn't fit through the email server.
>From a quick look:
> +static spinlock_t dma_page_lock = SPIN_LOCK_UNLOCKED;
DEFINE_SPIN_LOCK()
> +static unsigned int dma_initialized = 0;
Remove the `= 0'
+/*
+ * Initial task structure.
+ *
+ * All other task structs will be allocated on slabs in fork.c
+ */
+__asm__(".align 4");
+struct task_struct init_task = INIT_TASK(init_task);
weird. That align will probably go into .text, rather than where you want
it. Use __attribute__((__aligned__(4))) or ____cacheline_aligned, or just
remove it - the compiler will align this guy on a 4-byte boundary anyway.
Does this architecture support SMP? I see it's BROKEN_ON_SMP, but there
seems to be some smp-style stuff in there.
One concern when adding a new architecture is: will it be maintained
long-term? We don't want to merge an arch and then have it bitrot. Who is
behind this port, and how do we know that they'll still be around and doing
things in two years' time?
Can this arch use the generic IRQ handling code in kernel/irq/?
The idle routines don't appear to be up-to-date wrt post-2.6.14 changes.
Or if they are, they won't be after I merge Nick's stuff ;)
get_reg() is way too big to be inlined.
Ditto put_reg().
Can this arch use the generic lib/semaphore-sleepers.c?
> +extern void icache_init(void);
> +extern void dcache_init(void);
> +extern int read_iloc(void);
> +extern unsigned long ipdt_table[];
> +extern unsigned long dpdt_table[];
> +extern unsigned long icplb_table[];
> +extern unsigned long dcplb_table[];
> +int DmaMemCpy(char *dest_addr, char *source_addr, unsigned short size);
> +int DmaMemCpy16(char *dest_addr, char *source_addr, int size);
extern decls should always go in header files. If things like
icache_init() aren't in any headers, well mutter. It'd be nice to fix
that. Involves touching all architectures, yeah, not your job...
touch_l1_data() can have static scope. Please review all global symbols
for this.
Does a new arch need to support old_mmap()?
old_select()?
> +void time_sched_init(irqreturn_t(*timer_routine)
> + (int, void *, struct pt_regs *));
> +unsigned long gettimeoffset(void);
> +extern unsigned long wall_jiffies;
> +extern int setup_irq(unsigned int, struct irqaction *);
> +inline static void do_leds(void);
> +
> +extern u_long get_cclk(void);
More extern-decls-in-c-files
> +asmlinkage int sys_bfin_spinlock(int *spinlock)
Whoa, that's a syscall I never expected to see. What's it do? Shouldn't
it be using get_user() and put_user()? Or will this forever be a nommu
arch?
What _is_ a bluefin, anyway?
Are precompiled cross-complers/assemblers available anywhere?
bix:/home/akpm> grep volatile bfin_r2_4kernel-2.6.14.patch | wc -l
2901
Cow. You know that volatile in-kernel is basically always wrong?
>
> We've taken arch patches in a single hit before. It's not such a bad thing.
>
> A basic requirement should be "it should all compile before and after the
> patch". That's pretty hard to do in this case if it's split up.
>
> That being said, a 1.6MB patch is a bit hard to review, mainly because it
> doesn't fit through the email server.
>
> From a quick look:
>
> > +static spinlock_t dma_page_lock = SPIN_LOCK_UNLOCKED;
>
> DEFINE_SPIN_LOCK()
>
> > +static unsigned int dma_initialized = 0;
>
> Remove the `= 0'
>
> +/*
> + * Initial task structure.
> + *
> + * All other task structs will be allocated on slabs in fork.c
> + */
> +__asm__(".align 4");
> +struct task_struct init_task = INIT_TASK(init_task);
>
> weird. That align will probably go into .text, rather than where you want
> it. Use __attribute__((__aligned__(4))) or ____cacheline_aligned, or just
> remove it - the compiler will align this guy on a 4-byte boundary anyway.
>
>
> Does this architecture support SMP? I see it's BROKEN_ON_SMP, but there
> seems to be some smp-style stuff in there.
It doesn't support SMP now.
>
>
> One concern when adding a new architecture is: will it be maintained
> long-term? We don't want to merge an arch and then have it bitrot. Who is
> behind this port, and how do we know that they'll still be around and doing
> things in two years' time?
I don't clearly know the process of maintaining an arch in kernel.
But I am sure we can follow the right process. My question is: How do
they maintain the m68knommu arch? I think it need the uclinux patch to
run on real platfrom. What is the process like?
>
>
> Can this arch use the generic IRQ handling code in kernel/irq/?
Yes.
>
>
> The idle routines don't appear to be up-to-date wrt post-2.6.14 changes.
> Or if they are, they won't be after I merge Nick's stuff ;)
>
>
> get_reg() is way too big to be inlined.
>
> Ditto put_reg().
>
>
> Can this arch use the generic lib/semaphore-sleepers.c?
>
> > +extern void icache_init(void);
> > +extern void dcache_init(void);
> > +extern int read_iloc(void);
> > +extern unsigned long ipdt_table[];
> > +extern unsigned long dpdt_table[];
> > +extern unsigned long icplb_table[];
> > +extern unsigned long dcplb_table[];
> > +int DmaMemCpy(char *dest_addr, char *source_addr, unsigned short size);
> > +int DmaMemCpy16(char *dest_addr, char *source_addr, int size);
>
> extern decls should always go in header files. If things like
> icache_init() aren't in any headers, well mutter. It'd be nice to fix
> that. Involves touching all architectures, yeah, not your job...
>
>
> touch_l1_data() can have static scope. Please review all global symbols
> for this.
>
>
> Does a new arch need to support old_mmap()?
>
>
> old_select()?
>
>
> > +void time_sched_init(irqreturn_t(*timer_routine)
> > + (int, void *, struct pt_regs *));
> > +unsigned long gettimeoffset(void);
> > +extern unsigned long wall_jiffies;
> > +extern int setup_irq(unsigned int, struct irqaction *);
> > +inline static void do_leds(void);
> > +
> > +extern u_long get_cclk(void);
>
> More extern-decls-in-c-files
>
> > +asmlinkage int sys_bfin_spinlock(int *spinlock)
>
> Whoa, that's a syscall I never expected to see. What's it do? Shouldn't
> it be using get_user() and put_user()? Or will this forever be a nommu
> arch?
>
>
> What _is_ a bluefin, anyway?
>
>
> Are precompiled cross-complers/assemblers available anywhere?
Yes, please visit blackfin.uclinux.org to get our toolchain.
>
>
> bix:/home/akpm> grep volatile bfin_r2_4kernel-2.6.14.patch | wc -l
> 2901
>
> Cow. You know that volatile in-kernel is basically always wrong?
>
To the other detail questions/issues, I'll write to you soon.
Thank you for your help.
Luke Yang
Luke Yang wrote:
>>Does this architecture support SMP? I see it's BROKEN_ON_SMP, but there
>>seems to be some smp-style stuff in there.
>
>
> It doesn't support SMP now.
Wrong, how about dual core BF56x subfamily? It's true SMP beast.
Or you are try to told that "current SOFTWARE arch doesn't
support it yet", am I right?
Also, returning to previous posts, ALL BF5xx have normal
MMU (which possible not so useful for DSP tasks).
--
Regards
Andrey Volkov
On Fri, Nov 11, 2005 at 07:26:31PM +0800, Luke Yang wrote:
> > One concern when adding a new architecture is: will it be maintained
> > long-term? We don't want to merge an arch and then have it bitrot. Who is
> > behind this port, and how do we know that they'll still be around and doing
> > things in two years' time?
>
> I don't clearly know the process of maintaining an arch in kernel.
> But I am sure we can follow the right process. My question is: How do
> they maintain the m68knommu arch? I think it need the uclinux patch to
> run on real platfrom. What is the process like?
The process is like maintaining any other part of the kernel:
- Try to make sure it works on all releases (harder to do with a full
arch, I know, but not impossible.)
- keep it up to date with bugfixes and the such
- be responsive to questions from other developers
- accept patches from others and intregrate them into the mainline
version in a reasonable ammount of time.
Does this arch have corporate support behind it to maintain it over
time, or is something you are going to do in your spare time (which is
fine, just curious.)
thanks,
greg k-h
Greg KH wrote:
> Does this arch have corporate support behind it to maintain it over
> time, or is something you are going to do in your spare time (which is
> fine, just curious.)
The port is developed by a dedicated team at Analog Devices. For a
summary of what we're doing, see this message from an earlier thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113086025519904&w=2
(The reasone we're all not posting from analog.com email addresses is
that doing so would involve the use of outlook :-)
Bernd
On 11/12/05, Andrey Volkov <[email protected]> wrote:
> Luke Yang wrote:
> >>Does this architecture support SMP? I see it's BROKEN_ON_SMP, but there
> >>seems to be some smp-style stuff in there.
> >
> >
> > It doesn't support SMP now.
>
> Wrong, how about dual core BF56x subfamily? It's true SMP beast.
> Or you are try to told that "current SOFTWARE arch doesn't
> support it yet", am I right?
Yes, BF56x does have two cores in one chip. But we are not going to
make it a SMP system. The second core is going to be used as a pure
DSP, do some encode/decode work. Remember Blackfin itself is a DSP
anyway.
>
> Also, returning to previous posts, ALL BF5xx have normal
> MMU (which possible not so useful for DSP tasks).
Actually current BF5xx DSPs don't have a real MMU. It runs uClinux.
The called "MMU" in the mannual is only a cache management and memory
protect unit, not a virtual memory unit.
>
> --
> Regards
> Andrey Volkov
>
>
On 11/13/05, Greg KH <[email protected]> wrote:
> On Fri, Nov 11, 2005 at 07:26:31PM +0800, Luke Yang wrote:
> > > One concern when adding a new architecture is: will it be maintained
> > > long-term? We don't want to merge an arch and then have it bitrot. Who is
> > > behind this port, and how do we know that they'll still be around and doing
> > > things in two years' time?
> >
> > I don't clearly know the process of maintaining an arch in kernel.
> > But I am sure we can follow the right process. My question is: How do
> > they maintain the m68knommu arch? I think it need the uclinux patch to
> > run on real platfrom. What is the process like?
>
> The process is like maintaining any other part of the kernel:
> - Try to make sure it works on all releases (harder to do with a full
> arch, I know, but not impossible.)
Does this include all the rc releases? and the 2.6.14.x releases?
> - keep it up to date with bugfixes and the such
So the process is: when kernel release a new version, we should
update our arch related files to the new kernel, then send you the
patch. Am I right?
> - be responsive to questions from other developers
No problem. We have a website(blackfin.uclinux.org) and a forum.
> - accept patches from others and intregrate them into the mainline
> version in a reasonable ammount of time.
I totally understand.
>
> Does this arch have corporate support behind it to maintain it over
> time, or is something you are going to do in your spare time (which is
> fine, just curious.)
Blackfin is one of the main DSP products of ADI. ADI has a growing
team supporting. I am one of the members.
regards,
Luke Yang
> > The process is like maintaining any other part of the kernel:
> > - Try to make sure it works on all releases (harder to do with a full
> > arch, I know, but not impossible.)
>
> Does this include all the rc releases? and the 2.6.14.x releases?
>
> > - keep it up to date with bugfixes and the such
>
> So the process is: when kernel release a new version, we should
> update our arch related files to the new kernel, then send you the
> patch. Am I right?
well the idea is that you fix things BEFORE the kernel is released for
final, so that the final releases work out of the box (well out of
kernel.org). This implies that you sort of track the git tree on a
regular basis, but at minimum look at the first -rc kernel.
On Llu, 2005-11-14 at 15:34 +0800, Luke Yang wrote:
> So the process is: when kernel release a new version, we should
> update our arch related files to the new kernel, then send you the
> patch. Am I right?
That is the ideal case. Also in theory nothing major should change after
-rc1 of each release so nothing should break later on.
Not all of the minor trees work every release but its considered better
if they do.
Andrew wrote:
>What _is_ a bluefin, anyway?
He he -- I will have to tell the people doing the ads that their money
could be better spend on other things...
Since you asked - The Blackfin Processor includes the common 4 processor Ps
that people request for embedded designs - price, power, performance &
penguins.
The Blackfin Processor manufactured by Analog Devices is based on the
MicroSignal Architecture jointly developed by Analog Devices and Intel. It
combines a RISC programming model, with high performance signal processing
and power efficiency - and is running uClinux today.
For example - we are running a completely open source WiSIP Phone - via
LinPhone (VoIP) & a 802.11b Compact Flash card, on a processor which is
less than $5.00 (BF531).
I personally think that uClinux on a $5.00 processor will increase uClnux's
use in the embedded market, where it may not have been looked at in the
past due to the price of the computation power that it has required. You
now can make a board that runs the Linux networking stack for under $20
(including CPU, SDRAM, and Flash, and 10/100 Phy).
Greg wrote:
>Does this arch have corporate support behind it to maintain it over time,
>or is something you are going to do in your spare time (which is fine,
>just curious.)
As Bernd indicated - there is a small dedicated team (about 12 people,
split between the Norwood, Munich, and Shanghai) from Analog Devices -
testing, maintaining and supporting the ports we have done for the
toolchain, bootLoader, and kernel. We do this primarily through our web
site at blackfin.uclinux.org - We answer questions, review patches, write
documentation, and interact with the over 1,200 registered
developers/users, and 38,000 unregistered users downloading the over 576
Terabytes/month from our site.
>The process is like maintaining any other part of the kernel:
> - Try to make sure it works on all releases (harder to do with a full
> arch, I know, but not impossible.)
A critical part of our development team is our full time testers. We take
the investment in test pretty seriously - we were the first no-mmu
architecture to run LTP, and ported this to Tinderbox as an overall test
tool - to keep cvs as stable as possible. Right now, our tinderbox clients
pull from our cvs, but it shouldn't be too difficult to make things pull
from the proper tree once we are in it.
> - keep it up to date with bugfixes and the such
> - be responsive to questions from other developers
> - accept patches from others and intregrate them into the mainline
> version in a reasonable ammount of time.
Right now, we do most of this on our project web site - I think it is just
a matter of also keeping track of the lkml, and answering questions that
pop up here.
-Robin
On 11/14/05, Arjan van de Ven <[email protected]> wrote:
>
> > > The process is like maintaining any other part of the kernel:
> > > - Try to make sure it works on all releases (harder to do with a full
> > > arch, I know, but not impossible.)
> >
> > Does this include all the rc releases? and the 2.6.14.x releases?
> >
> > > - keep it up to date with bugfixes and the such
> >
> > So the process is: when kernel release a new version, we should
> > update our arch related files to the new kernel, then send you the
> > patch. Am I right?
>
> well the idea is that you fix things BEFORE the kernel is released for
> final, so that the final releases work out of the box (well out of
> kernel.org). This implies that you sort of track the git tree on a
> regular basis, but at minimum look at the first -rc kernel.
yep, that's our plan. And for the 2.6.14.1, 2.6.14.2... versions, do
we have to follow every of them?
>
>
On Tue, Nov 15, 2005 at 10:40:05AM +0800, Luke Yang wrote:
> On 11/14/05, Arjan van de Ven <[email protected]> wrote:
> >
> > > > The process is like maintaining any other part of the kernel:
> > > > - Try to make sure it works on all releases (harder to do with a full
> > > > arch, I know, but not impossible.)
> > >
> > > Does this include all the rc releases? and the 2.6.14.x releases?
> > >
> > > > - keep it up to date with bugfixes and the such
> > >
> > > So the process is: when kernel release a new version, we should
> > > update our arch related files to the new kernel, then send you the
> > > patch. Am I right?
> >
> > well the idea is that you fix things BEFORE the kernel is released for
> > final, so that the final releases work out of the box (well out of
> > kernel.org). This implies that you sort of track the git tree on a
> > regular basis, but at minimum look at the first -rc kernel.
>
> yep, that's our plan. And for the 2.6.14.1, 2.6.14.2... versions, do
> we have to follow every of them?
They should hopefully _not_ break anything, due to the small size of
those releases. If they do, please let the stable team know.
thanks,
greg k-h
Hi,
Le Mon, 14 Nov 2005 15:53:42 -0500, Robin Getz a ?crit?:
> Andrew wrote:
> Since you asked - The Blackfin Processor includes the common 4 processor Ps
> that people request for embedded designs - price, power, performance &
> penguins.
Could I add that ADI chips may be are cheap, but the implementation for
that could be ugly.
For example for the usb eagle (adsl chip) developped by ADI, they put the
smallest RAM as possible on the board. For that reason the DSP firmware is
swapped on the host computer : the firmware is split in pages and when the
chip wants a new page it asks it via an interrupt and the host sends the
requested page...
Also ADI never cares to correct some bugs in the usb eagle firmware nor to
sent us a correct documentation (after 6 months of discusion, they sent us
a 3 years old documentation and they never agree to put a
license for the firmware).
Finaly most of the linux code from ADI that I saw in my eagle usb projects
and in my job weren't very Linux compliant/robust (the first version of
eagle usb driver made by ADI had a memleack that make the modem unsuable
after some hours of use) [1].
I know there are different teams at Analog device and blackfin guys aren't
related to these projects.
I hope backfin project will change my vision of ADI ;)
Matthieu
[1] we have a joke about that : (in french) L? o? ADI passe, les
standards tr?passent.
>
>
> bix:/home/akpm> grep volatile bfin_r2_4kernel-2.6.14.patch | wc -l
> 2901
>
> Cow. You know that volatile in-kernel is basically always wrong?
>
I really don't know that... Could you refer me to any document or
posts talking about it? thank you!
Regards,
Luke
Luke wrote:
> > Cow. You know that volatile in-kernel is basically always wrong?
> >
> I really don't know that... Could you refer me to any document or
> posts talking about it? thank you!
Start with:
http://lkml.org/lkml/2004/1/6/139
> Date Tue, 6 Jan 2004 10:02:18 -0800 (PST)
> From Linus Torvalds <>
> Subject Re: [PATCH] fix get_jiffies_64 to work on voyager
>
> [ This is a big rant against using "volatile" on data structures. Feel
> free to ignore it, but the fact is, I'm right. You should never EVER use
> "volatile" on a data structure. ]
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
On 11/16/05, Paul Jackson <[email protected]> wrote:
> Luke wrote:
> > > Cow. You know that volatile in-kernel is basically always wrong?
> > >
> > I really don't know that... Could you refer me to any document or
> > posts talking about it? thank you!
>
> Start with:
>
> http://lkml.org/lkml/2004/1/6/139
>
> > Date Tue, 6 Jan 2004 10:02:18 -0800 (PST)
> > From Linus Torvalds <>
> > Subject Re: [PATCH] fix get_jiffies_64 to work on voyager
> >
> > [ This is a big rant against using "volatile" on data structures. Feel
> > free to ignore it, but the fact is, I'm right. You should never EVER use
> > "volatile" on a data structure. ]
Well, as this post pointed out, some "volatile" are fine.
Especially when you want to visit hardware registers... On the
embedded platforms like Blackfin, ARM, there must be many "volatile"
in the code.
And we will avoid using "volatile" out of the reasonable range.
>
> --
> I won't rest till it's the best ...
> Programmer, Linux Scalability
> Paul Jackson <[email protected]> 1.925.600.0401
>
Andrew Morton wrote:
>>+asmlinkage int sys_bfin_spinlock(int *spinlock)
>
>
> Whoa, that's a syscall I never expected to see. What's it do?
Replaces the TESTSET instruction, which has a few errata that make it
unreliable. It's used by the pthreads library to provide atomic operations.
> Shouldn't
> it be using get_user() and put_user()? Or will this forever be a nommu
> arch?
We currently don't expect that this code will ever support a MMU, but I
suppose it could use get/put_user for clarity.
Bernd
Matthieu wrote:
>Could I add that ADI chips may be are cheap, but the implementation for
>that could be ugly.
I don't think this is a fair - this is a common issue with any silicon
supplier in recent times. For things like you mentioned - modems - end
consumers don't care how ugly the implementation is - as long as it (a)
works in their environment (b) is cheap.
Ugly to one person is design tradeoffs to another - you just don't agree
with the tradeoffs someone else did. (And you might be right - I don't work
on USB modems)
>I know there are different teams at Analog device and blackfin guys aren't
>related to these projects.
Yes that is correct - ADI is a big place, and there are many different
groups here. The open source development group is small (but growing), and
we all are trying to do the right things - all of our documentation is
posted on our web site - or cvs. If you ask a question - ask on our forums
- it will get answered.
>I hope backfin project will change my vision of ADI ;)
I hope it can as well. If you have any thoughts on how we can interact with
people better - let me know.
-Robin