RE: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states
-Original Message- From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- ow...@vger.kernel.org] On Behalf Of Preeti U Murthy Sent: Thursday, July 25, 2013 5:03 PM To: b...@kernel.crashing.org; paul.gortma...@windriver.com; pau...@samba.org; sha...@linux.vnet.ibm.com; ga...@kernel.crashing.org; fweis...@gmail.com; paul...@linux.vnet.ibm.com; mich...@ellerman.id.au; a...@arndb.de; linux...@vger.kernel.org; rost...@goodmis.org; r...@sisk.pl; john.stu...@linaro.org; t...@linutronix.de; Zhao Chenhui-B35336; deep...@linux.vnet.ibm.com; ge...@infradead.org; linux- ker...@vger.kernel.org; srivatsa.b...@linux.vnet.ibm.com; schwidef...@de.ibm.com; sva...@linux.vnet.ibm.com; linuxppc- d...@lists.ozlabs.org Subject: [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states On PowerPC, when CPUs enter deep idle states, their local timers are switched off. The responsibility of waking them up at their next timer event, needs to be handed over to an external device. On PowerPC, we do not have an external device equivalent to HPET, which is currently done on architectures like x86. Instead we assign the local timer of one of the CPUs to do this job. I don't know much about the deep idle states. But is it necessary to turn off the timer in these states? I mean the extra work needed on the booting CPU and re-syncing Time Base after wakeup might defeat the power consumption benefit of turning off the timer. Btw, the Open PIC has an internal timer. Can we use it as the wakeup event? Regards, Leo This patchset is an attempt to make use of the existing timer broadcast framework in the kernel to meet the above requirement, except that the tick broadcast device is the local timer of the boot CPU. This patch series is ported ontop of 3.11-rc1 + the cpuidle driver backend for powernv posted by Deepthi Dharwar recently. The current design and implementation supports the ONESHOT tick mode. It does not yet support the PERIODIC tick mode. This patch is tested with NOHZ_FULL off. Patch[1/5], Patch[2/5]: optimize the broadcast mechanism on ppc. Patch[3/5]: Introduces the core of the timer offload framework on powerpc. Patch[4/5]: The cpu doing the broadcast should not go into tickless idle. Patch[5/5]: Add a deep idle state to the cpuidle state table on powernv. Patch[5/5] is the patch that ultimately makes use of the timer offload framework that the patches Patch[1/5] to Patch[4/5] build. --- Preeti U Murthy (3): cpuidle/ppc: Add timer offload framework to support deep idle states cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints cpuidle/ppc: Add longnap state to the idle states on powernv Srivatsa S. Bhat (2): powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC) powerpc: Implement broadcast timer interrupt as an IPI message arch/powerpc/include/asm/smp.h |3 + arch/powerpc/include/asm/time.h |3 + arch/powerpc/kernel/smp.c | 23 -- arch/powerpc/kernel/time.c | 84 +++ arch/powerpc/platforms/cell/interrupt.c |2 - arch/powerpc/platforms/powernv/Kconfig |1 arch/powerpc/platforms/powernv/processor_idle.c | 48 + arch/powerpc/platforms/ps3/smp.c|2 - kernel/time/tick-sched.c|7 ++ 9 files changed, 161 insertions(+), 12 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove
-Original Message- From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm- ow...@vger.kernel.org] On Behalf Of Wang Dongsheng-B40534 Sent: Wednesday, July 24, 2013 10:26 AM To: Rafael J. Wysocki Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: RE: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove -Original Message- From: Rafael J. Wysocki [mailto:r...@sisk.pl] Sent: Wednesday, July 24, 2013 5:33 AM To: Wang Dongsheng-B40534 Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove On Tuesday, July 23, 2013 05:28:00 PM Dongsheng Wang wrote: From: Wang Dongsheng dongsheng.w...@freescale.com The module can not be removed when execute rmmod. rmmod not use --force. Log: root:~# rmmod cpuidle-e500 incs[9], decs[1] rmmod: can't unload 'cpuidle_e500': Resource temporarily unavailable Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com Can you please check the current linux-next branch of the linux-pm.git tree and see if that doesn't conflict with the material in there? Also please explain in the changelog how your changes help to fix the problem. Yes, Linux-next branch also have this problem. Should I base on Linux-next to fix this problem? I think Dongsheng is trying to make the platform cpuidle driver as a kernel module. My questions are: Is the cpuidle driver supposed to work as a module? Or it can only be built-in like many current drivers do? Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, January 11, 2013 4:41 PM To: Chen Peter-B29397 Cc: ba...@ti.com; ker...@pengutronix.de; Li Yang-R58472; Greg KH; linux- u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3 Hi, On Fri, Jan 11, 2013 at 08:35:29AM +, Chen Peter-B29397 wrote: I am working on it, but there are two versions, this one and chipidea's. Anyway, I will send a patch to fix this problem. if you're already using chipidea, then send me a patch removing this driver and focus your effort on chipidea. Added Sascha Now, not all of FSL i.mx USB can move to use chipidea due to some platform and USB PHY problem. then we need to target fixing those problems and moving to chipidea completely at some point. There's no reason to duplicate efforts if we already have a re-usable driver in tree, right ? Let's fix this build break and focus on making sure all i.MX platforms can use chipidea so we can drop fsl udc on next merge window. That would be a great patchset to see. I do agree that we need move to use the chipidea driver and eventually remove the fsl udc driver, but there were many users of the current driver such as PowerPC and Coldfire platforms besides the i.MX platforms. The support for them with chipidea driver could also be broken for now. I would suggest to have a transitional period that both drivers are kept while new development be based on the new driver. Added Ramneek. What do you think of the current status for chipidea driver on PowerPC platforms? Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, January 10, 2013 10:30 PM To: Felipe Balbi Cc: Li Yang-R58472; linux-...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [BUILD BREAK] usb: gadget: fsl_mxc_udc can't compile on current v3.8-rc3 On Thu, Jan 10, 2013 at 12:08:35PM +0200, Felipe Balbi wrote: Hi, Some recent patch has caused fsl_mxc_udc.c driver to fail compilation because it can't find mach/hardware.h anymore. I would like this to be fixed still during this -rc cycle. Me too, who's sending a patch? :) Hi Peter, Who is currently working on the i.mx USB? Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Saturday, October 20, 2012 1:37 AM To: Simon Haggett Cc: Li Yang-R58472; Felipe Balbi; Greg Kroah-Hartman; linux- u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; Laurent Pinchart Subject: Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware Hi, On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote: Some gadget drivers may attempt to dequeue requests for an endpoint that has already been disabled. For example, in the UVC gadget driver, uvc_function_set_alt() will call usb_ep_disable() when alt setting 0 is selected. When the userspace application subsequently issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes usb_ep_dequeue() to ensure that all requests have been cancelled. bug is on uvc gadget, then. Laurent ? Also, fsl should be removed from the tree, I'm trying to persuade iMX folks to use drivers/usb/chipidea instead. Besides the iMX usage, the driver is also being used by many Freescale PowerPC/Coldfire SoCs. I agree that it's ideal to move to a common driver. But it is a large task to make the chipidea driver works for all the hardware that fsl_udc had supported and been tested on. For the Freescale High Speed Dual-Role USB controller, fsl_ep_dequeue() provides the implementation of usb_ep_dequeue(). If this is called for a disabled endpoint, a kernel oops will occur when the ep-ep.desc field is dereferenced (by ep_index()). fsl_ep_disable() sets this field to NULL, as well as deleting all pending requests for the endpoint. This patch adds an additional check to fsl_ep_dequeue() to ensure that the endpoint has not already been disabled before attempting to dequeue requests. Signed-off-by: Simon Haggett simon.hagg...@realvnc.com --- drivers/usb/gadget/fsl_udc_core.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c index 6ae70cb..acd513b 100644 --- a/drivers/usb/gadget/fsl_udc_core.c +++ b/drivers/usb/gadget/fsl_udc_core.c @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req) int ep_num, stopped, ret = 0; u32 epctrl; - if (!_ep || !_req) + /* Ensure that the ep and request are valid, and the ep is not +* disabled +*/ + if (!_ep || !_req || !ep-ep.desc) return -EINVAL; spin_lock_irqsave(ep-udc-lock, flags); -- 1.7.4.1 -- balbi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
在 Sep 28, 2012，0:07，Kumar Gala ga...@kernel.crashing.org 写道： Hi Kumar, I have already sent the log. Do you have any comment on it? Thanks. - Hongtao. Hongtao, You mentioned: I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. What do the values look like in both ATMU registers and io_resource if you reparse? I think Hongtao mentioned in previous email as follows, the ATMU registers are inline with the io_resource address. I was under that the impression that was the normal boot case, not the values from after wakeup. It is for the normal boot. But re-parse will use the io resource after pic scan to initialize atmu. Instead, the original atmu is initialized use the io resource before the scan. Leo - k Since potar is set by out_be32(pci-pow[j].potar, (hose- io_resource.start 12); I provide the result of hose-io_resource.start 12 as follows: pcie@ffe09000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7ed pcie@ffe0a000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7db pcie@ffe0b000: before pci scan: io_resource.start 12: 0 after pci scan : io_resource.start 12: ff7c9 Note that I tested on P1022DS. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
-Original Message- From: Jia Hongtao-B38951 Sent: Friday, September 21, 2012 11:14 AM To: Kumar Gala Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Wednesday, September 19, 2012 11:49 PM To: Jia Hongtao-B38951 Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Wood Scott-B07421 Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote: Power supply for PCI inbound/outbound window registers is off when system go to deep-sleep state. We save the values of registers before suspend and restore to registers after resume. Signed-off-by: Jiang Yutang b14...@freescale.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Changes for V4: We just rebase the patch upon following patch: powerpc/fsl-pci: Unify pci/pcie initialization code arch/powerpc/include/asm/pci-bridge.h |2 +- arch/powerpc/sysdev/fsl_pci.c | 121 + 2 files changed, 122 insertions(+), 1 deletions(-) Did you ever compare this to just re-parsing device tree method? - k I tested the re-parsing way by using setup_pci_atmu() when resume. And I found out that re-parsing will *change* outbound IO translation address regitster. It seems that in the first bootup, after setup_atmu() pcibios_setup_phb_resources() may update hose-io_resource, but atmu is not updated according to the new hose-io_resource value. In resume from sleep setup_atmu() will reset atmu according to the new hose-io_resource value. So the setup_atmu() will cause different result on outbound IO register between first bootup and resume from sleep. So... There's a possibility that in the first bootup atmu is not setup properly. [Are you seeing this happen in your testing? If so its a bug we need to look at fixing.] Yes, I see this in my testing. Also PCIe ethernet card works well after resuming from sleep in both save/restore and re-parsing way. (Maybe PCIe ethernet card don't need outbound IO resource) So, I guess the result of re-parsing (actually it's re-setup) is right and ATMU is not setup properly at the first bootup. Are you seeing the following message - PCI: I/O resource not set for host bridge ? No. Trying to understand why you'd hit the reassignment of io_resource. - k I did some investigations and the conclusion is: io_resource.flags IORESOURCE_IO are both positive but io_resource.start is 0 before pcibios_setup_phb_io_space() is done. The sequence of related process listed below: fsl_add_bridge() - setup_pci_atmu() pcibios_init() - pcibios_scan_phb() - pcibios_setup_phb_io_space() Because fsl_add_bridge() must be finished before pcibios_init() so ATMU is set when io_resource.start is 0. That means outbound IO regs are not set. If system re-setup ATMU the io_resource.start has already updated so outbound IO regs are set. My question is: Is there any problem if outbound IO regs are not set in first bootup? Please also provide the IO resource address range before and after the pci scan. Then we can evaluate if the range is needed to be mapped via ATMU. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, September 06, 2012 10:28 PM To: Enrico Scholz Cc: ba...@ti.com; Chen Peter-B29397; linux-...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; Li Yang-R58472; gre...@linuxfoundation.org Subject: Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer Hi, On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote: Felipe Balbi ba...@ti.com writes: Because the fsl_udc_core driver shares one 'status_req' object for the complete ep0 control transfer, it is not possible to prime the final STATUS phase immediately after the IN transaction. E.g. ch9getstatus() executed: | req = udc-status_req; | ... | list_add_tail(req-queue, ep-queue); if | (ep0_prime_status(udc, EP_DIR_OUT)) | | struct fsl_req *req = udc-status_req; | list_add_tail(req-queue, ep-queue); which corrupts the ep-queue list by inserting 'status_req' twice. This causes a kernel oops e.g. when 'lsusb -v' is executed on the host. Patch delays the final 'ep0_prime_status(udc, EP_DIR_OUT))' by moving it into the ep0 completion handler. Enrico, thanks for pointing this problem. As prime STATUS phase immediately after the IN transaction is followed USB 2.0 spec, to fix this problem, it is better to add data_req for ep0. In fact, it is already at FSL i.mx internal code, just still not mainlined. so, do I get an Acked-by to this patch ? Does it need to go on v3.6-rc or can it wait until v3.7 merge window ? Without this (or the mentioned data_req patch), I can crash a g_multi gadget by executing 'lsusb -v' as root on the host. Should not be exploitable (only a BUG_ON() is triggered) but issue should be fixed asap. cool, so I'll apply to my fixes branch as soon as I get Acked-by or Tested-by from someone. This seems to revert the error handling for USB2.0 spec 8.5.3.3. But the problem is a serious one to be fixed right away. So Acked-by: Li Yang le...@freescale.com We need to revisit the error handling issue later and find a proper way to address it. Regards, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V8] powerpc/fsl-pci: Unify pci/pcie initialization code
-Original Message-
From: Jia Hongtao-B38951
Sent: Tuesday, August 21, 2012 11:26 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Li Yang-
R58472; Bradley Hughes
Subject: RE: [PATCH V8] powerpc/fsl-pci: Unify pci/pcie initialization
code
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 21, 2012 6:04 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Li Yang-
R58472; Bradley Hughes
Subject: Re: [PATCH V8] powerpc/fsl-pci: Unify pci/pcie initialization
code
On 08/20/2012 05:06 AM, Jia Hongtao wrote:
We unified the Freescale pci/pcie initialization by changing the
fsl_pci to a platform driver. In previous PCI code architecture the
initialization routine is called at board_setup_arch stage. Now the
initialization is done in probe function which is architectural
better. Also It's convenient for adding PM support for PCI controller
in later patch.
Now we registered pci controllers as platform devices. So we combine
two initialization code as one platform driver.
Signed-off-by: Jia Hongtao b38...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
Changes for V8:
* Use previous primary determination. Based on the point that there
are
bugs on primary-less system.
* Add exceptional support on ge_imp3a in which the primary bus is not
the
first pci bus detected.
The exceptional thing about ge_imp3a is that it has no isa node, but
we're not sure if it actually has isa or not. We should not be relying
on probe order in any case. Device tree nodes are not ordered.
Yes... We don't know if ge_imp3a actually has isa and still no answer
from
board owner. I just set primary as the board used to. At least we don't
do
any harm.
Another interesting case is stxssa8555.dts, which has an i8259 node but
no ISA node (are there any other instances of this?). However, I can't
tell if stx_gp3.c is the platform file that goes with this device tree,
or if the platform code for stxssa8555 is out-of-tree (or some other
file
that I'm not seeing).
MPC8541_CDS and MPC8555_CDS also has i8259 but no ISA node. stx_gp3 seems
go
with stxssa8555.dts but I'm not sure ether.
So you mean we have to look for i8259 too for determining primary.
Take device tree as evidence we can tell that real primary ether has isa
node
or i8259 node. And if there is no isa we just arbitrarily designate one.
If this logic works well then ok.
If there is i8259 node in the device tree, it should be suggesting that there
is a PCI to ISA bridge but not explicitly described in the device tree. Then
we need to fix the device tree to add the ISA nodes.
- Leo
-void __devinit fsl_pci_init(void)
+void fsl_pci_assign_primary(void)
{
- int ret;
struct device_node *node;
- struct pci_controller *hose;
- dma_addr_t max = 0x;
/* Callers can specify the primary bus using other means. */
if (!fsl_pci_primary) {
Since the whole point of this function is now to find the primary, just
return if it's already set, instead of indenting the rest of the
function.
@@ -842,38 +839,60 @@ void __devinit fsl_pci_init(void)
node = fsl_pci_primary;
if (of_match_node(pci_ids, node))
- break;
+ return;
}
- }
- node = NULL;
- for_each_node_by_type(node, pci) {
- if (of_match_node(pci_ids, node)) {
+ node = of_find_node_by_type(NULL, pci);
+ if (of_match_node(pci_ids, node))
What if the node returned doesn't match? If you're checking for this,
handle the else-case (even if just with an error message).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V8] powerpc/fsl-pci: Unify pci/pcie initialization code
On Aug 22, 2012, at 1:16, Wood Scott-B07421 b07...@freescale.com wrote: On 08/21/2012 01:49 AM, Li Yang-R58472 wrote: If there is i8259 node in the device tree, it should be suggesting that there is a PCI to ISA bridge but not explicitly described in the device tree. Then we need to fix the device tree to add the ISA nodes. No, we need to work with existing device trees. Just because they're hosted in the kernel tree doesn't mean they can be treated as an internal kernel implementation detail. They are stable API with external entities such as bootloaders and hypervisors, get forked for custom boards, etc. You are right that device tree binding is a stable API but not a poorly written dts instance. We are not changing any binding definition. It is just adding the somehow missed node that should be there in some poorly written dts in the first place according to current binding. Is it making any sense to have ISA devices directly under pci bus? Boards with this problem should set fsl_pci_primary in platform code based on whatever criteria is relevant. I don't know how legitimate it is to use a new kernel but not the device tree from that source. If that's the problem that we need to take care of, I think we need to add the workaround in the platform code temporarily for a transitional period. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wang Dongsheng-B40534
Sent: Monday, August 13, 2012 1:54 PM
To: Wood Scott-B07421
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: RE: [PATCH v2 2/2] powerpc/mpic: add global timer support
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, August 11, 2012 3:40 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
d...@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On 08/10/2012 12:54 AM, dongsheng.w...@freescale.com wrote:
+static const struct of_device_id mpic_timer_ids[] = {
+ { .compatible = open-pic,global-timer, },
+ { .compatible = fsl,global-timer, },
+ {},
+};
+
+static int __init mpic_timer_init(void) {
+ struct device_node *np = NULL;
+
+ for_each_node_by_type(np, open-pic)
+ if (of_match_node(mpic_timer_ids, np))
+ group_init(np);
+
+ if (list_empty(group_list))
+ return -ENODEV;
+
+ return 0;
+}
+arch_initcall(mpic_timer_init);
Oh, and don't probe by device_type.
Actually it does match the compatible. The device_type is just to speed up the
search. I don't think it's a problem unless the device type is not mandatory
any more for defined types.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: rionet driver with MMIO DMA capability
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev- bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of Vineeth Sent: Wednesday, July 04, 2012 1:16 AM To: linux-embed...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linuxppc-embed...@ozlabs.org; Wood Scott-B07421; mpor...@kernel.crashing.org Cc: ranenikhi...@gmail.com Subject: rionet driver with MMIO DMA capability Hi, With kernel mainstream version 3.5.rc-5 there's SRIO low level driver with DMA support for MMIO. But the rionet driver in the same kernel version doesnt support MMIO. We are trying to find the maximum bandwidth that we can achieve using our custom board's(quad MPC8641 ) 4-lane SRIO. Now we are worried how to use this SRIO low level driver effectively ? The RIOnet driver (with 3.5.-rc5) uses message based communication. This doesnt use the DMA capability of low level driver. with this we are getting a bandwidth of nearly 900Mbps, which is very less. Is there any example code or modified middle ware driver for rionet/ or any code which uses the low level driver apis with MMIO DMA?? We provided the support for DMA in the old BSPs but didn't got the luck to make it upstream. I heard Alex (CCed) is working on an upstream-able version of the feature. Probably he can help to provide some code. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform
-Original Message- From: Wood Scott-B07421 Sent: Friday, June 29, 2012 11:02 AM To: Kumar Gala Cc: Jia Hongtao-B38951; Wood Scott-B07421; Li Yang-R58472; ag...@suse.de; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform On 06/29/2012 10:57 AM, Kumar Gala wrote: On Jun 28, 2012, at 9:36 PM, Jia Hongtao-B38951 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, June 29, 2012 12:31 AM To: Jia Hongtao-B38951 Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Li Yang-R58472; ag...@suse.de; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform On 06/27/2012 11:06 PM, Jia Hongtao-B38951 wrote: -Original Message- From: Wood Scott-B07421 Sent: Thursday, June 28, 2012 7:49 AM To: ga...@kernel.crashing.org Cc: ag...@suse.de; linuxppc-dev@lists.ozlabs.org; Jia Hongtao-B38951 Subject: [PATCH 0/3] powerpc/fsl: PCI refactoring and QEMU paravirt platform The QEMU stuff is related to the PCI refactoring because currently we have a hard time selecting a primary bus under QEMU, and also because the generic qemu e500 platform wants a full list of FSL PCI compatibles to check. It seems that not all primary bus has isa node like 8541 and 8555. Do those boards (it's the boards that matter, not chips...) have legacy ISA? If they do, and it's not in the device tree, then we should fix the device tree for consistency, but also retain some sort of hack to remain compatible with old device trees. A board can refrain from using the new common infrastructure if it has a good reason to. I'm not sure that MPC8541CDS (or 8555) has legacy ISA. I just checked in kernel and dts which implies the board has primary bus and no isa node. I will find out the facts later. Pretty sure the boards have ISA, if you see the .dts has references to 'ISA bridge' 'i8259' PIC. OK. How about looking for an i8259 node as well? That could work, but looks hackish. Our proposal for adding a new device tree property is a generic solution. The only problem is that new kernels would work with old device trees. I think we can use your solution for transitional period. And go for a well defined device tree binding for this in long run. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP
Subject: Question about MPIC_SINGLE_DEST_CPU on P1020 (e500 core) SMP Hi The P1020 manual states (in the PIC chapter) that in the Internal Interrupt Destination register, only 1 CPU (and not both) can be selected as the IRQ destination. How then can we achieve interrupt spraying for the PCI interrupt (we want interrupts to be sent alternately to CPU0 and CPU1). Also, we changed the code to ignore the MPIC_SINGLE_DEST_CPU flag and set both CPUs in the destination of the PIC_IIDRn register. This does seem to work. But we're not sure if we can rely on this behavior and whether it will cause other problems. I suggest you to follow the UM. The note should be there for a reason although personally I don't know what the specific problem will be. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, June 06, 2012 12:12 AM To: Li Yang-R58472 Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org Subject: Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source On 06/04/2012 11:08 PM, Li Yang-R58472 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, June 05, 2012 7:03 AM To: Zhao Chenhui-B35336 Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; Li Yang-R58472 Subject: Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source On 06/04/2012 06:36 AM, Zhao Chenhui wrote: On Fri, Jun 01, 2012 at 05:08:52PM -0500, Scott Wood wrote: On 05/11/2012 06:53 AM, Zhao Chenhui wrote: +int mpc85xx_pmc_set_wake(struct platform_device *pdev, bool +enable) Why does it have to be a platform_device? Would a bare device_node work here? If it's for stuff like device_may_wakeup() that could be in a platform_device wrapper function. It does not have to be a platform_device. I think it can be a struct device. Why does it even need that? The low level mechanism for influencing PMCDR should only need a device node, not a Linux device struct. It does no harm to pass the device structure and makes more sense for object oriented interface design. It does do harm if you don't have a device structure to pass, if for some reason you found the device by directly looking for it rather than going through the device model. Whether or not a device is a wakeup source not only depends on the SoC specification but also the configuration and current state for the device. I only expect the device driver to have this knowledge and call this function rather than some standalone platform code. Therefore I don't think your concern matters. Who is setting can_wakeup for these devices? The device driver is responsible to set can_wakeup. How would the device driver know how to set it? Wouldn't this depend on the particular SoC and low power mode? It is based on the fsl,magic-packet and fsl,wake-on-filer device tree properties. fsl,magic-packet was a mistake. It is equivalent to checking the compatible for etsec. It does not convey any information about whether It can be described either by explicit feature property or by the compatible. I don't think it is a problem that we choose one against another. the eTSEC is still active in a given low power mode. Whether or not the eTSEC is still active in both sleep and deep sleep is only depending on if we set it to be a wakeup source. If it behaves differently for low power modes in the future, we could address that by adding additional property. How is fsl,wake-os-filer relevant to this decision? When will it be set but not fsl,magic-packet? I mean either fsl,magic-packet or fsl,wake-on-filer shows it can be a wakeup source. Currently we don't have an SoC to have wake-on-filer while not wake-on-magic. But I think it's better to consider both as they are independent features. What about devices other than ethernet? What about differences between ordinary sleep and deep sleep? There is no difference for sleep and deep sleep for all wakeup sources currently. We can address the problem if it is not the case in the future. Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, June 05, 2012 7:03 AM
To: Zhao Chenhui-B35336
Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org;
ga...@kernel.crashing.org; Li Yang-R58472
Subject: Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup
event source
On 06/04/2012 06:36 AM, Zhao Chenhui wrote:
On Fri, Jun 01, 2012 at 05:08:52PM -0500, Scott Wood wrote:
On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
Add APIs for setting wakeup source and lossless Ethernet in low power
modes.
These APIs can be used by wake-on-packet feature.
Signed-off-by: Dave Liu dave...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jin Qing b24...@freescale.com
Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com
---
arch/powerpc/sysdev/fsl_pmc.c | 71
-
arch/powerpc/sysdev/fsl_soc.h |9 +
2 files changed, 79 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pmc.c
b/arch/powerpc/sysdev/fsl_pmc.c
index 1dc6e9e..c1170f7 100644
--- a/arch/powerpc/sysdev/fsl_pmc.c
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -34,6 +34,7 @@ struct pmc_regs {
__be32 powmgtcsr;
#define POWMGTCSR_SLP0x0002
#define POWMGTCSR_DPSLP 0x0010
+#define POWMGTCSR_LOSSLESS 0x0040
__be32 res3[2];
__be32 pmcdr;
};
@@ -43,6 +44,74 @@ static unsigned int pmc_flag;
#define PMC_SLEEP0x1
#define PMC_DEEP_SLEEP 0x2
+#define PMC_LOSSLESS 0x4
+
+/**
+ * mpc85xx_pmc_set_wake - enable devices as wakeup event source
+ * @pdev: platform device affected
+ * @enable: True to enable event generation; false to disable
+ *
+ * This enables the device as a wakeup event source, or disables it.
+ *
+ * RETURN VALUE:
+ * 0 is returned on success
+ * -EINVAL is returned if device is not supposed to wake up the
system
+ * Error code depending on the platform is returned if both the
platform and
+ * the native mechanism fail to enable the generation of wake-up
events
+ */
+int mpc85xx_pmc_set_wake(struct platform_device *pdev, bool enable)
Why does it have to be a platform_device? Would a bare device_node
work
here? If it's for stuff like device_may_wakeup() that could be in a
platform_device wrapper function.
It does not have to be a platform_device. I think it can be a struct
device.
Why does it even need that? The low level mechanism for influencing
PMCDR should only need a device node, not a Linux device struct.
It does no harm to pass the device structure and makes more sense for object
oriented interface design.
Where does this get called from? I don't see an example user in this
patchset.
It will be used by a gianfar related patch. I plan to submit that patch
after these patches accepted.
It would be nice to see how this is used when reviewing this.
+{
+ int ret = 0;
+ struct device_node *clk_np;
+ u32 *prop;
+ u32 pmcdr_mask;
+
+ if (!pmc_regs) {
+ pr_err(%s: PMC is unavailable\n, __func__);
+ return -ENODEV;
+ }
+
+ if (enable !device_may_wakeup(pdev-dev))
+ return -EINVAL;
Who is setting can_wakeup for these devices?
The device driver is responsible to set can_wakeup.
How would the device driver know how to set it? Wouldn't this depend on
the particular SoC and low power mode?
It is based on the fsl,magic-packet and fsl,wake-on-filer device tree
properties.
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
-Original Message- From: Anthony Foiani [mailto:t...@scrye.com] Sent: Friday, May 18, 2012 1:08 AM To: linuxppc-dev@lists.ozlabs.org Cc: ashish kalra; Li Yang-R58472; Jeff Garzik; Robert P.J.Day; Adrian Bunk Subject: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS Greetings. I was occasionally running into problems at boot time on an MPC8315-based board (derived from the MPC831xRDB, apparently), using SATA to talk to an SSD. My vendor suggested that I enable CONFIG_MPC8315_DS. That symbol is only found once in the entire kernel codebase: $ git checkout v3.4-rc7 HEAD is now at 36be505... Linux 3.4-rc7 $ git grep -nH CONFIG_MPC8315_DS drivers/ata/sata_fsl.c:729:#ifdef CONFIG_MPC8315_DS There is no kconfig support for it at all. It was added in 2007; further, this is the only commit in the entire git history that contains this string: commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 Author: ashish kalra ashish.ka...@freescale.com Date: Wed Oct 31 19:28:02 2007 +0800 ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef Signed-off-by: ashish kalra ashish.ka...@freescale.com Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Jeff Garzik j...@garzik.org diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index 5892472..e076e1f 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -652,6 +652,7 @@ static int sata_fsl_port_start(struct ata_port *ap) VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL)); VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA)); +#ifdef CONFIG_MPC8315_DS /* * Workaround for 8315DS board 3gbps link-up issue, * currently limit SATA port to GEN1 speed @@ -664,6 +665,7 @@ static int sata_fsl_port_start(struct ata_port *ap) sata_fsl_scr_read(ap, SCR_CONTROL, temp); dev_printk(KERN_WARNING, dev, scr_control, speed limited to %x\n, temp); +#endif return 0; } This otherwise-unsupported variable was noted by Robert Day in 2008; Adrian Bunk suggested a patch, but the Freescale folks said that it was for a not-yet-mainlined board, so the patch was dropped: http://marc.info/?l=linux-idem=121783965216004w=2 As Robert notied again in 2010, it still wasn't mainlined: http://marc.info/?l=linux-idem=121783965216004w=2 And, obviously, it still isn't today. Can the Freescale people tell us exactly what we should be testing to determine when to enforce this restriction? A config variable that points to a non-existent board doesn't seem much help. Thanks for bringing it up again. Looks like we do have a problem here. Btw, did it help with your problem by enabling it? Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] fsldma: fix performance degradation by optimizing spinlock use.
Hi Dan and Vinod, Please help to pick this patch up. It addresses a great performance regression for RAID offloading. Acked-by: Li Yang le...@freescale.com - Leo -Original Message- From: Shi Xuelin-B29237 Sent: Thursday, April 26, 2012 10:04 AM To: dan.j.willi...@intel.com Cc: vinod.k...@intel.com; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; Ira W. Snyder; Li Yang-R58472 Subject: RE: [PATCH] fsldma: fix performance degradation by optimizing spinlock use. Hi Dan Williams, Do you have any comment about this patch? Thanks, Forrest -Original Message- From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] Sent: 2012年1月12日 0:14 To: Shi Xuelin-B29237 Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] fsldma: fix performance degradation by optimizing spinlock use. On Wed, Jan 11, 2012 at 07:54:55AM +, Shi Xuelin-B29237 wrote: Hello Iris, As we discussed in the previous patch, I add one smp_mb() in fsl_tx_status. In my testing with iozone, this smp_mb() could cause 1%~2% performance degradation. Anyway it is acceptable for me. Do you have any other comments? This patch looks fine to me. Ira -Original Message- From: Shi Xuelin-B29237 Sent: 2011年12月26日 14:01 To: i...@ovro.caltech.edu; vinod.k...@intel.com; dan.j.willi...@intel.com; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org Cc: Shi Xuelin-B29237 Subject: [PATCH] fsldma: fix performance degradation by optimizing spinlock use. From: Forrest shi b29...@freescale.com dma status check function fsl_tx_status is heavily called in a tight loop and the desc lock in fsl_tx_status contended by the dma status update function. this caused the dma performance degrades much. this patch releases the lock in the fsl_tx_status function, and introduce the smp_mb() to avoid possible memory inconsistency. Signed-off-by: Forrest Shi xuelin@freescale.com --- drivers/dma/fsldma.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8a78154..008fb5e 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -986,15 +986,11 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan, struct fsldma_chan *chan = to_fsl_chan(dchan); dma_cookie_t last_complete; dma_cookie_t last_used; - unsigned long flags; - - spin_lock_irqsave(chan-desc_lock, flags); last_complete = chan-completed_cookie; + smp_mb(); last_used = dchan-cookie; - spin_unlock_irqrestore(chan-desc_lock, flags); - dma_set_tx_state(txstate, last_complete, last_used, 0); return dma_async_is_complete(cookie, last_complete, last_used); } -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
-#ifdef CONFIG_KEXEC
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_disable= generic_cpu_disable,
+ .cpu_die= generic_cpu_die,
+#endif
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
-#endif
};
We need to stop using smp_generic_give/take_timebase, not expand its use.
This stuff breaks under hypervisors where timebase can't be written. It
wasn't too bad before since we generally didn't enable CONFIG_KEXEC, but
we're more likely to want CONFIG_HOTPLUG_CPU.
I understand that the guest OS shouldn't change the real timebase. But no
matter what timebase syncing method we are using, the timebase need to be
changed anyway for certain features. I think the better way should be trapping
timebase modification in the hypervisor.
Do the timebase sync the way U-Boot does -- if you find the appropriate
guts node in the device tree.
That involves stopping timebase for a short time on all cores including the
cores that are still online. Won't this be a potential issue?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable Huang Changming-R66093 wrote: I have one similar patch to remove the select PHYS_64BIT. http://patchwork.ozlabs.org/patch/132351/ That one doesn't update the defconfigs, which means that the default kernel will not have PHYS_64BIT enabled. I think it is not necessary to enable the 64BIT, if customer want to enable it, he can do it manually. I agree with Changming that we shouldn't setting PHYS_64BIT by default. For the platforms covered by the mpc85xx_defconfig, most user won't need the PHYS_64BIT. We shouldn't set the one with worse performance and unnecessary to most people as default. Also all these platforms supports 32-bit mode. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
-Original Message- From: Tabi Timur-B04825 Sent: Friday, February 24, 2012 10:46 AM To: Li Yang-R58472 Cc: Huang Changming-R66093; ga...@kernel.crashing.org; b...@kernel.crashing.org; Wood Scott-B07421; linuxppc-...@ozlabs.org Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable Li Yang-R58472 wrote: I agree with Changming that we shouldn't setting PHYS_64BIT by default. The default kernel should always be the compatible with as much as possible. Disabling PHYS_64BIT by default means that the default kernel will not work with a 36-bit DTS. If you attempt to boot such a kernel with a 36-bit DTS, there will be no text output. Most people will not know why it's not working. So the safest option is for PHYS_64BIT to be enabled by default. That way, the kernel will always work. Even though the user still need to know the addressing mode that u-boot is using. It won't work if the addressing mode of u-boot and device tree are different. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable Li Yang-R58472 wrote: Even though the user still need to know the addressing mode that u-boot is using. It won't work if the addressing mode of u-boot and device tree are different. U-Boot will tell the user if the DT does not match. I added code to U- Boot to do that. So if you have a 36-bit U-Boot and a 32-bit DT, then you will get a warning. If you have a 36-bit U-boot and a 36-bit DT and a 32-bit kernel, you will get nothing. But if you have a 32-bit U-boot and a 32-bit DT and a 36-bit kernel, then that will work. A 36-bit kernel works with 32-bit *and* 36-bit DTs. This is why a 36-bit kernel should be the default. The mpc85xx_defconfig does include silicons with e500v1 core which doesn't have the 36-bit support. Won't enabling 36-bit support by default break the support for them? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable Li Yang-R58472 wrote: The mpc85xx_defconfig does include silicons with e500v1 core which doesn't have the 36-bit support. Won't enabling 36-bit support by default break the support for them? No. The kernel will detect at runtime that that it's an e500v1 core and it won't try to create 36-bit TLBs. (e.g. it won't write to MAS7). It's a good point. Why can't we decide to use 32-bit/36-bit TLB at runtime even for e500v2? Please remember that the Kconfig for the P1022DS already forced PHYS_64BIT for all mpc85xx platforms. All we're doing is making it possible to deselect PHYS_64BIT. I think it's a side-effect introduced by P1022DS support and need to be fixed. There was no mentioning of enforcing 36-bit for all mpc85xx platforms. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
I tried a debian install on the p5020ds here and I find SATA to be extremely slow, generating millions of interrupts. I think the defaults should be a lot more aggressive at coalescing. The P5020 has a hardware problem with SATA, making it generate more interrupts than it should. A new revision of the silicon will fix it. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
Subject: Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable On Feb 16, 2012, at 6:10 AM, Li Yang wrote: Fix the problem that large physical address support cannot be disabled when some platforms which only provides 36-bit support are selected. According to the philosophy of kernel config enabling a platform support doesn't mean the kernel is only running on that platform. Remove the auto selection of PHYS_64BIT option for these platforms. They will need to use a 36bit default config that selects PHYS_64BIT explicitly. The reason why we need to keep PHYS_64BIT option configurable is that enabling it cause negative performance impact on various aspects like TLB miss and physical address manipulating. We should not enable it unless really needed, e.g. use large memory of 4GB or bigger. Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/platforms/85xx/Kconfig |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) Nak, this isn't correct. For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, P5020DS only a 36-bit physical address map is supported by u-boot and the device tree. This was a decision that was made to NOT support 32-bit address map for these boards and accept the performance implication of it to reduce the # of builds, etc. Ok. Although personally I don't think # of builds matters that much. Additionally, outside of maybe P2041RDB I believe the majority of these boards ship with 4G of DDR (but that off the top of my head) and thus require the 36-bit / PHYS_64BIT support to be enabled. I know that current support of DPAA boards requires 36-bit. But I don't think they need to select the PHYS_64BIT option directly and make it not configurable. It's conflicting with the logic that enabling a platform support doesn't mean the kernel is only running on that platform. Btw: what's your recommendations on solving this? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC] Multi queue support in ethernet/freescale/ucc_geth.c
-Original Message- From: Paul Gortmaker [mailto:paul.gortma...@windriver.com] Sent: Friday, February 03, 2012 6:42 AM To: Li Yang-R58472 Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: [RFC] Multi queue support in ethernet/freescale/ucc_geth.c Hi Li, Hi Paul, Sorry for the late response due to holidays. A while back DaveM mentioned that it would be good to break out the ring allocations[1] in this driver. I was looking at it, and in the process noticed this: $ grep 'numQueues.*=' drivers/net/ethernet/freescale/ucc_geth.c .numQueuesTx = 1, .numQueuesRx = 1, $ My interpretation of the above is that there is no way (aside from a code edit) to enable multi queue support. They are only ever assigned one time, to a value of one. Assuming I'm not missing something obvious, is the multi queue support functional and tested, or just old code that never got tested and subsequently enabled? Previously the device is only used on single core cpu, so we didn't have the incentive to enable multi-queue. It is not tested on Linux currently. The reason I ask, is that the ring allocation code gets rid of the loop wrapping it, if the driver is really only meant to ever have just single queues for Rx/Tx. And other areas of the driver can also be simplified accordingly as well. Well. I would prefer the other way which is to add the multi-queue support as we are using the QE in multi-core SoC and the current driver is having almost all the code needed for multi-queue except interface to the protocol layer. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] Integrated Flash Controller support
-Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Wednesday, November 30, 2011 4:51 PM To: Kumar Gala Cc: Wood Scott-B07421; Li Yang-R58472; Liu Shuo-B35362; linux- ker...@vger.kernel.org Kernel; linux-...@lists.infradead.org; Andrew Morton; David Woodhouse; linuxppc-dev@lists.ozlabs.org list Subject: Re: [PATCH v2] Integrated Flash Controller support On Tue, 2011-11-29 at 19:47 -0600, Kumar Gala wrote: As Scott said, I was more asking about the 2nd patch in the sequence which did touch MTD. Since that one is dependent on this patch, wondering how we wanted to handle them. I do not have time to review it, but it looks OK, so I'd suggest to merge it vie the same tree as the rest of the patches. Hi Artem, So what is your suggestion on this patch? Can we regard your previous email as an ACK and merge it through the powerpc tree? Or do you prefer to merge them through the MTD tree with Kumar's ACK instead? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
Subject: Re: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use. On Thu, Nov 24, 2011 at 08:12:25AM +, Shi Xuelin-B29237 wrote: Hi Ira, Thanks for your review. After second thought, I think your scenario may not occur. Because the cookie 20 we query must be returned by fsl_dma_tx_submit(...) in practice. We never query a cookie not returned by fsl_dma_tx_submit(...). I agree about this part. When we call fsl_tx_status(20), the chan-common.cookie is definitely wrote as 20 and cpu2 could not read as 19. This is what I don't agree about. However, I'm not an expert on CPU cache vs. memory accesses in an multi-processor system. The section titled CACHE COHERENCY in Documentation/memory-barriers.txt leads me to believe that the scenario I described is possible. For Freescale PowerPC, the chip automatically takes care of cache coherency. Even if this is a concern, spinlock can't address it. What happens if CPU1's write of chan-common.cookie only goes into CPU1's cache. It never makes it to main memory before CPU2 fetches the old value of 19. I don't think you should see any performance impact from the smp_mb() operation. Smp_mb() do have impact on performance if it's in the hot path. While it might be safer having it, I doubt it is really necessary. If the CPU1 doesn't have the updated last_used, it's shouldn't have known there is a cookie 20 existed either. - Leo Thanks, Ira -Original Message- From: Ira W. Snyder [mailto:i...@ovro.caltech.edu] Sent: 2011年11月23日 2:59 To: Shi Xuelin-B29237 Cc: dan.j.willi...@intel.com; Li Yang-R58472; z...@zh-kernel.org; vinod.k...@intel.com; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use. On Tue, Nov 22, 2011 at 12:55:05PM +0800, b29...@freescale.com wrote: From: Forrest Shi b29...@freescale.com dma status check function fsl_tx_status is heavily called in a tight loop and the desc lock in fsl_tx_status contended by the dma status update function. this caused the dma performance degrades much. this patch releases the lock in the fsl_tx_status function. I believe it has no neglect impact on the following call of dma_async_is_complete(...). we can see below three conditions will be identified as success a) x complete use b) x complete+N use+N c) x complete use+N here complete is the completed_cookie, use is the last_used cookie, x is the querying cookie, N is MAX cookie when chan-completed_cookie is being read, the last_used may be incresed. Anyway it has no neglect impact on the dma status decision. Signed-off-by: Forrest Shi xuelin@freescale.com --- drivers/dma/fsldma.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index 8a78154..1dca56f 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -986,15 +986,10 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan, struct fsldma_chan *chan = to_fsl_chan(dchan); dma_cookie_t last_complete; dma_cookie_t last_used; - unsigned long flags; - - spin_lock_irqsave(chan-desc_lock, flags); This will cause a bug. See below for a detailed explanation. You need this instead: /* * On an SMP system, we must ensure that this CPU has seen the * memory accesses performed by another CPU under the * chan-desc_lock spinlock. */ smp_mb(); last_complete = chan-completed_cookie; last_used = dchan-cookie; - spin_unlock_irqrestore(chan-desc_lock, flags); - dma_set_tx_state(txstate, last_complete, last_used, 0); return dma_async_is_complete(cookie, last_complete, last_used); } Facts: - dchan-cookie is the same member as chan-common.cookie (same memory location) - chan-common.cookie is the last allocated cookie for a pending transaction - chan-completed_cookie is the last completed transaction I have replaced dchan-cookie with chan-common.cookie in the below explanation, to keep everything referenced from the same structure. Variable usage before your change. Everything is used locked. - RW chan-common.cookie(fsl_dma_tx_submit) - R chan-common.cookie(fsl_tx_status) - R chan-completed_cookie (fsl_tx_status) - W chan-completed_cookie (dma_do_tasklet) Variable usage after your change: - RW chan-common.cookieLOCKED - R chan-common.cookieNO LOCK - R chan-completed_cookie NO LOCK - W chan-completed_cookie LOCKED What if we assume that you have a 2 CPU system (such as a P2020). After your changes, one possible sequence is: === CPU1
RE: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
-Original Message- From: Peter Chen [mailto:hzpeterc...@gmail.com] Sent: Wednesday, November 23, 2011 11:02 AM To: Li Yang-R58472 Cc: Chen Peter-B29397; ba...@ti.com; gre...@suse.de; linux- u...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress On Tue, Nov 22, 2011 at 7:48 PM, Peter Chen hzpeterc...@gmail.com wrote: It seems to can't get the correct qh pointer, you may still need to use below code to get it int i = ep_index(ep) * 2 + ep_is_in(ep); struct ep_queue_head *dQH = ep-udc-ep_qh[i]; Thanks for trying. It will be much easier if we can dereference QH from the ep structure. It is really strange that the ep-qh pointer is not working somehow. Seems only ep0-out's qh pointer is assigned at ep structure. At probe: /* setup udc-eps[] for ep0 */ struct_ep_setup(udc_controller, 0, ep0, 0); We have initialized it in struct_ep_setup(): ep-qh = udc-ep_qh[index]; Can you do me a favor on investigating why it's failing? Leo, I have debugged this issue at my board just now, the reason of failure is we only have one ep struct for ep0, so when talking about ep0, it always pointers to udc-ep[0]. So even we initialize the current qh address for ep0in at probe, it still can't get the ep0in's qh address through ep structure, as ep0 is always udc-ep[0]. Oops. I forgot the fact that we used a single ep structure to handle both IN and OUT ep0 because the gadget layer only knows about one ep0 structure. I guess currently we have no other way out unless the gadget layer do honor ep0 with direction. IMHO, it is a limitation to current gadget APIs that each udc driver need to take too much care of the protocol related stuff on ep0. Thanks, Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Subject: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
large-page Nand chip
From: Liu Shuo b35...@freescale.com
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Liu Shuo b35...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c | 211
+++---
1 files changed, 194 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
b/drivers/mtd/nand/fsl_elbc_nand.c
index d634c5f..c96e714 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
[snip]
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv-ctrl-nand;
+ void *src, *dst;
+ int len = (oob ? 64 : 2048);
+
+ if (oob)
+ dst = elbc_fcm_ctrl-buffer + mtd-writesize + subpage * 64;
+ else
+ dst = elbc_fcm_ctrl-buffer + subpage * 2048;
+
+ src = elbc_fcm_ctrl-addr + (oob ? 2048 : 0);
+ memcpy_fromio(dst, src, len);
Might be safer to use _memcpy_fromio()
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv-ctrl-nand;
+ void *src, *dst;
+ int len = (oob ? 64 : 2048);
+
+ if (oob)
+ src = elbc_fcm_ctrl-buffer + mtd-writesize + subpage * 64;
+ else
+ src = elbc_fcm_ctrl-buffer + subpage * 2048;
+
+ dst = elbc_fcm_ctrl-addr + (oob ? 2048 : 0);
+ memcpy_toio(dst, src, len);
+
+ /* See the in_8() in fsl_elbc_write_buf() */
+ in_8(elbc_fcm_ctrl-addr);
Should be safer to read back the last char.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote: + /* +* Freescale FCM controller has a 2K size limitation of buffer +* RAM, so elbc_fcm_ctrl-buffer have to be used if writesize +* of chip is greater than 2048. +* We malloc a large enough buffer (maximum page size is 16K). +*/ + elbc_fcm_ctrl-buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL); Are there NANDs with 16KiB page size? We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
Subject: Re: [PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote: On Nov 16, 2011, at 12:42 PM, Scott Wood wrote: On 11/16/2011 03:55 AM, Zhao Chenhui wrote: From: Li Yang le...@freescale.com The timebase sync is not only necessary when using KEXEC. It should also be used by normal boot up and cpu hotplug. Remove the ifdef added by the KEXEC patch. Again, no it should not be used by normal boot up (whether KEXEC support is enabled or not). We should only do timebase sync when we actually need to (when we've actually just reset a core), and we should do it the way U-Boot does rather than with smp-tbsync.c. While looking into the timebase sync code in u-boot, I have a few questions. /* enable time base at the platform */ if (whoami) devdisr |= MPC85xx_DEVDISR_TB1; else devdisr |= MPC85xx_DEVDISR_TB0; out_be32(gur-devdisr, devdisr); /* readback to sync write */ in_be32(gur-devdisr); mtspr(SPRN_TBWU, 0); mtspr(SPRN_TBWL, 0); What are the TBWU/TBWL registers? I can't find the definition of them in either e500 RM or booke RM. Are they valid to be used? What is the result of writing to them? Aren't the SPR registers core specific? How can we set the TB for the other cores? devdisr = ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1); out_be32(gur-devdisr, devdisr); Also in the UM, I read Blocks disabled by DEVDISR must not be re-enabled without a hard reset. Is it safe we enable it here? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
Subject: Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
On Fri, Nov 11, 2011 at 08:38:13PM +0800, Li Yang wrote:
The original implementation of dequeuing a request in progress is not
correct. Change to use a correct process and also clean up the
related functions a little bit.
Signed-off-by: Li Yang le...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 62 +-
--
1 files changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b2c44e1..beef9b7 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -696,12 +696,31 @@ static void fsl_free_request(struct usb_ep *_ep,
struct usb_request *_req)
kfree(req);
}
-/*---
--*/
+/* Actually add a dTD chain to an empty dQH and let go */ static void
+fsl_prime_ep(struct fsl_ep *ep, struct ep_td_struct *td) {
+struct ep_queue_head *qh = ep-qh;
It seems to can't get the correct qh pointer, you may still need to use
below code to get it
int i = ep_index(ep) * 2 + ep_is_in(ep);
struct ep_queue_head *dQH = ep-udc-ep_qh[i];
Thanks for trying.It will be much easier if we can dereference QH from the
ep structure. It is really strange that the ep-qh pointer is not working
somehow.
We have initialized it in struct_ep_setup():
ep-qh = udc-ep_qh[index];
Can you do me a favor on investigating why it's failing?
Thanks,
Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER
Subject: [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER Some ISO gadgets, like audio, has SYNC attribute as well as USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint descriptor. So, it needs to use usb_endpoint_xfer_isoc to judge ISO XFER. Signed-off-by: Peter Chen peter.c...@freescale.com Acked-by: Li Yang le...@freescale.com - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/7] powerpc/85xx: add HOTPLUG_CPU support
Cc: linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
Subject: Re: [PATCH v2 2/7] powerpc/85xx: add HOTPLUG_CPU support
On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
+static void __cpuinit smp_85xx_mach_cpu_die(void) {
+unsigned int cpu = smp_processor_id();
+register u32 tmp;
+
+local_irq_disable();
+idle_task_exit();
+generic_set_cpu_dead(cpu);
+mb();
+
+mtspr(SPRN_TCR, 0);
+mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
Clearing these bits in TSR should be unnecessary since we clear TCR -- and
doesn't really accomplish anything since the TSR bits can continue to be
set.
I also recommend setting the CORE_IRQ_MASK and CORE_CI_MASK in the POWMGTCSR
register so that no interrupt will wakeup the core from NAP.
If watchdog is in use, we need to set the period to the highest possible
to effectively disable it.
Setting it to the highest timeout doesn't really disable the watchdog. The
best way for disabling the wdt is to reset the core, although it's a bit too
complex to do.
+if (cpu_has_feature(CPU_FTR_CAN_NAP)) {
Again, don't check this. On 85xx, we *always* can and should use nap here.
At best this is noise, at worst this will cause problems if
CONFIG_BDI_SWITCH is enabled, or if CPU_FTR_CAN_NAP is cleared for any
other reason (e.g. it's not set on e500mc, and the reason isn't that the
nap implementation is different (which it is), but that it's not usable in
the idle loop).
+static int __cpuinit smp_85xx_kick_cpu(int nr)
+
{
unsigned long flags;
const u64 *cpu_rel_addr;
-__iomem u32 *bptr_vaddr;
+__iomem struct epapr_spin_table *epapr;
Please don't call this just epapr. That's like calling a reference to
any powerpc-specific struct powerpc.
How about spin_table?
You mean the name of the variable not the structure, right? I agree.
-out_be32(bptr_vaddr + BOOT_ENTRY_PIR, hw_cpu);
+out_be32(epapr-pir, hw_cpu);
#ifdef CONFIG_PPC32
-out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
+#ifdef CONFIG_HOTPLUG_CPU
+/* Corresponding to generic_set_cpu_dead() */
+generic_set_cpu_up(nr);
+
+if (system_state == SYSTEM_RUNNING) {
+out_be32(epapr-addr_l, 0);
+
+smp_85xx_set_bootpg((u32)(*cpu_rel_addr PAGE_SHIFT));
As previously requested, please document why you're setting the boot page
here. This should really be done when you resume from deep sleep, rather
than here, and should be a restoration of the value that the register held
prior to deep sleep.
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+.setup_cpu = smp_85xx_setup_cpu,
+#ifdef CONFIG_HOTPLUG_CPU
+.cpu_disable= generic_cpu_disable,
+.cpu_die= generic_cpu_die,
+#endif
Only fill these fields in on e500v1/v2, until we properly support e500mc.
Likewise in ppc_md.cpu_die and anywhere else we advertise this
functionality.
Is there a standard function call that can tell that it is an e500mc not legacy
e500?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, November 09, 2011 4:58 AM
To: Li Yang-R58472
Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
On 11/08/2011 04:05 AM, Li Yang-R58472 wrote:
Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
On 11/04/2011 07:31 AM, Zhao Chenhui wrote:
+static int is_corenet;
+static void __cpuinit smp_85xx_setup_cpu(int cpu_nr);
+
+#if defined(CONFIG_HOTPLUG_CPU) defined(CONFIG_PPC32)
Why PPC32?
Not sure if it is the same for e5500. E5500 support will be verified
later.
It's better to have 64-bit silently do nothing here?
+ flush_disable_L1();
You'll also need to take down L2 on e500mc.
Right. E500mc support is beyond this patch series. We will work on it
after the e500v2 support is finalized.
I saw some support with is_corenet... If we don't support e500mc, make
sure the code doesn't try to run on e500mc.
The is_corenet code is just a start of the e500mc support and is far from
complete.
This isn't an e500v2-only BSP you're putting the code into. :-)
Yes, I know. But it will take quite some time to perfect the support for
different type of cores. I'd like to make the effort into stages. We want to
push the e500v2 support in first and add support to newer cores later so that
we don't need to re-spin the patches again and again. And the upstream kernel
can get the PM functionality at least for e500v2 earlier. Anyway, we need to
update the title of the patch to be more specific on e500v2.
+ tmp = 0;
+ if (cpu_has_feature(CPU_FTR_CAN_NAP))
+ tmp = HID0_NAP;
+ else if (cpu_has_feature(CPU_FTR_CAN_DOZE))
+ tmp = HID0_DOZE;
Those FTR bits are for what we can do in idle, and can be cleared if
the user sets CONFIG_BDI_SWITCH.
It is powersave_nap variable shows what we can do in idle.
No, that shows what the user wants to do in idle.
I think it's correct to use the CPU_FTR_CAN_* macro as CPU capability.
This is 85xx-specific code. We always can, and want to, nap here (though
the way we enter nap will be different on e500mc and up) -- even if it's
broken to use it for idle (such as on p4080, which would miss doorbells as
wake events).
Ok. Will stick to Nap.
+static void __cpuinit smp_85xx_reset_core(int nr) {
+ __iomem u32 *vaddr, *pir_vaddr;
+ u32 val, cpu_mask;
+
+ /* If CoreNet platform, use BRR as release register. */
+ if (is_corenet) {
+ cpu_mask = 1 nr;
+ vaddr = ioremap(get_immrbase() + MPC85xx_BRR_OFF, 4);
+ } else {
+ cpu_mask = 1 (24 + nr);
+ vaddr = ioremap(get_immrbase() + MPC85xx_ECM_EEBPCR_OFF, 4);
+ }
Please use the device tree node, not get_immrbase().
The get_immrbase() implementation uses the device tree node.
I mean the guts node. get_immrbase() should be avoided where possible.
Ok. I got your point to use offset from guts.
Also, some people might care about latency to enter/exit deep sleep.
Searching through the device tree at this point (rather than on init)
slows that down.
Actually the get_immrbase() is smarter than you thought. :) It only search the
device tree on first call and returns the saved value on follow up calls.
+static int __cpuinit smp_85xx_map_bootpg(u32 page) {
+ __iomem u32 *bootpg_ptr;
+ u32 bptr;
+
+ /* Get the BPTR */
+ bootpg_ptr = ioremap(get_immrbase() + MPC85xx_BPTR_OFF, 4);
+
+ /* Set the BPTR to the secondary boot page */
+ bptr = MPC85xx_BPTR_EN | (page MPC85xx_BPTR_BOOT_PAGE_MASK);
+ out_be32(bootpg_ptr, bptr);
+
+ iounmap(bootpg_ptr);
+ return 0;
+}
Shouldn't the boot page already be set by U-Boot?
The register should be lost after a deep sleep. Better to do it again.
How can it be lost after a deep sleep if we're relying on it to hold our
wakeup code?
In order to wake up from deep sleep, the boot page has been set to the deep
sleep restoration function. We need to set it back to the bootpage from u-boot.
It's not better to do it again if we're making a bad assumption about
the code and the table being in the same page.
Currently we are reusing the whole boot page including the spin-table from
u-boot. Are you suggesting to move just the boot page to kernel?
local_irq_save(flags);
- out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
+ out_be32(epapr-pir, hw_cpu);
#ifdef CONFIG_PPC32
- out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
+#ifdef CONFIG_HOTPLUG_CPU
+ if (system_state == SYSTEM_RUNNING) {
+ out_be32(epapr-addr_l, 0);
+ smp_85xx_map_bootpg((u32)(*cpu_rel_addr PAGE_SHIFT));
Why is this inside PPC32?
Not tested on 64-bit yet. Might require a different implementation on
PPC64.
Please make a reasonable effort to do things in a way that works on both.
It shouldn't be a big deal to test that it doesn't break booting on p5020.
Will do. But in stages
RE: [PATCH 5/7] fsl_pmc: update device bindings
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, November 09, 2011 4:40 AM To: Li Yang-R58472 Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings On 11/08/2011 04:56 AM, Li Yang-R58472 wrote: diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt index 07256b7..d84b4f8 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt @@ -9,22 +9,27 @@ Properties: fsl,mpc8548-pmc should be listed for any chip whose PMC is compatible. fsl,mpc8536-pmc should also be listed for any chip - whose PMC is compatible, and implies deep-sleep capability. + whose PMC is compatible, and implies deep-sleep capability and + wake on user defined packet(wakeup on ARP). Why does the PMC care? This is an ethernet controller feature, the PMC is just keeping the wakeup-relevant parts of the ethernet controller alive (whatever they happen to be). Do we have any chips that have ethernet controller support for wake on user-defined packet, but a sleep mode that doesn't let it be used? I think it is more a PMC feature cause Ethernet controller on many SoCs have the filer feature, but only very limited SoCs can support using it as a wake-up source. The differences should be mostly in the PM controller block. Have you tried waking from sleep with it on those other SoCs? We have tried and it's not working. Although the filer is an eTSEC feature, waking up on it is really a complex system wide change including eTSEC, DDR, ECM, PIC, and etc. And currently it's tied up to deep sleep feature. So I would like it to be part of the SoC integration domain i.e. PMC. Also the wake on user-defined packet feature was never mentioned in the Ethernet controller part of UM. AFAICT all this feature is, is programming the Ethernet controller to filter out some packets that we don't want to wake us up, and then refraining from entering magic packet mode. What PMC registers are programmed any differently for this? It's in the PM part of the manual because that's where they generally describe issues related to PM. They describe magic packet there too. The set of devices which are still active during sleep is a different issue from the conditions on which a device will request a wake. I also don't trust our PM documentation very much. It's ambiguous just what gets shut down in ordinary sleep mode. E.g. the mpc8544 manual talks about external interrupts, but in one place it looks like it means external to the SoC: In sleep mode, all clocks internal to the e500 core are turned off, including the timer facilities clock. All I/O interfaces in the device logic are also shut down. Only the clocks to the MPC8544E PIC are still running so that an external interrupt can wake up the device. But the note immediately below that seems to imply they're talking about external to the core: Only external interrupts can wake the MPC8544E from sleep mode. Internal interrupt sources like the core interval timer or watchdog timer depend on an active clock for their operation and these are disabled in sleep mode. Normally that shouldn't matter, but we already an unused binding for this. :-) Please provide rationale for doing it this way. Ideally it should probably use whatever http://devicetree.org/ClockBindings ends up being. I have looked into that binding. The binding was primarily defined for the Linux clock API which is not same as what we are doing here(set wakeup source). If in the future the clock API also covers wakeup related features, we can change to use it. While Linux APIs can serve as an inspiration, they're not the basis of device tree bindings. The device tree is not Linux-specific, and should not change just because Linux changes, but rather should describe the hardware. We want to get this right the first time. What we are describing here is how a device's clock is connected to the PMC. AFAIKT, the purpose of defining the clock binding is used to describe the topology of clocks in a system. And then used for runtime control of enabling/disabling clocks or getting/changing clock frequencies. But in this PM case, we just set the wakeup capability and provide little runtime control of the clocks for on-chip devices. And it doesn't get any benefit of using this binding. If your concern is the confusion with the already existing clock binding, we can remove the clk in the name of the PM binding. If we are to use the clock binding, I think adding the CSB clock, DDR clock, core clock, and etc with this binding is more appropriate. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On
Behalf Of Scott Wood
Sent: Saturday, November 05, 2011 1:34 AM
To: Zhao Chenhui-B35336
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/7] powerpc/85xx: re-enable timebase sync disabled by
KEXEC patch
On 11/04/2011 07:29 AM, Zhao Chenhui wrote:
From: Li Yang le...@freescale.com
The timebase sync is not only necessary when using KEXEC. It should also
be used by normal boot up and cpu hotplug. Remove the ifdef added by
the KEXEC patch.
The KEXEC patch didn't just add the ifdef, it also added the initializers:
Yes. But the code suggests that the timebase synchronization is only necessary
for KEXEC, but it turns out that sleep/wakeup also need it. Maybe the
description of the patch need to be changed as KEXEC is not to be blamed.
@@ -105,8 +107,64 @@ smp_85xx_setup_cpu(int cpu_nr)
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+#ifdef CONFIG_KEXEC
+ .give_timebase = smp_generic_give_timebase,
+ .take_timebase = smp_generic_take_timebase,
+#endif
};
U-Boot synchronizes the timebase on 85xx. With what chip and U-Boot
version are you seeing this not happen?
I'm curious why don't we make it happen in kernel as we are against adding
dependency to the bootloader? Other architectures don't have this dependency,
it will be better if we don't add this dependency either IMO.
If you are seeing only a small (around one tick) difference, make sure
you're running a U-Boot that has this commit:
commit 7afc45ad7d9493208d89072cbb78a5bfc8034b59
Author: Kumar Gala ga...@kernel.crashing.org
Date: Sun Mar 13 10:55:53 2011 -0500
powerpc/85xx: Fix synchronization of timebase on MP boot
There is a small ordering issue in the master core in that we need
to
make sure the disabling of the timebase in the SoC is visible before
we
set the value to 0. We can simply just read back the value to
synchronizatize the write, before we set TB to 0.
Reported-by: Dan Hettena
Tested-by: Dan Hettena
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
On 11/04/2011 07:31 AM, Zhao Chenhui wrote:
From: Li Yang le...@freescale.com
Add support to disable and re-enable individual cores at runtime
on MPC85xx/QorIQ SMP machines. Currently support e500 core.
MPC85xx machines use ePAPR spin-table in boot page for CPU kick-off.
This patch uses the boot page from bootloader to boot core at runtime.
It supports 32-bit and 36-bit physical address.
Note that there is no guarantee that the bootloader can handle you
resetting a core. In ePAPR the spin table is a one-time release
mechanism, not a core reset mechanism. If this has a U-Boot dependency,
document that.
Actually we suggested to add a spin table in kernel so that we won't have the
dependency on u-boot. But there seems to be some opposite opinion in the
internal discussion. I personally prefer to remove the u-boot dependency and
add the mechanism in kernel.
#ifdef CONFIG_SMP
/* When we get here, r24 needs to hold the CPU # */
.globl __secondary_start
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 7bf2187..12a54f0 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -381,8 +381,14 @@ void generic_cpu_die(unsigned int cpu)
for (i = 0; i 100; i++) {
smp_rmb();
-if (per_cpu(cpu_state, cpu) == CPU_DEAD)
+if (per_cpu(cpu_state, cpu) == CPU_DEAD) {
+/*
+ * After another core sets cpu_state to CPU_DEAD,
+ * it needs some time to die.
+ */
+msleep(10);
return;
+}
msleep(100);
It would be better to do this as a call into platform-specific code than
can check registers to determine whether the core has checked out (in
our case, whether it has entered nap) -- or to do a suitable delay for
that platform if this isn't possible.
It will be easier if we can add a platform specific cpu_die instead of using
the generic one?
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 9b0de9c..5a54fc1 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -17,6 +17,7 @@
#include linux/of.h
#include linux/kexec.h
#include linux/highmem.h
+#include linux/cpu.h
#include asm/machdep.h
#include asm/pgtable.h
@@ -30,26 +31,141 @@
extern void __early_start(void);
-#define BOOT_ENTRY_ADDR_UPPER 0
-#define BOOT_ENTRY_ADDR_LOWER 1
-#define BOOT_ENTRY_R3_UPPER 2
-#define BOOT_ENTRY_R3_LOWER 3
-#define BOOT_ENTRY_RESV 4
-#define BOOT_ENTRY_PIR 5
-#define BOOT_ENTRY_R6_UPPER 6
-#define BOOT_ENTRY_R6_LOWER 7
-#define NUM_BOOT_ENTRY 8
-#define SIZE_BOOT_ENTRY (NUM_BOOT_ENTRY * sizeof(u32))
-
-static int __init
-smp_85xx_kick_cpu(int nr)
+#define MPC85xx_BPTR_OFF0x00020
+#define MPC85xx_BPTR_EN 0x8000
+#define MPC85xx_BPTR_BOOT_PAGE_MASK 0x00ff
+#define MPC85xx_BRR_OFF 0xe0e4
+#define MPC85xx_ECM_EEBPCR_OFF 0x01010
+#define MPC85xx_PIC_PIR_OFF 0x41090
+
+struct epapr_entry {
ePAPR is more than just the spin table. Call it something like
epapr_spin_table.
+u32 addr_h;
+u32 addr_l;
+u32 r3_h;
+u32 r3_l;
+u32 reserved;
+u32 pir;
+u32 r6_h;
+u32 r6_l;
+};
Get rid of r6, it is not part of the ePAPR spin table.
Agree.
+static int is_corenet;
+static void __cpuinit smp_85xx_setup_cpu(int cpu_nr);
+
+#if defined(CONFIG_HOTPLUG_CPU) defined(CONFIG_PPC32)
Why PPC32?
Not sure if it is the same for e5500. E5500 support will be verified later.
+extern void flush_disable_L1(void);
If this isn't already in a header file, put it in one.
+static void __cpuinit smp_85xx_mach_cpu_die(void)
+{
+unsigned int cpu = smp_processor_id();
+register u32 tmp;
+
+local_irq_disable();
+idle_task_exit();
+generic_set_cpu_dead(cpu);
+smp_wmb();
+
+mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
+mtspr(SPRN_TCR, 0);
If clearing TSR matters at all (I'm not sure that it does), first clear
TCR, then TSR.
+flush_disable_L1();
You'll also need to take down L2 on e500mc.
Right. E500mc support is beyond this patch series. We will work on it after
the e500v2 support is finalized.
+tmp = 0;
+if (cpu_has_feature(CPU_FTR_CAN_NAP))
+tmp = HID0_NAP;
+else if (cpu_has_feature(CPU_FTR_CAN_DOZE))
+tmp = HID0_DOZE;
Those FTR bits are for what we can do in idle, and can be cleared if the
user sets CONFIG_BDI_SWITCH.
It is powersave_nap variable shows what we can do in idle. I think it's
correct to use the CPU_FTR_CAN_* macro as CPU capability.
On 85xx we always want to nap here, and at least on e500mc
RE: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
To: Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support Hi Zhao, From: Li Yang leoli at freescale.com Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode in addtion to the sleep PM mode. In sleep PM mode, the clocks of e500 core and unused IP blocks is turned off. IP blocks which are allowed to wake up the processor are still running While in deep sleep PM mode, additionally, the power supply is removed from e500 core and most IP blocks. Only the blocks needed to wake up the chip out of deep sleep are ON. This patch supports 32-bit and 36-bit address space. The deep sleep mode is equal to the Suspend-to-RAM state of Linux Power Management. Command to enter deep sleep mode. echo mem /sys/power/state Thanks a lot for bringing this code to mainline. I was recently involved in enabling deep sleep on a custom P1022 board, and would like to make some remarks based on this experience. 1. I think 85xx deep sleep code would be more complete if you also port FSL BSP code that saves eLBC configuration before entering deep sleep and restores it afterwards. Otherwise all eLBC customization done by u- boot is lost. Thanks for the comment. That work is also being considered for upstream, but not in this series. 2. You should implement fsl_deep_sleep() routine for 85xx. The default implementation in include/linux/fsl_devices.h always returns 0. The routine is used by FSL USB host driver, drivers/usb/host/ehci-fsl.c to restore USB hardware state after deep sleep. With default implementation USB is dead on 85xx after deep sleep if USB PHY is powered down completely. Added to the to-do list. Thanks. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
Subject: Re: [PATCH 3/7] powerpc/85xx: add sleep and deep sleep support
On 11/04/2011 07:33 AM, Zhao Chenhui wrote:
+/* Cast the ccsrbar to 64-bit parameter so that the assembly
+ * code can be compatible with both 32-bit 36-bit */
+extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
/*
* Please use proper
* Linux multi-line comment format.
*/
static int pmc_suspend_enter(suspend_state_t state)
{
int ret;
+u32 powmgtreq = 0x0050;
Where does this 0x0050 come from? Please symbolically define
individual bits.
The comment in the asm code says it should be 0x0010, BTW.
I think we should get rid of the powmgtreq argument, as we don't support
multiple modes for mpc85xx_enter_deep_sleep() now.
+
+switch (state) {
+case PM_SUSPEND_MEM:
+#ifdef CONFIG_SPE
+enable_kernel_spe();
+#endif
Should comment that currently only e500v2 hardware supports deep sleep
-- else we'd need to save normal FP here.
+pr_debug(Entering deep sleep\n);
+
+local_irq_disable();
+mpc85xx_enter_deep_sleep(get_immrbase(),
+powmgtreq);
+pr_debug(Resumed from deep sleep\n);
+
+return 0;
+
+/* else fall-through */
+case PM_SUSPEND_STANDBY:
What fall-through? You just returned.
+}
-/* Upon resume, wait for SLP bit to be clear. */
-ret = spin_event_timeout((in_be32(pmc_regs-pmcsr) PMCSR_SLP) ==
0,
- 1, 10) ? 0 : -ETIMEDOUT;
-if (ret)
-dev_err(pmc_dev, tired waiting for SLP bit to clear\n);
-return ret;
}
Remove that blank line as well.
@@ -58,13 +101,23 @@ static const struct platform_suspend_ops
pmc_suspend_ops = {
.enter = pmc_suspend_enter,
};
-static int pmc_probe(struct platform_device *ofdev)
+static int pmc_probe(struct platform_device *pdev)
{
-pmc_regs = of_iomap(ofdev-dev.of_node, 0);
+struct device_node *np = pdev-dev.of_node;
+
+pmc_regs = of_iomap(pdev-dev.of_node, 0);
if (!pmc_regs)
return -ENOMEM;
-pmc_dev = ofdev-dev;
+has_deep_sleep = 0;
+if (of_device_is_compatible(np, fsl,mpc8536-pmc))
+has_deep_sleep = 1;
+
+has_lossless = 0;
+if (of_device_is_compatible(np, fsl,p1022-pmc))
+has_lossless = 1;
+
You never use has_lossless.
It will be used in the later patch in the series.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/7] fsl_pmc: update device bindings
-Original Message- From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of Scott Wood Sent: Saturday, November 05, 2011 4:05 AM To: Zhao Chenhui-B35336 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings On 11/04/2011 07:36 AM, Zhao Chenhui wrote: From: Li Yang le...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- .../devicetree/bindings/powerpc/fsl/pmc.txt| 63 +++-- -- 1 files changed, 36 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt index 07256b7..d84b4f8 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt @@ -9,22 +9,27 @@ Properties: fsl,mpc8548-pmc should be listed for any chip whose PMC is compatible. fsl,mpc8536-pmc should also be listed for any chip - whose PMC is compatible, and implies deep-sleep capability. + whose PMC is compatible, and implies deep-sleep capability and + wake on user defined packet(wakeup on ARP). Why does the PMC care? This is an ethernet controller feature, the PMC is just keeping the wakeup-relevant parts of the ethernet controller alive (whatever they happen to be). Do we have any chips that have ethernet controller support for wake on user-defined packet, but a sleep mode that doesn't let it be used? I think it is more a PMC feature cause Ethernet controller on many SoCs have the filer feature, but only very limited SoCs can support using it as a wake-up source. The differences should be mostly in the PM controller block. Also the wake on user-defined packet feature was never mentioned in the Ethernet controller part of UM. BTW, please remove fsl,mpc8536-pmc from the p1023rds device tree -- it was wrong before (no deep sleep, though it does appear to have jog mode...), and is even more wrong with this provision (it has a different ethernet controller). + fsl,p1022-pmc should be listed for any chip whose PMC is + compatible, and implies lossless Ethernet capability during sleep. fsl,mpc8641d-pmc should be listed for any chip whose PMC is compatible; all statements below that apply to fsl,mpc8548-pmc also apply to fsl,mpc8641d-pmc. Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these - bit assignments are indicated via the sleep specifier in each device's - sleep property. + bit assignments are indicated via the clock nodes. Device which has a + controllable clock source should have a clk-handle property pointing + to the clock node. Do we have any code to use this? Yes, in another patch in the series. Normally that shouldn't matter, but we already an unused binding for this. :-) Please provide rationale for doing it this way. Ideally it should probably use whatever http://devicetree.org/ClockBindings ends up being. I have looked into that binding. The binding was primarily defined for the Linux clock API which is not same as what we are doing here(set wakeup source). If in the future the clock API also covers wakeup related features, we can change to use it. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 7/7] gianfar: add support for wake-on-packet
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On
Behalf Of Scott Wood
Sent: Saturday, November 05, 2011 5:14 AM
To: Zhao Chenhui-B35336
Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Fleming Andy-
AFLEMING
Subject: Re: [PATCH 7/7] gianfar: add support for wake-on-packet
On 11/04/2011 04:11 PM, Scott Wood wrote:
On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
static int gfar_suspend(struct device *dev) { @@ -1268,9 +1443,17
@@ static int gfar_suspend(struct device *dev)
struct gfar __iomem *regs = priv-gfargrp[0].regs;
unsigned long flags;
u32 tempval;
-
int magic_packet = priv-wol_en
- (priv-device_flags FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+ (priv-wol_opts GIANFAR_WOL_MAGIC);
+ int arp_packet = priv-wol_en
+ (priv-wol_opts GIANFAR_WOL_ARP);
+
+ if (arp_packet) {
+ pmc_enable_wake(priv-ofdev, PM_SUSPEND_MEM, 1);
+ pmc_enable_lossless(1);
+ gfar_arp_suspend(ndev);
+ return 0;
+ }
How do we know this isn't standby?
Or suspend to disk, for that matter?
There is nothing we can do for hibernation. The whole system is literally off.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event source
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On
Behalf Of Scott Wood
Sent: Saturday, November 05, 2011 5:14 AM
To: Zhao Chenhui-B35336
Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 6/7] fsl_pmc: Add API to enable device as wakeup event
source
On 11/04/2011 07:39 AM, Zhao Chenhui wrote:
@@ -45,6 +46,72 @@ static int has_lossless;
* code can be compatible with both 32-bit 36-bit */ extern void
mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
+#ifdef CONFIG_FSL_PMC
+/**
+ * pmc_enable_wake - enable OF device as wakeup event source
+ * @pdev: platform device affected
+ * @state: PM state from which device will issue wakeup events
+ * @enable: True to enable event generation; false to disable
+ *
+ * This enables the device as a wakeup event source, or disables it.
+ *
+ * RETURN VALUE:
+ * 0 is returned on success
+ * -EINVAL is returned if device is not supposed to wake up the
+system
+ * Error code depending on the platform is returned if both the
+platform and
+ * the native mechanism fail to enable the generation of wake-up
+events */ int pmc_enable_wake(struct platform_device *pdev,
+suspend_state_t state, bool enable)
pmc is too generic for a global function. If this can be either enable
or disable, perhaps it should be something like mpc85xx_pmc_set_wake().
+{
+int ret = 0;
+struct device_node *clk_np;
+u32 *pmcdr_mask;
+
+if (!pmc_regs) {
+printk(KERN_WARNING PMC is unavailable\n);
+return -ENOMEM;
+}
-ENOMEM is not appropriate here, maybe -ENODEV?
Should print __func__ so the user knows what's complaining.
+if (enable !device_may_wakeup(pdev-dev))
+return -EINVAL;
+
+clk_np = of_parse_phandle(pdev-dev.of_node, clk-handle, 0);
+if (!clk_np)
+return -EINVAL;
+
+pmcdr_mask = (u32 *)of_get_property(clk_np, fsl,pmcdr-mask, NULL);
+if (!pmcdr_mask) {
+ret = -EINVAL;
+goto out;
+}
+
+/* clear to enable clock in low power mode */
+if (enable)
+clrbits32(pmc_regs-pmcdr, *pmcdr_mask);
+else
+setbits32(pmc_regs-pmcdr, *pmcdr_mask);
We should probably initialize PMCDR to all bits set (or at least all ones
we know are valid) -- the default should be not a wakeup source.
Ideally I agree with you. But currently we only have the UI of changing
wake-up source for Ethernet device. Will do when we can change all of the
devices.
+/**
+ * pmc_enable_lossless - enable lossless ethernet in low power mode
+ * @enable: True to enable event generation; false to disable */
+void pmc_enable_lossless(int enable) {
+if (enable has_lossless)
+setbits32(pmc_regs-pmcsr, PMCSR_LOSSLESS);
+else
+clrbits32(pmc_regs-pmcsr, PMCSR_LOSSLESS); }
+EXPORT_SYMBOL_GPL(pmc_enable_lossless);
+#endif
Won't we overwrite this later?
You are right. Will remove the code that overwrite this.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 7/7] gianfar: add support for wake-on-packet
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On
Behalf Of Scott Wood
Sent: Saturday, November 05, 2011 5:12 AM
To: Zhao Chenhui-B35336
Cc: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Fleming Andy-
AFLEMING
Subject: Re: [PATCH 7/7] gianfar: add support for wake-on-packet
On 11/04/2011 07:40 AM, Zhao Chenhui wrote:
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 2c6be03..543e36c 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -56,6 +56,9 @@ Properties:
hardware.
- fsl,magic-packet : If present, indicates that the hardware supports
waking up via magic packet.
+ - fsl,wake-on-filer : If present, indicates that the hardware
supports
+waking up via arp request to local ip address or unicast packet to
+local mac address.
Is there any way to determine this at runtime via the device's registers?
I think TSEC_ID2[TSEC_CFG] can be used. The manual describes it
awkwardly, but it looks like 0x20 is the bit for the filer.
That bit only defines the filer feature but not wakeup on it. Another solution
is to get the capability from the fsl_pmc driver, but will make the driver a
lot more complex.
@@ -751,7 +764,6 @@ static int gfar_of_init(struct platform_device
*ofdev, struct net_device **pdev)
FSL_GIANFAR_DEV_HAS_PADDING |
FSL_GIANFAR_DEV_HAS_CSUM |
FSL_GIANFAR_DEV_HAS_VLAN |
-FSL_GIANFAR_DEV_HAS_MAGIC_PACKET |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH |
FSL_GIANFAR_DEV_HAS_TIMER;
This is an unrelated change. Are there any eTSECs that don't support
magic packet?
I'm not sure. But as we have the property for it in device tree, we use it.
+static int gfar_get_ip(struct net_device *dev)
+{
+struct gfar_private *priv = netdev_priv(dev);
+struct in_device *in_dev = (struct in_device *)dev-ip_ptr;
+struct in_ifaddr *ifa;
+
+if (in_dev != NULL) {
+ifa = (struct in_ifaddr *)in_dev-ifa_list;
+if (ifa != NULL) {
+memcpy(priv-ip_addr, ifa-ifa_address, 4);
+return 0;
+}
+}
+return -ENOENT;
+}
Unnecessary cast, ifa_list is already struct in_ifaddr *.
Better, use for_primary_ifa(), and document that you won't wake on ARP
packets for secondary IP addresses.
static int gfar_suspend(struct device *dev)
{
@@ -1268,9 +1443,17 @@ static int gfar_suspend(struct device *dev)
struct gfar __iomem *regs = priv-gfargrp[0].regs;
unsigned long flags;
u32 tempval;
-
int magic_packet = priv-wol_en
-(priv-device_flags FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+(priv-wol_opts GIANFAR_WOL_MAGIC);
+int arp_packet = priv-wol_en
+(priv-wol_opts GIANFAR_WOL_ARP);
+
+if (arp_packet) {
+pmc_enable_wake(priv-ofdev, PM_SUSPEND_MEM, 1);
+pmc_enable_lossless(1);
+gfar_arp_suspend(ndev);
+return 0;
+}
How do we know this isn't standby?
Maybe we can remove the PM state parameter from the API.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
-Original Message- From: Liu Shuo-B35362 Sent: Tuesday, July 12, 2011 12:49 PM To: dw...@infradead.org Cc: linux-...@lists.infradead.org; linuxppc-...@ozlabs.org; Liu Shuo- B35362; Li Yang-R58472 Subject: [PATCH v2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip From: Liu Shuo b35...@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we divide a page into multi-2K pages for MTD layer driver. In that case, we force to set the page size to 2K bytes. We convert the page address of MTD layer driver to a real page address in flash chips and a column index in fsl_elbc driver. We can issue any column address by UA instruction of elbc controller. Signed-off-by: Liu Shuo b35...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- Hi David and Artem, We have fixed the multi-line comment style problem. Could you help to pick the patch? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
答复: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt handler for sRIO.
Hi Alex, Just for your information as you mentioned about it. The dual port support is being worked on, but not likely to be ready in this merge window. - Leo 发件人: Bounine, Alexandre [alexandre.boun...@idt.com] 发送时间: 2011年5月20日 21:18 到: Kumar Gala Cc: Li Yang-R58472; Xie Shaohui-B21989; Zang Roy-R61911; a...@linux-foundation.org; linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780 主题: RE: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt handler for sRIO. Not at all. I tested it earlier and it works for me on 8548 platform. -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Friday, May 20, 2011 8:42 AM To: Bounine, Alexandre Cc: Li Yang-R58472; Xie Shaohui-B21989; Zang Roy-R61911; akpm@linux- foundation.org; linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780 Subject: Re: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt handler for sRIO. Any reason for me not to apply this and send it upstream for now? - k On May 20, 2011, at 7:14 AM, Bounine, Alexandre wrote: Kumar, Are you planning to release support for dual-port SRIO controller? If yes, it may be just merged into it (unless dual-port implementation already has it). Alex. -Original Message- From: linuxppc-dev- bounces+alexandre.bounine=idt@lists.ozlabs.org [mailto:linuxppc-dev- bounces+alexandre.bounine=idt@lists.ozlabs.org] On Behalf Of Kumar Gala Sent: Friday, May 20, 2011 12:29 AM To: Bounine, Alexandre Cc: Li Yang-R58472; Xie Shaohui-B21989; Zang Roy-R61911; akpm@linux- foundation.org; linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780 Subject: Re: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt handler for sRIO. Alex, What are we doing with this patch? - k On Dec 3, 2010, at 12:04 PM, Bounine, Alexandre wrote: I think they should follow the previous two that are in Kumar's tree. Probably Kumar may give you a better timeline estimate for this. Alex. From: linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org [mailto:linuxppc-dev- bounces+alexandre.bounine=idt@lists.ozlabs.org] On Behalf Of Xie Shaohui-B21989 Sent: Thursday, December 02, 2010 10:29 PM To: Bounine, Alexandre; linuxppc-dev@lists.ozlabs.org Cc: a...@linux-foundation.org; Gala Kumar-B11780; Li Yang-R58472; Zang Roy-R61911 Subject: RE: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt handler for sRIO. Hi Alex, May I ask when would these patches be applied to mainline? Best Regards, Shaohui Xie From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com] Sent: Wednesday, December 01, 2010 4:49 AM To: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org Cc: a...@linux-foundation.org; Li Yang-R58472; Gala Kumar-B11780; Zang Roy-R61911 Subject: RE: [PATCH 2/2][v3] rapidio, powerpc/85xx: Error interrupt handler for sRIO. Applies correctly now. Lab tested on 8548/RIO setup. Alex. -Original Message- From: Shaohui Xie [mailto:b21...@freescale.com] Sent: Thursday, November 18, 2010 1:58 AM To: linuxppc-dev@lists.ozlabs.org Cc: a...@linux-foundation.org; Shaohui Xie; Li Yang; Kumar Gala; Roy Zang; Bounine, Alexandre Subject: [PATCH 2/2][v3] rapidio, powerpc/85xx: Error interrupt handler for sRIO. The sRIO controller reports errors to the core with one signal, it uses register EPWISR to provides the core quick access to where the error occurred. The EPWISR indicates that there are 4 interrupts sources, port1, port2, message unit and port write receive, but the sRIO driver does not support port2 for now, still the handler takes care of port2. Currently the handler only clear error status without any recovery. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig
Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig On Thu, 12 May 2011 10:31:08 -0500 Scott Wood scottw...@freescale.com wrote: On Thu, 12 May 2011 01:11:03 -0500 Li Yang-R58472 r58...@freescale.com wrote: diff --git a/arch/powerpc/configs/e55xx_smp_defconfig b/arch/powerpc/configs/e55xx_smp_defconfig index 9fa1613..f4c5780 100644 --- a/arch/powerpc/configs/e55xx_smp_defconfig +++ b/arch/powerpc/configs/e55xx_smp_defconfig @@ -6,10 +6,10 @@ CONFIG_NR_CPUS=2 CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_SPARSE_IRQ=y Hi Scott, I remember in previous testing that this option has a negative effect on performance. Do we really need it to be enabled? I didn't change this setting, it just moved due to running it through savedefconfig. What was the performance impact? It adds CPU cycles to the interrupt handling path. Will cause performance drop for benchmarks with large amount of interrupts such as IP forwarding. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig
Subject: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig Even though support for the p5020's on-chip ethernet is not yet upstream, it is not appropriate to disable all networking support (including loopback, unix domain sockets, external ethernet devices, etc) in the defconfig. The networking settings are taken from mpc85xx_smp_defconfig, minus the drivers for ethernet devices not found on any current e5500 chip. The other changes are the result of running make savedefconfig. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/configs/e55xx_smp_defconfig | 38 ++--- 1 files changed, 29 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/configs/e55xx_smp_defconfig b/arch/powerpc/configs/e55xx_smp_defconfig index 9fa1613..f4c5780 100644 --- a/arch/powerpc/configs/e55xx_smp_defconfig +++ b/arch/powerpc/configs/e55xx_smp_defconfig @@ -6,10 +6,10 @@ CONFIG_NR_CPUS=2 CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_SPARSE_IRQ=y Hi Scott, I remember in previous testing that this option has a negative effect on performance. Do we really need it to be enabled? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RapidIO: multiple mport support for QorIQ
Subject: RapidIO: multiple mport support for QorIQ I'm planning to add support for the multiple(2) mports supported by the Freescale p2020 processor. I'm currently looking at the fsl layer to add in support for multiple port enumeration, and work up from there. It looks like the upper layers already have at least partial support for this. My question is, are there any efforts already ongoing I can hop in on so as not to duplicate effort? If not, I'll just do it. I'm not aware of someone working on that. There is some divergance in respect to the memory map that is non-trivial that I'm not sure how to handle, since it totally hoses the common fsl_rio.c structures. I think I want to create a new set that's p2020 specific, but has potential to be shared with the other QorIQ series, so dumping the pseries-specific code into platforms/pseries seems like a reasonable way to go. Thoughts? The dual-port RIO is very common on QorIQ chips. I won't suggest you add P2020 specific memory map file. The two port memory map should also be compatible with one port driver. -Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
On Thu, 2010-12-09 at 17:20 -0800, Mark Pearson wrote: Magical - thank you very very much. The patch fixes the problem Really appreciate the quick response - and I would never have found that in a million years. No worries. Looks like someone should send 78e2e68a2b to the stable crew. FSL guys? I think it has already been sent to the sta...@kernel.org. Not sure if it has been included though. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ucc_geth: transmit queue timeout at half-duplex mode
Subject: ucc_geth: transmit queue timeout at half-duplex mode Hi all, on my MPC8321E with linux-2.6.36 I get this netdev watchdog warning NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out if the link mode is half-duplex. The warning is caused, because all Tx BDs are full and packet transmission is stopped with netif_stop_queue() in ucc_geth_start_xmit(). You can reproduce the bug in the following way: - Connect to a switch, that supports only 10baseT, or set the mode manually with mii-diag -F 10baseT. - Open a telnet session to the target. Generate higher traffic with executing maybe cat /proc/interrupts many times. - After some tries the ethernet connection will be down, then again after approx. 30s seconds the netdev watchdog will dump the warning. It is unclear to me why the TxBDs get full. Due to missing Tx buffer sent interrupts, it seems that the QE stops the transmission. I found some issue in the errata: QE_ENET20: UEC may stop transmitting after late collision. But UCCE[TXE] is never set in this case. Thank you for your help in advance and best regards, I believe your problem is related to an errata for 8321: High Tx Virtual FIFO threshold size can cause UCC to halt. Reducing the UTFTT might fix the problem. If you are interested, I can sent you the detailed errata off the thread. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] fsldma: add support to 36-bit physical address
Subject: Re: [PATCH v2] fsldma: add support to 36-bit physical address On Nov 11, 2010, at 6:16 AM, Li Yang wrote: Expand the dma_mask of fsldma device to 36-bit, indicating that the DMA engine can deal with 36-bit physical address and does not need the SWIOTLB to create bounce buffer for it when doing dma_map_*(). Signed-off-by: Li Yang le...@freescale.com --- Add more detailed commit message drivers/dma/fsldma.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index cea08be..8c79b37 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -1,7 +1,7 @@ /* * Freescale MPC85xx, MPC83xx DMA Engine support * - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved. + * Copyright (C) 2007-2010 Freescale Semiconductor, Inc. All rights reserved. * * Author: * Zhang Wei wei.zh...@freescale.com, Jul 2007 @@ -1338,6 +1338,8 @@ static int __devinit fsldma_of_probe(struct platform_device *op, fdev-common.device_control = fsl_dma_device_control; fdev-common.dev = op-dev; +dma_set_mask((op-dev), DMA_BIT_MASK(36)); + Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block programming model allows the address to be 64-bits? The current code is only verified on chips with 36-bit physical address. I'm not sure if the driver can work without any change on the 64-bit chip, although the register model suggests it can work well with 64-bit. If you can confirm that it's compatible with the block on 64-bit chip, then we can change it to 64 bit dma mask. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote: From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif -/* Ensure that RFXE is set */ -mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC +/* Ensure that RFXE is set on e500 v1/v2 */ +mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /* +!PPC_E500MC */ #endif /* E500 */ I've never really been happy with this code. We really should set HID1_RFXE in cpu_setup_fsl_booke.S instead. But this bit is not recommended to be set unless necessary. And it is only required by SRIO for now. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
Subject: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access From: Li Yang le...@freescale.com The access to HID1 register is only legitimate for e500 v1/v2 cores. Also fixes magic number. Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Shaohui Xie b21...@freescale.com This patch is depending on another patch at http://patchwork.ozlabs.org/patch/56138/ - Leo --- arch/powerpc/sysdev/fsl_rio.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644 --- a/arch/powerpc/sysdev/fsl_rio.c +++ b/arch/powerpc/sysdev/fsl_rio.c @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device *dev) #ifdef CONFIG_E500 saved_mcheck_exception = ppc_md.machine_check_exception; ppc_md.machine_check_exception = fsl_rio_mcheck_exception; -#endif - /* Ensure that RFXE is set */ - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x2)); + +#ifndef CONFIG_PPC_E500MC + /* Ensure that RFXE is set on e500 v1/v2 */ + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); +#endif /* !PPC_E500MC */ +#endif /* E500 */ return 0; err: -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 1/4] fsl_rio: fix compile errors
Subject: Re: [PATCH v2 1/4] fsl_rio: fix compile errors On Aug 31, 2010, at 10:40 PM, Li Yang wrote: On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala ga...@kernel.crashing.org wrote: On Jun 18, 2010, at 1:24 AM, Li Yang wrote: Fixes the following compile problem on E500 platforms: arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception': arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first use in this function) Also fixes the compile problem on non-E500 platforms. Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/sysdev/fsl_rio.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) applied to merge Thanks, Kumar. How about the other ones in the series? I want to rework how the whole RIO mcheck works and will do so for 2.6.37. Part of the problem I have is that we are ignoring the fact that this code isn't right for 8641 support of SRIO. Right. So I protected the code with #ifdef CONFIG_E500. The following patches in series enable it to be used by e500mc. Having it to support all platforms is surely the best, but before that we can make it better. And I believe they wouldn't get in the way of further MPC8641 support. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Review Request: New proposal for device tree clock binding.
tt*-clock/tt is named for the signal name for the ''clock input''
of the device. it should describe the function of the signal for that
device, rather than the name of the system-wide clock line. For
example, a UART with two clocks - one for baud-rate clocking, and the
other for register clocking - may have clock input properties named
baud-clock and register-clock. The property value is a tuple
containing the phandle to the clock provider and the name of the clock
output signal.
For example:
uart {
baud-clock = osc, ckil;
register-clock = ref, bus;
};
This represents a device with two clock inputs, named baud and
register. The baud clock is connected to the ckil output of the
osc
device, and the register clock is connected to the bus output of the
ref device.
Instead of having two items to identify a clock, I would suggest to have
a node for each clock. So that clock can be referenced by one
handle. Also we can have clock specific information defined in the clock
node. Here is the example I am planning to use on 85xx PMC.
po...@e0070{
compatible = fsl,mpc8548-pmc,
fsl,p2020-pmc;
reg = 0xe0070 0x20;
etsec1_clk: soc-...@24{
fsl,pmcdr-mask = 0x0080;
};
etsec2_clk: soc-...@25{
fsl,pmcdr-mask = 0x0040;
};
etsec3_clk: soc-...@26{
fsl,pmcdr-mask = 0x0020;
};
};
enet0: ether...@24000 {
..
master-clock = etsec1_clk;
..
What do you think?
Quoting your reply:
I've avoided requiring clock nodes to have a separate sub node for
each output because it is more verbose and it prevents clock providers
from having child nodes for other purposes. Are you concerned that
I don't see why there should be child nodes for other purposes under clock node.
having the phandle+output name pair will be difficult to manage?
That's part of my concern. But my main concern is the inability of describing
the properties of each clock in the device tree. The clock stuff is much SoC
related, which means it could be variable among chips even in a same family.
Having clock properties defined in device tree will make it easier to have an
abstracted driver to handle clock operations. That's why device trees are used
in the first place, right?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Review Request: New proposal for device tree clock binding.
I've avoided requiring clock nodes to have a separate sub node for each output because it is more verbose and it prevents clock providers from having child nodes for other purposes. Are you concerned that I don't see why there should be child nodes for other purposes under clock node. having the phandle+output name pair will be difficult to manage? That's part of my concern. I was concerned about this too until I found precedence for doing the exact same thing in the pci binding (and ePAPR). Mixing phandle and a string in this way doesn't bother me anymore. Where exactly can I get the sample code for handling this binding? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Review Request: New proposal for device tree clock binding.
It looks like the previous sending didn't hit the mailing list. Resend.
Hi Grant,
I have some comment on this proposal.
Subject: Review Request: New proposal for device tree clock binding.
Hi Ben (well, hello to everyone, but I'm particularly interested in
Ben's feedback),
Jeremy and I have been kicking around the clock binding, and we've come
up with a new proposal that doesn't feel quite as forced to me.
Please take a look and let me know what you think. The link to the
binding is below[1], but I've also copied the full text so that you can
reply and comment. The rational for the new binding can be found in
talk page[2].
[1] http://www.devicetree.org/ClockBindings
[2] http://www.devicetree.org/Talk:ClockBindings
---
This page descibes the proposed OF clock bindings. These are a work-in-
progress, and are based on some
[http://patchwork.ozlabs.org/patch/31551/
experimental work by benh].
==Clock providers==
Sources of clock signal can be represented by any node in the device tree.
A mandatory ttclock-outputs/tt property describes the clock
outputs from this device.
{|border=1
!property
!format
!notes
|-
|ttclock-outputs/tt
|list of strings
|specifies output clock signal names.
|}
For example:
oscillator {
clock-outputs = ckil, ckih;
};
- this node defines a device with two clock outputs, the first named
ckil and the second named ckih. Consumer nodes always reference
clocks by name. The names should reflect the clock output signal names
for the device.
==Clock consumers==
A device connected to a clock signal needs a *-clock property for each
clock that it is connected to.
{|border=1
!property
!format
!notes
|-
|tt*-clock/tt
|1 cell phandle to the clock provider, followed by a string containing
the clock output name.
|The name of this property should be the name of the clock input
signal with a -clock suffix.
|}
tt*-clock/tt is named for the signal name for the ''clock input''
of the device. it should describe the function of the signal for that
device, rather than the name of the system-wide clock line. For
example, a UART with two clocks - one for baud-rate clocking, and the
other for register clocking - may have clock input properties named
baud-clock and register-clock. The property value is a tuple
containing the phandle to the clock provider and the name of the clock output
signal.
For example:
uart {
baud-clock = osc, ckil;
register-clock = ref, bus;
};
This represents a device with two clock inputs, named baud and
register. The baud clock is connected to the ckil output of the osc
device, and the register clock is connected to the bus output of the
ref device.
Instead of having two items to identify a clock, I would suggest to have a node
for each clock. So that clock can be referenced by one handle. Also we can
have clock specific information defined in the clock node. Here is the example
I am planning to use on 85xx PMC.
po...@e0070{
compatible = fsl,mpc8548-pmc, fsl,p2020-pmc;
reg = 0xe0070 0x20;
etsec1_clk: soc-...@24{
fsl,pmcdr-mask = 0x0080;
};
etsec2_clk: soc-...@25{
fsl,pmcdr-mask = 0x0040;
};
etsec3_clk: soc-...@26{
fsl,pmcdr-mask = 0x0020;
};
};
enet0: ether...@24000 {
..
master-clock = etsec1_clk;
..
What do you think?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
Subject: [PATCH] RapidIO,powerpc/85xx: remove MCSR_MASK in fsl_rio
Fixes compile problem caused by MCSR_MASK removal from book-E definitions.
Hi Alex,
Only with your patch, there will still be problem on SRIO platforms other than
MPC85xx.
I have posted a patch series to fix this together with several compatibility
issues a month before.
http://patchwork.ozlabs.org/patch/56135/
http://patchwork.ozlabs.org/patch/56136/
http://patchwork.ozlabs.org/patch/56138/
http://patchwork.ozlabs.org/patch/56137/
Can anyone pick the patch series quickly as currently there is a compile error
when SRIO is enabled.
- Leo
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Matt Porter mpor...@kernel.crashing.org
---
arch/powerpc/sysdev/fsl_rio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 30e1626..c58df58 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -245,7 +245,7 @@ static int (*saved_mcheck_exception)(struct pt_regs
*regs); static int fsl_rio_mcheck_exception(struct pt_regs *regs) {
const struct exception_table_entry *entry = NULL;
- unsigned long reason = (mfspr(SPRN_MCSR) MCSR_MASK);
+ unsigned long reason = mfspr(SPRN_MCSR);
if (reason MCSR_BUS_RBERR) {
reason = in_be32((u32 *)(rio_regs_win + RIO_LTLEDCSR));
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: CONFIG_NO_HZ causing poor console responsiveness
-Original Message- From: linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+leoli=freescale@lists.ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Friday, July 02, 2010 1:47 PM To: Tabi Timur-B04825 Cc: Linuxppc-dev Development Subject: Re: CONFIG_NO_HZ causing poor console responsiveness On Tue, 2010-06-29 at 14:54 -0500, Timur Tabi wrote: I'm adding support for a new e500-based board (the P1022DS), and in the process I've discovered that enabling CONFIG_NO_HZ (Tickless System / Dynamic Ticks) causes significant responsiveness problems on the serial console. When I type on the console, I see delays of up to a half-second for almost every character. It acts as if there's a background process eating all the CPU. I don't have time to debug this thoroughly at the moment. The problem occurs in the latest kernel, but it appears not to occur in 2.6.32. Has anyone else seen anything like this? I noticed that on the bimini with 2.6.35-rc* though I didn't get to track it down yet. Patch found at the following location fixed this problem. http://www.spinics.net/lists/linux-tip-commits/msg08279.html Hope it has already been merged. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Page fault on vmalloc'ed memory
Hi all, I got a weird page fault oops on vmalloc'ed area. Digging into the powerpc do_page_fault(), I found there is no handling of address in kernel space unlike the x86 counter part. Does any one know how we deal with the vmalloc'ed area on powerpc? Thanks a lot. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote: Kumar Gala wrote: Changes with respect to v1 as per comments received o. Rebased to linux-next as of 20091216 o. The selection is based exclusive of fsldma o. Intoduced a new Kernel Configuration variable *. This enables selecting the Cryptographic functionality of Talitos along with fsldma. *. Disables the XOR parity calculation offload, if fsldma enabled either as kernel in-built or as a module *. Once the inter-operability with fsldma is resolved, this option can be removed wait, why can't the interoperability bug be fixed in the first place? I agree w/Kim. We need to better understand what the bug is and how to reproduce it so we can get to the root cause. Paper taping over it by disabling fsldma is not the right solution. Hopefully this prompts fsldma authors to get involved because the interoperability issue has been out there without comment*, just band-aids, since October. -- Dan * well one comment from Ira saying the interrupt functionality worked for him. Yes, I have used the device_prep_dma_interrupt() functionality quite a while back. However, I found it to be pretty much useless. Any functionality I need is covered by adding a callback to the last DMA memcpy() operation. Since the operations happen in-order, I can be sure that the entire set of memcpy()s cas completed. I never needed the capability to generate an interrupt without a memcpy(). I agree that the fsldma driver could use some love. There are places where I am still not confident in the locking. Perhaps I can find some time over Christmas to work on it, but I need someone with 85xx/86xx hardware to test the changes. I only have 83xx hardware. I can also help with the 85xx testing when I finish the busy project soon. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Subject: Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload Ira W. Snyder wrote: Yes, I have used the device_prep_dma_interrupt() functionality quite a while back. However, I found it to be pretty much useless. The specific case it is needed for Talitos/raid is a channel switch interrupt. The interrupt causes the cleanup operation to be run which will kick off any pending dependent operations on the xor channel. In the raid case we only have callbacks at the end of a chain, so we need the interrupt to kick the engine in an operation chain like xor-copy-xor-callback. I am wondering if can use more callbacks to kick off pending dependent operations? Like xor-callback-copy-callback-xor-callback? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Ping does not work on my MPC8544 board, using linux2.6.23
Subject: Ping does not work on my MPC8544 board, using linux2.6.23 why linux-2.6.31 doesnot provide a config file like mpc8544_ds_defconfig? Because it is covered by common defconfig mpc85xx_defconfig. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC] powerpc/mm: honor O_SYNC flag for memory map
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] On Nov 17, 2009, at 1:10 AM, Li Yang wrote: Rather than the original intelligent way, we grant user more freedom. This enables user to map cacheable memory not managed by Linux. Signed-off-by: Li Yang le...@freescale.com --- The only direct users of this function is fb_mmap() and /dev/mem mmap. Although I'm not sure if anything is depending on the intelligent setting of cacheability. is there some reason to change this? Because there is no way to set mapped memory as cacheable if the memory is not managed by Linux kernel. While, it's not rare in real system to allocate some dedicated memory to a certain application which is not managed by kernel and then mmap'ed the memory to the application. The memory should be cacheable but we can't map it to be cacheable due to this intelligent setting. And it is a big hit to the performance. Moreover, the standard O_SYNC flag suggest that user has the control over cacheablity, but actually we had not. - Leo - k arch/powerpc/mm/mem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 579382c..0fd267e 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, if (ppc_md.phys_mem_access_prot) return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot); -if (!page_is_ram(pfn)) +if (file-f_flags O_SYNC) vma_prot = pgprot_noncached(vma_prot); return vma_prot; -- 1.6.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ARM clock API to PowerPC
Now, I know there is at least one person on earth contemplating sharing some drivers between PPC and ARM. I won't tell much more at this stage, but it makes sense in the grand scheme of things to see SoC vendors put similar IO cores into either PPC or ARM and providing that clock API is a good way to also allow these drivers to work since the drivers in questions make use of it. Freescale USB UDC driver is another example that shared between PowerPC and ARM(i.mx). Currently, the imx part of the driver uses clk API, but PowerPC part uses static initialization. It will be better if we can unify the clk setting part of the driver. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: DMA Engine on MPC8270
Hi, Can Freescale DMA engine driver can be used on MPC2870 ? No, the driver is only used on 83xx and 85xx cpus. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC PATCH] fsldma: Add DMA_SLAVE support
This is a request for comments on this patch. I hunch it is not quite ready for inclusion, though it is certainly ready for review. Correct functioning of this patch depends on the patches submitted earlier. As suggested by Dan Williams, I implemented DMA_SLAVE support for the fsldma controller to allow me to use the hardware to transfer to/from a scatterlist to a list of hardware address/length pairs. I implemented support for the extra features available in the DMA controller, such as external pause and external start. I have not tested the features yet. I am willing to drop the support if everything else looks good. I have implemented helper functions for creating the list of hardware address/length pairs as static inline functions in the linux/fsldma.h header. Should I incorporate these into the driver itself and use EXPORT_SYMBOL()? I've never done this before :) Any comments on this patch? No comment for now. Didn't get the time to study the DMA_SLAVE thing. :( I've tested the external start feature, and it works great. I Good. Is it working with your custom board? Can I verify this with my reference board? had to set the DMA Request Count (in the mode register) after the driver was in control. There is no interface for doing this in the existing driver. I just ioremap()ed the registers and added the value from my driver after claiming the channel with dma_request_channel(). There are ways to get the DMA controller into a state where the CB bit stays set no matter what you do. I have only seen this during an externally controlled transfer, when the external master does weird things. I would fix this state in terminate_all(), but I have been unsuccessful in getting the DMA controller working again after it has been messed up. What's the frequency for this to happen? Is the problem reproducable? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: USB does not work on mpc8347
Hi Leo USB work on mpc8347 now. Thank you for your help. The cause was Clock signal was not connected to USB. And I have the other problem. I need to java run time environment on mpc8347. I do not know where i can get it. Could you tell me if you know. I have no particular knowledge about installing JRE on Linux. Google leads me to this link which might be helpful: http://openjdk.java.net/ - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: USB drivers
I have a custom board based on the MPC8313ERDB and have communications capabilities over Ethernet using internet sockets. Basically, just data transfer from the host (my board) to a client (a PC). I want to be able to perform similar transactions across USB. I have done some cursory reading but am a little unclear on how I should approach this. Am I going to have to write a host driver for my custom board, and also write a gadget driver for any client machine? Also, since I am desiring to do simple data transfers only, which drivers could I use as a point of reference for my application? Thanks in advance for any tips and suggestions. Linux has a g_ether gadget, which can simulate a ethernet tunnal over USB. If you already have the communication code through ethernet, it will be easier to make use of that gadget. However, it has more overhead than pure usb transactions. The best way is like you said, custom gadget driver and host driver. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: USB does not work on mpc8347
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
On Behalf Of 山崎 精二
Sent: Wednesday, April 01, 2009 5:14 PM
To: linuxppc-dev@ozlabs.org
Subject: USB does not work on mpc8347
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have some problem.
One is USB does not work on mpc8347.
platform_driver_probe(udc_driver, fsl_udc_probe) is failed.
struct is
static struct platform_driver udc_driver = {
.probe = fsl_udc_probe,
.remove = __exit_p(fsl_udc_remove),
/* these suspend and resume are not usb suspend and resume */
.suspend = fsl_udc_suspend,
.resume = fsl_udc_resume,
.driver = {
//.name = (char *)driver_name,
.name = fsl-usb2-mph,
Why are you changing this? Mph module can only be host, not the device mode
supported by this driver.
.owner = THIS_MODULE,
},
};
I do not know why it fails.
Do i have to do something ?
So what function did you try to test? Host or device? For host mode, you
should look into the drivers/usb/host/ehci-fsl.c file.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: suspend-to-mem on the mpc8349e-mitx-gp?
-Original Message- From: Wood Scott-B07421 Sent: Friday, March 20, 2009 10:42 PM To: Li Yang-R58472 Cc: Soohyung Cho; linuxppc-dev@ozlabs.org Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp? Li Yang-R58472 wrote: However, the code should treat mem as standby on chips that don't support deep sleep. What does the device tree Well, shouldn't the valid() callback reject unsupported states instead of covering up? I don't think so, in this case. The user is not asking for sleep or deep sleep; they are asking for a power state that meets the definition of standby (which sleep does) or which meets the definition of mem (which both sleep and deep sleep do). When the user asks for mem, we provide the lowest power mode that qualifies. In my understanding, mem which is suspend-to-ram means all CPU states and registers are kept in memory and the CPU is completely off during suspension. I don't think the sleep mode of 8349 qualifies, does it? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: suspend-to-mem on the mpc8349e-mitx-gp?
-Original Message- From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org] On Behalf Of Soohyung Cho Sent: Thursday, March 19, 2009 1:47 PM To: linuxppc-dev@ozlabs.org; Wood Scott-B07421 Subject: suspend-to-mem on the mpc8349e-mitx-gp? Hello. I need to enable suspend-to-mem(deep sleep) on my mpc8349e-mitx-gp box. When I send mem message to /sys/power/state, the box seems to get stop. I think the box get stop when it executes suspend-asm.S codes. I know that the latest linux supports suspend-to-mem on the mpc8313erdb box well. Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp? I don't think the MPC8349 hardware has the deep sleep functionality. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: suspend-to-mem on the mpc8349e-mitx-gp?
-Original Message- From: Wood Scott-B07421 Sent: Friday, March 20, 2009 12:11 AM To: Li Yang-R58472 Cc: Soohyung Cho; linuxppc-dev@ozlabs.org Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp? On Thu, Mar 19, 2009 at 12:24:26AM -0700, Li Yang-R58472 wrote: -Original Message- From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org [mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org] On Behalf Of Soohyung Cho Sent: Thursday, March 19, 2009 1:47 PM To: linuxppc-dev@ozlabs.org; Wood Scott-B07421 Subject: suspend-to-mem on the mpc8349e-mitx-gp? Hello. I need to enable suspend-to-mem(deep sleep) on my mpc8349e-mitx-gp box. When I send mem message to /sys/power/state, the box seems to get stop. I think the box get stop when it executes suspend-asm.S codes. I know that the latest linux supports suspend-to-mem on the mpc8313erdb box well. Is it impossible to enable suspend-to-mem on the mpc8349e-mitx-gp? I don't think the MPC8349 hardware has the deep sleep functionality. However, the code should treat mem as standby on chips that don't support deep sleep. What does the device tree Well, shouldn't the valid() callback reject unsupported states instead of covering up? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] More compatibles or more quirk properties
Hi, I'm running into a dilemma choosing between two approaches of defining device tree binding. Let's say if we have several chips with a similar SoC block, but each of them have different quirks. If I define different compatibles for each of the chips, the driver will have a longer match table and thus bloat the device matching process. Or we can use a same compatible for all of them and define properties for each of the quirks. But it somewhat bloats the device tree. I'm more prone to the second solution, but I do want to hear what you guys think about it. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
-Original Message-
From: linuxppc-dev-bounces+leoli=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=freescale@ozlabs.org]
On Behalf Of Dushara Jayasinghe
Sent: Thursday, February 19, 2009 12:27 PM
To: 'linuxppc-dev@ozlabs.org'
Subject: Newby trying to get Ethernet going on MPC83xx series device.
Hi I'm having difficulty getting an Ethernet device up on a
dev board with an MPX8349 controller.
The contents of my .dts file are as follows (based on
mpc8349emitx.dts):
soc8...@e000 {
...
m...@24520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 24520 20;
/* Vitesse 8201 */
phy1c: ethernet-...@1c {
interrupt-parent = ipic;
interrupts = 3 8;
reg = 0;
device_type = ethernet-phy;
};
tbi0: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
m...@25520 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-tbi;
reg = 25520 20;
tbi1: tbi-...@11 {
reg = 11;
device_type = tbi-phy;
};
};
ether...@24000 {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 24000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 20 8 21 8 22 8;
interrupt-parent = ipic;
tbi-handle = tbi0;
phy-handle = phy1c;
linux,network-index = 0;
};
ether...@25000 {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 25000 1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 23 8 24 8 25 8;
interrupt-parent = ipic;
/* Vitesse 7385 isn't on the MDIO bus */
fixed-link = 1 1 1000 0 0;
linux,network-index = 1;
tbi-handle = tbi1;
phy-connection-type = gmii;
};
};
I get the following error during the boot sequence:
IP-Config: Device `eth0' not found
I also found that both gfar_init (in gianfar.c) and
gfar_mdio_init (in gianfar_mii.c) are called but the probe
handlers of either of these devices are not executed.
What am I missing?
Don't find any obvious problem. I suggest you to debug gfar_of_init()
in arch/powerpc/sysdev/fsl_soc.c to see if it works correctly.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
-Original Message-
From: Dushara Jayasinghe [mailto:dusha...@optiscan.com]
Sent: Thursday, February 19, 2009 2:33 PM
To: linuxppc-dev@ozlabs.org
Cc: Li Yang-R58472
Subject: RE: Newby trying to get Ethernet going on MPC83xx
series device.
Thanks for the swift response.
I also found that both gfar_init (in gianfar.c) and
gfar_mdio_init
(in gianfar_mii.c) are called but the probe handlers of either of
these devices are not executed.
What am I missing?
Don't find any obvious problem. I suggest you to debug
gfar_of_init()
in arch/powerpc/sysdev/fsl_soc.c to see if it works correctly.
That fn doesn't exist in the dev tree I'm using (commit
103f194f3ccf46842548eb52e607167b6d4951ef)
The driver is now initialised through of_device. I can't
figure out how the probe handler is invoked.
Well, I was looking at an older tree. If you are using of_device for
TSEC, the most likely cause of this problem is that
of_platform_bus_probe() didn't probe your ethernet nodes.
Refer to the following code in
arch/powerpc/platforms/83xx/mpc834x_itx.c. Make sure it creates
of_platform_device for TSEC.
static struct of_device_id __initdata mpc834x_itx_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{ .compatible = simple-bus, },
{},
};
static int __init mpc834x_itx_declare_of_platform_devices(void)
{
return of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
}
machine_device_initcall(mpc834x_itx,
mpc834x_itx_declare_of_platform_devices);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: PROBLEM: incorrect interrupt ack lead to interrupt loss on freescale powerpc
-Original Message- From: d...@datangmobile.cn [mailto:d...@datangmobile.cn] Sent: Tuesday, February 17, 2009 4:34 PM To: linux-ker...@vger.kernel.org Cc: Li Yang-R58472 Subject: PROBLEM: incorrect interrupt ack lead to interrupt loss on freescale powerpc [1.] One line summary of the problem: incorrect interrupt ack lead to interrupt loss Acked-by: Li Yang le...@freescale.com However, please resend the patch with a brief description and Signed-off-by at the top of the patch. You can read the Documentation/SubmittiongPatches for more information, or even a Chinese version under Documentation/zh_CN/. Here are some small comments about the patch itself, --- a/arch/powerpc/sysdev/ipic.c2009-02-17 15:10:18.0 +0800 +++ b/arch/powerpc/sysdev/ipic.c2009-02-17 15:10:24.0 +0800 @@ -9,6 +9,7 @@ * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. + * Da Yu d...@datangmobile.cn fixed the interrupt loss problem on powerpc IPIC It's not recommended to add changelog in the source now. Please describe in the patch description area. */ #include linux/kernel.h #include linux/init.h @@ -561,8 +562,7 @@ spin_lock_irqsave(ipic_lock, flags); - temp = ipic_read(ipic-regs, ipic_info[src].pend); - temp |= (1 (31 - ipic_info[src].bit)); + temp = (1 (31 - ipic_info[src].bit)); Remove unneeded brackets. ipic_write(ipic-regs, ipic_info[src].pend, temp); spin_unlock_irqrestore(ipic_lock, flags); @@ -581,8 +581,7 @@ temp = ~(1 (31 - ipic_info[src].bit)); ipic_write(ipic-regs, ipic_info[src].mask, temp); - temp = ipic_read(ipic-regs, ipic_info[src].pend); - temp |= (1 (31 - ipic_info[src].bit)); + temp = (1 (31 - ipic_info[src].bit)); Same as above. ipic_write(ipic-regs, ipic_info[src].pend, temp); spin_unlock_irqrestore(ipic_lock, flags); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/83xx: Revive Marvell PHY option onMPC8313E-RDB rev. C boards
-Original Message- From: Anton Vorontsov [mailto:avoront...@ru.mvista.com] Sent: Friday, February 13, 2009 9:18 AM To: Kumar Gala Cc: linuxppc-dev list; Li Yang-R58472 Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option onMPC8313E-RDB rev. C boards On Thu, Feb 12, 2009 at 05:51:57PM -0600, Kumar Gala wrote: On Feb 11, 2009, at 11:40 PM, Li Yang-R58472 wrote: Li, thanks for heads-up! One thing though: documentation says that Marvell PHY address is 0x3, while old device tree and this patch: http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add- default- dts.patch says 0x1... I don't have any rev. C boards, so it would be great if somebody could confirm that 0x1 is the actual address. The correct address is 0x3. The previous patch in revB BSP used a guess value before the revC documentation is available. The latest BSP has been updated to use the correct address. Anton, will you spin a new patch with this change? Since the correct address is 0x3, that means that the old device tree never worked on rev. C boards, thus there is no regression. And furthermore, it appears that U-Boot doesn't support Marvell PHY option either. No regression but to be more updated. RevC boards are newly introduced. So, I don't think that adding the new device tree makes any sense now. I think the better option would be to implement Marvell PHY support in U-Boot, and at the same time teach U-Boot to fixup 8313rdb's device tree depending on the environment variable (something like setenv marvell_phy_option yes/no), i.e. like I did for MPC8315E-RDB's ULPI/TSEC1 options: http://lists.denx.de/pipermail/u-boot/2008-July/036553.html This approach is surely more user friendly. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Tuesday, February 10, 2009 11:31 PM To: avoront...@ru.mvista.com Cc: Li Yang-R58472; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote: commit e85477f516c2de7ed515fcf94ceab5282eba7fa4 (powerpc/83xx: Fix TSEC0 workability on MPC8313E-RDB boards) fixed TSEC0 workability for rev. A and rev. B boards by using fixed-link property for VSC 7385 5-port switch. But rev. C boards have an option where TSEC0 connected to a Marvell PHY, which is a normal PHY on MDIO bus. So far U-Boot does not fix up TSEC0 nodes for MPC8313E-RDB boards, so we'd better include two device-tree files: one that specify Vitesse PHY and another for boards with Marvell PHY option. Reported-by: Li Yang le...@freescale.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Li, thanks for heads-up! One thing though: documentation says that Marvell PHY address is 0x3, while old device tree and this patch: http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-default- dts.patch says 0x1... I don't have any rev. C boards, so it would be great if somebody could confirm that 0x1 is the actual address. arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts | 401 + arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 +- 2 files changed, 402 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/dts/mpc8313erdb_marvell_phy.dts did we decide that we don't have any bcsr or something that convey board rev or this setting? Nope for now. The board do have two revision bits readable to the core, one bit set by resisters and the other set by a switch. We don't currently have a convention for using these two bits. And apperently they can't cover the information of both the board revision and setup. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, February 12, 2009 1:25 PM To: Li Yang-R58472 Cc: linuxppc-dev list; Anton Vorontsov Subject: Re: [PATCH] powerpc/83xx: Revive Marvell PHY option on MPC8313E-RDB rev. C boards On Feb 10, 2009, at 9:10 AM, Anton Vorontsov wrote: Li, thanks for heads-up! One thing though: documentation says that Marvell PHY address is 0x3, while old device tree and this patch: http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8313ERDB-add-default- dts.patch says 0x1... I don't have any rev. C boards, so it would be great if somebody could confirm that 0x1 is the actual address. The correct address is 0x3. The previous patch in revB BSP used a guess value before the revC documentation is available. The latest BSP has been updated to use the correct address. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: UCC GETH does not work on my MPC8360EA
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Grandegger Sent: Wednesday, September 17, 2008 5:18 PM To: linuxppc-dev Subject: UCC GETH does not work on my MPC8360EA Hello, I have a wired problems with my MPC8360EA using Linux 2.6.27-rc6. The UCC GEHT controller works fine with 100/Full but fails with 1000/Full. What I see is that the TX done interrupts come (ifconfig's TX packet counter goes up), but the messages does not show up on the wire. RX seems to work properly, though. Any idea what's going wrong? Does someone got it working with 1000/Full? This looks like an old problem that RGMII Tx shouldn't use internal delay while Rx should use. So try to use 'rgmii-rxid' as phy-connection-type in device tree. Also there should have been a fixup in u-boot for this. So update to use latest u-boot might fix your problem. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC PATCH 2/2 v2] powerpc/83xx: mpc836x_mds: add support for USBHost
-Original Message-
From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
Sent: Monday, September 01, 2008 9:35 PM
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org; Li Yang-R58472
Subject: [RFC PATCH 2/2 v2] powerpc/83xx: mpc836x_mds: add
support for USBHost
Various changes to support QE USB Host on a MPC8360E-MDS board:
- Update the device tree per QE USB bindings;
- Configure QE Par IO;
- Set up BCSR for both USB Host and Peripheral modes;
- Add timer (GTM) node;
- Add gpio-controller node for BCSR13 bank;
- Select FSL_GTM, QE_GPIO and OF_SIMPLE_GPIO.
The work is loosely based on Li Yang's patch[1], which is
used to support peripheral mode only.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
The s-o-b line of the original patch preserved here.
Signed-off-by: Li Yang [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
{snip}
@@ -297,11 +328,20 @@
};
[EMAIL PROTECTED] {
- compatible = qe_udc;
+ compatible = fsl,mpc8360-qe-usb,
+ fsl,mpc8323-qe-usb;
reg = 0x6c0 0x40 0x8b00 0x100;
interrupts = 11;
interrupt-parent = qeic;
- mode = slave;
+ fsl,fullspeed-clock = clk21;
+ fsl,lowspeed-clock = brg9;
+ gpios = qe_pio_b 2 0 /* USBOE */
+ qe_pio_b 3 0 /* USBTP */
+ qe_pio_b 8 0 /* USBTN */
+ qe_pio_b 9 0 /* USBRP */
+ qe_pio_b 11 0 /* USBRN */
+ bcsr135 0 /* SPEED */
+ bcsr134 1; /* POWER */
Nothing against this node. But I don't think gpio nodes can replaces par_io
nodes. Gpios are focusing on the pins which are directly manipulated by the
core, but par_io are for pins used by internal SoCs.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver
-Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2008 3:57 PM To: Li Yang-R58472 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controllerdriver On Tue, 2008-09-02 at 15:35 +0800, Li Yang wrote: On Tue, Sep 2, 2008 at 1:11 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 05:43:33PM +0800, Li Yang wrote: Some of Freescale SoC chips have a QE or CPM co-processor which supports full speed USB. The driver adds device mode support of both QE and CPM USB controller to Linux USB gadget. The driver is tested with MPC8360 and MPC8272, and should work with other models having QE/CPM given minor tweaks. Signed-off-by: Xie Xiaobo [EMAIL PROTECTED] Signed-off-by: Li Yang [EMAIL PROTECTED] --- This is the second submission of the driver. This version addressed: Comments from Anton Vorontsov. A lot of cosmetic problem. Sparse and various kernel DEBUG warnings. Just caught this: g_ether gadget: high speed config #1: CDC Ethernet (ECM) Does RNDIS work too? If not, is it possible to add or doesn't the HW support it? RNDIS is a gadget(protocol) level thing. I believe it can work with this driver although not tested myself. Noted: AFAIK, RNDIS gadget in Linux doesn't interoperate with windows well enough to be production level. Use at your own risk. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] ucc_geth: add support for netpoll
-Original Message- From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 5:59 AM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] ucc_geth: add support for netpoll On Mon, Oct 29, 2007 at 03:17:44PM +0300, Anton Vorontsov wrote: [...] Oops. The original patch happened to hit the Junk mail box. :( That one as well? http://lkml.org/lkml/2007/10/11/128 I think the patch is good to merge after the cosmetic change. I can do it in next pull request to Jeff. Ok, great. Thanks. I'm wondering if you missed that email again. Maybe your mail client/server doing weird things with emails from @ru.mvista.com? No. I have explicitly add you to the whitelist. :) Please be patient, isn't this patch a new feature which can only be integrated in the merge window? Thanks. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] ucc_geth: add support for netpoll
-Original Message-
From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 27, 2007 10:38 PM
To: Sergei Shtylyov
Cc: Anton Vorontsov; [EMAIL PROTECTED]; Li Yang-r58472;
[EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] ucc_geth: add support for netpoll
On Sat, Oct 27, 2007 at 05:09:51PM +0400, Sergei Shtylyov wrote:
Hello.
Anton Vorontsov wrote:
This patch adds netpoll support for the QE UCC Gigabit Ethernet
driver. The approach is very similar to the gianfar driver.
It's rather contrarywise -- this is standard approach
and gianfar
with its
3 TSEC IRQs has a quite non-standard poll_controller()
implementation.
Oh.. well, right -- gianfar a bit more comlex in that regard.
Tested using netconsole.
KGDBoE is considered a better test (I hope you've also
tested with it).
At the time of posting it was tested using netconsole only, a
few days later it's was tested using KGDBoE also. So, it works indeed.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git
a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
18a6f48..06807ce 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3691,6 +3691,22 @@ static irqreturn_t
ucc_geth_irq_handler(int irq, void *info)
return IRQ_HANDLED;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send
+skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev) {
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+
+ disable_irq(ugeth-ug_info-uf_info.irq);
+ ucc_geth_irq_handler(ugeth-ug_info-uf_info.irq, dev);
+ enable_irq(ugeth-ug_info-uf_info.irq);
Why not make it less complex (for a reader and gcc too :-) ?
Yup, I'm agree here but it's too late. Again. ;-)
This patch already accepted into the -mm (a week or so after
the silence), so.. now I'd rather not bother Andrew with such
really cosmetic changes. But if Jeff would directly apply
modfied patch, I'll send it. ;-)
Oops. The original patch happened to hit the Junk mail box. :( I think
the patch is good to merge after the cosmetic change. I can do it in
next pull request to Jeff.
Thanks
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
-Original Message- From: Medve Emilian-EMMEDVE1 Sent: Monday, October 22, 2007 9:48 PM To: David Miller Cc: [EMAIL PROTECTED]; Li Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings Hello David, No piece of code in the kernel should live in a vacuum. In order to improve overall code quality, every piece of driver code should avoid assuming things about pointer sizes and things of this nature. I'm afraid we might be talking about orthogonal issues here. I actively agree that all code (not only kernel) should be written up to the coding/quality standards you mention above, but I see a difference between fixing a warning and making a driver portable (to 64-bit PowerPCs, to other platforms, etc.). If there is a kernel todo list somewhere lets add to it the task to make the ucc_geth more portable. Then the driver can get enabled into the build on every platform, and therefore nobody will break the build of this driver again since it will get hit by allmodconfig et al. builds even on platforms other than the one it is meant for. This hack fix is not acceptable, really. Are you suggesting we leave those warnings there until somebody decides to fix all the portability issues of this driver? My patch is a small and insignificant improvement and not the revolution you're asking for, but is an small improvement today (I dislike warnings) vs. an improbable big one in the future. I'd say we can not use our way of doing things while working with the community. The community has to consider the kernel as a whole and thus has its own virtue. The warning has been there for some time. It stays as an indicator that we have something to do to improve the portability. I will work on a patch to fix this portability issue. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 11:30 PM To: Li Yang-r58472 Cc: linuxppc-dev list; Tabi Timur-B04825 Subject: Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules On May 25, 2007, at 7:15 AM, Kumar Gala wrote: On May 24, 2007, at 9:45 PM, Li Yang-r58472 wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 7:44 PM To: Li Yang-r58472 Cc: Paul; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules On May 24, 2007, at 4:14 AM, Li Yang wrote: Export symbols of qe_lib to be used by QE drivers. Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/sysdev/qe_lib/ucc.c |7 +++ arch/powerpc/sysdev/qe_lib/ucc_fast.c |8 arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++-- 3 files changed, 25 insertions(+), 2 deletions(-) What happened with this? This has been merged as commit 65482ccf9d00bf4f68e17eb9c656d045d26e5d1f. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v5 9/9] add MPC837x MDS board default device tree
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 9:17 PM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
is it me or are you just posting the patches you're updating?
(this is the only v5 patch I saw in the series)
I'm only posting the patch updated, to prevent spamming the list. If
you want, I can send the whole series to you.
On Oct 18, 2007, at 5:16 AM, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/
boot/dts/mpc8377_mds.dts new file mode 100644 index 000..8530de6
+ memory {
+ device_type = memory;
+ reg = 2000; // 512MB at 0
+ };
+
+ [EMAIL PROTECTED] {
[EMAIL PROTECTED]
I can update this now, but the device tree won't be usable by current
u-boot.
+ [EMAIL PROTECTED] {
+ compatible = mpc83xx_spi;
+ reg = 7000 1000;
+ interrupts = 10 8;
+ interrupt-parent = ipic ;
mode = cpu;
Oh ya, the spec has been changed. I also need to update mpc83xx_spi to
fsl_spi.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3 9/9] add MPC837x MDS board default device tree
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 9:59 PM
To: David Gibson
Cc: Li Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v3 9/9] add MPC837x MDS board default device tree
On Oct 14, 2007, at 7:37 PM, David Gibson wrote:
On Fri, Oct 12, 2007 at 09:28:48PM +0800, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 288 +
+
arch/powerpc/boot/dts/mpc8378_mds.dts | 268 +
+++
arch/powerpc/boot/dts/mpc8379_mds.dts | 308 +
3 files changed, 864 insertions(+), 0 deletions(-) create mode
100644 arch/powerpc/boot/dts/mpc8377_mds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
b/arch/powerpc/boot/dts/mpc8377_mds.dts
[snip]
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 e000 0010;
+ reg = e000 0200;
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = watchdog;
Drop this device_type.
+ compatible = mpc83xx_wdt;
+ reg = 200 100;
+ };
+
+ [EMAIL PROTECTED] {
+ device_type = i2c;
And this one.
I've asked Leo to leave this one as all other fsl boards do
this and the code depends on it. There was some discussion
about this but I wasn't sure if it was closed or not.
I'm afraid not only i2c but also watchdog and spi need device_type now.
Shall we proceed removing the type check?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Fix ethernet multicast for ucc_geth.
-Original Message- From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 5:06 PM To: Netdev; Li Yang-r58472 Subject: [PATCH] Fix ethernet multicast for ucc_geth. From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund [EMAIL PROTECTED] Date: Wed, 17 Oct 2007 11:01:44 +0200 Subject: [PATCH] Fix ethernet multicast for ucc_geth. hw_add_addr_in_hash() already swaps byte order, don't do it in ucc_geth_set_multi() too. Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED] Acked-by: Li Yang [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v6 resend 9/9] add MPC837x MDS board default device tree
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 11:02 PM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH v6 resend 9/9] add MPC837x MDS board default device tree On Oct 18, 2007, at 10:09 AM, Li Yang wrote: Signed-off-by: Li Yang [EMAIL PROTECTED] --- Fix a typo in previous one. arch/powerpc/boot/dts/mpc8377_mds.dts | 282 ++ + arch/powerpc/boot/dts/mpc8378_mds.dts | 264 ++ +++ arch/powerpc/boot/dts/mpc8379_mds.dts | 300 ++ +++ 3 files changed, 846 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts still has issues with the i2c nodes. (maybe v7 will be lucky) Do we still need address-cell and size-cell even when it has no child node? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v6 2/9] ipic: add new interrupts introduced by new chip
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 10:57 PM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH v6 2/9] ipic: add new interrupts introduced by new chip On Oct 18, 2007, at 10:04 AM, Li Yang wrote: These interrupts are introduced by the latest Freescale SoC such as MPC837x. The patch also adds comment to interrupts. Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/sysdev/ipic.c | 224 + +-- arch/powerpc/sysdev/ipic.h |7 +- include/asm-powerpc/ipic.h | 12 ++- 3 files changed, 186 insertions(+), 57 deletions(-) see comments: http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044636.html But you didn't answer to my feedback http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044711.html If you are so persistent on thinking it's harmful rather than useful, please at least attempt to persuade me. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v6 4/9] add platform support for MPC837x MDS board
-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 8:43 AM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
+static int __init mpc837x_mds_probe(void) {
+unsigned long root = of_get_flat_dt_root();
+
+return of_flat_dt_is_compatible(root, fsl,mpc837xmds);
To call these two routines, you should include asm/prom.h directly.
asm/prom.h is included in linux/of.h now. Do you think it should be
included explicitly?
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3 3/9] add Freescale SerDes PHY support
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 10:13 PM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v3 3/9] add Freescale SerDes PHY support
{snip}
This patch has been superseded by v4. And the problems have already
been addressed. Thanks.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v4 9/9] add MPC837x MDS board default device tree
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 9:55 PM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v4 9/9] add MPC837x MDS board default device tree
On Oct 15, 2007, at 9:56 AM, Li Yang wrote:
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 281 ++
+
arch/powerpc/boot/dts/mpc8378_mds.dts | 263 ++
+++
arch/powerpc/boot/dts/mpc8379_mds.dts | 299 ++
+++
3 files changed, 843 insertions(+), 0 deletions(-) create mode
100644 arch/powerpc/boot/dts/mpc8377_mds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts
create mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts
{snip}
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 2000; // 512MB at 0
+ };
+
+ [EMAIL PROTECTED] {
make this just '[EMAIL PROTECTED]'
The current u-boot support uses soc837x. U-boot should be changed first
for [EMAIL PROTECTED] to work.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3 4/9] add platform support for MPC837x MDS board
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 9:47 PM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH v3 4/9] add platform support for MPC837x MDS board On Oct 12, 2007, at 8:28 AM, Li Yang wrote: The MPC837x MDS is a new member of Freescale MDS reference system. Signed-off-by: Li Yang [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/Kconfig | 12 arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ++ +++ 3 files changed, 116 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/ platforms/83xx/Kconfig index ec305f1..0c61e7a 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -50,6 +50,11 @@ config MPC836x_MDS help This option enables support for the MPC836x MDS Processor Board. +config MPC837x_MDS + bool Freescale MPC837x MDS + select DEFAULT_UIMAGE + help + This option enables support for the MPC837x MDS Processor Board. endchoice config PPC_MPC831x @@ -75,3 +80,10 @@ config PPC_MPC836x select PPC_UDBG_16550 select PPC_INDIRECT_PCI default y if MPC836x_MDS + +config PPC_MPC837x + bool + select PPC_UDBG_16550 + select PPC_INDIRECT_PCI + select FSL_SERDES + default y if MPC837x_MDS Do we really need this Kconfig option for anything? The chip series can be used on other boards. This option is a container for CPU related selects and can be reused by other boards. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3 2/9] ipic: add new interrupts introduced by new chip
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 9:46 PM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v3 2/9] ipic: add new interrupts
introduced by new chip
On Oct 12, 2007, at 8:28 AM, Li Yang wrote:
These interrupts are introduced by the latest Freescale SoC such as
MPC837x. The patch also adds comment to interrupts.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
arch/powerpc/sysdev/ipic.c | 224 +
+--
arch/powerpc/sysdev/ipic.h |7 +-
include/asm-powerpc/ipic.h | 12 ++-
3 files changed, 186 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c
b/arch/powerpc/sysdev/ipic.c
index 05a56e5..cd8590d 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -33,7 +33,31 @@ static struct ipic * primary_ipic; static
DEFINE_SPINLOCK(ipic_lock);
static struct ipic_info ipic_info[] = {
- [9] = {
+ [1] = { /* PEX1 CNT */
Remove the comments, they are not correct for all IPIC users
and thus misleading.
We had discussed about this. The reason why I add these comments is
that IPIC register definition in our user manual only reference
interrupts by name rather than numbers. It will greatly enhance the
readability of the code, so that we can check easily if the current code
fits IPIC definition of a specific chip. Without comments the check
will be a disaster. :)
The comments are correct for all the in tree CPUs. It should be kept
up-to-date easily when adding new CPUs.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
