Hello Scott,
Scott Wood wrote:
> On Wed, Jan 09, 2008 at 01:58:49PM +0100, Heiko Schocher wrote:
>> @@ -1312,6 +1312,9 @@ static int __devinit fs_enet_probe(struct of_device
>> *ofdev,
>> ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
>> ndev->dev_addr[3], ndev->
Hello Scott,
Heiko Schocher wrote:
> Hello Scott,
[...]
> Will resend this fixed patch.
Here it is:
[POWERPC] Fix Ethernet over SCC on a CPM2,
also Fix crash in fs_enet_rx_napi()
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/driv
On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > It would be much better if the kernel would 'just work'. The ideal way
> > of achieving that is for the firmware to be fixed -- but that's been
> > promised for a long time now, and we just don't believe you
On Wed, 9 Jan 2008, Geoff Levand wrote:
> --- /dev/null
> +++ b/drivers/ps3/ps3-lpm.c
> + * @node_id: The node id of a BE prosessor whos performance monitor this
whose
With kind regards,
Geert Uytter
On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote:
> ASOC v2 is sitting on a Wolfson server out of tree. I have been using
> it for several months without problem. The pace of it being merged
> could probably be sped up.
I think we are probably looking at submission in the next 8 - 10 weeks.
Cur
On Wed, Jan 09, Grant Likely wrote:
> From: Olaf Hering <[EMAIL PROTECTED]>
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties.
On Thu, Jan 10, Paul Mackerras wrote:
> Olaf Hering writes:
>
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
> > else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
> > of_work
What is the review status of this series, should I post it again?
On 12/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Since copying i2c-mpc.c to maintain support for the ppc architecture seems to
> be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to
> support both the ppc an
So, like, the other day David Gibson mumbled:
> > The doubly-linked list is intended to make it easier to construct search
> > path lists one-at-a-time from arguments in the proper order, without
> > needing to reverse the list at the end.
>
> We've already got that problem with a bunch of the lis
So, like, the other day Scott Wood mumbled:
> This allows /include/s to work when in non-default states,
> such as PROPNODECHAR.
>
> We may want to use state stacks to get rid of BEGIN_DEFAULT() altogether...
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Hmmm.. With this applied, I get the
On Thu, 10 Jan 2008 17:50:49 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote:
> > On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> > > David Gibson wrote:
> > > > Hrm... I'd say this is not something which has a fi
On 1/10/08, Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> Hi Grant,
>
> On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely <[EMAIL PROTECTED]> wrote:
> >
> > +mpc52xx_map_common_devices(void)
> > {
>
> > + /* Clock Distribution Module, used by PSC clock setting function */
> > + np = of_find_
Folks,
I have tagged DTC v1.1.0-rc1 and pushed it out.
Please verify that this is going to be a viable 1.1 release!
Consider this the last call for features and first call
for bug fixes for the 1.1 release. :-)
Thanks,
jdl
___
Linuxppc-dev mailing lis
Acked-by: Dragos Carp <[EMAIL PROTECTED]>
On Mon, 2008-01-07 at 12:07 -0700, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> It is dangerous for an mpc52xx device driver to modify the port_config
> register. If the driver is probed incorrectly, it will change the pin
> IO confi
On 1/9/08, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> As much as I despise having to work around firmware bugs, it looks
> indeed like this one has been broken for way too long to the point where
> users are being hurt, distros are being hurt, and telling people to
> whack things in nvramr
Liam Girdwood wrote:
> I think we are probably looking at submission in the next 8 - 10 weeks.
> Currently most of the core code is complete, however some platforms and
> codecs still need porting.
With that in mind, can I get some kind of consensus from the PPC side as to
whether this ASoC V1 d
On Thu, Jan 10, 2008 at 08:31:18AM -0700, Grant Likely wrote:
> 1. Apply a device tree fixup to change device_type from "chrp" to
> "efika" (the current solution)
> 2. Modify chrp_probe() to check specifically for the Efika when probing
> 3. Modify the link order so that Efika is probed before CHR
On Sat, Dec 29, 2007 at 06:13:08PM +0100, Joakim Tjernlund wrote:
> > -Original Message-
> > From:
> > [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > abs.org] On Behalf Of Vitaly Bordug
> > Sent: den 6 december 2007 23:51
> > To: Paul Mackerras
> > Cc: [EMAIL PROTECTED]; linuxppc-dev
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Liam Girdwood wrote:
>
> > I think we are probably looking at submission in the next 8 - 10 weeks.
> > Currently most of the core code is complete, however some platforms and
> > codecs still need porting.
>
> With that in mind, can I get some kin
Paul,
Can you please pull this tree to get an Efika boot fix into 2.6.24.
Without this fix, Ethernet on the Efika will not work without the user
jumping through all kinds of hoops.
Thanks,
g.
The following changes since commit fd0b45dfd1858c6b49d06355a460bcf36d654c06:
Linus Torvalds (1):
Grant Likely wrote:
> The driver doesn't need to be 100% correct. Drivers are easy to
> change if they aren't quite right. There are no long term
> consequences.
>
> However, the device tree issues must be addressed before it is merged
> and deployed. Otherwise we end up having to support poor
On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote:
> On 09/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> >
> > > Heh. That's the elbow-grease of this thing. The easy part is to get
> > > the core function working
On 10/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote:
> > On 09/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> > >
> > > > Heh. That's the elbow-grease of t
On 1/7/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Update the MPC8610 HPCD files to support the audio driver. Update
> booting-without-of.txt with information on the SSI device.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
>
> Updated based on comments from mailing lists. Split the pat
On Thu, 10 Jan 2008 09:14:26 -0500, Jon Smirl wrote:
> What is the review status of this series, should I post it again?
No please! /o\
I'll go through your numerous past posts now, stay tuned.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-de
David Gibson wrote:
> On Sun, Jan 06, 2008 at 04:55:09PM -0600, Scott Wood wrote:
>> On Fri, Jan 04, 2008 at 03:30:33PM +1100, David Gibson wrote:
>>> This is unequivocally wrong. boot_info should have information about
>>> the contents of the blob, not state information like the error.
>> "This b
Kumar Gala wrote:
>
> On Jan 9, 2008, at 1:52 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> I'm thinking I'll add something like:
>>>if (addr < total_lowmem)
>>>reserve_bootmem(lmb.reserved.region[i].base,
>>>lmb_s
Heiko Schocher wrote:
> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c
> index f2a4d39..f432a18 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev
On Wed, Jan 09, 2008 at 05:07:23PM -0600, Rune Torgersen wrote:
> > From: Scott Wood [mailto:[EMAIL PROTECTED]
> > Rune Torgersen wrote:
> > > Did that, now we get e checkstop resert. Time to hook up the
> > > BDI-2000 Is there a way to have the bootwrapper use the u-boot
> > > serial for a wh
What exactly does this function do?
/* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
* do this for us
*/
On the taco, with the 440EP, it doesn't seem to make any difference if I
call this or not. Since I am using u-boot, is it not needed?
Cheers,
Sean
_
On Thu, 10 Jan 2008 13:38:12 -0500
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> What exactly does this function do?
>
> /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
> * do this for us
> */
>
> On the taco, with the 440EP, it doesn't seem to make any difference if I
> ca
Hello Scott,
Scott Wood wrote:
> Heiko Schocher wrote:
>> diff --git a/drivers/net/fs_enet/fs_enet-main.c
>> b/drivers/net/fs_enet/fs_enet-main.c
>> index f2a4d39..f432a18 100644
>> --- a/drivers/net/fs_enet/fs_enet-main.c
>> +++ b/drivers/net/fs_enet/fs_enet-main.c
>> @@ -810,6 +810,10 @@ static
> From: Scott Wood
>
> The tree looks OK. The checkstop may be from erratum SIU18;
> I had this issue on the ep8248e board.
>
> Try clearing BCR[PLDP].
Not sure what was wrong. We took a step back, and redid some stuff, and
now we have serial output from the boot-wrapper.
THe checkstop came fro
Rune Torgersen wrote:
> Not sure what was wrong. We took a step back, and redid some stuff, and
> now we have serial output from the boot-wrapper.
> THe checkstop came from the wrapper grying to access the bcsr and doing
> the chip select fixup. We don';t have a bcsr on our board, and the cs
> layo
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > The driver doesn't need to be 100% correct. Drivers are easy to
> > change if they aren't quite right. There are no long term
> > consequences.
> >
> > However, the device tree issues must be addressed before it is mer
Jon Smirl wrote:
> Isn't your codec is i2c controlled? Where does the main node for the
> code live, i2c bus or ssi bus? What does the link between the buses
> look like for pointing to the codec entry?
The CS4270 driver is "old style", which means it probes all possible I2C
addresses until it f
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Isn't your codec is i2c controlled? Where does the main node for the
> > code live, i2c bus or ssi bus? What does the link between the buses
> > look like for pointing to the codec entry?
>
> The CS4270 driver is "old style"
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > Isn't your codec is i2c controlled? Where does the main node for the
> > code live, i2c bus or ssi bus? What does the link between the buses
> > look like for pointing to the codec entry?
>
> The CS4270 driver is "old style"
Jon Smirl wrote:
> So the codec is controlled from the i2c bus and SSI is used to supply
> it with data. Based on what has been said on this list, the device
> tree node for the codec should be on the i2c bus with a link from the
> ssi bus to it.
I'm working on that now. I'll have a new patch wi
Grant Likely wrote:
> Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or
> [EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a
> sound device enough).
Well, SSI stands for "Synchronous Serial Interface" (although it's capable of
asynchronous c
Linas Vepstas wrote:
> On 10/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote:
>
>>On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote:
>>
>>>On 09/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote:
>>>
On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
>He
These patches add ALSA SoC device drivers for the Freescale MPC8610 SoC
and the MPC8610-HPCD reference board.
The first patch updates some files in arch/powerpc and booting-without-of.txt.
The second patch adds the new audio driver files to sound/soc.
Both must be applied in order to avoid a bu
Update the MPC8610 HPCD files to support the audio driver. Update
booting-without-of.txt with information on the SSI device.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Updated the DTS based comments on the list.
This patch applies on top of
git://git.kernel.org/pub/scm/linux/kernel/git/p
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Update the MPC8610 HPCD files to support the audio driver. Update
> booting-without-of.txt with information on the SSI device.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
> b/arch/po
New version with recommended changes. Device types removed. FPGA moved to
correct bus.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-10 13:04:49.0 -0500
@@ -0,0 +1,230 @@
+/*
+ * De
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Add the ASoC drivers for the Freescale MPC8610 SoC and the MPC8610 HPCD
> reference board.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
This is a very big patch, but I'm going to keep my nose out of the
ALSA stuff. I've got no problem again
David Gibson wrote:
>
> Fold all this into cuboot-warp.c, unless you actually anticipate
> adding another wrapper for another firmware which will also use the
> functions in warp.c.
>
>
Done.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/
Grant Likely wrote:
> Does the driver access the DMA and GUTS registers directly? If so,
> what do you have to protect against race conditions of other drivers
> accessing them also.
I don't have any more protection than any other driver that accesses SOC
registers directly. Last I heard, Zhan
On 1/10/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Does the driver access the DMA and GUTS registers directly? If so,
> > what do you have to protect against race conditions of other drivers
> > accessing them also.
>
> I don't have any more protection than any other dri
Grant Likely wrote:
>> As for the GUTS driver, well, I just program a few registers at startup, and
>> I
>> don't think any other driver touches them.
>
> Okay; at some point in the future they'll need to be accessed from a
> common routine too.
I'll add that to my to-do list.
--
Timur Tabi
L
From: Takashi Yamamoto <[EMAIL PROTECTED]>
Add PS3 logical performance monitor (lpm) device driver.
The PS3's LV1 hypervisor provides a Logical Performance Monitor that
abstracts the Cell processor's performance monitor features for use
by guest operating systems.
Signed-off-by: Takashi Yamamot
On Thu, 10 Jan 2008 08:01:09 -0700 "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> On 1/10/08, Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> > Hi Grant,
> >
> > On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely <[EMAIL PROTECTED]> wrote:
> > >
> > > +mpc52xx_map_common_devices(void)
> > > {
> >
> > >
Grant Likely wrote:
>> +[EMAIL PROTECTED] {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "fsl,mpc8610-dma", "fsl,eloplus-dma";
>> +cell-index = <0>;
>> +
> From: Scott Wood [
> Rune Torgersen wrote:
> > Not sure what was wrong. We took a step back, and redid
> some stuff, and
> > now we have serial output from the boot-wrapper.
> > THe checkstop came from the wrapper grying to access the
> bcsr and doing
> > the chip select fixup. We don';t have a
On Thu, Jan 10, 2008 at 05:12:16PM -0600, Timur Tabi wrote:
> Grant Likely wrote:
>
> > Does the driver access the DMA and GUTS registers directly? If so,
> > what do you have to protect against race conditions of other drivers
> > accessing them also.
>
> I don't have any more protection than a
On Thu, Jan 10, 2008 at 06:59:03PM -0500, Sean MacLennan wrote:
> New version with recommended changes. Device types removed. FPGA
> moved to correct bus.
[snip]
> + [EMAIL PROTECTED],0 {
> + compatible = "pika,fpga";
> +
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on
Michael Neuling wrote:
> @@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
> local_irq_disable();
> idle_task_exit();
> xics_teardown_cpu(0);
> + unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow()));
^
Should that not be
Mike Strosaker wrote:
>
> At the risk of repeating what others have already said, the PHYP-assistance
> method provides some advantages that the kexec method cannot:
> - Availability of the system for production use before the dump data is
> collected. As was mentioned before, some production
> > @@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
> > local_irq_disable();
> > idle_task_exit();
> > xics_teardown_cpu(0);
> > + unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow()));
> ^
> Should that not be hard_smp_process
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on
This patch extends the Ebony and Walnut platform code to instantiate
the existing ds1742 RTC class driver for the DS1743 RTC/NVRAM chip
found on both those boards. The patch uses a helper function to scan
the device tree and instantiate the appropriate platform_device based
on it, so it should be
This patch adds an fdt_set_name() function to libfdt, mirroring
fdt_get_name(). This is a r/w function which alters the name of a
given device tree node.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/libfdt/libfdt.h
===
This probe_mutex conforms to the new struct mutex type.
This patch converts it from the old semaphore to the new struct mutex.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/ps3/ps3-vuart.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: li
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [
David Gibson wrote:
> On Thu, Jan 10, 2008 at 06:59:03PM -0500, Sean MacLennan wrote:
>
>> New version with recommended changes. Device types removed. FPGA
>> moved to correct bus.
>>
>
> [snip]
>
>> +[EMAIL PROTECTED],0 {
>> +
On Fri, Jan 11, 2008 at 12:21:20AM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > On Thu, Jan 10, 2008 at 06:59:03PM -0500, Sean MacLennan wrote:
> >
> >> New version with recommended changes. Device types removed. FPGA
> >> moved to correct bus.
> >>
> >
> > [snip]
> >
> >> +
On Thursday 10 January 2008, Josh Boyer wrote:
> On Thu, 10 Jan 2008 13:38:12 -0500
>
> Sean MacLennan <[EMAIL PROTECTED]> wrote:
> > What exactly does this function do?
> >
> > /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't
> > * do this for us
> > */
> >
> > On the taco, w
David Gibson wrote:
> Or possibly what you actually want is:
> [EMAIL PROTECTED],0 {
> reg = <2 0 2200>;
> ...
> };
>
That is what I want. I was missing a call to
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc"); (see updated patch3/5 to follow.
Signed-off-by: Se
Update based on fixes to warp.dts.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..cd83c4f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52
Stefan Roese wrote:
>> There are firmwares that do not reset the EMAC and MAL before passing
>> control to the client program (Linux in our case). This can cause
>> weird things to happen, like spurious interrupts or DMAs from the
>> hardware overwriting kernel memory. So we quiesce the hardware
No comments? I really thought I would get raked over the coals for this one.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson <[EMAIL PROTECTED]> wrote:
>
> +++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.0
> +1100
> +static __initdata struct {
> + const char *compatible;
If you make this an array, then the string will become __initdata as we
On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
> I have split up the patches slightly differently based on Josh's comments.
>
> The first patch is basically the platform/44x files.
>
> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
> No comments? I really thoug
Stephen Rothwell wrote:
> On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
>> I have split up the patches slightly differently based on Josh's comments.
>>
>> The first patch is basically the platform/44x files.
>>
>> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]
75 matches
Mail list logo
