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
Linuxppc-dev@lists.oz
> 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 us
> 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
> > drivers/net/wirel
> 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
> 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,
> >
>
> -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
> 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
> 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 o
> 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 sti
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
>
> Would it not make more sense to configure this property
> 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 onl
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 ebc79c4f8da0f
13 matches
Mail list logo
