* [PATCH 1/3][RESEND] phylib: add PHY interface modes for internal delay for tx and rx only
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Allow phylib specification of cases where hardware needs to configure
PHYs for Internal Delay only on either RX or TX (not both).
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
include/linux/phy.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f0742b6..e10763d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -58,6 +58,8 @@ typedef enum {
PHY_INTERFACE_MODE_RMII,
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
+ PHY_INTERFACE_MODE_RGMII_RXID,
+ PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI
} phy_interface_t;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/3][RESEND] phylib: marvell: add support for TX-only and RX-only Internal Delay
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Previously, Internal Delay specification implied the delay be
applied to both TX and RX. This patch allows for separate TX/RX-only
internal delay specification.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/phy/marvell.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 035fd41..f057407 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -143,21 +143,29 @@ static int m88e1111_config_init(struct phy_device *phydev)
int err;
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
- (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)) {
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
int temp;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
- temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
- if (temp < 0)
- return temp;
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ if (temp < 0)
+ return temp;
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
temp |= (MII_M1111_RX_DELAY | MII_M1111_TX_DELAY);
-
- err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
- if (err < 0)
- return err;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ temp &= ~MII_M1111_TX_DELAY;
+ temp |= MII_M1111_RX_DELAY;
+ } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ temp &= ~MII_M1111_RX_DELAY;
+ temp |= MII_M1111_TX_DELAY;
}
+ err = phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
+ if (err < 0)
+ return err;
+
temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
if (temp < 0)
return temp;
--
1.5.2.2
^ permalink raw reply related
* [PATCH 3/3][RESEND] ucc_geth: handle passing of RX-only and TX-only internal delay PHY connection type parameters
From: Kim Phillips @ 2007-11-26 22:17 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Li Yang, linuxppc-dev
Extend the RGMII-Internal Delay specification case to include
TX-only and RX-only variants.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Li Yang <leoli@freescale.com>
---
drivers/net/ucc_geth.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index a3ff270..7f68990 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1460,6 +1460,8 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
upsmr |= UPSMR_RPM;
switch (ugeth->max_speed) {
@@ -1557,6 +1559,8 @@ static void adjust_link(struct net_device *dev)
if ((ugeth->phy_interface == PHY_INTERFACE_MODE_RMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
+ (ugeth->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth->phy_interface == PHY_INTERFACE_MODE_RTBI)) {
if (phydev->speed == SPEED_10)
upsmr |= UPSMR_R10M;
@@ -3795,6 +3799,10 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_RGMII;
if (strcasecmp(phy_connection_type, "rgmii-id") == 0)
return PHY_INTERFACE_MODE_RGMII_ID;
+ if (strcasecmp(phy_connection_type, "rgmii-txid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_TXID;
+ if (strcasecmp(phy_connection_type, "rgmii-rxid") == 0)
+ return PHY_INTERFACE_MODE_RGMII_RXID;
if (strcasecmp(phy_connection_type, "rtbi") == 0)
return PHY_INTERFACE_MODE_RTBI;
@@ -3889,6 +3897,8 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
case PHY_INTERFACE_MODE_GMII:
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
case PHY_INTERFACE_MODE_TBI:
case PHY_INTERFACE_MODE_RTBI:
max_speed = SPEED_1000;
--
1.5.2.2
^ permalink raw reply related
* RE: Xilinx devicetrees
From: Koss, Mike (Mission Systems) @ 2007-11-26 22:19 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <474B37C9.8020405@dlasystems.com>
=20
>> I don't know if packaging the device tree with the bitstream is the=20
>> best way to go. It's possible that it could lead to headaches for=20
>> certain systems that have security restrictions.
> Make it an option. Where are the systems with security restrictions
going to get their hardware information ?
> Besides - though I am not aware off the top of my head of a
bitstream decompliler, still if you have access to the bitstream you
have access to
> the information about the device. We deal with alot of high security
applications. Security restrictions have to make sense.
> blocking devicetrees for security reasons is like telling somebody
they can have the manual in computer readable form, but not on paper.
> Further if you are going to boot an OS that requires devicetrees
then the devicetree must be somewhere - whether it is appended to the
bitstream,
> appended to the kernel, compiled into the kernel, in a separate file,
it still has to be present.
The devicetree itself is not the security concern, but the retrieval of
it from the bitstream. If it is stored in the FPGA, it may be that
accessing that stored information may not be probable at run-time.
>> The worst that one can say is:
>> SN> 1) I need several KB additional non volatile storage. Given the
>> size of the FPGA bitstream, this can't be a huge constraint.
>> =20
> Several KB is NOT happening. The bitstream is in flash. Flash is
not a limited reasorce for us.
> FPGA cells, and BRAM are precious as gold. The more we use the
less our clients have.
Which is why I'm proposing that it be an "extra" file that can be stored
however. For one system, it could be stored in the FPGA using BRAM and
it could be automatically available to kernel. For another system, it
could be stored in FLASH and the bootloader may have to copy the data
from FLASH to RAM.
>> I do agree that using more FPGA resources is not a solution to the=20
>> problem. I'm already hitting 80% usage on a FX60 and trying to
squeeze=20
>> more real estate for storage of the device tree seems silly.=20
>> Especially since that would require that every image have this extra=20
>> hardware built into it just to support booting a Linux kernel. Why=20
>> should I have to have different hardware to boot linux, versus=20
>> non-kernel, xilkernel, or other (GHS, LynxOS, etc..)?
>> =20
> One of the problems is that neither devicetrees, nor any of the
ways of tracking them are one size fits all solutions.
> I do GHS work, it would be nice if GHS supported devicetrees and
maybe it will.
> bound to the kernel, in a separate file, appended to the bitstream
and in the FPGA fabric all have pluses and minuses.
> One reason I am harping on version registers is they are extremely
cost cheap, can easily be made optional, and can be fairly easily
incorporated > into any OS (or no OS - we do that too). They are not a
replacement for devicetrees. But they still have very important uses in
many environments.
>
>> SN> Certainly.. But in a sense, these are all intermediate files on=20
>> SN> the
>> path to the image on the board.
> Unless we are going to teach linux to read and interpret .bit files
while loading, then devicetrees are intermediate in an entirely
different
> sense.
> The hardware works fine regardless of whether their is a
devicetree.
> But Linux may not boot.
You are correct, but I think a single self-contained file that has all
of the hardware descriptions is much preferred to many header files, and
#ifdef macro's to make sense of what is actually available at run-time.
> My objective is to get alot of software - linux, GHS, and
standalone apps, to all load - from a single executables, accross
multiple different
> bit images on several different (though deliberately
> similar) products. My Linux kernel needs to work regardless of the
Pico card and regardless of the bit image, as done my GHS kernel, and
....
> And I need to do that in a severly resource constrained environment.
> I would hope that should make sense of my harping about
version/capabilities registers. If I have maybe 10 possible peices of IP
that may/maynot
> be present in a given FPGA and I am trying to dynamically configure -
Linux/GHS/... to adapt to whatever it encounters and work as long as it
is a
> viable combination. At best devicetrees are an extremly complex way of
solving that - while version registers are a trivial way.
> As an example I know that if I have a UartLite, Keyhole, TEMAC,
PIC, ... they will always be at specific addresses. We never move them.
> But I do not know for sure it they are present. A version register
provides a fairly safe very efficient means of checking that a device is
> present (and establishing its version and maybe capabilites) - device
trees might do the same thing but have alot higher overhead to do so.
For your system, yes, you never move the location of the devices. But
for others, we may add other pieces or multiple pieces and require them
in multiple/different places. That's the beauty of the device tree. You
*can* create that one monolithic kernel that has support for ANY type of
hardware, and at boot-time a device tree is provided to the kernel that
defines all of the devices that are physically available in your FPGA.
I'm not trying to argue for/against the version registers. Just that a
version register is short-sighted with regards to the larger FPGA-based
view. Version registers work wonderfully when everything is staticly
located, like in your image builds or a SoC like 440GX. For general
usage for others creating their own FPGA images with varying hardware
setups, statically defined location version register checking is not
feasible.
The device tree approach can "easily" be adapted to other systems, such
as GHS, through adaptors in your corresponding BSP.
-- Mike
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Dave Jiang @ 2007-11-26 22:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47435338.2050107@mvista.com>
NM, it was a bad test causing weird behavior on PPC. :(
Dave Jiang wrote:
> It seems the mmap() userland call on PPC causes the kernel to lose the ref
> count for the mount point. This is what I did on a prpmc2800 board (74xx) with
> latest powerpc.git tree (but also seem to happen on 8548 as well).
>
> I mounted an IDE partition. The userland test app opens a file on the mounted
> partition and sits in a sleep loop while holding the file open. I call umount
> on the partition and I get "device is busy" which is suppose to happen.
> However, after the test app calls mmap on the file id for the opened file, I
> can successfully umount even though it should still say "device is busy". This
> does not happen on x86 so I'm assuming something is going on with just PPC.
>
> So using lsof I can list the opened files on a particular partition. When the
> file is opened, it lists 1 entry. When mmaped, on x86 it would list 2 entries,
> but on ppc it lists nothing. Not only did the mmaped entry not show up, the
> entry caused by open disappeared as well. Also, I put a printk in do_umount()
> to see what the refcount is. On x86, it would be 3 and thus causes device busy.
> On PPC it is 3 when the file is openend, however if mmap is called, the
> refcount becomes 2 and thus umount proceeds. It's almost as if the mmap call
> wiped out the opened file entry and decremented the mount count as well.
>
>
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Jon Loeliger @ 2007-11-26 22:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
This all sounds fine by me. We should take the incompatibility hit
once here and now; it shouldn't be a problem to eek in some more still.
Thanks,
jdl
^ permalink raw reply
* Re: mmap on PPC removes file refcount?
From: Benjamin Herrenschmidt @ 2007-11-26 22:38 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev
In-Reply-To: <474B4923.905@mvista.com>
On Mon, 2007-11-26 at 15:30 -0700, Dave Jiang wrote:
> NM, it was a bad test causing weird behavior on PPC. :(
Ah good, because I did spend some time looking at the code and didn't
see anything wrong :-)
Cheers,
Ben.
^ permalink raw reply
* PPC upstream kernel ignored DABR bug
From: Jan Kratochvil @ 2007-11-26 22:02 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Roland McGrath
Hi,
this testcase:
http://people.redhat.com/jkratoch/dabr-lost.c
reproduces a PPC DABR kernel bug. The variable `variable' should not get
modified as the thread modifying it should be caught by its DABR:
$ ./dabr-lost
TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30914: hitting the variable
TID 30915: hitting the variable
TID 30916: hitting the variable
variable found = 30916, caught TID = 30914
TID 30916: DABR 0x10012a77
Variable got modified by a thread which has DABR still set!
At the `variable found =' line the parent ptracer found the TID thread 30916
wrote the value into the variable - despite it had DABR alrady set before.
As the behavior is dependent on the current weather I expect the scheduling
matters there.
It is important the target thread is in the `nanosleep' syscall. If you define
WORKAROUND_SET_DABR_IN_SYSCALL in the testcase it busyloops in the userland and
the bug gets no longer reproduced.
I got it reproduced on a utrace-patched kernel on dual-CPU Power5 and Roland
McGrath reported it reproduced on the vanilla upstream kernel on a Mac G5.
Regards,
Jan Kratochvil
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 22:46 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1196107715.7195.107.camel@pasglop>
With the following 15 patches on top of the DENX git tree, I have both emac ports working:
1) [PATCH 2/2] PowerPC: Fix Sequoia MAL0 and EMAC dts entries.
2) [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
3) [PATCH] Fix typo in new EMAC driver.
4) PowerPC: Enable NEW EMAC support for Sequoia 440EPx.
5) [PATCH 1/8] ibm_newemac: Fix possible lockup on close
6) [PATCH 2/8] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
7) [PATCH 3/8] ibm_newemac: Add ET1011c PHY support
8) [PATCH 4/8] ibm_newemac: Fix ZMII refcounting bug
9) [PATCH 5/8] ibm_newemac: Workaround reset timeout when no link
10) [PATCH 6/8] ibm_newemac: Cleanup/Fix RGMII MDIO support detection
11) [PATCH 7/8] ibm_newemac: Cleanup/fix support for STACR register variants
12) [PATCH 8/8] ibm_newemac: Skip EMACs that are marked unused by the firmware
13) [PATCH 1/3] PowerPC: ibm_newemac correct opb_bus_freq value
14) [PATCH 2/3] PowerPC: ibm_newemac tah_ph typo fix
15) [PATCH 3/3] PowerPC: ibm_newemac call dev_set_drvdata() before tah_reset()
Steve
Benjamin Herrenschmidt wrote:
> On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote:
>> I've attached a copy of my bootlog. I added in one patch to enable
>> rgmii but that didn't fix
>> it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html)
>>
>> I am curious why the new emac driver is enabled in the DENX tree but
>> not in the upstream trees. Has DENX successfully used this driver on
>> the Sequoia board? Am I trying something that is known not to work?
>>
>> I'm interested in helping in whatever way I can. I need ARCH=powerpc
>> to use the current Xenomai patches, and I need both EMACs so I can
>> evaluate bonding (for high-availability).
>
> Have you tried adding the various patches I posted along with the
> patches Valentine posted ?
>
> I'll re-send a full serie later this week. Let us know if those help or
> if something is still broken.
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Benjamin Herrenschmidt @ 2007-11-26 22:49 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <474B4CA9.3070506@harris.com>
On Mon, 2007-11-26 at 17:46 -0500, Steven A. Falco wrote:
> With the following 15 patches on top of the DENX git tree, I have both emac ports working:
.../...
Good. All of these should go in 2.6.25 (not .24 at this stage though).
I suppose DENX will pick them up asap.
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Elimar Riesebieter @ 2007-11-26 22:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: joerg
In-Reply-To: <slrnfk1d21.229.joerg@alea.gnuu.de>
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Hi,
I can confirm this situation. But it seems, that no one takes care
of it ....
Elimar
--
Excellent day for drinking heavily.
Spike the office water cooler;-)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: LED heartbeat trigger - in_atomic() while allocs
From: Nathan Lynch @ 2007-11-26 20:36 UTC (permalink / raw)
To: Benedict, Michael; +Cc: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2DA2@twx-exch01.twacs.local>
Benedict, Michael wrote:
> I was playing around with the LED heartbeat trigger and it caught the
> BUG() code when trying to activate. Does anyone know why this call
> stack would be in_atomic()? Or any ideas for a patch that would allow
> the heartbeat trigger to allocate when it is not in atomic context?
>
> BUG: sleeping function called from invalid context at mm/slab.c:3024
> in_atomic():1, irqs_disabled():0
> Call Trace:
> [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> [def3de20] [c0196844] led_trigger_set+0x128/0x160
> [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> [def3df10] [c0068ff4] sys_write+0x4c/0x90
> [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xfe83818
> LR = 0xfe35448
>
> Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>From a brief glance at the code, looks like led_trigger_store is
holding a rwlock while calling led_trigger_set.
^ permalink raw reply
* Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Kok, Auke @ 2007-11-26 23:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, auke-jan.h.kok, netdev
In-Reply-To: <474791D3.1090607@pobox.com>
Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
>> The e1000 driver stores the content of the PCI resources into
>> unsigned long's before ioremapping. This breaks on 32 bits
>> platforms that support 64 bits MMIO resources such as ppc 44x.
>>
>> This fixes it by removing those temporary variables and passing
>> directly the result of pci_resource_start/len to ioremap.
>>
>> The side effect is that I removed the assignments to the netdev
>> fields mem_start, mem_end and base_addr, which are totally useless
>> for PCI devices.
>>
>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> --
>>
>> drivers/net/e1000/e1000_main.c | 18 +++++-------------
>> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> Looks good to me. auke?
yes, please apply.
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Auke
^ permalink raw reply
* Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Benjamin Herrenschmidt @ 2007-11-26 23:41 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <1416528026.20071107014041@emcraft.com>
BTW... Do you know why we can't just enable HW snoop ? The 440SPe
documentation seems to indicate that this is supported by the L2 cache
via snooping on the PLB.
Cheers,
Ben.
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Stephen Rothwell @ 2007-11-27 0:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071126172712.128301000@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> @@ -594,20 +594,21 @@ static const struct {
> unsigned mask : 19;
> unsigned id : 4;
> } ps3av_preferred_modes[] = {
> - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
Why did you remove the C99 style initialisers?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Michael Neuling @ 2007-11-27 0:35 UTC (permalink / raw)
To: Christoph Raisch
Cc: Jeff Garzik, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Paul Mackerras, Marcus Eder, tklein, Stefan Roscher
In-Reply-To: <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com>
In message <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> > a) if there are a finite number of handles and we can predict their
> > values, just delete them all in the kdump kernel before the driver
> > loads.
>
> Guessing the values does not work, because of the handle structure
> defined by the hypervisor.
>
> > b) if there are a small & finite number of handles, save their values
> > in a device tree property and have the kdump kernel read them and
> > delete them before the driver loads.
>
> 5*16*nr_ports+1+1= >82. a ML16 has 4 adapters with up to 16 ports, so the
> number is not small anymore....
I assume this machine with a huge number of adapters has a huge amount
of memory too! :-)
> The device tree functions are currently not exported.
We can add this.
> If you crashdump to a new kernel, will it get the device tree
> representation of the crashed kernel or of the initial one of open
> firmware?
The kexec tools userspace control this. Normally it just takes the
current device tree plus some modifications (eg. initrd location
changes).
So provided the ehea driver export this info somewhere, it can be
grabbed by the kexec tools and stuffed in the device tree of the new
kernel.
That being said, the proper place to have this would be original device
tree.
>
> > c) if neither of those work, provide a minimal routine that _only_
> > deletes the handles in the crashed kernel.
>
> I would hope this has the highest chance to actually work.
> For this we would have to add a proper notifier chain.
> Do you agree?
>
> > d) <something else>
>
> Firmware change? But that's not something you will get very soon.
>
> Christoph R.
>
^ permalink raw reply
* RE: LED heartbeat trigger - in_atomic() while allocs
From: Benedict, Michael @ 2007-11-27 1:02 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-embedded
In-Reply-To: <20071126203649.GD29155@localdomain>
Thanks, yeah I see that now. I just changed the alloc to be GPF_ATOMIC
for now, but I don't really know how this was intended to work.
-Michael=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+mbenedict=3Dtwacs.com@ozlabs.o
rg] On Behalf Of Nathan Lynch
> Sent: Monday, November 26, 2007 2:37 PM
> To: Benedict, Michael
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: LED heartbeat trigger - in_atomic() while allocs
>=20
> Benedict, Michael wrote:
> > I was playing around with the LED heartbeat trigger and it=20
> caught the
> > BUG() code when trying to activate. Does anyone know why this call
> > stack would be in_atomic()? Or any ideas for a patch that=20
> would allow
> > the heartbeat trigger to allocate when it is not in atomic context?
> >=20
> > BUG: sleeping function called from invalid context at mm/slab.c:3024
> > in_atomic():1, irqs_disabled():0
> > Call Trace:
> > [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
> > [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
> > [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
> > [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
> > [def3de20] [c0196844] led_trigger_set+0x128/0x160
> > [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
> > [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
> > [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
> > [def3def0] [c0068ea4] vfs_write+0x9c/0x110
> > [def3df10] [c0068ff4] sys_write+0x4c/0x90
> > [def3df40] [c000fc00] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0xfe83818
> > LR =3D 0xfe35448
> >=20
> > Kernel 2.6.22-4, powerpc, targeting an MPC 8347.
>=20
> From a brief glance at the code, looks like led_trigger_store is
> holding a rwlock while calling led_trigger_set.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: dtc: Flexible tree checking infrastructure (v2)
From: David Gibson @ 2007-11-27 3:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmCq-0002g9-Nk@jdl.com>
On Mon, Nov 26, 2007 at 04:13:32PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > dtc: Flexible tree checking infrastructure
> >
> > Here, at last, is a substantial start on revising dtc's infrastructure
> > for checking the tree; this is the rework I've been saying was
> > necessary practically since dtc was first release.
> >
> > In the new model, we have a table of "check" structures, each with a
> > name, references to checking functions, and status variables. Each
> > check can (in principle) be individually switched off or on (as either
> > a warning or error). Checks have a list of prerequisites, so if
> > checks need to rely on results from earlier checks to make sense (or
> > even to avoid crashing) they just need to list the relevant other
> > checks there.
> >
> > For now, only the "structural" checks and the fixups for phandle
> > references are converted to the new mechanism. The rather more
> > involved semantic checks (which is where this new mechanism will
> > really be useful) will have to be converted in future patches.
> >
> > At present, there's no user interface for turning on/off the checks -
> > the -f option now forces output even if "error" level checks fail.
> > Again, future patches will be needed to add the fine-grained control,
> > but that should be quite straightforward with the infrastructure
> > implemented here.
> >
> > Also adds a testcase for the handling of bad references, which catches
> > a bug encountered while developing this patch.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> While I've Applied this one, it has introduced this:
>
> CC dtc.o
> dtc.c: In function 'main':
> dtc.c:199: warning: 'structure_ok' is used uninitialized in this function
>
> Followup easy patch?
Crap. For some reason my compiler isn't giving that warning, so I
missed that little bug :(.
I'm away at the moment, I'll see what I can do.
--
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: dtc: Add valgrind support to testsuite
From: David Gibson @ 2007-11-27 4:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmA3-0002eh-OO@jdl.com>
On Mon, Nov 26, 2007 at 04:10:39PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > This patch adds some options to the run_tests.sh script allowing it to
> > run all the testcases under valgrind to check for pointer corruption
> > bugs and memory leaks. Invoking "make checkm" will run the testsuite
> > with valgrind.
> >
> > It include a mechanism for specifying valgrind errors to be suppressed
> > on a per-testcase basis, and adds a couple of such suppression files
> > for the mangle-layout and open_pack testcases which dump for use by
> > other testcases a buffer which may contain uninitialized sections. We
> > use suppressions rather than initializing the buffer so that valgrind
> > will catch any internal access s to the uninitialized data, which
> > would be a bug.
> >
> > The patch also fixes one genuine bug caught by valgrind -
> > _packblocks() in fdt_rw.c was using memcpy() where it should have been
> > using memmove().
> >
> > At present the valgrinding won't do anything useful for testcases
> > invoked via a shell script - which includes all the dtc testcases. I
> > plan to fix that later.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> Thanks,
> jdl
>
> PS -- Clearly, I'm going to have to break down and install valgrind now. :-)
Absolutely. Actually valgrind didn't show up much interesting on
libfdt. Some preliminary investigations suggest it may find some
problems in dtc, once I get the shell scripts to pass the valgrind
option through properly.
Be aware that running the testsuite under valgrind will take a long
time. It goes from something like 1s without valgrind to 10 minutes
on one of my machines.
--
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: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-27 4:27 UTC (permalink / raw)
To: Scott Wood; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <20071126165751.GA4415@loki.buserror.net>
[-- Attachment #1: Type: text/html, Size: 4592 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Tony Breeds @ 2007-11-27 5:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1196094193.4149.287.camel@johannes.berg>
On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I'll see if I can grab an appropriate machine tomorrow and have a look at
it. I think it's just an accounting bug, which is probably my fault :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-27 7:38 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <474B2A7F.5090607@anagramm.de>
>> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
>> calling 'reboot' in the shell, it just hangs. Using the same dts and
>> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
>> someone who does should be able to confirm whether the issue exists
>> or
>> not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
>> ACK. Exactly the same over here (mpc8540ads compatible).
> I added the global-utilities today as well, but reboot fails.
if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer).
> Why is the guts stuff missing i.e. in most of the shipped
> mpc85xx*.dts? Does it depend on some hardware connections
> external to the CPU?
Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we
use to reset. (8540, 8560, 8541, 8555 do not).
- k
^ permalink raw reply
* Re: Booting latest linux kernel(2.6.20) on MPC8548ECDS
From: Kumar Gala @ 2007-11-27 7:40 UTC (permalink / raw)
To: rajendra prasad; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <760ff48e0711262154u39c30dbduacdf310b820a7c81@mail.gmail.com>
On Nov 26, 2007, at 11:54 PM, rajendra prasad wrote:
> Hi,
>
> I am using MPC8548ECDS board from CDS for my telecom application. I am
> able to build 2.6.10 linux kernel and boot 2.6.10 kernel on
> MPC8548ECDS board.When I take same configuration file and built
> successfully but not able to boot on MPC8548E CDS board.I am using
> u-boot-1.1.6 as boot loader.I came to know taht latest kernel is
> booted with new procedure.Pls tell me the procedure how to boot
> procedure.
Ask this question on the linuxppc-dev list. You're more likely to get
an answer.
Its unclear, but you are trying to use the latest kernel on a MPC8548E
CDS?
- k
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-27 8:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <474B3D7F.8060503@freescale.com>
On Mon, 26 Nov 2007 15:41:19 -0600
Scott Wood wrote:
> Vitaly Bordug wrote:
> > perhaps I was not clear enough. That was a rough idea how to handle
> > the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> > case, but there can be other actions that may confuse CPM being
> > triggered simultaneously or overlapping.
>
> What kind of actions did you have in mind? Microcode patching?
>
microcode is another case to handle gracefully. There are also
"soft" cases like cpmux mess-up, incompatible SoC devices (which we are handling by
logical exclude now but which do have natural reasons of "not leaving together" like
shared dedicated GPIO or smth else) etc.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Geert Uytterhoeven @ 2007-11-27 8:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071127110538.32f8dfef.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2562 bytes --]
On Tue, 27 Nov 2007, Stephen Rothwell wrote:
> On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > @@ -594,20 +594,21 @@ static const struct {
> > unsigned mask : 19;
> > unsigned id : 4;
> > } ps3av_preferred_modes[] = {
> > - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> > - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> > - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> > - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> > - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> > + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> > + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> > + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> > + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> > + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
>
> Why did you remove the C99 style initialisers?
Because else things no longer fit on one line.
I prefered a clean structural overview over the protection against the
(almost nonexisting) risk of initializing the wrong member.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ 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