hello all
SDR0_MFR_ECS is defined for 440xx,now want to change it for 405ex ,but i
donnot known what means in /drivers/net/ibm_newemac/core.c line 2374 to 2385 ?
plese help me
leo
On Fri, 2009-02-20 at 17:35 -0800, Shubhada Pugaonkar wrote:
>
>
> cxgb3_main.c:
>
> mmio_start = pci_resource_start(pdev, 0);
>
> mmio_len = pci_resource_len(pdev, 0);
>
> ai = t3_get_adapter_info(ent->driver_data);
> > Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
> > functions/macros I need to use to do byte swapping to make everything
> > go little endian (and back again when I read them back in the kernel)?
> >
> > Or is there some cleverer way already implemented in the kernel?
> >
>
On Fri, Feb 20, 2009 at 03:56:39PM -0600, Matt Sealey wrote:
> On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote:
> > On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
> >> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
> >> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey w
On Fri, 2009-02-20 at 12:57 -0600, Matt Sealey wrote:
> Hi guys,
>
> What's the correct way to read from PCI address space (basically it's
> guaranteed to be non-coherent memory bar) without flipping bits like
> ioread32() does?
ioread32be() ? :-) But from what you say below, it seems the wrong
a
On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
>> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
>> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>> >
>> > I'm pretty sure memcpy_fromio() and memcpy_toio() wil
Scott,
I am not so sure about your PHY, but if you access to PHY while packet
transmission through MDIO bus, the packet might be corrupted. Do you
have "phy_interrupt" in the /proc/interrupts? What is your dmesg around
the eTSEC look like (there is phy driver info surrounded).
Regards
Dai
> --
On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote:
> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
> >
> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> > want. They don't change byte orderi
Dai,
> Is this your own board? If so, what PHY chip are you using? Are you
> using the PHY driver?
> If the generic PHY driver is used and polling the MDIO periodically
for
> the link check, you may truncate the packet. I hope this is not the
> case.
Yes this is our own board. Both the 8568
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
* Kumar Gala | 2009-02-19 14:49:17 [-0600]:
Now that we set archdata for of_platform and platform devices via
platform_notify() we no longer need to special case having a NULL
device
pointer or NULL archdata. It should be a driver error if
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
* Kumar Gala | 2009-02-19 14:49:16 [-0600]:
Since a number of powerpc chips are SoCs we end up having dma-able
devices that are registered as platform or of_platform devices. We
need
to hook the archdata to setup proper dma_ops for these
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote:
* Kumar Gala | 2009-02-19 14:49:15 [-0600]:
This will allow us to remove the ppc32 specific checks in
get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forwa
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote:
> On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
>
> I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you
> want. They don't change byte ordering.
Are they guaranteed to only do 32-bit, aligned accesses?
I made s
Hi Scott,
Is this your own board? If so, what PHY chip are you using? Are you
using the PHY driver?
If the generic PHY driver is used and polling the MDIO periodically for
the link check, you may truncate the packet. I hope this is not the
case.
Regards
Dai
> -Original Message-
> From
On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote:
> Hi guys,
>
> What's the correct way to read from PCI address space (basically it's
> guaranteed to be non-coherent memory bar) without flipping bits like
> ioread32() does?
>
> I need to be able to copy a bank of registers from PCI ad
Hi guys,
What's the correct way to read from PCI address space (basically it's
guaranteed to be non-coherent memory bar) without flipping bits like
ioread32() does?
I need to be able to copy a bank of registers from PCI address space
into a temporary buffer so I can compare them in userspace thro
Hi,
I am a newbie to PowerPC architecture and eTSEC. I have some queries:
1. Is there a way for me to configure different eTSECs in different media
modes? I understand that the MII interface does the same thing; yet do I
have to take some explicit care in the drivers for the eTSEC to
differentiat
Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.
Signed-o
On Fri, Feb 20, 2009 at 11:31:09AM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>> index 3e3ec8f..c54b90d 100644
>> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
>> +++ b/arch/powerpc/boot/dts/mpc83
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.
So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: Anton Vorontsov
Acked-by: Arnd Bergmann
---
drivers/mmc/host/Kconfig|
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
t
FSL eSDHC controllers can support maximum block size up to 4096
bytes. The MBL (Maximum Block Length) field in the capabilities
register extended by one bit, and bits 13:15 in the block size
register reserved.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 28 +++
FSL eSDHC controllers losing signal/interrupt enable states after
reset, so we should re-enable them.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |7 +++
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sd
SDHCI driver must take special care when working with "triggering"
registers on hosts with strict 32 bit addressing.
In FSL eSDHC hosts all registers are 32 bit width, writing to the
first half of any register will cause [undefined?] write the second
half of the register. That is, 16 bit write to
Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.
This patch modifies the driver so that now we only enable relevant
(DMA or PIO) interrupts during transfers.
Signed-off-by: Anton Vorontsov
---
dri
From: Ben Dooks
Some controllers do not provide clock information in their capabilities
(in the Samsung case, it is because there are multiple clock sources
available to the controller). Add hooks to allow the system to supply
clock information.
p.s.
In the original Ben's patch there was a bug t
This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.
p.s. Actually, the quirk is more board-specific than
controller-specific.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |2 ++
drivers/mmc/host/sdhci.h |2
Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).
With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.
For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endi
Card detection interrupts should be handled separately as they should
not be enabled before mmc_add_host() returns and should be disabled
before calling mmc_remove_host(). The same is for suspend and resume
routines.
sdhci_init() no longer enables card-detection irqs. Instead, two new
functions im
This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.
This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to
From: Ben Dooks
The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
to generate an INT_DATA_END after the transfer has completed and
the bus busy state finished.
Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
new busy method are the cause of the behaviour change.
Si
Hi all,
Some updates for the eSDHC support:
Changes since the third RFC:
- Use uninitialized_var() (suggested by Laurent Pinchart);
- Fixed a bug in eSDHC SDCLK prescaler calculations because of which
we were over-clocking the SDCLK, and that caused CRC errors using some
SD cards;
- Not a cha
Anton Vorontsov wrote:
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 3e3ec8f..c54b90d 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -137,6 +137,7 @@
reg = <0x3000 0x100>
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 Fri, 20 Feb 2009 16:46:44 +0100
Geert Uytterhoeven wrote:
> Fortunately there already exists a generic RTC class driver: "rtc-parisc".
> Despite it's name, it's platform-independent, as it's build on top of the RTC
> abstraction used by "genrtc".
>
> This patch series
> - adds a missing mod
Warning: genrtc and rtc-generic are not 100% userspace compatible:
- /dev/rtc provided by genrtc uses a misc character device (10:135)
- /dev/rtc provided by rtc-generic uses a dynamic character device
Signed-off-by: Geert Uytterhoeven
---
drivers/char/Kconfig | 25 ---
drivers/char/Makef
The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic, and make it depend on the new
Kconfig symbol ARCH_HAS_GENERIC_RTC.
Signed-off-by: Geert Uytterhoeven
---
arch/parisc/Kco
I've been looking into problems with auto-loading the RTC driver on PPC (more
specifically on PS3):
- The recent "rtc-ppc" RTC class driver is not autoloaded by udev because
it's an old style platform driver that contains its own platform device.
- The alternative old "genrtc" driver is au
Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set.
Kill rtc-ppc, as rtc-generic offers the same functionality in a more generic
way.
Signed-off-by: Geert Uytterhoeven
---
arch/powerpc/Kconfig |4 ++
arch/powerpc/kernel/time.c | 22 ++
drivers/rtc/Kcon
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/Kconfig |4
arch/m68k/kernel/time.c | 21 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index fb87c08..9d2565e 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m
Make udev autoload the driver
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index c6bfa6f..28fb7d3 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc
The new firmware release exports further RTC calls. This
patch adds these calls to the QPACE platform setup file.
Signed-off-by: Benjamin Krill
---
arch/powerpc/platforms/cell/qpace_setup.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/qpac
Hello,
My board has a Davicom DM9000A ethernet controller on the MPC5200B's
Local Plus bus.
With the following setup and code the controller *works fine* with the
MPC5200B, but I think the code + setup to make it happen could be a
lot cleaner.
The DM9000A is setup for 16 bit mode, and wired as su
From: Thomas Klein
Date: Thu, 19 Feb 2009 12:32:11 +0100
> Added missing set_bit() to disable data transfer when a memchange
> notification is handled
>
> Signed-off-by: Thomas Klein
Applied to net-next-2.6
But this was a real pain because you never tell me what
tree your changes are destined
From: Anton Blanchard
Date: Fri, 20 Feb 2009 16:19:56 +1100
>
> Hi David,
>
> > I should probably do this on sparc64 too.
> >
> > Why don't we just change this thing to CONFIG_64BIT?
>
> I agree. How does this look?
Hmmm... my bad, I think you need to keep the CONFIG_NUMA
there too as there
45 matches
Mail list logo
