Anton Vorontsov wrote:
On Tue, Mar 17, 2009 at 10:12:22AM +0100, Wolfgang Grandegegr wrote:
From: Wolfgang Grandegger w...@grandegger.com
This patch adds multi-chip support for the Micron MT29F8G08FAB NAND
flash memory on the TQM8548 modules.
This patch should go through the powerpc/85xx
Hi,
I'm trying to get the spidev.c driver working in Kernel 2.6.27.19 on a ppc8247.
Firstly, would I need to convert it to an 'of'-style driver?
Assuming this is the case, I've changed spidev_init() to use
of_register_platform_driver() with what I think is an appropriate
parameter:
static
Anton Vorontsov wrote:
On Tue, Mar 17, 2009 at 10:12:19AM +0100, Wolfgang Grandegegr wrote:
From: Wolfgang Grandegger w...@grandegger.com
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver. This requires support for multiple GPIOs for the RNB pins.
Signed-off-by:
On Wed, 2009-03-18 at 14:06 +0900, TOMARI Hisanobu wrote:
Hello,
I'm using an OCZ PATA SSD on Apple PowerBook5,4 computer.
The IDE drive fails to recognize 80-conductor cable that
connects the drive to motherboard to fall back to UDMA33.
This patch fixes this behavior by assuming that the
An alternative: the task that created the container namely, is the parent
(outside the container) of the container init(1). In turn, init(1) creates
a special 'monitor' thread that monitors the restart, and the outside task
reaps the exit status of that thread (and only that thread).
[Hmmm...
Hi Daniel,
in the attachment i send a spi driver (little bit of) done by myself
1.
to init it you can use the following in your dts-file
s...@f000 {
...
c...@119c0 {
...
s...@11aa0 {
device_type = spi;
Hi,
I have a request from a client to support PCIe hot plugging on an PowerPC Linux
platform.
I have had a general look into how Linux supports PCIe hot plugging, i.e.
pciehp utilising ACPI firmware.
I'm not too familiar with the PowerPC platform and I'm not sure if ACPI is
supported at all
The following series implements basic support for the GE Fanuc PPC9A, a
6U single board computer, based on the Freescale MPC8641D.
This series provides:
- The ability to boot the board with a serial console.
- Ethernet support.
- Sata and USB.
- Support for one of the 2 available watchdog
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/boot/dts/gef_ppc9a.dts |
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the default config file for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
Mark,
I found that the current sata_dwc can only work on
DENX-2.6.25-stable, and have problems in DENX-2.6.26, 27, 28,
29(master),
the boot errors is as the following, I hope you and AMCC staff submit
it into mainline soon, thanks.
there is also some other boot panic kmsg, I will reproduce it
On Wed, Mar 18, 2009 at 08:41:17AM +0100, Wolfgang Grandegger wrote:
Anton Vorontsov wrote:
On Tue, Mar 17, 2009 at 10:12:19AM +0100, Wolfgang Grandegegr wrote:
From: Wolfgang Grandegger w...@grandegger.com
This patch adds support for multi-chip NAND devices to the FSL-UPM
driver. This
On Mar 17, 2009, at 1:59 PM, Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so
I thought the short-40pin assumption would cause no problem
considering all models beginning with PowerBook5 are laptops.
Do you mean an option to toggle this hack on/off should be present
in Kconfig?
Thanks,
TOMARI Hisanobu
On Wed, 18 Mar 2009 18:58:17 +1100
Benjamin Herrenschmidt
On Wed, Mar 18, 2009 at 08:21:18AM -0500, Kumar Gala wrote:
[...]
arch/powerpc/platforms/83xx/mpc834x_mds.c |1 +
arch/powerpc/platforms/83xx/mpc837x_mds.c |1 +
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
14 files changed, 398 insertions(+), 319 deletions(-)
If we do this we
Benjamin Herrenschmidt wrote:
On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote:
I found a bug when using the function __div64_32 in assembly in a 32 bit
ppc
architecture unit.
I tried the numbers 5583456504800 for the dividend and 4294967079 for
the divisor. When passing these
On Wed, Mar 18, 2009 at 06:28:00PM +0300, Anton Vorontsov wrote:
It would be great to have #include gianfar_enet.dts facility in .dts
files. ;-) I heard some rumors about this, what was the consequence?..
You can already do a raw include, but in most cases it needs parameterized
On Wed, Mar 18, 2009 at 9:43 AM, Scott Wood scottw...@freescale.com wrote:
On Wed, Mar 18, 2009 at 06:28:00PM +0300, Anton Vorontsov wrote:
ranges = 0x0 0x24520 0x20;
Yes, will change.
I'd prefer ranges = 0 0x24000 0x1000, in case any other sub-blocks come
along in the
Hello,
I'm working on SD card and Nand drivers that I would like to eventually submit
for inclusion in the mainline kernel. This being my first kernel port being
submitted upstream I was hoping for comments on my proposed design to ensure it
would be excepted in the mainline kernel(from a
On Wed, Mar 18, 2009 at 10:29 AM, Eddie Dawydiuk ed...@embeddedarm.com wrote:
Hello,
I'm working on SD card and Nand drivers that I would like to eventually
submit for inclusion in the mainline kernel. This being my first kernel port
being submitted upstream I was hoping for comments on my
Hello,
I'm working on SD card and Nand drivers that I would like to eventually
submit for inclusion in the mainline kernel. This being my first kernel port
being submitted upstream I was hoping for comments on my proposed design to
ensure it would be excepted in the mainline kernel(from a
Hi Martyn,
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c7352f7..ecf52e4 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -772,7 +772,7 @@ config TXX9_WDT
config GEF_WDT
tristate GE Fanuc Watchdog Timer
- depends on GEF_SBC610
On Tue, Mar 17, 2009 at 12:52:52PM -0400, Mark Bishop wrote:
Quoting Vijay Nikam vijay.t.ni...@gmail.com:
Hi Mark,
Could you please let me know how you booted the latest Linux kernel on
MPC8313ERDB board ? ? ? As I tried but was not successful. It hangs or
does nothing and waits at network
On Mar 18, 2009, at 12:35 PM, Wim Van Sebroeck wrote:
Hi Martyn,
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c7352f7..ecf52e4 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -772,7 +772,7 @@ config TXX9_WDT
config GEF_WDT
tristate
Hi Kumar,
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c7352f7..ecf52e4 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -772,7 +772,7 @@ config TXX9_WDT
config GEF_WDT
tristate GE Fanuc Watchdog Timer
- depends on GEF_SBC610 ||
On Thu, Mar 12, 2009 at 02:01:00PM -0500, Timur Tabi wrote:
Can someone explain CLOCK_TICK_RATE to me? It's defined in
arch/powerpc/include/asm/timex.h as such:
#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */
Every architecture defines this, but some use the better comment
On Mon, Mar 16, 2009 at 05:39:08AM -0800, liran raz wrote:
Thanks, I don't see any mdev process running.
Does it run during the boot scripts? Or do you have udev?
Just wonder who is creating /dev/ttyCPM1 since in the device table file
(device_table.txt)
I have only node: 204 (major) 46
On Tue, Mar 17, 2009 at 10:12:22AM +0100, Wolfgang Grandegegr wrote:
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -389,6 +389,11 @@
reg = 3 0x0 0x800;
fsl,upm-addr-offset = 0x10;
Currently the drivers just read reg property for constructing MDIO
bus IDs, but this won't work when we'll start using ranges = in
the device tree, so this will pop up:
Gianfar MII Bus: probed
sysfs: duplicate filename 'm...@520' can not be created
[ cut here ]
Badness at
The I2C driver for the MPC still uses a fixed clock divider hard-coded
into the driver. This issue has already been discussed twice:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21933.html
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg26923.html
Let's code speak ;-). The
On Wed, Mar 18, 2009 at 06:28:00PM +0300, Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 08:21:18AM -0500, Kumar Gala wrote:
[...]
arch/powerpc/platforms/83xx/mpc834x_mds.c |1 +
arch/powerpc/platforms/83xx/mpc837x_mds.c |1 +
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
14
This patch adds pmc nodes to the device tree files so that the boards
will able to use standby capability of MPC837x processors. The MPC837x
PMC controllers are compatible with MPC8349 ones (i.e. no deep sleep).
sleep = properties are used to specify SCCR masks as described
in Specifying Device
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so the mdio nodes should be placed
correctly. Otherwise we
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so the mdio nodes should be placed
correctly. Otherwise we
Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so the mdio nodes should be placed
On Wed, Mar 18, 2009 at 03:05:51PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
effect), mdio nodes placement will become important: mdio controller
is a
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 03:05:51PM -0500, Scott Wood wrote:
Hmm, would that imply that the mdio underneath it is disabled as well?
Technically, yes. In practice, MDIO and MAC drivers are probed
separately.
Currently, yes, but that may not always be the case.
I don't
On Wed, Mar 18, 2009 at 11:23:44PM +0300, Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 03:05:51PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = properties will take
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 11:23:44PM +0300, Anton Vorontsov wrote:
I don't see any better solution, should I just leave the core1's
mdio node intact?
Ah. We also could change compatible entry to fsl,gianfar-slave.
This will prevent gianfar MAC driver to probe on core1.
On Wed, Mar 18, 2009 at 03:31:29PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 11:23:44PM +0300, Anton Vorontsov wrote:
I don't see any better solution, should I just leave the core1's
mdio node intact?
Ah. We also could change compatible entry to
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 03:31:29PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 11:23:44PM +0300, Anton Vorontsov wrote:
I don't see any better solution, should I just leave the core1's
mdio node intact?
Ah. We also could change compatible
On Wed, Mar 18, 2009 at 03:35:11PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 03:31:29PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
On Wed, Mar 18, 2009 at 11:23:44PM +0300, Anton Vorontsov wrote:
I don't see any better solution, should I just leave the
Anton Vorontsov wrote:
I mean do you see any problem with giving Linux knowledge of
the -slave name?
I guess I don't really see the point, compared with just having a naked
mdio node. The power management issue in this case should be addressed
by ensuring that core0 never puts
On Wed, Mar 18, 2009 at 03:46:49PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
I mean do you see any problem with giving Linux knowledge of
the -slave name?
I guess I don't really see the point, compared with just having a naked
mdio node. The power management issue in this case
Hi RenQuan:
We are aware of the issue, currently the sata is only supported up to
2.6.25.7. We are working on a patchable version
to submit to main line.
Thanks
Feng Kan
Cheng Renquan wrote:
Mark,
I found that the current sata_dwc can only work on
DENX-2.6.25-stable, and have problems in
On Wed, Mar 18, 2009 at 12:29:15PM +, Martyn Welch wrote:
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
One tiny nit left..
[snip]
+
On Wed, Mar 18, 2009 at 10:43:07AM -0500, Scott Wood wrote:
On Wed, Mar 18, 2009 at 06:28:00PM +0300, Anton Vorontsov wrote:
It would be great to have #include gianfar_enet.dts facility in .dts
files. ;-) I heard some rumors about this, what was the consequence?..
You can already do a raw
On Thu, Mar 19, 2009 at 6:21 AM, Feng Kan f...@amcc.com wrote:
Hi RenQuan:
We are aware of the issue, currently the sata is only supported up to
2.6.25.7. We are working on a patchable version
to submit to main line.
Well, we want some new kernel features on amcc borads,
Timur Tabi writes:
Can someone explain CLOCK_TICK_RATE to me? It's defined in
arch/powerpc/include/asm/timex.h as such:
#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */
Every architecture defines this, but some use the better comment
Underlying frequency of the HZ timer.
My
Commit bedd30d986a05e32dc3eab874e4b9ed8a38058bb (genirq: make irqreturn_t
an enum) from the genirq tree in next-20090319 caused this new warning:
arch/powerpc/sysdev/pmi.c: In function 'pmi_of_probe':
arch/powerpc/sysdev/pmi.c:166: warning: passing argument 2 of 'request_irq'
from incompatible
From: Grant Likely grant.lik...@secretlab.ca
Building the fs_enet driver as a modules fails because it cannot
access the global cpm2_immr symbol.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
Hey Ben and Kumar,
Just found this while testing some unrelated changes. Technically
this
On Tue, Mar 10, 2009 at 2:29 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Tue, Mar 10, 2009 at 01:48:26PM -0600, Grant Likely wrote:
Regardless, I
think all the drivers should be using common code for obtaining the
phy_device from the device tree.
Not necessary `struct phy_device'.
From: Grant Likely grant.lik...@secretlab.ca
of_parse_phandle() is a helper function to read and parse a phandle
property and return a pointer to the resulting device_node.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/base.c | 23 +++
From: Grant Likely grant.lik...@secretlab.ca
This patch makes changes in preparation for supporting open firmware
device tree descriptions of MDIO busses. Changes include:
- Cleanup handling of phy_map[] entries; they are already NULLed when
registering and so don't need to be re-cleared, and
From: Grant Likely grant.lik...@secretlab.ca
Add phy_connect_direct() and phy_attach_direct() functions so that
drivers can use a pointer to the phy_device instead of trying to determine
the phy's bus_id string.
This patch is useful for OF device tree descriptions of phy devices where
the driver
From: Grant Likely grant.lik...@secretlab.ca
Add support for parsing the device tree for PHY devices on an MDIO bus
CC: Andy Fleming aflem...@freescale.com
CC: linuxppc-dev@ozlabs.org
CC: devtree-disc...@ozlabs.org
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/Kconfig
From: Grant Likely grant.lik...@secretlab.ca
The patch reworks the MPC5200 Fast Ethernet Controller (FEC) driver to
use the of_mdio infrastructure for registering PHY devices from data out
openfirmware device tree, and eliminates the assumption that the PHY
for the FEC is always attached to the
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/gianfar.c | 94 ++---
drivers/net/gianfar.h |3 +
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/ucc_geth.c | 27 ++-
drivers/net/ucc_geth_mii.c | 17 +++--
2 files
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/pasemi_mac.c | 19 +++
drivers/net/pasemi_mac.h |1 -
2 files changed, 3
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/fs_enet/fs_enet-main.c | 66 +---
drivers/net/fs_enet/mii-bitbang.c | 29
Bah! Messed up the 'stg mail' command when sending this series and
the 'RFC' tag didn't get added.
This is firmly in the RFC category. Please don't apply. It doesn't
have the level of polish that I'm happy with.
This series is intended to make phy_device connecting simpler and more
robust by
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch makes changes in preparation for supporting open firmware
device tree descriptions of MDIO busses. Changes include:
- Cleanup
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
Add phy_connect_direct() and phy_attach_direct() functions so that
drivers can use a pointer to the phy_device instead of trying to
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
Add support for parsing the device tree for PHY devices on an MDIO bus
CC: Andy Fleming aflem...@freescale.com
CC:
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
The patch reworks the MPC5200 Fast Ethernet Controller (FEC) driver to
use the of_mdio infrastructure for registering PHY devices from data
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:01 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
On Wed, 2009-03-18 at 23:00 -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
of_parse_phandle() is a helper function to read and parse a phandle
property and return a pointer to the resulting device_node.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
Hi Grant,
I have here one query though. I found out that there are various
configurations of the PHY device that my be connected to the eTSEC on
the 8548. I am talking only about this because I faced some issues.
My HW had RGMII, SGMII configurations for the different ports to the
PHYs. And the
From: Grant Likely grant.lik...@secretlab.ca
Date: Wed, 18 Mar 2009 23:07:35 -0600
RFC, please don't apply yet.
You know, if you have posted a 0/9 patch explaining the purpose
and intent of the patch series, you'd only need to re-shit into
my inbox one time to say this stuff is RFC and don't
73 matches
Mail list logo
