Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
On Fri, Oct 29, 2021 at 4:27 PM Eugene Bordenkircher wrote: > > Typing Greg's email correct this time. My apologies. > > Eugene > > -Original Message- > From: Eugene Bordenkircher > Sent: Friday, October 29, 2021 10:14 AM > To: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Cc: leoyang...@nxp.com; ba...@kernel.org; gre...@linuxfoundataion.org > Subject: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to > unrecoverable loop. > > Hello all, > > We've discovered a situation where the FSL udc driver > (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the > request queue, but the queue has been corrupted at some point so it loops > infinitely. I believe we have narrowed into the offending code, but we are > in need of assistance trying to find an appropriate fix for the problem. The > identified code appears to be in all versions of the Linux kernel the driver > exists in. > > The problem appears to be when handling a USB_REQ_GET_STATUS request. The > driver gets this request and then calls the ch9getstatus() function. In this > function, it starts a request by "borrowing" the per device status_req, > filling it in, and then queuing it with a call to list_add_tail() to add the > request to the endpoint queue. Right before it exits the function however, > it's calling ep0_prime_status(), which is filling out that same status_req > structure and then queuing it with another call to list_add_tail() to add the > request to the endpoint queue. This adds two instances of the exact same > LIST_HEAD to the endpoint queue, which breaks the list since the prev and > next pointers end up pointing to the wrong things. This ends up causing a > hard loop the next time nuke() gets called, which happens on the next setup > IRQ. > I agree with you that this looks problematic. This is probably introduced by f79a60b8785 "usb: fsl_udc_core: prime status stage once data stage has primed" that it didn't consider that the status_req has been re-used for the DATA phase. I think the proper fix should be having a separate request allocated for the data phase after the above change. > I'm not sure what the appropriate fix to this problem is, mostly due to my > lack of expertise in USB and this driver stack. The code has been this way > in the kernel for a very long time, which suggests that it has been working, > unless USB_REQ_GET_STATUS requests are never made. This further suggests > that there is something else going on that I don't understand. Deleting the > call to ep0_prime_status() and the following ep0stall() call appears, on the > surface, to get the device working again, but may have side effects that I'm > not seeing. > > I'm hopeful someone in the community can help provide some information on > what I may be missing or help come up with a solution to the problem. A big > thank you to anyone who would like to help out. > > Eugene
Re: [PATCH] usb: gadget: Mark USB_FSL_QE broken on 64-bit
On Wed, Oct 27, 2021 at 5:25 AM Geert Uytterhoeven wrote: > > On 64-bit: > > drivers/usb/gadget/udc/fsl_qe_udc.c: In function ‘qe_ep0_rx’: > drivers/usb/gadget/udc/fsl_qe_udc.c:842:13: error: cast from pointer to > integer of different size [-Werror=pointer-to-int-cast] > 842 | vaddr = (u32)phys_to_virt(in_be32(>buf)); > | ^ > In file included from drivers/usb/gadget/udc/fsl_qe_udc.c:41: > drivers/usb/gadget/udc/fsl_qe_udc.c:843:28: error: cast to pointer from > integer of different size [-Werror=int-to-pointer-cast] > 843 | frame_set_data(pframe, (u8 *)vaddr); > |^ > > The driver assumes physical and virtual addresses are 32-bit, hence it > cannot work on 64-bit platforms. The device is truly only used in legacy 32-bit PowerPC chips and never tested with 64-bit. Thanks. > > Signed-off-by: Geert Uytterhoeven Acked-by: Li Yang > --- > One more casualty of CONFIG_WERROR=y. > http://kisskb.ellerman.id.au/kisskb/buildresult/14652936/ > --- > drivers/usb/gadget/udc/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig > index 8c614bb86c665c77..69394dc1cdfb6436 100644 > --- a/drivers/usb/gadget/udc/Kconfig > +++ b/drivers/usb/gadget/udc/Kconfig > @@ -330,6 +330,7 @@ config USB_AMD5536UDC > config USB_FSL_QE > tristate "Freescale QE/CPM USB Device Controller" > depends on FSL_SOC && (QUICC_ENGINE || CPM) > + depends on !64BIT || BROKEN > help >Some of Freescale PowerPC processors have a Full Speed >QE/CPM2 USB controller, which support device mode with 4 > -- > 2.25.1 >
Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions
On Thu, Dec 2, 2021 at 3:30 PM Andy Shevchenko wrote: > > On Thu, Dec 02, 2021 at 08:01:54PM +, Leo Li wrote: > > > From: Andy Shevchenko > > > Sent: Thursday, December 2, 2021 3:33 AM > > > On Wed, Dec 01, 2021 at 01:41:16PM -0600, Li Yang wrote: > > > > On Tue, Nov 23, 2021 at 10:32 AM Andy Shevchenko > > > > wrote: > > ... > > > > > The build test is good. I have applied it for next. Thanks. > > > > > > Thanks, what about MAINTAINERS updates? I don't see them neither in next > > > nor in your tree. > > > > I am ok with these MAINTAINERS updates. I thought you want to send them > > directly to Linus. I can take them if you like. > > I was just pointing out that it would be good that you (as a maintainer of SOC > FSL) have them applied and pushed for the current cycle, but they are not code > fixes anyway, so it's not critical. > > TL;DR: Yes, please take them, thanks! Got it. Both applied for next. Thanks. Regards, Leo
Re: [PATCH v2 3/3] soc: fsl: Replace kernel.h with the necessary inclusions
On Tue, Nov 23, 2021 at 10:32 AM Andy Shevchenko wrote: > > On Tue, Nov 16, 2021 at 11:38:01AM +0200, Andy Shevchenko wrote: > > On Mon, Nov 15, 2021 at 10:24:36PM +, Leo Li wrote: > > > > From: Andy Shevchenko > > > > Sent: Monday, November 15, 2021 5:30 AM > > > > On Wed, Nov 10, 2021 at 12:59:52PM +0200, Andy Shevchenko wrote: > > > > ... > > > > > > > v2: updated Cc list based on previous changes to MAINTAINERS > > > > > > > > Any comments on this, please? > > > > > > > > I really want to decrease amount of kernel.h usage in the common > > > > headers. > > > > So others won't copy'n'paste bad example. > > > > > > There seems to be no problem with the patch although I didn't get time to > > > really compile with it applied. > > > > > > Will pick them up later after build test. > > > > Thank you! > > > > Note, it has two fixes against MAINTAINERS which may be sent, I believe, > > sooner than later to Linus. > > Any new so far? The build test is good. I have applied it for next. Thanks. Regards, Leo
Re: [PATCH] soc: fsl: qe: convert QE interrupt controller to platform_device
On Mon, Jul 19, 2021 at 1:57 AM Maxim Kochetkov wrote:
>
> 15.07.2021 01:29, Li Yang wrote:
> > From the original code, this should be type = "qeic". It is not
> > defined in current binding but probably needed for backward
> > compatibility.
>
> I took these strings from this part:
>
> np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
>
> if (!np) {
>
> np = of_find_node_by_type(NULL, "qeic");
>
> if (!np)
>
> return -ENODEV;
>
> }
>
> However I can't find usage of "qeic" in any dts, so I will drop this in V2
It is really a bit hard to find as it is pretty old. But it was
really used up until this commit below in 2008. So probably it will
be better to keep it just for backward compatibility?
commit a2dd70a11d4c9cb8a4e4bb41f53a9b430e08559b
Author: Anton Vorontsov
Date: Thu Jan 24 18:39:59 2008 +0300
[POWERPC] QE: get rid of most device_types and model
Now we're searching for "fsl,qe", "fsl,qe-muram", "fsl,qe-muram-data"
and "fsl,qe-ic".
Unfortunately it's still impossible to remove device_type = "qe"
from the existing device trees because older u-boots are looking for it.
Signed-off-by: Anton Vorontsov
Signed-off-by: Kumar Gala
Regards,
Leo
[PATCH 3/6] powerpc/mpc85xx: remove "simple-bus" compatible from ifc node
The binding of ifc device has been updated. Update dts to match
accordingly.
Signed-off-by: Li Yang
---
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/c293si-post.dtsi| 2 +-
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 4f044b41a776..fb3200b006ad 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -50,7 +50,7 @@ _pfdr {
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <25 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
index 2a677fd323eb..5c53cee8755f 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
@@ -35,7 +35,7 @@
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <16 2 0 0 20 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
index b8e0edd1ac69..4da451e000d9 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -35,7 +35,7 @@
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
/* FIXME: Test whether interrupts are split */
interrupts = <16 2 0 0 20 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
b/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
index bec0fc36849d..ee3b45806ee3 100644
--- a/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
@@ -35,7 +35,7 @@
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <19 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index ccda0a91abf0..4b5671462eb3 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -35,7 +35,7 @@
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <16 2 0 0 19 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index d552044c5afc..c15a49df66e1 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -52,7 +52,7 @@ _pfdr {
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <25 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index f58eb820eb5e..38703e58dd09 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -52,7 +52,7 @@ _pfdr {
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <25 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
index ecbb447920bc..58ef8bf6045c 100644
--- a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
@@ -50,7 +50,7 @@ _pfdr {
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <25 2 0 0>;
};
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index fcac73486d48..65f3e17c0d41 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -50,7 +50,7 @@ _pfdr {
{
#address-cells = <2>;
#size-cells = <1>;
- compatible = "fsl,ifc", "simple-bus";
+ compatible = "fsl,ifc";
interrupts = <25 2 0 0>;
};
--
2.25.1
[PATCH 6/6] powerpc/fsl: update ifc node name to be memory-controller
Update the node name to be align with latest binding.
Signed-off-by: Li Yang
---
arch/powerpc/boot/dts/fsl/bsc9131rdb.dts| 2 +-
arch/powerpc/boot/dts/fsl/bsc9132qds.dts| 2 +-
arch/powerpc/boot/dts/fsl/c293pcie.dts | 2 +-
arch/powerpc/boot/dts/fsl/p1010rdb_32b.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1010rdb_36b.dtsi | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131rdb.dts
b/arch/powerpc/boot/dts/fsl/bsc9131rdb.dts
index 8da984251abc..0ba86a6dce1b 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9131rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/bsc9131rdb.dts
@@ -15,7 +15,7 @@ memory {
device_type = "memory";
};
- board_ifc: ifc: ifc@ff71e000 {
+ board_ifc: ifc: memory-controller@ff71e000 {
/* NAND Flash on board */
ranges = <0x0 0x0 0x0 0xff80 0x4000>;
reg = <0x0 0xff71e000 0x0 0x2000>;
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132qds.dts
b/arch/powerpc/boot/dts/fsl/bsc9132qds.dts
index 7cb2158dfe58..ce642e879a1b 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132qds.dts
+++ b/arch/powerpc/boot/dts/fsl/bsc9132qds.dts
@@ -15,7 +15,7 @@ memory {
device_type = "memory";
};
- ifc: ifc@ff71e000 {
+ ifc: memory-controller@ff71e000 {
/* NOR, NAND Flash on board */
ranges = <0x0 0x0 0x0 0x8800 0x0800
0x1 0x0 0x0 0xff80 0x0001>;
diff --git a/arch/powerpc/boot/dts/fsl/c293pcie.dts
b/arch/powerpc/boot/dts/fsl/c293pcie.dts
index 5e905e0857cf..e2fdac2ed420 100644
--- a/arch/powerpc/boot/dts/fsl/c293pcie.dts
+++ b/arch/powerpc/boot/dts/fsl/c293pcie.dts
@@ -42,7 +42,7 @@ memory {
device_type = "memory";
};
- ifc: ifc@fffe1e000 {
+ ifc: memory-controller@fffe1e000 {
reg = <0xf 0xffe1e000 0 0x2000>;
ranges = <0x0 0x0 0xf 0xec00 0x0400
0x1 0x0 0xf 0xff80 0x0001
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb_32b.dtsi
b/arch/powerpc/boot/dts/fsl/p1010rdb_32b.dtsi
index fdc19aab2f70..583a6cd05079 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb_32b.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb_32b.dtsi
@@ -36,7 +36,7 @@ memory {
device_type = "memory";
};
-board_ifc: ifc: ifc@ffe1e000 {
+board_ifc: ifc: memory-controller@ffe1e000 {
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0x0 0xee00 0x0200
0x1 0x0 0x0 0xff80 0x0001
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb_36b.dtsi
b/arch/powerpc/boot/dts/fsl/p1010rdb_36b.dtsi
index de2fceed4f79..4d41efe0038f 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb_36b.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb_36b.dtsi
@@ -36,7 +36,7 @@ memory {
device_type = "memory";
};
-board_ifc: ifc: ifc@fffe1e000 {
+board_ifc: ifc: memory-controller@fffe1e000 {
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0xf 0xee00 0x0200
0x1 0x0 0xf 0xff80 0x0001
--
2.25.1
Re: [PATCH] soc: fsl: qe: Check of ioremap return value
On Thu, Dec 30, 2021 at 9:47 AM Jiasheng Jiang wrote:
>
> As the possible failure of the ioremap(), the par_io could be NULL.
> Therefore it should be better to check it and return error in order to
> guarantee the success of the initiation.
> But, I also notice that all the caller like mpc85xx_qe_par_io_init() in
> `arch/powerpc/platforms/85xx/common.c` don't check the return value of
> the par_io_init().
> Actually, par_io_init() needs to check to handle the potential error.
> I will submit another patch to fix that.
> Anyway, par_io_init() itsely should be fixed.
>
> Fixes: 7aa1aa6ecec2 ("QE: Move QE from arch/powerpc to drivers/soc")
> Signed-off-by: Jiasheng Jiang
Applied for next. Thanks.
> ---
> drivers/soc/fsl/qe/qe_io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
> index e277c827bdf3..a5e2d0e5ab51 100644
> --- a/drivers/soc/fsl/qe/qe_io.c
> +++ b/drivers/soc/fsl/qe/qe_io.c
> @@ -35,6 +35,8 @@ int par_io_init(struct device_node *np)
> if (ret)
> return ret;
> par_io = ioremap(res.start, resource_size());
> + if (!par_io)
> + return -ENOMEM;
>
> if (!of_property_read_u32(np, "num-ports", _ports))
> num_par_io_ports = num_ports;
> --
> 2.25.1
>
Re: [PATCH 1/2] soc: fsl: guts: Revert commit 3c0d64e867ed
On Thu, Nov 4, 2021 at 4:09 AM Christophe JAILLET
wrote:
>
> This reverts commit 3c0d64e867ed
> ("soc: fsl: guts: reuse machine name from device tree").
>
> A following patch will fix the missing memory allocation failure check
> instead.
>
> Suggested-by: Tyrel Datwyler
> Signed-off-by: Christophe JAILLET
Applied for next. Thanks.
> ---
> This is a follow-up of discussion in:
> https://lore.kernel.org/kernel-janitors/b12e8c5c5d6ab3061d9504de8fbaefcad6bbc385.1629321668.git.christophe.jail...@wanadoo.fr/
> ---
> drivers/soc/fsl/guts.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index 072473a16f4d..af7741eafc57 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -28,7 +28,6 @@ struct fsl_soc_die_attr {
> static struct guts *guts;
> static struct soc_device_attribute soc_dev_attr;
> static struct soc_device *soc_dev;
> -static struct device_node *root;
>
>
> /* SoC die attribute definition for QorIQ platform */
> @@ -138,7 +137,7 @@ static u32 fsl_guts_get_svr(void)
>
> static int fsl_guts_probe(struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *root, *np = pdev->dev.of_node;
> struct device *dev = >dev;
> const struct fsl_soc_die_attr *soc_die;
> const char *machine;
> @@ -159,8 +158,9 @@ static int fsl_guts_probe(struct platform_device *pdev)
> root = of_find_node_by_path("/");
> if (of_property_read_string(root, "model", ))
> of_property_read_string_index(root, "compatible", 0,
> );
> + of_node_put(root);
> if (machine)
> - soc_dev_attr.machine = machine;
> + soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
>
> svr = fsl_guts_get_svr();
> soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> @@ -195,7 +195,6 @@ static int fsl_guts_probe(struct platform_device *pdev)
> static int fsl_guts_remove(struct platform_device *dev)
> {
> soc_device_unregister(soc_dev);
> - of_node_put(root);
> return 0;
> }
>
> --
> 2.30.2
>
Re: [PATCH] soc: fsl: qe: fix typo in a comment
On Sat, Dec 11, 2021 at 5:12 PM Jason Wang wrote: > > The double `is' in the comment in line 150 is repeated. Remove one > of them from the comment. Looks like you also removed a redundant tab in a new line. We probably can squeeze this trivial cleanup in, but we need to mention it. > > Signed-off-by: Jason Wang Applied for next with commit message updated. > --- > drivers/soc/fsl/qe/qe.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c > index 4d38c80f8be8..b3c226eb5292 100644 > --- a/drivers/soc/fsl/qe/qe.c > +++ b/drivers/soc/fsl/qe/qe.c > @@ -147,7 +147,7 @@ EXPORT_SYMBOL(qe_issue_cmd); > * memory mapped space. > * The BRG clock is the QE clock divided by 2. > * It was set up long ago during the initial boot phase and is > - * is given to us. > + * given to us. > * Baud rate clocks are zero-based in the driver code (as that maps > * to port numbers). Documentation uses 1-based numbering. > */ > @@ -421,7 +421,7 @@ static void qe_upload_microcode(const void *base, > > for (i = 0; i < be32_to_cpu(ucode->count); i++) > iowrite32be(be32_to_cpu(code[i]), _immr->iram.idata); > - > + > /* Set I-RAM Ready Register */ > iowrite32be(QE_IRAM_READY, _immr->iram.iready); > } > -- > 2.34.1 >
Re: [PATCH 2/2] soc: fsl: guts: Add a missing memory allocation failure check
On Thu, Nov 4, 2021 at 4:10 AM Christophe JAILLET
wrote:
>
> If 'devm_kstrdup()' fails, we should return -ENOMEM.
>
> While at it, move the 'of_node_put()' call in the error handling path and
> after the 'machine' has been copied.
> Better safe than sorry.
>
> Suggested-by: Tyrel Datwyler
> Signed-off-by: Christophe JAILLET
Applied with Fixes tag and Depends-on tag added. Thanks.
> ---
> Not sure of which Fixes tag to add. Should be a6fc3b698130, but since
> another commit needs to be reverted for this patch to make sense, I'm
> unsure of what to do. :(
> So, none is given.
> ---
> drivers/soc/fsl/guts.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index af7741eafc57..5ed2fc1c53a0 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -158,9 +158,14 @@ static int fsl_guts_probe(struct platform_device *pdev)
> root = of_find_node_by_path("/");
> if (of_property_read_string(root, "model", ))
> of_property_read_string_index(root, "compatible", 0,
> );
> - of_node_put(root);
> - if (machine)
> + if (machine) {
> soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
> + if (!soc_dev_attr.machine) {
> + of_node_put(root);
> + return -ENOMEM;
> + }
> + }
> + of_node_put(root);
>
> svr = fsl_guts_get_svr();
> soc_die = fsl_soc_die_match(svr, fsl_soc_die);
> --
> 2.30.2
>
Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
On Sat, Feb 25, 2023 at 10:52 AM Paul Gortmaker wrote: > > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On > 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > > > > > -Original Message- > > > From: Paul Gortmaker > > > Sent: Monday, February 20, 2023 5:59 AM > > > To: linuxppc-dev@lists.ozlabs.org > > > Cc: Leo Li ; Claudiu Manoil ; > > > Paul Gortmaker ; Scott Wood > > > ; Michael Ellerman ; Benjamin > > > Herrenschmidt ; Paul Mackerras > > > > > > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > > > > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > > > > > This series removes support for four e300 (MPC83xx) Freescale processor > > > family evaluation boards that were added to the kernel in the 2006 era. > > > > Hi Paul, > > > > I talked with our marketing team on this. Although we do not recommend any > > new design with these SoCs, they are still being shipped in large amount to > > customers now. Plus it is possible for the bigger amount of existing > > devices to be updating their software that includes a new kernel. So we > > should definitely keep all the common SoC code that might be needed to > > support their own design. > > Thanks for confirming with your marketing team that they "do not > recommend any new design with these SoCs" -- it also confirms the > information I read on the web pages for the platforms. > > As those of us immersed in this world all know from the 101 basics of > Product Life Cycle lessons, it doesn't matter if it is a phone or a > set-top-box/PVR or whatever else kind of non-PC consumer device -- > kernel uprevs never happen in that product space. One thing is that the QorIQ platforms are not for the consumer devices. They are mostly used in networking or communication equipment. I think their product life cycle would be more like the server or data center scenario. Regards, Leo > > So with the best interests of the mainline kernel in mind, I think we > are good to proceed with this for summer 2023. And of course as I've > said many times before - the kernel is in git, so really you can't > delete anything anyway - it remains in history forever. > > Thanks, > Paul. > -- > > > > > > > > > These boards were all of a very similar form factor, a largish PCI or > > > PCI-X card > > > that could also be used standalone with an external power brick, and all > > > shared the Modular Development System (MDS) designation. > > > > > > These platforms were made in limited quantity and were generally designed > > > to get early silicon into the hands of OEMs who would later develop their > > > own boards/platforms. As such, availability was limited to those who > > > would > > > be working on boards and/or BSP support. > > > > > > Many early revision MDS platforms used a mechanical clamping system to > > > hold the BGA CPU in place to facilitate CPU updates -- something not > > > normally possible for a soldered down BGA in a COTS system. > > > > > > The point of these details is to give context that reflects that these > > > four > > > boards were made in limited quantities, were not in a form factor that is > > > really "hobbyist" friendly and hence make sense for removal 17 years > > > later. > > > > We would agree with you that the MDS platforms are only used by a limited > > number of customers for evaluation purpose, so it should be fine to be > > removed. So for this series: > > > > Acked-by: Li Yang > > > > > > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > > > > > There will still exist several e300 Freescale Reference Design System > > > (RDS) > > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > > > probably makes sense to consider removing these as well, based on age. > > > > These boards are mass market boards that sold in larger amount and are much > > more likely to still be used. We would suggest we keep them for now. > > > > > > > > But before we get to that, lets see how this goes -- and then we should > > > look > > > at similar early e500 evaluation platforms [MPC8540-ADS, etc] next
Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
On Sat, Feb 25, 2023 at 4:51 PM Arnd Bergmann wrote: > > On Sat, Feb 25, 2023, at 17:50, Paul Gortmaker wrote: > > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On > > 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > Thanks for confirming with your marketing team that they "do not > > recommend any new design with these SoCs" -- it also confirms the > > information I read on the web pages for the platforms. > > > > As those of us immersed in this world all know from the 101 basics of > > Product Life Cycle lessons, it doesn't matter if it is a phone or a > > set-top-box/PVR or whatever else kind of non-PC consumer device -- > > kernel uprevs never happen in that product space. > > > > So with the best interests of the mainline kernel in mind, I think we > > are good to proceed with this for summer 2023. And of course as I've > > said many times before - the kernel is in git, so really you can't > > delete anything anyway - it remains in history forever. > > Thanks for working on this, this is a good step towards removing > the known unused code. One aspect I'd add from doing similar cleanups > on arm32 is that I would prioritize removing evaluation platforms > for SoCs that have no other supported boards, and then > garbage-collecting the device drivers that become unused. > > I'm not sure where the RDB boards fit in that, in particular if > an unmodified kernel would work on a machine that is derived from > the reference platform, or if it really only works on the machine > itself. On most arm platforms, we moved to having only per-soc > "compatible" strings, but on Freescale ppc32 it appears that > the kernel always matches a board specific string and requires > patches in order to support anything else. The RDB boards normally don't include the complex configuration mechanisms as used on the MDS platforms to support different configurations at the same time. They were designed to mimic a real product and should be much more likely to work unmodified or with some minor tweaks. Regards, Leo
Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms
am/ > [6] https://www.nxp.com/docs/en/user-guide/MPC8568EMDSPBUGAD.pdf > [7] > https://www.nxp.com/design/qoriq-developer-resources/qoriq-p1021-p1012-modular-development-system:P1021MDS > [8] > https://www.nxp.com/products/no-longer-manufactured/integrated-communications-processor-development-system:MPC8572DS > [9] https://www.nxp.com/docs/en/fact-sheet/MPC8544DSFS.pdf > > Cc: Scott Wood > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Li Yang > Cc: Claudiu Manoil > Cc: Pali Rohár > > --- > > Paul Gortmaker (4): > powerpc: drop MPC8540_ADS and MPC8560_ADS platform support > powerpc: drop MPC85xx_CDS platform support > powerpc: drop MPC8568_MDS / P1021_MDS platform support > powerpc: remove orphaned MPC85xx kernel config fragments. > > arch/powerpc/boot/Makefile| 5 - > arch/powerpc/boot/dts/fsl/mpc8540ads.dts | 355 > arch/powerpc/boot/dts/fsl/mpc8541cds.dts | 375 - > arch/powerpc/boot/dts/fsl/mpc8548cds.dtsi | 302 - > arch/powerpc/boot/dts/fsl/mpc8548cds_32b.dts | 82 > arch/powerpc/boot/dts/fsl/mpc8548cds_36b.dts | 82 > arch/powerpc/boot/dts/fsl/mpc8555cds.dts | 375 - > arch/powerpc/boot/dts/fsl/mpc8560ads.dts | 388 - > arch/powerpc/boot/dts/fsl/mpc8568mds.dts | 310 -- > arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi | 270 > arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi | 68 --- > arch/powerpc/boot/dts/fsl/p1021mds.dts| 319 -- > arch/powerpc/configs/85xx-32bit.config| 5 - > arch/powerpc/configs/85xx-hw.config | 139 -- > arch/powerpc/configs/85xx-smp.config | 2 - > .../configs/85xx/mpc8540_ads_defconfig| 47 --- > .../configs/85xx/mpc8560_ads_defconfig| 50 --- > .../configs/85xx/mpc85xx_cds_defconfig| 52 --- > arch/powerpc/configs/mpc85xx_base.config | 3 - > arch/powerpc/platforms/85xx/Makefile | 3 - > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 171 > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 397 - > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 398 -- > 23 files changed, 4198 deletions(-) > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8540ads.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8541cds.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8548cds.dtsi > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8548cds_32b.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8548cds_36b.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8555cds.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8560ads.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8568mds.dts > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi > delete mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi > delete mode 100644 arch/powerpc/boot/dts/fsl/p1021mds.dts > delete mode 100644 arch/powerpc/configs/85xx-32bit.config > delete mode 100644 arch/powerpc/configs/85xx-hw.config > delete mode 100644 arch/powerpc/configs/85xx-smp.config > delete mode 100644 arch/powerpc/configs/85xx/mpc8540_ads_defconfig > delete mode 100644 arch/powerpc/configs/85xx/mpc8560_ads_defconfig > delete mode 100644 arch/powerpc/configs/85xx/mpc85xx_cds_defconfig > delete mode 100644 arch/powerpc/platforms/85xx/mpc85xx_ads.c > delete mode 100644 arch/powerpc/platforms/85xx/mpc85xx_cds.c > delete mode 100644 arch/powerpc/platforms/85xx/mpc85xx_mds.c > > -- > 2.17.1 >
Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
On Tue, Feb 28, 2023 at 11:52 AM Arnd Bergmann wrote: > > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote: > > On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: > >> > > > > >> > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > >> > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the > >> > > > kernel. > >> > > > > >> > > > There will still exist several e300 Freescale Reference Design > >> > > > System (RDS) > >> > > > boards[5] and mini-ITX boards[6] with support in the kernel. While > >> > > > these > >> > > > were more of a COTS "ready to deploy" design more suited to > >> > > > hobbyists, it > >> > > > probably makes sense to consider removing these as well, based on > >> > > > age. > >> > > > >> > > These boards are mass market boards that sold in larger amount and are > >> > > much more likely to still be used. We would suggest we keep them for > >> > > now. > > > > Agreed, the RDS design is still used here. > > Can you elaborate what the typical kernel upgrade schedule for > these boards? > > Note that for the debate about dropping the machines from future > kernels, it does not really matter how many remaining users there > are or how many boards get sold. The only question is whether > someone is still planning to provide upgrades to kernels later > than linux-6.3 in the future. > > It sounds like there are commercial requirements for validating > and distributing kernel upgrades (in addition to hobbyist uses), so > I would expect that whoever is paying for the upgrades has a clear > plan for how much longer they are going to do that, or at least > a some idea of how many of the previous LTS kernels (5.10, 5.15, > 6.1) ended up actually getting shipped to users. > > It may be worth pointing out that the official webpage for > the MPC8313ERDB board in the example only lists a hilariously > outdated BSP kernel based on a patched linux-2.6.23 release, > so maybe the marketing team can change that to point to the > latest validated LTS kernel instead. The BSP/SDK releases from NXP do follow a different development principle from working with upstream directly. However, we do value the customers who prefer to work closer with the upstream community than relying on our BSPs/SDKs deliveries and that's why we pushed our development team internally to upstream code as much as possible. And we will try to help keep them well maintained in the community. Regards, Leo
Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
On Mon, May 8, 2023 at 8:44 AM Uwe Kleine-König wrote: > > Hello Leo, > > On Thu, Apr 13, 2023 at 08:00:04AM +0200, Uwe Kleine-König wrote: > > On Wed, Apr 12, 2023 at 09:30:05PM +, Leo Li wrote: > > > > On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote: > > > > > Hello, > > > > > > > > > > many bus remove functions return an integer which is a historic > > > > > misdesign that makes driver authors assume that there is some kind of > > > > > error handling in the upper layers. This is wrong however and > > > > > returning and error code only yields an error message. > > > > > > > > > > This series improves the fsl-mc bus by changing the remove callback to > > > > > return no value instead. As a preparation all drivers are changed to > > > > > return zero before so that they don't trigger the error message. > > > > > > > > Who is supposed to pick up this patch series (or point out a good > > > > reason for > > > > not taking it)? > > > > > > Previously Greg KH picked up MC bus patches. > > > > > > If no one is picking up them this time, I probably can take it through > > > the fsl soc tree. > > > > I guess Greg won't pick up this series as he didn't get a copy of it :-) > > > > Browsing through the history of drivers/bus/fsl-mc there is no > > consistent maintainer to see. So if you can take it, that's very > > appreciated. > > My mail was meant encouraging, maybe it was too subtile? I'll try again: > > Yes, please apply, that would be wonderful! Sorry for missing your previous email. I will do that. Thanks. Regards, Leo
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: 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: [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: [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: [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: 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: 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
[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: 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
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: 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: 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
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: [PATCH] USB_DR host support for FSL MPC831x
Hi Vitaly,
I believe that your patch is addresses by my patch in 2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
ehci_fsl-update-for-mpc831x-support.patch
- Leo
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Vitaly Bordug
Sent: Tuesday, July 17, 2007 8:59 AM
To: Greg KH
Cc: linuxppc-dev@ozlabs.org
Subject: [PATCH] USB_DR host support for FSL MPC831x
Modifies fsl_ehci code so that to get USB host working on
mpc831x platform. Verified with MPC8313RDB reference board.
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8313erdb.dts |1 +
drivers/usb/host/ehci-fsl.c |4 +++-
drivers/usb/host/ehci-hcd.c |2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 1b351dc..c330e79 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -90,6 +90,7 @@
interrupt-parent = ipic ;
interrupts = 26 8;
phy_type = utmi_wide;
+ control_init = 0280; // UTMI ext
48 MHz clk
};
[EMAIL PROTECTED] {
diff --git a/drivers/usb/host/ehci-fsl.c
b/drivers/usb/host/ehci-fsl.c index c7a7c59..3e3187b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct
usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct fsl_usb2_platform_data *pdata;
void __iomem *non_ehci = hcd-regs;
+ u32 temp;
pdata =
(struct fsl_usb2_platform_data *)hcd-self.controller-
platform_data;
/* Enable PHY interface in the control reg. */
- out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x0004);
+ temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
+ out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x0004);
out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x001b);
#if defined(CONFIG_PPC32) !defined(CONFIG_NOT_COHERENT_CACHE)
diff --git a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c index 099aff6..994a127 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -925,7 +925,7 @@ MODULE_LICENSE (GPL);
#define PCI_DRIVER ehci_pci_driver
#endif
-#ifdef CONFIG_MPC834x
+#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
#include ehci-fsl.c
#define PLATFORM_DRIVER ehci_fsl_driver
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] USB_DR device support for FSL MPC831x
Hi Vitaly,
The max_ep_nr will be read from DCCPARAMS register with my patch in
2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
fsl_usb2_udc-get-max-ep-number-from-dccparams-register.patch
- Leo
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Vitaly Bordug
Sent: Tuesday, July 17, 2007 8:59 AM
To: Greg KH
Cc: linuxppc-dev@ozlabs.org
Subject: [PATCH] USB_DR device support for FSL MPC831x
This adds support for USB device mode on mpc831x series.
Devicetree node modification is required to make it work -
dr_mode =peripheral;
which should be commented out if host mode is desired onboot.
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c |1 +
include/linux/fsl_devices.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c
b/arch/powerpc/sysdev/fsl_soc.c index c0ddc80..27a1510 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -514,6 +514,7 @@ static int __init fsl_usb_of_init(void)
}
} else if (prop !strcmp(prop, peripheral)) {
usb_data.operating_mode = FSL_USB2_DR_DEVICE;
+ usb_data.max_ep_nr = *(unsigned
int*)of_get_property(np,
+max_ep_nr,NULL);
usb_dev_dr_client =
platform_device_register_simple(
fsl-usb2-udc, i, r, 2);
if (IS_ERR(usb_dev_dr_client)) {
diff --git a/include/linux/fsl_devices.h
b/include/linux/fsl_devices.h index 12e631f..a3feb34 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -103,6 +103,7 @@ struct fsl_usb2_platform_data {
enum fsl_usb2_operating_modes operating_mode;
enum fsl_usb2_phy_modes phy_mode;
unsigned intport_enables;
+ unsigned intmax_ep_nr;
};
/* Flags in fsl_usb2_mph_platform_data */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Tabi Timur-B04825
Sent: Friday, August 31, 2007 5:07 AM
To: Anton Vorontsov
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts
to use SPI1in QE, register mmc_spi stub
Anton Vorontsov wrote:
+static int __init mpc832x_spi_init(void) {
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
Why are you doing this here, and not in the device tree?
I saw you used pio node, but later changed to make it hardcoded. What's
the reason? IMO, device tree is used to describe the hardware settings,
pio node is a perfect match. Moreover, changing the device tree is much
easier than changing the code.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] ucc_geth: fix compilation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kumar Gala Sent: Friday, September 14, 2007 10:08 PM To: Jeff Garzik Cc: linuxppc-dev@ozlabs.org list; netdev Subject: Re: [PATCH] ucc_geth: fix compilation On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote: Currently qe_bd_t is used in the macro call -- dma_unmap_single, which is a no-op on PPC32, thus error is hidden today. Starting with 2.6.24, macro will be replaced by the empty static function, and erroneous use of qe_bd_t will trigger compilation error. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- Jeff, I'm going to pick this up via the powerpc.git tree since its currently only broken in our for-2.6.24 branch (because of other changes in there). Any issues? Kumar, Kim Phillips has posted the same patch to netdev list before Anton. Therefore, I do prefer to use his. Thanks - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 4/9] add platform support for MPC837x MDS board
-Original Message- From: Stephen Rothwell [mailto:[EMAIL PROTECTED] Sent: Thursday, October 11, 2007 9:06 AM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 4/9] add platform support for MPC837x MDS board On Wed, 10 Oct 2007 18:06:39 +0800 Li Yang [EMAIL PROTECTED] wrote: +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c +#include asm/of_platform.h You actually neeed linux/of.h (for of_ routines) and asm/prom.h (for of_flat_dt_is_compatible). Thanks for the comments. Updated version on the way. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2] drivers/ata: add support to Freescale 3.0Gbps SATA Controller
-Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 9:55 PM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Kalra Ashish-B00888; Li Yang-r58472 Subject: Re: [PATCH v2] drivers/ata: add support to Freescale 3.0Gbps SATA Controller + cd = pp-cmdentry + tag; + + memcpy(fis, cd-sfis, 6 * 4); /* should we use memcpy_from_io() */ If cd-sfis points at memory over the PCI bus (eg mmio or memory on the controller card) then you need to use ioread/_io type functions. If cd-sfis points into host memory where the FIS is delivered by DMA from the card you will be fine if it was allocated with an _coherent allocator Thanks for the clarification. So the code here is ok, that we use command descriptor from dma_alloc_coherent(). :) - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 3/9 v2] add Freescale SerDes PHY support
-Original Message- From: Wood Scott-B07421 Sent: Friday, October 12, 2007 4:10 AM To: Li Yang-r58472 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: Re: [PATCH 3/9 v2] add Freescale SerDes PHY support On Thu, Oct 11, 2007 at 05:53:45PM +0800, Li Yang wrote: diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index 19d4628..e89f803 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -291,4 +291,8 @@ config FSL_ULI1575 Freescale reference boards. The boards all use the ULI in pretty much the same way. +config FSL_SERDES + bool + default n default n is the default -- no need to specify it explicitly. + /* Configure SRDSCR1 */ + tmp = in_be32(regs + FSL_SRDSCR1_OFFS); + tmp = ~FSL_SRDSCR1_PLLBW; + out_be32(regs + FSL_SRDSCR1_OFFS, tmp); clrbits32? + /* Configure SRDSCR2 */ + tmp = in_be32(regs + FSL_SRDSCR2_OFFS); + tmp = ~FSL_SRDSCR2_SEIC_MASK; + tmp |= FSL_SRDSCR2_SEIC_SATA; + out_be32(regs + FSL_SRDSCR2_OFFS, tmp); clrsetbits_be32? Ok, I will try the up-to-the-minute arsenal. :) - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
-Original Message-
From: Medve Emilian-EMMEDVE1
Sent: Saturday, October 13, 2007 7:26 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Li
Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Medve Emilian-EMMEDVE1
Subject: [PATCH] [POWERPC] ucc_geth: Fix build break
introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
CC drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function 'ucc_geth_startup':
drivers/net/ucc_geth.c:2614: warning: assignment makes
integer from pointer without a cast
drivers/net/ucc_geth.c:2651: warning: assignment makes
integer from pointer without a cast
drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first
use in this function)
drivers/net/ucc_geth.c:3483: error: (Each undeclared
identifier is reported only once
drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Thanks for the patch. Here are some comments.
The patch fixes the dev undeclared compile error not the warnings. So
they shouldn't be listed here.
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
Here is a convenient link for the culprit patch:
http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.g
it;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
netdev-2.6 scripts/checkpatch.pl
0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch
Your patch has no obvious style problems and is ready for submission.
drivers/net/ucc_geth.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d00e7d4..c43d4d1 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -63,7 +63,7 @@
#define UGETH_MSG_DEFAULT(NETIF_MSG_IFUP 1 ) - 1
void uec_set_ethtool_ops(struct net_device *netdev);
-
+
static DEFINE_SPINLOCK(ugeth_lock);
static struct {
There are quite a few references to the dev structure. I would prefer
to add a new variable dev here.
- Leo
@@ -3480,9 +3480,9 @@ static int ucc_geth_rx(struct
ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
dev_kfree_skb_any(skb);
ugeth-rx_skbuff[rxQ][ugeth-skb_currx[rxQ]] = NULL;
- dev-stats.rx_dropped++;
+ ugeth-dev-stats.rx_dropped++;
} else {
- dev-stats.rx_packets++;
+ ugeth-dev-stats.rx_packets++;
howmany++;
/* Prep the skb for the packet */
@@ -3491,7 +3491,7 @@ static int ucc_geth_rx(struct
ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
/* Tell the skb what kind of packet this is */
skb-protocol = eth_type_trans(skb, ugeth-dev);
- dev-stats.rx_bytes += length;
+ ugeth-dev-stats.rx_bytes += length;
/* Send the packet up the stack */
#ifdef CONFIG_UGETH_NAPI
netif_receive_skb(skb);
@@ -3506,7 +3506,7 @@ static int ucc_geth_rx(struct
ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
if (!skb) {
if (netif_msg_rx_err(ugeth))
ugeth_warn(%s: No Rx Data
Buffer, __FUNCTION__);
- dev-stats.rx_dropped++;
+ ugeth-dev-stats.rx_dropped++;
break;
}
--
1.5.3.GIT
___
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Arnd Bergmann
Sent: Friday, October 12, 2007 10:34 PM
To: linuxppc-dev@ozlabs.org
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH v3 3/9] add Freescale SerDes PHY support
On Friday 12 October 2007, Li Yang wrote:
The SerDes(serializer/deserializer) PHY block is a new SoC
block used
in Freescale chips to support multiple serial interfaces,
such as PCI
Express, SGMII, SATA.
Some of my comments here are similar to those for the ata
driver, so I won't be as verbose here
+static int __init setup_serdes(struct device_node *np) {
+ void __iomem *regs;
+ const void *prot;
+ const unsigned int *freq;
+ struct resource res;
+ u32 rfcks;
+
+ of_address_to_resource(np, 0, res);
+ regs = ioremap(res.start, res.end - res.start + 1);
of_iomap?
I'd like to but of_iomap() couldn't provide the physical address of the
device used as identification.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
-Original Message-
From: Medve Emilian-EMMEDVE1
Sent: Monday, October 15, 2007 9:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Li
Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Medve Emilian-EMMEDVE1
Subject: [PATCH v2] [POWERPC] ucc_geth: Fix build break
introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first
use in this function)
drivers/net/ucc_geth.c:3483: error: (Each undeclared
identifier is reported only once
drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Emil Medve [EMAIL PROTECTED]
Acked-by: Li Yang [EMAIL PROTECTED]
---
Here is a convenient link for the culprit patch:
http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.g
it;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
netdev-2.6 scripts/checkpatch.pl
0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch
Your patch has no obvious style problems and is ready for submission.
drivers/net/ucc_geth.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d00e7d4..bec413b 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -63,7 +63,7 @@
#define UGETH_MSG_DEFAULT(NETIF_MSG_IFUP 1 ) - 1
void uec_set_ethtool_ops(struct net_device *netdev);
-
+
static DEFINE_SPINLOCK(ugeth_lock);
static struct {
@@ -3454,9 +3454,12 @@ static int ucc_geth_rx(struct
ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
u16 length, howmany = 0;
u32 bd_status;
u8 *bdBuffer;
+ struct net_device * dev;
ugeth_vdbg(%s: IN, __FUNCTION__);
+ dev = ugeth-dev;
+
/* collect received buffers */
bd = ugeth-rxBd[rxQ];
--
1.5.3.GIT
___
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
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] 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 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] [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] 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] 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
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] 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: [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: 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: 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
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: 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: 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: [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: [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 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 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: [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 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] 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: 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 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: [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: 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 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: 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 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: [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: [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: [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
答复: [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: [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
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: 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: 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: 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: [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][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][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 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: [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: [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: [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: [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: 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: 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
