From: Anton Vorontsov
Date: Wed, 18 Mar 2009 22:21:52 +0300
> David, I believe Kumar would like to pick this patch into his tree
> along with a patch set that adds "ranges = <>" properties to the
> device tree... So would you mind if we take it via powerpc.git?
No problem, and feel free to add m
From: Kumar Gala
Date: Tue, 17 Mar 2009 11:16:07 -0500
> We need to be passing the of_platform device struct into the DMA ops as
> its the one that has the archdata setup to know which low-level DMA ops we
> should be using (not the net_device one). This isn't an issue until we
> expect the arch
Hi all,
please bear these probably newbie questions.
I am trying to port a BSP from 2.4 to 2.6 for a mpc834x based platform.
I am building and working on the device tree now.
Is there a way build this bsp, without taking the device tree route ?
I guess not.
The uboot version i am using is old an
On Wed, Mar 18, 2009 at 11:42 PM, David Miller wrote:
> From: Grant Likely
> 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 o
On Thu, 2009-03-19 at 17:07 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
> > 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 h
On Wed, 2009-03-18 at 22:47 +0900, TOMARI Hisanobu wrote:
> 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?
Actually, it makes -some- am
Hi Grant,
Thanx a lot for the comments. I will start activities to bind the phy
type to the phy layer and post someting useful. But, to be honest,
please correct me on spot wherever i go wrong. I am new the open
source and this is very exciting!
thanx!
Sundar
On Thu, Mar 19, 2009 at 11:31 AM, Gr
On Wed, Mar 18, 2009 at 11:37 PM, sunder ramani wrote:
> To Summarize, should not we have a phy_type flag in the OF tree which
> will let the PHY layer do the various PHY tasks based on if it is a
> copper/fiber interface. I really dont like my fix in my kernel and am
> new to open source. Do you
From: Grant Likely
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 apply yet"
instead of 9
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 k
On Wed, 2009-03-18 at 23:00 -0600, Grant Likely wrote:
> From: Grant Likely
>
> 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
> ---
>
> drivers/of/base.c | 23 +++
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:01 PM, Grant Likely
wrote:
> From: Grant Likely
>
> This patch simplifies the driver by making use of more common code.
>
> Signed-off-by: Grant Likely
> ---
>
> drivers/net/fs_enet/fs_enet-main.c | 66
> +--
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> This patch simplifies the driver by making use of more common code.
>
> Signed-off-by: Grant Likely
> ---
>
> drivers/net/pasemi_mac.c | 19 +++
> drivers/net/pasemi_ma
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> This patch simplifies the driver by making use of more common code.
>
> Signed-off-by: Grant Likely
> ---
>
> drivers/net/ucc_geth.c | 27 ++-
> drivers/net
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> This patch simplifies the driver by making use of more common code.
>
> Signed-off-by: Grant Likely
> ---
>
> drivers/net/gianfar.c | 94
> ++--
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> 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
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> Add support for parsing the device tree for PHY devices on an MDIO bus
>
> CC: Andy Fleming
> CC: linuxppc-dev@ozlabs.org
> CC: devtree-disc...@ozlabs.org
>
> Signed-off-by: Grant Likely
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> 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
RFC, please don't apply yet.
On Wed, Mar 18, 2009 at 11:00 PM, Grant Likely
wrote:
> From: Grant Likely
>
> 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 alread
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 u
From: Grant Likely
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely
---
drivers/net/fs_enet/fs_enet-main.c | 66 +---
drivers/net/fs_enet/mii-bitbang.c | 29 +---
drivers/net/fs_enet/mii-fec.c
From: Grant Likely
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely
---
drivers/net/pasemi_mac.c | 19 +++
drivers/net/pasemi_mac.h |1 -
2 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/net/pasem
From: Grant Likely
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely
---
drivers/net/ucc_geth.c | 27 ++-
drivers/net/ucc_geth_mii.c | 17 +++--
2 files changed, 9 insertions(+), 35 deletions(-)
diff -
From: Grant Likely
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely
---
drivers/net/gianfar.c | 94 ++---
drivers/net/gianfar.h |3 +
drivers/net/gianfar_mii.c | 52 +
From: Grant Likely
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 FEC's own MDIO bus. With t
From: Grant Likely
Add support for parsing the device tree for PHY devices on an MDIO bus
CC: Andy Fleming
CC: linuxppc-dev@ozlabs.org
CC: devtree-disc...@ozlabs.org
Signed-off-by: Grant Likely
---
drivers/of/Kconfig |6 ++
drivers/of/Makefile |1
drivers/of/of_mdio.c|
From: Grant Likely
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 doesn't need or know what
From: Grant Likely
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 it is good practice
to c
From: Grant Likely
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
---
drivers/of/base.c | 23 +++
include/linux/of.h |3 +++
2 files changed, 26 insertions(+
On Tue, Mar 10, 2009 at 2:29 PM, Anton Vorontsov
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'. All we need is
From: Grant Likely
Building the fs_enet driver as a modules fails because it cannot
access the global cpm2_immr symbol.
Signed-off-by: Grant Likely
---
Hey Ben and Kumar,
Just found this while testing some unrelated changes. Technically
this is a bug fix that should go into 2.6.29, but it lo
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
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"
On Thu, Mar 19, 2009 at 6:21 AM, Feng Kan 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,
(squashfs/ubifs/layered fs/..
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 facility in .dts
> > files. ;-) I heard some rumors about this, what was the consequence?..
>
> You can already do a raw include, b
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]
>
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 D
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 cas
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 ether...@24000
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 l
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 ent
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 "fsl
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 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 ta
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 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 controlle
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
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
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 Devic
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 |
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 atta
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 ]
Badne
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>;
>
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 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
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"
>>> - d
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 "G
On Tue, Mar 17, 2009 at 12:52:52PM -0400, Mark Bishop wrote:
> Quoting Vijay Nikam :
>
>> 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 configuratio
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
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 design
On Wed, Mar 18, 2009 at 10:29 AM, Eddie Dawydiuk 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 proposed design to
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 desi
On Wed, Mar 18, 2009 at 9:43 AM, Scott Wood 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 future.
On Wed, Mar 18, 2009 at 06:28:00PM +0300, Anton Vorontsov wrote:
> It would be great to have #include 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
templates/macros to make it us
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 pa
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 t
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 wrote:
>
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
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
> >>
> >> This patch adds support for multi-chip NAND devices to the FSL-UPM
> >> driver. This requi
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 to
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
---
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1889 ++
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
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 364
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 time
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
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... thi
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";
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 th
Anton Vorontsov wrote:
> On Tue, Mar 17, 2009 at 10:12:19AM +0100, Wolfgang Grandegegr wrote:
>> From: Wolfgang Grandegger
>>
>> 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: Wolfgang Gr
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 struc
Anton Vorontsov wrote:
> On Tue, Mar 17, 2009 at 10:12:22AM +0100, Wolfgang Grandegegr wrote:
>> From: Wolfgang Grandegger
>>
>> 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 channel.
81 matches
Mail list logo
