Any plans to include this patch series at
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078693.html
into your 'next' branch or there are some outstanding issues with this.
Thanks,
Vivek
___
Linuxppc-dev mailing list
From:
linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs.
org
[mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists
.ozlabs.org] On Behalf Of Felix Radensky
Sent: Thursday, December 17, 2009 12:52 PM
I just noticed a MSI enable bit in
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Thursday, December 17, 2009 2:26 PM
Yes, I've enabled that bit, but didn't get any interrupt.
Thanks for trying.
Thanks a lot. If I understand you correctly, the only way I
can get ath9k driver to work on this board using
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Wednesday, December 16, 2009 2:56 PM
To: Mahajan Vivek-B08308
Cc: linuxppc-...@ozlabs.org; Aggrwal Poonam-B10812; Kumar Gala
Subject: Re: Problem with mini-PCI-E slot on P2020RDB
Hi,
Looks like INTA is not being routed to IRQ0
From: Felix Radensky [mailto:fe...@embedded-sol.com]
Sent: Wednesday, December 16, 2009 5:30 PM
As per the p2020rm, PCIe legacy INTA is shared with IRQ0 for this
ctlr, which is the exactly the case with other SoC's p2020ds,
mpc8536ds, mpc8572ds. To me it seems like a board issue and
-Original Message-
From:
linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs.
org
[mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists
.ozlabs.org] On Behalf Of Felix Radensky
Sent: Wednesday, December 16, 2009 2:56 AM
To: linuxppc-...@ozlabs.org; Aggrwal
From: Wood Scott-B07421
Sent: Friday, November 20, 2009 11:09 PM
Cache-sram does not have any device tree entry since it is not a
hardware as such. Putting it under chosen can be another option.
I think, Scott (cc'ed) was of the opinion that since 32b
base address
support is
From: Gala Kumar-B11780
Sent: Thursday, November 19, 2009 7:51 PM
+ * Cache SRAM handling for QorIQ platform
should say PQ3 some QorIQ platforms
Ok
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default 0xfff0
+
I really don't like
From: Jeff Garzik [mailto:j...@garzik.org]
Sent: Tuesday, November 17, 2009 1:12 PM
In this case msi is supposed to be passed via insmod and not via
kernel cmdline. If the driver is built-in the kernel, then force
sata_sil24_msi = 1 in the driver to enable it.
First, the original
From: Grant Grundler [mailto:grund...@google.com]
Sent: Monday, November 16, 2009 11:08 PM
+static int sata_sil24_msi; /* Disable MSI */
+module_param_named(msi, sata_sil24_msi, bool, S_IRUGO);
+MODULE_PARM_DESC(msi, Enable MSI (Default: false));
Vivek,
Do we even still need the
Wolfgang Denk Sent: Wednesday, October 21, 2009 11:20 PM
* How to enable it from a low level driver
* How to set its size
...
+The size of the above cache SRAM memory window is passed via the
+kernel command line as cache-sram-size=
Would it not make more sense to configure this
From: Gala Kumar-B11780
Sent: Friday, September 25, 2009 12:08 AM
+ mbar(1);
why isn't eieio() sufficient here?
When I initially added / tested cache SRAM for P2020RDB, its RM talked
about using mbar() though mbar(1) is identical to eieio() opcode-wise.
Also as cache-sram works only for
Hello Markus,
Apparently this
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;
h=5622f295b53fb60dbf9bed3e2c89d182490a8b7f breaks the powerpc build as
under when built from
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=summary
with latest commit
13 matches
Mail list logo
