LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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

* RE: [PATCH 5/6] fix warning on test_ti_thread_flag()
From: Chen, Kenneth W @ 2006-01-25 17:08 UTC (permalink / raw)
  To: Geert Uytterhoeven, Akinobu Mita
  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, Chris Zankel, dev-etrax, ultralinux,
	Linux Kernel Development, linuxsh-dev, linux390, Russell King,
	parisc-linux

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 =3D=3D 64
> > - struct thread_info.flag 32 is bits
> > - second argument of test_bit() was void *
> >=20
> > Then compiler print error message on test_ti_thread_flags()
> > in include/linux/thread_info.h
> >=20
> > Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
> > ---
> >  thread_info.h |    2 +-
> >  1 files changed, 1 insertion(+), 1 deletion(-)
> >=20
> > Index: 2.6-git/include/linux/thread_info.h
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- 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 @@
> > =20
> >  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);
> >  }
>=20
> 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.
>=20
> Affected platforms:
>   - alpha: flags is unsigned int
>   - ia64, sh, x86_64: flags is __u32
>=20
> 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.

I don't think you need to change the flags size.

- Ken

^ permalink raw reply

* Re: Enable Billionton PCMCIA Bluetooth in MPC860 system (again)
From: Lo Chun Chung @ 2006-01-25 16:56 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

I also found a such message here: http://ozlabs.org/pipermail/linuxppc-embedded/2000-May/001402.html
   
  it says:
   
  "... The 8250/16550 driver (serial.c) probes at init-time which will cause
problems. .... "
   
  I want to know are there anyone fixed this problem? 
  
Thanks all.
   
  Best regards,
  Lo Chun Chung
  
Lo Chun Chung <lcsquare2@yahoo.com.hk> 說:
    Dear all,

  Hi again, I have asked a same question here before (http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021617.html), now I have some discoveries ... but I still do not know how to solve.
   
  (My system is a MPC860 Processor Card, plus a custom made PCB to provide a PCMCIA interface, now the latest progress is I can use PCMCIA WLAN cards in this system without any problem. But my main target is use a PCMCIA Bluetooth card ... )
   
  I have noticed when I load up the "serial.o", function "rs_init" must be executed, inside this function call, a function "autoconfig" will be called.
   
  My problem is due to this "autoconfig", it will try to parse a standard uart to determine what is its model. But my case is my standard uart is a PCMCIA Bluetooth Card.
   
  I can simply comment out the function "rs_init" to let the "serial.o" do not run this function. But later when I load the module "serial_cs", many problems happened. (seems "rs_init" will initialize other things that I have not done ...)
   
  Since "serial_cs" (the pcmcia uart driver) needs two function calls in "serial.o" (they are: resgister_serial() and unregister_serial() ), so I really need load up "serial.o" before I  can load up "serial_cs.o"
   
  So my problem is, how can I setup such driver in MPC860 environment with a PCMCIA ? 
   
  Thanks all~
  
Best regards,
Chung



Best regards,
Chung  _______________________________________
YM - 離線訊息
就算你沒有上網,你的朋友仍可以留下訊息給你,當你上網時就能立即看到,任何說話都冇走失。
http://messenger.yahoo.com.hk
  


_______________________________________
 YM - 離線訊息
 就算你沒有上網,你的朋友仍可以留下訊息給你,當你上網時就能立即看到,任何說話都冇走失。
 http://messenger.yahoo.com.hk

[-- Attachment #2: Type: text/html, Size: 2856 bytes --]

^ permalink raw reply

* Re: Misunderstanding with function cpm_dpalloc in Linux 2.6.x
From: Pantelis Antoniou @ 2006-01-25 16:14 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <000001c621b5$f8e45ab0$5201a8c0@GEG2400>

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

On Wednesday 25 January 2006 15:48, Laurent Lagrange wrote:
> 
> Hello,
> 
> I work on MPC boards with Linux 2.6.9 and I have a problem with the
> cpm_dpalloc function.
> 
> In the file cpm2_common.c the function "uint cpm_dpalloc(uint size, uint
> align)" is intended
> to allocate a piece of memory in the dpram. This piece of memory has at
> least "size" bytes
> and I beleived that the returned address should be aligned on "align" bytes.
> 
> This function calls "void *rh_alloc(rh_info_t * info, int size, const char
> *owner)" from rheap.c file.
> In this function the alignment is only used to calculate the right size with
> the formula :
> size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
> It seems to be right but the alignment is not used to retreive an aligned
> start address.
> 
> So if I do the following sequential calls, I have the following results :
> cpm_dpalloc(16, 8)	-> 	0XC0		-> right aligned
> cpm_dpalloc(64, 64)	-> 	0XD0		-> wrong aligned -> must be 0x100
> cpm_dpalloc(16, 8)	-> 	0X110		-> right aligned but wrong to use
> cpm_dpalloc(24, 8)	-> 	0X1200		-> right aligned but wrong to use
> 
> I can have the wanted values if instead of size, I try to allocate (size +
> align - 1) bytes
> but I don't think it is the solution.
> 
> Perhaps, I don't understand the allocation theory.
> Any idea ?
> 
> Thanks all
> Laurent
> 
> 

Laurent Hi,

Yes this is a know bug. This patch fixes it.

Marcelo, please apply - we have this hanging for quite a while.

Pantelis

[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-diff, Size: 4160 bytes --]

diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
 	return (void *)s;
 }
 
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
 {
 	struct list_head *l;
 	rh_block_t *blk;
 	rh_block_t *newblk;
 	void *start;
 
-	/* Validate size */
-	if (size <= 0)
+	/* Validate size, (must be power of two) */
+	if (size <= 0 || (alignment & (alignment - 1)) != 0)
 		return ERR_PTR(-EINVAL);
 
+	/* given alignment larger that default rheap alignment */
+	if (alignment > info->alignment)
+		size += alignment - 1;
+
 	/* Align to configured alignment */
 	size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
 
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
 
 	attach_taken_block(info, newblk);
 
+	/* for larger alignment return fixed up pointer  */
+	/* this is no problem with the deallocator since */
+	/* we scan for pointers that lie in the blocks   */
+	if (alignment > info->alignment)
+		start = (void *)(((unsigned long)start + alignment - 1) &
+				~(alignment - 1));
+
 	return start;
 }
 
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+	return rh_alloc_align(info, size, info->alignment, owner);
+}
+
 /* allocate at precisely the given address */
 void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
 {
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
 	unsigned long flags;
 
 	spin_lock_irqsave(&cpm_dpmem_lock, flags);
-	cpm_dpmem_info.alignment = align;
-	start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+	start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
 	spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
 
 	return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
 EXPORT_SYMBOL(cpm_dpfree);
 
 /* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
 {
 	void *start;
 	unsigned long flags;
 
 	spin_lock_irqsave(&cpm_dpmem_lock, flags);
-	cpm_dpmem_info.alignment = align;
 	start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
 	spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
 
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
 extern	cpm8xx_t	*cpmp;		/* Pointer to comm processor */
 extern uint cpm_dpalloc(uint size, uint align);
 extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
 extern void cpm_dpdump(void);
 extern void *cpm_dpram_addr(uint offset);
 extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern		cpm_cpm2_t	*cpmp;	 /* Pointer to
 
 extern uint cpm_dpalloc(uint size, uint align);
 extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
 extern void cpm_dpdump(void);
 extern void *cpm_dpram_addr(uint offset);
 extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t * 
 /* Detach a free region */
 extern void *rh_detach_region(rh_info_t * info, void *start, int size);
 
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+		const char *owner);
+
 /* Allocate the given size from the remote heap */
 extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
 

^ permalink raw reply

* Re: Trouble with SMC serial port in ppc/boot/simple on Embedded Planet8248 board
From: Laurent Pinchart @ 2006-01-25 16:09 UTC (permalink / raw)
  To: Steven Blakeslee; +Cc: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB942B7F8@ep-01.EmbeddedPlanet.local>

> > I'm trying to port the Linux kernel (2.6.15.1) to the
> > Embedded Planet 8248 board. The board has a proprietary boot
> > loader and uses SMC1 has a serial console.
>
> Do you have SCC1 enabled also?  In arch/ppc/boot/simple/m8260_tty.c you
> will see that if SCC1 is enabled the early text tries to print to it,
> even if SMC1 is selected as the console in the config.  That was about
> the only trick to do to get the early text.

I commented that line to fix the problem, and I was thinking about either a 
configuration option (CONFIG_SERIAL_CONSOLE_SCCx and 
CONFIG_SERIAL_CONSOLE_SMCx) or a macro in the platform-specifix header file 
to override that. Any comment ?

Laurent Pinchart

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox