Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opposition. Furthermore, the economic
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that opposition.
That's right, and I fully agree with that change. To me, going back
to allowing spin locks is a regression because it adds a new source of
scheduling latency.
I think that the change was not about reducing scheduling
latency. Rather, the idea was simply to allow mdio bus drivers that
sleep.
On Tue, Jun 15, 2010 at 06:08:20PM +0200, Richard Cochran wrote:
+static inline void skb_tx_timetamp(struct phy_device *phy, struct sk_buff
*skb)
+{
+ union skb_shared_tx *shtx = skb_tx(skb);
+
+ if (shtx-hardware phy phy-drv-txtstamp)
+ phy-drv-txtstamp(phy, skb);
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good arguments to support
that
On Tue, Jun 15, 2010 at 11:20:41AM -0600, Grant Likely wrote:
Is this header file used by anything other than gianfar_ptp.c? If
not, then roll the two files together.
I anticipate that it might be necessary to share the header's contents
with gianfar.c one day.
Use dash ('-') not
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will
not happen for several reasons. The opposition to the idea is
widespread and deeply held, and there are good
On Tue, Jun 15, 2010 at 12:41:56PM -0600, Grant Likely wrote:
Nitpick. We use all lower case names for structures in Linux.
Yes, I know, but in this case an exception makes sense.
I prefer to use the exact same register mnemonics as in the hardware
documentation, whenever possible. That way,
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That will not
happen for several reasons. The opposition to the idea is widespread
and deeply held, and there are good arguments to support that
opposition. Furthermore, the economic conditions necessary for the
In message: 4c187013.5000...@firmworks.com
Mitch Bradley w...@firmworks.com writes:
: Mike Rapoport wrote:
: Mitch Bradley wrote:
: Mike Rapoport wrote:
: Mitch Bradley wrote:
:
: The second topic is the hypothetical use of OFW as a HAL. That will
: not happen for several
Hi,
Attached is a patch to fix large physical address support for the e500v2
core. When 4GB addresses are used, the MAS7 register needs to be valid
for tlbsx instruction usage.
Please review and apply.
Micha
diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h
Hi Timur,
On Fri, 4 Jun 2010 10:46:28 -0500
Timur Tabi ti...@freescale.com wrote:
On Tue, Jun 1, 2010 at 4:38 AM, Anatolij Gustschin ag...@denx.de wrote:
Could you please test these patches on MPC8610 HPCD? I think these
changes won't break that platform. The patches apply cleanly on
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread and deeply held, and
-Original Message-
From:
linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of
Micha
Nelissen
Sent: Wednesday, June 16, 2010 12:29 PM
To: linuxppc-dev@lists.ozlabs.org
Subject:
On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
Won't this break things for existing DP83640 users?
Nope, the driver was only added five patches ago, and it only offers
the timestamping stuff. The standard PHY functions just call the
generic functions, so the PHY works fine even
When SPARSE_IRQ is set, irq_to_desc() can
return NULL. While the code here has a
check for NULL, it's not really correct.
Fix it by separating the check for it.
This fixes CPU hot unplug for me.
Reported-by: Alastair Bridgewater alastair.bridgewa...@gmail.com
Cc: sta...@kernel.org [2.6.32+]
Mitch Bradley wrote:
I'm also objecting the step (b) and, fortunately, it's not yet the
status quo.
Current U-Boot/kernel implementations I've encountered still do not
have OS calls to resident HW access routines. But if such calls would
be allowed, my impression is that SoC vendors would
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
Mike Rapoport wrote:
Mitch Bradley wrote:
The second topic is the hypothetical use of OFW as a HAL. That
will not happen for several reasons. The opposition to the idea
is widespread
-Original Message-
From: Micha Nelissen [mailto:mi...@neli.hopto.org]
Sent: Wednesday, June 16, 2010 2:55 PM
To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
Aggrwal Poonam-B10812 wrote:
Attached is
Aggrwal Poonam-B10812 wrote:
Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence
possibly u-boot has to made aware of large physical address space.
Please correct me if I am wrong.
Yes, I can
Mike Rapoport wrote:
Which of course raises the question: How does the Linux community view
such SoC vendors? Are they embraced and eagerly supported, or (either
openly or secretly) viewed as a nuisance? How does the widespread
objection to something that such vendors would make
-Original Message-
From: Micha Nelissen [mailto:mi...@neli.hopto.org]
Sent: Wednesday, June 16, 2010 5:04 PM
To: Aggrwal Poonam-B10812
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
Aggrwal Poonam-B10812 wrote:
Not sure
On 16 Jun 2010, at 12:41, Jamie Lokier wrote:
Mike Rapoport wrote:
Which of course raises the question: How does the Linux community view
such SoC vendors? Are they embraced and eagerly supported, or (either
openly or secretly) viewed as a nuisance? How does the widespread
objection to
On Tue, Jun 15, 2010 at 11:00:10AM -0600, Grant Likely wrote:
Question from an ignorant reviewer: Why a new interface instead of
working with the existing high resolution timers infrastructure?
Short answer: Timers are only one part of the PTP API. If you offer
the PTP clock as a Linux clock
On Wed, Jun 16, 2010 at 4:24 AM, Micha Nelissen mi...@neli.hopto.org wrote:
IMHO:
1) Linux should not be dependent on U-boot or any other bootloader, or at
least as possible
2) U-boot cannot (and does not want to) know whether Linux is going to use
large physical addresses.
To quote The
Fix smatch warning: constant 0x8000 is so big it is unsigned long
Signed-off-by: Denis Kirjanov dkirja...@kernel.org
---
arch/powerpc/include/asm/abs_addr.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/abs_addr.h
On Wed, 16 Jun 2010, Mike Rapoport wrote:
Mitch Bradley wrote:
One counterargument, of course, is that there is a better way. But it is
only better under a cost function that values things differently than the
vendors value them. Were that not so, the vendors would gladly use the
better
Timur Tabi wrote:
I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing.
Why?
That's
just the way it works.
What a great design philosophy!
Linux patches that repeat what U-Boot already
does just so that you
On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote:
Hi,
Attached is a patch to fix large physical address support for the e500v2
core. When 4GB addresses are used, the MAS7 register needs to be valid for
tlbsx instruction usage.
Please review and apply.
Micha
diff -u -ru
On Wed, Jun 16, 2010 at 4:05 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote:
Won't this break things for existing DP83640 users?
Nope, the driver was only added five patches ago, and it only offers
the timestamping stuff. The
Kumar Gala wrote:
+BEGIN_MMU_FTR_SECTION
+ mfspr r2,SPRN_HID0
+ ori r2,r2,hid0_en_mas7_upd...@l
+ mtspr SPRN_HID0, r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
+#endif
If you want to do this, do it in:
arch/powerpc/kernel/cpu_setup_fsl_booke.S
Do you mean like
I don't know if this is a right fix for the problem
since of_get_property can return NULL.
Since iseries_device_information is used only for informational purpose,
we can skip this function without valid HvSubBusNumber number.
Signed-off-by: Denis Kirjanov dkirja...@kernel.org
---
Micha Nelissen wrote:
Do you mean like attached? I had to change the order of the '_GLOBAL'
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
e500v2 only.
Hmm, maybe need to use r0 or r3 instead of r2?
Micha
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
Anatolij Gustschin wrote:
Any chance this could be done soon? I'd like to include the MPC5121e DIU
support in 2.6.36 since it is currently broken in mainline and the patches
provide the fix.
Ok, I'll try it today.
___
Linuxppc-dev mailing list
On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi ti...@freescale.com wrote:
Anatolij Gustschin wrote:
Any chance this could be done soon? I'd like to include the
MPC5121e DIU support in 2.6.36 since it is currently broken in
mainline and the patches provide the fix.
Ok, I'll try it
Anatolij Gustschin wrote:
On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi ti...@freescale.com wrote:
Anatolij Gustschin wrote:
Any chance this could be done soon? I'd like to include the
MPC5121e DIU support in 2.6.36 since it is currently broken in
mainline and the patches provide the fix.
Can you email me, perhaps in one tarball, all of the patches I need?
Or push a git tree :)
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred c.alf...@internode.on.net wrote:
I am trying to port a DSA (Distributed Switch Architecture) driver for
the Micrel KS8995M managed switch connected to a MPC5200. There is an
SPI interface and MII interface managed by the DSA driver.
I can't
On Tue, Jun 15, 2010 at 4:19 PM, Dmitry Eremin-Solenikov
dbarysh...@gmail.com wrote:
Dmitry Eremin-Solenikov wrote:
According to my schematics, on Lite5200 board ethernet phy uses address
0 (all ADDR lines are pulled down). With this change I can talk to
onboard phy (LXT971) and correctly use
Am 19.05.10 18:02 schrieb(en) Grant Likely:
That's http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog, isn't it?
Hmmm, didn't find it there... :-/
Ugh... Stupid typing too fast. I meant to say, I *don't* think ben
has asked me to take...
Well this leaves a bit of a mess. I'll make sure
On Wed, 16 Jun 2010 11:26:39 -0500
Timur Tabi ti...@freescale.com wrote:
Anatolij Gustschin wrote:
On Wed, 16 Jun 2010 10:42:28 -0500
Timur Tabi ti...@freescale.com wrote:
Anatolij Gustschin wrote:
Any chance this could be done soon? I'd like to include the
MPC5121e DIU support in
On Wed, May 26, 2010 at 11:04 AM, Sergey Temerkhanov
temerkha...@cifronik.ru wrote:
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v2-v3:
-Fixed whitespaces for SAVE_FPR/REST_FPR.
-Changed description of MSR_AP bit.
-Removed the stub for APU
-Original Message-
From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely
Sent: Wednesday, June 16, 2010 1:02 PM
To: Sergey Temerkhanov
Cc:
From: Grant Likely grant.lik...@secretlab.ca
Date: Fri, 04 Jun 2010 15:11:38 -0600
Now that the device tree node pointer has been moved out of struct
of_device and into the common struct device, there isn't anything
unique about of_device anymore. In fact, there isn't much need
for a
On 06/16/2010 07:39 AM, Nicolas Pitre wrote:
The cost function _is_ different for the Linux community and decision
makers at chip vendor companies. I know that for having worked long
enough at a prominent chip vendor already.
Those vendors want to ship a product and be first on the market
From: Anton Vorontsov cbouatmai...@gmail.com
Date: Fri, 11 Jun 2010 16:20:23 +0400
On Fri, Jun 11, 2010 at 01:49:05PM +0200, Manfred Rudigier wrote:
Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if
the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work
Grant Likely wrote:
On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
c.alf...@internode.on.net wrote:
I am trying to port a DSA (Distributed Switch Architecture) driver
for the Micrel KS8995M managed switch connected to a MPC5200. There
is an SPI interface and MII interface managed by the DSA
On Wed, Jun 16, 2010 at 4:06 PM, Chris Alfred c.alf...@internode.on.net wrote:
Grant Likely wrote:
On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred
c.alf...@internode.on.net wrote:
I am trying to port a DSA (Distributed Switch Architecture) driver
for the Micrel KS8995M managed switch connected
dsa_of_init is successfully called; but dsa_of_probe is not called.
That means the node is not being used to register an of_device. I
need some more information to suggest how best to fix this.
What SoC are you using?
What file in arch/powerpc/platforms/* is used to setup your machine?
We
On Wed, Jun 16, 2010 at 4:48 PM, Chris Alfred c.alf...@internode.on.net wrote:
dsa_of_init is successfully called; but dsa_of_probe is not called.
That means the node is not being used to register an of_device. I
need some more information to suggest how best to fix this.
What SoC are you
From: Richard Cochran richardcoch...@gmail.com
Date: Tue, 15 Jun 2010 18:08:20 +0200
+static inline void skb_tx_timetamp(struct phy_device *phy, struct sk_buff
*skb)
+{
+ union skb_shared_tx *shtx = skb_tx(skb);
+
+ if (shtx-hardware phy phy-drv-txtstamp)
+
From: Jay Vosburgh fu...@us.ibm.com
Date: Tue, 15 Jun 2010 09:45:47 -0700
Jan-Bernd Themann ossth...@de.ibm.com wrote:
In the eHEA poll function an rmb() is required. Without that some packets
on the receive queue are not seen and thus delayed until the next interrupt
is handled for the same
From: Jan-Bernd Themann ossth...@de.ibm.com
Date: Tue, 15 Jun 2010 17:35:42 +0200
Port reset operations and memory add/remove operations need to
be serialized to avoid a kernel deadlock. The deadlock is caused
by calling the napi_disable() function twice.
Therefore we have to employ the
From: Anton Vorontsov avoront...@mvista.com
Date: Sat, 12 Jun 2010 00:51:03 +0400
Issuing the following command on host:
$ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
oops like this:
...
Dumped buffer
In message 20100616004839.ga18...@linux.vnet.ibm.com you wrote:
crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.
Untested, probably does
dsa_of_init is successfully called; but dsa_of_probe is not
called.
That means the node is not being used to register an of_device. I
need some more information to suggest how best to fix this.
What SoC are you using?
What file in arch/powerpc/platforms/* is used to setup your
machine?
We have only done a text search/replace lite5200 to jkc5200.
I meant to write:
We copied lite5200.c to jkc5200n8.c, and have only done a text
search/replace lite5200 to jkc5200n8
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Thu, Jun 17, 2010 at 11:56:53AM +1000, Michael Neuling wrote:
In message 20100616004839.ga18...@linux.vnet.ibm.com you wrote:
crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the
58 matches
Mail list logo
