* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-12 18:13 UTC (permalink / raw)
To: Grant Likely, Liam Girdwood, linuxppc-dev, alsa-devel, timur
In-Reply-To: <20080712173609.GA6523@sirena.org.uk>
On Sat, Jul 12, 2008 at 11:36 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> The power configuration should be fixed, though. Normally drivers
> either fully implement DAPM (including set_bias_level()) or power
> everything in the codec up when the driver is loaded. At the minute
> what the driver is doing appears to be powering the codec up in both
> _hw_params() and _probe() but never powering anything down - if that is
> the case then probably all you need to do is remove the extra power up
> from hw_params(), giving you the simple option.
Okay, cool. I'll do this for the time being then.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-12 18:14 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080712180959.GB6523@sirena.org.uk>
On Sat, Jul 12, 2008 at 12:10 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
>
>> ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
>> v1 API, so I don't expect it to get merged as-is, but I want to get it
>> out there for review.
>
> I've not reviewed this revision of these drivers yet but I just wanted
> to point out that there's absoluely no problem with merging v1 drivers -
> so long as a driver uses the existing merged APIs there's no issue from
> that point of view.
Oops, I forgot to update my commit messages. I'll probably repost v3
of the series this evening and I'll fix this.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Please pull linux-2.6-mpc52xx tree
From: Grant Likely @ 2008-07-12 18:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Andre Schwarz, Stephen Rothwell
Hi Ben,
Please pull the following patches for MPC5xxx support.
git://git.secretlab.ca/git/linux-2.6-mpc52xx next
Thanks,
g.
The following changes since commit 0db9360aaa9b95b0cf67f82874809f16e68068eb:
Nathan Fontenot (1):
powerpc/pseries: Update numa association of hotplug memory add
for drconf memory
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx next
Andre Schwarz (1):
powerpc/mpc5200: PCI write combine timer
Grant Likely (3):
powerpc/mpc5200: Add PSC helpers for bestcomm engine
powerpc/mpc5200: fix compile warnings in bestcomm driver
powerpc: Modify MPC52xx maintainers entry to cover all MPC5xxx parts
John Rigby (4):
powerpc/mpc5121: Update device tree for MPC5121ADS evaluation board
powerpc/mpc5121: Add clock driver
powerpc/mpc5121: Add generic board support for MPC5121 platforms
powerpc/mpc5121: Add support for CPLD on MPC5121ADS board
Jon Smirl (1):
powerpc/i2c: Convert i2c-mpc into an of_platform driver
Robert P. J. Day (1):
OpenFirmware: Include <linux/of_i2c.h> from of_i2c.c.
Stephen Rothwell (3):
powerpc/pata_mpc52xx: use linux/of_platform.h instead of asm
powerpc/mpc52xx_psc_spi: use linux/of_platform.h instead of asm
powerpc/mpc5200_wdt: use linux/of_platform.h instead of asm
Wolfgang Grandegger (1):
powerpc/mpc5200: add missing MSCAN FDT nodes for TQM52xx
MAINTAINERS | 4 +-
Makefile | 1 +
arch/powerpc/boot/dts/mpc5121ads.dts | 310 ++++++++++-
arch/powerpc/boot/dts/tqm5200.dts | 14 +
arch/powerpc/platforms/512x/Kconfig | 17 +-
arch/powerpc/platforms/512x/Makefile | 4 +-
arch/powerpc/platforms/512x/clock.c | 729 ++++++++++++++++++++++++
arch/powerpc/platforms/512x/mpc5121_ads.c | 69 +--
arch/powerpc/platforms/512x/mpc5121_ads.h | 16 +
arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 204 +++++++
arch/powerpc/platforms/512x/mpc5121_generic.c | 58 ++
arch/powerpc/platforms/512x/mpc512x.h | 17 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 83 +++
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 3 +-
arch/powerpc/sysdev/bestcomm/bestcomm.c | 2 +-
arch/powerpc/sysdev/bestcomm/gen_bd.c | 95 +++
arch/powerpc/sysdev/bestcomm/gen_bd.h | 5 +
arch/powerpc/sysdev/bestcomm/sram.c | 2 +-
arch/powerpc/sysdev/fsl_soc.c | 133 -----
drivers/ata/pata_mpc52xx.c | 2 +-
drivers/i2c/busses/i2c-mpc.c | 104 ++--
drivers/of/of_i2c.c | 1 +
drivers/spi/mpc52xx_psc_spi.c | 2 +-
drivers/watchdog/mpc5200_wdt.c | 2 +-
24 files changed, 1620 insertions(+), 257 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/clock.c
create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.h
create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
create mode 100644 arch/powerpc/platforms/512x/mpc5121_generic.c
create mode 100644 arch/powerpc/platforms/512x/mpc512x.h
create mode 100644 arch/powerpc/platforms/512x/mpc512x_shared.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: insmod: unresolved symbol XIo_In32/XIo_Out32
From: Juliana Su @ 2008-07-12 19:22 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20080711210514.GB18239@secretlab.ca>
Hi again,
Ok, so I tried mapping to in_be32( ) and out_be32( ) by changing:
#define XIo_In32(InputPtr) (*(volatile u32 *)(InputPtr)); SYNCHRONIZE_IO;
to
#define XIo_In32(InputPtr) in_be32(InputPtr)
and
#define XIo_Out32(OutputPtr, Value) \
{ (*(volatile u32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
to
#define XIo_Out32(OutputPtr, Value) out_be32(OutputPtr, Value)
I made sure to include asm-ppc/io.h, too. However, I still get the same
unresolved symbol error message... Did I do the mapping correctly?
Thanks again for your help!
-Juliana
Grant Likely wrote:
> On Fri, Jul 11, 2008 at 03:11:06PM -0400, Juliana Su wrote:
>
>> Hi,
>>
>> Thanks for your reply! I am new to creating loadable kernel modules, so
>> I hope you do not mind some more questions... How can I get the XIo_*
>> helper routines to compile into the kernel or export them with
>> EXPORT_SYMBOL( )? In my c file (my driver file from which I create the
>> object file), I made sure to include xio.h, which is where XIo_In32 and
>> XIo_Out32 are defined (see below section from xio.h).
>>
>
> Add an EXPORT_SYMBOL() line to the location where the io accessors are
> implemented. However, you'd probably be better just to replace xio.h
> implementation with macros that just map them to the in_be32() and
> out_be32() macros.
>
> g.
>
>
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Milton Miller @ 2008-07-12 22:32 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <Pine.LNX.4.64.0807101654080.6791@localhost.localdomain>
On Fri Jul 11 00:59:25 EST 2008, Roman Zippel wrote:
> On Thu, 10 Jul 2008, Michael Ellerman wrote:
>
> > Well yes :) But I think that's because you're thinking of
> > "end-users" and I'm thinking of "users" like myself - ie. _I_ use
> > Kconfig and I do expect myself to be able to type a 64-bit address.
>
> That doesn't really answer my question, why you need this.
>
> > > > --- .config.orig 2008-07-08 09:30:00.000000000 +1000
> > > > +++ .config 2008-07-08 09:30:43.000000000 +1000
> > > > @@ -370,9 +370,8 @@
> > > > CONFIG_HOTPLUG_PCI_RPA=m
> > > > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > > > # CONFIG_HAS_RAPIDIO is not set
> > > > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > > > -CONFIG_KERNEL_START=0xc000000002000000
> > > > -CONFIG_PHYSICAL_START=0x02000000
> > > > +CONFIG_PAGE_OFFSET=0xc0000000
> > > > +CONFIG_PHYSICAL_START=0x2000000
> > >
> > > Why is this worse? These are constants, you're not supposed to
> change them
> > > anyway.
> > > The remaining values are generated in page.h and should be the
> same as
> > > before. If that isn't the case and this patch produces a nonworking
> > > kernel, I'd like to hear about it.
> >
> > You're right the built kernel is fine. So it's not a bug,
>
But its horrible code.
> Good, could someone please ack whether the powerpc changes are
> acceptable?
>
Well, since no one else has said it,
NAK
The primary reason I object is this:
>>>> Index: linux-2.6/include/asm-powerpc/page.h
>>>> ===================================================================
>>>> --- linux-2.6.orig/include/asm-powerpc/page.h
>>>> +++ linux-2.6/include/asm-powerpc/page.h
>>>> @@ -67,9 +67,15 @@
>>>> * If you want to test if something's a kernel address, use
>>>> is_kernel_addr().
>>>> */
>>>>
>>>> -#define KERNELBASE ASM_CONST(CONFIG_KERNEL_START)
>>>> +#ifdef CONFIG_PPC64
>>>> +#define PAGE_OFFSET (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>>> +#define KERNELBASE
>>>> (PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET PAGE_OFFSET
>>>> +#else
>>>> +#define KERNELBASE ASM_CONST(CONFIG_KERNEL_START)
>>>> #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
>>>> -#define LOAD_OFFSET
>>>> ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
>>>> +#define LOAD_OFFSET
>>>> (ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START))
>>>> +#endif
>>>>
>>>> #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
>>>> #ifndef __ASSEMBLY__
(1) #define PAGE_OFFSET (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
It creates unreadable code, where two defines with almost the same name
(the only difference being
the CONFIG_ prefix, which is often ignored when scanning) contains
radically different values.
(2) #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
It creates config variables that mean different things depending on
other config variables
The 32 and 64 bit powerpc kernel share a common source, a config
variable should be used for
only one purpose.
> > but I think it is nicer to have the real values in the .config.
>
> Why?
Mostly consistency between the different portions of the archticture.
As I remember, this code was adjusted and some of the defines moved
from page.h
as part of the 32 bit relocatable kernel for 85xx booke ASMP support.
The 32 bit kernel has advanced options to change the VMA split, which
enable
direct user input when explicitly defined. That allows us to not need
patches
for the embedded boards who need some other split than 3G/1G. So there
is the reason that we have this directly specified in Kconfig at all.
While the 64 bit kernel doesn't need to actually change the page
offset, as we
don't support the full 64 bits of the real address anyways (in fact, the
archtiecture prevents us from doing so) and therefore don't need to
adjust
the effective address spilt between user and kernel.
But introducing config variables that mean different things is
UNMAINTAINABLE.
Also, I remember, CONFIG_PAGE_OFFSET is used by the linker script and
previously
page.h was conditionally included. Does it always include page.h now?
On a seperate note,
>>>> config PINT3_ASSIGN
>>>> hex "PINT3_ASSIGN"
>>>> depends on PINTx_REASSIGN
>>>> - default 0x02020303
>>>> + default 0x2020303
is harder to read. The value is a list of 4 1 byte values, but you
have hidden the first nibble making parsing the rest of the value hard.
>>>>
>>>> config IRAM_SIZE
>>>> hex "Internal memory size (hex)"
>>>> depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 ||
>>>> CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM
>>>> - default "00080000" if CHIP_M32700
>>>> - default "00010000" if CHIP_M32102 || CHIP_OPSP ||
>>>> CHIP_M32104
>>>> - default "00008000" if CHIP_VDEC2
>>>> + default "0x80000" if CHIP_M32700
>>>> + default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104
>>>> + default "0x8000" if CHIP_VDEC2
Likewize, I find it easier to mentally check the order of magnitude and
compare sizes when they have
leading zeros and are right aligned.
Going to another email in the thread,
On Fri Jul 11 00:52:25 EST 2008, Roman Zippel wrpte:
> On Tue, 8 Jul 2008, Sam Ravnborg wrote:
> > We use Kconfig for a mixture of user editable values and fixed
> > configuration values.
> > And I agree that asking the user to input a 64 bit number is not
> usefull.
> >
> > But keeping support for 64 bit values is what I would consider
> > expected functionality.
...
> > > This would also ease on any portability issues
> > > (kconfig is compiled with the host compiler not the target
> compiler).
> >
> > We use strtol() in a few places in symbol.c already where we do an
> > implicit conversion to int. Why did this not cause us problems
> before?
> >
> > Is it because these code paths are only triggered when we deal with
> ranges?
> > If so we could 'fix' strdup_type() to not use strto{,u}l() so it
> > is 64 bit clean and we are back to old behaviour.
>
> Ranges are the primary reason I made it consistent with this.
> If we really wanted to support 64bit numbers, it would create only more
> problems. First you have to make sure that on every build host (i.e
> also
> non-Linux) strtoll() is available. Then how it should these numbers be
> represented? On 32bit these may need a 'll' postfix, but the powerpc
> example already shows, that there are different requirements, so they
> use
> ASM_CONST for that. How should this postprecessing be integrated into
> kconfig?
I think the architectures will already do something like ASM_CONST in
their C code when its needed. This should not be the responsibility of
kbuild.
If you are worried about users tring to set values that are too high,
then make the types be hex8, hex16, hex32, and hex64.
milton
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Roman Zippel @ 2008-07-12 23:21 UTC (permalink / raw)
To: Milton Miller
Cc: Stephen Rothwell, linux-kernel, ppcdev, Paul Mackerras,
Sam Ravnborg
In-Reply-To: <7b8dd1f1421b1f52ebc76565986fd2a9@bga.com>
Hi,
On Sat, 12 Jul 2008, Milton Miller wrote:
> (1) #define PAGE_OFFSET (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>
> It creates unreadable code, where two defines with almost the same name (the
> only difference being
> the CONFIG_ prefix, which is often ignored when scanning) contains radically
> different values.
>
> (2) #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
Giving it different names is not really difficult. Any objections to
CONFIG_PAGE_HIGH_OFFSET?
> On a seperate note,
> > > > > config PINT3_ASSIGN
> > > > > hex "PINT3_ASSIGN"
> > > > > depends on PINTx_REASSIGN
> > > > > - default 0x02020303
> > > > > + default 0x2020303
>
> is harder to read. The value is a list of 4 1 byte values, but you have
> hidden the first nibble making parsing the rest of the value hard.
Sam mentioned that already, but that's a situation where the warning can
be relaxed.
> If you are worried about users tring to set values that are too high,
> then make the types be hex8, hex16, hex32, and hex64.
It's not this, I value consistency as much as you and the values are
sometimes used as integers, so a working range is needed. Using simple
integers keeps things much simpler and as the ASM_CONST example shows any
bigger values are not necessarily directly usable anyway.
bye, Roman
^ permalink raw reply
* Re: [i2c] [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
From: Jon Smirl @ 2008-07-13 3:59 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080712080004.GA16739@pengutronix.de>
On 7/12/08, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Fri, Jul 11, 2008 at 12:23:23PM -0600, Grant Likely wrote:
>
> > On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
> > > Firstly kernel warns at set_irq_chip, and then dies completely:
> > >
> > > Trying to install chip for IRQ-1
> > >
> > > diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
> > > index b2ccdcb..95a24de 100644
> > > --- a/drivers/of/of_i2c.c
> > > +++ b/drivers/of/of_i2c.c
> > > @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
> > > if (info.irq == NO_IRQ)
> > > info.irq = -1;
> >
> > What is the reason that info.irq is set to -1 in the first place? This
> > looks like another bug to me. Does something in the i2c layer depend on
> > the -1 value?
> >
>
>
> You already acked a fix to this :) I wasn't sure if my patch would
> make it on its own, as Jon Smirl was also working on fixes to of_i2c.c
> and he seemed to pick up this issue, too.
I did another patch for the mpc-i2c driver changing all of the
comparisons to NO_IRQ. My understanding of this is the ppc has NO_IRQ
set to -1, and powerpc has NO_IRQ = 0. So to make all of this work
right you have to use the NO_IRQ symbol and you can't check against 0
or -1 directly. I also believe work is underway to get all platforms
to NO_IRQ = 0 but I don't know if it is completed yet.
>
> (Original patch is here:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058801.html
> )
>
> All the best,
>
> Wolfram
>
>
> --
> Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIeGSED27XaX1/VRsRAr+EAJ948UwobnY7WSSR4i/ywjof1+8dJACfWzPN
> bhW6NXgBCnwqITIC5rSXeAI=
> =W3sj
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Hans de Goede @ 2008-07-13 6:31 UTC (permalink / raw)
To: Jean Delvare
Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, Milton Miller,
lm-sensors
In-Reply-To: <20080711093650.4b98e3b7@hyperion.delvare>
Jean Delvare wrote:
> On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> Hi Hans, hi Milton,
>>>
>> <snip>
>>
>>>> One could make a superio driver, and create sub-devices for the IR,
>>>> I2C, floppy, parallel, etc
>>>> nodes.
>>> There have been proposals to do this, and this would indeed be a very
>>> good idea, but unfortunately nobody took the time to implement this
>>> properly, push it upstream and volunteer to maintain it. The problem is
>>> that you don't need just a "driver", but a new subsystem, that needs to
>>> be designed and maintained.
>> Well, I believe there have been some lightweight superio locking coordinator
>> patches been floating around on the lm_sensors list, and I have reviewed them
>> and then a new version was done with my issues fixed.
>>
>> I kinda liked the proposed solution there, it was quite simple, moved all the
>> generic superio stuff into generic superio code, and added locking for super io
>> access from multiple drivers, what ever happened to those patches?
>
> As far as I know, nothing, and this is the problem. Somebody needs to
> step up and call him/herself the maintainer of the new code, and push
> it upstream and convert all the drivers (hwmon, watchdog, parallel
> port...) to make use of it. And I am not the one to do this, I am busy
> enough as is with i2c and hwmon.
>
Ok, I've mailed Jim Cromie, the author of the superio access patches
from end 2007 and told him we're still interested in this and asked him
if he is willing to drive this forward.
Regards,
Hans
^ permalink raw reply
* Re: insmod: unresolved symbol XIo_In32/XIo_Out32
From: Joachim Foerster @ 2008-07-13 7:30 UTC (permalink / raw)
To: Juliana Su; +Cc: linuxppc-embedded
In-Reply-To: <4879046A.1020508@bucknell.edu>
Hi,
On Sat, 2008-07-12 at 15:22 -0400, Juliana Su wrote:
> Ok, so I tried mapping to in_be32( ) and out_be32( ) by changing:
>
> #define XIo_In32(InputPtr) (*(volatile u32 *)(InputPtr)); SYNCHRONIZE_IO;
> to
> #define XIo_In32(InputPtr) in_be32(InputPtr)
>
> and
>
> #define XIo_Out32(OutputPtr, Value) \
> { (*(volatile u32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> to
> #define XIo_Out32(OutputPtr, Value) out_be32(OutputPtr, Value)
>
> I made sure to include asm-ppc/io.h, too. However, I still get the same
> unresolved symbol error message... Did I do the mapping correctly?
Hmmm, as Grant already said, you need to replace the _implementation_
(the actual function) by macros. You replaced a #define with another
#define - and a #define is not a symbol (for the compiler, only for
cpp). So - without knowing anything about your MontaVista Linux sources
- I think that the #defines you replaced are _not_ used, instead there
have to be some function _definition_ (in xio.h) you need to replace.
As an example: Xilinx also has a xio.h in their git tree. There one
would have to replace lines 167..173 in
http://git.xilinx.com/cgi-bin/gitweb.cgi?p=linux-2.6-xlnx.git;a=blob;f=drivers/xilinx_common/xio.h;h=7b22a677bbf7769d8698d37397f2174a2cd7e2b2;hb=HEAD
Joachim
^ permalink raw reply
* Re: [RFC] reorganize cputypes for PPC64
From: Marvin @ 2008-07-13 12:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Arnd Bergmann
In-Reply-To: <200807122000.05966.arnd@arndb.de>
Hi,
On Saturday 12 July 2008 20:00:05 Arnd Bergmann wrote:
> On Saturday 12 July 2008, Marvin wrote:
> > attached patch introduces a "processor type" menu similar to ppc32. It
> > _should_ not change anything upto now.
> >
> > The aim is to allow future fine graded cpu optimizations via mcpu/mtune
> > compiler flags and also to clean up the arch Makefile/Kconfig.cputypes (I
> > know this is a minefield).
>
> I tried something similar last year, but failed miserably, because the
> complexity cannot really be contained. I still think it's a good idea,
> but I'm not sure whether your patch will help at all.
before I try to change something, I like to get some feedback about the
direction to take. Therefore your comments are more than welcome.
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype
> > b/arch/powerpc/platforms/Kconfig.cputype index f7efaa9..eebde6c 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -54,35 +54,65 @@ config E200
> >
> > endchoice
> >
> > -config POWER4_ONLY
> > - bool "Optimize for POWER4"
> > +choice
> > + prompt "Processor Type"
> > depends on PPC64
> > + default TUNE_POWER4
> > + help
> > + There are serveral families of 64 bit PowerPC chips supported.
> > + These include the Power3 to Power6 series, 970, and Cell BE
> > based + CPUs made be IBM.
> > +
> > + If unsure, select Power4.
> > +
> > +config TUNE_POWER3
> > + bool "Power3"
> > +
> > +config TUNE_POWER4
> > + bool "Power4"
> > +
> > +config TUNE_970
> > + bool "970/G5"
> > +
> > +config TUNE_POWER5
> > + bool "Power5"
> > +
> > +config TUNE_POWER6
> > + bool "Power6"
> > +
> > +config TUNE_CELL
> > + bool "Cell Broadband Engine"
> > + help
> > + Cause the compiler to optimize for the PPE of the Cell
> > Broadband + Engine. This will make the code run considerably
> > faster on Cell + but somewhat slower on other machines. If the
> > resulting kernel is + built to run only on Cell BE machines,
> > select also OPT_EXCLUSIVE. +
> > +endchoice
>
> What about the other CPUs? There is also RS64, Power5+, PA6T and Power7.
I grepped the source (especially the defconfigs) and it seems, that there is
only one distinction between the different PPC64 archs named POWER3. POWER4
is always set on PPC64 archs, POWER3 is not set on G5, maple and pasemi.
Grepping further reveals, that POWER3 is mentioned in mm/pgtable_32.c only,
where is used to define HAVE_BATS (it exists also in asm/cputable.h, which is
a candidate for cleanup -> replace !POWER4 && !POWER3 by !PPC64).
My daring conclusion is therefore:
1. POWER3 could be replaced by HAVE_BATS
2. POWER4 could be replaced by PPC64
The only processor dependant config left is the tuning option. gcc has no
special option for power7 or pa6t yet, but the reorg should be flexible, so
new tuning options can be added easily. RS64 could be added to the tuneing
options.
> > +
> > +config OPT_EXCLUSIVE
> > + bool "Optimize to run exclusive on selected CPU"
> > default n
> > - ---help---
> > - Cause the compiler to optimize for POWER4/POWER5/PPC970
> > processors. - The resulting binary will not work on POWER3 or
> > RS64 processors - when compiled with binutils 2.15 or later.
> > + help
> > + Cause the compiler to optimize to run exclusive on the selected
> > + CPU. The resulting binary will probably not work on other CPUs.
> > +
> > + If the compiler/binutils combination does not support the
> > exclusive + optimization, it will try to tune only or fail.
> > +
> > + If you are unsure, select no.
>
> Almost all CPUs are backwards compatible, so the option should not
> be labelled 'exclusive'. In general, if you build for PowerX, it will
> also run on Power(X+1). 970 is backwards compatible to Power4, Cell
> and PA6T are backwards compatible to 970, Power6 is backwards compatible
> to both of these.
>
> Also, there are good reasons to have the -mcpu option different from
> -mtune. E.g. you may want to use Power4 compatible instructions but
> tune for Power6 in a typical distro kernel.
ok. That would mean to have two config menus:
- optimize to run exclusive on cpu_x or higher
- tune for cpu_y, and use instruction set for cpu_x, where x<=y
That seems to be rather complex and I think this is also unrealistic, because
there are often only two cases:
- a distro doesn't want to maintain one kernel per cpu. So they always choose
common instructions and tune for some higher cpu (likely power4).
- a high end user (or specilized distro), who wants to compile his own kernel
for maximum performance compiles exlusive only (e.g. for cell be).
This is why I choosed "select cpu" menu and a bool for exclusive (use mcpu) or
not (use mtune). Another option would be to add a string prompt, so the user
can enter his own tuning options "-mcpu=cpu_x -mtune=cpu_y", but I think this
is undesired.
> > config POWER3
> > - bool
> > depends on PPC64
> > - default y if !POWER4_ONLY
> > + def_bool y if !POWER4_ONLY
> >
> > config POWER4
> > depends on PPC64
> > def_bool y
> >
> > -config TUNE_CELL
> > - bool "Optimize for Cell Broadband Engine"
> > +config POWER4_ONLY
> > depends on PPC64
> > - help
> > - Cause the compiler to optimize for the PPE of the Cell
> > Broadband - Engine. This will make the code run considerably
> > faster on Cell - but somewhat slower on other machines. This
> > option only changes - the scheduling of instructions, not the
> > selection of instructions - itself, so the resulting kernel will
> > keep running on all other - machines. When building a kernel that
> > is supposed to run only - on Cell, you should also select the
> > POWER4_ONLY option. + def_bool y if TUNE_POWER4 && OPT_EXCLUSIVE
> >
> > config 6xx
> > bool
>
> Tuning for Cell gives a significant performance bonus on cell based
> machines with a new compiler, and again, you would typically want to use
> the Power4 instruction set, but not restrict to Power3 or use all of the
> Cell instructions.
That's again the "distro/high end user" question discussed above. I think this
was raised several times in the past on this list without a common
conclusion. A small survey shows, that distros are shipping kernels for ppc32
(sometimes prep and chrp) and ppc64 (common, iseries, pseries, and ps3) for
installation only and provide a single image for updates. Maybe this would
change if there is a choice....
Thanks
Marvin
^ permalink raw reply
* EXT2-fs error when trying to work with highmem
From: Nadav Sharabi @ 2008-07-13 14:21 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6053 bytes --]
Hi All,
I have built a 2.6.14 image and Ramdisk for my board witch has a ppc 8349
processor with 1G DDR. The system works file if I build it without highmem
support but if I try to add highmem support to the system, witch I need in
order to expand my memory to 2G, I get the following error:
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #2:
directory entry across blocks - offset=0, inode=2147614725, rec_len=1152,
name_len=8
This is my console output:
==== Booting kernel ====
## Booting image at 00200000 ...
Image Name: Linux-2.6.14.7-saline
Image Type: PowerPC Linux Kernel Image (grip compressed)
Data Size: 1658344 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAM Disk Image at 01000000 ...
Image Name: Corrigent_ignited_fess
Image Type: PowerPC Linux RAM Disk Image (grip compressed)
Data Size: 13721548 Bytes = 13.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0b2ea000, end 0bffffcc ... OK
Linux version 2.6.14.7-saline (nadavs@nadavs_l.corrigent.com) (gcc version
3.4.4 (Wind River Linux)) #50 PREEMPT Sun Jul 13 11:04:30 IDT 2008
Built 1 zonelists
Kernel command line: root=/dev/ram0 rw ramdisk_size=300000 mem=1008M
ip=192.168.10.50:192.168.10.1:192.168.10.1:255.255.255.0:SBC8349:eth0:off
console=ttyS1,115200,115200 debug_flag=no msm_standalone=no oper_mode=normal
bootdir=msm_images vlan= sd=
LTT : ltt-base init
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1005368k available (2612k kernel code, 960k data, 124k init, 114688k
highmem)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
checking if image is initramfs...softlockup thread 0 started up.
it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 13399k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 2 of device 0000:00:00.0
PCI: Failed to allocate mem resource #2:80000000@0 for 0000:00:00.0
Generic PHY: Registered new driver
LTT : ltt-facilities init
LTT : ltt-core init as module
Registering GDB sysrq handler
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
LTT : ltt-facility-core init in kernel
LTT : ltt-facility-fs init in kernel
LTT : ltt-facility-ipc init in kernel
LTT : ltt-facility-kernel_arch init in kernel
LTT : ltt-facility-kernel init in kernel
LTT : ltt-facility-memory init in kernel
LTT : ltt-facility-network init in kernel
LTT : ltt-facility-process init in kernel
LTT : ltt-facility-socket init in kernel
LTT : ltt-facility-timer init in kernel
LTT : ltt-facility-statedump init in kernel
Software Watchdog Timer: 0.07 initialized. soft_noboot=1 soft_margin=10 sec
(nowayout= 1)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ttyS0 at MMIO map 0xe0004500 mem 0xfe004500 (irq = 9) is a 16550A
ttyS1 at MMIO map 0xe0004600 mem 0xfe004600 (irq = 10) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 1 RAM disks of 300000K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
eth0: Gianfar Ethernet Controller Version 1.1, 40:08:db:00:00:01
eth0: Running with NAPI disabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 40:08:db:00:10:00
eth1: Running with NAPI disabled
eth1: 256/256 RX/TX BD ring size
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: W7NCF01GH20IS4BG, CFA DISK drive
ide0 at 0xf9002000-0xf9002007,0xf900208c on irq 21
hda: max request size: 128KiB
hda: 2046240 sectors (1047 MB) w/0KiB Cache, CHS=2030/16/63
hda: cache flushes not supported
hda: hda1 hda2
physmap flash device: 800000 at ff800000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
ip_conntrack version 2.3 (8064 buckets, 64512 max) - 236 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
eth0: PHY is Marvell 88E6046 (1410c89)
IP-Config: Complete:
device=eth0, addr=192.168.10.50, mask=255.255.255.0, gw=192.168.10.1,
host=SBC8349, domain=, nis-domain=(none),
bootserver=192.168.10.1, rootserver=192.168.10.1, rootpath=
RAMDISK: Compressed image found at block 0
eth0: Full Duplex
eth0: Speed 1000BT
eth0: Link is up
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 124k init
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #2:
directory entry across blocks - offset=0, inode=2147614725, rec_len=1152,
name_len=8
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
<0>Rebooting in 180 seconds
Thanks,
Nadav
[-- Attachment #2: Type: text/html, Size: 8479 bytes --]
^ permalink raw reply
* EXT2-fs error when trying to work with highmem
From: Nadav Sharabi @ 2008-07-13 14:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6209 bytes --]
Hi All,
I have built a 2.6.14 image and Ramdisk for my board witch has a ppc
8349 processor with 1G DDR. The system works file if I build it without
highmem support but if I try to add highmem support to the system, witch
I need in order to expand my memory to 2G, I get the following error:
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #2:
directory entry across blocks - offset=0, inode=2147614725,
rec_len=1152, name_len=8
This is my console output:
==== Booting kernel ====
## Booting image at 00200000 ...
Image Name: Linux-2.6.14.7-saline
Image Type: PowerPC Linux Kernel Image (grip compressed)
Data Size: 1658344 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAM Disk Image at 01000000 ...
Image Name: Corrigent_ignited_fess
Image Type: PowerPC Linux RAM Disk Image (grip compressed)
Data Size: 13721548 Bytes = 13.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0b2ea000, end 0bffffcc ... OK
Linux version 2.6.14.7-saline (nadavs@nadavs_l.corrigent.com) (gcc
version 3.4.4 (Wind River Linux)) #50 PREEMPT Sun Jul 13 11:04:30 IDT
2008
Built 1 zonelists
Kernel command line: root=/dev/ram0 rw ramdisk_size=300000 mem=1008M
ip=192.168.10.50:192.168.10.1:192.168.10.1:255.255.255.0:SBC8349:eth0:of
f console=ttyS1,115200,115200 debug_flag=no msm_standalone=no
oper_mode=normal bootdir=msm_images vlan= sd=
LTT : ltt-base init
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1005368k available (2612k kernel code, 960k data, 124k init,
114688k highmem)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
checking if image is initramfs...softlockup thread 0 started up.
it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 13399k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 2 of device 0000:00:00.0
PCI: Failed to allocate mem resource #2:80000000@0 for 0000:00:00.0
Generic PHY: Registered new driver
LTT : ltt-facilities init
LTT : ltt-core init as module
Registering GDB sysrq handler
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
LTT : ltt-facility-core init in kernel
LTT : ltt-facility-fs init in kernel
LTT : ltt-facility-ipc init in kernel
LTT : ltt-facility-kernel_arch init in kernel
LTT : ltt-facility-kernel init in kernel
LTT : ltt-facility-memory init in kernel
LTT : ltt-facility-network init in kernel
LTT : ltt-facility-process init in kernel
LTT : ltt-facility-socket init in kernel
LTT : ltt-facility-timer init in kernel
LTT : ltt-facility-statedump init in kernel
Software Watchdog Timer: 0.07 initialized. soft_noboot=1 soft_margin=10
sec (nowayout= 1)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
ttyS0 at MMIO map 0xe0004500 mem 0xfe004500 (irq = 9) is a 16550A
ttyS1 at MMIO map 0xe0004600 mem 0xfe004600 (irq = 10) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 1 RAM disks of 300000K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
eth0: Gianfar Ethernet Controller Version 1.1, 40:08:db:00:00:01
eth0: Running with NAPI disabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 40:08:db:00:10:00
eth1: Running with NAPI disabled
eth1: 256/256 RX/TX BD ring size
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hda: W7NCF01GH20IS4BG, CFA DISK drive
ide0 at 0xf9002000-0xf9002007,0xf900208c on irq 21
hda: max request size: 128KiB
hda: 2046240 sectors (1047 MB) w/0KiB Cache, CHS=2030/16/63
hda: cache flushes not supported
hda: hda1 hda2
physmap flash device: 800000 at ff800000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
ip_conntrack version 2.3 (8064 buckets, 64512 max) - 236 bytes per
conntrack
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
TCP bic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
eth0: PHY is Marvell 88E6046 (1410c89)
IP-Config: Complete:
device=eth0, addr=192.168.10.50, mask=255.255.255.0,
gw=192.168.10.1,
host=SBC8349, domain=, nis-domain=(none),
bootserver=192.168.10.1, rootserver=192.168.10.1, rootpath=
RAMDISK: Compressed image found at block 0
eth0: Full Duplex
eth0: Speed 1000BT
eth0: Link is up
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 124k init
EXT2-fs error (device ram0): ext2_check_page: bad entry in directory #2:
directory entry across blocks - offset=0, inode=2147614725,
rec_len=1152, name_len=8
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
<0>Rebooting in 180 seconds
Thanks,
Nadav
[-- Attachment #2: Type: text/html, Size: 8466 bytes --]
^ permalink raw reply
* rtc integration with hwclock
From: mahendra varman @ 2008-07-13 14:53 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel, linux-mips@linux-mips.org
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Hi
Help me to solve the below point
Hi have wrote a simple i2c based driver for rtc chip (x1226) in linux 2.6
with inbuilt i2c routines.
In the get_rtc_time routine i can able to read the values from the rtc chip
and store it in variables
I need to know how to update those values into the rtc structure so that if
i put hwclock it should display the read value....
Any example code depicting the above point is also welcome
Thanks in advance
[-- Attachment #2: Type: text/html, Size: 498 bytes --]
^ permalink raw reply
* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: David Hubbard @ 2008-07-13 21:11 UTC (permalink / raw)
To: Hans de Goede
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Jean Delvare
In-Reply-To: <4879A144.8060203@hhs.nl>
Hi Hans, Milton, Jean,
On Sun, Jul 13, 2008 at 12:31 AM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> Jean Delvare wrote:
>> On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
>>> Jean Delvare wrote:
>>>> Hi Hans, hi Milton,
>>>>
>>> <snip>
>>>
>>>>> One could make a superio driver, and create sub-devices for the IR,
>>>>> I2C, floppy, parallel, etc
>>>>> nodes.
>>>> There have been proposals to do this, and this would indeed be a very
>>>> good idea, but unfortunately nobody took the time to implement this
>>>> properly, push it upstream and volunteer to maintain it. The problem is
>>>> that you don't need just a "driver", but a new subsystem, that needs to
>>>> be designed and maintained.
>>> Well, I believe there have been some lightweight superio locking coordinator
>>> patches been floating around on the lm_sensors list, and I have reviewed them
>>> and then a new version was done with my issues fixed.
>>>
>>> I kinda liked the proposed solution there, it was quite simple, moved all the
>>> generic superio stuff into generic superio code, and added locking for super io
>>> access from multiple drivers, what ever happened to those patches?
>>
>> As far as I know, nothing, and this is the problem. Somebody needs to
>> step up and call him/herself the maintainer of the new code, and push
>> it upstream and convert all the drivers (hwmon, watchdog, parallel
>> port...) to make use of it. And I am not the one to do this, I am busy
>> enough as is with i2c and hwmon.
>>
>
> Ok, I've mailed Jim Cromie, the author of the superio access patches
> from end 2007 and told him we're still interested in this and asked him
> if he is willing to drive this forward.
I propose writing a subsystem driver. (Is that properly called "The
SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
put together some code and submit it for review, and maintain it.
Some hwmon chips have odd / unique probe sequences. IMHO this is where
the design needs to be inspected. One of those is the w83627ehf, which
Jean and Hans are familiar enough with to check my work.
Thoughts?
David
^ permalink raw reply
* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Hans de Goede @ 2008-07-13 21:22 UTC (permalink / raw)
To: David Hubbard
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Jean Delvare
In-Reply-To: <4dfa50520807131411ied883cgcb20eb6bd94f761@mail.gmail.com>
David Hubbard wrote:
> Hi Hans, Milton, Jean,
>
> On Sun, Jul 13, 2008 at 12:31 AM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
>> Jean Delvare wrote:
>>> On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
>>>> Jean Delvare wrote:
>>>>> Hi Hans, hi Milton,
>>>>>
>>>> <snip>
>>>>
>>>>>> One could make a superio driver, and create sub-devices for the IR,
>>>>>> I2C, floppy, parallel, etc
>>>>>> nodes.
>>>>> There have been proposals to do this, and this would indeed be a very
>>>>> good idea, but unfortunately nobody took the time to implement this
>>>>> properly, push it upstream and volunteer to maintain it. The problem is
>>>>> that you don't need just a "driver", but a new subsystem, that needs to
>>>>> be designed and maintained.
>>>> Well, I believe there have been some lightweight superio locking coordinator
>>>> patches been floating around on the lm_sensors list, and I have reviewed them
>>>> and then a new version was done with my issues fixed.
>>>>
>>>> I kinda liked the proposed solution there, it was quite simple, moved all the
>>>> generic superio stuff into generic superio code, and added locking for super io
>>>> access from multiple drivers, what ever happened to those patches?
>>> As far as I know, nothing, and this is the problem. Somebody needs to
>>> step up and call him/herself the maintainer of the new code, and push
>>> it upstream and convert all the drivers (hwmon, watchdog, parallel
>>> port...) to make use of it. And I am not the one to do this, I am busy
>>> enough as is with i2c and hwmon.
>>>
>> Ok, I've mailed Jim Cromie, the author of the superio access patches
>> from end 2007 and told him we're still interested in this and asked him
>> if he is willing to drive this forward.
>
> I propose writing a subsystem driver. (Is that properly called "The
> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
> put together some code and submit it for review, and maintain it.
>
> Some hwmon chips have odd / unique probe sequences. IMHO this is where
> the design needs to be inspected. One of those is the w83627ehf, which
> Jean and Hans are familiar enough with to check my work.
>
> Thoughts?
I'm afraid that making this a "bus" will be a bit overkill. Jim's patches are
quite simple and seem todo the job.
Also keep in mind that most users will be platform devices which just want to
use the superio registers to find out the baseaddress of their logical device,
a whole bus seems overkill for this, would the hwmon driver then need to be a
superio_driver (as well as an platform_driver) or can the bus be queried / used
without having to be a bustype-driver?
Regards,
Hans
^ permalink raw reply
* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: David Hubbard @ 2008-07-13 21:26 UTC (permalink / raw)
To: Hans de Goede
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Jean Delvare
In-Reply-To: <487A7211.7030309@hhs.nl>
Hi Hans,
>> I propose writing a subsystem driver. (Is that properly called "The
>> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
>> put together some code and submit it for review, and maintain it.
>>
>> Some hwmon chips have odd / unique probe sequences. IMHO this is where
>> the design needs to be inspected. One of those is the w83627ehf, which
>> Jean and Hans are familiar enough with to check my work.
>>
>> Thoughts?
>
> I'm afraid that making this a "bus" will be a bit overkill. Jim's patches
> are quite simple and seem todo the job.
>
> Also keep in mind that most users will be platform devices which just want
> to use the superio registers to find out the baseaddress of their logical
> device, a whole bus seems overkill for this, would the hwmon driver then
> need to be a superio_driver (as well as an platform_driver) or can the bus
> be queried / used
> without having to be a bustype-driver?
I think that's a valid point. I am willing to keep it small, but I
would prefer to follow the pattern set in other subsystems. It may be
my lack of experience in designing a subsystem showing here! What are
some alternative ways to implement it?
In other words, Jim's patches are a good start, but maybe I am
misunderstanding them. I see it as the superio-locks module, a driver
that other drivers would depend on / auto-load. Is that something
other subsystems also do?
Regards,
David
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Paul Mackerras @ 2008-07-13 22:32 UTC (permalink / raw)
To: Srinivasa D S; +Cc: linuxppc-dev
In-Reply-To: <200807071952.27427.srinivasa@in.ibm.com>
Srinivasa D S writes:
> task_pt_regs() macro defines pt_regs for the given task, this macro is
> currently not defined for powerpc arch. We need this macro for
> upcoming utrace features.
> Below attached patch defines this macro for powerpc arch. Please let
> me know your comments on this.
> +#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.regs)
The cast is unnecessary since tsk->thread.regs is already a struct
pt_regs *. Also note that tsk->thread.regs will be NULL for a kernel
thread.
Paul.
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Benjamin Herrenschmidt @ 2008-07-13 22:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Srinivasa D S
In-Reply-To: <18554.33417.542066.185326@cargo.ozlabs.ibm.com>
On Mon, 2008-07-14 at 08:32 +1000, Paul Mackerras wrote:
> Srinivasa D S writes:
>
> > task_pt_regs() macro defines pt_regs for the given task, this macro is
> > currently not defined for powerpc arch. We need this macro for
> > upcoming utrace features.
> > Below attached patch defines this macro for powerpc arch. Please let
> > me know your comments on this.
>
> > +#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.regs)
>
> The cast is unnecessary since tsk->thread.regs is already a struct
> pt_regs *. Also note that tsk->thread.regs will be NULL for a kernel
> thread.
Hrm.. I stuck that one in powerpc master, but not yet in next. Wonder if
I should back it out, sounds like a minor issue.
Ben.
^ permalink raw reply
* Re: Mikrotik RouterBoard 333
From: Jerry Van Baren @ 2008-07-14 0:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080709040925.GA13810@secretlab.ca>
Grant Likely wrote:
> On Tue, Jul 08, 2008 at 02:26:32PM +1000, David Gibson wrote:
>> Does anyone on this list have contacts with the makers of this board?
>>
>> Its firmware apparently provides a flattened device tree to the OS.
>> And while this step towards world domination is flattering, it's an
>> example of what I feared when people first got enthusiastic about the
>> idea of including flattened device trees in firmwares. The tree has
>> not, AFAIK, been past this list, and has apparently not been reviewed
>> by someone knowledgeable about device trees. In short, it's crap, and
>> now that it's embedded in the firware we can't really fix it.
>>
>> So, to any embedded hardware/firmware vendors doing Linux ports out
>> there. I certainly encourage you to use flattened device trees, but
>> can I please suggest you put the blob into your kernel image (in the
>> bootwrapper strictly speaking), rather than into the flashed firmware.
>> It's a lot easier to fix mistakes that way.
>>
>> There are situations where it's nice to have the device tree in
>> firmware, but there are many others where it buys little to nothing.
>> People seem to be a bit overenthusaistic on the concept at the moment.
>
> Total Ack! Allow me second that opinion.
>
> g.
I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than
using a bootwrapper for obvious reasons. The u-boot implementation
takes the blob as a boot parameter and passes it along to the kernel
after doing appropriate (optional) fixups. The usual implementation is
to burn it into a block of flash separate from u-boot itself or use tftp
to load it from the server.
Other than that quibble, I agree that burning the blob into the firmware
so that the firmware must be recompiled and reburned to change the blob
is very undesirable.
Best regards,
gvb
^ permalink raw reply
* MC146818 support and migration from todc to rtc, guidance please
From: Stephen Horton @ 2008-07-14 2:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hello folks,
In a current work project, I have inherited a compactPCI board that has
an mpc7447/7448 powerpc processor as well as a Marvell system
controller, model mv64462 (stripped down mv64460). The board has a
somewhat working Gentoo Linux port running on it from long ago and a
company far far away (kernel version 2.6.9 built using arch/ppc). To
prepare for an upcoming deployment, I would like to bring the OS
up-to-date on this board with a newer kernel (targeting 2.6.24).
The 2.6.9 kernel that was previously developed for the board uses the
todc.h library to enable real time clock functionality on the board's
mc146818 device. The todc library appears to have been removed during
the arch/ppc to arch/powerpc migration and replaced with a more generic
RTC mechanism.(??) I can also see that there is an
include/asm-powerpc/mc146818rtc.h file for this device included with the
2.6.24 kernel.
Can anyone give me some tips on what was intended with the removal of
the todc library? What direction should I take to port my platform file
code from todc to the new mechanism? Is this work already done for me
in the kernel source? What work am I expected to do to add support for
this device in my kernel code? I'm specifically interested in what needs
to be included in my .dts file to enable this device.
Thanks for any guidance and advice, regards,
Stephen
[-- Attachment #2: Type: text/html, Size: 3753 bytes --]
^ permalink raw reply
* Re: Updates to powerpc.git
From: Benjamin Herrenschmidt @ 2008-07-14 5:32 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Andrew Morton
In-Reply-To: <1215588881.8970.358.camel@pasglop>
On Wed, 2008-07-09 at 17:34 +1000, Benjamin Herrenschmidt wrote:
>
> It contains 3 branches:
>
> - merge : this is for merging with the current stable and doesn't
> currently contain anything interesting
>
> - master : this is our current "powerpc.git" tree, it may contain
> various experimental stuff that may or may not go upstream
> or may contain dependent patches that we rely on but that
> are to be merged via some other tree.
>
> - next : this is the candidate stuff for linux-next and the next
> merge window
-next and -merge are now both to the same level, which is the same
as I pushed last week plus a merge with 2.6.26 to resolve a conflict.
I'll start putting new stuff in tomorrow if all goes well.
Cheers,
Ben.
^ permalink raw reply
* linux-next: manual merge of the powerpc tree
From: Stephen Rothwell @ 2008-07-14 5:44 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: Nelson, Steven Rostedt, Mark, linux-next, Ingo Molnar,
Thomas Gleixner
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi Paul, Ben,
Today's linux-next merge of the powerpc tree got a conflict in
arch/powerpc/Kconfig between commit
4e491d14f2506b218d678935c25a7027b79178b1 ("ftrace: support for PowerPC")
from the ftrace tree and commit 3affedc4e1ce837033b6c5e9289d2ce2f5a62d31
("powerpc/dma: implement new dma_*map*_attrs() interfaces") from the
powerpc tree.
The former commit moved the "select HAVE_OPROFILE" to the bottom of the
"config PPC" list (for no reason that I can fathom) while the latter
added another select. Simple fixup. I can carry it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Updates to powerpc.git
From: Stephen Rothwell @ 2008-07-14 5:49 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, Andrew Morton
In-Reply-To: <1216013556.7549.244.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
Hi Ben,
On Mon, 14 Jul 2008 15:32:36 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> -next and -merge are now both to the same level, which is the same
I think you meant -master (not -merge).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* build error in powerpc tree
From: Stephen Rothwell @ 2008-07-14 7:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, Dave Kleikamp
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
Hi Ben,
Commit ef3d3246a0d06be622867d21af25f997aeeb105f ("powerpc/mm: Add Strong
Access Ordering support") in the powerpc/{next,master} tree caused the
following in a powerpc allmodconfig build:
usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported headers
Also, that header file is now using CONFIG_PPC64 which we should not do
in the unprotected (by #ifdef __KERNEL__) part an exported header file,
we should use __powerpc64__ instead.
I suspect all the CONFIG_PPC64 part of the file could be surrounded by
#ifdef __KERNEL__ and the include of <linux/mm.h> could be moved to this
section. The file should then be changed to unifdef-y from header-y in
the Kbuild file. (Might have been easier to send a patch :-))
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-14 7:59 UTC (permalink / raw)
To: David Hubbard
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <4dfa50520807131426t4013142cp1fcd49e078a79c1f@mail.gmail.com>
On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote:
> Hi Hans,
>
> >> I propose writing a subsystem driver. (Is that properly called "The
> >> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
> >> put together some code and submit it for review, and maintain it.
> >>
> >> Some hwmon chips have odd / unique probe sequences. IMHO this is where
> >> the design needs to be inspected. One of those is the w83627ehf, which
> >> Jean and Hans are familiar enough with to check my work.
> >>
> >> Thoughts?
> >
> > I'm afraid that making this a "bus" will be a bit overkill. Jim's patches
> > are quite simple and seem todo the job.
> >
> > Also keep in mind that most users will be platform devices which just want
> > to use the superio registers to find out the baseaddress of their logical
> > device, a whole bus seems overkill for this, would the hwmon driver then
> > need to be a superio_driver (as well as an platform_driver) or can the bus
> > be queried / used
> > without having to be a bustype-driver?
>
> I think that's a valid point. I am willing to keep it small, but I
> would prefer to follow the pattern set in other subsystems. It may be
> my lack of experience in designing a subsystem showing here! What are
> some alternative ways to implement it?
>
> In other words, Jim's patches are a good start, but maybe I am
> misunderstanding them. I see it as the superio-locks module, a driver
> that other drivers would depend on / auto-load. Is that something
> other subsystems also do?
Well, there are two approaches to the problem. The first approach
(which I think Jim took in his patches? I don't really remember) is to
simply solve the problem of concurrent I/O access to the Super-I/O
configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a
simple driver requesting the ports in question and exporting an API for
other drivers to access them in a safe way.
The second approach is to make it a whole subsystem, as David is
suggesting. The Super-I/O driver would then not only request the I/O
ports, it would also identify which Super-I/O is there, and it would
create devices (in the Linux device driver model sense of the term) for
every logical device we are interested in (amongst which the hwmon
ones.) The hwmon drivers would have to be converted from platform
drivers to superio drivers.
Each approach has its advantages. The first one is rather simple and
also very generic in nature. It could be reused for other purposes. The
second one offers automatic loading of hwmon drivers, which would be
nice to have.
There's probably a middle way which would keep the simplicity of the
first approach while still allowing for driver auto-loading, without
changing the bus type of all drivers. It would probably take some
research though.
Me, I don't really care which path we choose, given that I am not the
one who will take care of it. All I have to say is that this has been
discussed several times over the past 2 years and nothing came out of
it (as far as the mainline kernel is concerned, at least) so whatever
is done now, what really matters is that it makes it into the kernel
quickly. We have some drivers missing features because of this (for
example real-time reading of VID pin values.)
This should also not prevent us from fixing the drivers now so that
they temporarily request the Super-I/O ports they are using, as Milton
suggested. Not only we don't know when we will have something better to
offer, but it might also help us find conflicts between drivers, so
that we know which drivers should make use of the future superio
driver. This could also reveal conflicts with PNP BIOS reservations,
etc. Milton, will you write a patch?
--
Jean Delvare
^ 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