* [PATCH] ipv4: some rt_iif -> rt_route_iif conversions
From: Julian Anastasov @ 2011-08-09 14:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev
As rt_iif represents input device even for packets
coming from loopback with output route, it is not an unique
key specific to input routes. Now rt_route_iif has such role,
it was fl.iif in 2.6.38, so better to change the checks at
some places to save CPU cycles and to restore 2.6.38 semantics.
compare_keys:
- input routes: only rt_route_iif matters, rt_iif is same
- output routes: only rt_oif matters, rt_iif is not
used for matching in __ip_route_output_key
- now we are back to 2.6.38 state
ip_route_input_common:
- matching rt_route_iif implies input route
- compared to 2.6.38 we eliminated one rth->fl.oif check
because it was not needed even for 2.6.38
compare_hash_inputs:
Only the change here is not an optimization, it has
effect only for output routes. I assume I'm restoring
the original intention to ignore oif, it was using fl.iif
- now we are back to 2.6.38 state
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp linux/net/ipv4/route.c linux/net/ipv4/route.c
--- linux/net/ipv4/route.c 2011-08-09 12:40:43.000000000 +0300
+++ linux/net/ipv4/route.c 2011-08-09 12:46:16.880358197 +0300
@@ -716,7 +716,7 @@ static inline bool compare_hash_inputs(c
{
return ((((__force u32)rt1->rt_key_dst ^ (__force u32)rt2->rt_key_dst) |
((__force u32)rt1->rt_key_src ^ (__force u32)rt2->rt_key_src) |
- (rt1->rt_iif ^ rt2->rt_iif)) == 0);
+ (rt1->rt_route_iif ^ rt2->rt_route_iif)) == 0);
}
static inline int compare_keys(struct rtable *rt1, struct rtable *rt2)
@@ -726,8 +726,7 @@ static inline int compare_keys(struct rt
(rt1->rt_mark ^ rt2->rt_mark) |
(rt1->rt_key_tos ^ rt2->rt_key_tos) |
(rt1->rt_route_iif ^ rt2->rt_route_iif) |
- (rt1->rt_oif ^ rt2->rt_oif) |
- (rt1->rt_iif ^ rt2->rt_iif)) == 0;
+ (rt1->rt_oif ^ rt2->rt_oif)) == 0;
}
static inline int compare_netns(struct rtable *rt1, struct rtable *rt2)
@@ -2281,9 +2280,8 @@ int ip_route_input_common(struct sk_buff
rth = rcu_dereference(rth->dst.rt_next)) {
if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
- (rth->rt_iif ^ iif) |
+ (rth->rt_route_iif ^ iif) |
(rth->rt_key_tos ^ tos)) == 0 &&
- rt_is_input_route(rth) &&
rth->rt_mark == skb->mark &&
net_eq(dev_net(rth->dst.dev), net) &&
!rt_is_expired(rth)) {
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-09 14:03 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: Robin Holt, socketcan-core@lists.berlios.de,
netdev@vger.kernel.org, Devicetree-discuss@lists.ozlabs.org,
Marc Kleine-Budde
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1C4746@039-SN1MPN1-002.039d.mgd.msft.net>
On 08/09/2011 03:44 PM, U Bhaskar-B22300 wrote:
>
>
>> -----Original Message-----
>> From: Robin Holt [mailto:holt@sgi.com]
>> Sent: Tuesday, August 09, 2011 7:06 PM
>> To: Wolfgang Grandegger
>> Cc: Robin Holt; U Bhaskar-B22300; socketcan-core@lists.berlios.de;
>> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org; Marc Kleine-
>> Budde
>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>
>> On Tue, Aug 09, 2011 at 03:03:50PM +0200, Wolfgang Grandegger wrote:
>>> On 08/09/2011 02:49 PM, Robin Holt wrote:
>>>> On Tue, Aug 09, 2011 at 12:41:39PM +0000, U Bhaskar-B22300 wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
>>>>>> Sent: Tuesday, August 09, 2011 4:19 PM
>>>>>> To: U Bhaskar-B22300
>>>>>> Cc: Marc Kleine-Budde; socketcan-core@lists.berlios.de;
>>>>>> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org
>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>>>>>
>>>>>> On 08/09/2011 11:27 AM, U Bhaskar-B22300 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
>>>>>>>> Sent: Tuesday, August 09, 2011 2:03 PM
>>>>>>>> To: U Bhaskar-B22300
>>>>>>>> Cc: Marc Kleine-Budde; socketcan-core@lists.berlios.de;
>>>>>>>> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org
>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
>> source.
>>>>>>>>
>>>>>>>> Hi Bhaskar,
>>>>>>>>
>>>>>>>> On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
>>>>>>>>>> Sent: Tuesday, August 09, 2011 12:23 AM
>>>>>>>>>> To: Wolfgang Grandegger
>>>>>>>>>> Cc: socketcan-core@lists.berlios.de; netdev@vger.kernel.org; U
>>>>>>>>>> Bhaskar- B22300
>>>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
>> source.
>>>>>>>>>>
>>>>>>>>>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>>>>>>>>>> ACK - The device tree bindings as in mainline's
>>>>>>>>>>>> Documentation is a
>>>>>>>>>> mess.
>>>>>>>>>>>> If the powerpc guys are happy with a clock interfaces based
>>>>>>>>>>>> approach somewhere in arch/ppc, I'm more than happy to
>> remove:
>>>>>>>>>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl
>>>>>>>>>>>> driver)
>>>>>>>>> [Bhaskar]I have pushed the FlexCAN series of patches, It
>>>>>>>>> contains the usage of all the fields posted in the FlexCAN
>>>>>>>>> bindings at
>>>>>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.gi
>>>>>>>>> t;a=b
>>>>>>>>> lo
>>>>>>>>> b;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h
>>>>>>>>> =1a72
>>>>>>>>> 9f
>>>>>>>>> 089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb85
>>>>>>>>> 16972
>>>>>>>>> cb
>>>>>>>>> ebdc8274
>>>>>>>>
>>>>>>>> As Marc already pointed out, Robin already has a much more
>>>>>>>> advanced patch stack in preparation. Especially your patches do
>>>>>>>> not care about the already existing Flexcan core on the
>> Freescale's ARM socks.
>>>>>>> [Bhaskar] No, the patches are taking care of the existing ARM
>>>>>> functionality.
>>>>>>> I have not tested on the ARM based board, but the patches are
>>>>>>> made
>>>>>> in a
>>>>>>> Manner that it should not break the ARM based functionality.
>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - fsl,flexcan-clock-divider \__ replace with code in
>> arch/ppc, or
>>>>>>>>>>>> - clock-frequency / a single clock-frequency
>> attribute
>>>>>>>>>>>
>>>>>>>>>>> In the "net-next-2.6" tree there is also:
>>>>>>>>>>>
>>>>>>>>>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
>>>>>>>> "platform";
>>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
>>>>>>>> "platform";
>>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
>> v1.0";
>>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
>> <2>;
>>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
>> v1.0";
>>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
>> <2>;
>>>>>>>>>>>
>>>>>>>>>>> Especially the fsl,flexcan-clock-divider = <2>; might make
>>>>>>>>>>> people think, that they could set something else.
>>>>>>>>>>
>>>>>>>>> [Bhaskar] As it is mentioned in the Flexcan bindings, the need
>>>>>>>>> of
>>>>>>>> fsl,flexcan-clock-divider = <2>;
>>>>>>>>> But I kept it as "2" because FlexCan clock source is the
>>>>>>>> platform clock and it is CCB/2
>>>>>>>>> If the "2" is misleading, the bindings can be changed or
>>>>>>>>> some
>>>>>>>> text can be written to make the meaning of "2"
>>>>>>>>> Understandable , Please suggest ..
>>>>>>>>
>>>>>>>> The clock source and frequency is fixed. Why do we need an extra
>>>>>>>> properties for that. We have panned to remove these bogus
>>>>>>>> bindings from the Linux kernel, which sneaked in *without* any
>>>>>>>> review on the relevant mailing lists (at least I have not
>>>>>>>> realized any posting). We do not think they are really needed.
>>>>>>>> They just confuse the user. We also prefer to use the
>>>>>>>> compatibility string "fsl,flexcan" instead "fsl,flexcan-v1.0".
>>>>>>>> It's unusual to add a version number, which is for the Flexcan
>>>>>>>> on the PowerPC cores only, I assume, but there will be device
>>>>>>>> tree for ARM soon. A proper compatibility string would be
>> "fsl,p1010-flexcan" if we really need to distinguish.
>>>>>>>>
>>>>>>> [Bhaskar] About clock source.. There can be two sources of clock
>>>>>>> for
>>>>>> the CAN.
>>>>>>> Oscillator or the platform clock, but at present only
>> platform
>>>>>> clock is supported
>>>>>>> in P1010.If we remove the fsl,flexcan-clock-source property,
>> we
>>>>>> will lost the flexibility
>>>>>>> of changing the clock source ..
>>>>>>>
>>>>>>> About clock-frequency... it is also not fixed. It
>>>>>>> depends on
>>>>>> the platform clock which in turns
>>>>>>> Depends on the CCB clock. So it will be better to keep
>>>>>>> clock-
>>>>>> frequency property which is getting fixed via u-boot.
>>>>>>
>>>>>> The frequency is fixed to CCB-frequency / 2. Will that ever
>>>>>> change? What can we expect from future Flexcan hardware? Will it
>>>>>> support further clock sources?
>>>>> [Bhaskar] Yes the frequency will always be CCB-frequency/2.Even if
>> the CCB gets changed that will be taken care by the u-boot fixup code for
>>>>> clock-frequency. clock-frequency is not filled by somebody in the
>> dts file. It will be done by u-boot.
>>>>> For clock source,I can't say right now, that's why I have kept a
>> property for this in the can node. So that in future, we need to fill it
>>>>> appropriately
>>>>
>>>> Speaking of the dts file, I have left the p1010si.dtsi file with the
>>>> fsl,flexcan-v1.0 .compatible definition. The flexcan folks (IIRC
>>>> Wolfgang) objected to that as it does not follow the standard which
>>>> should be just fsl,flexcan.
>>>>
>>>> How would you like to change that? Should I add it as part of this
>>>> patch, add another patch to the series, or let you take care of it?
>>>>
>>>> Also, I assume the uboot project will need to be changed as well to
>>>> reflect the corrected name.
>>>
>>> I think you should provide patches within this series to cleanup the
>>> obsolete stuff, dts and binding doc.
>>
>> It reads to me that the binding doc now reduces just the required
>> properties. Should I remove the file entirely?
> [Bhaskar] I think the binding doc should atleast be present with the required properties to give the clarity
> about the CAN functionality
> can0@1c000 {
> compatible = "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> clock-frequency = <fixed by u-boot>;
> };
Yes, I also find the introduction is quite useful, with some related
correction.
Wolfgang.
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Robin Holt @ 2011-08-09 14:09 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: U Bhaskar-B22300, Robin Holt, socketcan-core@lists.berlios.de,
netdev@vger.kernel.org, Devicetree-discuss@lists.ozlabs.org,
Marc Kleine-Budde
In-Reply-To: <4E413E3A.7050502@grandegger.com>
On Tue, Aug 09, 2011 at 04:03:38PM +0200, Wolfgang Grandegger wrote:
> On 08/09/2011 03:44 PM, U Bhaskar-B22300 wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Holt [mailto:holt@sgi.com]
> >> Sent: Tuesday, August 09, 2011 7:06 PM
> >> To: Wolfgang Grandegger
> >> Cc: Robin Holt; U Bhaskar-B22300; socketcan-core@lists.berlios.de;
> >> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org; Marc Kleine-
> >> Budde
> >> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
> >>
> >> On Tue, Aug 09, 2011 at 03:03:50PM +0200, Wolfgang Grandegger wrote:
> >>> On 08/09/2011 02:49 PM, Robin Holt wrote:
> >>>> On Tue, Aug 09, 2011 at 12:41:39PM +0000, U Bhaskar-B22300 wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> >>>>>> Sent: Tuesday, August 09, 2011 4:19 PM
> >>>>>> To: U Bhaskar-B22300
> >>>>>> Cc: Marc Kleine-Budde; socketcan-core@lists.berlios.de;
> >>>>>> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org
> >>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
> >>>>>>
> >>>>>> On 08/09/2011 11:27 AM, U Bhaskar-B22300 wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> >>>>>>>> Sent: Tuesday, August 09, 2011 2:03 PM
> >>>>>>>> To: U Bhaskar-B22300
> >>>>>>>> Cc: Marc Kleine-Budde; socketcan-core@lists.berlios.de;
> >>>>>>>> netdev@vger.kernel.org; Devicetree-discuss@lists.ozlabs.org
> >>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
> >> source.
> >>>>>>>>
> >>>>>>>> Hi Bhaskar,
> >>>>>>>>
> >>>>>>>> On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> >>>>>>>>>> Sent: Tuesday, August 09, 2011 12:23 AM
> >>>>>>>>>> To: Wolfgang Grandegger
> >>>>>>>>>> Cc: socketcan-core@lists.berlios.de; netdev@vger.kernel.org; U
> >>>>>>>>>> Bhaskar- B22300
> >>>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
> >> source.
> >>>>>>>>>>
> >>>>>>>>>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
> >>>>>>>>>>>> ACK - The device tree bindings as in mainline's
> >>>>>>>>>>>> Documentation is a
> >>>>>>>>>> mess.
> >>>>>>>>>>>> If the powerpc guys are happy with a clock interfaces based
> >>>>>>>>>>>> approach somewhere in arch/ppc, I'm more than happy to
> >> remove:
> >>>>>>>>>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl
> >>>>>>>>>>>> driver)
> >>>>>>>>> [Bhaskar]I have pushed the FlexCAN series of patches, It
> >>>>>>>>> contains the usage of all the fields posted in the FlexCAN
> >>>>>>>>> bindings at
> >>>>>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.gi
> >>>>>>>>> t;a=b
> >>>>>>>>> lo
> >>>>>>>>> b;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h
> >>>>>>>>> =1a72
> >>>>>>>>> 9f
> >>>>>>>>> 089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb85
> >>>>>>>>> 16972
> >>>>>>>>> cb
> >>>>>>>>> ebdc8274
> >>>>>>>>
> >>>>>>>> As Marc already pointed out, Robin already has a much more
> >>>>>>>> advanced patch stack in preparation. Especially your patches do
> >>>>>>>> not care about the already existing Flexcan core on the
> >> Freescale's ARM socks.
> >>>>>>> [Bhaskar] No, the patches are taking care of the existing ARM
> >>>>>> functionality.
> >>>>>>> I have not tested on the ARM based board, but the patches are
> >>>>>>> made
> >>>>>> in a
> >>>>>>> Manner that it should not break the ARM based functionality.
> >>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> - fsl,flexcan-clock-divider \__ replace with code in
> >> arch/ppc, or
> >>>>>>>>>>>> - clock-frequency / a single clock-frequency
> >> attribute
> >>>>>>>>>>>
> >>>>>>>>>>> In the "net-next-2.6" tree there is also:
> >>>>>>>>>>>
> >>>>>>>>>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
> >>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
> >>>>>>>> "platform";
> >>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
> >>>>>>>> "platform";
> >>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
> >> v1.0";
> >>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
> >> <2>;
> >>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
> >> v1.0";
> >>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
> >> <2>;
> >>>>>>>>>>>
> >>>>>>>>>>> Especially the fsl,flexcan-clock-divider = <2>; might make
> >>>>>>>>>>> people think, that they could set something else.
> >>>>>>>>>>
> >>>>>>>>> [Bhaskar] As it is mentioned in the Flexcan bindings, the need
> >>>>>>>>> of
> >>>>>>>> fsl,flexcan-clock-divider = <2>;
> >>>>>>>>> But I kept it as "2" because FlexCan clock source is the
> >>>>>>>> platform clock and it is CCB/2
> >>>>>>>>> If the "2" is misleading, the bindings can be changed or
> >>>>>>>>> some
> >>>>>>>> text can be written to make the meaning of "2"
> >>>>>>>>> Understandable , Please suggest ..
> >>>>>>>>
> >>>>>>>> The clock source and frequency is fixed. Why do we need an extra
> >>>>>>>> properties for that. We have panned to remove these bogus
> >>>>>>>> bindings from the Linux kernel, which sneaked in *without* any
> >>>>>>>> review on the relevant mailing lists (at least I have not
> >>>>>>>> realized any posting). We do not think they are really needed.
> >>>>>>>> They just confuse the user. We also prefer to use the
> >>>>>>>> compatibility string "fsl,flexcan" instead "fsl,flexcan-v1.0".
> >>>>>>>> It's unusual to add a version number, which is for the Flexcan
> >>>>>>>> on the PowerPC cores only, I assume, but there will be device
> >>>>>>>> tree for ARM soon. A proper compatibility string would be
> >> "fsl,p1010-flexcan" if we really need to distinguish.
> >>>>>>>>
> >>>>>>> [Bhaskar] About clock source.. There can be two sources of clock
> >>>>>>> for
> >>>>>> the CAN.
> >>>>>>> Oscillator or the platform clock, but at present only
> >> platform
> >>>>>> clock is supported
> >>>>>>> in P1010.If we remove the fsl,flexcan-clock-source property,
> >> we
> >>>>>> will lost the flexibility
> >>>>>>> of changing the clock source ..
> >>>>>>>
> >>>>>>> About clock-frequency... it is also not fixed. It
> >>>>>>> depends on
> >>>>>> the platform clock which in turns
> >>>>>>> Depends on the CCB clock. So it will be better to keep
> >>>>>>> clock-
> >>>>>> frequency property which is getting fixed via u-boot.
> >>>>>>
> >>>>>> The frequency is fixed to CCB-frequency / 2. Will that ever
> >>>>>> change? What can we expect from future Flexcan hardware? Will it
> >>>>>> support further clock sources?
> >>>>> [Bhaskar] Yes the frequency will always be CCB-frequency/2.Even if
> >> the CCB gets changed that will be taken care by the u-boot fixup code for
> >>>>> clock-frequency. clock-frequency is not filled by somebody in the
> >> dts file. It will be done by u-boot.
> >>>>> For clock source,I can't say right now, that's why I have kept a
> >> property for this in the can node. So that in future, we need to fill it
> >>>>> appropriately
> >>>>
> >>>> Speaking of the dts file, I have left the p1010si.dtsi file with the
> >>>> fsl,flexcan-v1.0 .compatible definition. The flexcan folks (IIRC
> >>>> Wolfgang) objected to that as it does not follow the standard which
> >>>> should be just fsl,flexcan.
> >>>>
> >>>> How would you like to change that? Should I add it as part of this
> >>>> patch, add another patch to the series, or let you take care of it?
> >>>>
> >>>> Also, I assume the uboot project will need to be changed as well to
> >>>> reflect the corrected name.
> >>>
> >>> I think you should provide patches within this series to cleanup the
> >>> obsolete stuff, dts and binding doc.
> >>
> >> It reads to me that the binding doc now reduces just the required
> >> properties. Should I remove the file entirely?
> > [Bhaskar] I think the binding doc should atleast be present with the required properties to give the clarity
> > about the CAN functionality
> > can0@1c000 {
> > compatible = "fsl,flexcan";
> > reg = <0x1c000 0x1000>;
> > interrupts = <48 0x2>;
> > interrupt-parent = <&mpic>;
> > clock-frequency = <fixed by u-boot>;
> > };
>
> Yes, I also find the introduction is quite useful, with some related
> correction.
I am not sure what is useful. The clock source bits are all wrong.
When that is removed, you end up with a discussion about the prescaler
which is actually related to the flexcan.c file and has nothing
to do with the device node. Maybe I am just going back into my
not-communicating-well mode. Could you follow up with what you think
belongs in the introduction of the binding file?
Thanks,
Robin
^ permalink raw reply
* Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
From: Wolfgang Grandegger @ 2011-08-09 14:14 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
U Bhaskar-B22300, Marc Kleine-Budde
In-Reply-To: <20110809140901.GX4926-sJ/iWh9BUns@public.gmane.org>
On 08/09/2011 04:09 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 04:03:38PM +0200, Wolfgang Grandegger wrote:
>> On 08/09/2011 03:44 PM, U Bhaskar-B22300 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Robin Holt [mailto:holt-sJ/iWh9BUns@public.gmane.org]
>>>> Sent: Tuesday, August 09, 2011 7:06 PM
>>>> To: Wolfgang Grandegger
>>>> Cc: Robin Holt; U Bhaskar-B22300; socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org;
>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Marc Kleine-
>>>> Budde
>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>>>
>>>> On Tue, Aug 09, 2011 at 03:03:50PM +0200, Wolfgang Grandegger wrote:
>>>>> On 08/09/2011 02:49 PM, Robin Holt wrote:
>>>>>> On Tue, Aug 09, 2011 at 12:41:39PM +0000, U Bhaskar-B22300 wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
>>>>>>>> Sent: Tuesday, August 09, 2011 4:19 PM
>>>>>>>> To: U Bhaskar-B22300
>>>>>>>> Cc: Marc Kleine-Budde; socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org;
>>>>>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.
>>>>>>>>
>>>>>>>> On 08/09/2011 11:27 AM, U Bhaskar-B22300 wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
>>>>>>>>>> Sent: Tuesday, August 09, 2011 2:03 PM
>>>>>>>>>> To: U Bhaskar-B22300
>>>>>>>>>> Cc: Marc Kleine-Budde; socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org;
>>>>>>>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>>>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
>>>> source.
>>>>>>>>>>
>>>>>>>>>> Hi Bhaskar,
>>>>>>>>>>
>>>>>>>>>> On 08/09/2011 09:57 AM, U Bhaskar-B22300 wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Marc Kleine-Budde [mailto:mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org]
>>>>>>>>>>>> Sent: Tuesday, August 09, 2011 12:23 AM
>>>>>>>>>>>> To: Wolfgang Grandegger
>>>>>>>>>>>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; U
>>>>>>>>>>>> Bhaskar- B22300
>>>>>>>>>>>> Subject: Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock
>>>> source.
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08/2011 05:33 PM, Wolfgang Grandegger wrote:
>>>>>>>>>>>>>> ACK - The device tree bindings as in mainline's
>>>>>>>>>>>>>> Documentation is a
>>>>>>>>>>>> mess.
>>>>>>>>>>>>>> If the powerpc guys are happy with a clock interfaces based
>>>>>>>>>>>>>> approach somewhere in arch/ppc, I'm more than happy to
>>>> remove:
>>>>>>>>>>>>>> - fsl,flexcan-clock-source (not implemented, even in the fsl
>>>>>>>>>>>>>> driver)
>>>>>>>>>>> [Bhaskar]I have pushed the FlexCAN series of patches, It
>>>>>>>>>>> contains the usage of all the fields posted in the FlexCAN
>>>>>>>>>>> bindings at
>>>>>>>>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.gi
>>>>>>>>>>> t;a=b
>>>>>>>>>>> lo
>>>>>>>>>>> b;f=Documentation/devicetree/bindings/net/can/fsl-flexcan.txt;h
>>>>>>>>>>> =1a72
>>>>>>>>>>> 9f
>>>>>>>>>>> 089866259ef82d0db5893ff7a8c54d5ccf;hb=94ed5b4788a7cdbe68bc7cb85
>>>>>>>>>>> 16972
>>>>>>>>>>> cb
>>>>>>>>>>> ebdc8274
>>>>>>>>>>
>>>>>>>>>> As Marc already pointed out, Robin already has a much more
>>>>>>>>>> advanced patch stack in preparation. Especially your patches do
>>>>>>>>>> not care about the already existing Flexcan core on the
>>>> Freescale's ARM socks.
>>>>>>>>> [Bhaskar] No, the patches are taking care of the existing ARM
>>>>>>>> functionality.
>>>>>>>>> I have not tested on the ARM based board, but the patches are
>>>>>>>>> made
>>>>>>>> in a
>>>>>>>>> Manner that it should not break the ARM based functionality.
>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - fsl,flexcan-clock-divider \__ replace with code in
>>>> arch/ppc, or
>>>>>>>>>>>>>> - clock-frequency / a single clock-frequency
>>>> attribute
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the "net-next-2.6" tree there is also:
>>>>>>>>>>>>>
>>>>>>>>>>>>> $ grep flexcan arch/powerpc/boots/dts/*.dts
>>>>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
>>>>>>>>>> "platform";
>>>>>>>>>>>>> p1010rdb.dts: fsl,flexcan-clock-source =
>>>>>>>>>> "platform";
>>>>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
>>>> v1.0";
>>>>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
>>>> <2>;
>>>>>>>>>>>>> p1010si.dtsi: compatible = "fsl,flexcan-
>>>> v1.0";
>>>>>>>>>>>>> p1010si.dtsi: fsl,flexcan-clock-divider =
>>>> <2>;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Especially the fsl,flexcan-clock-divider = <2>; might make
>>>>>>>>>>>>> people think, that they could set something else.
>>>>>>>>>>>>
>>>>>>>>>>> [Bhaskar] As it is mentioned in the Flexcan bindings, the need
>>>>>>>>>>> of
>>>>>>>>>> fsl,flexcan-clock-divider = <2>;
>>>>>>>>>>> But I kept it as "2" because FlexCan clock source is the
>>>>>>>>>> platform clock and it is CCB/2
>>>>>>>>>>> If the "2" is misleading, the bindings can be changed or
>>>>>>>>>>> some
>>>>>>>>>> text can be written to make the meaning of "2"
>>>>>>>>>>> Understandable , Please suggest ..
>>>>>>>>>>
>>>>>>>>>> The clock source and frequency is fixed. Why do we need an extra
>>>>>>>>>> properties for that. We have panned to remove these bogus
>>>>>>>>>> bindings from the Linux kernel, which sneaked in *without* any
>>>>>>>>>> review on the relevant mailing lists (at least I have not
>>>>>>>>>> realized any posting). We do not think they are really needed.
>>>>>>>>>> They just confuse the user. We also prefer to use the
>>>>>>>>>> compatibility string "fsl,flexcan" instead "fsl,flexcan-v1.0".
>>>>>>>>>> It's unusual to add a version number, which is for the Flexcan
>>>>>>>>>> on the PowerPC cores only, I assume, but there will be device
>>>>>>>>>> tree for ARM soon. A proper compatibility string would be
>>>> "fsl,p1010-flexcan" if we really need to distinguish.
>>>>>>>>>>
>>>>>>>>> [Bhaskar] About clock source.. There can be two sources of clock
>>>>>>>>> for
>>>>>>>> the CAN.
>>>>>>>>> Oscillator or the platform clock, but at present only
>>>> platform
>>>>>>>> clock is supported
>>>>>>>>> in P1010.If we remove the fsl,flexcan-clock-source property,
>>>> we
>>>>>>>> will lost the flexibility
>>>>>>>>> of changing the clock source ..
>>>>>>>>>
>>>>>>>>> About clock-frequency... it is also not fixed. It
>>>>>>>>> depends on
>>>>>>>> the platform clock which in turns
>>>>>>>>> Depends on the CCB clock. So it will be better to keep
>>>>>>>>> clock-
>>>>>>>> frequency property which is getting fixed via u-boot.
>>>>>>>>
>>>>>>>> The frequency is fixed to CCB-frequency / 2. Will that ever
>>>>>>>> change? What can we expect from future Flexcan hardware? Will it
>>>>>>>> support further clock sources?
>>>>>>> [Bhaskar] Yes the frequency will always be CCB-frequency/2.Even if
>>>> the CCB gets changed that will be taken care by the u-boot fixup code for
>>>>>>> clock-frequency. clock-frequency is not filled by somebody in the
>>>> dts file. It will be done by u-boot.
>>>>>>> For clock source,I can't say right now, that's why I have kept a
>>>> property for this in the can node. So that in future, we need to fill it
>>>>>>> appropriately
>>>>>>
>>>>>> Speaking of the dts file, I have left the p1010si.dtsi file with the
>>>>>> fsl,flexcan-v1.0 .compatible definition. The flexcan folks (IIRC
>>>>>> Wolfgang) objected to that as it does not follow the standard which
>>>>>> should be just fsl,flexcan.
>>>>>>
>>>>>> How would you like to change that? Should I add it as part of this
>>>>>> patch, add another patch to the series, or let you take care of it?
>>>>>>
>>>>>> Also, I assume the uboot project will need to be changed as well to
>>>>>> reflect the corrected name.
>>>>>
>>>>> I think you should provide patches within this series to cleanup the
>>>>> obsolete stuff, dts and binding doc.
>>>>
>>>> It reads to me that the binding doc now reduces just the required
>>>> properties. Should I remove the file entirely?
>>> [Bhaskar] I think the binding doc should atleast be present with the required properties to give the clarity
>>> about the CAN functionality
>>> can0@1c000 {
>>> compatible = "fsl,flexcan";
>>> reg = <0x1c000 0x1000>;
>>> interrupts = <48 0x2>;
>>> interrupt-parent = <&mpic>;
>>> clock-frequency = <fixed by u-boot>;
>>> };
>>
>> Yes, I also find the introduction is quite useful, with some related
>> correction.
>
> I am not sure what is useful. The clock source bits are all wrong.
> When that is removed, you end up with a discussion about the prescaler
> which is actually related to the flexcan.c file and has nothing
> to do with the device node. Maybe I am just going back into my
> not-communicating-well mode. Could you follow up with what you think
> belongs in the introduction of the binding file?
Yep, you are right. Keep it simple...
Wolfgang,
^ permalink raw reply
* [PATCH v2] net: add Documentation/networking/scaling.txt
From: Willem de Bruijn @ 2011-08-09 14:20 UTC (permalink / raw)
To: rdunlap, linux-doc, davem, netdev, therbert
Describes RSS, RPS, RFS, accelerated RFS, and XPS.
This version incorporates comments by Randy Dunlap and Rick Jones.
Besides text cleanup, it adds an explicit "Suggested Configuration"
heading to each section.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
Documentation/networking/scaling.txt | 372 ++++++++++++++++++++++++++++++++++
1 files changed, 372 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/scaling.txt
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
new file mode 100644
index 0000000..3da03c3
--- /dev/null
+++ b/Documentation/networking/scaling.txt
@@ -0,0 +1,372 @@
+Scaling in the Linux Networking Stack
+
+
+Introduction
+============
+
+This document describes a set of complementary techniques in the Linux
+networking stack to increase parallelism and improve performance for
+multi-processor systems.
+
+The following technologies are described:
+
+ RSS: Receive Side Scaling
+ RPS: Receive Packet Steering
+ RFS: Receive Flow Steering
+ Accelerated Receive Flow Steering
+ XPS: Transmit Packet Steering
+
+
+RSS: Receive Side Scaling
+=========================
+
+Contemporary NICs support multiple receive and transmit descriptor queues
+(multi-queue). On reception, a NIC can send different packets to different
+queues to distribute processing among CPUs. The NIC distributes packets by
+applying a filter to each packet that assigns it to one of a small number
+of logical flows. Packets for each flow are steered to a separate receive
+queue, which in turn can be processed by separate CPUs. This mechanism is
+generally known as “Receive-side Scaling” (RSS). The goal of RSS and
+the other scaling techniques to increase performance uniformly.
+Multi-queue distribution can also be used for traffic prioritization, but
+that is not the focus of these techniques.
+
+The filter used in RSS is typically a hash function over the network
+and/or transport layer headers-- for example, a 4-tuple hash over
+IP addresses and TCP ports of a packet. The most common hardware
+implementation of RSS uses a 128-entry indirection table where each entry
+stores a queue number. The receive queue for a packet is determined
+by masking out the low order seven bits of the computed hash for the
+packet (usually a Toeplitz hash), taking this number as a key into the
+indirection table and reading the corresponding value.
+
+Some advanced NICs allow steering packets to queues based on
+programmable filters. For example, webserver bound TCP port 80 packets
+can be directed to their own receive queue. Such “n-tuple” filters can
+be configured from ethtool (--config-ntuple).
+
+==== RSS Configuration
+
+The driver for a multi-queue capable NIC typically provides a kernel
+module parameter for specifying the number of hardware queues to
+configure. In the bnx2x driver, for instance, this parameter is called
+num_queues. A typical RSS configuration would be to have one receive queue
+for each CPU if the device supports enough queues, or otherwise at least
+one for each cache domain at a particular cache level (L1, L2, etc.).
+
+The indirection table of an RSS device, which resolves a queue by masked
+hash, is usually programmed by the driver at initialization. The
+default mapping is to distribute the queues evenly in the table, but the
+indirection table can be retrieved and modified at runtime using ethtool
+commands (--show-rxfh-indir and --set-rxfh-indir). Modifying the
+indirection table could be done to give different queues different
+relative weights.
+
+== RSS IRQ Configuration
+
+Each receive queue has a separate IRQ associated with it. The NIC triggers
+this to notify a CPU when new packets arrive on the given queue. The
+signaling path for PCIe devices uses message signaled interrupts (MSI-X),
+that can route each interrupt to a particular CPU. The active mapping
+of queues to IRQs can be determined from /proc/interrupts. By default,
+an IRQ may be handled on any CPU. Because a non-negligible part of packet
+processing takes place in receive interrupt handling, it is advantageous
+to spread receive interrupts between CPUs. To manually adjust the IRQ
+affinity of each interrupt see Documentation/IRQ-affinity. Some systems
+will be running irqbalance, a daemon that dynamically optimizes IRQ
+assignments and as a result may override any manual settings.
+
+== Suggested Configuration
+
+RSS should be enabled when latency is a concern or whenever receive
+interrupt processing forms a bottleneck. Spreading load between CPUs
+decreases queue length. For low latency networking, the optimal setting
+is to allocate as many queues as there are CPUs in the system (or the
+NIC maximum, if lower). Because the aggregate number of interrupts grows
+with each additional queue, the most efficient high-rate configuration
+is likely the one with the smallest number of receive queues where no
+CPU that processes receive interrupts reaches 100% utilization. Per-cpu
+load can be observed using the mpstat utility.
+
+
+RPS: Receive Packet Steering
+============================
+
+Receive Packet Steering (RPS) is logically a software implementation of
+RSS. Being in software, it is necessarily called later in the datapath.
+Whereas RSS selects the queue and hence CPU that will run the hardware
+interrupt handler, RPS selects the CPU to perform protocol processing
+above the interrupt handler. This is accomplished by placing the packet
+on the desired CPU’s backlog queue and waking up the CPU for processing.
+RPS has some advantages over RSS: 1) it can be used with any NIC,
+2) software filters can easily be added to hash over new protocols,
+3) it does not increase hardware device interrupt rate (although it does
+introduce inter-processor interrupts (IPIs)).
+
+RPS is called during bottom half of the receive interrupt handler, when
+a driver sends a packet up the network stack with netif_rx() or
+netif_receive_skb(). These call the get_rps_cpu() function, which
+selects the queue that should process a packet.
+
+The first step in determining the target CPU for RPS is to calculate a
+flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+depending on the protocol). This serves as a consistent hash of the
+associated flow of the packet. The hash is either provided by hardware
+or will be computed in the stack. Capable hardware can pass the hash in
+the receive descriptor for the packet; this would usually be the same
+hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
+skb->rx_hash and can be used elsewhere in the stack as a hash of the
+packet’s flow.
+
+Each receive hardware queue has an associated list of CPUs to which
+RPS may enqueue packets for processing. For each received packet,
+an index into the list is computed from the flow hash modulo the size
+of the list. The indexed CPU is the target for processing the packet,
+and the packet is queued to the tail of that CPU’s backlog queue. At
+the end of the bottom half routine, IPIs are sent to any CPUs for which
+packets have been queued to their backlog queue. The IPI wakes backlog
+processing on the remote CPU, and any queued packets are then processed
+up the networking stack.
+
+==== RPS Configuration
+
+RPS requires a kernel compiled with the CONFIG_RPS kconfig symbol (on
+by default for SMP). Even when compiled in, RPS remains disabled until
+explicitly configured. The list of CPUs to which RPS may forward traffic
+can be configured for each receive queue using a sysfs file entry:
+
+ /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
+
+This file implements a bitmap of CPUs. RPS is disabled when it is zero
+(the default), in which case packets are processed on the interrupting
+CPU. Documentation/IRQ-affinity.txt explains how CPUs are assigned to
+the bitmap.
+
+== Suggested Configuration
+
+For a single queue device, a typical RPS configuration would be to set
+the rps_cpus to the CPUs in the same cache domain of the interrupting
+CPU. If NUMA locality is not an issue, this could also be all CPUs in
+the system. At high interrupt rate, it might be wise to exclude the
+interrupting CPU from the map since that already performs much work.
+
+For a multi-queue system, if RSS is configured so that a hardware
+receive queue is mapped to each CPU, then RPS is probably redundant
+and unnecessary. If there are fewer hardware queues than CPUs, then
+RPS might be beneficial if the rps_cpus for each queue are the ones that
+share the same cache domain as the interrupting CPU for that queue.
+
+
+RFS: Receive Flow Steering
+==========================
+
+While RPS steers packets solely based on hash, and thus generally
+provides good load distribution, it does not take into account
+application locality. This is accomplished by Receive Flow Steering
+(RFS). The goal of RFS is to increase datacache hitrate by steering
+kernel processing of packets to the CPU where the application thread
+consuming the packet is running. RFS relies on the same RPS mechanisms
+to enqueue packets onto the backlog of another CPU and to wake up that
+CPU.
+
+In RFS, packets are not forwarded directly by the value of their hash,
+but the hash is used as index into a flow lookup table. This table maps
+flows to the CPUs where those flows are being processed. The flow hash
+(see RPS section above) is used to calculate the index into this table.
+The CPU recorded in each entry is the one which last processed the flow.
+If an entry does not hold a valid CPU, then packets mapped to that entry
+are steered using plain RPS. Multiple table entries may point to the
+same CPU. Indeed, with many flows and few CPUs, it is very likely that
+a single application thread handles flows with many different flow hashes.
+
+rps_sock_table is a global flow table that contains the *desired* CPU for
+flows: the CPU that is currently processing the flow in userspace. Each
+table value is a CPU index that is updated during calls to recvmsg and
+sendmsg (specifically, inet_recvmsg(), inet_sendmsg(), inet_sendpage()
+and tcp_splice_read()).
+
+When the scheduler moves a thread to a new CPU while it has outstanding
+receive packets on the old CPU, packets may arrive out of order. To
+avoid this, RFS uses a second flow table to track outstanding packets
+for each flow: rps_dev_flow_table is a table specific to each hardware
+receive queue of each device. Each table value stores a CPU index and a
+counter. The CPU index represents the *current* CPU onto which packets
+for this flow are enqueued for further kernel processing. Ideally, kernel
+and userspace processing occur on the same CPU, and hence the CPU index
+in both tables is identical. This is likely false if the scheduler has
+recently migrated a userspace thread while the kernel still has packets
+enqueued for kernel processing on the old CPU.
+
+The counter in rps_dev_flow_table values records the length of the current
+CPU's backlog when a packet in this flow was last enqueued. Each backlog
+queue has a head counter that is incremented on dequeue. A tail counter
+is computed as head counter + queue length. In other words, the counter
+in rps_dev_flow_table[i] records the last element in flow i that has
+been enqueued onto the currently designated CPU for flow i (of course,
+entry i is actually selected by hash and multiple flows may hash to the
+same entry i).
+
+And now the trick for avoiding out of order packets: when selecting the
+CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
+and the rps_dev_flow table of the queue that the packet was received on
+are compared. If the desired CPU for the flow (found in the
+rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
+table), the packet is enqueued onto that CPU’s backlog. If they differ,
+the current CPU is updated to match the desired CPU if one of the
+following is true:
+
+- The current CPU's queue head counter >= the recorded tail counter
+ value in rps_dev_flow[i]
+- The current CPU is unset (equal to NR_CPUS)
+- The current CPU is offline
+
+After this check, the packet is sent to the (possibly updated) current
+CPU. These rules aim to ensure that a flow only moves to a new CPU when
+there are no packets outstanding on the old CPU, as the outstanding
+packets could arrive later than those about to be processed on the new
+CPU.
+
+==== RFS Configuration
+
+RFS is only available if the kconfig symbol CONFIG_RFS is enabled (on
+by default for SMP). The functionality remains disabled until explicitly
+configured. The number of entries in the global flow table is set through:
+
+ /proc/sys/net/core/rps_sock_flow_entries
+
+The number of entries in the per-queue flow table are set through:
+
+ /sys/class/net/<dev>/queues/tx-<n>/rps_flow_cnt
+
+== Suggested Configuration
+
+Both of these need to be set before RFS is enabled for a receive queue.
+Values for both are rounded up to the nearest power of two. The
+suggested flow count depends on the expected number of active connections
+at any given time, which may be significantly less than the number of open
+connections. We have found that a value of 32768 for rps_sock_flow_entries
+works fairly well on a moderately loaded server.
+
+For a single queue device, the rps_flow_cnt value for the single queue
+would normally be configured to the same value as rps_sock_flow_entries.
+For a multi-queue device, the rps_flow_cnt for each queue might be
+configured as rps_sock_flow_entries / N, where N is the number of
+queues. So for instance, if rps_flow_entries is set to 32768 and there
+are 16 configured receive queues, rps_flow_cnt for each queue might be
+configured as 2048.
+
+
+Accelerated RFS
+===============
+
+Accelerated RFS is to RFS what RSS is to RPS: a hardware-accelerated load
+balancing mechanism that uses soft state to steer flows based on where
+the application thread consuming the packets of each flow is running.
+Accelerated RFS should perform better than RFS since packets are sent
+directly to a CPU local to the thread consuming the data. The target CPU
+will either be the same CPU where the application runs, or at least a CPU
+which is local to the application thread’s CPU in the cache hierarchy.
+
+To enable accelerated RFS, the networking stack calls the
+ndo_rx_flow_steer driver function to communicate the desired hardware
+queue for packets matching a particular flow. The network stack
+automatically calls this function every time a flow entry in
+rps_dev_flow_table is updated. The driver in turn uses a device specific
+method to program the NIC to steer the packets.
+
+The hardware queue for a flow is derived from the CPU recorded in
+rps_dev_flow_table. The stack consults a CPU to hardware queue map which
+is maintained by the NIC driver. This is an auto-generated reverse map of
+the IRQ affinity table shown by /proc/interrupts. Drivers can use
+functions in the cpu_rmap (“CPU affinity reverse map”) kernel library
+to populate the map. For each CPU, the corresponding queue in the map is
+set to be one whose processing CPU is closest in cache locality.
+
+==== Accelerated RFS Configuration
+
+Accelerated RFS is only available if the kernel is compiled with
+CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
+It also requires that ntuple filtering is enabled via ethtool. The map
+of CPU to queues is automatically deduced from the IRQ affinities
+configured for each receive queue by the driver, so no additional
+configuration should be necessary.
+
+== Suggested Configuration
+
+This technique should be enabled whenever one wants to use RFS and the
+NIC supports hardware acceleration.
+
+XPS: Transmit Packet Steering
+=============================
+
+Transmit Packet Steering is a mechanism for intelligently selecting
+which transmit queue to use when transmitting a packet on a multi-queue
+device. To accomplish this, a mapping from CPU to hardware queue(s) is
+recorded. The goal of this mapping is usually to assign queues
+exclusively to a subset of CPUs, where the transmit completions for
+these queues are processed on a CPU within this set. This choice
+provides two benefits. First, contention on the device queue lock is
+significantly reduced since fewer CPUs contend for the same queue
+(contention can be eliminated completely if each CPU has its own
+transmit queue). Secondly, cache miss rate on transmit completion is
+reduced, in particular for data cache lines that hold the sk_buff
+structures.
+
+XPS is configured per transmit queue by setting a bitmap of CPUs that
+may use that queue to transmit. The reverse mapping, from CPUs to
+transmit queues, is computed and maintained for each network device.
+When transmitting the first packet in a flow, the function
+get_xps_queue() is called to select a queue. This function uses the ID
+of the running CPU as a key into the CPU-to-queue lookup table. If the
+ID matches a single queue, that is used for transmission. If multiple
+queues match, one is selected by using the flow hash to compute an index
+into the set.
+
+The queue chosen for transmitting a particular flow is saved in the
+corresponding socket structure for the flow (e.g. a TCP connection).
+This transmit queue is used for subsequent packets sent on the flow to
+prevent out of order (ooo) packets. The choice also amortizes the cost
+of calling get_xps_queues() over all packets in the connection. To avoid
+ooo packets, the queue for a flow can subsequently only be changed if
+skb->ooo_okay is set for a packet in the flow. This flag indicates that
+there are no outstanding packets in the flow, so the transmit queue can
+change without the risk of generating out of order packets. The
+transport layer is responsible for setting ooo_okay appropriately. TCP,
+for instance, sets the flag when all data for a connection has been
+acknowledged.
+
+==== XPS Configuration
+
+XPS is only available if the kconfig symbol CONFIG_XPS is enabled (on by
+default for SMP). The functionality remains disabled until explicitly
+configured. To enable XPS, the bitmap of CPUs that may use a transmit
+queue is configured using the sysfs file entry:
+
+/sys/class/net/<dev>/queues/tx-<n>/xps_cpus
+
+== Suggested Configuration
+
+For a network device with a single transmission queue, XPS configuration
+has no effect, since there is no choice in this case. In a multi-queue
+system, XPS is preferably configured so that each CPU maps onto one queue.
+If there are as many queues as there are CPUs in the system, then each
+queue can also map onto one CPU, resulting in exclusive pairings that
+experience no contention. If there are fewer queues than CPUs, then the
+best CPUs to share a given queue are probably those that share the cache
+with the CPU that processes transmit completions for that queue
+(transmit interrupts).
+
+
+Further Information
+===================
+RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
+2.6.38. Original patches were submitted by Tom Herbert
+(therbert@google.com)
+
+Accelerated RFS was introduced in 2.6.35. Original patches were
+submitted by Ben Hutchings (bhutchings@solarflare.com)
+
+Authors:
+Tom Herbert (therbert@google.com)
+Willem de Bruijn (willemb@google.com)
+
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH net-next 2/2] bnx2x: Coalesce pr_cont uses and fix DP typos
From: Eilon Greenstein @ 2011-08-09 14:41 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <98d09e1b3d7a73bf5f2744f0ca238321573e4579.1312818707.git.joe@perches.com>
On Mon, 2011-08-08 at 08:53 -0700, Joe Perches wrote:
> Uses of pr_cont should be avoided where reasonably possible
> because they can be interleaved by other threads and processes.
>
> Coalesce pr_cont uses.
>
> Fix typos, duplicated words and spacing in DP uses caused
> by split multi-line formats. Coalesce some of these
> split formats. Add missing terminating newlines to DP uses.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
....
> @@ -12254,7 +12261,7 @@ void bnx2x_period_func(struct link_params *params, struct link_vars *vars)
> {
> struct bnx2x *bp = params->bp;
> if (!params) {
> - DP(NETIF_MSG_LINK, "Ininitliazed params !\n");
> + DP(NETIF_MSG_LINK, "Uninitialized params !\n");
> return;
> }
> /* DP(NETIF_MSG_LINK, "Periodic called vars->phy_flags 0x%x speed 0x%x
This does not apply on the current net-next. Other than that - it looks
good.
Please re-submit this patch series once net-next is opened for driver
changes (see: http://marc.info/?l=linux-netdev&m=131278578427946&w=2 )
and I will ACK it.
Thanks,
Eilon
^ permalink raw reply
* [Patch 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010) -V9
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, PPC list, Kumar Gala
Marc, Wolfgang or U Bhaskar,
This patch set should have all your comments included. It is based on
the David S. Miller net-next-2.6 tree commit 19fd617.
This series adds a fifth patch which cleans up and corrects the device
bindigs for the fsl-flexcan nodes.
I have compiled each patch in the series individually for both arm and
powerpc (cheated on ppc and reordered them with the last patch first so
I could select CAN_FLEXCAN.
With all the patches applied, my p1010rdb works for communicating between
its two can ports and also can communicate with an external PSOC. I have
done no testing beyond compile testing on an arm system as I have no
access to an arm based system.
For the first three patches in the series, I believe they are all ready
for forwarding to David S. Miller for the netdev tree. I think patch
4 is ready for submission to the PPC85xx maintainer. This is the
first submission of patch 5.
Thanks,
Robin Holt
^ permalink raw reply
* [PATCH 1/5] [flexcan] Remove #include <mach/clock.h>
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, PPC list, Wolfgang Grandegger
In-Reply-To: <1312901031-29887-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
powerpc does not have a mach-####/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 1767811..586b2cd 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -35,8 +35,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <mach/clock.h>
-
#define DRV_NAME "flexcan"
/* 8 for RX fifo and 2 error handling */
--
1.7.2.1
^ permalink raw reply related
* [PATCH 2/5] [flexcan] Abstract off read/write for big/little endian.
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1312901031-29887-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 140 ++++++++++++++++++++++++++------------------
1 files changed, 83 insertions(+), 57 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 586b2cd..68cbe52 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -190,6 +190,31 @@ static struct can_bittiming_const flexcan_bittiming_const = {
};
/*
+ * Abstract off the read/write for arm versus ppc.
+ */
+#if defined(__BIG_ENDIAN)
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return in_be32(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ out_be32(addr, val);
+}
+#else
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return readl(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ writel(val, addr);
+}
+#endif
+
+/*
* Swtich transceiver on or off
*/
static void flexcan_transceiver_switch(const struct flexcan_priv *priv, int on)
@@ -210,9 +235,9 @@ static inline void flexcan_chip_enable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg &= ~FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
udelay(10);
}
@@ -222,9 +247,9 @@ static inline void flexcan_chip_disable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
}
static int flexcan_get_berr_counter(const struct net_device *dev,
@@ -232,7 +257,7 @@ static int flexcan_get_berr_counter(const struct net_device *dev,
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
- u32 reg = readl(®s->ecr);
+ u32 reg = flexcan_read(®s->ecr);
bec->txerr = (reg >> 0) & 0xff;
bec->rxerr = (reg >> 8) & 0xff;
@@ -266,15 +291,15 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (cf->can_dlc > 0) {
u32 data = be32_to_cpup((__be32 *)&cf->data[0]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
}
if (cf->can_dlc > 3) {
u32 data = be32_to_cpup((__be32 *)&cf->data[4]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
}
- writel(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
- writel(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
+ flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
+ flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
kfree_skb(skb);
@@ -462,8 +487,8 @@ static void flexcan_read_fifo(const struct net_device *dev,
struct flexcan_mb __iomem *mb = ®s->cantxfg[0];
u32 reg_ctrl, reg_id;
- reg_ctrl = readl(&mb->can_ctrl);
- reg_id = readl(&mb->can_id);
+ reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_id = flexcan_read(&mb->can_id);
if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
@@ -473,12 +498,12 @@ static void flexcan_read_fifo(const struct net_device *dev,
cf->can_id |= CAN_RTR_FLAG;
cf->can_dlc = get_can_dlc((reg_ctrl >> 16) & 0xf);
- *(__be32 *)(cf->data + 0) = cpu_to_be32(readl(&mb->data[0]));
- *(__be32 *)(cf->data + 4) = cpu_to_be32(readl(&mb->data[1]));
+ *(__be32 *)(cf->data + 0) = cpu_to_be32(flexcan_read(&mb->data[0]));
+ *(__be32 *)(cf->data + 4) = cpu_to_be32(flexcan_read(&mb->data[1]));
/* mark as read */
- writel(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
- readl(®s->timer);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
+ flexcan_read(®s->timer);
}
static int flexcan_read_frame(struct net_device *dev)
@@ -514,17 +539,17 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
* The error bits are cleared on read,
* use saved value from irq handler.
*/
- reg_esr = readl(®s->esr) | priv->reg_esr;
+ reg_esr = flexcan_read(®s->esr) | priv->reg_esr;
/* handle state changes */
work_done += flexcan_poll_state(dev, reg_esr);
/* handle RX-FIFO */
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
while (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE &&
work_done < quota) {
work_done += flexcan_read_frame(dev);
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
}
/* report bus errors */
@@ -534,8 +559,8 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
if (work_done < quota) {
napi_complete(napi);
/* enable IRQs */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
- writel(priv->reg_ctrl_default, ®s->ctrl);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default, ®s->ctrl);
}
return work_done;
@@ -549,9 +574,9 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg_iflag1, reg_esr;
- reg_iflag1 = readl(®s->iflag1);
- reg_esr = readl(®s->esr);
- writel(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
+ reg_iflag1 = flexcan_read(®s->iflag1);
+ reg_esr = flexcan_read(®s->esr);
+ flexcan_write(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
/*
* schedule NAPI in case of:
@@ -567,16 +592,16 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
* save them for later use.
*/
priv->reg_esr = reg_esr & FLEXCAN_ESR_ERR_BUS;
- writel(FLEXCAN_IFLAG_DEFAULT & ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE,
- ®s->imask1);
- writel(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT &
+ ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
®s->ctrl);
napi_schedule(&priv->napi);
}
/* FIFO overflow */
if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
- writel(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
dev->stats.rx_over_errors++;
dev->stats.rx_errors++;
}
@@ -585,7 +610,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
/* tx_bytes is incremented in flexcan_start_xmit */
stats->tx_packets++;
- writel((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
+ flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
netif_wake_queue(dev);
}
@@ -599,7 +624,7 @@ static void flexcan_set_bittiming(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg &= ~(FLEXCAN_CTRL_PRESDIV(0xff) |
FLEXCAN_CTRL_RJW(0x3) |
FLEXCAN_CTRL_PSEG1(0x7) |
@@ -623,11 +648,11 @@ static void flexcan_set_bittiming(struct net_device *dev)
reg |= FLEXCAN_CTRL_SMP;
dev_info(dev->dev.parent, "writing ctrl=0x%08x\n", reg);
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: mcr=0x%08x ctrl=0x%08x\n", __func__,
- readl(®s->mcr), readl(®s->ctrl));
+ flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
}
/*
@@ -648,10 +673,10 @@ static int flexcan_chip_start(struct net_device *dev)
flexcan_chip_enable(priv);
/* soft reset */
- writel(FLEXCAN_MCR_SOFTRST, ®s->mcr);
+ flexcan_write(FLEXCAN_MCR_SOFTRST, ®s->mcr);
udelay(10);
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
if (reg_mcr & FLEXCAN_MCR_SOFTRST) {
dev_err(dev->dev.parent,
"Failed to softreset can module (mcr=0x%08x)\n",
@@ -673,12 +698,12 @@ static int flexcan_chip_start(struct net_device *dev)
* choose format C
*
*/
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_FEN | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_SUPV | FLEXCAN_MCR_WRN_EN |
FLEXCAN_MCR_IDAM_C;
dev_dbg(dev->dev.parent, "%s: writing mcr=0x%08x", __func__, reg_mcr);
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
/*
* CTRL
@@ -696,7 +721,7 @@ static int flexcan_chip_start(struct net_device *dev)
* (FLEXCAN_CTRL_ERR_MSK), too. Otherwise we don't get any
* warning or bus passive interrupts.
*/
- reg_ctrl = readl(®s->ctrl);
+ reg_ctrl = flexcan_read(®s->ctrl);
reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
@@ -704,38 +729,39 @@ static int flexcan_chip_start(struct net_device *dev)
/* save for later use */
priv->reg_ctrl_default = reg_ctrl;
dev_dbg(dev->dev.parent, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
- writel(reg_ctrl, ®s->ctrl);
+ flexcan_write(reg_ctrl, ®s->ctrl);
for (i = 0; i < ARRAY_SIZE(regs->cantxfg); i++) {
- writel(0, ®s->cantxfg[i].can_ctrl);
- writel(0, ®s->cantxfg[i].can_id);
- writel(0, ®s->cantxfg[i].data[0]);
- writel(0, ®s->cantxfg[i].data[1]);
+ flexcan_write(0, ®s->cantxfg[i].can_ctrl);
+ flexcan_write(0, ®s->cantxfg[i].can_id);
+ flexcan_write(0, ®s->cantxfg[i].data[0]);
+ flexcan_write(0, ®s->cantxfg[i].data[1]);
/* put MB into rx queue */
- writel(FLEXCAN_MB_CNT_CODE(0x4), ®s->cantxfg[i].can_ctrl);
+ flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
+ ®s->cantxfg[i].can_ctrl);
}
/* acceptance mask/acceptance code (accept everything) */
- writel(0x0, ®s->rxgmask);
- writel(0x0, ®s->rx14mask);
- writel(0x0, ®s->rx15mask);
+ flexcan_write(0x0, ®s->rxgmask);
+ flexcan_write(0x0, ®s->rx14mask);
+ flexcan_write(0x0, ®s->rx15mask);
flexcan_transceiver_switch(priv, 1);
/* synchronize with the can bus */
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_HALT;
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
priv->can.state = CAN_STATE_ERROR_ACTIVE;
/* enable FIFO interrupts */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: reading mcr=0x%08x ctrl=0x%08x\n",
- __func__, readl(®s->mcr), readl(®s->ctrl));
+ __func__, flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
return 0;
@@ -757,12 +783,12 @@ static void flexcan_chip_stop(struct net_device *dev)
u32 reg;
/* Disable all interrupts */
- writel(0, ®s->imask1);
+ flexcan_write(0, ®s->imask1);
/* Disable + halt module */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS | FLEXCAN_MCR_HALT;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
flexcan_transceiver_switch(priv, 0);
priv->can.state = CAN_STATE_STOPPED;
@@ -854,24 +880,24 @@ static int __devinit register_flexcandev(struct net_device *dev)
/* select "bus clock", chip must be disabled */
flexcan_chip_disable(priv);
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
flexcan_chip_enable(priv);
/* set freeze, halt and activate FIFO, restrict register access */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_FEN | FLEXCAN_MCR_SUPV;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
/*
* Currently we only support newer versions of this core
* featuring a RX FIFO. Older cores found on some Coldfire
* derivates are not yet supported.
*/
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
if (!(reg & FLEXCAN_MCR_FEN)) {
dev_err(dev->dev.parent,
"Could not enable RX FIFO, unsupported core\n");
--
1.7.2.1
^ permalink raw reply related
* [PATCH 3/5] [flexcan] Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, PPC list, Wolfgang Grandegger
In-Reply-To: <1312901031-29887-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
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-sJ/iWh9BUns@public.gmane.org>
To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.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 4/5] [powerpc] Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1312901031-29887-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
I added a simple clock source for the p1010rdb so the flexcan driver
could determine a clock frequency. The p1010 can device only has an
oscillator of system bus frequency divided by 2.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
arch/powerpc/platforms/85xx/Kconfig | 2 +
arch/powerpc/platforms/85xx/Makefile | 2 +
arch/powerpc/platforms/85xx/clock.c | 53 ++++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/p1010rdb.c | 8 +++++
4 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/clock.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 498534c..c4304ae 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -70,6 +70,8 @@ config MPC85xx_RDB
config P1010_RDB
bool "Freescale P1010RDB"
select DEFAULT_UIMAGE
+ select HAVE_CAN_FLEXCAN if NET && CAN
+ select PPC_CLOCK if CAN_FLEXCAN
help
This option enables support for the MPC85xx RDB (P1010 RDB) board
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index a971b32..cc7f381 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -3,6 +3,8 @@
#
obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_PPC_CLOCK) += clock.o
+
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
new file mode 100644
index 0000000..16fae04
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/clock.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2011 SGI, inc.
+ *
+ * This code is licensed for use under the GPL V2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/of.h>
+
+#include <asm/clk_interface.h>
+
+#include <sysdev/fsl_soc.h>
+
+/*
+ * p1010 needs to provide a clock source for the flexcan driver. The
+ * oscillator for the p1010 processor is only ever the system clock / 2.
+ */
+
+static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
+{
+ if (!dev)
+ return ERR_PTR(-ENOENT);
+
+ if (!dev->of_node ||
+ !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
+ return ERR_PTR(-ENOENT);
+
+ return NULL;
+}
+
+static void mpc85xx_clk_put(struct clk *clk)
+{
+ return;
+}
+
+static unsigned long mpc85xx_clk_get_rate(struct clk *clk)
+{
+ return fsl_get_sys_freq() / 2;
+}
+
+static struct clk_interface mpc85xx_clk_functions = {
+ .clk_get = mpc85xx_clk_get,
+ .clk_get_rate = mpc85xx_clk_get_rate,
+ .clk_put = mpc85xx_clk_put,
+};
+
+void __init mpc85xx_clk_init(void)
+{
+ clk_functions = mpc85xx_clk_functions;
+}
+
diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
index d7387fa..5e52122 100644
--- a/arch/powerpc/platforms/85xx/p1010rdb.c
+++ b/arch/powerpc/platforms/85xx/p1010rdb.c
@@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
}
+extern void mpc85xx_clk_init(void);
+
+static void __init p1010_rdb_init(void)
+{
+ mpc85xx_clk_init();
+}
+
static struct of_device_id __initdata p1010rdb_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
@@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
.name = "P1010 RDB",
.probe = p1010_rdb_probe,
.setup_arch = p1010_rdb_setup_arch,
+ .init = p1010_rdb_init,
.init_IRQ = p1010_rdb_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
--
1.7.2.1
^ permalink raw reply related
* [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-09 14:43 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger,
U Bhaskar-B22300
Cc: Robin Holt, socketcan-core, netdev, PPC list, Kumar Gala
In-Reply-To: <1312901031-29887-1-git-send-email-holt@sgi.com>
In working with the socketcan developers, we have come to the conclusion
the fsl-flexcan device tree bindings need to be cleaned up. The driver
does not depend upon any properties other than the required properties
so we are removing the file. Additionally, the p1010*dts files are not
following the standard for node naming in that they have a trailing -v1.0.
Signed-off-by: Robin Holt <holt@sgi.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
To: Wolfgang Grandegger <wg@grandegger.com>,
To: 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>
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
arch/powerpc/boot/dts/p1010si.dtsi | 6 +-
3 files changed, 2 insertions(+), 73 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
deleted file mode 100644
index 1a729f0..0000000
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-CAN Device Tree Bindings
-------------------------
-2011 Freescale Semiconductor, Inc.
-
-fsl,flexcan-v1.0 nodes
------------------------
-In addition to the required compatible-, reg- and interrupt-properties, you can
-also specify which clock source shall be used for the controller.
-
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
- (driven by the PLL) or the crystal oscillator clock. The selected clock
- is the one fed to the prescaler to generate the Serial Clock (Sclock).
- The PRESDIV field of CTRL(control register) controls a prescaler that
- generates the Serial Clock (Sclock), whose period defines the
- time quantum used to compose the CAN waveform.
-
-Can Engine Clock Source
- There are two sources for CAN clock
- - Platform Clock It represents the bus clock
- - Oscillator Clock
-
- Peripheral Clock (PLL)
- --------------
- |
- --------- -------------
- | |CPI Clock | Prescaler | Sclock
- | |---------------->| (1.. 256) |------------>
- --------- -------------
- | |
- -------------- ---------------------CLK_SRC
- Oscillator Clock
-
-- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
- the peripheral clock. PLL clock is fed to the
- prescaler to generate the Serial Clock (Sclock).
- Valid values are "oscillator" and "platform"
- "oscillator": CAN engine clock source is oscillator clock.
- "platform" The CAN engine clock source is the bus clock
- (platform clock).
-
-- fsl,flexcan-clock-divider : for the reference and system clock, an additional
- clock divider can be specified.
-- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
-
-Note:
- - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- - P1010 does not have oscillator as the Clock Source.So the default
- Clock Source is platform clock.
-Examples:
-
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
- reg = <0x1c000 0x1000>;
- interrupts = <48 0x2>;
- interrupt-parent = <&mpic>;
- fsl,flexcan-clock-source = "platform";
- fsl,flexcan-clock-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..d6a0bb2 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb.dts
@@ -169,14 +169,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..37e47cd 100644
--- a/arch/powerpc/boot/dts/p1010si.dtsi
+++ b/arch/powerpc/boot/dts/p1010si.dtsi
@@ -141,19 +141,17 @@
};
can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ compatible = "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
can1@1d000 {
- compatible = "fsl,flexcan-v1.0";
+ compatible = "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 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: U Bhaskar-B22300 @ 2011-08-09 14:45 UTC (permalink / raw)
To: Robin Holt, Marc Kleine-Budde, Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, PPC list
In-Reply-To: <1312892907-20419-5-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Hi Robin,
Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
Or the existing code of ARM based FlexCAN will work for P1010 ??
--Bhaskar
> -----Original Message-----
> From: Robin Holt [mailto:holt-sJ/iWh9BUns@public.gmane.org]
> Sent: Tuesday, August 09, 2011 5:58 PM
> To: Robin Holt; Marc Kleine-Budde; Wolfgang Grandegger; U Bhaskar-B22300
> Cc: Robin Holt; socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> PPC list
> Subject: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
>
> I added a simple clock source for the p1010rdb so the flexcan driver
> could determine a clock frequency. The p1010 can device only has an
> oscillator of system bus frequency divided by 2.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +
> arch/powerpc/platforms/85xx/Makefile | 2 +
> arch/powerpc/platforms/85xx/clock.c | 42
> ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/85xx/p1010rdb.c | 8 ++++++
> 4 files changed, 54 insertions(+), 0 deletions(-) create mode 100644
> arch/powerpc/platforms/85xx/clock.c
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile
> b/arch/powerpc/platforms/85xx/Makefile
> index a971b32..cc7f381 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -3,6 +3,8 @@
> #
> obj-$(CONFIG_SMP) += smp.o
>
> +obj-$(CONFIG_PPC_CLOCK) += clock.o
> +
> obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o diff --git
> a/arch/powerpc/platforms/85xx/clock.c
> b/arch/powerpc/platforms/85xx/clock.c
> new file mode 100644
> index 0000000..a6fd2c8
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/clock.c
> @@ -0,0 +1,42 @@
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +
> +#include <asm/clk_interface.h>
> +
> +#include <sysdev/fsl_soc.h>
> +
> +/*
> + * p1010 needs to provide a clock source for the flexcan driver. The
> + * oscillator for the p1010 processor is only ever the system clock / 2.
> + */
> +
> +static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
> +{
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> + return NULL;
> +}
> +
> +static void mpc85xx_clk_put(struct clk *clk) {
> + return;
> +}
> +
> +static unsigned long mpc85xx_clk_get_rate(struct clk *clk) {
> + return fsl_get_sys_freq() / 2;
> +}
> +
> +static struct clk_interface mpc85xx_clk_functions = {
> + .clk_get = mpc85xx_clk_get,
> + .clk_get_rate = mpc85xx_clk_get_rate,
> + .clk_put = mpc85xx_clk_put,
> +};
> +
> +void __init mpc85xx_clk_init(void)
> +{
> + clk_functions = mpc85xx_clk_functions; }
> +
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c
> b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d7387fa..5e52122 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +extern void mpc85xx_clk_init(void);
> +
> +static void __init p1010_rdb_init(void) {
> + mpc85xx_clk_init();
> +}
> +
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
> --
> 1.7.2.1
>
^ permalink raw reply
* Re: [PATCHv3 1/9] at91: provide macb clks with "pclk" and "hclk" name
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:49 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-2-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> The macb driver expects clocks with the names "pclk" and "hclk". We
> currently provide "macb_clk" but to fit in line with other
> architectures (namely AVR32), provide "pclk" and a fake "hclk".
>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
we now use clkdev
I'll send a updated version
Best Regards,
J.
^ permalink raw reply
* [PATCH 1/9 v4] at91: provide macb clks with "pclk" and "hclk" name
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:51 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: netdev, Jean-Christophe PLAGNIOL-VILLARD, Jamie Iles
In-Reply-To: <1312881411-2376-2-git-send-email-jamie@jamieiles.com>
From: Jamie Iles <jamie@jamieiles.com>
The macb driver expects clocks with the names "pclk" and "hclk". We
currently provide "macb_clk" but to fit in line with other
architectures (namely AVR32), provide "pclk" and a fake "hclk".
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
v4:
use clkdev
Best Regards,
J.
arch/arm/mach-at91/at91cap9.c | 4 +++-
arch/arm/mach-at91/at91sam9260.c | 4 +++-
arch/arm/mach-at91/at91sam9263.c | 4 +++-
arch/arm/mach-at91/at91sam9g45.c | 4 +++-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/at91cap9.c b/arch/arm/mach-at91/at91cap9.c
index bfc6844..a229c5c 100644
--- a/arch/arm/mach-at91/at91cap9.c
+++ b/arch/arm/mach-at91/at91cap9.c
@@ -137,7 +137,7 @@ static struct clk pwm_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91CAP9_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
@@ -210,6 +210,8 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ /* One additional fake clock for macb_hclk */
+ CLKDEV_CON_ID("hclk", &macb_clk),
CLKDEV_CON_DEV_ID("hclk", "atmel_usba_udc", &utmi_clk),
CLKDEV_CON_DEV_ID("pclk", "atmel_usba_udc", &udphs_clk),
CLKDEV_CON_DEV_ID("mci_clk", "at91_mci.0", &mmc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index cb397be..dc36479 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -120,7 +120,7 @@ static struct clk ohci_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9260_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
@@ -190,6 +190,8 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ /* One additional fake clock for macb_hclk */
+ CLKDEV_CON_ID("hclk", &macb_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.1", &spi1_clk),
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 044f3c9..43c144c 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -118,7 +118,7 @@ static struct clk pwm_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9263_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
@@ -182,6 +182,8 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ /* One additional fake clock for macb_hclk */
+ CLKDEV_CON_ID("hclk", &macb_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
CLKDEV_CON_DEV_ID("mci_clk", "at91_mci.0", &mmc0_clk),
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index e04c5fb..8abac30 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -144,7 +144,7 @@ static struct clk ac97_clk = {
.type = CLK_TYPE_PERIPHERAL,
};
static struct clk macb_clk = {
- .name = "macb_clk",
+ .name = "pclk",
.pmc_mask = 1 << AT91SAM9G45_ID_EMAC,
.type = CLK_TYPE_PERIPHERAL,
};
@@ -202,6 +202,8 @@ static struct clk *periph_clocks[] __initdata = {
};
static struct clk_lookup periph_clocks_lookups[] = {
+ /* One additional fake clock for macb_hclk */
+ CLKDEV_CON_ID("hclk", &macb_clk),
/* One additional fake clock for ohci */
CLKDEV_CON_ID("ohci_clk", &uhphs_clk),
CLKDEV_CON_DEV_ID("ehci_clk", "atmel-ehci", &uhphs_clk),
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCHv3 2/9] macb: remove conditional clk handling
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:52 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-3-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> AT91 now provides both "pclk" and "hclk" aliases for the the macb
> device so we can use the same clk handling paths for both AT91 and
> AVR32.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 3/9] macb: unify at91 and avr32 platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:53 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-4-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> Both at91 and avr32 defines its own platform data structure for
> the macb driver and both share common structures though at91
> includes a currently unused phy_irq_pin. Create a common
> macb_platform_data for macb that both at91 and avr32 can use. In
> future we can use this to support other architectures that use the
> same IP block with the macb driver.
>
> v2: rename eth_platform_data to macb_platform_data and allow at91_ether
> to share the platform data with macb.
not sure we need to keep this in the commit
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-09 14:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, therbert, netdev
In-Reply-To: <1312877173.2371.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Tue, 09 Aug 2011 10:06:13 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 09 août 2011 à 00:41 -0700, David Miller a écrit :
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 8 Aug 2011 11:19:17 -0700
> >
> > > On Mon, 8 Aug 2011 11:01:57 -0700
> > > Tom Herbert <therbert@google.com> wrote:
> > >
> > >> > Since transmit completion means calling dev_kfree_skb() why not account
> > >> > there? You could add some info to netdev if necessary to get compile
> > >> > the statistics.
> > >> >
> > >> The algorithm depends on knowing the total number of packets competed
> > >> in a single execution of transmit completion (epic based). We only
> > >> want to recalculate the limits once per completion, which happens when
> > >> the completion function is called.
> > >
> > > So just add some stats to netdev and count the number of dev_kfree_skb
> > > calls and do your work at napi complete.
> >
> > No, I think what Tom's doing here is reasonable.
> >
> > First off, drivers have never been required to do specific things if
> > they return success for ->ndo_start_xmit(). They can kfree_skb(skb)
> > and return NET_TX_SUCCESS, and that's fine.
> >
> > This mean we can't use ->ndo_start_xmit() return values to drive the
> > BQL engine.
> >
> > So we simply have a way for the driver to say when it really does
> > queue up a packet, and that might be useful for other things.
> >
> > Second, you absolutely do not want to run the BQL engine on every
> > single dev_kfree_skb() call. You want to batch it, and that's what
> > Tom's new interface does, and that is therefore quite reasonable
> > too.
> >
> > In fact, I think the best part about this revision of the BQL patches
> > is the device driver interface. :-)
> >
>
> I agree, it permits a smooth transition to selected drivers, even some
> non NAPI ones ;)
>
> In some stress situations, NAPI never completes, so it would also mean
> adding a dql call in this case...
Ok. then we need to fix all NAPI drivers at once, and get more
drivers converted over to NAPI. It is really annoying how there
is just too much variation among network drivers.
^ permalink raw reply
* Re: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-09 14:55 UTC (permalink / raw)
To: U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, PPC list, Wolfgang Grandegger
In-Reply-To: <9C64B7751C3BCA41B64A68E23005A7BE1C4A88-TcFNo7jSaXPiTqIcKZ1S2K4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>
On Tue, Aug 09, 2011 at 02:45:58PM +0000, U Bhaskar-B22300 wrote:
> Hi Robin,
> Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
> Or the existing code of ARM based FlexCAN will work for P1010 ??
It appears that the of_device stuff got moved under the struct device
and that allows the request_irq() to just magically work.
Robin
^ permalink raw reply
* Re: [PATCHv3 5/9] macb: initial support for Cadence GEM
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:55 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-6-git-send-email-jamie@jamieiles.com>
>
> MODULE_LICENSE("GPL");
> -MODULE_DESCRIPTION("Atmel MACB Ethernet driver");
> -MODULE_AUTHOR("Haavard Skinnemoen (Atmel)");
> +MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
> +MODULE_AUTHOR("Haavard Skinnemoen");
Haavard do it as a Atmel emloyee so please keep the (Atmel)
otherwise
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 6/9] macb: support higher rate GEM MDIO clock divisors
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:56 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-7-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM devices support larger clock divisors and have a different
> range of divisors. Program the MDIO clock divisors based on the
> device type.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 7/9] macb: support statistics for GEM devices
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:57 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-8-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM devices have a different number of statistics registers and they
> are at a different offset to MACB devices. Make the statistics
> collection method dependent on device type.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 8/9] macb: support DMA bus widths > 32 bits
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:57 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-9-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> Some GEM implementations may support DMA bus widths up to 128 bits. We
> can get the maximum supported DMA bus width from the design
> configuration register so use that to program the device up.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCHv3 9/9] macb: allow GEM to have configurable receive buffer size
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-08-09 14:59 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel
In-Reply-To: <1312881411-2376-10-git-send-email-jamie@jamieiles.com>
On 10:16 Tue 09 Aug , Jamie Iles wrote:
> GEM has configurable receive buffer sizes so requires this to be
> programmed up. Any size < 2048 and a multiple of 64 bytes is permitted.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 4/4] [powerpc] Add flexcan device support for p1010rdb.
From: Wolfgang Grandegger @ 2011-08-09 15:10 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, U Bhaskar-B22300, PPC list,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110809145507.GY4926-sJ/iWh9BUns@public.gmane.org>
On 08/09/2011 04:55 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:45:58PM +0000, U Bhaskar-B22300 wrote:
>> Hi Robin,
>> Where are you doing the irq handling ie request_irq() for the powerpc based P1010.
>> Or the existing code of ARM based FlexCAN will work for P1010 ??
>
> It appears that the of_device stuff got moved under the struct device
> and that allows the request_irq() to just magically work.
Cool! Actually I was also missing of_address_to_resource (or of_iomap)
and irq_of_parse_and_map(). But the resources seem to be filled in here:
http://lxr.linux.no/#linux+v3.0.1/drivers/of/platform.c#L121
Wolfgang.
^ 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