* 44x/pci: Add __init annotations for *init_port_hw() functions.
From: Tony Breeds @ 2011-08-11 6:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev, Josh Boyer; +Cc: Stephen Rothwell
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 <sfr@canb.auug.org.au>
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
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
^ permalink raw reply related
* Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
From: Kumar Gala @ 2011-08-11 4:46 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E42CB01.7030700@grandegger.com>
On Aug 10, 2011, at 1:16 PM, Wolfgang Grandegger wrote:
> On 08/10/2011 07:01 PM, Kumar Gala wrote:
>>=20
>> On Aug 10, 2011, at 11:27 AM, Robin Holt wrote:
>>=20
>>> 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.
>>>=20
>>> Signed-off-by: Robin Holt <holt@sgi.com>
>>> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
>>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>,
>>> Cc: U Bhaskar-B22300 <B22300@freescale.com>
>>> Cc: socketcan-core@lists.berlios.de,
>>> Cc: netdev@vger.kernel.org,
>>> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
>>> Cc: Kumar Gala <galak@kernel.crashing.org>
>>> ---
>>> 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
>>=20
>> I dont understand how mpc85xx_clk_functions() ends up being =
associated with the frequency the flexcan is running at.
>=20
> The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" =
for
> Flexcan devices.
>=20
>> This either seems to global or I'm missing something.
>=20
> 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.
>=20
> 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=
^ permalink raw reply
* Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-11 3:56 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E42CB01.7030700@grandegger.com>
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 <holt@sgi.com>
> >> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
> >> Acked-by: Wolfgang Grandegger <wg@grandegger.com>,
> >> Cc: U Bhaskar-B22300 <B22300@freescale.com>
> >> Cc: socketcan-core@lists.berlios.de,
> >> Cc: netdev@vger.kernel.org,
> >> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> >> Cc: Kumar Gala <galak@kernel.crashing.org>
> >> ---
> >> 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 <holt@sgi.com>
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 <linux/kernel.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#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 err;
}
@@ -1020,7 +1035,8 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem->start, resource_size(mem));
- clk_put(priv->clk);
+ if (priv->clk)
+ clk_put(priv->clk);
free_candev(dev);
^ permalink raw reply related
* Re: [PATCH 1/3] KVM: PPC: Assemble book3s{, _hv}_rmhandlers.S separately
From: Alexander Graf @ 2011-08-11 1:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <20110810235818.GC5536@bloggs.ozlabs.ibm.com>
Am 11.08.2011 um 01:58 schrieb Paul Mackerras <paulus@samba.org>:
> 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.
>>>=20
>>> 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.
>>>=20
>>> Moving them out requires that we add some #includes that the
>>> book3s_{,hv_}rmhandlers.S code was previously getting implicitly
>>> via exceptions-64s.S.
>>=20
>> 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?
>=20
> 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.
>=20
> 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 se=
nd out a pullreq soon.
Alex
>=20
> Paul.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] KVM: PPC: Assemble book3s{,_hv}_rmhandlers.S separately
From: Paul Mackerras @ 2011-08-10 23:58 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <4E37EB8C.8040408@suse.de>
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.
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: fix build errors with older toolchains
From: Alexander Graf @ 2011-08-10 21:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, Marcelo Tosatti, linux-kernel, kvm-ppc, Paul Mackerras,
Avi Kivity, Nishanth Aravamudan, linuxppc-dev
In-Reply-To: <1313002585.1674.13.camel@pasglop>
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:
>>>=20
>>> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1254: Error: Unrecognized =
opcode: stxvd2x
>>> arch/powerpc/kvm/book3s_hv_rmhandlers.S:1316: Error: Unrecognized =
opcode: lxvd2x
>>=20
>> Paul, mind to ack?
>=20
> I merged it already :-) It was trivial & annoying enough.
Alright then, I won't touch it :)
Alex
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: fix build errors with older toolchains
From: Benjamin Herrenschmidt @ 2011-08-10 18:56 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm, Marcelo Tosatti, linux-kernel, kvm-ppc, Paul Mackerras,
Avi Kivity, Nishanth Aravamudan, linuxppc-dev
In-Reply-To: <4E429CAD.5050000@suse.de>
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<nacc@us.ibm.com>
> > ---
> > 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-08-10 18:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <CA+55aFxbjN3y3Wg193C2qDLbv+AeuR0=23p-r38jB19WbbRa-g@mail.gmail.com>
On Wed, 2011-08-10 at 11:07 -0700, Linus Torvalds wrote:
> On Wed, Aug 10, 2011 at 8:27 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> 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.
^ permalink raw reply
* Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 18:45 UTC (permalink / raw)
To: Scott Wood
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
Robin Holt, PPC list
In-Reply-To: <4E42D09E.4080405@freescale.com>
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,<processor>-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,<processor>-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
^ permalink raw reply
* Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-10 18:40 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
PPC list
In-Reply-To: <20110810183016.GY4926@sgi.com>
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,<processor>-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,<processor>-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
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-10 18:39 UTC (permalink / raw)
To: Robin Holt
Cc: Wood Scott-B07421, netdev@vger.kernel.org, U Bhaskar-B22300,
socketcan-core@lists.berlios.de, PPC list
In-Reply-To: <20110810183526.GZ4926@sgi.com>
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
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 18:35 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, netdev@vger.kernel.org, U Bhaskar-B22300,
socketcan-core@lists.berlios.de, Robin Holt, PPC list
In-Reply-To: <4E42CDA8.5050902@freescale.com>
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 +0000, 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
^ permalink raw reply
* Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 18:30 UTC (permalink / raw)
To: Scott Wood
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
Robin Holt, PPC list
In-Reply-To: <4E42C196.7030708@freescale.com>
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-<processor>"
> >>
> >> fsl,<processor>-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,<processor>-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,<processor>-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>;
};
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-10 18:27 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Wood Scott-B07421, netdev@vger.kernel.org, U Bhaskar-B22300,
socketcan-core@lists.berlios.de, Robin Holt, PPC list
In-Reply-To: <4E42CCB0.8090803@grandegger.com>
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 +0000, 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
^ permalink raw reply
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2011-08-10 18:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
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
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-10 18:23 UTC (permalink / raw)
To: Robin Holt
Cc: Wood Scott-B07421, netdev@vger.kernel.org, U Bhaskar-B22300,
socketcan-core@lists.berlios.de, PPC list
In-Reply-To: <20110810160054.GT4926@sgi.com>
On 08/10/2011 06:00 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 02:36:20PM +0000, 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.
^ permalink raw reply
* Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
From: Wolfgang Grandegger @ 2011-08-10 18:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list
In-Reply-To: <8E5FA886-038D-4DF4-8A54-DD60188A21A2@kernel.crashing.org>
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 <holt@sgi.com>
>> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
>> Acked-by: Wolfgang Grandegger <wg@grandegger.com>,
>> Cc: U Bhaskar-B22300 <B22300@freescale.com>
>> Cc: socketcan-core@lists.berlios.de,
>> Cc: netdev@vger.kernel.org,
>> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> 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.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2011-08-10 18:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <1312990072.1674.5.camel@pasglop>
On Wed, Aug 10, 2011 at 8:27 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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 actuall=
y
> send it as I was travelling.
>
> Cheers,
> Ben.
>
> The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c=
03:
>
> =A0Merge 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:
>
> =A0git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git ..BRANC=
H.NOT.VERIFIED..
What branch?
Linus
^ permalink raw reply
* Re: union/struct representations for MAS Registers
From: Kumar Gala @ 2011-08-10 17:48 UTC (permalink / raw)
To: David Laight; +Cc: Linuxppc-dev list
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AE26@saturn3.aculab.com>
On Aug 10, 2011, at 12:38 PM, David Laight wrote:
>=20
>>> Bitfields are rather non-portable, the compiler has a lot of choice
>>> about how to align the bits in memory.
>>=20
>> I'm ok with the masking stuff.
>> However, I'm actually surprised this is true given the=20
>> maturity of our ABIs.
>=20
> The C standard says nothing at all about how bitfields are =
implemented,
> I think the first bit might be 0x1, 0x80, 0x1000000 or 0x80000000
> when treated as a 32bit value, regardless of the endianness.
>=20
> Different architectures can (and do) assign things in different ways.
> So code that is ok on ppc might fail on arm or x86 (etc).
>=20
> 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=
^ permalink raw reply
* RE: union/struct representations for MAS Registers
From: David Laight @ 2011-08-10 17:38 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: Linuxppc-dev list
In-Reply-To: <B8DCD489-B158-40BB-87BD-873A3591737F@pobox.com>
=20
> > Bitfields are rather non-portable, the compiler has a lot of choice
> > about how to align the bits in memory.
>=20
> I'm ok with the masking stuff.
> However, I'm actually surprised this is true given the=20
> 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, 0x1000000 or 0x80000000
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
^ permalink raw reply
* Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
From: Paul Gortmaker @ 2011-08-10 16:40 UTC (permalink / raw)
To: Scott Wood; +Cc: Baruch Siach, linuxppc-dev, Timur Tabi
In-Reply-To: <4E42AB6F.1050900@freescale.com>
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 <baruch@tkos.co.il> 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
>
^ permalink raw reply
* Re: [PATCH v11 5/5] powerpc: Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-10 17:36 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
PPC list
In-Reply-To: <20110810171933.GW4926@sgi.com>
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-<processor>"
>>
>> fsl,<processor>-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,<processor>-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
^ permalink raw reply
* Re: union/struct representations for MAS Registers
From: Jimi Xenidis @ 2011-08-10 17:31 UTC (permalink / raw)
To: David Laight; +Cc: Linuxppc-dev list
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AE25@saturn3.aculab.com>
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
>
>
^ permalink raw reply
* Re: union/struct representations for MAS Registers
From: Jimi Xenidis @ 2011-08-10 17:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev list
In-Reply-To: <9FE83BDE-592D-42FC-B2B4-A2B6E7E49206@kernel.crashing.org>
On Aug 10, 2011, at 12:25 PM, Kumar Gala wrote:
>=20
> On Aug 10, 2011, at 12:21 PM, Jimi Xenidis wrote:
>=20
>> I have some and use them in some code, they represent ISA 2.06 MAVN=3D1=
(version 2)
>> Can I keep them?
>> if so, should I put them somewhere useful to others?
>>=20
>> 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;
>> };
>> };
>=20
> 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
>=20
> - k
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Kumar Gala @ 2011-08-10 17:26 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core@lists.berlios.de, Wood Scott-B07421,
U Bhaskar-B22300, PPC list, netdev@vger.kernel.org
In-Reply-To: <20110810172040.GX4926@sgi.com>
>>>>>>> So the node names should be
>>>>>>> can@1c000 {
>>>>>>> can@1d000 {
>>>>>>> correct?
>>>>>>>=20
>>>>>> [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" ?
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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?
>>>>=20
>>>> It has not effect. The label is just if you need to reference it =
via some other means.
>>>=20
>>> Does the alias have an effect?
>>=20
>> nope
>=20
> 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=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox