* Re: [PATCH 1/6] {set,clear,test}_bit() related cleanup
From: Pavel Machek @ 2006-01-26 16:14 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060125112857.GB18584@miraclelinux.com>
Hi!
> While working on these patch set, I found several possible cleanup
> on x86-64 and ia64.
It is probably not your fault, but...
> Index: 2.6-git/include/asm-x86_64/mmu_context.h
> ===================================================================
> --- 2.6-git.orig/include/asm-x86_64/mmu_context.h 2006-01-25 19:07:15.000000000 +0900
> +++ 2.6-git/include/asm-x86_64/mmu_context.h 2006-01-25 19:13:59.000000000 +0900
> @@ -34,12 +34,12 @@
> unsigned cpu = smp_processor_id();
> if (likely(prev != next)) {
> /* stop flush ipis for the previous mm */
> - clear_bit(cpu, &prev->cpu_vm_mask);
> + cpu_clear(cpu, prev->cpu_vm_mask);
> #ifdef CONFIG_SMP
> write_pda(mmu_state, TLBSTATE_OK);
> write_pda(active_mm, next);
> #endif
> - set_bit(cpu, &next->cpu_vm_mask);
> + cpu_set(cpu, next->cpu_vm_mask);
> load_cr3(next->pgd);
>
> if (unlikely(next->context.ldt != prev->context.ldt))
cpu_set sounds *very* ambiguous. We have thing called cpusets, for
example. I'd not guess that is set_bit in cpu endianity (is it?).
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: Error: Three ML403 boards
From: Paula Saameño @ 2006-01-26 14:07 UTC (permalink / raw)
To: Peter Ryser, linuxppc-embedded
In-Reply-To: <259581790601110038w5c4164bcy3a4b2ba916195fa@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
Hi again,
Finally, I get those three boards working with 2.4. It was a hardware
problem. I had written in ddr size 0x40000000, when it should be 0x4000000
(one extra 0, oops!).
I don't really know why it worked in the first one, haha!
Thank you very much!!!
Paula
On 1/11/06, Paula Saameño <gnathita@gmail.com> wrote:
>
>
> Hi, Peter,
>
> I have already checked that record, and even fixing that bug and adding
> the C_APU_CONTROL parameter, it still does not work in any board but one.
>
> Anyone has suffered the same issue or have any idea of why it is
> happening??
>
> Thanks a lot!
> Paula
>
>
> On 1/10/06, Peter Ryser <peter.ryser@xilinx.com> wrote:
> >
> > Paula,
> >
> > please verify that you are not running into the problem described in
> > Xilinx Answer Record 22179
> > (http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=22179
> > ).
> >
> > - Peter
> >
> >
> > Paula Saameño wrote:
> >
> > > Hello,
> > >
> > > I have 3 Xilinx ML403 boards. I have implemented a 2.4 kernel with a
> > > basic configuration, with network support, systemACE, IIC... and it
> > > works perfectly in one of them.
> > >
> > > However, when I put the ACE card, without making any change, in other
> > > ML403 board, it does not work. The .ace file is loaded ok but then the
> > > network leds (6 leds) start blinking and nothing else happens.
> > >
> > > I have tried with two ML403 different boards, and I have no idea of
> > > where the problem is. They should work in the same way, don't they?
> > >
> > > Any help would be great.
> > >
> > > Also, I am trying to load a 2.6 kernel, but I am still on the way. I
> > > will let you know if I get it working.
> > >
> > > Thanks a lot!
> > > Paula
> > >
> >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Linuxppc-embedded mailing list
> > >Linuxppc-embedded@ozlabs.org
> > >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 3324 bytes --]
^ permalink raw reply
* HELP! Memory mapping and address space doubts
From: Jose França (Ext_GTBC) @ 2006-01-26 14:04 UTC (permalink / raw)
To: linuxppc-embedded
Hello u all!
I need to clarify some aspects of the memory management in ppc linux =
and i hope that you could help me.
Lets imagine we have a mpc8272 based board with 3 devices A, B and C.In =
the bootloader (in my case, i use u-boot), i configured the BRx and Orx =
so that A has base address X, B has base address Y and C has base =
address Z. My first doubt arrises here: what address should i use? Being =
SDRAM base address 0x00000000 and kernel base address 0xC0000000, where =
will i put these devices mapped on? Above 0xC0000000 or in between the =
end of physical memory and 0xC0000000? Do i really need to configure the =
BAT registers in u boot?
In linux 2.4 kernel, we have ppc_md.setup_io_mappings to map address =
blocks into the BAT registers... As i observed in the kernel source tree =
examples, we must map CPM (why?). And what about the other devices A, B =
and C? How will i setup them in this case and what addresses i can use? =
Above 0xC0000000 or in between the end of physical memory and =
0xC0000000? Is the SDRAM included?
Thanks in advance to all contributions! All of them will be most =
welcomed!
Best regards,
Filipe
^ permalink raw reply
* RE: Linux kernel and u-boot debugging with Eclipse IDE
From: IGOR LURI @ 2006-01-26 10:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]
We have rev. B CPU (MPC5200LiteB evaluation board), and we have found that Eclipse don´t see difference between two files with the same name but different path, that's why we thought Eclipse had problems understanding u-boot symbols.
Now, we have removed all folders under "board" and "cpu" except "icecube" and "mpc5xxx". Also we have removed "lib_arm", "lib_i386", etc. except "lib_generic" and "lib_ppc" folders, and we have debugged u-boot until it relocates in RAM. At this point, the stack is moved from internal SRAM to the SDRAM. Eclipse has problems when it examines the stack and it shows the folowing error message:
< instantanea21.png >
In the other hand, if we see the backtrace with DDD, it shows the same error but it continues showing the stack.
< instantanea11.png >
Answering people who says Metrowerks IDE is better than DDD etc., we could say that Eclipse IDE is a very good choice, even better than Metrowerks and its open source.
Igor Luri
R&D Software Department
Fagor Automation S. Coop.
-----Mensaje original-----
De: wd@denx.de [mailto:wd@denx.de]
Enviado el: miércoles, 25 de enero de 2006 12:43
Para: IGOR LURI
CC: linuxppc-embedded@ozlabs.org
Asunto: Re: Linux kernel and u-boot debugging with Eclipse IDE
In message <918EB199DDDFFA42BEA2EB3A1C6021F399AFAD@correo.fagorautomation.net> you wrote:
>
> We have a MPC5200Lite board running Linux 2.4.25 and u-boot 1.1.4. We
> are able to debug Linux kernel and U-boot using DDD/GDB and BDI2000, and
> we are trying to use Eclipse IDE (with CDT plugin) / BDI2000 to develop
> and debug software.
Are you sure that U-Boot and Kernel debugging works fine with GDB? So
is this a rev. B CPU then? If not, please read the errata!
> Eclipse works well to remote debugging aplications over ethernet,
> however, we are not able to debug Linux kernel or u-boot using Eclipse.
> When it stops in the first breakpoint, I can´t view some variables and
> stepping into a function, it shows another. It seems that Eclipse has
> problems with Linux kernel and u-boot symbols.
My guess is that what you see is the effects of the chip errata -
please read the errata sheet.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery
[-- Attachment #2: instantánea1.png --]
[-- Type: image/png, Size: 12938 bytes --]
[-- Attachment #3: instantánea2.png --]
[-- Type: image/png, Size: 117172 bytes --]
^ permalink raw reply
* [PATCH] Remove arch/ppc/syslib/ppc4xx_pm.c
From: Alexey Dobriyan @ 2006-01-26 10:50 UTC (permalink / raw)
To: Andrew Morton, Paul Mackerras; +Cc: linuxppc-dev, Domen Puncer, linux-kernel
From: Domen Puncer <domen@coderock.org>
Remove nowhere referenced file ("grep ppc4xx_pm -r ." didn't find anything).
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/ppc/syslib/ppc4xx_pm.c | 47 --------------------------------------------
1 file changed, 47 deletions(-)
--- a/arch/ppc/syslib/ppc4xx_pm.c
+++ b/arch/ppc/syslib/ppc4xx_pm.c
@@ -1,47 +0,0 @@
-/*
- * Author: Armin Kuster <akuster@mvista.com>
- *
- * 2002 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- * This an attempt to get Power Management going for the IBM 4xx processor.
- * This was derived from the ppc4xx._setup.c file
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-
-#include <asm/ibm4xx.h>
-
-void __init
-ppc4xx_pm_init(void)
-{
-
- unsigned int value = 0;
-
- /* turn off unused hardware to save power */
-#ifdef CONFIG_405GP
- value |= CPM_DCP; /* CodePack */
-#endif
-
-#if !defined(CONFIG_IBM_OCP_GPIO)
- value |= CPM_GPIO0;
-#endif
-
-#if !defined(CONFIG_PPC405_I2C_ADAP)
- value |= CPM_IIC0;
-#ifdef CONFIG_STB03xxx
- value |= CPM_IIC1;
-#endif
-#endif
-
-
-#if !defined(CONFIG_405_DMA)
- value |= CPM_DMA;
-#endif
-
- mtdcr(DCRN_CPMFR, value);
-
-}
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Stefan Roese @ 2006-01-26 10:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43D7D334.3070709@ovro.caltech.edu>
On Wednesday 25 January 2006 20:36, David Hawkins wrote:
> I haven't looked for it yet, but do you know if there is a driver
> for the Yosemite board I2C temperature sensor already written?
The Analog Devices AD7414 is used on Yosemite/Yellowstone and it doesn't seem
to be supported from the lm-sensors project right now. Shouldn't be that
difficult to write a driver for it though.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-26 8:55 UTC (permalink / raw)
To: Akinobu Mita, linux-kernel, Ivan Kokshaysky, Ian Molton,
dev-etrax, David Howells, Yoshinori Sato, Linus Torvalds,
linux-ia64, Hirokazu Takata, linux-m68k, Greg Ungerer, linux-mips,
parisc-linux, linuxppc-dev, linux390, linuxsh-dev,
linuxsh-shmedia-dev, sparclinux, ultralinux, Miles Bader,
Andi Kleen, Chris Zankel
In-Reply-To: <20060126000618.GA5592@twiddle.net>
On Wed, Jan 25, 2006 at 04:06:18PM -0800, Richard Henderson wrote:
> On Wed, Jan 25, 2006 at 08:02:50PM +0000, Russell King wrote:
> > > + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> > > + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> > > + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
> ...
> > Basically, shifts which depend on a variable are more expensive than
> > constant-based shifts.
>
> Actually, they're all constant shifts. Just written stupidly.
Unfortunately that's not correct. You do not appear to have checked
the compiler output like I did - this code does _not_ generate
constant shifts.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Ian Molton @ 2006-01-25 23:25 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-m68k, linux-ia64, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060125200250.GA26443@flint.arm.linux.org.uk>
Russell King wrote:
> This code generates more expensive shifts than our (ARMs) existing C
> version. This is a backward step.
>
> Basically, shifts which depend on a variable are more expensive than
> constant-based shifts.
arm26 will have the same problem here.
^ permalink raw reply
* Re: [PATCH] Updated Patch to add support for Freescale 83xx Host Mode USB
From: Kumar Gala @ 2006-01-26 5:15 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20060125161959.GC4390@dmt.cnet>
On Jan 25, 2006, at 10:19 AM, Marcelo Tosatti wrote:
> On Mon, Jan 23, 2006 at 04:59:33PM -0700, Randy Vinson wrote:
>> Greetings,
>> I've attached an updated patch (based on 2.6.16-rc1) which adds
>> Host mode support for the Dual-Role(DR) and Multi-Port-Host (MPH) USB
>> controllers found in the Freescale 8349. The update was to
>> reconcile the
>> port numbering scheme such that it matches the 8349 documentation.
>> Since
>> my previous patch has not yet gone upstream, the maintainer
>> requested a
>> fresh patch.
>>
>> Note that this patch only provides the platform-specific code that
>> sets up the external hardware and pin configuration. The actual DR
>> and
>> MPH controller driver was posted on the linux-usb-devel mailing list.
>>
>> Using a Freescale 8349CDS reference board, the DR and MPH
>> controllers have been successfully tested using a USB 2.0 high speed
>> FLASH drive, a USB 1.1 full speed 4-port hub and a Siemens
>> SpeedStream
>> USB to Ethernet adapter (assuming the previous 8349 driver updates
>> posted to linux-usb-devel have been applied).
>>
>> Randy Vinson
>> MontaVista Software
>
>> Adding platform support for the 834x Host Mode USB controller.
>>
>> This patch provides the platform-specific hardware setup required
>> by the
>> 83xx Host Mode USB controller on the Freescale 8349CDS reference
>> system.
>>
>> Signed-off-by: Randy Vinson <rvinson@mvista.com>
>>
>> ---
>> commit 30caa62b0e433b466b0880efa32375359b6e4fea
>> tree e9bacf15ad1a58f6f15a343a2b5f233affec0ca1
>> parent a3d36ef38dcdcbbc7e1860f2f92569145524b1d5
>> author Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006
>> 16:46:39 -0700
>> committer Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006
>> 16:46:39 -0700
>>
>> arch/ppc/Kconfig | 2 +
>> arch/ppc/platforms/83xx/Kconfig | 28 +++++++++
>> arch/ppc/platforms/83xx/mpc834x_sys.c | 100 +++++++++++++++++++++
>> ++++++++++++
>> arch/ppc/platforms/83xx/mpc834x_sys.h | 3 +
>> arch/ppc/syslib/mpc83xx_devices.c | 16 +++++
>> include/asm-ppc/mpc83xx.h | 17 ++++++
>> 6 files changed, 166 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
>> index 11899f0..b33b0eb 100644
>> --- a/arch/ppc/Kconfig
>> +++ b/arch/ppc/Kconfig
>> @@ -681,6 +681,8 @@ config EV64360
>> platform.
>> endchoice
>>
>> +source arch/ppc/platforms/83xx/Kconfig
>> +
>> config PQ2ADS
>> bool
>> depends on ADS8272
>> diff --git a/arch/ppc/platforms/83xx/Kconfig b/arch/ppc/platforms/
>> 83xx/Kconfig
>> new file mode 100644
>> index 0000000..90bc67a
>> --- /dev/null
>> +++ b/arch/ppc/platforms/83xx/Kconfig
>> @@ -0,0 +1,28 @@
>> +config 834x_USB_SUPPORT
>> + bool "834x USB Support"
>> + depends on MPC834x_SYS
>> + default y
>> + ---help---
>> + Enables support for the USB controllers on the MPC834x chip.
>> The 834x
>> + reference board is wired for only one USB port. That port may be
>> + used by either the MPH or DR USB controller.
>> + Requires USB Host EHCI support.
>> + If unsure, say Y.
>> +choice
>> + prompt "834x USB Controller Selection"
>> + depends on 834x_USB_SUPPORT
>> + default 834x_DR_USB_SUPPORT
>> +
>> +config 834x_DR_USB_SUPPORT
>> + bool "DR Controller"
>> + select USB_EHCI_ROOT_HUB_TT
>> + ---help---
>> + Select if using the Dual-Role (DR) USB controller.
>> +
>> +config 834x_MPH_USB_SUPPORT
>> + bool "MPH Controller"
>> + ---help---
>> + Select if using the Multi-Port-Host (MPH) USB controller.
>> +
>> +endchoice
>> +
>> diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/
>> platforms/83xx/mpc834x_sys.c
>> index 012e1e6..319661e 100644
>> --- a/arch/ppc/platforms/83xx/mpc834x_sys.c
>> +++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
>> @@ -11,6 +11,9 @@
>> * under the terms of the GNU General Public License as
>> published by the
>> * Free Software Foundation; either version 2 of the License,
>> or (at your
>> * option) any later version.
>> + *
>> + * USB setup added by Randy Vinson <rvinson@mvista.com> based on
>> code from
>> + * Hunter Wu.
>> */
>>
>> #include <linux/config.h>
>> @@ -93,6 +96,99 @@ mpc83xx_exclude_device(u_char bus, u_cha
>> }
>> #endif /* CONFIG_PCI */
>>
>> +/*
>> + * Configure the on-chip USB controller. The MPC834xCDS only
>> supports the
>> + * second USB interface (port 1). This code sets up the hardware
>> and then
>> + * lets the platform driver take over device setup.
>> + */
>> +
>> +#ifdef CONFIG_834x_USB_SUPPORT
>> +void mpc834x_board_init(void)
>> +{
>> + unsigned char __iomem *bcsr;
>> + volatile unsigned char *bcsr5_p;
>> +
>> + /*
>> + * if SYS board is plug into PIB board,
>> + * force to use the PHY on SYS board
>> + * */
>> + bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
>> + bcsr5_p = bcsr + BCSR5_OFF;
>> + if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
>> + *bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
>
> Randy,
>
> Can you please use in/out io accessors instead of direct memory
> references
> to ?
Marcelo, good comment. Just, an FYI. This patch of Randy's isn't
going into the kernel. I ask him to post it just so it was on list.
I wonder if sparse would be capable of warning for doing direct
pointer load/store on __iomem pointers.
- kumar
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Edgar Toernig @ 2006-01-26 4:34 UTC (permalink / raw)
To: Richard Henderson
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, Andi,
linuxsh-shmedia-dev, Linus Torvalds, Kokshaysky, Ivan,
Akinobu Mita, Chris Zankel, dev-etrax, ultralinux, linux-kernel,
linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060126000618.GA5592@twiddle.net>
Richard Henderson wrote:
>
> On Wed, Jan 25, 2006 at 08:02:50PM +0000, Russell King wrote:
> > > + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> > > + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> > > + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
> ...
> > Basically, shifts which depend on a variable are more expensive than
> > constant-based shifts.
>
> Actually, they're all constant shifts. Just written stupidly.
Why shift at all?
int ffs(u32 word)
{
int bit = 0;
word &= -word; // only keep the lsb.
if (word & 0xffff0000) bit |= 16;
if (word & 0xff00ff00) bit |= 8;
if (word & 0xf0f0f0f0) bit |= 4;
if (word & 0xcccccccc) bit |= 2;
if (word & 0xaaaaaaaa) bit |= 1;
return bit;
}
Ciao, ET.
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Paul Mackerras @ 2006-01-26 4:12 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-m68k, linux-ia64, ultralinux, Andi Kleen,
Linux Kernel Development, Linux/PPC Development, Chen, Kenneth W,
'Geert Uytterhoeven', sparclinux, linux390, linuxsh-dev,
parisc-linux
In-Reply-To: <20060126035004.GA11543@miraclelinux.com>
Akinobu Mita writes:
> I can fix this without changing the flags size for those architectures.
>
> 1. Introduce *_le_bit() bit operations which takes void *addr
> (already I have these functions in the scope of
> HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS in my patch)
>
> 2. Change flags to __u8 flags[4] or __u8 flags[8] for each architectures.
>
> 3. Use *_le_bit() in include/linux/thread_info.h
Please don't do this, you'll break the powerpc assembly code that
tests bits in thread_info()->flags.
Paul.
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Akinobu Mita @ 2006-01-26 3:50 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: linux-m68k, linux-ia64, ultralinux, Linux Kernel Development,
Andi Kleen, Linux/PPC Development, 'Geert Uytterhoeven',
sparclinux, linux390, linuxsh-dev, parisc-linux
In-Reply-To: <200601252002.k0PK2Mg31276@unix-os.sc.intel.com>
On Wed, Jan 25, 2006 at 12:02:21PM -0800, Chen, Kenneth W wrote:
> Geert Uytterhoeven wrote on Wednesday, January 25, 2006 9:19 AM
> > > I don't think you need to change the flags size.
> >
> > Passing a pointer to a 32-bit entity to a function that takes a
> > pointer to a 64-bit entity is a classical endianness bug. So it's
> > better to change it, before people copy the code to a big endian
> > platform.
>
> Well, x86-64 and linux-ia64 both use little endian. I don't
> understand why you are barking at us with big endian issue.
>
I can fix this without changing the flags size for those architectures.
1. Introduce *_le_bit() bit operations which takes void *addr
(already I have these functions in the scope of
HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS in my patch)
2. Change flags to __u8 flags[4] or __u8 flags[8] for each architectures.
3. Use *_le_bit() in include/linux/thread_info.h
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Akinobu Mita @ 2006-01-26 2:13 UTC (permalink / raw)
To: Keith Owens
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <24086.1138190083@ocs3.ocs.com.au>
On Wed, Jan 25, 2006 at 10:54:43PM +1100, Keith Owens wrote:
> Be very, very careful about using these generic *_bit() routines if the
> architecture supports non-maskable interrupts.
>
> NMI events can occur at any time, including when interrupts have been
> disabled by *_irqsave(). So you can get NMI events occurring while a
> *_bit fucntion is holding a spin lock. If the NMI handler also wants
> to do bit manipulation (and they do) then you can get a deadlock
> between the original caller of *_bit() and the NMI handler.
>
> Doing any work that requires spinlocks in an NMI handler is just asking
> for deadlock problems. The generic *_bit() routines add a hidden
> spinlock behind what was previously a safe operation. I would even say
> that any arch that supports any type of NMI event _must_ define its own
> bit routines that do not rely on your _atomic_spin_lock_irqsave() and
> its hash of spinlocks.
At least cris and parisc are using similar *_bit function on SMP.
I will add your advise in comment.
--- ./include/asm-generic/bitops.h.orig 2006-01-26 10:56:00.000000000 +0900
+++ ./include/asm-generic/bitops.h 2006-01-26 11:01:28.000000000 +0900
@@ -50,6 +50,16 @@ extern raw_spinlock_t __atomic_hash[ATOM
* C language equivalents written by Theodore Ts'o, 9/26/92
*/
+/*
+ * NMI events can occur at any time, including when interrupts have been
+ * disabled by *_irqsave(). So you can get NMI events occurring while a
+ * *_bit fucntion is holding a spin lock. If the NMI handler also wants
+ * to do bit manipulation (and they do) then you can get a deadlock
+ * between the original caller of *_bit() and the NMI handler.
+ *
+ * by Keith Owens
+ */
+
static __inline__ void set_bit(int nr, volatile unsigned long *addr)
{
unsigned long mask = BITOP_MASK(nr);
^ permalink raw reply
* Re: [PATCH 4/6] use include/asm-generic/bitops for each architecture
From: Akinobu Mita @ 2006-01-26 1:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-ia64, Ian Molton, David Howells, linuxppc-dev,
Greg Ungerer, sparclinux, Miles Bader, Linus Torvalds,
Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev, linux-m68k,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, Andi Kleen, linuxsh-dev, linux390, Russell King,
parisc-linux
In-Reply-To: <20060125113336.GE18584@miraclelinux.com>
On Wed, Jan 25, 2006 at 08:33:37PM +0900, mita wrote:
> compile test on i386, x86_64, ppc, sparc, sparc64, alpha
> boot test on i386, x86_64, ppc
>
I have fogotten attaching the changes for each archtecture.
o alpha
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- if defined(__alpha_cix__) and defined(__alpha_fix__)
- define HAVE_ARCH_FLS_BITOPS
- define HAVE_ARCH_HWEIGHT_BITOPS
- define HAVE_ARCH_HWEIGHT64_BITOPS
- else
- remove fls()
- remove hweight64()
- remove hweight{32,16,8}()
- remove fls64()
- remove find_{next,first}{,_zero}_bit()
- define HAVE_ARCH_SCHED_BITOPS
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o arm
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- if __LINUX_ARM_ARCH__ < 5
- remove ffz()
- remove __ffs()
- remove fls()
- remove ffs()
- else (__LINUX_ARM_ARCH__ >= 5)
- define HAVE_ARCH_FLS_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- remove fls64()
- remove hweight64()
- remove hweight{32,16,8}()
- remove sched_find_first_bit()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove HAVE_ARCH_MINIX_BITOPS
o arm26
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- remove ffz()
- remove __ffs()
- remove fls()
- remove fls64()
- remove ffs()
- remove sched_find_first_bit()
- remove hweight{32,16,8}()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- define HAVE_MINIX_BITOPS
o cris
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- remove fls()
- remove fls64()
- remove hweight{32,16,8}()
- remove find_{next,first}{,_zero}_bit()
- define HAVE_ARCH_FFS_BITOPS
- remove sched_find_first_bit()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o frv
- remove ffz()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- remove find_{next,first}{,_zero}_bit()
- remove ffs()
- remove __ffs()
- remove fls64()
- remove sched_find_first_bit()
- remove hweight{32,16,8}()
- define HAVE_ARCH_FLS_BITOPS
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- define HAVE_ARCH_MINIX_BITOPS
o h8300
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- remove ffs()
- remove find_{next,first}{,_zero}_bit()
- remove sched_find_first_bit()
- remove hweight{32,16,8}()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- define HAVE_ARCH___FFS_BITOPS
- remove fls()
- remove fls64()
o i386
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- remove fls64()
- remove sched_find_first_bit()
- define HAVE_ARCH_FFS_BITOPS
- remove hweight{32,16,8}()
- define HAVE_ARCH_FLS_BITOPS
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o ia64
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- remove fls64()
- define HAVE_ARCH_FLS_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH_HWEIGHT_BITOPS
- define HAVE_ARCH_HWEIGHT64_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- remove sched_find_first_bit()
o m32r
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- remove ffz()
- remove find_{next,first}{,_zero}_bit()
- remove __ffs()
- remove fls()
- remove fls64()
- remove sched_find_first_bit()
- remove ffs()
- remove hweight()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
o m68k
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- remove fls64()
- remove sched_find_first_bit()
- remove ffs()
- remove hweight()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_MINIX_BITOPS
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
o m68knommu
- remove ffs()
- remove __ffs()
- remove sched_find_first_bit()
- remove ffz()
- remove find_{next,first}{,_zero}_bit()
- remove hweight()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- define HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- remove fls()
- remove fls64()
o mips
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- if defined(CONFIG_CPU_MIPS32) or defined(CONFIG_CPU_MIPS64)
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH_FLS_BITOPS
- else
- remove __ffs()
- remove ffs()
- remove ffz()
- remove fls()
- remove fls64()
- remove find_{next,first}{,_zero}_bit()
- remove sched_find_first_bit()
- remove hweight()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o s390
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- remove ffs()
- remove fls()
- remove fls64()
- remove hweight()
- remove hweight64()
- define HAVE_ARCH_SCHED_BITOPS
- define HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o sh
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- remove find_{next,first}{,_zero}_bit()
- remove ffs()
- remove hweight()
- remove sched_find_first_bit()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- remove fls()
- remove fls64()
o sh64
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- remove __ffs()
- remove find_{next,first}{,_zero}_bit()
- remove hweight()
- remove sched_find_first_bit()
- remove ffs()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
- remove fls()
- remove fls64()
o sparc
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- remove ffz()
- remove __ffs()
- remove sched_find_first_bit()
- remove ffs()
- remove fls()
- remove fls64()
- remove hweight{32,16,8}()
- remove find_{next,first}{,_zero}_bit()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o sparc64
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_ATOMIC_BITOPS
- remove ffz()
- remove __ffs()
- remove fls()
- remove fls64()
- remove sched_find_first_bit()
- remove ffs()
- if defined(ULTRA_HAS_POPULATION_COUNT)
- define HAVE_ARCH_HWEIGHT64_BITOPS
- define HAVE_ARCH_HWEIGHT_BITOPS
- else
- remove hweight64()
- remove hweight{32,16,8}()
- define HAVE_ARCH_FIND_BITOPS
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- define HAVE_ARCH_EXT2_NON_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o v850
- remove ffz()
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- remove find_{next,first}{,_zero}_bit()
- remove ffs()
- remove fls()
- remove fls64()
- remove __ffs()
- remove sched_find_first_bit()
- remove hweight{32,16,8}()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o x86_64
- define HAVE_ARCH_ATOMIC_BITOPS
- define HAVE_ARCH_NON_ATOMIC_BITOPS
- define HAVE_ARCH_FIND_BITOPS
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FLS_BITOPS
- remove sched_find_first_bit()
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH_FLS64_BITOPS
- remove hweight{32,16,8}()
- define HAVE_ARCH_FLS_BITOPS
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o xtensa
- remove {,test_and_}{set,clear,change}_bit()
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- define HAVE_ARCH_FFZ_BITOPS
- define HAVE_ARCH___FFS_BITOPS
- define HAVE_ARCH_FFS_BITOPS
- define HAVE_ARCH_FLS_BITOPS
- remove fls64()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- define HAVE_ARCH_EXT2_ATOMIC_BITOPS
- remove hweight{32,16,8}()
- remove sched_find_first_bit()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
o remove unused generic bitops
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Richard Henderson @ 2006-01-26 0:06 UTC (permalink / raw)
To: Akinobu Mita, linux-kernel, Ivan Kokshaysky, Ian Molton,
dev-etrax, David Howells, Yoshinori Sato, Linus Torvalds,
linux-ia64, Hirokazu Takata, linux-m68k, Greg Ungerer, linux-mips,
parisc-linux, linuxppc-dev, linux390, linuxsh-dev,
linuxsh-shmedia-dev, sparclinux, ultralinux, Miles Bader,
Andi Kleen, Chris Zankel
In-Reply-To: <20060125200250.GA26443@flint.arm.linux.org.uk>
On Wed, Jan 25, 2006 at 08:02:50PM +0000, Russell King wrote:
> > + s = 16; if (word << 16 != 0) s = 0; b += s; word >>= s;
> > + s = 8; if (word << 24 != 0) s = 0; b += s; word >>= s;
> > + s = 4; if (word << 28 != 0) s = 0; b += s; word >>= s;
...
> Basically, shifts which depend on a variable are more expensive than
> constant-based shifts.
Actually, they're all constant shifts. Just written stupidly.
r~
^ permalink raw reply
* Re: [PATCH] Updated Patch to add support for Freescale 83xx Host Mode USB
From: Marcelo Tosatti @ 2006-01-25 16:19 UTC (permalink / raw)
To: Randy Vinson; +Cc: linuxppc-embedded
In-Reply-To: <43D56DE5.5040004@mvista.com>
On Mon, Jan 23, 2006 at 04:59:33PM -0700, Randy Vinson wrote:
> Greetings,
> I've attached an updated patch (based on 2.6.16-rc1) which adds
> Host mode support for the Dual-Role(DR) and Multi-Port-Host (MPH) USB
> controllers found in the Freescale 8349. The update was to reconcile the
> port numbering scheme such that it matches the 8349 documentation. Since
> my previous patch has not yet gone upstream, the maintainer requested a
> fresh patch.
>
> Note that this patch only provides the platform-specific code that
> sets up the external hardware and pin configuration. The actual DR and
> MPH controller driver was posted on the linux-usb-devel mailing list.
>
> Using a Freescale 8349CDS reference board, the DR and MPH
> controllers have been successfully tested using a USB 2.0 high speed
> FLASH drive, a USB 1.1 full speed 4-port hub and a Siemens SpeedStream
> USB to Ethernet adapter (assuming the previous 8349 driver updates
> posted to linux-usb-devel have been applied).
>
> Randy Vinson
> MontaVista Software
> Adding platform support for the 834x Host Mode USB controller.
>
> This patch provides the platform-specific hardware setup required by the
> 83xx Host Mode USB controller on the Freescale 8349CDS reference system.
>
> Signed-off-by: Randy Vinson <rvinson@mvista.com>
>
> ---
> commit 30caa62b0e433b466b0880efa32375359b6e4fea
> tree e9bacf15ad1a58f6f15a343a2b5f233affec0ca1
> parent a3d36ef38dcdcbbc7e1860f2f92569145524b1d5
> author Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006 16:46:39 -0700
> committer Randy Vinson <rvinson@linuxbox.(none)> Mon, 23 Jan 2006 16:46:39 -0700
>
> arch/ppc/Kconfig | 2 +
> arch/ppc/platforms/83xx/Kconfig | 28 +++++++++
> arch/ppc/platforms/83xx/mpc834x_sys.c | 100 +++++++++++++++++++++++++++++++++
> arch/ppc/platforms/83xx/mpc834x_sys.h | 3 +
> arch/ppc/syslib/mpc83xx_devices.c | 16 +++++
> include/asm-ppc/mpc83xx.h | 17 ++++++
> 6 files changed, 166 insertions(+), 0 deletions(-)
>
> diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
> index 11899f0..b33b0eb 100644
> --- a/arch/ppc/Kconfig
> +++ b/arch/ppc/Kconfig
> @@ -681,6 +681,8 @@ config EV64360
> platform.
> endchoice
>
> +source arch/ppc/platforms/83xx/Kconfig
> +
> config PQ2ADS
> bool
> depends on ADS8272
> diff --git a/arch/ppc/platforms/83xx/Kconfig b/arch/ppc/platforms/83xx/Kconfig
> new file mode 100644
> index 0000000..90bc67a
> --- /dev/null
> +++ b/arch/ppc/platforms/83xx/Kconfig
> @@ -0,0 +1,28 @@
> +config 834x_USB_SUPPORT
> + bool "834x USB Support"
> + depends on MPC834x_SYS
> + default y
> + ---help---
> + Enables support for the USB controllers on the MPC834x chip. The 834x
> + reference board is wired for only one USB port. That port may be
> + used by either the MPH or DR USB controller.
> + Requires USB Host EHCI support.
> + If unsure, say Y.
> +choice
> + prompt "834x USB Controller Selection"
> + depends on 834x_USB_SUPPORT
> + default 834x_DR_USB_SUPPORT
> +
> +config 834x_DR_USB_SUPPORT
> + bool "DR Controller"
> + select USB_EHCI_ROOT_HUB_TT
> + ---help---
> + Select if using the Dual-Role (DR) USB controller.
> +
> +config 834x_MPH_USB_SUPPORT
> + bool "MPH Controller"
> + ---help---
> + Select if using the Multi-Port-Host (MPH) USB controller.
> +
> +endchoice
> +
> diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
> index 012e1e6..319661e 100644
> --- a/arch/ppc/platforms/83xx/mpc834x_sys.c
> +++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
> @@ -11,6 +11,9 @@
> * under the terms of the GNU General Public License as published by the
> * Free Software Foundation; either version 2 of the License, or (at your
> * option) any later version.
> + *
> + * USB setup added by Randy Vinson <rvinson@mvista.com> based on code from
> + * Hunter Wu.
> */
>
> #include <linux/config.h>
> @@ -93,6 +96,99 @@ mpc83xx_exclude_device(u_char bus, u_cha
> }
> #endif /* CONFIG_PCI */
>
> +/*
> + * Configure the on-chip USB controller. The MPC834xCDS only supports the
> + * second USB interface (port 1). This code sets up the hardware and then
> + * lets the platform driver take over device setup.
> + */
> +
> +#ifdef CONFIG_834x_USB_SUPPORT
> +void mpc834x_board_init(void)
> +{
> + unsigned char __iomem *bcsr;
> + volatile unsigned char *bcsr5_p;
> +
> + /*
> + * if SYS board is plug into PIB board,
> + * force to use the PHY on SYS board
> + * */
> + bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
> + bcsr5_p = bcsr + BCSR5_OFF;
> + if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
> + *bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
Randy,
Can you please use in/out io accessors instead of direct memory references
to ?
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: David S. Miller @ 2006-01-26 0:04 UTC (permalink / raw)
To: paulus
Cc: linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev, gerg,
sparclinux, uclinux-v850, ysato, takata, linuxsh-dev, torvalds,
ink, rth, mita, chris, dev-etrax, ultralinux, linux-m68k,
linux-kernel, linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <17367.64370.844350.972910@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Thu, 26 Jan 2006 09:28:02 +1100
> Akinobu Mita writes:
>
> > If the arechitecture is
> > - BITS_PER_LONG == 64
> > - struct thread_info.flag 32 is bits
> > - second argument of test_bit() was void *
> >
> > Then compiler print error message on test_ti_thread_flags()
> > in include/linux/thread_info.h
>
> And correctly so. The correct fix is to make thread_info.flag an
> unsigned long. This patch is NAKed.
I agree.
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Frank @ 2006-01-25 23:46 UTC (permalink / raw)
To: Carlos Munoz; +Cc: linuxppc-embedded
In-Reply-To: <43D7DC34.8050604@kenati.com>
--- Carlos Munoz <carlos@kenati.com> wrote:
> Frank wrote:
>
> >I remember reading a while back that the 2.6 kernel is
> >considerably slower then the 2.4 kernel (Wolfgang Denx). Has
> >anybody taken any performance measurements on a later kernel
> >version to see if the above still hods true?
> >
> >I'm thinking about moving to 2.6 since a lot of open source
> >projects have stopped suporting the 2.4 kernel.
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Tired of spam? Yahoo! Mail has the best spam protection
> around
> >http://mail.yahoo.com
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> Hi Frank,
>
> While at my previous company we tried to move to the 2.6
> kernel (can't
> remember the version, however it was a little over a year ago)
> from the
> 2.4.20 kernel. The 2.6 kernel could not keep up with our
> stress tests,
> not even close. Unfortunately, I don't have any hard data. We
> spent
> about 2 weeks trying to figure out why the performance
> degradation.
> However, since there was no real need to use the 2.6 kernel
> other than
> for better performance, and due to other pressing projects,
> management
> decided to put on hold the upgrade to 2.6, and as far as I
> know they are
> still on the 2.4 kernel. A lot has changed on 2.6 since then,
> so maybe
> the performance is better now. You can always compare them
> both and post
> your results.
>
> Thanks,
>
>
> Carlos Munoz
Thanks, I let eneryone know what i find out...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Grant Likely @ 2006-01-25 23:44 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Txema Lopez, John Rigby, linuxppc-embedded
In-Reply-To: <43D807E0.1090206@246tNt.com>
Sylvain Munaut wrote:
>
> I haven't gotten around setup a git tree ... anyone know a good tutorial
> not only on how to checkout stuff but how to well manage a remote
> repository for publishing ?
Try this link; I've got it bookmarked as "Git Essentials" :)
http://wellington.pm.org/archive/200510/git/
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: Problem getting code from git repository
From: Wolfgang Denk @ 2006-01-25 23:40 UTC (permalink / raw)
To: marty.wedepohl; +Cc: linuxppc-embedded
In-Reply-To: <1f82ba6e0601231256s15cb73dehdb6dd53ed50c38de@mail.gmail.com>
In message <1f82ba6e0601231256s15cb73dehdb6dd53ed50c38de@mail.gmail.com> you wrote:
> When I attempt to retrieve the current source from the git repository
> I get the following
>
> Any suggestions ??? Martin
Do you use a current version of the git tools? The same commands
worked perfectly fine for me when I checked ... I'm using git-1.1.2
and cogito-0.6.3 on a FC4 system:
-> rpm -qa | grep git
git-core-1.1.2-1.fc4
git-1.1.2-1.fc4
git-cvs-1.1.2-1.fc4
git-svn-1.1.2-1.fc4
git-arch-1.1.2-1.fc4
cogito-0.16.3-1.fc4
gitk-1.1.2-1.fc4
-> cd /tmp/
-> cg-clone http://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx.git/
/tmp/linux-2.6-denx.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for http://www.denx.de/git/linux-2.6-denx.git/
Getting pack list for http://www.denx.de/git/linux-2.6-denx.git/
Getting index for pack b3c6fbdfa36a326815de6358885c7a570a986b1b
Getting index for pack 459148e2ea863c15479d69ed4886a6f200c79a49
Getting index for pack ad1ecbdb18e6a825fafa9f57ebb11a5dbe6e12ef
Getting index for pack 2dae6bb81ac4383926b1d6a646e3f73b130ba124
Getting index for pack dcd74895edc829753c14248afdcc8537c7c62207
Getting pack dcd74895edc829753c14248afdcc8537c7c62207
which contains 1c06cf5a9851a83493f5b5f3749b4ced4e07af29
Getting pack 2dae6bb81ac4383926b1d6a646e3f73b130ba124
which contains 5014bfa48ac169e0748e1e9651897788feb306dc
Getting pack ad1ecbdb18e6a825fafa9f57ebb11a5dbe6e12ef
which contains 7b7ed3723b67cacdad7d664ed4392339925810a3
Getting pack 459148e2ea863c15479d69ed4886a6f200c79a49
which contains e12c24654003c0f3e033fe05ba6d703c01a992e3
Fetching tags...
Missing tag DENX-2005-10-02-1830... retrieved
Missing tag DENX-2005-12-03-2208... retrieved
Missing tag DENX-v2.6.15... retrieved
Missing tag v2.6.11-tree... retrieved
Missing tag v2.6.11... retrieved
Missing tag v2.6.12-rc2... retrieved
Missing tag v2.6.12-rc3... retrieved
Missing tag v2.6.12-rc4... retrieved
Missing tag v2.6.12-rc5... retrieved
Missing tag v2.6.12-rc6... retrieved
Missing tag v2.6.12... retrieved
Missing tag v2.6.13-rc1... retrieved
Missing tag v2.6.13-rc2... retrieved
Missing tag v2.6.13-rc3... retrieved
Missing tag v2.6.13-rc4... retrieved
Missing tag v2.6.13-rc5... retrieved
Missing tag v2.6.13-rc6... retrieved
Missing tag v2.6.13-rc7... retrieved
Missing tag v2.6.13... retrieved
Missing tag v2.6.14-rc1... retrieved
Missing tag v2.6.14-rc2... retrieved
Missing tag v2.6.14-rc3-BAD... retrieved
Missing tag v2.6.14-rc3... retrieved
Missing tag v2.6.14-rc4... retrieved
Missing tag v2.6.14-rc5... retrieved
Missing tag v2.6.14... retrieved
Missing tag v2.6.15-rc1... retrieved
Missing tag v2.6.15-rc2... retrieved
Missing tag v2.6.15-rc3... retrieved
Missing tag v2.6.15-rc4... retrieved
Missing tag v2.6.15-rc5... retrieved
Missing tag v2.6.15-rc6... retrieved
New branch: 1c06cf5a9851a83493f5b5f3749b4ced4e07af29
Cloned to linux-2.6-denx.git// (origin http://www.denx.de/git/linux-2.6-denx.git available as branch "origin")
-> echo RC=$?
RC=0
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"This isn't brain surgery; it's just television." - David Letterman
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Sylvain Munaut @ 2006-01-25 23:21 UTC (permalink / raw)
To: Txema Lopez; +Cc: John Rigby, linuxppc-embedded
In-Reply-To: <43D751F8.9060204@aotek.es>
Hi
Txema Lopez wrote:
> Sylvain Munaut wrote:
>> John Rigby wrote:
>>> Here is an updated patch for the liteb board.
>>>
> We have a Lite5200b and are very interesting in this point.
>
> For wich kernel version is this patch?
Should apply fine on vanilla. My suggestion for now is take vanilla,
apply this patch, then the 2-3 patch from Andrey for BestComm and stuff.
I haven't gotten around setup a git tree ... anyone know a good tutorial
not only on how to checkout stuff but how to well manage a remote
repository for publishing ?
>> Looks good. But two comments :
>>
>> * Isn't a modif to the arch/ppc/platform/Makefile missing ?
>> * What's the "cs-1" you turn on there :
>>
>>
>>
>>>
>>> +#ifdef CONFIG_LITE5200B
>>> + /* turn on cs1 */
>>> + port_config |= 0x80000000;
>>> +#endif
>>>
> What fix this ?
It's to activate the second bank of DDR-SDRAM. However, I find that's
the job of the bootloader. Fully initializing the memory subsystem is
one of the few things the kernel expects, so I probably won't include this.
My politics (at least for the 5200 stuff) is the boot loader should :
* Init memory stuff like it wants (at least boot flash & all dynamic
mem). The init of some static chipselect could be done in platform init.
* Put the pin muxes & stuff to the "safest" mode (that is for example
GPIO Input) execpt for what it requires for boot (like a console PSC and
ethernet). All other pin mux (defnitive one) should be done in platform
init depending on the board.
>> I couldn't find the schema / real-doc of the Lite5200b,
>> is this available somewhere on-line ?
>>
> Sylvain, I don't know if there are some Lite5200b doc on line, but I
> have the schematics and could send to you or to anyone who want it.
Yes, please, I'd appreciate an early copy.
John sent the link to the User Manual but the latter hasn't the full
schematic.
Sylvain
^ permalink raw reply
* Re: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Paul Mackerras @ 2006-01-25 22:28 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-mips, linux-ia64, Ian Molton, Andi Kleen, David Howells,
linuxppc-dev, Greg Ungerer, sparclinux, Miles Bader,
Yoshinori Sato, Hirokazu Takata, linuxsh-dev, Linus Torvalds,
Ivan Kokshaysky, Richard Henderson, Chris Zankel, dev-etrax,
ultralinux, linux-m68k, linux-kernel, linuxsh-shmedia-dev,
linux390, Russell King, parisc-linux
In-Reply-To: <20060125113446.GF18584@miraclelinux.com>
Akinobu Mita writes:
> If the arechitecture is
> - BITS_PER_LONG == 64
> - struct thread_info.flag 32 is bits
> - second argument of test_bit() was void *
>
> Then compiler print error message on test_ti_thread_flags()
> in include/linux/thread_info.h
And correctly so. The correct fix is to make thread_info.flag an
unsigned long. This patch is NAKed.
Paul.
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-25 20:34 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060125201320.GB19460@gate.ebshome.net>
> DO NOT access UIC registers directly. DO NOT.
Okay :)
> Nothing that can be of interest for a general public. They are
> board-specific (lots of bit-banging SPI stuff). All other drivers I
> wrote are already in public tree.
With regard to SPI drivers. Has the 2.6 kernel implemented
an SPI 'bus' interface (like PCI, OCP, etc). The 440EP also
has an SPI interface that I plan to look at.
The custom boards will need temperature sensing and other
monitoring jobs. I want to see what kind of overhead both
the I2C and SPI bus require. If its too much, then I'll
move those tasks out into an FPGA FSM.
The PowerPC's main job will be reading FPGA data every 1ms,
int-to-float conversions, FFT, and accumulation.
Cheers
Dave
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Carlos Munoz @ 2006-01-25 20:14 UTC (permalink / raw)
To: Frank; +Cc: linuxppc-embedded
In-Reply-To: <20060123042413.806.qmail@web32201.mail.mud.yahoo.com>
Frank wrote:
>I remember reading a while back that the 2.6 kernel is
>considerably slower then the 2.4 kernel (Wolfgang Denx). Has
>anybody taken any performance measurements on a later kernel
>version to see if the above still hods true?
>
>I'm thinking about moving to 2.6 since a lot of open source
>projects have stopped suporting the 2.4 kernel.
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
Hi Frank,
While at my previous company we tried to move to the 2.6 kernel (can't
remember the version, however it was a little over a year ago) from the
2.4.20 kernel. The 2.6 kernel could not keep up with our stress tests,
not even close. Unfortunately, I don't have any hard data. We spent
about 2 weeks trying to figure out why the performance degradation.
However, since there was no real need to use the 2.6 kernel other than
for better performance, and due to other pressing projects, management
decided to put on hold the upgrade to 2.6, and as far as I know they are
still on the 2.4 kernel. A lot has changed on 2.6 since then, so maybe
the performance is better now. You can always compare them both and post
your results.
Thanks,
Carlos Munoz
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: Eugene Surovegin @ 2006-01-25 20:13 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43D7D5A1.70704@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 11:46:41AM -0800, David Hawkins wrote:
> Hi Eugene,
>
> >>Now while looking at some of the other drivers, I noticed the use
> >>of the following syntax:
> >>
> >> unsigned long flags;
> >> local_irq_save(flags);
> >>
> >> ... mfdcr, mtdcr, etc operations ...
> >>
> >> local_irq_restore(flags);
> >>
> >>which is treating the operations on the DCRs as a critical section.
> >>
> >>I should probably be doing the same when I enable the external IRQs
> >>and modify the GPIO registers.
> >
> >You have to use locks if you access GPIO registers, because other bits
> >can be used by other device drivers, although there is no drivers in
> >the official tree which use GPIO (I have tons of them in my private
> >tree and I added global "gpio_lock" to serialize GPIO access).
>
> What kind of global lock; a spinlock?
yes, spinlock.
> What is the advantage of say using the gpio_lock, rather than
> the irq_save/restore sequence above - which is what is used in
> the emac and usb code?
emac doesn't use GPIO registers :). Also, if there is no IRQ code
accesses GPIO registers, you don't need IRQ disabling lock, and
spin_lock effectively becomes just a preemption lock. Personally, I use
spinlocks just out of habit, I think it's a good style, even if you
know your chip doesn't support SMP (but some day might :).
> >DCRs are a little different, there are separate DCR for different
> >peripherals, so generally, you don't have to use locks, because those
> >DCR accesses are implicitly bound to particular device anyway and
> >device "owns" them.
>
> Right, but I was accessing the DCR for the UIC status register,
> which, I assume, is also used by the Linux IRQ handling subsystem.
DO NOT access UIC registers directly. DO NOT.
> Well, ok perhaps that is not a good example, I have not tested
> whether the IRQ handler in the example code I posted needs to
> clear the UIC1_SR bit, or whether the Linux IRQ handling code
> already takes care of it. I suspect the latter, since the IRQ
> could be shared, and Linux needs to go through and call all
> handlers on that IRQ line.
>
> But in a debug context of reading those registers, I would
> expect some form of lock holding would be recommended.
> Do you happen to know if the Linux IRQ handling code uses a
> lock?
4xx IRQ code takes care of all this. You don't need to mess with UIC
registers. 4xx PIC code doesn't use locks because it's being called
from special context (IRQs disabled), 4xx doesn't support SMP and PIC
code "owns" those DCRs.
> I'm just learning, so feel free to enlighten me.
>
> What drivers do you have in your 'private' tree that you might
> be willing to share?
Nothing that can be of interest for a general public. They are
board-specific (lots of bit-banging SPI stuff). All other drivers I
wrote are already in public tree.
--
Eugene
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox