* [PATCH v12 4/6] flexcan: Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-12 8:45 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300, Scott Wood, Grant Likely
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
Robin Holt, PPC list
In-Reply-To: <1313138752-24006-1-git-send-email-holt@sgi.com>
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 <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: Grant Likely <grant.likely@secretlab.ca>
Cc: socketcan-core@lists.berlios.de
Cc: netdev@vger.kernel.org
Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
Cc: devicetree-discuss@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
^ permalink raw reply related
* [PATCH v12 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-12 8:45 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300, Scott Wood, Grant Likely
Cc: netdev, devicetree-discuss, socketcan-core, Robin Holt, PPC list
In-Reply-To: <1313138752-24006-1-git-send-email-holt@sgi.com>
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 used by the driver so we are removing them.
Signed-off-by: Robin Holt <holt@sgi.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>,
To: Wolfgang Grandegger <wg@grandegger.com>,
To: U Bhaskar-B22300 <B22300@freescale.com>
To: Scott Wood <scottwood@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: socketcan-core@lists.berlios.de,
Cc: netdev@vger.kernel.org,
Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ++++----------------
arch/powerpc/boot/dts/p1010rdb.dts | 10 +---
arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
3 files changed, 17 insertions(+), 64 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1a729f0..80a78a9 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -1,61 +1,22 @@
-CAN Device Tree Bindings
-------------------------
-2011 Freescale Semiconductor, Inc.
+Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
-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,<processor>-flexcan" and "fsl,flexcan"
-Can Engine Clock Source
- There are two sources for CAN clock
- - Platform Clock It represents the bus clock
- - Oscillator Clock
+ An implementation should also claim any of the following compatibles
+ that it is fully backwards compatible with:
- Peripheral Clock (PLL)
- --------------
- |
- --------- -------------
- | |CPI Clock | Prescaler | Sclock
- | |---------------->| (1.. 256) |------------>
- --------- -------------
- | |
- -------------- ---------------------CLK_SRC
- Oscillator Clock
+ - fsl,p1010-flexcan
-- 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).
+- reg : Offset and length of the register set for this device
+- interrupts : Interrupt tuple for this device
-- 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.
+Example:
-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";
+ can@1c000 {
+ compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-source = "platform";
- fsl,flexcan-clock-divider = <2>;
- clock-frequency = <fixed by u-boot>;
};
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";
- };
-
- can1@1d000 {
- fsl,flexcan-clock-source = "platform";
- };
-
usb@22000 {
phy_type = "utmi";
};
diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
index 7f51104..f00076b 100644
--- a/arch/powerpc/boot/dts/p1010si.dtsi
+++ b/arch/powerpc/boot/dts/p1010si.dtsi
@@ -140,20 +140,18 @@
interrupt-parent = <&mpic>;
};
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ can0: can@1c000 {
+ compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
- can1@1d000 {
- compatible = "fsl,flexcan-v1.0";
+ can1: can@1d000 {
+ compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1d000 0x1000>;
interrupts = <61 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
L2: l2-cache-controller@20000 {
--
1.7.2.1
^ permalink raw reply related
* Re: [PATCH v11 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-12 8:28 UTC (permalink / raw)
To: Grant Likely
Cc: netdev, devicetree-discuss, U Bhaskar-B22300, socketcan-core,
Robin Holt, Scott Wood, PPC list
In-Reply-To: <CACxGe6vA8K7fhrSvBpKC+9aKftUc2+1EAUQ=A0SmmwzJ2Le=9A@mail.gmail.com>
On Thu, Aug 11, 2011 at 10:53:43AM -0600, Grant Likely wrote:
> On Thu, Aug 11, 2011 at 10:07 AM, Robin Holt <holt@sgi.com> wrote:
> > +- compatible : Should be "fsl,<processor>-flexcan" and "fsl,flexcan"
>
> Don't do this. "fsl,flexcan" is far too generic. Be specific to the
> soc part number or the ip core implementation version.
I don't have any crumbs to go with here. There is nothing in the
documentation I have found to indicate what this is or should be.
I looked at the documentation for the P1010 processor and there is nothing
in there which I noticed that indicates what I could possibly use other
than flexcan. They don't even indicate the registers are equivalent or
identical to their i.MX implementations for i.MX25 and i.MX35. The only
thing they call it is flexcan. I have asked our local freescale rep and
he said "There is no 'chip', it is just flexcan. flexcan is flexcan."
His tone was such that I got the feeling he thought the question was
crazy as flexcan is flexcan.
> > -Can Engine Clock Source
> > - There are two sources for CAN clock
> > - - Platform Clock It represents the bus clock
> > - - Oscillator Clock
> > + An implementation should also claim any of the following compatibles
> > + that it is fully backwards compatible with:
> >
> > - Peripheral Clock (PLL)
> > - --------------
> > - |
> > - --------- -------------
> > - | |CPI Clock | Prescaler | Sclock
> > - | |---------------->| (1.. 256) |------------>
> > - --------- -------------
> > - | |
> > - -------------- ---------------------CLK_SRC
> > - Oscillator Clock
> > + - fsl,p1010-flexcan
> >
> > -- 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).
> > +- reg : Offset and length of the register set for this device
> > +- interrupts : Interrupt tuple for this device
> >
> > -- 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.
> > +Example:
> >
> > -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 = <fixed by u-boot>;
> > - };
> > + can@1c000 {
> > + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> > + reg = <0x1c000 0x1000>;
> > + interrupts = <48 0x2>;
> > + interrupt-parent = <&mpic>;
> > + };
>
> The diffstat for this patch looks too big because the whitespace has
> changed. Try to restrict whitespace changes so that the patch is
> friendly to reviewers.
Reworked the best I can. That reduced the diffstat by 3 lines.
Robin
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Alexander Graf @ 2011-08-12 8:09 UTC (permalink / raw)
To: David Gibson
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <20110812074308.GV30552@yookeroo.fritz.box>
Am 12.08.2011 um 09:43 schrieb David Gibson <david@gibson.dropbear.id.au>:
> On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
>>=20
>> Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>=
:
>>=20
>>> On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
>>>> When running a PAPR guest, we need to handle a few hypercalls in kernel=
space,
>>>> most prominently the page table invalidation (to sync the shadows).
>>>>=20
>>>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I=
tried
>>>> to share the code with HV mode, but it ended up being a lot easier this=
way
>>>> around, as the two differ too much in those details.
>>>=20
>>> Are these strictly necessary, or just an optimization? Because you're
>>> using the space allocated by qemu for the guest hash table, it seems
>>> to be you could just let h_enter fall through to qemu which will put
>>> the right thing into the guest hash table which you can then walk in
>>> the kernel translation code.
>>=20
>> Every time a PTE can be invalidated, we need to do so in kvm to keep
>> the SPT in sync. IIRC h_enter can evict/overwrite a previous entry,
>> so we need to handle it in kvm as well :). Removal definitely needs
>> to happin in-kernel.
>=20
> True. I think you could actually delay this invalidation until the
> guest issues the tlbie, but it's probably not worth it.
Well, since we need to have HTAB modification code in kvm for PR either way,=
I'd rather have all of it at the same place :)
Alex=
^ permalink raw reply
* Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
From: Alexander Graf @ 2011-08-12 8:07 UTC (permalink / raw)
To: David Gibson
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <20110812074359.GW30552@yookeroo.fritz.box>
Am 12.08.2011 um 09:43 schrieb David Gibson <david@gibson.dropbear.id.au>:
> On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
>>=20
>> Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>=
:
>>=20
>>> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
>>>> PAPR defines hypercalls as SC1 instructions. Using these, the guest mod=
ifies
>>>> page tables and does other privileged operations that it wouldn't be al=
lowed
>>>> to do in supervisor mode.
>>>>=20
>>>> This patch adds support for PR KVM to trap these instructions and route=
them
>>>> through the same PAPR hypercall interface that we already use for HV st=
yle
>>>> KVM.
>>>=20
>>> This will work on a powermac or bare metal host. Unfortunately, it's
>>> not enough on a pSeries LPAR host - the sc 1 instruction from the
>>> guest problem state will go direct to the hypervisor, which will
>>> return an error rather than trapping to the guest kernel.
>>>=20
>>> The only way around this I can see is for qemu to search for and patch
>>> up sc 1 instructions to something else. Obviously that would also
>>> need some kernel support, and probably a capability to let it know if
>>> it's necessary.
>>=20
>> Well I'd like to keep Qemu out of the patching business, so the
>> guest kernel would have to patch itself.
>=20
> Well sure, but guest patching itself means it can't run existing
> kernels. I thought qemu already patched a few things, ugly though
> that approach is.
Nope, qemu doesn't patch guest code by itself. The only time the guest kerne=
l doesn't patch itself is the TPR acceleration for Windows - because we can'=
t modify the guest here.
I also don't think it's that important to support older Linux guests if it m=
eans we need to patch the guest from the outside :). If you really need to u=
se PHyP, just run a newer guest kernel or -M mac99.
One thing I agree with though is that we should fail the CAP enable if we ru=
n on broken hypervisors.
Alex
>=20
^ permalink raw reply
* Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
From: David Gibson @ 2011-08-12 7:43 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <998B41E9-23CC-4FBD-BD35-11004D77B087@suse.de>
On Fri, Aug 12, 2011 at 07:35:42AM +0200, Alexander Graf wrote:
>
> Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>:
>
> > On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
> >> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
> >> page tables and does other privileged operations that it wouldn't be allowed
> >> to do in supervisor mode.
> >>
> >> This patch adds support for PR KVM to trap these instructions and route them
> >> through the same PAPR hypercall interface that we already use for HV style
> >> KVM.
> >
> > This will work on a powermac or bare metal host. Unfortunately, it's
> > not enough on a pSeries LPAR host - the sc 1 instruction from the
> > guest problem state will go direct to the hypervisor, which will
> > return an error rather than trapping to the guest kernel.
> >
> > The only way around this I can see is for qemu to search for and patch
> > up sc 1 instructions to something else. Obviously that would also
> > need some kernel support, and probably a capability to let it know if
> > it's necessary.
>
> Well I'd like to keep Qemu out of the patching business, so the
> guest kernel would have to patch itself.
Well sure, but guest patching itself means it can't run existing
kernels. I thought qemu already patched a few things, ugly though
that approach is.
> But yes, PHyP guests can't
> run this target yet :). I'll take a stab at that too, but one
> continent at a time! ;)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: David Gibson @ 2011-08-12 7:43 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <D03414E2-97E0-4439-BD88-E3FFCCF1E5FB@suse.de>
On Fri, Aug 12, 2011 at 07:38:54AM +0200, Alexander Graf wrote:
>
> Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>:
>
> > On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
> >> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> >> most prominently the page table invalidation (to sync the shadows).
> >>
> >> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> >> to share the code with HV mode, but it ended up being a lot easier this way
> >> around, as the two differ too much in those details.
> >
> > Are these strictly necessary, or just an optimization? Because you're
> > using the space allocated by qemu for the guest hash table, it seems
> > to be you could just let h_enter fall through to qemu which will put
> > the right thing into the guest hash table which you can then walk in
> > the kernel translation code.
>
> Every time a PTE can be invalidated, we need to do so in kvm to keep
> the SPT in sync. IIRC h_enter can evict/overwrite a previous entry,
> so we need to handle it in kvm as well :). Removal definitely needs
> to happin in-kernel.
True. I think you could actually delay this invalidation until the
guest issues the tlbie, but it's probably not worth it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Alexander Graf @ 2011-08-12 5:38 UTC (permalink / raw)
To: David Gibson
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <20110812033529.GS30552@yookeroo.fritz.box>
Am 12.08.2011 um 05:35 schrieb David Gibson <david@gibson.dropbear.id.au>:
> On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
>> When running a PAPR guest, we need to handle a few hypercalls in kernel s=
pace,
>> most prominently the page table invalidation (to sync the shadows).
>>=20
>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I t=
ried
>> to share the code with HV mode, but it ended up being a lot easier this w=
ay
>> around, as the two differ too much in those details.
>=20
> Are these strictly necessary, or just an optimization? Because you're
> using the space allocated by qemu for the guest hash table, it seems
> to be you could just let h_enter fall through to qemu which will put
> the right thing into the guest hash table which you can then walk in
> the kernel translation code.
Every time a PTE can be invalidated, we need to do so in kvm to keep the SPT=
in sync. IIRC h_enter can evict/overwrite a previous entry, so we need to h=
andle it in kvm as well :). Removal definitely needs to happin in-kernel.
Alex
>=20
^ permalink raw reply
* Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
From: Alexander Graf @ 2011-08-12 5:35 UTC (permalink / raw)
To: David Gibson
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <20110812033343.GR30552@yookeroo.fritz.box>
Am 12.08.2011 um 05:33 schrieb David Gibson <david@gibson.dropbear.id.au>:
> On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
>> PAPR defines hypercalls as SC1 instructions. Using these, the guest modif=
ies
>> page tables and does other privileged operations that it wouldn't be allo=
wed
>> to do in supervisor mode.
>>=20
>> This patch adds support for PR KVM to trap these instructions and route t=
hem
>> through the same PAPR hypercall interface that we already use for HV styl=
e
>> KVM.
>=20
> This will work on a powermac or bare metal host. Unfortunately, it's
> not enough on a pSeries LPAR host - the sc 1 instruction from the
> guest problem state will go direct to the hypervisor, which will
> return an error rather than trapping to the guest kernel.
>=20
> The only way around this I can see is for qemu to search for and patch
> up sc 1 instructions to something else. Obviously that would also
> need some kernel support, and probably a capability to let it know if
> it's necessary.
Well I'd like to keep Qemu out of the patching business, so the guest kernel=
would have to patch itself. But yes, PHyP guests can't run this target yet :=
). I'll take a stab at that too, but one continent at a time! ;)
Alex
>=20
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: David Gibson @ 2011-08-12 3:35 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-8-git-send-email-agraf@suse.de>
On Tue, Aug 09, 2011 at 06:31:45PM +0200, Alexander Graf wrote:
> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> most prominently the page table invalidation (to sync the shadows).
>
> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> to share the code with HV mode, but it ended up being a lot easier this way
> around, as the two differ too much in those details.
Are these strictly necessary, or just an optimization? Because you're
using the space allocated by qemu for the guest hash table, it seems
to be you could just let h_enter fall through to qemu which will put
the right thing into the guest hash table which you can then walk in
the kernel translation code.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
From: David Gibson @ 2011-08-12 3:33 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-10-git-send-email-agraf@suse.de>
On Tue, Aug 09, 2011 at 06:31:47PM +0200, Alexander Graf wrote:
> PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
> page tables and does other privileged operations that it wouldn't be allowed
> to do in supervisor mode.
>
> This patch adds support for PR KVM to trap these instructions and route them
> through the same PAPR hypercall interface that we already use for HV style
> KVM.
This will work on a powermac or bare metal host. Unfortunately, it's
not enough on a pSeries LPAR host - the sc 1 instruction from the
guest problem state will go direct to the hypervisor, which will
return an error rather than trapping to the guest kernel.
The only way around this I can see is for qemu to search for and patch
up sc 1 instructions to something else. Obviously that would also
need some kernel support, and probably a capability to let it know if
it's necessary.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Question about the drivers movement (IBM_NEW_EMAC)
From: Stephen Rothwell @ 2011-08-12 2:54 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, ppc-dev, linux-kernel, David Miller
In-Reply-To: <20110812120744.1912ca01ab4e76faaa93892c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
[just cc'ing linuxppc-dev mailing list]
On Fri, 12 Aug 2011 12:07:44 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Jeff,
>
> In commit 9aa328359545 ("ehea/ibm*: Move the IBM drivers") from Dave's
> net tree, you not only move the drivers around, but you change
> CONFIG_IBM_NEW_EMAC to CONFIG_IBM_EMAC. Won't that mean that all the
> PowerPC configs that currently set CONFIG_IBM_NEW_EMAC to y will no
> longer build this driver?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH part1 v2 9/9] ps3: Only prealloc the flash bounce buffer for the OtherOS lpar
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
It's only used by the ps3flash driver, which only supports the
OtherOS lpar.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/setup.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 1239059..81ce835 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -233,7 +233,10 @@ static void __init ps3_setup_arch(void)
#endif
prealloc_ps3fb_videomemory();
- prealloc_ps3flash_bounce_buffer();
+
+ /* the ps3flash driver only works for OtherOS */
+ if (ps3_get_ss_laid() == PS3_SS_LAID_OTHEROS)
+ prealloc_ps3flash_bounce_buffer();
ppc_md.power_save = ps3_power_save;
ps3_os_area_init();
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 8/9] ps3flash: Refuse to work in lpars other than OtherOS
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
The driver implements a character and misc device, meant for the
axed OtherOS to exchange various settings with GameOS.
Since Firmware 3.21 there is no support anymore to write these
settings, so test if we're running in OtherOS, and refuse to load
if that is not the case.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/Kconfig | 2 +-
drivers/char/ps3flash.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index 84df5c8..72fdecd 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -121,7 +121,7 @@ config PS3_FLASH
This support is required to access the PS3 FLASH ROM, which
contains the boot loader and some boot options.
- In general, all users will say Y or M.
+ In general, all PS3 OtherOS users will say Y or M.
As this driver needs a fixed buffer of 256 KiB of memory, it can
be disabled on the kernel command line using "ps3flash=off", to
diff --git a/drivers/char/ps3flash.c b/drivers/char/ps3flash.c
index d0c57c2..fc6d867 100644
--- a/drivers/char/ps3flash.c
+++ b/drivers/char/ps3flash.c
@@ -25,6 +25,7 @@
#include <asm/lv1call.h>
#include <asm/ps3stor.h>
+#include <asm/firmware.h>
#define DEVICE_NAME "ps3flash"
@@ -464,6 +465,12 @@ static struct ps3_system_bus_driver ps3flash = {
static int __init ps3flash_init(void)
{
+ if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
+ return -ENODEV;
+
+ if (ps3_get_ss_laid() != PS3_SS_LAID_OTHEROS)
+ return -ENODEV;
+
return ps3_system_bus_driver_register(&ps3flash);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 7/9] ps3: Log the detected lpar on startup
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
Add PS3_SS_LAID_GAMEOS to enum ps3_ss_laid.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/include/asm/ps3.h | 1 +
arch/powerpc/platforms/ps3/setup.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index 9e8c878..136354a 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -40,6 +40,7 @@ void ps3_get_firmware_version(union ps3_firmware_version *v);
int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
enum ps3_ss_laid {
+ PS3_SS_LAID_GAMEOS = 0x1070000002000001UL,
PS3_SS_LAID_OTHEROS = 0x1080000004000001UL,
};
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 9f23a6d..1239059 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -199,6 +199,7 @@ static int ps3_set_dabr(unsigned long dabr)
static void __init ps3_setup_arch(void)
{
+ const char *laid_str;
DBG(" -> %s:%d\n", __func__, __LINE__);
@@ -208,6 +209,18 @@ static void __init ps3_setup_arch(void)
ps3_firmware_version.rev);
ps3_repository_read_ss_laid(&ps3_ss_laid);
+ switch (ps3_ss_laid) {
+ case PS3_SS_LAID_GAMEOS:
+ laid_str = "GameOS";
+ break;
+ case PS3_SS_LAID_OTHEROS:
+ laid_str = "OtherOS";
+ break;
+ default:
+ laid_str = "unknown";
+ break;
+ }
+ printk(KERN_INFO "Running in %s LPAR\n", laid_str);
ps3_spu_set_platform();
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 6/9] ps3: Detect the current lpar
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
Detect it by reading the ss laid repository node, and make it
accessible via ps3_get_ss_laid().
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/include/asm/ps3.h | 6 ++++++
arch/powerpc/platforms/ps3/platform.h | 4 ++++
arch/powerpc/platforms/ps3/repository.c | 19 +++++++++++++++++++
arch/powerpc/platforms/ps3/setup.c | 9 +++++++++
4 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index 7f065e1..9e8c878 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -39,6 +39,12 @@ union ps3_firmware_version {
void ps3_get_firmware_version(union ps3_firmware_version *v);
int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev);
+enum ps3_ss_laid {
+ PS3_SS_LAID_OTHEROS = 0x1080000004000001UL,
+};
+
+enum ps3_ss_laid ps3_get_ss_laid(void);
+
/* 'Other OS' area */
enum ps3_param_av_multi_out {
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/ps3/platform.h
index d9b4ec0..b912d15 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -235,4 +235,8 @@ int ps3_repository_read_spu_resource_id(unsigned int res_index,
int ps3_repository_read_vuart_av_port(unsigned int *port);
int ps3_repository_read_vuart_sysmgr_port(unsigned int *port);
+/* repository ss info */
+
+int ps3_repository_read_ss_laid(enum ps3_ss_laid *laid);
+
#endif
diff --git a/arch/powerpc/platforms/ps3/repository.c b/arch/powerpc/platforms/ps3/repository.c
index 9908d61..06f8801 100644
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -1038,6 +1038,25 @@ int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
lpar, rights);
}
+/**
+ * ps3_repository_read_ss_laid - Read the lpar auth id
+ */
+
+int ps3_repository_read_ss_laid(enum ps3_ss_laid *laid)
+{
+ int result;
+ u64 id, v1;
+
+ lv1_get_logical_partition_id(&id);
+ result = read_node(PS3_LPAR_ID_PME,
+ make_first_field("ss", 0),
+ make_field("laid", 0),
+ id, 0,
+ &v1, NULL);
+ *laid = v1;
+ return result;
+}
+
#if defined(DEBUG)
int ps3_repository_dump_resource_info(const struct ps3_repository_device *repo)
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index 149bea2..9f23a6d 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -47,6 +47,7 @@ DEFINE_MUTEX(ps3_gpu_mutex);
EXPORT_SYMBOL_GPL(ps3_gpu_mutex);
static union ps3_firmware_version ps3_firmware_version;
+static enum ps3_ss_laid ps3_ss_laid;
void ps3_get_firmware_version(union ps3_firmware_version *v)
{
@@ -68,6 +69,12 @@ int ps3_compare_firmware_version(u16 major, u16 minor, u16 rev)
}
EXPORT_SYMBOL_GPL(ps3_compare_firmware_version);
+enum ps3_ss_laid ps3_get_ss_laid(void)
+{
+ return ps3_ss_laid;
+}
+EXPORT_SYMBOL_GPL(ps3_get_ss_laid);
+
static void ps3_power_save(void)
{
/*
@@ -200,6 +207,8 @@ static void __init ps3_setup_arch(void)
ps3_firmware_version.major, ps3_firmware_version.minor,
ps3_firmware_version.rev);
+ ps3_repository_read_ss_laid(&ps3_ss_laid);
+
ps3_spu_set_platform();
#ifdef CONFIG_SMP
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 5/9] ps3: MEMORY_HOTPLUG is not a requirement anymore
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index 476d9d9..84df5c8 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -7,7 +7,6 @@ config PPC_PS3
select USB_OHCI_BIG_ENDIAN_MMIO
select USB_ARCH_HAS_EHCI
select USB_EHCI_BIG_ENDIAN_MMIO
- select MEMORY_HOTPLUG
select PPC_PCI_CHOICE
help
This option enables support for the Sony PS3 game console
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 4/9] Add region 1 memory early
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
From: Hector Martin <hector@marcansoft.com>
Real mode memory can be limited and runs out quickly as memory is
allocated during kernel startup.
Having region1 available sooner fixes this.
Signed-off-by: Hector Martin <hector@marcansoft.com>
[a.heider: Various cleanups to make checkpatch.pl happy]
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/mm.c | 75 +++++++--------------------------------
1 files changed, 13 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 983b719..68b3879 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -20,7 +20,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
-#include <linux/memory_hotplug.h>
#include <linux/memblock.h>
#include <linux/slab.h>
@@ -94,10 +93,8 @@ struct mem_region {
* @vas_id - HV virtual address space id
* @htab_size: htab size in bytes
*
- * The HV virtual address space (vas) allows for hotplug memory regions.
- * Memory regions can be created and destroyed in the vas at runtime.
* @rm: real mode (bootmem) region
- * @r1: hotplug memory region(s)
+ * @r1: high memory region
*
* ps3 addresses
* virt_addr: a cpu 'translated' effective address
@@ -223,10 +220,6 @@ void ps3_mm_vas_destroy(void)
}
}
-/*============================================================================*/
-/* memory hotplug routines */
-/*============================================================================*/
-
/**
* ps3_mm_region_create - create a memory region in the vas
* @r: pointer to a struct mem_region to accept initialized values
@@ -319,57 +312,6 @@ zero_region:
return result;
}
-/**
- * ps3_mm_add_memory - hot add memory
- */
-
-static int __init ps3_mm_add_memory(void)
-{
- int result;
- unsigned long start_addr;
- unsigned long start_pfn;
- unsigned long nr_pages;
-
- if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
- return -ENODEV;
-
- BUG_ON(!mem_init_done);
-
- if (!map.r1.size) {
- DBG("%s:%d: no region 1, not adding memory\n",
- __func__, __LINE__);
- return 0;
- }
-
- start_addr = map.rm.size;
- start_pfn = start_addr >> PAGE_SHIFT;
- nr_pages = (map.r1.size + PAGE_SIZE - 1) >> PAGE_SHIFT;
-
- DBG("%s:%d: start_addr %lxh, start_pfn %lxh, nr_pages %lxh\n",
- __func__, __LINE__, start_addr, start_pfn, nr_pages);
-
- result = add_memory(0, start_addr, map.r1.size);
-
- if (result) {
- pr_err("%s:%d: add_memory failed: (%d)\n",
- __func__, __LINE__, result);
- return result;
- }
-
- memblock_add(start_addr, map.r1.size);
- memblock_analyze();
-
- result = online_pages(start_pfn, nr_pages);
-
- if (result)
- pr_err("%s:%d: online_pages failed: (%d)\n",
- __func__, __LINE__, result);
-
- return result;
-}
-
-device_initcall(ps3_mm_add_memory);
-
/*============================================================================*/
/* dma routines */
/*============================================================================*/
@@ -1256,14 +1198,23 @@ void __init ps3_mm_init(void)
BUG_ON(!map.rm.size);
/* check if we got the highmem region from an earlier boot step */
- if (ps3_mm_get_repository_highmem(&map.r1)) {
- /* arrange to do this in ps3_mm_add_memory */
+ if (ps3_mm_get_repository_highmem(&map.r1))
ps3_mm_region_create(&map.r1, map.total - map.rm.size);
- }
/* correct map.total for the real total amount of memory we use */
map.total = map.rm.size + map.r1.size;
+ if (!map.r1.size) {
+ DBG("%s:%d: no region 1, not adding memory\n",
+ __func__, __LINE__);
+ } else {
+ DBG("%s:%d: adding memory: start %llxh, size %llxh\n",
+ __func__, __LINE__, map.rm.size, map.r1.size);
+
+ memblock_add(map.rm.size, map.r1.size);
+ memblock_analyze();
+ }
+
DBG(" <- %s:%d\n", __func__, __LINE__);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 3/9] ps3: Get lv1 high memory region from the repository
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
This lets the bootloader preallocate the high lv1 region and pass its
location to the kernel through the repository. Thus, it can be used to
hold the initrd. If the region info doesn't exist, the kernel retains
the old behavior and attempts to allocate the region itself.
Based on the patch
"[PS3] Get lv1 high memory region from devtree"
from Hector Martin <hector@marcansoft.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/mm.c | 46 ++++++++++++++++++++++++++++++++++++--
1 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index c204588..983b719 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -78,12 +78,14 @@ enum {
* @base: base address
* @size: size in bytes
* @offset: difference between base and rm.size
+ * @destroy: flag if region should be destroyed upon shutdown
*/
struct mem_region {
u64 base;
u64 size;
unsigned long offset;
+ int destroy;
};
/**
@@ -261,6 +263,7 @@ static int ps3_mm_region_create(struct mem_region *r, unsigned long size)
goto zero_region;
}
+ r->destroy = 1;
r->offset = r->base - map.rm.size;
return result;
@@ -279,6 +282,12 @@ static void ps3_mm_region_destroy(struct mem_region *r)
int result;
DBG("%s:%d: r->base = %llxh\n", __func__, __LINE__, r->base);
+
+ if (!r->destroy) {
+ DBG("%s:%d: not destroying region\n", __func__, __LINE__);
+ return;
+ }
+
if (r->base) {
result = lv1_release_memory(r->base);
BUG_ON(result);
@@ -287,6 +296,29 @@ static void ps3_mm_region_destroy(struct mem_region *r)
}
}
+static int ps3_mm_get_repository_highmem(struct mem_region *r)
+{
+ int result = ps3_repository_read_highmem_info(&r->base, &r->size);
+
+ if (result)
+ goto zero_region;
+
+ if (!r->base || !r->size) {
+ result = -1;
+ goto zero_region;
+ }
+
+ r->offset = r->base - map.rm.size;
+ DBG("%s:%d got high region from repository: %llxh %llxh\n",
+ __func__, __LINE__, r->base, r->size);
+ return 0;
+
+zero_region:
+ DBG("%s:%d no high region in repository...\n", __func__, __LINE__);
+ r->size = r->base = r->offset = 0;
+ return result;
+}
+
/**
* ps3_mm_add_memory - hot add memory
*/
@@ -303,6 +335,12 @@ static int __init ps3_mm_add_memory(void)
BUG_ON(!mem_init_done);
+ if (!map.r1.size) {
+ DBG("%s:%d: no region 1, not adding memory\n",
+ __func__, __LINE__);
+ return 0;
+ }
+
start_addr = map.rm.size;
start_pfn = start_addr >> PAGE_SHIFT;
nr_pages = (map.r1.size + PAGE_SIZE - 1) >> PAGE_SHIFT;
@@ -1217,9 +1255,11 @@ void __init ps3_mm_init(void)
BUG_ON(map.rm.base);
BUG_ON(!map.rm.size);
-
- /* arrange to do this in ps3_mm_add_memory */
- ps3_mm_region_create(&map.r1, map.total - map.rm.size);
+ /* check if we got the highmem region from an earlier boot step */
+ if (ps3_mm_get_repository_highmem(&map.r1)) {
+ /* arrange to do this in ps3_mm_add_memory */
+ ps3_mm_region_create(&map.r1, map.total - map.rm.size);
+ }
/* correct map.total for the real total amount of memory we use */
map.total = map.rm.size + map.r1.size;
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 2/9] ps3: Add helper functions to read highmem info from the repository
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
An earlier step in the boot chain can preallocate the highmem region.
A boot loader doing so will place the region infos in the repository.
Provide helper functions to read the required nodes.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/platforms/ps3/platform.h | 3 ++
arch/powerpc/platforms/ps3/repository.c | 36 +++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/platform.h b/arch/powerpc/platforms/ps3/platform.h
index 9a196a8..d9b4ec0 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -187,6 +187,9 @@ int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size);
int ps3_repository_read_region_total(u64 *region_total);
int ps3_repository_read_mm_info(u64 *rm_base, u64 *rm_size,
u64 *region_total);
+int ps3_repository_read_highmem_base(u64 *highmem_base);
+int ps3_repository_read_highmem_size(u64 *highmem_size);
+int ps3_repository_read_highmem_info(u64 *highmem_base, u64 *highmem_size);
/* repository pme info */
diff --git a/arch/powerpc/platforms/ps3/repository.c b/arch/powerpc/platforms/ps3/repository.c
index 5e304c2..9908d61 100644
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -778,6 +778,42 @@ int ps3_repository_read_mm_info(u64 *rm_base, u64 *rm_size, u64 *region_total)
: ps3_repository_read_region_total(region_total);
}
+int ps3_repository_read_highmem_base(u64 *highmem_base)
+{
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("highmem", 0),
+ make_field("base", 0),
+ 0,
+ highmem_base, NULL);
+}
+
+int ps3_repository_read_highmem_size(u64 *highmem_size)
+{
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("highmem", 0),
+ make_field("size", 0),
+ 0,
+ highmem_size, NULL);
+}
+
+/**
+ * ps3_repository_read_highmem_info - Read high memory info
+ * @highmem_base: High memory base address.
+ * @highmem_size: High mode memory size.
+ */
+
+int ps3_repository_read_highmem_info(u64 *highmem_base, u64 *highmem_size)
+{
+ int result;
+
+ *highmem_base = 0;
+ result = ps3_repository_read_highmem_base(highmem_base);
+ return result ? result
+ : ps3_repository_read_highmem_size(highmem_size);
+}
+
/**
* ps3_repository_read_num_spu_reserved - Number of physical spus reserved.
* @num_spu: Number of physical spus.
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 1/9] Add udbg driver using the PS3 gelic Ethernet device
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
From: Hector Martin <hector@marcansoft.com>
Signed-off-by: Hector Martin <hector@marcansoft.com>
[a.heider: Various cleanups to make checkpatch.pl happy]
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
arch/powerpc/Kconfig.debug | 8 +
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
arch/powerpc/platforms/ps3/Kconfig | 12 ++
arch/powerpc/platforms/ps3/Makefile | 1 +
arch/powerpc/platforms/ps3/gelic_udbg.c | 273 +++++++++++++++++++++++++++++++
drivers/net/ps3_gelic_net.c | 3 +
drivers/net/ps3_gelic_net.h | 6 +
8 files changed, 306 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 067cb84..ab2335f 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -258,6 +258,14 @@ config PPC_EARLY_DEBUG_WSP
depends on PPC_WSP
select PPC_UDBG_16550
+config PPC_EARLY_DEBUG_PS3GELIC
+ bool "Early debugging through the PS3 Ethernet port"
+ depends on PPC_PS3
+ select PS3GELIC_UDBG
+ help
+ Select this to enable early debugging for the PlayStation3 via
+ UDP broadcasts sent out through the Ethernet port.
+
endchoice
config PPC_EARLY_DEBUG_HVSI_VTERMNO
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 93e05d1..7cf796f 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -54,6 +54,7 @@ extern void __init udbg_init_40x_realmode(void);
extern void __init udbg_init_cpm(void);
extern void __init udbg_init_usbgecko(void);
extern void __init udbg_init_wsp(void);
+extern void __init udbg_init_ps3gelic(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index faa82c1..5b3e98e 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -67,6 +67,8 @@ void __init udbg_early_init(void)
udbg_init_usbgecko();
#elif defined(CONFIG_PPC_EARLY_DEBUG_WSP)
udbg_init_wsp();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_PS3GELIC)
+ udbg_init_ps3gelic();
#endif
#ifdef CONFIG_PPC_EARLY_DEBUG
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index dfe316b..476d9d9 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -148,4 +148,16 @@ config PS3_LPM
profiling support of the Cell processor with programs like
oprofile and perfmon2, then say Y or M, otherwise say N.
+config PS3GELIC_UDBG
+ bool "PS3 udbg output via UDP broadcasts on Ethernet"
+ depends on PPC_PS3
+ help
+ Enables udbg early debugging output by sending broadcast UDP
+ via the Ethernet port (UDP port number 18194).
+
+ This driver uses a trivial implementation and is independent
+ from the main network driver.
+
+ If in doubt, say N here.
+
endmenu
diff --git a/arch/powerpc/platforms/ps3/Makefile b/arch/powerpc/platforms/ps3/Makefile
index ac1bdf8..02b9e63 100644
--- a/arch/powerpc/platforms/ps3/Makefile
+++ b/arch/powerpc/platforms/ps3/Makefile
@@ -2,6 +2,7 @@ obj-y += setup.o mm.o time.o hvcall.o htab.o repository.o
obj-y += interrupt.o exports.o os-area.o
obj-y += system-bus.o
+obj-$(CONFIG_PS3GELIC_UDBG) += gelic_udbg.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPU_BASE) += spu.o
obj-y += device-init.o
diff --git a/arch/powerpc/platforms/ps3/gelic_udbg.c b/arch/powerpc/platforms/ps3/gelic_udbg.c
new file mode 100644
index 0000000..20b46a1
--- /dev/null
+++ b/arch/powerpc/platforms/ps3/gelic_udbg.c
@@ -0,0 +1,273 @@
+/*
+ * udbg debug output routine via GELIC UDP broadcasts
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2006, 2007 Sony Corporation
+ * Copyright (C) 2010 Hector Martin <hector@marcansoft.com>
+ * Copyright (C) 2011 Andre Heider <a.heider@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ */
+
+#include <asm/io.h>
+#include <asm/udbg.h>
+#include <asm/lv1call.h>
+
+#define GELIC_BUS_ID 1
+#define GELIC_DEVICE_ID 0
+#define GELIC_DEBUG_PORT 18194
+#define GELIC_MAX_MESSAGE_SIZE 1000
+
+#define GELIC_LV1_GET_MAC_ADDRESS 1
+#define GELIC_LV1_GET_VLAN_ID 4
+#define GELIC_LV1_VLAN_TX_ETHERNET_0 2
+
+#define GELIC_DESCR_DMA_STAT_MASK 0xf0000000
+#define GELIC_DESCR_DMA_CARDOWNED 0xa0000000
+
+#define GELIC_DESCR_TX_DMA_IKE 0x00080000
+#define GELIC_DESCR_TX_DMA_NO_CHKSUM 0x00000000
+#define GELIC_DESCR_TX_DMA_FRAME_TAIL 0x00040000
+
+#define GELIC_DESCR_DMA_CMD_NO_CHKSUM (GELIC_DESCR_DMA_CARDOWNED | \
+ GELIC_DESCR_TX_DMA_IKE | \
+ GELIC_DESCR_TX_DMA_NO_CHKSUM)
+
+static u64 bus_addr;
+
+struct gelic_descr {
+ /* as defined by the hardware */
+ __be32 buf_addr;
+ __be32 buf_size;
+ __be32 next_descr_addr;
+ __be32 dmac_cmd_status;
+ __be32 result_size;
+ __be32 valid_size; /* all zeroes for tx */
+ __be32 data_status;
+ __be32 data_error; /* all zeroes for tx */
+} __attribute__((aligned(32)));
+
+struct debug_block {
+ struct gelic_descr descr;
+ u8 pkt[1520];
+} __packed;
+
+struct ethhdr {
+ u8 dest[6];
+ u8 src[6];
+ u16 type;
+} __packed;
+
+struct vlantag {
+ u16 vlan;
+ u16 subtype;
+} __packed;
+
+struct iphdr {
+ u8 ver_len;
+ u8 dscp_ecn;
+ u16 total_length;
+ u16 ident;
+ u16 frag_off_flags;
+ u8 ttl;
+ u8 proto;
+ u16 checksum;
+ u32 src;
+ u32 dest;
+} __packed;
+
+struct udphdr {
+ u16 src;
+ u16 dest;
+ u16 len;
+ u16 checksum;
+} __packed;
+
+static __iomem struct ethhdr *h_eth;
+static __iomem struct vlantag *h_vlan;
+static __iomem struct iphdr *h_ip;
+static __iomem struct udphdr *h_udp;
+
+static __iomem char *pmsg;
+static __iomem char *pmsgc;
+
+static __iomem struct debug_block dbg __attribute__((aligned(32)));
+
+static int header_size;
+
+static void map_dma_mem(int bus_id, int dev_id, void *start, size_t len,
+ u64 *real_bus_addr)
+{
+ s64 result;
+ u64 real_addr = ((u64)start) & 0x0fffffffffffffffUL;
+ u64 real_end = real_addr + len;
+ u64 map_start = real_addr & ~0xfff;
+ u64 map_end = (real_end + 0xfff) & ~0xfff;
+ u64 bus_addr = 0;
+
+ u64 flags = 0xf800000000000000UL;
+
+ result = lv1_allocate_device_dma_region(bus_id, dev_id,
+ map_end - map_start, 12, 0,
+ &bus_addr);
+ if (result)
+ lv1_panic(0);
+
+ result = lv1_map_device_dma_region(bus_id, dev_id, map_start,
+ bus_addr, map_end - map_start,
+ flags);
+ if (result)
+ lv1_panic(0);
+
+ *real_bus_addr = bus_addr + real_addr - map_start;
+}
+
+static int unmap_dma_mem(int bus_id, int dev_id, u64 bus_addr, size_t len)
+{
+ s64 result;
+ u64 real_bus_addr;
+
+ real_bus_addr = bus_addr & ~0xfff;
+ len += bus_addr - real_bus_addr;
+ len = (len + 0xfff) & ~0xfff;
+
+ result = lv1_unmap_device_dma_region(bus_id, dev_id, real_bus_addr,
+ len);
+ if (result)
+ return result;
+
+ return lv1_free_device_dma_region(bus_id, dev_id, real_bus_addr);
+}
+
+static void gelic_debug_init(void)
+{
+ s64 result;
+ u64 v2;
+ u64 mac;
+ u64 vlan_id;
+
+ result = lv1_open_device(GELIC_BUS_ID, GELIC_DEVICE_ID, 0);
+ if (result)
+ lv1_panic(0);
+
+ map_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID, &dbg, sizeof(dbg),
+ &bus_addr);
+
+ memset(&dbg, 0, sizeof(dbg));
+
+ dbg.descr.buf_addr = bus_addr + offsetof(struct debug_block, pkt);
+
+ wmb();
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_MAC_ADDRESS, 0, 0, 0,
+ &mac, &v2);
+ if (result)
+ lv1_panic(0);
+
+ mac <<= 16;
+
+ h_eth = (struct ethhdr *)dbg.pkt;
+
+ memset(&h_eth->dest, 0xff, 6);
+ memcpy(&h_eth->src, &mac, 6);
+
+ header_size = sizeof(struct ethhdr);
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_VLAN_ID,
+ GELIC_LV1_VLAN_TX_ETHERNET_0, 0, 0,
+ &vlan_id, &v2);
+ if (!result) {
+ h_eth->type = 0x8100;
+
+ header_size += sizeof(struct vlantag);
+ h_vlan = (struct vlantag *)(h_eth + 1);
+ h_vlan->vlan = vlan_id;
+ h_vlan->subtype = 0x0800;
+ h_ip = (struct iphdr *)(h_vlan + 1);
+ } else {
+ h_eth->type = 0x0800;
+ h_ip = (struct iphdr *)(h_eth + 1);
+ }
+
+ header_size += sizeof(struct iphdr);
+ h_ip->ver_len = 0x45;
+ h_ip->ttl = 10;
+ h_ip->proto = 0x11;
+ h_ip->src = 0x00000000;
+ h_ip->dest = 0xffffffff;
+
+ header_size += sizeof(struct udphdr);
+ h_udp = (struct udphdr *)(h_ip + 1);
+ h_udp->src = GELIC_DEBUG_PORT;
+ h_udp->dest = GELIC_DEBUG_PORT;
+
+ pmsgc = pmsg = (char *)(h_udp + 1);
+}
+
+static void gelic_debug_shutdown(void)
+{
+ if (bus_addr)
+ unmap_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ bus_addr, sizeof(dbg));
+ lv1_close_device(GELIC_BUS_ID, GELIC_DEVICE_ID);
+}
+
+static void gelic_sendbuf(int msgsize)
+{
+ u16 *p;
+ u32 sum;
+ int i;
+
+ dbg.descr.buf_size = header_size + msgsize;
+ h_ip->total_length = msgsize + sizeof(struct udphdr) +
+ sizeof(struct iphdr);
+ h_udp->len = msgsize + sizeof(struct udphdr);
+
+ h_ip->checksum = 0;
+ sum = 0;
+ p = (u16 *)h_ip;
+ for (i = 0; i < 5; i++)
+ sum += *p++;
+ h_ip->checksum = ~(sum + (sum >> 16));
+
+ dbg.descr.dmac_cmd_status = GELIC_DESCR_DMA_CMD_NO_CHKSUM |
+ GELIC_DESCR_TX_DMA_FRAME_TAIL;
+ dbg.descr.result_size = 0;
+ dbg.descr.data_status = 0;
+
+ wmb();
+
+ lv1_net_start_tx_dma(GELIC_BUS_ID, GELIC_DEVICE_ID, bus_addr, 0);
+
+ while ((dbg.descr.dmac_cmd_status & GELIC_DESCR_DMA_STAT_MASK) ==
+ GELIC_DESCR_DMA_CARDOWNED)
+ cpu_relax();
+}
+
+static void ps3gelic_udbg_putc(char ch)
+{
+ *pmsgc++ = ch;
+ if (ch == '\n' || (pmsgc-pmsg) >= GELIC_MAX_MESSAGE_SIZE) {
+ gelic_sendbuf(pmsgc-pmsg);
+ pmsgc = pmsg;
+ }
+}
+
+void __init udbg_init_ps3gelic(void)
+{
+ gelic_debug_init();
+ udbg_putc = ps3gelic_udbg_putc;
+}
+
+void udbg_shutdown_ps3gelic(void)
+{
+ udbg_putc = NULL;
+ gelic_debug_shutdown();
+}
+EXPORT_SYMBOL(udbg_shutdown_ps3gelic);
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index d82a82d..e743c94 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -1674,6 +1674,9 @@ static int __devinit ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
int result;
pr_debug("%s: called\n", __func__);
+
+ udbg_shutdown_ps3gelic();
+
result = ps3_open_hv_device(dev);
if (result) {
diff --git a/drivers/net/ps3_gelic_net.h b/drivers/net/ps3_gelic_net.h
index d3fadfb..a93df6a 100644
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -359,6 +359,12 @@ static inline void *port_priv(struct gelic_port *port)
return port->priv;
}
+#ifdef CONFIG_PPC_EARLY_DEBUG_PS3GELIC
+extern void udbg_shutdown_ps3gelic(void);
+#else
+static inline void udbg_shutdown_ps3gelic(void) {}
+#endif
+
extern int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask);
/* shared netdev ops */
extern void gelic_card_up(struct gelic_card *card);
--
1.7.5.4
^ permalink raw reply related
* [PATCH part1 v2 0/9] ps3: General improvements and preparation for support more than the OtherOS lpar
From: Andre Heider @ 2011-08-11 19:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1312228986-32307-1-git-send-email-a.heider@gmail.com>
This is the first part of my previous series including the discussed fixups.
I dropped the old #2 ([PS3] Get lv1 high memory region from devtree)
and replaced it with 2 new patches, now #2 and #3. The latter contains
the fixups mentioned on the old #2 thread.
Patches are based on today's Linus' tree.
Andre Heider (7):
ps3: Add helper functions to read highmem info from the repository
ps3: Get lv1 high memory region from the repository
ps3: MEMORY_HOTPLUG is not a requirement anymore
ps3: Detect the current lpar
ps3: Log the detected lpar on startup
ps3flash: Refuse to work in lpars other than OtherOS
ps3: Only prealloc the flash bounce buffer for the OtherOS lpar
Hector Martin (2):
Add udbg driver using the PS3 gelic Ethernet device
Add region 1 memory early
arch/powerpc/Kconfig.debug | 8 +
arch/powerpc/include/asm/ps3.h | 7 +
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
arch/powerpc/platforms/ps3/Kconfig | 15 ++-
arch/powerpc/platforms/ps3/Makefile | 1 +
arch/powerpc/platforms/ps3/gelic_udbg.c | 273 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/ps3/mm.c | 85 +++++------
arch/powerpc/platforms/ps3/platform.h | 7 +
arch/powerpc/platforms/ps3/repository.c | 55 ++++++
arch/powerpc/platforms/ps3/setup.c | 27 +++-
drivers/char/ps3flash.c | 7 +
drivers/net/ps3_gelic_net.c | 3 +
drivers/net/ps3_gelic_net.h | 6 +
14 files changed, 447 insertions(+), 50 deletions(-)
create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c
--
1.7.5.4
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-11 18:12 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, Scott Wood,
PPC list
In-Reply-To: <9C81E6C0-D278-40BF-8F32-445F870F845A@kernel.crashing.org>
On Thu, Aug 11, 2011 at 12:41:34PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2011, at 11:07 AM, Robin Holt wrote:
>
> > Allow the p1010 processor to select the flexcan network driver.
> >
> > 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/boot/dts/p1010rdb.dts | 8 ++++++++
> > arch/powerpc/platforms/85xx/Kconfig | 2 ++
> > 2 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> > index d6c669c..df89b60 100644
> > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > @@ -171,6 +171,14 @@
> > };
> > };
> >
> > + can@1c000 {
> > + clock-frequency = <0x0bebc1fc>;
> > + };
> > +
> > + can1: can@1d000 {
> > + clock-frequency = <0x0bebc1fc>;
> > + };
> > +
>
> set them to 0, as we expect u-boot to fill them in.
Done.
>
> > usb@22000 {
> > phy_type = "utmi";
> > };
> > 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
>
> Can you move this to arch/powerpc/Kconfig & FSL_SOC instead.
I am not sure. FSL_SOC seems to come with any of the freescale system
on a chip. I would not be that worried, about the flexcan build as
I think that is sufficiently agostic where we will not see problems,
but now we could end up with build failures on any of the other configs
which select CAN_FLEXCAN. I would normally want to do all those builds,
but there is no way I would know how to do that with my limited knowledge
of powerpc and freescale.
If you are comfortable with that, I will happily make the change.
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Kumar Gala @ 2011-08-11 17:41 UTC (permalink / raw)
To: Robin Holt; +Cc: socketcan-core, netdev, U Bhaskar-B22300, Scott Wood, PPC list
In-Reply-To: <1313078831-2511-7-git-send-email-holt@sgi.com>
On Aug 11, 2011, at 11:07 AM, Robin Holt wrote:
> Allow the p1010 processor to select the flexcan network driver.
>=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/boot/dts/p1010rdb.dts | 8 ++++++++
> arch/powerpc/platforms/85xx/Kconfig | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts =
b/arch/powerpc/boot/dts/p1010rdb.dts
> index d6c669c..df89b60 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -171,6 +171,14 @@
> };
> };
>=20
> + can@1c000 {
> + clock-frequency =3D <0x0bebc1fc>;
> + };
> +
> + can1: can@1d000 {
> + clock-frequency =3D <0x0bebc1fc>;
> + };
> +
set them to 0, as we expect u-boot to fill them in.
> usb@22000 {
> phy_type =3D "utmi";
> };
> 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
Can you move this to arch/powerpc/Kconfig & FSL_SOC instead.
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) =
board
>=20
> --=20
> 1.7.2.1
^ permalink raw reply
* Re: [PATCH v11 5/6] flexcan: Prefer device tree clock frequency if available.
From: Kumar Gala @ 2011-08-11 17:40 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core, netdev, devicetree-discuss, U Bhaskar-B22300,
Robin Holt, Scott Wood, PPC list
In-Reply-To: <4E4400CC.3020704@pengutronix.de>
On Aug 11, 2011, at 11:18 AM, Marc Kleine-Budde wrote:
> On 08/11/2011 06:07 PM, Robin Holt wrote:
>> 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.
>=20
> nitpicking follows inline:
>=20
>> Signed-off-by: Robin Holt <holt@sgi.com>
>> To: Kumar Gala <galak@kernel.crashing.org>
>> To: Wolfgang Grandegger <wg@grandegger.com>,
>> To: Marc Kleine-Budde <mkl@pengutronix.de>,
>> To: U Bhaskar-B22300 <B22300@freescale.com>
>> To: Scott Wood <scottwood@freescale.com>
>> To: Grant Likely <grant.likely@secretlab.ca>
>> Cc: socketcan-core@lists.berlios.de,
>> Cc: netdev@vger.kernel.org,
>> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
>> Cc: devicetree-discuss@lists.ozlabs.org
>> ---
>> .../devicetree/bindings/net/can/fsl-flexcan.txt | 2 +
>> drivers/net/can/flexcan.c | 33 =
+++++++++++++++-----
>> 2 files changed, 27 insertions(+), 8 deletions(-)
>>=20
>> diff --git =
a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt =
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> index c78dcbb..a4382c7 100644
>> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> @@ -11,6 +11,7 @@ Required properties:
>>=20
>> - reg : Offset and length of the register set for this device
>> - interrupts : Interrupt tuple for this device
>> +- clock-frequency : The oscillator frequency driving the flexcan =
device
>>=20
>> Example:
>>=20
>> @@ -19,4 +20,5 @@ Example:
>> reg =3D <0x1c000 0x1000>;
>> interrupts =3D <48 0x2>;
>> interrupt-parent =3D <&mpic>;
>> + clock-frequency =3D <0x0bebc1fc>;
>=20
> Does the device tree support dec coded integers? IMHO a frequency is
> best expressed in decimal.
Yes it does, and agree that in the example a dec # might be better
- 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