[PATCH] powerpc: add adt7461 thermal monitor support to applicable boards
Add thermal monitor support to following boards:
P1022DS, MPC8536DS, P2041RDB, P3041DS, P4080DS, P5020DS, P5040DS
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/boot/dts/mpc8536ds.dtsi |4
arch/powerpc/boot/dts/p1022ds.dtsi |4
arch/powerpc/boot/dts/p2041rdb.dts |4
arch/powerpc/boot/dts/p3041ds.dts|4
arch/powerpc/boot/dts/p4080ds.dts|4
arch/powerpc/boot/dts/p5020ds.dts|4
arch/powerpc/boot/dts/p5040ds.dts|4
7 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi
b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index d304a2d..7c3dde8 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -132,6 +132,10 @@
reg = <0x68>;
interrupts = <0 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
spi@7000 {
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi
b/arch/powerpc/boot/dts/p1022ds.dtsi
index c3344b0..873da35 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -149,6 +149,10 @@
compatible = "dallas,ds1339";
reg = <0x68>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
spi@7000 {
diff --git a/arch/powerpc/boot/dts/p2041rdb.dts
b/arch/powerpc/boot/dts/p2041rdb.dts
index baab034..d97ad74 100644
--- a/arch/powerpc/boot/dts/p2041rdb.dts
+++ b/arch/powerpc/boot/dts/p2041rdb.dts
@@ -94,6 +94,10 @@
compatible = "pericom,pt7c4338";
reg = <0x68>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
i2c@118100 {
diff --git a/arch/powerpc/boot/dts/p3041ds.dts
b/arch/powerpc/boot/dts/p3041ds.dts
index 6cdcadc..2fed3bc 100644
--- a/arch/powerpc/boot/dts/p3041ds.dts
+++ b/arch/powerpc/boot/dts/p3041ds.dts
@@ -98,6 +98,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/p4080ds.dts
b/arch/powerpc/boot/dts/p4080ds.dts
index 3e20460..1cf6148 100644
--- a/arch/powerpc/boot/dts/p4080ds.dts
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -96,6 +96,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
usb0: usb@21 {
diff --git a/arch/powerpc/boot/dts/p5020ds.dts
b/arch/powerpc/boot/dts/p5020ds.dts
index 27c07ed..2869fea 100644
--- a/arch/powerpc/boot/dts/p5020ds.dts
+++ b/arch/powerpc/boot/dts/p5020ds.dts
@@ -98,6 +98,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/p5040ds.dts
b/arch/powerpc/boot/dts/p5040ds.dts
index d86bf2e..8165c93 100644
--- a/arch/powerpc/boot/dts/p5040ds.dts
+++ b/arch/powerpc/boot/dts/p5040ds.dts
@@ -146,6 +146,10 @@
label = "NAND Writable User area";
reg = <0x1f00 0x0100>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
board-control@3,0 {
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Make sure IPI handlers see data written by IPI senders
On Sat, Aug 25, 2012 at 03:04:23PM +1000, Paul Mackerras wrote:
> We have been observing hangs, both in KVM guest vcpus and more
> generally, where a process that is woken doesn't properly wake up and
> continue to run, but instead sticks in TASK_WAKING state. This
> happens because the update of rq->wake_list in ttwu_queue_remote()
> is not ordered with the update of ipi_message in
> smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
> scheduler_ipi() is not ordered with the reading of ipi_message in
> smp_ipi_demux(). Thus it is possible for the IPI receiver not to see
> the updated rq->wake_list and therefore conclude that there is nothing
> for it to do.
>
> In order to make sure that anything done before calling
> smp_send_reschedule() is ordered before anything done in the resulting
> call to scheduler_ipi(), this adds barriers in
> smp_muxed_message_pass() and smp_ipi_demux(). The barrier in
> smp_muxed_message_pass() is a full barrier to ensure that there is a
> full ordering between the smp_send_reschedule() caller and
> scheduler_ipi(). In smp_ipi_demux(), we use xchg() rather than
> xchg_local() because xchg() includes release and acquire barriers.
> Using xchg() rather than xchg_local() makes sense given that
> ipi_message is not just accessed locally.
>
> These changes made no measurable difference to the speed of IPIs as
> measured using a simple ping-pong latency test across two CPUs on
> different cores of a POWER7 machine.
>
> The analysis of the reason why processes were not waking up properly
> is due to Milton Miller.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Milton Miller
> Signed-off-by: Paul Mackerras
Reviewed-by: Paul E. McKenney
> ---
> arch/powerpc/kernel/smp.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index e292ff2..ca1040a 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -197,8 +197,15 @@ void smp_muxed_ipi_message_pass(int cpu, int msg)
> struct cpu_messages *info = &per_cpu(ipi_message, cpu);
> char *message = (char *)&info->messages;
>
> + /*
> + * Order previous accesses before accesses in the IPI handler.
> + */
> + smp_mb();
> message[msg] = 1;
> - mb();
> + /*
> + * Order setting of message before IPI.
> + */
> + smp_wmb();
> smp_ops->cause_ipi(cpu, info->data);
> }
>
> @@ -210,7 +217,7 @@ irqreturn_t smp_ipi_demux(void)
> mb(); /* order any irq clear */
>
> do {
> - all = xchg_local(&info->messages, 0);
> + all = xchg(&info->messages, 0);
>
> #ifdef __BIG_ENDIAN
> if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNCTION)))
> --
> 1.7.10.rc3.219.g53414
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] rapidio/tsi721: modify mport name assignment
On Friday, August 24, 2012 5:02 PM Andrew Morton > > On Tue, 21 Aug 2012 10:23:54 -0400 > Alexandre Bounine wrote: > >> Modify mport device name assignment to provide clear reference to devices >> in systems with multiple Tsi721 bridges. >> >> This patch is applicable to kernel versions starting from v3.2. > > This seems to imply that you think the patch should be backported into > earlier kernels. But no reason for doing this was provided. We cannot prevent users of earlier versions from using more than one Tsi721 device in their systems. In that case the old name form will not provide definitive reference to a particular mport. Please, see comment below. > > > --- a/drivers/rapidio/devices/tsi721.c > > +++ b/drivers/rapidio/devices/tsi721.c > > @@ -2165,7 +2165,8 @@ static int __devinit tsi721_setup_mport(struct > tsi721_device *priv) > > rio_init_dbell_res(&mport->riores[RIO_DOORBELL_RESOURCE], 0, > 0x); > > rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 3); > > rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 3); > > - strcpy(mport->name, "Tsi721 mport"); > > + snprintf(mport->name, RIO_MAX_MPORT_NAME, "%s(%s)", > > +dev_driver_string(&pdev->dev), dev_name(&pdev->dev)); > > And it's a non-back-compatible change to a userspace-visible interface! > As such we'd need extraordinary justification to merge it into > *future* kernels, let alone backport it. An mport device do not provide a userspace-visible interface at this point. This name is used internally in RapidIO subsystem for resource tracking and debugging. For Tsi721 as a PCIe peripheral, having the mport name that may be easily associated with its PCIe base helps with tracking of assigned PCIe resources. This option looks to me better than adding simple indexing component into existing name format, especially for systems that use add-on cards with PCIe-to-SRIO bridges. > > Please, do provide much better changelogging than this. Modify RapidIO mport device name assignment to include device name of PCIe side of Tsi721 bridge. The new name format is intended to provide definitive reference between RapidIO and PCIe sides of the bridge in systems with multiple Tsi721 bridges. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] rapidio: apply RX/TX enable to active switch ports only
On Friday, August 24, 2012 5:04 PM Andrew Morton > > On Tue, 21 Aug 2012 10:23:55 -0400 > Alexandre Bounine wrote: > >> Modify RIO enumeration to apply RX/TX enable operations only to >> active switch ports. This will leave inactive ports in condition consistent >> with their state. > > It's unclear (to me) what the effects of this are. Does it fix some > user-visible malfunction? Or is it just some nice-to-have thing? Or > what? > This patch was intended to keep inactive switch ports with inbound and outbound packet transfers disabled to block unexpected packets during hot insertion event. While it does not fix any visible malfunction it was intended to prevent such events in future. Since this patch was published it was brought to my attention that some existing switches may require inbound and outbound ports enabled for inactive ports as well (not spec compliant). Therefore, please remove this patch from your tree. >> This patch is applicable to kernel versions starting from v2.6.35. > > Is that a recommendation that such a backport be performed? If so, > please provide the reasoning. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
