* Réf. : Status of I2C on mpc5200
From: Eric DUJARDIN @ 2008-02-20 8:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]
Got it. The mpc52xx's still don't support interrupts i.e. reads require
polling.
As a consequence reads may time out.
But it doesn't prevent I2c from working.
Sorry for disturbing,
Eric Dujardin
-------------------------------
Sagem DS - DP Combat Terrestre
178 rue de Paris - F-91344 Massy Cedex
(33) 1 69196792 (direct)
(33) 1 69196904 (fax)
-------------------------------
"Eric DUJARDIN" <eric.dujardin@sagem.com>
Envoyé par : linuxppc-dev-bounces+eric.dujardin=sagem.com@ozlabs.org
19/02/2008 19:00
Remis le : 19/02/2008 19:01
Pour :
cc : (ccc : Eric DUJARDIN/DRD/SAGEM)
Objet : Status of I2C on mpc5200
Hello all,
I have a question regarding the stability of I2C on mpc52xx.
According to menuconfig's help it isn't still stable as it says:
"The driver may also work on 52xx family processors, though interrupts are
known not to work"
However there has been a patch from Domen Puncer that apparently fixed the
driver in 2.6.23.
<snip>
If any kind soul could provide a status I'd be glad to provide the patch
for the help file...
Thanks,
Eric Dujardin
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
[-- Attachment #2: Type: text/html, Size: 3242 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Willy Tarreau @ 2008-02-20 7:32 UTC (permalink / raw)
To: Andi Kleen
Cc: Nick Piggin, Roel Kluin, lkml, linuxppc-dev, cbe-oss-dev,
Arjan van de Ven
In-Reply-To: <20080219092846.GB6485@one.firstfloor.org>
On Tue, Feb 19, 2008 at 10:28:46AM +0100, Andi Kleen wrote:
> > Sometimes, for performance critical paths, I would like gcc to be dumb and
> > follow *my* code and not its hard-coded probabilities.
>
> If you really want that, simple: just disable optimization @)
already tried. It fixed some difficulties, but create new expected issues
with data being reloaded often from memory instead of being passed along
a few registers. Don't forget that optimizing for x86 requires a lot of
smartness from the compiler because of the very small number of registers!
> > Maybe one thing we would need would be the ability to assign probabilities
> > to each branch based on what we expect, so that gcc could build a better
> > tree keeping most frequently used code tight.
>
> Just use profile feedback then for user space. I don't think it's a good
> idea for kernel code though because it leads to unreproducible binaries
> which would wreck the development model.
I never found this to be practically usable in fact, because you have to
use it on the *exact* same source. End of game for cross-compilation. It
would be good to be able to use a few pragmas in the code to say "hey, I
want this block optimized like this". This is what I understood the
__builtin_expect() was for, except that it tends to throw unpredicted
branches too far away.
> > Hmm I've just noticed -fno-guess-branch-probability in the man, I never tried
> > it.
>
> Or -fno-reorder-blocks
Thanks for the hint, I will try it.
Willy
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Jean Delvare @ 2008-02-20 7:20 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev, i2c
In-Reply-To: <47BB50E9.60508@pikatech.com>
Hi Sean,
On Tue, 19 Feb 2008 16:58:01 -0500, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>
> --- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c 2008-02-18 16:36:30.000000000 -0500
> +++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-02-19 16:46:35.000000000 -0500
> @@ -6,6 +6,9 @@
> * Copyright (c) 2003, 2004 Zultys Technologies.
> * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
> *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <smaclennan@pikatech.com>
> + *
> * Based on original work by
> * Ian DaSilva <idasilva@mvista.com>
> * Armin Kuster <akuster@mvista.com>
> (...)
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -244,7 +244,7 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on 4xx
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
I've applied this version. I see that there are discussions going on
about the best "depends on" statement in Kconfig, feel free to submit
an updated (or incremental) patch as soon as a decision will have been
taken.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Jean Delvare @ 2008-02-20 6:57 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <200802192355.17707.arnd@arndb.de>
Hi Arnd,
On Tue, 19 Feb 2008 23:55:16 +0100, Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
> > On Tuesday 19 February 2008, Jean Delvare wrote:
> > >
> > > With this Kconfig change, "make menuconfig" lets me select the
> > > i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
> > > that you want to restrict the build to PPC machines somehow, or at
> > > least make sure that either IBM_OCP or OF support is present.
> >=20
> > How about this:
> >=20
> > -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> > +=A0=A0=A0=A0=A0=A0=A0depends on 4xx
>=20
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>=20
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>=20
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
Fine with me as long as the default is set appropriately (i.e. default
to not building the driver on archs/platforms where it builds but is
known to be useless.)
>=20
> - depends on IBM_OCP
> + depends on IBM_OCP || PPC_MERGE
--=20
Jean Delvare
^ permalink raw reply
* Re: [patch 0/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Grant Grundler @ 2008-02-20 6:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <20080219043952.845136014@ldl.fc.hp.com>
On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
> There are many implementations of pcibios_enable_resources() that differ
> in minor ways that look more like bugs than architectural differences.
> This patch series consolidates most of them to use the x86 version.
>
> This series is for discussion only at this point. I'm interested in
> feedback about whether any of the differences are "real" and need to
> be preserved.
>
> ARM and PA-RISC, in particular, have interesting differences:
> - ARM always enables bridge devices, which no other arch does
> - PA-RISC always turns on SERR and PARITY, which no other arch does
>
> Should other arches do the same thing, or are these somehow related to
> ARM and PA-RISC architecture?
My impression was most x86 BIOS's did NOT turn on SERR/PERR when I added
that code to parisc-linux port (2000 or 2001 so) . HPUX was turning on
SERR/PERR and so I was comfortable the HW was stable and it not crash
under normal use unless something was really broken.
There is certainly nothing architectural specific about SERR/PERR.
I felt (at the time) this is more of a case of "if it's not reported to the
user, we won't get blamed for it not working well."
hth,
grant
^ permalink raw reply
* [GIT PULL] Please pull spufs.git master branch
From: Jeremy Kerr @ 2008-02-20 5:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
Hi Paul,
Please do a:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git master
I have two new bugfixes for spufs: these are both fixes for regressions
since .24.
Cheers,
Jeremy
--- 2 commits:
[POWERPC] spufs: fix scheduler starvation by idle contexts
Jeremy Kerr <jk@ozlabs.org>
arch/powerpc/platforms/cell/spufs/run.c | 1 +
arch/powerpc/platforms/cell/spufs/sched.c | 8 +++-----
2 files changed, 4 insertions(+), 5 deletions(-)
[POWERPC] cell: fix spurious false return from spu_trap_data_{map,seg}
Andre Detsch <adetsch@br.ibm.com>
arch/powerpc/platforms/cell/spu_base.c | 12 ------------
arch/powerpc/platforms/cell/spufs/switch.c | 6 +++---
include/asm-powerpc/spu.h | 3 +--
3 files changed, 4 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 5:29 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.212655.173468988.davem@davemloft.net>
On Feb 19, 2008, at 11:26 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 23:16:18 -0600
>
>> The for loop above the code I added will move all the existing slots
>> up one. Its just the tail cleanup we are missing.
>
> Aha, I see how this works now, thanks!
>
> I'll add this to my LMB tree.
Sounds good. Now just convince Paul or Linus to pull this in for
2.6.25 :)
- k
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: David Miller @ 2008-02-20 5:26 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <7A7ECF09-E547-4C04-A388-C3E8755478DD@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 23:16:18 -0600
> The for loop above the code I added will move all the existing slots
> up one. Its just the tail cleanup we are missing.
Aha, I see how this works now, thanks!
I'll add this to my LMB tree.
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: Kumar Gala @ 2008-02-20 5:19 UTC (permalink / raw)
To: raul.moreno
Cc: maxime louvel,
linuxppc-embedded-bounces+raul.moreno=telvent.abengoa.com,
linuxppc-embedded
In-Reply-To: <OF5ABF0D8A.75A05AE1-ONC12573F4.00426B12-C12573F4.0043B5F0@abengoa.com>
On Feb 19, 2008, at 6:19 AM, raul.moreno@telvent.abengoa.com wrote:
>
> Hello Maxime,
>
> if your board is still running, although you can't see the messages
> that
> means you don't have any console. Try to set one (I think you can
> use a SCM
> of the CPM) in the kernel configuration (characters devices) or in
> the
> command line (console=).
If you really have a mpc8548 than there is no CPM. It has 16550 style
UARTs on it.
- k
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 5:16 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.204525.193731674.davem@davemloft.net>
On Feb 19, 2008, at 10:45 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
>
>> We introduced a bug in fixing lmb_add_region to handle an initial
>> region being non-zero. Before that fix it was impossible to insert
>> a region at the head of the list since the first region always
>> started
>> at zero.
>>
>> Now that its possible for the first region to be non-zero we need to
>> check to see if the new region should be added at the head and if so
>> actually add it.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ...
>> @@ -184,6 +184,11 @@ static long __init lmb_add_region(struct
>> lmb_region *rgn, u64 base, u64 size)
>> break;
>> }
>> }
>> +
>> + if (base < rgn->region[0].base) {
>> + rgn->region[0].base = base;
>> + rgn->region[0].size = size;
>> + }
>> rgn->cnt++;
>>
>> return 0;
>
> Are you sure this is sufficient?
>
> It seems to me, to handle this properly, you'll need to handle
> the case where the lower addressed entry you are inserting is
> not contiguous with the existing entry 0.
>
> Therefore, you need to move all existing entries up a slot,
> then you can set the 0 entry to 'base' and 'size'.
The for loop above the code I added will move all the existing slots
up one. Its just the tail cleanup we are missing.
- k
^ permalink raw reply
* Re: [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: David Miller @ 2008-02-20 4:45 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802192227170.2215@blarg.am.freescale.net>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 22:27:48 -0600 (CST)
> We introduced a bug in fixing lmb_add_region to handle an initial
> region being non-zero. Before that fix it was impossible to insert
> a region at the head of the list since the first region always started
> at zero.
>
> Now that its possible for the first region to be non-zero we need to
> check to see if the new region should be added at the head and if so
> actually add it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
...
> @@ -184,6 +184,11 @@ static long __init lmb_add_region(struct lmb_region *rgn, u64 base, u64 size)
> break;
> }
> }
> +
> + if (base < rgn->region[0].base) {
> + rgn->region[0].base = base;
> + rgn->region[0].size = size;
> + }
> rgn->cnt++;
>
> return 0;
Are you sure this is sufficient?
It seems to me, to handle this properly, you'll need to handle
the case where the lower addressed entry you are inserting is
not contiguous with the existing entry 0.
Therefore, you need to move all existing entries up a slot,
then you can set the 0 entry to 'base' and 'size'.
What do you think?
^ permalink raw reply
* [PATCH] [LMB]: Fix lmb_add_region if region should be added at the head
From: Kumar Gala @ 2008-02-20 4:27 UTC (permalink / raw)
To: davem; +Cc: sparclinux, linuxppc-dev, linux-kernel
We introduced a bug in fixing lmb_add_region to handle an initial
region being non-zero. Before that fix it was impossible to insert
a region at the head of the list since the first region always started
at zero.
Now that its possible for the first region to be non-zero we need to
check to see if the new region should be added at the head and if so
actually add it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
lib/lmb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index e3c8dcb..3c43b95 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -184,6 +184,11 @@ static long __init lmb_add_region(struct lmb_region *rgn, u64 base, u64 size)
break;
}
}
+
+ if (base < rgn->region[0].base) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ }
rgn->cnt++;
return 0;
--
1.5.3.8
^ permalink raw reply related
* Sample driver
From: Silwer star @ 2008-02-20 4:13 UTC (permalink / raw)
To: linuxppc-embedded
Does anyone have sample drivers in Linux for the EBC interface for PPC405Ex?
I would be thankful if someone could put in a sample code here.
--
View this message in context: http://www.nabble.com/Sample-driver-tp15582059p15582059.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-02-20 3:46 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a few more bug and warning fixes for powerpc. The diffstat is
bloated by the defconfig updates -- the actual code changes are only a
few dozen lines.
Thanks,
Paul.
arch/powerpc/boot/Makefile | 8
arch/powerpc/boot/dts/bamboo.dts | 3
arch/powerpc/boot/dts/ebony.dts | 2
arch/powerpc/boot/dts/katmai.dts | 2
arch/powerpc/boot/dts/kilauea.dts | 3
arch/powerpc/boot/dts/makalu.dts | 3
arch/powerpc/boot/dts/rainier.dts | 4
arch/powerpc/boot/dts/sequoia.dts | 4
arch/powerpc/boot/dts/taishan.dts | 4
arch/powerpc/configs/bamboo_defconfig | 81 ++-
arch/powerpc/configs/ebony_defconfig | 79 ++-
arch/powerpc/configs/ep405_defconfig | 92 ++-
arch/powerpc/configs/kilauea_defconfig | 69 ++
arch/powerpc/configs/makalu_defconfig | 69 ++
arch/powerpc/configs/ppc44x_defconfig | 904 ++++++++++++++++++++++++++++++++
arch/powerpc/configs/rainier_defconfig | 82 ++-
arch/powerpc/configs/sequoia_defconfig | 77 ++-
arch/powerpc/configs/taishan_defconfig | 81 ++-
arch/powerpc/configs/walnut_defconfig | 81 ++-
arch/powerpc/configs/warp_defconfig | 139 +++--
arch/powerpc/kernel/kprobes.c | 9
arch/powerpc/kernel/prom.c | 13
arch/powerpc/platforms/44x/Kconfig | 10
arch/powerpc/platforms/pseries/power.c | 2
arch/ppc/platforms/4xx/ibm440ep.c | 6
drivers/net/ibm_newemac/rgmii.c | 1
26 files changed, 1497 insertions(+), 331 deletions(-)
create mode 100644 arch/powerpc/configs/ppc44x_defconfig
Ananth N Mavinakayanahalli (1):
[POWERPC] Kill sparse warnings in kprobes
Becky Bruce (1):
[POWERPC] Fix dt_mem_next_cell() to read the full address
Josh Boyer (4):
[POWERPC] 4xx: Update defconfigs for 2.6.25
[POWERPC] 44x: Fix Kconfig formatting
[POWERPC] 44x: Add multiplatform defconfig
[POWERPC] Fix bootwrapper builds with older gcc versions
Stefan Roese (2):
[POWERPC] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
[POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
Stephen Rothwell (1):
[POWERPC] Fix warning in pseries/power.c
Wolfgang Ocker (1):
[POWERPC] PPC440EP Interrupt Triggering and Level Settings
^ permalink raw reply
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: David Miller @ 2008-02-20 3:31 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <4130F47E-4F4A-4911-B63B-403A8C423565@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 21:02:04 -0600
> np. Are we trying to get this into 2.6.25 or .26?
I'm ambivalent but I would obviously prefer 2.6.25 because
it would allow me to proceed more easily with my sparc64
NUMA work as well as get your bug fixes in more smoothly.
^ permalink raw reply
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-20 3:02 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080219.163003.152862383.davem@davemloft.net>
On Feb 19, 2008, at 6:30 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue, 19 Feb 2008 13:51:37 -0600 (CST)
>
>> If we add to an empty lmb region with a non-zero base we will not
>> coalesce
>> the number of regions down to one. This causes problems on ppc32
>> for the
>> memory region as its assumed to only have one region.
>>
>> We can fix this easily by causing the initial add to replace the
>> dummy
>> region.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>>
>> Fix a bug the initial patch introduced if we have a region that
>> gets added
>> at the beginning of the list we wouldn't actually add it.
>>
>> Dave can you replace the patch in you tree with this one.
>
> I think my tree has already or will soon be pulled in so
> I don't want to rebase it.
>
> Why don't you simply send me the relative bug fix instead?
np. Are we trying to get this into 2.6.25 or .26?
- k
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: David Gibson @ 2008-02-20 2:04 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <47BB7FDB.3050809@gmail.com>
On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
> Jon Loeliger wrote:
> > So, like, the other day David Gibson mumbled:
> >> In light of the recently discovered bug with NOP handling, this adds
> >> some more testcases for NOP handling. Specifically, it adds a helper
> >> program which will add a NOP tag after every existing tag in a dtb,
> >> and runs the standard battery of tests over trees mangled in this way.
> >>
> >> For now, this does not add a NOP at the very beginning of the
> >> structure block. This causes problems for libfdt at present, because
> >> we assume in many places that the root node's BEGIN_NODE tag is at
> >> offset 0. I'm still contemplating what to do about this (with one
> >> option being simply to declare such dtbs invalid).
> >>
> >> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Applied.
> >
> > BTW, declaring DTBs with BEGIN_NODES not at offset 0
> > as invalid seems like a fine choice to me.
> >
> > jdl
>
> FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
> as invalid. The root being at offset 0 assumption is pretty well
> entrenched and I cannot think of any reason to change it that would be
> worth the effort.
Well, it's actually not that hard to deal with. I've already been
planning to add a helper function/macro which validates a node offset
(something currently open-coded in a whole bunch of places). It would
be fairly easy to make it skip over nops as well.
But, likewise I can think of no reason that NOPs before the root node
would be useful or likely to occur in practice.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: Jerry Van Baren @ 2008-02-20 1:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <E1JR6vQ-0000h9-2f@jdl.com>
Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
>> In light of the recently discovered bug with NOP handling, this adds
>> some more testcases for NOP handling. Specifically, it adds a helper
>> program which will add a NOP tag after every existing tag in a dtb,
>> and runs the standard battery of tests over trees mangled in this way.
>>
>> For now, this does not add a NOP at the very beginning of the
>> structure block. This causes problems for libfdt at present, because
>> we assume in many places that the root node's BEGIN_NODE tag is at
>> offset 0. I'm still contemplating what to do about this (with one
>> option being simply to declare such dtbs invalid).
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> BTW, declaring DTBs with BEGIN_NODES not at offset 0
> as invalid seems like a fine choice to me.
>
> jdl
FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
as invalid. The root being at offset 0 assumption is pretty well
entrenched and I cannot think of any reason to change it that would be
worth the effort.
Best regards,
gvb
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Paul Mackerras @ 2008-02-20 0:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20080219040530.7b1d115d.akpm@linux-foundation.org>
Andrew Morton writes:
> Bizarrely, the original author of the patch (Anton) has fallen off the cc.
> Could whoever did that please thwap himself?
>
> Anyway, my head is now officially spinning. Did anyone actually have a
> reason why we shouldn't proceed with Anton's patch?
I was wondering if it would be sufficient to provide alternative
versions of fb_readl, fb_writel etc. that do byte-swapping. That
would mean that all framebuffers would have to have the same
endianness, but that would suffice for embedded systems such as
Anton's and would end up a lot simpler IMHO.
Paul.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Benjamin Herrenschmidt @ 2008-02-20 0:50 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven, Andrew Morton
In-Reply-To: <28238.1203468428@turing-police.cc.vt.edu>
On Tue, 2008-02-19 at 19:47 -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> > On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <clemens.koller@anagramm.de
> > wrote:
> > > That's not an issue in my case. The SM50x can be connected to
> > > either an PCI or some Local/CPU-whateverbus IF.
> > > I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
> > > If the sm501 is attached to the MPC85xx' PCI like any other video card,
> > > the PCI config-space is can be accessed as usual, whereas the framebuffer
> > > memory area is byte-swapped compared to other common video cards.
>
> > Anyway, my head is now officially spinning. Did anyone actually have a
> > reason why we shouldn't proceed with Anton's patch?
>
> Clemens answered my question regarding the real-life existence of hardware
> that would benefit. I'd say if Anton's patch works on Clemens' hardware and
> otherwise passes review, we should proceed...
No objection here neither.
Ben.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Valdis.Kletnieks @ 2008-02-20 0:47 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20080219040530.7b1d115d.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said:
> On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <clemens.koller@anagramm.de
> wrote:
> > That's not an issue in my case. The SM50x can be connected to
> > either an PCI or some Local/CPU-whateverbus IF.
> > I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses.
> > If the sm501 is attached to the MPC85xx' PCI like any other video card,
> > the PCI config-space is can be accessed as usual, whereas the framebuffer
> > memory area is byte-swapped compared to other common video cards.
> Anyway, my head is now officially spinning. Did anyone actually have a
> reason why we shouldn't proceed with Anton's patch?
Clemens answered my question regarding the real-life existence of hardware
that would benefit. I'd say if Anton's patch works on Clemens' hardware and
otherwise passes review, we should proceed...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: David Miller @ 2008-02-20 0:30 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802191350590.10089@blarg.am.freescale.net>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 13:51:37 -0600 (CST)
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions down to one. This causes problems on ppc32 for the
> memory region as its assumed to only have one region.
>
> We can fix this easily by causing the initial add to replace the dummy
> region.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Fix a bug the initial patch introduced if we have a region that gets added
> at the beginning of the list we wouldn't actually add it.
>
> Dave can you replace the patch in you tree with this one.
I think my tree has already or will soon be pulled in so
I don't want to rebase it.
Why don't you simply send me the relative bug fix instead?
Thanks!
^ permalink raw reply
* [PATCH] [POWERPC] fix warning in pseries/power.c
From: Stephen Rothwell @ 2008-02-20 0:27 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Greg KH
Introduced by commit 79393fc46ede43451a500a132e5de9856f5a4c83 ("kobject:
convert pseries/power.c to kobj_attr interface").
sys_create_file takes a "struct attrbute *" not a "struct kobj_addribute *".
arch/powerpc/platforms/pseries/power.c: In function 'apo_pm_init':
arch/powerpc/platforms/pseries/power.c:78: warning: passing argument 2 of 'sysfs_create_file' from incompatible pointer type
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/power.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/power.c b/arch/powerpc/platforms/pseries/power.c
index e95fc15..6d62662 100644
--- a/arch/powerpc/platforms/pseries/power.c
+++ b/arch/powerpc/platforms/pseries/power.c
@@ -75,7 +75,7 @@ core_initcall(pm_init);
#else
static int __init apo_pm_init(void)
{
- return (sysfs_create_file(power_kobj, &auto_poweron_attr));
+ return (sysfs_create_file(power_kobj, &auto_poweron_attr.attr));
}
__initcall(apo_pm_init);
#endif
--
1.5.4.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Greg KH @ 2008-02-19 23:55 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080219151149.684610000@sunsite.dk>
On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
> This patch adds HCD support for the Cypress c67x00 family of devices.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And it doesn't build:
CC [M] drivers/usb/c67x00/c67x00-hcd.o
distcc[2413] ERROR: compile /home/gregkh/.ccache/c67x00-hcd.tmp.mini.2409.i on localhost failed
drivers/usb/c67x00/c67x00-hcd.c:345: error: redefinition of 'c67x00_hcd_probe'
drivers/usb/c67x00/c67x00-hcd.h:119: error: previous definition of 'c67x00_hcd_probe' was here
drivers/usb/c67x00/c67x00-hcd.c:402: error: redefinition of 'c67x00_hcd_remove'
drivers/usb/c67x00/c67x00-hcd.h:126: error: previous definition of 'c67x00_hcd_remove' was here
make[2]: *** [drivers/usb/c67x00/c67x00-hcd.o] Error 1
make[1]: *** [drivers/usb/c67x00] Error 2
make: *** [_module_drivers/usb] Error 2
This is _after_ removing the obviously incorrect usb_disabled()
function that you included in your .h file.
I'm going to hold off applying any of these for now, as it doesn't look
like something is configured properly here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-02-19 23:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jean Delvare, Stephen Rothwell, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <20080220104133.e9722e62.sfr@canb.auug.org.au>
On Wednesday 20 February 2008, Stephen Rothwell wrote:
> > > - =A0 =A0 =A0 depends on IBM_OCP
> > > + =A0 =A0 =A0 depends on IBM_OCP || PPC_MERGE
>=20
> not PPC_OF? =A0or even OF (give the sparc guys the opportunity to build it
> for us :-))?
>=20
Right, I was looking for that option but couldn't find it. I would
guess sparc doesn't work because it's lacking the necessary I/O functions,
in_8 and out_8 that are powerpc specific.
so maybe:
depends on PPC
depends on IBM_OCP || OF
Arnd <><
^ 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