Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
Am 10.08.2011 um 06:42 schrieb Paul Mackerras : > On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote: > >> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and >> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR >> mode. > > Don't we want to enable it only for 64-bit hosts? Trying to run a > PAPR guest on a 32-bit Book 3S host won't work very well, unless I am > missing something... I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts. And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU. It'd be a nightmare to check all configurations on every setter function. Unless... We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on vcpu_run. Alex > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Robin, On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote: > In working with the socketcan developers, we have come to the conclusion > the Documentation...fsl-flexcan.txt device tree documentation needs to > be cleaned up. The driver does not depend upon any properties other > than the required properties so we are removing the file. Additionally, > the p1010*dts* files are not following the standard for node naming in > that they have a trailing -v1.0. > > Signed-off-by: Robin Holt > To: Marc Kleine-Budde , > To: Wolfgang Grandegger , > To: U Bhaskar-B22300 > To: Scott Wood > Cc: socketcan-c...@lists.berlios.de, > Cc: net...@vger.kernel.org, > Cc: PPC list > Cc: Kumar Gala > --- > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 > > arch/powerpc/boot/dts/p1010rdb.dts |8 --- > arch/powerpc/boot/dts/p1010si.dtsi |8 +- > 3 files changed, 4 insertions(+), 73 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt I suggest that you set devicetree-disc...@lists.ozlabs.org and Grant Likely on Cc: for this patch. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: numa: Remove double of_node_put in hot_add_node_scn_to_nid
Hi Anton, On Wed, 10 Aug 2011 16:49:34 +1000 Anton Blanchard wrote: > > During memory hotplug testing, I got the following warning: > > > ERROR: Bad of_node_put() on /memory@0 > > of_find_node_by_type() loop does of_node_put for us so remove the > duplicate one inside the loop. But does an of_node_get() on its return value .. > Signed-off-by: Anton Blanchard > Cc: sta...@kernel.org > --- > > Index: linux-powerpc/arch/powerpc/mm/numa.c > === > --- linux-powerpc.orig/arch/powerpc/mm/numa.c 2011-06-06 08:07:35.148708089 > +1000 > +++ linux-powerpc/arch/powerpc/mm/numa.c 2011-08-10 11:31:59.723379868 > +1000 > @@ -1214,7 +1214,6 @@ int hot_add_node_scn_to_nid(unsigned lon > break; > } > > - of_node_put(memory); > if (nid >= 0) > break; > } Won't that need an of_node_put(memory) after the loop if (nid >= 0) ? In fact you should be able to just move the of_node_put(memory) to after the loop since of_node_put(NULL) is fine. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpCfk3jFaUpd.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
On 08/10/2011 05:06 AM, Robin Holt wrote:
> I added a simple clock source for the p1010rdb so the flexcan driver
> could determine a clock frequency. The p1010 can device only has an
> oscillator of system bus frequency divided by 2.
>
> Signed-off-by: Robin Holt
> Acked-by: Marc Kleine-Budde ,
> Acked-by: Wolfgang Grandegger ,
> To: U Bhaskar-B22300
> Cc: socketcan-c...@lists.berlios.de,
> Cc: net...@vger.kernel.org,
> Cc: PPC list
> Cc: Kumar Gala
> ---
> arch/powerpc/platforms/85xx/Kconfig|2 +
> arch/powerpc/platforms/85xx/Makefile |2 +
> arch/powerpc/platforms/85xx/clock.c| 53
>
> arch/powerpc/platforms/85xx/p1010rdb.c |8 +
> 4 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile
> b/arch/powerpc/platforms/85xx/Makefile
> index a971b32..cc7f381 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -3,6 +3,8 @@
> #
> obj-$(CONFIG_SMP) += smp.o
>
> +obj-$(CONFIG_PPC_CLOCK) += clock.o
> +
> obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
> diff --git a/arch/powerpc/platforms/85xx/clock.c
> b/arch/powerpc/platforms/85xx/clock.c
> new file mode 100644
> index 000..16fae04
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/clock.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright 2011 SGI, inc.
> + *
> + * This code is licensed for use under the GPL V2 as published by
> + * the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +/*
> + * p1010 needs to provide a clock source for the flexcan driver. The
> + * oscillator for the p1010 processor is only ever the system clock / 2.
> + */
> +
> +static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
> +{
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> +if (!dev->of_node ||
> +!of_device_is_compatible(dev->of_node, "fsl,flexcan"))
> +return ERR_PTR(-ENOENT);
> +
> + return NULL;
> +}
> +
> +static void mpc85xx_clk_put(struct clk *clk)
> +{
> + return;
> +}
> +
> +static unsigned long mpc85xx_clk_get_rate(struct clk *clk)
> +{
> + return fsl_get_sys_freq() / 2;
> +}
> +
> +static struct clk_interface mpc85xx_clk_functions = {
> + .clk_get = mpc85xx_clk_get,
> + .clk_get_rate = mpc85xx_clk_get_rate,
> + .clk_put = mpc85xx_clk_put,
> +};
> +
> +void __init mpc85xx_clk_init(void)
> +{
> + clk_functions = mpc85xx_clk_functions;
> +}
> +
git is even picker then me: "new blank line at EOF."
please fix
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c
> b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d7387fa..5e52122 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +extern void mpc85xx_clk_init(void);
> +
> +static void __init p1010_rdb_init(void)
> +{
> + mpc85xx_clk_init();
> +}
> +
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
On 08/10/2011 05:05 AM, Robin Holt wrote: > With all the patches applied, my p1010rdb works for communicating between > its two can ports and also can communicate with an external PSOC. I have > done no testing beyond compile testing on an arm system as I have no > access to an arm based system. > > For the first three patches in the series, I believe they are all ready > for forwarding to David S. Miller for the netdev tree. I think patch > 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed > from the previous post by adding a second compatible string for the > fsl,p1010_flexcan. One remark for the subjects. It seems no one is using "[$subsystem]" anymore, but rather "$subsystem:". cheers, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Grant, Do you need this patch resent with you on the Cc: list or can you pick up the discussion from here? I am just trying to minimize noise on the mailing lists if it is not needed. The essence of the discussion to this point is: 1) Freescale built a board support package for a new processor and eval board (p1010) based upon some older boards. 2) As part of that effort, they made changes as they saw fit to get it working without submitting those changes to the community. 3) In the case of the flexcan device, that included defining a device tree node for the integrated Controller Area Network device and set .compatible="fsl,flexcan-v1.0". Apparently this was copied from another device, possibly mscan. 4) In an effort to get my p1010rdb eval board working with a community kernel, I started submitting patches for flexcan which have evolved to the point of nearly being accepted with the exception of we need to settle on the node's .compatible= strings and whether it should be documented. 5) To this point, I believe the concensus has settled on "fsl,p1010-flexcan" and "fsl,flexcan" as the compatible strings. This leaves the most flexibility for segragating future specific revisions of the flexcan interface if needed. 6) I failed to Cc: you or the device tree list when I submitted version 10 of the patches. I have added both to the patch header so they will be included in the next pass. Thanks, Robin Holt On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote: > In working with the socketcan developers, we have come to the conclusion > the Documentation...fsl-flexcan.txt device tree documentation needs to > be cleaned up. The driver does not depend upon any properties other > than the required properties so we are removing the file. Additionally, > the p1010*dts* files are not following the standard for node naming in > that they have a trailing -v1.0. > > Signed-off-by: Robin Holt > To: Marc Kleine-Budde , > To: Wolfgang Grandegger , > To: U Bhaskar-B22300 > To: Scott Wood > Cc: socketcan-c...@lists.berlios.de, > Cc: net...@vger.kernel.org, > Cc: PPC list > Cc: Kumar Gala > --- > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 > > arch/powerpc/boot/dts/p1010rdb.dts |8 --- > arch/powerpc/boot/dts/p1010si.dtsi |8 +- > 3 files changed, 4 insertions(+), 73 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > deleted file mode 100644 > index 1a729f0..000 > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > +++ /dev/null > @@ -1,61 +0,0 @@ > -CAN Device Tree Bindings > - > -2011 Freescale Semiconductor, Inc. > - > -fsl,flexcan-v1.0 nodes > > -In addition to the required compatible-, reg- and interrupt-properties, you > can > -also specify which clock source shall be used for the controller. > - > -CPI Clock- Can Protocol Interface Clock > - This CLK_SRC bit of CTRL(control register) selects the clock source to > - the CAN Protocol Interface(CPI) to be either the peripheral clock > - (driven by the PLL) or the crystal oscillator clock. The selected clock > - is the one fed to the prescaler to generate the Serial Clock (Sclock). > - The PRESDIV field of CTRL(control register) controls a prescaler that > - generates the Serial Clock (Sclock), whose period defines the > - time quantum used to compose the CAN waveform. > - > -Can Engine Clock Source > - There are two sources for CAN clock > - - Platform Clock It represents the bus clock > - - Oscillator Clock > - > - Peripheral Clock (PLL) > - -- > - | > - - - > - | |CPI Clock| Prescaler | Sclock > - | |>| (1.. 256) |> > - - - > - | | > - -- -CLK_SRC > - Oscillator Clock > - > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects > - the peripheral clock. PLL clock is fed to the > - prescaler to generate the Serial Clock (Sclock). > - Valid values are "oscillator" and "platform" > - "oscillator": CAN engine clock source is > oscillator clock. > - "platform" The CAN engine clock source is the bus > clock > - (platform clock). > - > -- fsl,flexcan-clock-divider : for the reference and system clock, an > additional > - clock divider can be specified. > -- clock-frequ
Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote: > On 08/10/2011 05:05 AM, Robin Holt wrote: > > With all the patches applied, my p1010rdb works for communicating between > > its two can ports and also can communicate with an external PSOC. I have > > done no testing beyond compile testing on an arm system as I have no > > access to an arm based system. > > > > For the first three patches in the series, I believe they are all ready > > for forwarding to David S. Miller for the netdev tree. I think patch > > 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed > > from the previous post by adding a second compatible string for the > > fsl,p1010_flexcan. > > One remark for the subjects. It seems no one is using "[$subsystem]" > anymore, but rather "$subsystem:". I will, one day, get these patches subject lines correct ;) Did you happen to get a chance to test the patches on arm? Thanks, Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
On Wed, Aug 10, 2011 at 11:56:01AM +0200, Marc Kleine-Budde wrote:
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > diff --git a/arch/powerpc/platforms/85xx/clock.c
> > b/arch/powerpc/platforms/85xx/clock.c
> > new file mode 100644
> > index 000..16fae04
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/85xx/clock.c
> > @@ -0,0 +1,53 @@
...
> > +void __init mpc85xx_clk_init(void)
> > +{
> > + clk_functions = mpc85xx_clk_functions;
> > +}
> > +
>
> git is even picker then me: "new blank line at EOF."
> please fix
That reminded me that I have slacked on using checkpatch.pl in a few
resends and it really does not like this patch at all so I will rework
the patch with its concerns. I am going to hold off on resending until
there are more substantial changes.
Thanks,
Robin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
On 08/10/2011 12:11 PM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote: >> On 08/10/2011 05:05 AM, Robin Holt wrote: >>> With all the patches applied, my p1010rdb works for communicating between >>> its two can ports and also can communicate with an external PSOC. I have >>> done no testing beyond compile testing on an arm system as I have no >>> access to an arm based system. >>> >>> For the first three patches in the series, I believe they are all ready >>> for forwarding to David S. Miller for the netdev tree. I think patch >>> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed >>> from the previous post by adding a second compatible string for the >>> fsl,p1010_flexcan. >> >> One remark for the subjects. It seems no one is using "[$subsystem]" >> anymore, but rather "$subsystem:". > > I will, one day, get these patches subject lines correct ;) > > Did you happen to get a chance to test the patches on arm? It's still compiling... Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
On 08/10/2011 05:05 AM, Robin Holt wrote: > With all the patches applied, my p1010rdb works for communicating between > its two can ports and also can communicate with an external PSOC. I have > done no testing beyond compile testing on an arm system as I have no > access to an arm based system. > > For the first three patches in the series, I believe they are all ready > for forwarding to David S. Miller for the netdev tree. I think patch > 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed > from the previous post by adding a second compatible string for the > fsl,p1010_flexcan. This patch series is working on phytec's pcm043 (mx35) based on current net-next. Feel free to add my Acked-by to all patches. good work, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: numa: Remove double of_node_put in hot_add_node_scn_to_nid
Hi Stephen, > > Index: linux-powerpc/arch/powerpc/mm/numa.c > > === > > --- linux-powerpc.orig/arch/powerpc/mm/numa.c 2011-06-06 > > 08:07:35.148708089 +1000 +++ > > linux-powerpc/arch/powerpc/mm/numa.c2011-08-10 > > 11:31:59.723379868 +1000 @@ -1214,7 +1214,6 @@ int > > hot_add_node_scn_to_nid(unsigned lon break; } > > > > - of_node_put(memory); > > if (nid >= 0) > > break; > > } > > Won't that need an of_node_put(memory) after the loop if (nid >= > 0) ? In fact you should be able to just move the of_node_put(memory) > to after the loop since of_node_put(NULL) is fine. Nice catch! Will respin the patch. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote: > > Am 10.08.2011 um 06:42 schrieb Paul Mackerras : > > > On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote: > > > >> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and > >> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR > >> mode. > > > > Don't we want to enable it only for 64-bit hosts? Trying to run a > > PAPR guest on a 32-bit Book 3S host won't work very well, unless I am > > missing something... > > I agree that it doesn't make sense, but if anything we should > restrict it to 64-bit _guests_. you can also run 32-bit guests on > 64-bit hosts. I had a look in PAPR and I didn't find anything that says the processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible in theory. However, I don't think there are currently any 32-bit PAPR operating systems that would use hcalls. > And so far, we don't have a single interface setting PVR and PAPR > mode at the same time, so you could still enable PAPR with a 64-bit > guest CPU and then switch to a 32-bit CPU. > > It'd be a nightmare to check all configurations on every setter function. > > Unless... > > We could introduce a sanity check function that gets executed every > time we change PVR or enable PAPR. That could set a variable in the > vcpu struct to indicate that the config is ok. We could then check > that on vcpu_run. It's probably not worth worrying about it. The rest of the series looks very nice. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
On 08/10/2011 02:26 PM, Paul Mackerras wrote: On Wed, Aug 10, 2011 at 09:59:41AM +0200, Alexander Graf wrote: Am 10.08.2011 um 06:42 schrieb Paul Mackerras: On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote: Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR mode. Don't we want to enable it only for 64-bit hosts? Trying to run a PAPR guest on a 32-bit Book 3S host won't work very well, unless I am missing something... I agree that it doesn't make sense, but if anything we should restrict it to 64-bit _guests_. you can also run 32-bit guests on 64-bit hosts. I had a look in PAPR and I didn't find anything that says the processor has to be 64-bit, so I guess a 32-bit PAPR guest is possible in theory. However, I don't think there are currently any 32-bit PAPR operating systems that would use hcalls. That's what I figured :). The code flow we're affecting here is pretty much generic. And so far, we don't have a single interface setting PVR and PAPR mode at the same time, so you could still enable PAPR with a 64-bit guest CPU and then switch to a 32-bit CPU. It'd be a nightmare to check all configurations on every setter function. Unless... We could introduce a sanity check function that gets executed every time we change PVR or enable PAPR. That could set a variable in the vcpu struct to indicate that the config is ok. We could then check that on vcpu_run. It's probably not worth worrying about it. Too late, already implemented it :). It really does make sense to have some sort of checking here - even if it only means that our hypercall implementation can't handle it yet or that we didn't test it. And we can put the "HV KVM can only run PAPR" check in there as well. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 11/10] KVM: PPC: Add sanity checking to vcpu_run
There are multiple features in PowerPC KVM that can now be enabled
depending on the user's wishes. Some of the combinations don't make
sense or don't work though.
So this patch adds a way to check if the executing environment would
actually be able to run the guest properly. It also adds sanity
checks if PVR is set (should always be true given the current code
flow), if PAPR is only used with book3s_64 where it works and that
HV KVM is only used in PAPR mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm.h |5 +
arch/powerpc/include/asm/kvm_host.h |2 ++
arch/powerpc/include/asm/kvm_ppc.h |1 +
arch/powerpc/kvm/44x.c |2 ++
arch/powerpc/kvm/book3s_hv.c|8
arch/powerpc/kvm/book3s_pr.c| 10 ++
arch/powerpc/kvm/booke.c| 10 +-
arch/powerpc/kvm/e500.c |2 ++
arch/powerpc/kvm/powerpc.c | 28
9 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a6a253e..08fe69e 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -284,6 +284,11 @@ struct kvm_guest_debug_arch {
#define KVM_INTERRUPT_UNSET-2U
#define KVM_INTERRUPT_SET_LEVEL-3U
+#define KVM_CPU_4401
+#define KVM_CPU_E500V2 2
+#define KVM_CPU_3S_32 3
+#define KVM_CPU_3S_64 4
+
/* for KVM_CAP_SPAPR_TCE */
struct kvm_create_spapr_tce {
__u64 liobn;
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index e681302..2b8284f 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -390,6 +390,8 @@ struct kvm_vcpu_arch {
u8 osi_needed;
u8 osi_enabled;
u8 papr_enabled;
+ u8 sane;
+ u8 cpu_type;
u8 hcall_needed;
u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index d121f49..46efd1a 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -66,6 +66,7 @@ extern int kvmppc_emulate_instruction(struct kvm_run *run,
extern int kvmppc_emulate_mmio(struct kvm_run *run, struct kvm_vcpu *vcpu);
extern void kvmppc_emulate_dec(struct kvm_vcpu *vcpu);
extern u32 kvmppc_get_dec(struct kvm_vcpu *vcpu, u64 tb);
+extern int kvmppc_sanity_check(struct kvm_vcpu *vcpu);
/* Core-specific hooks */
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index da3a122..ca1f88b 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -78,6 +78,8 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
for (i = 0; i < ARRAY_SIZE(vcpu_44x->shadow_refs); i++)
vcpu_44x->shadow_refs[i].gtlb_index = -1;
+ vcpu->arch.cpu_type = KVM_CPU_440;
+
return 0;
}
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index cc0d7f1..830e07a 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -510,6 +510,9 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm,
unsigned int id)
spin_unlock(&vcore->lock);
vcpu->arch.vcore = vcore;
+ vcpu->arch.cpu_type = KVM_CPU_3S_64;
+ kvmppc_sanity_check(vcpu);
+
return vcpu;
free_vcpu:
@@ -800,6 +803,11 @@ int kvmppc_vcpu_run(struct kvm_run *run, struct kvm_vcpu
*vcpu)
{
int r;
+ if (!vcpu->arch.sane) {
+ kvm_run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
+ return -EINVAL;
+ }
+
do {
r = kvmppc_run_vcpu(run, vcpu);
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 48558f6..6e3488b 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -153,6 +153,7 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
if (!to_book3s(vcpu)->hior_sregs)
to_book3s(vcpu)->hior = 0xfff0;
to_book3s(vcpu)->msr_mask = 0xULL;
+ vcpu->arch.cpu_type = KVM_CPU_3S_64;
} else
#endif
{
@@ -160,8 +161,11 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
if (!to_book3s(vcpu)->hior_sregs)
to_book3s(vcpu)->hior = 0;
to_book3s(vcpu)->msr_mask = 0xULL;
+ vcpu->arch.cpu_type = KVM_CPU_3S_32;
}
+ kvmppc_sanity_check(vcpu);
+
/* If we are in hypervisor level on 970, we can tell the CPU to
* treat DCBZ as 32 bytes store */
vcpu->arch.hflags &= ~BOOK3S_HFLAG_DCBZ32;
@@ -938,6 +942,12 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
#endif
ulong ext_msr;
+ /* Check if we can run the vcpu at all */
+ if (!vcpu->arch.sane) {
+ kvm_run->exit_reason = KVM_EXIT_INT
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
Hi Robin,
On 08/10/2011 05:06 AM, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
Your first sentence could be misleading. Please just describe what the
patch does and why, something like:
"This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not needed as the frequency of the source clock is
fixed..." and so on.
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
> Signed-off-by: Robin Holt
> To: Marc Kleine-Budde ,
> To: Wolfgang Grandegger ,
> To: U Bhaskar-B22300
> To: Scott Wood
> Cc: socketcan-c...@lists.berlios.de,
> Cc: net...@vger.kernel.org,
> Cc: PPC list
> Cc: Kumar Gala
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt| 61
>
> arch/powerpc/boot/dts/p1010rdb.dts |8 ---
> arch/powerpc/boot/dts/p1010si.dtsi |8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> deleted file mode 100644
> index 1a729f0..000
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -CAN Device Tree Bindings
> -
> -2011 Freescale Semiconductor, Inc.
> -
> -fsl,flexcan-v1.0 nodes
>
> -In addition to the required compatible-, reg- and interrupt-properties, you
> can
> -also specify which clock source shall be used for the controller.
> -
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> -
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> -
> - Peripheral Clock (PLL)
> - --
> - |
> - - -
> - | |CPI Clock| Prescaler | Sclock
> - | |>| (1.. 256) |>
> - - -
> - | |
> - -- -CLK_SRC
> - Oscillator Clock
> -
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is
> oscillator clock.
> - "platform" The CAN engine clock source is the bus
> clock
> - (platform clock).
> -
> -- fsl,flexcan-clock-divider : for the reference and system clock, an
> additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> -
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divqider = <2>;
> - clock-frequency = ;
> - };
Do we really want to drop the documentation for that binding. I think
something like the following text would be still useful:
Flexcan CAN contoller on Freescale's ARM and PowerPC processors
Required properties:
- compatible : Should be "fsl,flexcan" and optionally
"fsl,flexcan-"
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Example:
can@1c000 {
compatible = "fsl,p1010-flexcan", "fsl,flexcan";
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> Hi Robin,
>
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > In working with the socketcan developers, we have come to the conclusion
> > the Documentation...fsl-flexcan.txt device tree documentation needs to
> > be cleaned up. The driver does not depend upon any properties other
>
> Your first sentence could be misleading. Please just describe what the
> patch does and why, something like:
>
> "This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not needed as the frequency of the source clock is
> fixed..." and so on.
I borrowed heavily from your message. ;)
> > than the required properties so we are removing the file. Additionally,
> > the p1010*dts* files are not following the standard for node naming in
> > that they have a trailing -v1.0.
>
> > Signed-off-by: Robin Holt
> > To: Marc Kleine-Budde ,
> > To: Wolfgang Grandegger ,
> > To: U Bhaskar-B22300
> > To: Scott Wood
> > Cc: socketcan-c...@lists.berlios.de,
> > Cc: net...@vger.kernel.org,
> > Cc: PPC list
> > Cc: Kumar Gala
> > ---
> > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61
> >
> > arch/powerpc/boot/dts/p1010rdb.dts |8 ---
> > arch/powerpc/boot/dts/p1010si.dtsi |8 +-
> > 3 files changed, 4 insertions(+), 73 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > deleted file mode 100644
> > index 1a729f0..000
> > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > +++ /dev/null
> > @@ -1,61 +0,0 @@
> > -CAN Device Tree Bindings
> > -
> > -2011 Freescale Semiconductor, Inc.
> > -
> > -fsl,flexcan-v1.0 nodes
> >
> > -In addition to the required compatible-, reg- and interrupt-properties,
> > you can
> > -also specify which clock source shall be used for the controller.
> > -
> > -CPI Clock- Can Protocol Interface Clock
> > - This CLK_SRC bit of CTRL(control register) selects the clock source to
> > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > - (driven by the PLL) or the crystal oscillator clock. The selected clock
> > - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> > - The PRESDIV field of CTRL(control register) controls a prescaler that
> > - generates the Serial Clock (Sclock), whose period defines the
> > - time quantum used to compose the CAN waveform.
> > -
> > -Can Engine Clock Source
> > - There are two sources for CAN clock
> > - - Platform Clock It represents the bus clock
> > - - Oscillator Clock
> > -
> > - Peripheral Clock (PLL)
> > - --
> > -|
> > - - -
> > - | |CPI Clock| Prescaler | Sclock
> > - | |>| (1.. 256) |>
> > - - -
> > - | |
> > - -- -CLK_SRC
> > - Oscillator Clock
> > -
> > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> > -the peripheral clock. PLL clock is fed to the
> > -prescaler to generate the Serial Clock (Sclock).
> > -Valid values are "oscillator" and "platform"
> > -"oscillator": CAN engine clock source is
> > oscillator clock.
> > -"platform" The CAN engine clock source is the bus
> > clock
> > -(platform clock).
> > -
> > -- fsl,flexcan-clock-divider : for the reference and system clock, an
> > additional
> > - clock divider can be specified.
> > -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> > -
> > -Note:
> > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> > - - P1010 does not have oscillator as the Clock Source.So the default
> > - Clock Source is platform clock.
> > -Examples:
> > -
> > - can0@1c000 {
> > - compatible = "fsl,flexcan-v1.0";
> > - reg = <0x1c000 0x1000>;
> > - interrupts = <48 0x2>;
> > - interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-source = "platform";
> > - fsl,flexcan-clock-divqider = <2>;
> > - clock-frequency = ;
> > - };
>
> Do we really want to drop the documentation for that binding. I think
> something like the following text would be still useful:
>
>
> Flexcan CAN contoller on Freescale's ARM and PowerPC processors
>
> Required properties:
>
> - comp
Re: [PATCH v10 3/5] [flexcan] Add of_match to platform_device definition.
On Tue, Aug 09, 2011 at 10:06:02PM -0500, Robin Holt wrote:
> On powerpc, the OpenFirmware devices are not matched without specifying
> an of_match array. Introduce that array as that is used for matching
> on the Freescale P1010 processor.
>
> Signed-off-by: Robin Holt
> To: Marc Kleine-Budde
> Acked-by: Wolfgang Grandegger
> To: U Bhaskar-B22300
> Cc: socketcan-c...@lists.berlios.de
> Cc: net...@vger.kernel.org
> Cc: PPC list
> ---
> drivers/net/can/flexcan.c | 13 -
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index 68cbe52..662f832 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> +static struct of_device_id flexcan_of_match[] = {
> + {
> + .compatible = "fsl,flexcan",
Let me make sure I have this correct. At this point, we would want it
to be fsl,flexcan here. If, at some point, we find the i.MX-wonderful
has diverged from the -p1010, we would, at that point in the code, use
of_device_is_compatible to differentiate the two, correct? That would
mean we should make no change to this patch for the fsl,flexcan-p1010,
right?
Robin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
> -Original Message-
> From: Robin Holt [mailto:h...@sgi.com]
> Sent: Wednesday, August 10, 2011 7:46 PM
> To: Wolfgang Grandegger
> Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421;
> net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC
> list
> Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree
> binding.
>
> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> > Hi Robin,
> >
> > On 08/10/2011 05:06 AM, Robin Holt wrote:
> > > In working with the socketcan developers, we have come to the
> > > conclusion the Documentation...fsl-flexcan.txt device tree
> > > documentation needs to be cleaned up. The driver does not depend
> > > upon any properties other
> >
> > Your first sentence could be misleading. Please just describe what the
> > patch does and why, something like:
> >
> > "This patch cleans up the documentation of the device-tree binding for
> > the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> > properties are not needed as the frequency of the source clock is
> > fixed..." and so on.
>
> I borrowed heavily from your message. ;)
>
> > > than the required properties so we are removing the file.
> > > Additionally, the p1010*dts* files are not following the standard
> > > for node naming in that they have a trailing -v1.0.
> >
> > > Signed-off-by: Robin Holt
> > > To: Marc Kleine-Budde ,
> > > To: Wolfgang Grandegger ,
> > > To: U Bhaskar-B22300
> > > To: Scott Wood
> > > Cc: socketcan-c...@lists.berlios.de,
> > > Cc: net...@vger.kernel.org,
> > > Cc: PPC list
> > > Cc: Kumar Gala
> > > ---
> > > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 --
> --
> > > arch/powerpc/boot/dts/p1010rdb.dts |8 ---
> > > arch/powerpc/boot/dts/p1010si.dtsi |8 +-
> > > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode
> > > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > deleted file mode 100644
> > > index 1a729f0..000
> > > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > > +++ /dev/null
> > > @@ -1,61 +0,0 @@
> > > -CAN Device Tree Bindings
> > > -
> > > -2011 Freescale Semiconductor, Inc.
> > > -
> > > -fsl,flexcan-v1.0 nodes
> > >
> > > -In addition to the required compatible-, reg- and
> > > interrupt-properties, you can -also specify which clock source shall
> be used for the controller.
> > > -
> > > -CPI Clock- Can Protocol Interface Clock
> > > - This CLK_SRC bit of CTRL(control register) selects the clock source
> to
> > > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > > - (driven by the PLL) or the crystal oscillator clock. The selected
> clock
> > > - is the one fed to the prescaler to generate the Serial Clock
> (Sclock).
> > > - The PRESDIV field of CTRL(control register) controls a prescaler
> that
> > > - generates the Serial Clock (Sclock), whose period defines the
> > > - time quantum used to compose the CAN waveform.
> > > -
> > > -Can Engine Clock Source
> > > - There are two sources for CAN clock
> > > - - Platform Clock It represents the bus clock
> > > - - Oscillator Clock
> > > -
> > > - Peripheral Clock (PLL)
> > > - --
> > > - |
> > > - - -
> > > - | |CPI Clock| Prescaler | Sclock
> > > - | |>| (1.. 256) |>
> > > - - -
> > > - | |
> > > - -- -CLK_SRC
> > > - Oscillator Clock
> > > -
> > > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property
> selects
> > > - the peripheral clock. PLL clock is fed to the
> > > - prescaler to generate the Serial Clock (Sclock).
> > > - Valid values are "oscillator" and "platform"
> > > - "oscillator": CAN engine clock source is
> oscillator clock.
> > > - "platform" The CAN engine clock source is the bus
> clock
> > > - (platform clock).
> > > -
> > > -- fsl,flexcan-clock-divider : for the reference and system clock, an
> additional
> > > - clock divider can be specified.
> > > -- clock-frequency: frequency required to calculate the bitrate for
> FlexCAN.
> > > -
> > > -Note:
> > > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010
> SOC.
> > > - - P1010 does not have oscillator as the Clock Source.So the default
> > > - Clock Source is platform clock.
> > > -Examples:
> > > -
> > > - can0@1c000 {
> > > - compatible = "fsl,flexcan-v1.0";
> > > - reg = <0x1
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On 08/10/2011 04:15 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
...
> Done, except the
>> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
>
> line is
> compatible = "fsl,flexcan", "fsl,flexcan-p1010";
IIRC, there order is more to less specific, e.g. for I2C:
compatible = "fsl,mpc5200-i2c", "fsl-i2c"
...
>> Please also correct the node names (not using the number suffix).
>
> So the node names should be
> can@1c000 {
> can@1d000 {
> correct?
Yes, just have a look how other node names are constructed, e.g. for
sata, serial, rtc, etc.:
$ grep serial@ *.dts
...
pdm360ng.dts: serial@11000 {
pdm360ng.dts: serial@11100 {
pdm360ng.dts: serial@11200 {
pdm360ng.dts: serial@11300 {
pdm360ng.dts: serial@11400 {
pdm360ng.dts: serial@11600 {
pdm360ng.dts: serial@11800 {
pdm360ng.dts: serial@11B00 {
...
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Aug 10, 2011, at 9:15 AM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: >> Hi Robin, >> >> On 08/10/2011 05:06 AM, Robin Holt wrote: >>> In working with the socketcan developers, we have come to the conclusion >>> the Documentation...fsl-flexcan.txt device tree documentation needs to >>> be cleaned up. The driver does not depend upon any properties other >> >> Your first sentence could be misleading. Please just describe what the >> patch does and why, something like: >> >> "This patch cleans up the documentation of the device-tree binding for >> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra >> properties are not needed as the frequency of the source clock is >> fixed..." and so on. > > I borrowed heavily from your message. ;) > >>> than the required properties so we are removing the file. Additionally, >>> the p1010*dts* files are not following the standard for node naming in >>> that they have a trailing -v1.0. >> >>> Signed-off-by: Robin Holt >>> To: Marc Kleine-Budde , >>> To: Wolfgang Grandegger , >>> To: U Bhaskar-B22300 >>> To: Scott Wood >>> Cc: socketcan-c...@lists.berlios.de, >>> Cc: net...@vger.kernel.org, >>> Cc: PPC list >>> Cc: Kumar Gala >>> --- >>> .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 >>> >>> arch/powerpc/boot/dts/p1010rdb.dts |8 --- >>> arch/powerpc/boot/dts/p1010si.dtsi |8 +- >>> 3 files changed, 4 insertions(+), 73 deletions(-) >>> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt I don't understand how we can do this? What binding spec covers the P1010 CAN support if you remove this? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Aug 10, 2011, at 9:41 AM, Wolfgang Grandegger wrote:
> On 08/10/2011 04:15 PM, Robin Holt wrote:
>> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> ...
>> Done, except the
>>> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
>>
>> line is
>> compatible = "fsl,flexcan", "fsl,flexcan-p1010";
>
> IIRC, there order is more to less specific, e.g. for I2C:
>
> compatible = "fsl,mpc5200-i2c", "fsl-i2c"
>
> ...
>
>>> Please also correct the node names (not using the number suffix).
>>
>> So the node names should be
>> can@1c000 {
>> can@1d000 {
>> correct?
>
> Yes, just have a look how other node names are constructed, e.g. for
> sata, serial, rtc, etc.:
>
> $ grep serial@ *.dts
> ...
> pdm360ng.dts:serial@11000 {
> pdm360ng.dts:serial@11100 {
> pdm360ng.dts:serial@11200 {
> pdm360ng.dts:serial@11300 {
> pdm360ng.dts:serial@11400 {
> pdm360ng.dts:serial@11600 {
> pdm360ng.dts:serial@11800 {
> pdm360ng.dts:serial@11B00 {
> ...
>
> Wolfgang.
Agree w/Wolfgang here, can@1c000, can@1d000 is what we should use.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Aug 9, 2011, at 3:59 PM, Robin Holt wrote: > I guess my poor wording may have gotten me in trouble. I am getting > ready to repost this patch, but I want to ensure I am getting it as > right as possible. > > I think I should reword the commit message to indicate we are removing > the Documentation/.../fsl-flexcan.txt file which has essentially become > empty and change the p1010si.dtsi file's can nodes to "fsl,p1010-flexcan", > "fsl,flexcan". Is that correct? > > Thanks, > Robin This is wrong. Again, what binding covers "fsl,flexcan" if you remove fsl-flexcan.txt: [galak@right powerpc]$ git grep flexcan Documentation/devicetree/bindings Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:fsl,flexcan-v1.0 nodes Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- fsl,flexcan-clock-divider : for the reference and system clock, an additional Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC. Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: compatible = "fsl,flexcan-v1.0"; Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: fsl,flexcan-clock-source = "platform"; Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: fsl,flexcan-clock-divider = <2>; Not seeing anything that covers it. I think the issue should be resolved by patching fsl-flexcan.txt to remove wording or update it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/kvm: fix build errors with older toolchains
On 08/03/2011 08:55 PM, Nishanth Aravamudan wrote: On a box with gcc 4.3.2, I see errors like: arch/powerpc/kvm/book3s_hv_rmhandlers.S:1254: Error: Unrecognized opcode: stxvd2x arch/powerpc/kvm/book3s_hv_rmhandlers.S:1316: Error: Unrecognized opcode: lxvd2x Paul, mind to ack? Alex Signed-off-by: Nishanth Aravamudan --- arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index 6dd3358..de29501 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -1251,7 +1251,7 @@ BEGIN_FTR_SECTION reg = 0 .rept 32 li r6,reg*16+VCPU_VSRS - stxvd2x reg,r6,r3 + STXVD2X(reg,r6,r3) reg = reg + 1 .endr FTR_SECTION_ELSE @@ -1313,7 +1313,7 @@ BEGIN_FTR_SECTION reg = 0 .rept 32 li r7,reg*16+VCPU_VSRS - lxvd2x reg,r7,r4 + LXVD2X(reg,r7,r4) reg = reg + 1 .endr FTR_SECTION_ELSE ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few fixes for powerpc. Mostly innocuous stuff, in fact most of it has been in my tree for a while, I just hadn't got a chance to actually send it as I was travelling. Cheers, Ben. The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03: Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 (2011-08-04 06:37:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git ..BRANCH.NOT.VERIFIED.. Anatolij Gustschin (1): MAINTAINERS: change maintainership of mpc5xxx Anton Blanchard (10): powerpc: Fix device tree claim code powerpc: Clean up some panic messages in prom_init powerpc: Jump label misalignment causes oops at boot powerpc: pseries: Fix kexec on machines with more than 4TB of RAM powerpc: Move kdump default base address to half RMO size on 64bit powerpc: Lack of ibm,io-events not that important! powerpc: Make KVM_GUEST default to n powerpc/pseries: Fix kexec on recent firmware versions powerpc/pseries: Cleanup VPA registration and deregistration errors powerpc/pseries: Simplify vpa deregistration functions Benjamin Herrenschmidt (3): powerpc/4xx: Fix build of PCI code on 405 powerpc: Fix build without CONFIG_PCI powerpc: Really fix build without CONFIG_PCI David Ahern (1): powerpc/perf: Disable pagefaults during callchain stack read Nishanth Aravamudan (1): powerpc/kvm: Fix build errors with older toolchains Peter Zijlstra (1): ppc: Remove duplicate definition of PV_POWER7 Scott Wood (2): powerpc: mtspr/mtmsr should take an unsigned long powerpc: Return the_cpu_ spec from identify_cpu MAINTAINERS |4 +- arch/powerpc/include/asm/jump_label.h |2 - arch/powerpc/include/asm/kdump.h| 10 --- arch/powerpc/include/asm/reg.h |8 +++-- arch/powerpc/kernel/cputable.c | 11 --- arch/powerpc/kernel/iomap.c |2 + arch/powerpc/kernel/machine_kexec.c | 10 +-- arch/powerpc/kernel/perf_callchain.c| 20 +++-- arch/powerpc/kernel/prom_init.c | 14 + arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 +- arch/powerpc/platforms/Kconfig |2 +- arch/powerpc/platforms/pseries/dtl.c|2 +- arch/powerpc/platforms/pseries/hotplug-cpu.c|4 +- arch/powerpc/platforms/pseries/io_event_irq.c |8 ++--- arch/powerpc/platforms/pseries/kexec.c | 34 +++ arch/powerpc/platforms/pseries/lpar.c | 19 ++--- arch/powerpc/platforms/pseries/plpar_wrappers.h | 12 arch/powerpc/platforms/pseries/setup.c |5 ++- arch/powerpc/sysdev/ppc4xx_pci.c|5 ++- 19 files changed, 99 insertions(+), 77 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 09:45:17AM -0500, Kumar Gala wrote: > > On Aug 10, 2011, at 9:15 AM, Robin Holt wrote: > > > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: > >> Hi Robin, > >> > >> On 08/10/2011 05:06 AM, Robin Holt wrote: > >>> In working with the socketcan developers, we have come to the conclusion > >>> the Documentation...fsl-flexcan.txt device tree documentation needs to > >>> be cleaned up. The driver does not depend upon any properties other > >> > >> Your first sentence could be misleading. Please just describe what the > >> patch does and why, something like: > >> > >> "This patch cleans up the documentation of the device-tree binding for > >> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra > >> properties are not needed as the frequency of the source clock is > >> fixed..." and so on. > > > > I borrowed heavily from your message. ;) > > > >>> than the required properties so we are removing the file. Additionally, > >>> the p1010*dts* files are not following the standard for node naming in > >>> that they have a trailing -v1.0. > >> > >>> Signed-off-by: Robin Holt > >>> To: Marc Kleine-Budde , > >>> To: Wolfgang Grandegger , > >>> To: U Bhaskar-B22300 > >>> To: Scott Wood > >>> Cc: socketcan-c...@lists.berlios.de, > >>> Cc: net...@vger.kernel.org, > >>> Cc: PPC list > >>> Cc: Kumar Gala > >>> --- > >>> .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 > >>> > >>> arch/powerpc/boot/dts/p1010rdb.dts |8 --- > >>> arch/powerpc/boot/dts/p1010si.dtsi |8 +- > >>> 3 files changed, 4 insertions(+), 73 deletions(-) > >>> delete mode 100644 > >>> Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > I don't understand how we can do this? What binding spec covers the P1010 > CAN support if you remove this? We have added it back in based upon an earlier comment from Wolfgang. I will post a new version shortly. Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
On Wed, Aug 10, 2011 at 1:21 AM, Baruch Siach wrote: > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus > breaking clear_pages(), probably others too. > > This patch adds a new "Processor Type" entry for e500mc, and makes e500 > systems > depend on PPC_E500_V1_V2. Isn't the original invalid configuration still possible, i.e. I can choose E500_V1_V2 and also E500MC at the same time, unless you add something like a "depends !E500MC" to your new V1_V2 option? Alternatively, you could treat it like using i386 kernel on a modern core by taking the LCD for the L1_CACHE_SHIFT of the configured in platforms. I have booted a kernel built for an mpc8548 core on a P4080 CPU, so that does work (with only minimal dts fiddling). And it keeps the ability to boot one kernel on several platforms open (one of the reasons for the ppc --> powerpc shuffle a couple of years ago...) Paul. > > Cc: Kumar Gala > Signed-off-by: Baruch Siach > --- > > Changes from v2: > > * s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ to avoid confusion as > noted by Scott Wood > > Changes from v1: > > * Rebase on 3.1-rc1 > > * Remove the list of processor families from the PPC_E500 and > PPC_E500MC options description. The P20xx can be either e500v2 or > e500mc. > > arch/powerpc/platforms/85xx/Kconfig | 13 + > arch/powerpc/platforms/Kconfig.cputype | 27 +++ > 2 files changed, 24 insertions(+), 16 deletions(-) > > diff --git a/arch/powerpc/platforms/85xx/Kconfig > b/arch/powerpc/platforms/85xx/Kconfig > index 498534c..00d4720 100644 > --- a/arch/powerpc/platforms/85xx/Kconfig > +++ b/arch/powerpc/platforms/85xx/Kconfig > @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE > > if PPC32 > > +if PPC_E500_V1_V2 > + > config MPC8540_ADS > bool "Freescale MPC8540 ADS" > select DEFAULT_UIMAGE > @@ -171,10 +173,13 @@ config SBC8560 > help > This option enables support for the Wind River SBC8560 board > > +endif # PPC_E500_V1_V2 > + > +if PPC_E500MC > + > config P2040_RDB > bool "Freescale P2040 RDB" > select DEFAULT_UIMAGE > - select PPC_E500MC > select PHYS_64BIT > select SWIOTLB > select MPC8xxx_GPIO > @@ -186,7 +191,6 @@ config P2040_RDB > config P3041_DS > bool "Freescale P3041 DS" > select DEFAULT_UIMAGE > - select PPC_E500MC > select PHYS_64BIT > select SWIOTLB > select MPC8xxx_GPIO > @@ -198,7 +202,6 @@ config P3041_DS > config P4080_DS > bool "Freescale P4080 DS" > select DEFAULT_UIMAGE > - select PPC_E500MC > select PHYS_64BIT > select SWIOTLB > select MPC8xxx_GPIO > @@ -207,13 +210,15 @@ config P4080_DS > help > This option enables support for the P4080 DS board > > +endif # PPC_E500MC > + > endif # PPC32 > > config P5020_DS > bool "Freescale P5020 DS" > + depends on PPC_E500MC > select DEFAULT_UIMAGE > select E500 > - select PPC_E500MC > select PHYS_64BIT > select SWIOTLB > select MPC8xxx_GPIO > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index e06e395..e6cb00c 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -10,13 +10,13 @@ choice > prompt "Processor Type" > depends on PPC32 > help > - There are five families of 32 bit PowerPC chips supported. > + There are six families of 32 bit PowerPC chips supported. > The most common ones are the desktop and server CPUs (601, 603, > 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their > embedded 512x/52xx/82xx/83xx/86xx counterparts. > - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500 > - (85xx) each form a family of their own that is not compatible > - with the others. > + The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500 > + (85xx), and e500mc each form a family of their own that is not > + compatible with the others. > > If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx. > > @@ -24,10 +24,15 @@ config PPC_BOOK3S_32 > bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" > select PPC_FPU > > -config PPC_85xx > - bool "Freescale 85xx" > +config PPC_E500_V1_V2 > + bool "Freescale e500v1/e500v2" > + select PPC_85xx > select E500 > > +config PPC_E500MC > + bool "Freescale e500mc/e5500" > + select PPC_85xx > + > config PPC_8xx > bool "Freescale 8xx" > select FSL_SOC > @@ -128,15 +133,13 @@ config TUNE_CELL > config 8xx > bool > > -config E500 > +config PPC_85xx > + bool > select FSL_EMB_PERFMON > select PPC_FSL_BOOK3E > - bool > > -config PPC_E500MC > - bool "e500mc Support" > - select PPC_FPU > - depe
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote: > > > > -Original Message- > > From: Robin Holt [mailto:h...@sgi.com] > > Sent: Wednesday, August 10, 2011 7:46 PM > > To: Wolfgang Grandegger > > Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421; > > net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC > > list > > Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree > > binding. > > > > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: > > > Hi Robin, > > > > > > On 08/10/2011 05:06 AM, Robin Holt wrote: > > > > In working with the socketcan developers, we have come to the > > > > conclusion the Documentation...fsl-flexcan.txt device tree > > > > documentation needs to be cleaned up. The driver does not depend > > > > upon any properties other > > > > > > Your first sentence could be misleading. Please just describe what the > > > patch does and why, something like: > > > > > > "This patch cleans up the documentation of the device-tree binding for > > > the Flexcan devices on Freescale's PowerPC and ARM cores. Extra > > > properties are not needed as the frequency of the source clock is > > > fixed..." and so on. > > > > I borrowed heavily from your message. ;) > > > > > > than the required properties so we are removing the file. > > > > Additionally, the p1010*dts* files are not following the standard > > > > for node naming in that they have a trailing -v1.0. > > > > > > > Signed-off-by: Robin Holt > > > > To: Marc Kleine-Budde , > > > > To: Wolfgang Grandegger , > > > > To: U Bhaskar-B22300 > > > > To: Scott Wood > > > > Cc: socketcan-c...@lists.berlios.de, > > > > Cc: net...@vger.kernel.org, > > > > Cc: PPC list > > > > Cc: Kumar Gala > > > > --- > > > > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 -- > > -- > > > > arch/powerpc/boot/dts/p1010rdb.dts |8 --- > > > > arch/powerpc/boot/dts/p1010si.dtsi |8 +- > > > > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode > > > > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > > > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > > > deleted file mode 100644 > > > > index 1a729f0..000 > > > > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > > > +++ /dev/null > > > > @@ -1,61 +0,0 @@ > > > > -CAN Device Tree Bindings > > > > - > > > > -2011 Freescale Semiconductor, Inc. > > > > - > > > > -fsl,flexcan-v1.0 nodes > > > > > > > > -In addition to the required compatible-, reg- and > > > > interrupt-properties, you can -also specify which clock source shall > > be used for the controller. > > > > - > > > > -CPI Clock- Can Protocol Interface Clock > > > > - This CLK_SRC bit of CTRL(control register) selects the clock > > > > source > > to > > > > - the CAN Protocol Interface(CPI) to be either the peripheral > > > > clock > > > > - (driven by the PLL) or the crystal oscillator clock. The > > > > selected > > clock > > > > - is the one fed to the prescaler to generate the Serial Clock > > (Sclock). > > > > - The PRESDIV field of CTRL(control register) controls a prescaler > > that > > > > - generates the Serial Clock (Sclock), whose period defines the > > > > - time quantum used to compose the CAN waveform. > > > > - > > > > -Can Engine Clock Source > > > > - There are two sources for CAN clock > > > > - - Platform Clock It represents the bus clock > > > > - - Oscillator Clock > > > > - > > > > - Peripheral Clock (PLL) > > > > - -- > > > > -| > > > > - - - > > > > - | |CPI Clock| Prescaler | Sclock > > > > - | |>| (1.. 256) |> > > > > - - - > > > > - | | > > > > - -- -CLK_SRC > > > > - Oscillator Clock > > > > - > > > > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property > > selects > > > > -the peripheral clock. PLL clock is fed to > > > > the > > > > -prescaler to generate the Serial Clock > > > > (Sclock). > > > > -Valid values are "oscillator" and > > > > "platform" > > > > -"oscillator": CAN engine clock source is > > oscillator clock. > > > > -"platform" The CAN engine clock source is > > > > the bus > > clock > > > > -(platform clock). > > > > - > > > > -- fsl,flexcan-clock-divider : for the reference and system clock, a
Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
On 08/10/2011 10:39 AM, Paul Gortmaker wrote: > On Wed, Aug 10, 2011 at 1:21 AM, Baruch Siach wrote: >> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, >> thus >> breaking clear_pages(), probably others too. >> >> This patch adds a new "Processor Type" entry for e500mc, and makes e500 >> systems >> depend on PPC_E500_V1_V2. > > Isn't the original invalid configuration still possible, i.e. I can > choose E500_V1_V2 > and also E500MC at the same time, unless you add something like a > "depends !E500MC" to your new V1_V2 option? They're members of a "choice", not standalone bools -- so they're mutually exclusive. > Alternatively, you could treat it like using i386 kernel on a modern > core by taking > the LCD for the L1_CACHE_SHIFT of the configured in platforms. For alignment you want to err on the high side, but for invalidation you want to err on the low side. For dcbz you can't err at all. And there are other issues than cache size with combining e500v2 and e500mc. Could it be done with sufficient hoop-jumping? Probably. Is it worth it? No. These chips don't even have compatible userspace, unless you use soft-float. > I have booted > a kernel built for an mpc8548 core on a P4080 CPU, so that does work (with > only > minimal dts fiddling). The opposite direction does not work, and simply booting doesn't mean there wouldn't be issues in running that kernel on a p4080 (floating point? bad cache size information being given to userspace? emulation of non-cacheable dcbz? performance?). What dts fiddling? > And it keeps the ability to boot one kernel on several > platforms open (one of the reasons for the ppc --> powerpc shuffle a couple > of years ago...) It's much better than the arch/ppc way of a separate kernel build for every board. Beyond a certain point there are diminishing returns on the effort. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 09:52:07AM -0500, Kumar Gala wrote: > > On Aug 9, 2011, at 3:59 PM, Robin Holt wrote: > > > I guess my poor wording may have gotten me in trouble. I am getting > > ready to repost this patch, but I want to ensure I am getting it as > > right as possible. > > > > I think I should reword the commit message to indicate we are removing > > the Documentation/.../fsl-flexcan.txt file which has essentially become > > empty and change the p1010si.dtsi file's can nodes to "fsl,p1010-flexcan", > > "fsl,flexcan". Is that correct? > > > > Thanks, > > Robin > > This is wrong. Again, what binding covers "fsl,flexcan" if you remove > fsl-flexcan.txt: > > [galak@right powerpc]$ git grep flexcan Documentation/devicetree/bindings > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:fsl,flexcan-v1.0 > nodes > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- > fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt:- > fsl,flexcan-clock-divider : for the reference and system clock, an additional > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: - v1.0 of > flexcan-v1.0 represent the IP block version for P1010 SOC. > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: > compatible = "fsl,flexcan-v1.0"; > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: > fsl,flexcan-clock-source = "platform"; > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt: > fsl,flexcan-clock-divider = <2>; > > Not seeing anything that covers it. > > I think the issue should be resolved by patching fsl-flexcan.txt to remove > wording or update it. Done. Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v11 0/5] flexcan/powerpc: Add support for powerpc flexcan (freescale p1010)
With all the patches applied, my p1010rdb works for communicating between its two can ports and also can communicate with an external PSOC. I have done no testing beyond compile testing on an arm system as I have no access to an arm based system. For the first three patches in the series, I believe they are all ready for forwarding to David S. Miller for the netdev tree. I think patch 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed from the previous post by adding a second compatible string for the fsl,flexcan-p1010 and bringing back the Documentation file in a more correct form. Thanks, Robin Holt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v11 1/5] flexcan: Remove #include
powerpc does not have a mach-/clock.h. When testing, I found neither arm nor powerpc needed the mach/clock.h at all so I removed it. Signed-off-by: Robin Holt Acked-by: Marc Kleine-Budde Acked-by: Wolfgang Grandegger Cc: U Bhaskar-B22300 Cc: socketcan-c...@lists.berlios.de Cc: net...@vger.kernel.org Cc: PPC list --- drivers/net/can/flexcan.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index 1767811..586b2cd 100644 --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -35,8 +35,6 @@ #include #include -#include - #define DRV_NAME "flexcan" /* 8 for RX fifo and 2 error handling */ -- 1.7.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v11 2/5] flexcan: Abstract off read/write for big/little endian.
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
Cc: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kernel.org
Cc: PPC list
---
drivers/net/can/flexcan.c | 140 ++--
1 files changed, 83 insertions(+), 57 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 586b2cd..68cbe52 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -190,6 +190,31 @@ static struct can_bittiming_const flexcan_bittiming_const
= {
};
/*
+ * Abstract off the read/write for arm versus ppc.
+ */
+#if defined(__BIG_ENDIAN)
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return in_be32(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ out_be32(addr, val);
+}
+#else
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return readl(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ writel(val, addr);
+}
+#endif
+
+/*
* Swtich transceiver on or off
*/
static void flexcan_transceiver_switch(const struct flexcan_priv *priv, int on)
@@ -210,9 +235,9 @@ static inline void flexcan_chip_enable(struct flexcan_priv
*priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg &= ~FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
udelay(10);
}
@@ -222,9 +247,9 @@ static inline void flexcan_chip_disable(struct flexcan_priv
*priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
}
static int flexcan_get_berr_counter(const struct net_device *dev,
@@ -232,7 +257,7 @@ static int flexcan_get_berr_counter(const struct net_device
*dev,
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
- u32 reg = readl(®s->ecr);
+ u32 reg = flexcan_read(®s->ecr);
bec->txerr = (reg >> 0) & 0xff;
bec->rxerr = (reg >> 8) & 0xff;
@@ -266,15 +291,15 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct
net_device *dev)
if (cf->can_dlc > 0) {
u32 data = be32_to_cpup((__be32 *)&cf->data[0]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
}
if (cf->can_dlc > 3) {
u32 data = be32_to_cpup((__be32 *)&cf->data[4]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
}
- writel(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
- writel(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
+ flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
+ flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
kfree_skb(skb);
@@ -462,8 +487,8 @@ static void flexcan_read_fifo(const struct net_device *dev,
struct flexcan_mb __iomem *mb = ®s->cantxfg[0];
u32 reg_ctrl, reg_id;
- reg_ctrl = readl(&mb->can_ctrl);
- reg_id = readl(&mb->can_id);
+ reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_id = flexcan_read(&mb->can_id);
if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
@@ -473,12 +498,12 @@ static void flexcan_read_fifo(const struct net_device
*dev,
cf->can_id |= CAN_RTR_FLAG;
cf->can_dlc = get_can_dlc((reg_ctrl >> 16) & 0xf);
- *(__be32 *)(cf->data + 0) = cpu_to_be32(readl(&mb->data[0]));
- *(__be32 *)(cf->data + 4) = cpu_to_be32(readl(&mb->data[1]));
+ *(__be32 *)(cf->data + 0) = cpu_to_be32(flexcan_read(&mb->data[0]));
+ *(__be32 *)(cf->data + 4) = cpu_to_be32(flexcan_read(&mb->data[1]));
/* mark as read */
- writel(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
- readl(®s->timer);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
+ flexcan_read(®s->timer);
}
static int flexcan_read_frame(struct net_device *dev)
@@ -514,17 +539,17 @@ static int flexcan_poll(struct napi_struct *napi, int
quota)
* The error bits are cleared on read,
* use saved value from irq handler.
*/
- reg_esr = readl(®s->esr) | priv->reg_esr;
+ reg_esr = flexcan_read(®s->esr) | priv->reg_esr;
/* handle state changes */
work_done += flexcan_poll_state(dev, reg_esr);
/* handle RX-FIFO */
- reg_iflag1
[PATCH v11 3/5] flexcan: Add of_match to platform_device definition.
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
Cc: U Bhaskar-B22300
Cc: Grant Likely
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kernel.org
Cc: PPC list
Cc: devicetree-disc...@lists.ozlabs.org
---
drivers/net/can/flexcan.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 68cbe52..662f832 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct
platform_device *pdev)
return 0;
}
+static struct of_device_id flexcan_of_match[] = {
+ {
+ .compatible = "fsl,flexcan",
+ },
+ {},
+};
+
static struct platform_driver flexcan_driver = {
- .driver.name = DRV_NAME,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = flexcan_of_match,
+ },
.probe = flexcan_probe,
.remove = __devexit_p(flexcan_remove),
};
--
1.7.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
I added a simple clock source for the p1010rdb so the flexcan driver
could determine a clock frequency. The p1010 flexcan device only has
an oscillator of system bus frequency divided by 2.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde ,
Acked-by: Wolfgang Grandegger ,
Cc: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de,
Cc: net...@vger.kernel.org,
Cc: PPC list
Cc: Kumar Gala
---
arch/powerpc/platforms/85xx/Kconfig|2 +
arch/powerpc/platforms/85xx/Makefile |2 +
arch/powerpc/platforms/85xx/clock.c| 52
arch/powerpc/platforms/85xx/p1010rdb.c |8 +
4 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/clock.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index 498534c..c4304ae 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -70,6 +70,8 @@ config MPC85xx_RDB
config P1010_RDB
bool "Freescale P1010RDB"
select DEFAULT_UIMAGE
+ select HAVE_CAN_FLEXCAN if NET && CAN
+ select PPC_CLOCK if CAN_FLEXCAN
help
This option enables support for the MPC85xx RDB (P1010 RDB) board
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index a971b32..cc7f381 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -3,6 +3,8 @@
#
obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_PPC_CLOCK) += clock.o
+
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
diff --git a/arch/powerpc/platforms/85xx/clock.c
b/arch/powerpc/platforms/85xx/clock.c
new file mode 100644
index 000..0b6db1d
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/clock.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2011 SGI, inc.
+ *
+ * This code is licensed for use under the GPL V2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include
+
+/*
+ * p1010 needs to provide a clock source for the flexcan driver. The
+ * oscillator for the p1010 processor is only ever the system clock / 2.
+ */
+
+static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
+{
+ if (!dev)
+ return ERR_PTR(-ENOENT);
+
+ if (!dev->of_node ||
+ !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
+ return ERR_PTR(-ENOENT);
+
+ return NULL;
+}
+
+static void mpc85xx_clk_put(struct clk *clk)
+{
+ return;
+}
+
+static unsigned long mpc85xx_clk_get_rate(struct clk *clk)
+{
+ return fsl_get_sys_freq() / 2;
+}
+
+static struct clk_interface mpc85xx_clk_functions = {
+ .clk_get = mpc85xx_clk_get,
+ .clk_get_rate = mpc85xx_clk_get_rate,
+ .clk_put = mpc85xx_clk_put,
+};
+
+void __init mpc85xx_clk_init(void)
+{
+ clk_functions = mpc85xx_clk_functions;
+}
diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c
b/arch/powerpc/platforms/85xx/p1010rdb.c
index d7387fa..5e52122 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
}
+extern void mpc85xx_clk_init(void);
+
+static void __init p1010_rdb_init(void)
+{
+ mpc85xx_clk_init();
+}
+
static struct of_device_id __initdata p1010rdb_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
.name = "P1010 RDB",
.probe = p1010_rdb_probe,
.setup_arch = p1010_rdb_setup_arch,
+ .init = p1010_rdb_init,
.init_IRQ = p1010_rdb_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
--
1.7.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not needed as the frequency of the source clock is
fixed, there is not external divider beyond what the driver already
works with, and the clock source can not be selected.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde ,
To: Wolfgang Grandegger ,
To: U Bhaskar-B22300
To: Scott Wood
To: Grant Likely
To: Kumar Gala
Cc: socketcan-c...@lists.berlios.de,
Cc: net...@vger.kernel.org,
Cc: PPC list
Cc: devicetree-disc...@lists.ozlabs.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt| 70
arch/powerpc/boot/dts/p1010rdb.dts | 10 +--
arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
3 files changed, 19 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1a729f0..869f4ca 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -1,61 +1,17 @@
-CAN Device Tree Bindings
-
-2011 Freescale Semiconductor, Inc.
+Flexcan CAN contoller on Freescale's ARM and PowerPC processors
-fsl,flexcan-v1.0 nodes
-In addition to the required compatible-, reg- and interrupt-properties, you can
-also specify which clock source shall be used for the controller.
+Required properties:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
- (driven by the PLL) or the crystal oscillator clock. The selected clock
- is the one fed to the prescaler to generate the Serial Clock (Sclock).
- The PRESDIV field of CTRL(control register) controls a prescaler that
- generates the Serial Clock (Sclock), whose period defines the
- time quantum used to compose the CAN waveform.
+- compatible : Should be "fsl,flexcan" and optionally
+ "fsl,flexcan-"
+- reg : Offset and length of the register set for this device
+- interrupts : Interrupt tuple for this device
-Can Engine Clock Source
- There are two sources for CAN clock
- - Platform Clock It represents the bus clock
- - Oscillator Clock
+Example:
- Peripheral Clock (PLL)
- --
-|
- - -
- | |CPI Clock| Prescaler | Sclock
- | |>| (1.. 256) |>
- - -
- | |
- -- -CLK_SRC
- Oscillator Clock
-
-- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
-the peripheral clock. PLL clock is fed to the
-prescaler to generate the Serial Clock (Sclock).
-Valid values are "oscillator" and "platform"
-"oscillator": CAN engine clock source is
oscillator clock.
-"platform" The CAN engine clock source is the bus
clock
-(platform clock).
-
-- fsl,flexcan-clock-divider : for the reference and system clock, an additional
- clock divider can be specified.
-- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
-
-Note:
- - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- - P1010 does not have oscillator as the Clock Source.So the default
- Clock Source is platform clock.
-Examples:
-
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
- reg = <0x1c000 0x1000>;
- interrupts = <48 0x2>;
- interrupt-parent = <&mpic>;
- fsl,flexcan-clock-source = "platform";
- fsl,flexcan-clock-divider = <2>;
- clock-frequency = ;
- };
+ can@1c000 {
+ compatible = "fsl,p1010-flexcan", "fsl,flexcan";
+ reg = <0x1c000 0x1000>;
+ interrupts = <48 0x2>;
+ interrupt-parent = <&mpic>;
+ };
diff --git a/arch/powerpc/boot/dts/p1010rdb.dts
b/arch/powerpc/boot/dts/p1010rdb.dts
index 6b33b73..d6c669c 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb.dts
@@ -23,6 +23,8 @@
ethernet2 = &enet2;
pci0 = &pci0;
pci1 = &pci1;
+ can0 = &can0;
+ can1 = &can1;
};
memory {
@@ -169,14 +171,6 @@
};
};
- can0@1c000 {
- fsl,flexcan-clock-source = "platform";
- };
-
-
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Aug 10, 2011, at 11:00 AM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote: >> >> >>> -Original Message- >>> From: Robin Holt [mailto:h...@sgi.com] >>> Sent: Wednesday, August 10, 2011 7:46 PM >>> To: Wolfgang Grandegger >>> Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421; >>> net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC >>> list >>> Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree >>> binding. >>> >>> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: Hi Robin, On 08/10/2011 05:06 AM, Robin Holt wrote: > In working with the socketcan developers, we have come to the > conclusion the Documentation...fsl-flexcan.txt device tree > documentation needs to be cleaned up. The driver does not depend > upon any properties other Your first sentence could be misleading. Please just describe what the patch does and why, something like: "This patch cleans up the documentation of the device-tree binding for the Flexcan devices on Freescale's PowerPC and ARM cores. Extra properties are not needed as the frequency of the source clock is fixed..." and so on. >>> >>> I borrowed heavily from your message. ;) >>> > than the required properties so we are removing the file. > Additionally, the p1010*dts* files are not following the standard > for node naming in that they have a trailing -v1.0. > Signed-off-by: Robin Holt > To: Marc Kleine-Budde , > To: Wolfgang Grandegger , > To: U Bhaskar-B22300 > To: Scott Wood > Cc: socketcan-c...@lists.berlios.de, > Cc: net...@vger.kernel.org, > Cc: PPC list > Cc: Kumar Gala > --- > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 -- >>> -- > arch/powerpc/boot/dts/p1010rdb.dts |8 --- > arch/powerpc/boot/dts/p1010si.dtsi |8 +- > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > diff --git > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > deleted file mode 100644 > index 1a729f0..000 > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > +++ /dev/null > @@ -1,61 +0,0 @@ > -CAN Device Tree Bindings > - > -2011 Freescale Semiconductor, Inc. > - > -fsl,flexcan-v1.0 nodes > > -In addition to the required compatible-, reg- and > interrupt-properties, you can -also specify which clock source shall >>> be used for the controller. > - > -CPI Clock- Can Protocol Interface Clock > - This CLK_SRC bit of CTRL(control register) selects the clock source >>> to > - the CAN Protocol Interface(CPI) to be either the peripheral clock > - (driven by the PLL) or the crystal oscillator clock. The selected >>> clock > - is the one fed to the prescaler to generate the Serial Clock >>> (Sclock). > - The PRESDIV field of CTRL(control register) controls a prescaler >>> that > - generates the Serial Clock (Sclock), whose period defines the > - time quantum used to compose the CAN waveform. > - > -Can Engine Clock Source > - There are two sources for CAN clock > - - Platform Clock It represents the bus clock > - - Oscillator Clock > - > - Peripheral Clock (PLL) > - -- > - | > - - - > - | |CPI Clock| Prescaler | Sclock > - | |>| (1.. 256) |> > - - - > - | | > - -- -CLK_SRC > - Oscillator Clock > - > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property >>> selects > - the peripheral clock. PLL clock is fed to the > - prescaler to generate the Serial Clock (Sclock). > - Valid values are "oscillator" and "platform" > - "oscillator": CAN engine clock source is >>> oscillator clock. > - "platform" The CAN engine clock source is the bus >>> clock > - (platform clock). > - > -- fsl,flexcan-clock-divider : for the reference and system clock, an >>> additional > - clock divider can be specified. > -- clock-frequency: frequency required to calculate the bitrate for >>> FlexCAN. > - > -Note: > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 >>> SOC. > - - P1010 does not have oscillator as the Cl
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On 08/10/2011 11:27 AM, Robin Holt wrote: > -CPI Clock- Can Protocol Interface Clock > - This CLK_SRC bit of CTRL(control register) selects the clock source to > - the CAN Protocol Interface(CPI) to be either the peripheral clock > - (driven by the PLL) or the crystal oscillator clock. The selected clock > - is the one fed to the prescaler to generate the Serial Clock (Sclock). > - The PRESDIV field of CTRL(control register) controls a prescaler that > - generates the Serial Clock (Sclock), whose period defines the > - time quantum used to compose the CAN waveform. > +- compatible : Should be "fsl,flexcan" and optionally > + "fsl,flexcan-" fsl,-flexcan, and it should not be optional, and should come before "fsl,flexcan". Also may want to list fsl,p1010-rdb as a "canonical compatible" for anything which is backwards compatible with p1010's implementation. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
On Aug 10, 2011, at 11:27 AM, Robin Holt wrote: > I added a simple clock source for the p1010rdb so the flexcan driver > could determine a clock frequency. The p1010 flexcan device only has > an oscillator of system bus frequency divided by 2. > > Signed-off-by: Robin Holt > Acked-by: Marc Kleine-Budde , > Acked-by: Wolfgang Grandegger , > Cc: U Bhaskar-B22300 > Cc: socketcan-c...@lists.berlios.de, > Cc: net...@vger.kernel.org, > Cc: PPC list > Cc: Kumar Gala > --- > arch/powerpc/platforms/85xx/Kconfig|2 + > arch/powerpc/platforms/85xx/Makefile |2 + > arch/powerpc/platforms/85xx/clock.c| 52 > arch/powerpc/platforms/85xx/p1010rdb.c |8 + > 4 files changed, 64 insertions(+), 0 deletions(-) > create mode 100644 arch/powerpc/platforms/85xx/clock.c I dont understand how mpc85xx_clk_functions() ends up being associated with the frequency the flexcan is running at. This either seems to global or I'm missing something. I still think the clk / freq info should be in the device tree and handled in the driver and NOT arch/powerpc platform code. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 11:53:15AM -0500, Kumar Gala wrote: > > On Aug 10, 2011, at 11:00 AM, Robin Holt wrote: > > > On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote: > >> > >> > >>> -Original Message- > >>> From: Robin Holt [mailto:h...@sgi.com] > >>> Sent: Wednesday, August 10, 2011 7:46 PM > >>> To: Wolfgang Grandegger > >>> Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421; > >>> net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC > >>> list > >>> Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree > >>> binding. > >>> > >>> On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: > Hi Robin, > > On 08/10/2011 05:06 AM, Robin Holt wrote: > > In working with the socketcan developers, we have come to the > > conclusion the Documentation...fsl-flexcan.txt device tree > > documentation needs to be cleaned up. The driver does not depend > > upon any properties other > > Your first sentence could be misleading. Please just describe what the > patch does and why, something like: > > "This patch cleans up the documentation of the device-tree binding for > the Flexcan devices on Freescale's PowerPC and ARM cores. Extra > properties are not needed as the frequency of the source clock is > fixed..." and so on. > >>> > >>> I borrowed heavily from your message. ;) > >>> > > than the required properties so we are removing the file. > > Additionally, the p1010*dts* files are not following the standard > > for node naming in that they have a trailing -v1.0. > > > Signed-off-by: Robin Holt > > To: Marc Kleine-Budde , > > To: Wolfgang Grandegger , > > To: U Bhaskar-B22300 > > To: Scott Wood > > Cc: socketcan-c...@lists.berlios.de, > > Cc: net...@vger.kernel.org, > > Cc: PPC list > > Cc: Kumar Gala > > --- > > .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 -- > >>> -- > > arch/powerpc/boot/dts/p1010rdb.dts |8 --- > > arch/powerpc/boot/dts/p1010si.dtsi |8 +- > > 3 files changed, 4 insertions(+), 73 deletions(-) delete mode > > 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > > > diff --git > > a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > deleted file mode 100644 > > index 1a729f0..000 > > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > > +++ /dev/null > > @@ -1,61 +0,0 @@ > > -CAN Device Tree Bindings > > - > > -2011 Freescale Semiconductor, Inc. > > - > > -fsl,flexcan-v1.0 nodes > > > > -In addition to the required compatible-, reg- and > > interrupt-properties, you can -also specify which clock source shall > >>> be used for the controller. > > - > > -CPI Clock- Can Protocol Interface Clock > > - This CLK_SRC bit of CTRL(control register) selects the clock > > source > >>> to > > - the CAN Protocol Interface(CPI) to be either the peripheral > > clock > > - (driven by the PLL) or the crystal oscillator clock. The > > selected > >>> clock > > - is the one fed to the prescaler to generate the Serial Clock > >>> (Sclock). > > - The PRESDIV field of CTRL(control register) controls a prescaler > >>> that > > - generates the Serial Clock (Sclock), whose period defines the > > - time quantum used to compose the CAN waveform. > > - > > -Can Engine Clock Source > > - There are two sources for CAN clock > > - - Platform Clock It represents the bus clock > > - - Oscillator Clock > > - > > - Peripheral Clock (PLL) > > - -- > > -| > > - - - > > - | |CPI Clock| Prescaler | Sclock > > - | |>| (1.. 256) |> > > - - - > > - | | > > - -- -CLK_SRC > > - Oscillator Clock > > - > > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property > >>> selects > > -the peripheral clock. PLL clock is fed to > > the > > -prescaler to generate the Serial Clock > > (Sclock). > > -Valid values are "oscillator" and > > "platform" > > -"oscillator": CAN engine clock source is > >>> oscillator clock. > > -"platform" The CAN engine c
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Aug 10, 2011, at 12:16 PM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 11:53:15AM -0500, Kumar Gala wrote: >> >> On Aug 10, 2011, at 11:00 AM, Robin Holt wrote: >> >>> On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote: > -Original Message- > From: Robin Holt [mailto:h...@sgi.com] > Sent: Wednesday, August 10, 2011 7:46 PM > To: Wolfgang Grandegger > Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421; > net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC > list > Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree > binding. > > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: >> Hi Robin, >> >> On 08/10/2011 05:06 AM, Robin Holt wrote: >>> In working with the socketcan developers, we have come to the >>> conclusion the Documentation...fsl-flexcan.txt device tree >>> documentation needs to be cleaned up. The driver does not depend >>> upon any properties other >> >> Your first sentence could be misleading. Please just describe what the >> patch does and why, something like: >> >> "This patch cleans up the documentation of the device-tree binding for >> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra >> properties are not needed as the frequency of the source clock is >> fixed..." and so on. > > I borrowed heavily from your message. ;) > >>> than the required properties so we are removing the file. >>> Additionally, the p1010*dts* files are not following the standard >>> for node naming in that they have a trailing -v1.0. >> >>> Signed-off-by: Robin Holt >>> To: Marc Kleine-Budde , >>> To: Wolfgang Grandegger , >>> To: U Bhaskar-B22300 >>> To: Scott Wood >>> Cc: socketcan-c...@lists.berlios.de, >>> Cc: net...@vger.kernel.org, >>> Cc: PPC list >>> Cc: Kumar Gala >>> --- >>> .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 -- > -- >>> arch/powerpc/boot/dts/p1010rdb.dts |8 --- >>> arch/powerpc/boot/dts/p1010si.dtsi |8 +- >>> 3 files changed, 4 insertions(+), 73 deletions(-) delete mode >>> 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt >>> >>> diff --git >>> a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt >>> b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt >>> deleted file mode 100644 >>> index 1a729f0..000 >>> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt >>> +++ /dev/null >>> @@ -1,61 +0,0 @@ >>> -CAN Device Tree Bindings >>> - >>> -2011 Freescale Semiconductor, Inc. >>> - >>> -fsl,flexcan-v1.0 nodes >>> >>> -In addition to the required compatible-, reg- and >>> interrupt-properties, you can -also specify which clock source shall > be used for the controller. >>> - >>> -CPI Clock- Can Protocol Interface Clock >>> - This CLK_SRC bit of CTRL(control register) selects the clock >>> source > to >>> - the CAN Protocol Interface(CPI) to be either the peripheral >>> clock >>> - (driven by the PLL) or the crystal oscillator clock. The >>> selected > clock >>> - is the one fed to the prescaler to generate the Serial Clock > (Sclock). >>> - The PRESDIV field of CTRL(control register) controls a prescaler > that >>> - generates the Serial Clock (Sclock), whose period defines the >>> - time quantum used to compose the CAN waveform. >>> - >>> -Can Engine Clock Source >>> - There are two sources for CAN clock >>> - - Platform Clock It represents the bus clock >>> - - Oscillator Clock >>> - >>> - Peripheral Clock (PLL) >>> - -- >>> -| >>> - - - >>> - | |CPI Clock| Prescaler | Sclock >>> - | |>| (1.. 256) |> >>> - - - >>> - | | >>> - -- -CLK_SRC >>> - Oscillator Clock >>> - >>> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property > selects >>> -the peripheral clock. PLL clock is fed to >>> the >>> -prescaler to generate the Serial Clock >>> (Sclock). >>> -Valid values are "oscillator" and >>> "platform" >>> -"oscillator": CAN engine clock source is > oscillator clock. >>> -
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote: > On 08/10/2011 11:27 AM, Robin Holt wrote: > > -CPI Clock- Can Protocol Interface Clock > > - This CLK_SRC bit of CTRL(control register) selects the clock source to > > - the CAN Protocol Interface(CPI) to be either the peripheral clock > > - (driven by the PLL) or the crystal oscillator clock. The selected clock > > - is the one fed to the prescaler to generate the Serial Clock (Sclock). > > - The PRESDIV field of CTRL(control register) controls a prescaler that > > - generates the Serial Clock (Sclock), whose period defines the > > - time quantum used to compose the CAN waveform. > > +- compatible : Should be "fsl,flexcan" and optionally > > + "fsl,flexcan-" > > fsl,-flexcan, and it should not be optional, and should come > before "fsl,flexcan". > > Also may want to list fsl,p1010-rdb as a "canonical compatible" for > anything which is backwards compatible with p1010's implementation. How do I specify 'canonical compatible'? What would be the use of it in that implementation? Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 12:17:45PM -0500, Kumar Gala wrote: > > On Aug 10, 2011, at 12:16 PM, Robin Holt wrote: > > > On Wed, Aug 10, 2011 at 11:53:15AM -0500, Kumar Gala wrote: > >> > >> On Aug 10, 2011, at 11:00 AM, Robin Holt wrote: > >> > >>> On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote: > > > > -Original Message- > > From: Robin Holt [mailto:h...@sgi.com] > > Sent: Wednesday, August 10, 2011 7:46 PM > > To: Wolfgang Grandegger > > Cc: Robin Holt; Marc Kleine-Budde; U Bhaskar-B22300; Wood Scott-B07421; > > net...@vger.kernel.org; Kumar Gala; socketcan-c...@lists.berlios.de; PPC > > list > > Subject: Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree > > binding. > > > > On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote: > >> Hi Robin, > >> > >> On 08/10/2011 05:06 AM, Robin Holt wrote: > >>> In working with the socketcan developers, we have come to the > >>> conclusion the Documentation...fsl-flexcan.txt device tree > >>> documentation needs to be cleaned up. The driver does not depend > >>> upon any properties other > >> > >> Your first sentence could be misleading. Please just describe what the > >> patch does and why, something like: > >> > >> "This patch cleans up the documentation of the device-tree binding for > >> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra > >> properties are not needed as the frequency of the source clock is > >> fixed..." and so on. > > > > I borrowed heavily from your message. ;) > > > >>> than the required properties so we are removing the file. > >>> Additionally, the p1010*dts* files are not following the standard > >>> for node naming in that they have a trailing -v1.0. > >> > >>> Signed-off-by: Robin Holt > >>> To: Marc Kleine-Budde , > >>> To: Wolfgang Grandegger , > >>> To: U Bhaskar-B22300 > >>> To: Scott Wood > >>> Cc: socketcan-c...@lists.berlios.de, > >>> Cc: net...@vger.kernel.org, > >>> Cc: PPC list > >>> Cc: Kumar Gala > >>> --- > >>> .../devicetree/bindings/net/can/fsl-flexcan.txt| 61 -- > > -- > >>> arch/powerpc/boot/dts/p1010rdb.dts |8 --- > >>> arch/powerpc/boot/dts/p1010si.dtsi |8 +- > >>> 3 files changed, 4 insertions(+), 73 deletions(-) delete mode > >>> 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > >>> b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > >>> deleted file mode 100644 > >>> index 1a729f0..000 > >>> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt > >>> +++ /dev/null > >>> @@ -1,61 +0,0 @@ > >>> -CAN Device Tree Bindings > >>> - > >>> -2011 Freescale Semiconductor, Inc. > >>> - > >>> -fsl,flexcan-v1.0 nodes > >>> > >>> -In addition to the required compatible-, reg- and > >>> interrupt-properties, you can -also specify which clock source shall > > be used for the controller. > >>> - > >>> -CPI Clock- Can Protocol Interface Clock > >>> - This CLK_SRC bit of CTRL(control register) selects the clock > >>> source > > to > >>> - the CAN Protocol Interface(CPI) to be either the peripheral > >>> clock > >>> - (driven by the PLL) or the crystal oscillator clock. The > >>> selected > > clock > >>> - is the one fed to the prescaler to generate the Serial Clock > > (Sclock). > >>> - The PRESDIV field of CTRL(control register) controls a prescaler > > that > >>> - generates the Serial Clock (Sclock), whose period defines the > >>> - time quantum used to compose the CAN waveform. > >>> - > >>> -Can Engine Clock Source > >>> - There are two sources for CAN clock > >>> - - Platform Clock It represents the bus clock > >>> - - Oscillator Clock > >>> - > >>> - Peripheral Clock (PLL) > >>> - -- > >>> - | > >>> - - - > >>> - | |CPI Clock| Prescaler | Sclock > >>> - | |>| (1.. 256) |> > >>> - - - > >>> - | | > >>> - -- -CLK_SRC > >>> - Oscillator Clock > >>> - > >>> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property > > selects > >>> - the peripheral clock. PLL clock is fed to > >>> the > >>> - prescaler to
union/struct representations for MAS Registers
I have some and use them in some code, they represent ISA 2.06 MAVN=1 (version
2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
u32 _reserved_1:2;
u32 ind:1;
u32 ts:1;
u32 tsize:4;
u32 _reserved_2:8;
};
};
-jx
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:21 PM, Jimi Xenidis wrote:
> I have some and use them in some code, they represent ISA 2.06 MAVN=1
> (version 2)
> Can I keep them?
> if so, should I put them somewhere useful to others?
>
> Examples:
> union mas1 {
> u32 _val;
> struct {
> u32 v:1;
> u32 iprot:1;
> u32 tid:14;
> u32 _reserved_1:2;
> u32 ind:1;
> u32 ts:1;
> u32 tsize:4;
> u32 _reserved_2:8;
> };
> };
Uugh, we really have avoided unions for such things and it would be nice to
keep it that way.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: union/struct representations for MAS Registers
> I have some and use them in some code, they represent ISA
> 2.06 MAVN=1 (version 2)
> Can I keep them?
> if so, should I put them somewhere useful to others?
>
> Examples:
> union mas1 {
> u32 _val;
> struct {
> u32 v:1;
> u32 iprot:1;
> u32 tid:14;
> u32 _reserved_1:2;
> u32 ind:1;
> u32 ts:1;
> u32 tsize:4;
> u32 _reserved_2:8;
> };
> };
Bitfields are rather non-portable, the compiler has a lot of choice
about how to align the bits in memory.
Their use to map anything physical is doomed to portabilily issues.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
>>> So the node names should be
>>> can@1c000 {
>>> can@1d000 {
>>> correct?
>>>
>> [Bhaskar] As there are two CAN controllers on P1010,So won't it be better
>> to distinguish it by can0 and can1 instead by simple "can" ?
>
> It looks like the way to do that is to assign a label to those devices
> and then associate the label with an alias. I have no idea how that
> works under the hood, but it is the way other files are set up. Take a
> look at arch/powerpc/boot/dts/bamboo.dts for how they define the serial
> interfaces.
>
> Grant or Wolfgang, is that the right way to handle the concern about
> names or does it have no practical effect with the Linux kernel?
It has not effect. The label is just if you need to reference it via some
other means.
>>>
>>> Does the alias have an effect?
>>
>> nope
>
> Then how does the device number get associated with a particular device
What do you mean by device number?
> and how is user-space ensured a consistent namespace?
that is left to udev rules.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:25 PM, Kumar Gala wrote:
>
> On Aug 10, 2011, at 12:21 PM, Jimi Xenidis wrote:
>
>> I have some and use them in some code, they represent ISA 2.06 MAVN=1
>> (version 2)
>> Can I keep them?
>> if so, should I put them somewhere useful to others?
>>
>> Examples:
>> union mas1 {
>> u32 _val;
>> struct {
>> u32 v:1;
>> u32 iprot:1;
>> u32 tid:14;
>> u32 _reserved_1:2;
>> u32 ind:1;
>> u32 ts:1;
>> u32 tsize:4;
>> u32 _reserved_2:8;
>> };
>> };
>
> Uugh, we really have avoided unions for such things and it would be nice to
> keep it that way.
I like "nice", I'll convert
-JX
>
> - k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:25 PM, David Laight wrote:
>
>> I have some and use them in some code, they represent ISA
>> 2.06 MAVN=1 (version 2)
>> Can I keep them?
>> if so, should I put them somewhere useful to others?
>>
>> Examples:
>> union mas1 {
>> u32 _val;
>> struct {
>> u32 v:1;
>> u32 iprot:1;
>> u32 tid:14;
>> u32 _reserved_1:2;
>> u32 ind:1;
>> u32 ts:1;
>> u32 tsize:4;
>> u32 _reserved_2:8;
>> };
>> };
>
> Bitfields are rather non-portable, the compiler has a lot of choice
> about how to align the bits in memory.
I'm ok with the masking stuff.
However, I'm actually surprised this is true given the maturity of our ABIs.
-JX
> Their use to map anything physical is doomed to portabilily issues.
>
> David
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On 08/10/2011 12:19 PM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote: >> On 08/10/2011 11:27 AM, Robin Holt wrote: >>> -CPI Clock- Can Protocol Interface Clock >>> - This CLK_SRC bit of CTRL(control register) selects the clock source to >>> - the CAN Protocol Interface(CPI) to be either the peripheral clock >>> - (driven by the PLL) or the crystal oscillator clock. The selected clock >>> - is the one fed to the prescaler to generate the Serial Clock (Sclock). >>> - The PRESDIV field of CTRL(control register) controls a prescaler that >>> - generates the Serial Clock (Sclock), whose period defines the >>> - time quantum used to compose the CAN waveform. >>> +- compatible : Should be "fsl,flexcan" and optionally >>> + "fsl,flexcan-" >> >> fsl,-flexcan, and it should not be optional, and should come >> before "fsl,flexcan". >> >> Also may want to list fsl,p1010-rdb as a "canonical compatible" for >> anything which is backwards compatible with p1010's implementation. > > How do I specify 'canonical compatible'? Something like: compatible: Should be "fsl,-flexcan" and "fsl,flexcan". An implementation should also claim any of the following compatibles that it is fully backwards compatible with: - fsl,p1010-rdb > What would be the use of it in that implementation? It limits the number of compatibles a driver has to care about, so you don't need a huge ID table just to be able to figure out whether this is a p1010-style flexcan or ARM-style. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
On 11-08-10 12:01 PM, Scott Wood wrote: > On 08/10/2011 10:39 AM, Paul Gortmaker wrote: >> On Wed, Aug 10, 2011 at 1:21 AM, Baruch Siach wrote: >>> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, >>> thus >>> breaking clear_pages(), probably others too. >>> >>> This patch adds a new "Processor Type" entry for e500mc, and makes e500 >>> systems >>> depend on PPC_E500_V1_V2. >> >> Isn't the original invalid configuration still possible, i.e. I can >> choose E500_V1_V2 >> and also E500MC at the same time, unless you add something like a >> "depends !E500MC" to your new V1_V2 option? > > They're members of a "choice", not standalone bools -- so they're > mutually exclusive. OK, I missed that. > >> Alternatively, you could treat it like using i386 kernel on a modern >> core by taking >> the LCD for the L1_CACHE_SHIFT of the configured in platforms. > > For alignment you want to err on the high side, but for invalidation you > want to err on the low side. For dcbz you can't err at all. > > And there are other issues than cache size with combining e500v2 and e500mc. > > Could it be done with sufficient hoop-jumping? Probably. Is it worth > it? No. These chips don't even have compatible userspace, unless you > use soft-float. Yeah, if there are lots of other issues and the value return is low, then I can't argue with that. And yes I did use soft float in the thing I was meddling with. > >> I have booted >> a kernel built for an mpc8548 core on a P4080 CPU, so that does work (with >> only >> minimal dts fiddling). > > The opposite direction does not work, and simply booting doesn't mean > there wouldn't be issues in running that kernel on a p4080 (floating > point? bad cache size information being given to userspace? emulation > of non-cacheable dcbz? performance?). > > What dts fiddling? Just making sure that the 8548 dts had the right address to find the uart on the actual p4080 platform. > >> And it keeps the ability to boot one kernel on several >> platforms open (one of the reasons for the ppc --> powerpc shuffle a couple >> of years ago...) > > It's much better than the arch/ppc way of a separate kernel build for > every board. Beyond a certain point there are diminishing returns on > the effort. Given the extra info you list above, I agree. I just thought it worth a mention since I had happened to boot the 8548 kernel on a p4080 as part of something else I was experimenting with, and it didn't totally catch fire (which somewhat surprised me). P. > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: union/struct representations for MAS Registers
> > Bitfields are rather non-portable, the compiler has a lot of choice > > about how to align the bits in memory. > > I'm ok with the masking stuff. > However, I'm actually surprised this is true given the > maturity of our ABIs. The C standard says nothing at all about how bitfields are implemented, I think the first bit might be 0x1, 0x80, 0x100 or 0x8000 when treated as a 32bit value, regardless of the endianness. Different architectures can (and do) assign things in different ways. So code that is ok on ppc might fail on arm or x86 (etc). David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:38 PM, David Laight wrote: > >>> Bitfields are rather non-portable, the compiler has a lot of choice >>> about how to align the bits in memory. >> >> I'm ok with the masking stuff. >> However, I'm actually surprised this is true given the >> maturity of our ABIs. > > The C standard says nothing at all about how bitfields are implemented, > I think the first bit might be 0x1, 0x80, 0x100 or 0x8000 > when treated as a 32bit value, regardless of the endianness. > > Different architectures can (and do) assign things in different ways. > So code that is ok on ppc might fail on arm or x86 (etc). > > David I think PPCs a bit sane and what Jimi was proposing the union for is something that would never need to be portable (as it a PPC specific register). Still, prefer the shifts, masks & macros as that's what I've been reading & using in ppc land forever ;) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Wed, Aug 10, 2011 at 8:27 AM, Benjamin Herrenschmidt wrote: > > Here are a few fixes for powerpc. Mostly innocuous stuff, in fact most of > it has been in my tree for a while, I just hadn't got a chance to actually > send it as I was travelling. > > Cheers, > Ben. > > The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03: > > Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 > (2011-08-04 06:37:07 -1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git > ..BRANCH.NOT.VERIFIED.. What branch? Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
On 08/10/2011 07:01 PM, Kumar Gala wrote: > > On Aug 10, 2011, at 11:27 AM, Robin Holt wrote: > >> I added a simple clock source for the p1010rdb so the flexcan driver >> could determine a clock frequency. The p1010 flexcan device only has >> an oscillator of system bus frequency divided by 2. >> >> Signed-off-by: Robin Holt >> Acked-by: Marc Kleine-Budde , >> Acked-by: Wolfgang Grandegger , >> Cc: U Bhaskar-B22300 >> Cc: socketcan-c...@lists.berlios.de, >> Cc: net...@vger.kernel.org, >> Cc: PPC list >> Cc: Kumar Gala >> --- >> arch/powerpc/platforms/85xx/Kconfig|2 + >> arch/powerpc/platforms/85xx/Makefile |2 + >> arch/powerpc/platforms/85xx/clock.c| 52 >> >> arch/powerpc/platforms/85xx/p1010rdb.c |8 + >> 4 files changed, 64 insertions(+), 0 deletions(-) >> create mode 100644 arch/powerpc/platforms/85xx/clock.c > > I dont understand how mpc85xx_clk_functions() ends up being associated with > the frequency the flexcan is running at. The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for Flexcan devices. > This either seems to global or I'm missing something. This patch extends the existing Flexcan platform driver for ARM for the PowerPC using the device tree. Due to the nice integration of the device tree (of-platform) into the platform driver and devices, the difference are quite small (see patches 1..3). Apart from the endianess issue, only the clock needs to be handled in a common way. As ARM already uses the clk interface, we found it straight-forward to implement it for the P1010, or more general for the 85xx, as well, instead of using an additional helper function. > I still think the clk / freq info should be in the device tree and handled in > the driver and NOT arch/powerpc platform code. If I understand you correctly, you want the boot-loader to provide the relevant information by fixing up the device tree, which then can be handled arch-independently by the driver, right? Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On 08/10/2011 06:00 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote:
...
> It looks like the way to do that is to assign a label to those devices
> and then associate the label with an alias. I have no idea how that
> works under the hood, but it is the way other files are set up. Take a
> look at arch/powerpc/boot/dts/bamboo.dts for how they define the serial
> interfaces.
With a label you mean "label:" at the beginning of a node. Such labels
are translated by the device tree compiler in node handles, which can be
referenced within nodes by using <&label>, e.g.:
UIC0: interrupt-controller0 {
...
};
UIC1: interrupt-controller1 {
...
interrupt-parent = <&UIC0>;
...
};
It has nothing to do with the name of the node.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Ben, Finally somewhat caught up. Now that -rc1 is out, here are some patches for the next merge window. josh The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03: Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 (2011-08-04 06:37:07 -1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Ayman El-Khashab (1): powerpc/4xx: enable and fix pcie gen1/gen2 on the 460sx Josh Boyer (1): powerpc/40x: Remove obsolete HCU4 board Mike Williams (1): powerpc/4xx: edac: Add comma to fix build error Stefan Roese (1): powerpc/44x: Add NOR flash device to Yosemite dts Suzuki Poulose (1): powerpc/44x: Kexec support for PPC440X chipsets arch/powerpc/Kconfig|2 +- arch/powerpc/boot/dts/hcu4.dts | 168 -- arch/powerpc/boot/dts/yosemite.dts | 36 +++ arch/powerpc/configs/40x/hcu4_defconfig | 80 -- arch/powerpc/configs/ppc40x_defconfig |1 - arch/powerpc/include/asm/kexec.h|2 +- arch/powerpc/kernel/misc_32.S | 171 +++ arch/powerpc/platforms/40x/Kconfig |8 -- arch/powerpc/platforms/40x/Makefile |1 - arch/powerpc/platforms/40x/hcu4.c | 61 --- arch/powerpc/sysdev/ppc4xx_pci.c| 89 +--- arch/powerpc/sysdev/ppc4xx_pci.h| 12 ++ drivers/edac/ppc4xx_edac.c |2 +- 13 files changed, 294 insertions(+), 339 deletions(-) delete mode 100644 arch/powerpc/boot/dts/hcu4.dts delete mode 100644 arch/powerpc/configs/40x/hcu4_defconfig delete mode 100644 arch/powerpc/platforms/40x/hcu4.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On 08/10/2011 01:23 PM, Wolfgang Grandegger wrote:
> On 08/10/2011 06:00 PM, Robin Holt wrote:
>> On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote:
> ...
>> It looks like the way to do that is to assign a label to those devices
>> and then associate the label with an alias. I have no idea how that
>> works under the hood, but it is the way other files are set up. Take a
>> look at arch/powerpc/boot/dts/bamboo.dts for how they define the serial
>> interfaces.
>
> With a label you mean "label:" at the beginning of a node. Such labels
> are translated by the device tree compiler in node handles, which can be
> referenced within nodes by using <&label>, e.g.:
>
> UIC0: interrupt-controller0 {
> ...
> };
> UIC1: interrupt-controller1 {
> ...
> interrupt-parent = <&UIC0>;
> ...
> };
>
> It has nothing to do with the name of the node.
"...and then associate the label with an alias."
The alias can then be used if you want "can0" versus "can1".
Appending numbers to the node name is typically only done when there's
no unit address, and a need to disambiguate.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 12:36:22PM -0500, Scott Wood wrote:
> On 08/10/2011 12:19 PM, Robin Holt wrote:
> > On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
> >> On 08/10/2011 11:27 AM, Robin Holt wrote:
> >>> -CPI Clock- Can Protocol Interface Clock
> >>> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> >>> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> >>> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> >>> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> >>> - The PRESDIV field of CTRL(control register) controls a prescaler that
> >>> - generates the Serial Clock (Sclock), whose period defines the
> >>> - time quantum used to compose the CAN waveform.
> >>> +- compatible : Should be "fsl,flexcan" and optionally
> >>> + "fsl,flexcan-"
> >>
> >> fsl,-flexcan, and it should not be optional, and should come
> >> before "fsl,flexcan".
> >>
> >> Also may want to list fsl,p1010-rdb as a "canonical compatible" for
> >> anything which is backwards compatible with p1010's implementation.
> >
> > How do I specify 'canonical compatible'?
>
> Something like:
>
> compatible: Should be "fsl,-flexcan" and "fsl,flexcan".
>
> An implementation should also claim any of the following compatibles
> that it is fully backwards compatible with:
>
> - fsl,p1010-rdb
I am so confused. fsl,p1010-flexcan refers, in my mind at least, to
a particular chiplet on the p1010 freescale processor. fsl,p1010-rdb
would mean nothing to me as that is a p1010 processor with two flexcan
chiplets wired to a pair of DB-9 jacks. For the driver, what additional
information is being conveyed?
Let's cut to the chase. Here is what I have after incorporating your
earlier comment about the compatible line. Please mark this up to
exactly what you are asking for.
Thanks,
Robin
Flexcan CAN contoller on Freescale's ARM and PowerPC processors
Required properties:
- compatible : Should be "fsl,-flexcan" and "fsl,flexcan"
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Example:
can@1c000 {
compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 01:27:52PM -0500, Scott Wood wrote:
> On 08/10/2011 01:23 PM, Wolfgang Grandegger wrote:
> > On 08/10/2011 06:00 PM, Robin Holt wrote:
> >> On Wed, Aug 10, 2011 at 02:36:20PM +, U Bhaskar-B22300 wrote:
> > ...
> >> It looks like the way to do that is to assign a label to those devices
> >> and then associate the label with an alias. I have no idea how that
> >> works under the hood, but it is the way other files are set up. Take a
> >> look at arch/powerpc/boot/dts/bamboo.dts for how they define the serial
> >> interfaces.
> >
> > With a label you mean "label:" at the beginning of a node. Such labels
> > are translated by the device tree compiler in node handles, which can be
> > referenced within nodes by using <&label>, e.g.:
> >
> > UIC0: interrupt-controller0 {
> > ...
> > };
> > UIC1: interrupt-controller1 {
> > ...
> > interrupt-parent = <&UIC0>;
> > ...
> > };
> >
> > It has nothing to do with the name of the node.
>
> "...and then associate the label with an alias."
>
> The alias can then be used if you want "can0" versus "can1".
Does the alias get used by either the kernel or something else or is it
just extra detail with no purpose?
Robin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
On 08/10/2011 01:35 PM, Robin Holt wrote: > On Wed, Aug 10, 2011 at 01:27:52PM -0500, Scott Wood wrote: >> "...and then associate the label with an alias." >> >> The alias can then be used if you want "can0" versus "can1". > > Does the alias get used by either the kernel or something else or is it > just extra detail with no purpose? It could be used by udev to produce a symlink. Currently, the major non-human consumer of the aliases is U-Boot. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On 08/10/2011 01:30 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 12:36:22PM -0500, Scott Wood wrote:
>> On 08/10/2011 12:19 PM, Robin Holt wrote:
>>> On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote:
Also may want to list fsl,p1010-rdb as a "canonical compatible" for
anything which is backwards compatible with p1010's implementation.
>>>
>>> How do I specify 'canonical compatible'?
>>
>> Something like:
>>
>> compatible: Should be "fsl,-flexcan" and "fsl,flexcan".
>>
>> An implementation should also claim any of the following compatibles
>> that it is fully backwards compatible with:
>>
>> - fsl,p1010-rdb
Gah, I don't know how "rdb" replaced "flexcan" in the above. Sorry for
any confusion.
> I am so confused. fsl,p1010-flexcan refers, in my mind at least, to
> a particular chiplet on the p1010 freescale processor.
It refers to a particular version of the flexcan logic, for which the
hardware doc people weren't kind enough to give us a public version number.
It has been common and recommended practice in such cases, when there
are multiple chips containing the same device, to pick a canonical chip
(such as the first one to have the device or to be supported) and have
others claim compatibility with it.
> fsl,p1010-rdb
> would mean nothing to me as that is a p1010 processor with two flexcan
> chiplets wired to a pair of DB-9 jacks. For the driver, what additional
> information is being conveyed?
The programming model of the flexcan chiplet.
> Let's cut to the chase. Here is what I have after incorporating your
> earlier comment about the compatible line. Please mark this up to
> exactly what you are asking for.
>
> Thanks,
> Robin
>
> Flexcan CAN contoller on Freescale's ARM and PowerPC processors
>
> Required properties:
>
> - compatible : Should be "fsl,-flexcan" and "fsl,flexcan"
An implementation should also claim any of the following compatibles
that it is fully backwards compatible with:
- fsl,p1010-flexcan
> - reg : Offset and length of the register set for this device
> - interrupts : Interrupt tuple for this device
>
> Example:
>
> can@1c000 {
> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> };
>
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
On Wed, Aug 10, 2011 at 01:40:30PM -0500, Scott Wood wrote: > On 08/10/2011 01:30 PM, Robin Holt wrote: > > On Wed, Aug 10, 2011 at 12:36:22PM -0500, Scott Wood wrote: > >> On 08/10/2011 12:19 PM, Robin Holt wrote: > >>> On Wed, Aug 10, 2011 at 11:56:28AM -0500, Scott Wood wrote: > Also may want to list fsl,p1010-rdb as a "canonical compatible" for > anything which is backwards compatible with p1010's implementation. > >>> > >>> How do I specify 'canonical compatible'? > >> > >> Something like: > >> > >> compatible: Should be "fsl,-flexcan" and "fsl,flexcan". > >> > >> An implementation should also claim any of the following compatibles > >> that it is fully backwards compatible with: > >> > >> - fsl,p1010-rdb > > Gah, I don't know how "rdb" replaced "flexcan" in the above. Sorry for > any confusion. > > > I am so confused. fsl,p1010-flexcan refers, in my mind at least, to > > a particular chiplet on the p1010 freescale processor. > > It refers to a particular version of the flexcan logic, for which the > hardware doc people weren't kind enough to give us a public version number. > > It has been common and recommended practice in such cases, when there > are multiple chips containing the same device, to pick a canonical chip > (such as the first one to have the device or to be supported) and have > others claim compatibility with it. > > > fsl,p1010-rdb > > would mean nothing to me as that is a p1010 processor with two flexcan > > chiplets wired to a pair of DB-9 jacks. For the driver, what additional > > information is being conveyed? > > The programming model of the flexcan chiplet. > > > Let's cut to the chase. Here is what I have after incorporating your > > earlier comment about the compatible line. Please mark this up to > > exactly what you are asking for. > > > > Thanks, > > Robin > > > > Flexcan CAN contoller on Freescale's ARM and PowerPC processors > > > > Required properties: > > > > - compatible : Should be "fsl,-flexcan" and "fsl,flexcan" > >An implementation should also claim any of the following compatibles >that it is fully backwards compatible with: > >- fsl,p1010-flexcan Ah, there is my confusion. I did not realize you were saying the entire preceeding 4 lines should be included. I thought you were making a comment which I did not understand. Thank you for your patience with my ignorance, Robin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Wed, 2011-08-10 at 11:07 -0700, Linus Torvalds wrote: > On Wed, Aug 10, 2011 at 8:27 AM, Benjamin Herrenschmidt > wrote: > > > > Here are a few fixes for powerpc. Mostly innocuous stuff, in fact most of > > it has been in my tree for a while, I just hadn't got a chance to actually > > send it as I was travelling. > > > > Cheers, > > Ben. > > > > The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03: > > > > Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 > > (2011-08-04 06:37:07 -1000) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git > > ..BRANCH.NOT.VERIFIED.. > > What branch? Heh oops, sorry, the mirror hadn't caught up. It's in the subject of the email tho :-) "merge" is the branch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/kvm: fix build errors with older toolchains
On Wed, 2011-08-10 at 16:58 +0200, Alexander Graf wrote: > On 08/03/2011 08:55 PM, Nishanth Aravamudan wrote: > > On a box with gcc 4.3.2, I see errors like: > > > > arch/powerpc/kvm/book3s_hv_rmhandlers.S:1254: Error: Unrecognized opcode: > > stxvd2x > > arch/powerpc/kvm/book3s_hv_rmhandlers.S:1316: Error: Unrecognized opcode: > > lxvd2x > > Paul, mind to ack? I merged it already :-) It was trivial & annoying enough. Cheers, Ben. > > Alex > > > Signed-off-by: Nishanth Aravamudan > > --- > > arch/powerpc/kvm/book3s_hv_rmhandlers.S |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > > b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > > index 6dd3358..de29501 100644 > > --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S > > +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S > > @@ -1251,7 +1251,7 @@ BEGIN_FTR_SECTION > > reg = 0 > > .rept 32 > > li r6,reg*16+VCPU_VSRS > > - stxvd2x reg,r6,r3 > > + STXVD2X(reg,r6,r3) > > reg = reg + 1 > > .endr > > FTR_SECTION_ELSE > > @@ -1313,7 +1313,7 @@ BEGIN_FTR_SECTION > > reg = 0 > > .rept 32 > > li r7,reg*16+VCPU_VSRS > > - lxvd2x reg,r7,r4 > > + LXVD2X(reg,r7,r4) > > reg = reg + 1 > > .endr > > FTR_SECTION_ELSE > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" 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] powerpc/kvm: fix build errors with older toolchains
On 10.08.2011, at 20:56, Benjamin Herrenschmidt wrote: > On Wed, 2011-08-10 at 16:58 +0200, Alexander Graf wrote: >> On 08/03/2011 08:55 PM, Nishanth Aravamudan wrote: >>> On a box with gcc 4.3.2, I see errors like: >>> >>> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1254: Error: Unrecognized opcode: >>> stxvd2x >>> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1316: Error: Unrecognized opcode: >>> lxvd2x >> >> Paul, mind to ack? > > I merged it already :-) It was trivial & annoying enough. Alright then, I won't touch it :) Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] KVM: PPC: Assemble book3s{,_hv}_rmhandlers.S separately
On Tue, Aug 02, 2011 at 02:20:28PM +0200, Alexander Graf wrote:
> On 07/23/2011 09:41 AM, Paul Mackerras wrote:
> >This makes arch/powerpc/kvm/book3s_rmhandlers.S and
> >arch/powerpc/kvm/book3s_hv_rmhandlers.S be assembled as
> >separate compilation units rather than having them #included in
> >arch/powerpc/kernel/exceptions-64s.S. We no longer have any
> >conditional branches between the exception prologs in
> >exceptions-64s.S and the KVM handlers, so there is no need to
> >keep their contents close together in the vmlinux image.
> >
> >In their current location, they are using up part of the limited
> >space between the first-level interrupt handlers and the firmware
> >NMI data area at offset 0x7000, and with some kernel configurations
> >this area will overflow (e.g. allyesconfig), leading to an
> >"attempt to .org backwards" error when compiling exceptions-64s.S.
> >
> >Moving them out requires that we add some #includes that the
> >book3s_{,hv_}rmhandlers.S code was previously getting implicitly
> >via exceptions-64s.S.
>
> So what if your kernel binary is bigger than the 24 bits we can jump
> and the KVM code happens to be at the end? Or do we just not care
> here?
Actually we can jump +/- 32MB (26 bits). I believe that the linker
inserts trampolines if the branch target is more than 32MB away, so it
should still work if the kernel is really large and the KVM code
happens to be at the end.
Stephen Rothwell has been asking me about this patch. He wants it in
(or something like it) so that he can get his daily linux-next powerpc
allyesconfig builds to stop failing.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] KVM: PPC: Assemble book3s{, _hv}_rmhandlers.S separately
Am 11.08.2011 um 01:58 schrieb Paul Mackerras :
> On Tue, Aug 02, 2011 at 02:20:28PM +0200, Alexander Graf wrote:
>> On 07/23/2011 09:41 AM, Paul Mackerras wrote:
>>> This makes arch/powerpc/kvm/book3s_rmhandlers.S and
>>> arch/powerpc/kvm/book3s_hv_rmhandlers.S be assembled as
>>> separate compilation units rather than having them #included in
>>> arch/powerpc/kernel/exceptions-64s.S. We no longer have any
>>> conditional branches between the exception prologs in
>>> exceptions-64s.S and the KVM handlers, so there is no need to
>>> keep their contents close together in the vmlinux image.
>>>
>>> In their current location, they are using up part of the limited
>>> space between the first-level interrupt handlers and the firmware
>>> NMI data area at offset 0x7000, and with some kernel configurations
>>> this area will overflow (e.g. allyesconfig), leading to an
>>> "attempt to .org backwards" error when compiling exceptions-64s.S.
>>>
>>> Moving them out requires that we add some #includes that the
>>> book3s_{,hv_}rmhandlers.S code was previously getting implicitly
>>> via exceptions-64s.S.
>>
>> So what if your kernel binary is bigger than the 24 bits we can jump
>> and the KVM code happens to be at the end? Or do we just not care
>> here?
>
> Actually we can jump +/- 32MB (26 bits). I believe that the linker
> inserts trampolines if the branch target is more than 32MB away, so it
> should still work if the kernel is really large and the KVM code
> happens to be at the end.
>
> Stephen Rothwell has been asking me about this patch. He wants it in
> (or something like it) so that he can get his daily linux-next powerpc
> allyesconfig builds to stop failing.
Yup, currently running autotest with this and other patches applied. Will send
out a pullreq soon.
Alex
>
> Paul.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" 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 v11 4/5] powerpc: Add flexcan device support for p1010rdb.
On Wed, Aug 10, 2011 at 08:16:33PM +0200, Wolfgang Grandegger wrote:
> On 08/10/2011 07:01 PM, Kumar Gala wrote:
> >
> > On Aug 10, 2011, at 11:27 AM, Robin Holt wrote:
> >
> >> I added a simple clock source for the p1010rdb so the flexcan driver
> >> could determine a clock frequency. The p1010 flexcan device only has
> >> an oscillator of system bus frequency divided by 2.
> >>
> >> Signed-off-by: Robin Holt
> >> Acked-by: Marc Kleine-Budde ,
> >> Acked-by: Wolfgang Grandegger ,
> >> Cc: U Bhaskar-B22300
> >> Cc: socketcan-c...@lists.berlios.de,
> >> Cc: net...@vger.kernel.org,
> >> Cc: PPC list
> >> Cc: Kumar Gala
> >> ---
> >> arch/powerpc/platforms/85xx/Kconfig|2 +
> >> arch/powerpc/platforms/85xx/Makefile |2 +
> >> arch/powerpc/platforms/85xx/clock.c| 52
> >>
> >> arch/powerpc/platforms/85xx/p1010rdb.c |8 +
> >> 4 files changed, 64 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/powerpc/platforms/85xx/clock.c
> >
> > I dont understand how mpc85xx_clk_functions() ends up being associated with
> > the frequency the flexcan is running at.
>
> The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for
> Flexcan devices.
>
> > This either seems to global or I'm missing something.
>
> This patch extends the existing Flexcan platform driver for ARM for the
> PowerPC using the device tree. Due to the nice integration of the device
> tree (of-platform) into the platform driver and devices, the difference
> are quite small (see patches 1..3). Apart from the endianess issue, only
> the clock needs to be handled in a common way. As ARM already uses the
> clk interface, we found it straight-forward to implement it for the
> P1010, or more general for the 85xx, as well, instead of using an
> additional helper function.
>
> > I still think the clk / freq info should be in the device tree and handled
> > in the driver and NOT arch/powerpc platform code.
>
> If I understand you correctly, you want the boot-loader to provide the
> relevant information by fixing up the device tree, which then can be
> handled arch-independently by the driver, right?
Marc and Wolfgang,
This is a very early swag at this which I worked up while driving home from
dinner
this evening. It works with my current config, but that includes at least one
bogus patch. I will have to do more testing tomorrow. For now, it is something
to ponder.
Thanks,
Robin
flexcan: Prefer device tree clock frequency if available.
If our CAN device's device tree node has a clock-frequency property,
then use that value for the can devices clock frequency. If not, fall
back to asking the platform/mach code for the clock frequency associated
with the flexcan device.
Too-early-to-be-signed-off-by: Robin Holt
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 662f832..d6a87c9 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#define DRV_NAME "flexcan"
@@ -929,12 +930,25 @@ static int __devinit flexcan_probe(struct platform_device
*pdev)
void __iomem *base;
resource_size_t mem_size;
int err, irq;
+ u32 clock_freq = 0;
- clk = clk_get(&pdev->dev, NULL);
- if (IS_ERR(clk)) {
- dev_err(&pdev->dev, "no clock defined\n");
- err = PTR_ERR(clk);
- goto failed_clock;
+ if (pdev->dev.of_node) {
+ u32 *clock_freq_p;
+
+ clk = NULL;
+ clock_freq_p = (u32 *)of_get_property(pdev->dev.of_node,
"clock-frequency", NULL);
+ if (clock_freq_p)
+ clock_freq = *clock_freq_p;
+ }
+
+ if (clock_freq) {
+ clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "no clock defined\n");
+ err = PTR_ERR(clk);
+ goto failed_clock;
+ }
+ clock_freq = clk_get_rate(clk);
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -967,7 +981,7 @@ static int __devinit flexcan_probe(struct platform_device
*pdev)
dev->flags |= IFF_ECHO; /* we support local echo in hardware */
priv = netdev_priv(dev);
- priv->can.clock.freq = clk_get_rate(clk);
+ priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = &flexcan_bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
priv->can.do_get_berr_counter = flexcan_get_berr_counter;
@@ -1002,7 +1016,8 @@ static int __devinit flexcan_probe(struct platform_device
*pdev)
failed_map:
release_mem_region(mem->start, mem_size);
failed_get:
- clk_put(clk);
+ if (clk)
+ clk_put(clk);
failed_clock:
return e
Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
On Aug 10, 2011, at 1:16 PM, Wolfgang Grandegger wrote: > On 08/10/2011 07:01 PM, Kumar Gala wrote: >> >> On Aug 10, 2011, at 11:27 AM, Robin Holt wrote: >> >>> I added a simple clock source for the p1010rdb so the flexcan driver >>> could determine a clock frequency. The p1010 flexcan device only has >>> an oscillator of system bus frequency divided by 2. >>> >>> Signed-off-by: Robin Holt >>> Acked-by: Marc Kleine-Budde , >>> Acked-by: Wolfgang Grandegger , >>> Cc: U Bhaskar-B22300 >>> Cc: socketcan-c...@lists.berlios.de, >>> Cc: net...@vger.kernel.org, >>> Cc: PPC list >>> Cc: Kumar Gala >>> --- >>> arch/powerpc/platforms/85xx/Kconfig|2 + >>> arch/powerpc/platforms/85xx/Makefile |2 + >>> arch/powerpc/platforms/85xx/clock.c| 52 >>> >>> arch/powerpc/platforms/85xx/p1010rdb.c |8 + >>> 4 files changed, 64 insertions(+), 0 deletions(-) >>> create mode 100644 arch/powerpc/platforms/85xx/clock.c >> >> I dont understand how mpc85xx_clk_functions() ends up being associated with >> the frequency the flexcan is running at. > > The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for > Flexcan devices. > >> This either seems to global or I'm missing something. > > This patch extends the existing Flexcan platform driver for ARM for the > PowerPC using the device tree. Due to the nice integration of the device > tree (of-platform) into the platform driver and devices, the difference > are quite small (see patches 1..3). Apart from the endianess issue, only > the clock needs to be handled in a common way. As ARM already uses the > clk interface, we found it straight-forward to implement it for the > P1010, or more general for the 85xx, as well, instead of using an > additional helper function. I see, that. What concerns me is there are numerous clocks / frequencies that exist inside a MPC85xx/P1010 SOC. The code I'm seeing does NOT seem to do anything to relate this clock JUST to the flexcan. >> I still think the clk / freq info should be in the device tree and handled >> in the driver and NOT arch/powerpc platform code. > > If I understand you correctly, you want the boot-loader to provide the > relevant information by fixing up the device tree, which then can be > handled arch-independently by the driver, right? Yes, that is part of what I want. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
44x/pci: Add __init annotations for *init_port_hw() functions.
The various port_init_hw methods of ppc4xx_pciex_hwops should have been
marked __init and when I added ppc4xx_pciex_port_reset_sdr(), which is
__init. This added many section mismatch warnings like:
WARNING: arch/powerpc/sysdev/built-in.o(.text+0x5c68): Section mismatch in
reference from the function ppc440spe_pciex_init_port_hw() to the function
.init.text:ppc4xx_pciex_port_reset_sdr()
The function ppc440spe_pciex_init_port_hw() references
the function __init ppc4xx_pciex_port_reset_sdr().
This is often because ppc440spe_pciex_init_port_hw lacks a __init
annotation or the annotation of ppc4xx_pciex_port_reset_sdr is wrong.
Trivial patch to silence those warnings.
Reported-By: Stephen Rothwell
Signed-off-by: Tony Breeds
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index dbfe96b..60541a6 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -834,7 +834,7 @@ static int __init ppc440spe_pciex_core_init(struct
device_node *np)
return 3;
}
-static int ppc440spe_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc440spe_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
u32 val = 1 << 24;
@@ -872,12 +872,12 @@ static int ppc440spe_pciex_init_port_hw(struct
ppc4xx_pciex_port *port)
return ppc4xx_pciex_port_reset_sdr(port);
}
-static int ppc440speA_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc440speA_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
return ppc440spe_pciex_init_port_hw(port);
}
-static int ppc440speB_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc440speB_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
int rc = ppc440spe_pciex_init_port_hw(port);
@@ -936,7 +936,7 @@ static int __init ppc460ex_pciex_core_init(struct
device_node *np)
return 2;
}
-static int ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
u32 val;
u32 utlset1;
@@ -1122,7 +1122,7 @@ static int __init ppc460sx_pciex_core_init(struct
device_node *np)
return 2;
}
-static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
if (port->endpoint)
@@ -1189,7 +1189,7 @@ static void ppc405ex_pcie_phy_reset(struct
ppc4xx_pciex_port *port)
mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET, 0x00101000);
}
-static int ppc405ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init ppc405ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
u32 val;
Yours Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] [PATCH] powerpc: numa: Remove double of_node_put in hot_add_node_scn_to_nid
During memory hotplug testing, I got the following warning: ERROR: Bad of_node_put() on /memory@0 of_node_release kref_put of_node_put of_find_node_by_type hot_add_node_scn_to_nid hot_add_scn_to_nid memory_add_physaddr_to_nid ... of_find_node_by_type() loop does the of_node_put for us so we only need the handle the case where we terminate the loop early. As suggested by Stephen Rothwell we can do the of_node_put unconditionally outside of the loop since of_node_put handles a NULL argument fine. Signed-off-by: Anton Blanchard Cc: sta...@kernel.org --- Index: linux-powerpc/arch/powerpc/mm/numa.c === --- linux-powerpc.orig/arch/powerpc/mm/numa.c 2011-06-06 08:07:35.148708089 +1000 +++ linux-powerpc/arch/powerpc/mm/numa.c2011-08-11 09:07:07.329584634 +1000 @@ -1214,11 +1214,12 @@ int hot_add_node_scn_to_nid(unsigned lon break; } - of_node_put(memory); if (nid >= 0) break; } + of_node_put(memory); + return nid; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] [PATCH] powerpc: Use for_each_node_by_type instead of open coding it
Use for_each_node_by_type instead of open coding it.
Signed-off-by: Anton Blanchard
---
Index: linux-powerpc/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-powerpc.orig/arch/powerpc/kernel/machine_kexec_64.c 2011-08-10
16:17:52.508167607 +1000
+++ linux-powerpc/arch/powerpc/kernel/machine_kexec_64.c2011-08-10
16:18:03.0 +1000
@@ -74,8 +74,7 @@ int default_machine_kexec_prepare(struct
}
/* We also should not overwrite the tce tables */
- for (node = of_find_node_by_type(NULL, "pci"); node != NULL;
- node = of_find_node_by_type(node, "pci")) {
+ for_each_node_by_type(node, "pci") {
basep = of_get_property(node, "linux,tce-base", NULL);
sizep = of_get_property(node, "linux,tce-size", NULL);
if (basep == NULL || sizep == NULL)
Index: linux-powerpc/arch/powerpc/kernel/setup_64.c
===
--- linux-powerpc.orig/arch/powerpc/kernel/setup_64.c 2011-08-10
16:17:52.518167781 +1000
+++ linux-powerpc/arch/powerpc/kernel/setup_64.c2011-08-10
16:19:00.629356097 +1000
@@ -278,7 +278,7 @@ static void __init initialize_cache_info
DBG(" -> initialize_cache_info()\n");
- for (np = NULL; (np = of_find_node_by_type(np, "cpu"));) {
+ for_each_node_by_type(np, "cpu") {
num_cpus += 1;
/* We're assuming *all* of the CPUs have the same
Index: linux-powerpc/arch/powerpc/mm/numa.c
===
--- linux-powerpc.orig/arch/powerpc/mm/numa.c 2011-08-10 16:17:52.508167607
+1000
+++ linux-powerpc/arch/powerpc/mm/numa.c2011-08-10 16:19:57.080356036
+1000
@@ -710,7 +710,7 @@ static void __init parse_drconf_memory(s
static int __init parse_numa_properties(void)
{
struct device_node *cpu = NULL;
- struct device_node *memory = NULL;
+ struct device_node *memory;
int default_nid = 0;
unsigned long i;
@@ -750,8 +750,8 @@ static int __init parse_numa_properties(
}
get_n_mem_cells(&n_mem_addr_cells, &n_mem_size_cells);
- memory = NULL;
- while ((memory = of_find_node_by_type(memory, "memory")) != NULL) {
+
+ for_each_node_by_type(memory, "memory") {
unsigned long start;
unsigned long size;
int nid;
@@ -1187,10 +1187,10 @@ static int hot_add_drconf_scn_to_nid(str
*/
int hot_add_node_scn_to_nid(unsigned long scn_addr)
{
- struct device_node *memory = NULL;
+ struct device_node *memory;
int nid = -1;
- while ((memory = of_find_node_by_type(memory, "memory")) != NULL) {
+ for_each_node_by_type(memory, "memory") {
unsigned long start, size;
int ranges;
const unsigned int *memcell_buf;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] [PATCH] powerpc: Coding style cleanups
While converting code to use for_each_node_by_type I noticed a
number of coding style issues.
Signed-off-by: Anton Blanchard
---
Index: linux-powerpc/arch/powerpc/kernel/setup_64.c
===
--- linux-powerpc.orig/arch/powerpc/kernel/setup_64.c 2011-08-10
16:19:00.629356097 +1000
+++ linux-powerpc/arch/powerpc/kernel/setup_64.c2011-08-10
16:21:31.642031299 +1000
@@ -281,11 +281,11 @@ static void __init initialize_cache_info
for_each_node_by_type(np, "cpu") {
num_cpus += 1;
- /* We're assuming *all* of the CPUs have the same
+ /*
+* We're assuming *all* of the CPUs have the same
* d-cache and i-cache sizes... -Peter
*/
-
- if ( num_cpus == 1 ) {
+ if (num_cpus == 1) {
const u32 *sizep, *lsizep;
u32 size, lsize;
@@ -294,10 +294,13 @@ static void __init initialize_cache_info
sizep = of_get_property(np, "d-cache-size", NULL);
if (sizep != NULL)
size = *sizep;
- lsizep = of_get_property(np, "d-cache-block-size",
NULL);
+ lsizep = of_get_property(np, "d-cache-block-size",
+NULL);
/* fallback if block size missing */
if (lsizep == NULL)
- lsizep = of_get_property(np,
"d-cache-line-size", NULL);
+ lsizep = of_get_property(np,
+"d-cache-line-size",
+NULL);
if (lsizep != NULL)
lsize = *lsizep;
if (sizep == 0 || lsizep == 0)
@@ -314,9 +317,12 @@ static void __init initialize_cache_info
sizep = of_get_property(np, "i-cache-size", NULL);
if (sizep != NULL)
size = *sizep;
- lsizep = of_get_property(np, "i-cache-block-size",
NULL);
+ lsizep = of_get_property(np, "i-cache-block-size",
+NULL);
if (lsizep == NULL)
- lsizep = of_get_property(np,
"i-cache-line-size", NULL);
+ lsizep = of_get_property(np,
+"i-cache-line-size",
+NULL);
if (lsizep != NULL)
lsize = *lsizep;
if (sizep == 0 || lsizep == 0)
Index: linux-powerpc/arch/powerpc/mm/numa.c
===
--- linux-powerpc.orig/arch/powerpc/mm/numa.c 2011-08-10 16:19:57.080356036
+1000
+++ linux-powerpc/arch/powerpc/mm/numa.c2011-08-10 16:20:46.981240046
+1000
@@ -709,7 +709,6 @@ static void __init parse_drconf_memory(s
static int __init parse_numa_properties(void)
{
- struct device_node *cpu = NULL;
struct device_node *memory;
int default_nid = 0;
unsigned long i;
@@ -732,6 +731,7 @@ static int __init parse_numa_properties(
* each node to be onlined must have NODE_DATA etc backing it.
*/
for_each_present_cpu(i) {
+ struct device_node *cpu;
int nid;
cpu = of_get_cpu_node(i, NULL);
@@ -800,8 +800,9 @@ new_range:
}
/*
-* Now do the same thing for each MEMBLOCK listed in the
ibm,dynamic-memory
-* property in the ibm,dynamic-reconfiguration-memory node.
+* Now do the same thing for each MEMBLOCK listed in the
+* ibm,dynamic-memory property in the
+* ibm,dynamic-reconfiguration-memory node.
*/
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
if (memory)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: Fix oops when echoing bad values to /sys/devices/system/memory/probe
If we echo an address the hypervisor doesn't like to
/sys/devices/system/memory/probe we oops the box:
# echo 0x100 > /sys/devices/system/memory/probe
kernel BUG at arch/powerpc/mm/hash_utils_64.c:541!
The backtrace is:
create_section_mapping
arch_add_memory
add_memory
memory_probe_store
sysdev_class_store
sysfs_write_file
vfs_write
SyS_write
In create_section_mapping we BUG if htab_bolt_mapping returned
an error. A better approach is to return an error which will
propagate back to userspace.
Rerunning the test with this patch applied:
# echo 0x100 > /sys/devices/system/memory/probe
-bash: echo: write error: Invalid argument
Signed-off-by: Anton Blanchard
Cc: sta...@kernel.org
---
Index: linux-build/arch/powerpc/mm/hash_utils_64.c
===
--- linux-build.orig/arch/powerpc/mm/hash_utils_64.c2011-08-10
17:00:42.603007554 +1000
+++ linux-build/arch/powerpc/mm/hash_utils_64.c 2011-08-10 17:05:56.338457482
+1000
@@ -534,11 +534,11 @@ static unsigned long __init htab_get_tab
}
#ifdef CONFIG_MEMORY_HOTPLUG
-void create_section_mapping(unsigned long start, unsigned long end)
+int create_section_mapping(unsigned long start, unsigned long end)
{
- BUG_ON(htab_bolt_mapping(start, end, __pa(start),
+ return htab_bolt_mapping(start, end, __pa(start),
pgprot_val(PAGE_KERNEL), mmu_linear_psize,
-mmu_kernel_ssize));
+mmu_kernel_ssize);
}
int remove_section_mapping(unsigned long start, unsigned long end)
Index: linux-build/arch/powerpc/include/asm/sparsemem.h
===
--- linux-build.orig/arch/powerpc/include/asm/sparsemem.h 2011-08-10
17:06:11.948728948 +1000
+++ linux-build/arch/powerpc/include/asm/sparsemem.h2011-08-10
17:06:21.878901648 +1000
@@ -16,7 +16,7 @@
#endif /* CONFIG_SPARSEMEM */
#ifdef CONFIG_MEMORY_HOTPLUG
-extern void create_section_mapping(unsigned long start, unsigned long end);
+extern int create_section_mapping(unsigned long start, unsigned long end);
extern int remove_section_mapping(unsigned long start, unsigned long end);
#ifdef CONFIG_NUMA
extern int hot_add_scn_to_nid(unsigned long scn_addr);
Index: linux-build/arch/powerpc/mm/mem.c
===
--- linux-build.orig/arch/powerpc/mm/mem.c 2011-08-10 17:06:42.539260996
+1000
+++ linux-build/arch/powerpc/mm/mem.c 2011-08-10 17:06:45.269308484 +1000
@@ -123,7 +123,8 @@ int arch_add_memory(int nid, u64 start,
pgdata = NODE_DATA(nid);
start = (unsigned long)__va(start);
- create_section_mapping(start, start + size);
+ if (create_section_mapping(start, start + size))
+ return -EINVAL;
/* this should work for most non-highmem platforms */
zone = pgdata->node_zones;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
