* 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
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Russell King @ 2006-01-25 20:02 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-shmedia-dev,
Linus Torvalds, Ivan Kokshaysky, Richard Henderson, Chris Zankel,
dev-etrax, ultralinux, linux-m68k, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060125113206.GD18584@miraclelinux.com>
On Wed, Jan 25, 2006 at 08:32:06PM +0900, Akinobu Mita wrote:
> +#ifndef HAVE_ARCH___FFS_BITOPS
> +
> +/**
> + * __ffs - find first bit in word.
> + * @word: The word to search
> + *
> + * Returns 0..BITS_PER_LONG-1
> + * Undefined if no bit exists, so code should check against 0 first.
> + */
> +static inline unsigned long __ffs(unsigned long word)
> {
> - int mask;
> + int b = 0, s;
>
> - addr += nr >> 5;
> - mask = 1 << (nr & 0x1f);
> - return ((mask & *addr) != 0);
> +#if BITS_PER_LONG == 32
> + 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;
> + s = 2; if (word << 30 != 0) s = 0; b += s; word >>= s;
> + s = 1; if (word << 31 != 0) s = 0; b += s;
> +
> + return b;
> +#elif BITS_PER_LONG == 64
> + s = 32; if (word << 32 != 0) s = 0; b += s; word >>= s;
> + s = 16; if (word << 48 != 0) s = 0; b += s; word >>= s;
> + s = 8; if (word << 56 != 0) s = 0; b += s; word >>= s;
> + s = 4; if (word << 60 != 0) s = 0; b += s; word >>= s;
> + s = 2; if (word << 62 != 0) s = 0; b += s; word >>= s;
> + s = 1; if (word << 63 != 0) s = 0; b += s;
> +
> + return b;
> +#else
> +#error BITS_PER_LONG not defined
> +#endif
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.
I've not really looked at the rest because I haven't figured out which
bits will be used on ARM and which won't - which I think is another
problem with this patch set. I'll look again later tonight.
--
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 5/6] fix warning on test_ti_thread_flag()
From: Chen, Kenneth W @ 2006-01-25 20:02 UTC (permalink / raw)
To: 'Geert Uytterhoeven'
Cc: Akinobu Mita, linux-m68k, linux-ia64, ultralinux,
Linux Kernel Development, Andi Kleen, Linux/PPC Development,
sparclinux, linux390, linuxsh-dev, parisc-linux
In-Reply-To: <Pine.LNX.4.62.0601251814350.19174@pademelon.sonytel.be>
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.
- Ken
Side-note: cc list trimmed.
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-25 19:46 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060125185518.GB7425@gate.ebshome.net>
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?
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?
> 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.
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?
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?
I'm planning on putting the 440EP on custom boards with a
number of Altera FPGAs located in the peripheral bus. I'll
post results and code as I go. Ulimately I'll open-source
the lot (hardware and all).
Here's the existing hardware I'm revising:
http://www.ovro.caltech.edu/~dwh/correlator
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Eugene Surovegin @ 2006-01-25 19:48 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43D7D334.3070709@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 11:36:20AM -0800, David Hawkins wrote:
[snip]
> 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?
I have no idea what temp sensor is used in this board, but it's very
likely that lm-sensors project already has a driver for it (look
under Drivers/Hardware Monitoring support).
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-25 19:36 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060125185131.GA7425@gate.ebshome.net>
Hi Eugene,
>
> use in_/out_ accessors, not pointers. Look at other 4xx drivers (i2c,
> emac)
>
> Also, you don't have worry about this code being non-portable, because
> every chip has it's own GPIO impl anyway.
>
Thanks for the feedback.
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?
If its not, that might be a nice little exercise for me.
Thanks,
Dave
^ permalink raw reply
* Re: 2.4.x vs 2.6.x performance
From: Otto Solares @ 2006-01-25 18:41 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <c8c05211d33576b79dee80725822322b@embeddedalley.com>
On Wed, Jan 25, 2006 at 07:45:38AM -0800, Dan Malek wrote:
> I wouldn't say "considerably" slower, but there are some
> performance differences. It's most evident on the
> smaller, slower processors, like the 8xx, but we have
> taken steps to alleviate that. The problem is 2.6 is just
> bigger with more stuff in it. You want the new features,
> you have to pay for that somewhere. I think it would
> help if the kernel was a little more configurable for
> embedded systems. It seems there is just too much
> stuff in a basic kernel that I wish could be stripped out.
Many things can be stripped out with LinuxTiny patches:
http://www.selenic.com/linux-tiny/
-otto
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: Eugene Surovegin @ 2006-01-25 18:55 UTC (permalink / raw)
To: David Hawkins; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <43D7C3C6.8020709@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 10:30:30AM -0800, David Hawkins wrote:
>
> Hi Stephan,
>
> > You seem to have used the wrong IRQ number though. Please see below.
> >
> > You are using the "External IRQ 8". This results in IRQ number 19 of the 2nd
> > interrupt controller of the 440ep. So please try (19+32) as the IRQ number
> > upon requesting the interrupt.
>
> Yep, that was it!
>
> 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).
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.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: Eugene Surovegin @ 2006-01-25 18:51 UTC (permalink / raw)
To: David Hawkins; +Cc: Stefan Roese, linuxppc-embedded
In-Reply-To: <43D7C2EF.5060508@ovro.caltech.edu>
On Wed, Jan 25, 2006 at 10:26:55AM -0800, David Hawkins wrote:
> Hi Stefan,
>
> >>readl() and ioread32() read the registers in little-endian format!
> >
> > Correct. That's how it is implemented on all platforms. Think for example of
> > an pci device driver. Using these IO functions, the driver will become
> > platform independent, running without modifications on little- and big-endian
> > machines.
>
> Ok, I figured that was probably the case. Thanks for the confirmation.
>
> >>Should I just be using pointers for remapped processor
> >>registers, and only use readl(), ioread32(), etc, on external
> >>memory?
> >
> > That's how I do it. Only use readl() and friends for pci spaces (or other
> > little endian memory mapped areas).
>
> I took a look at the Yosemite network and USB drivers, it looks like
> the authors of those drivers chose to use in_be32() and out_be32().
>
> Personally I like the concept of using pointers, or more usefully
> pointers to structure overlays for device control. However, the
> impression I have is that this is inherently more non-portable
> than using the readl()/writel(), ioread32()/iowrite32(), and
> now I guess I can add in_be32()/out_be32() to that list.
>
> But if you use pointers, thats good enough for me!
use in_/out_ accessors, not pointers. Look at other 4xx drivers (i2c,
emac)
Also, you don't have worry about this code being non-portable, because
every chip has it's own GPIO impl anyway.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP is there a global interrupt enable mask?
From: David Hawkins @ 2006-01-25 18:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601251128.05370.sr@denx.de>
Hi Stephan,
> You seem to have used the wrong IRQ number though. Please see below.
>
> You are using the "External IRQ 8". This results in IRQ number 19 of the 2nd
> interrupt controller of the 440ep. So please try (19+32) as the IRQ number
> upon requesting the interrupt.
Yep, that was it!
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.
Any comments on that?
Dave
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-25 18:26 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601251057.47619.sr@denx.de>
Hi Stefan,
>>readl() and ioread32() read the registers in little-endian format!
>
> Correct. That's how it is implemented on all platforms. Think for example of
> an pci device driver. Using these IO functions, the driver will become
> platform independent, running without modifications on little- and big-endian
> machines.
Ok, I figured that was probably the case. Thanks for the confirmation.
>>Should I just be using pointers for remapped processor
>>registers, and only use readl(), ioread32(), etc, on external
>>memory?
>
> That's how I do it. Only use readl() and friends for pci spaces (or other
> little endian memory mapped areas).
I took a look at the Yosemite network and USB drivers, it looks like
the authors of those drivers chose to use in_be32() and out_be32().
Personally I like the concept of using pointers, or more usefully
pointers to structure overlays for device control. However, the
impression I have is that this is inherently more non-portable
than using the readl()/writel(), ioread32()/iowrite32(), and
now I guess I can add in_be32()/out_be32() to that list.
But if you use pointers, thats good enough for me!
Cheers
Dave
^ permalink raw reply
* RE: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Geert Uytterhoeven @ 2006-01-25 17:19 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: Linux/MIPS Development, linux-m68k, linux-ia64, Ian Molton,
Andi Kleen, David Howells, Linux/PPC Development, 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 Development, linuxsh-dev, linux390,
Russell King, parisc-linux
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB509780224@scsmsx401.amr.corp.intel.com>
On Wed, 25 Jan 2006, Chen, Kenneth W wrote:
> Geert Uytterhoeven wrote on Wednesday, January 25, 2006 4:29 AM
> > On Wed, 25 Jan 2006, Akinobu Mita wrote:
> > > 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
> > >
> > > Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> > > ---
> > > thread_info.h | 2 +-
> > > 1 files changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Index: 2.6-git/include/linux/thread_info.h
> > > ===================================================================
> > > --- 2.6-git.orig/include/linux/thread_info.h 2006-01-25
> 19:07:12.000000000 +0900
> > > +++ 2.6-git/include/linux/thread_info.h 2006-01-25
> 19:14:26.000000000 +0900
> > > @@ -49,7 +49,7 @@
> > >
> > > static inline int test_ti_thread_flag(struct thread_info *ti, int
> flag)
> > > {
> > > - return test_bit(flag,&ti->flags);
> > > + return test_bit(flag, (void *)&ti->flags);
> > > }
> >
> > This is not safe. The bitops are defined to work on unsigned long
> only, so
> > flags should be changed to unsigned long instead, or you should use a
> > temporary.
> >
> > Affected platforms:
> > - alpha: flags is unsigned int
> > - ia64, sh, x86_64: flags is __u32
> >
> > The only affected 64-platforms are little endian, so it will silently
> work
> > after your change, though...
>
> I thought test_bit can operate on array beyond unsigned long.
> It's perfectly legitimate to do: test_bit(999, bit_array) as
> long as bit_array is indeed big enough to hold 999 bits. It
> is the responsibility of the caller to make sure that the
> underlying array is big enough for the bit that is being tested.
Yes, it can operate on arrays of unsigned long.
> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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