* Re: [PATCH] powerpc: Add write barrier before enabling DTL flags
From: Michael Ellerman @ 2009-03-25 0:44 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <200903241659.55302.jk@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Tue, 2009-03-24 at 16:59 +1100, Jeremy Kerr wrote:
> Michael,
>
> > Wouldn't this still be a problem on a UP kernel?
>
> I don't believe so - stores should be ordered with respect to the
> current CPU, and in the UP case we still get a barrier().
But what if the CPU decides to do the store to the enable_mask before
the stores to the other fields?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: Joakim Tjernlund @ 2009-03-24 23:35 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090324.162913.226453070.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 25/03/2009 00:29:13:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Wed, 25 Mar 2009 00:08:53 +0100
>
> > David Miller <davem@davemloft.net> wrote on 24/03/2009 23:49:02:
> > >
> > > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > > Date: Tue, 24 Mar 2009 23:45:13 +0100
> > >
> > > > I don't follow. Are these mandatory now? They were not in the old
> > > > impl. either.
> > >
> > > See ether_setup() which is called indirectly via alloc_etherdev().
> > >
> > > Yawn...
> >
> > Same here, getting tiered. Should have seen that. Here goes,
> > attatched as well as explained earlier.
>
> I'll apply this, thanks.
Thanks.
>
> Please provide a proper "Signed-off-by:" line with future
> patch submissions, thanks.
Yep, getting tiered ...
Hopefully I will have something more coming your way the next few days.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: David Miller @ 2009-03-24 23:29 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <OF4B79F4DE.4DC6DEA7-ONC1257583.007ECBEA-C1257583.007F2805@transmode.se>
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Wed, 25 Mar 2009 00:08:53 +0100
> David Miller <davem@davemloft.net> wrote on 24/03/2009 23:49:02:
> >
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Tue, 24 Mar 2009 23:45:13 +0100
> >
> > > I don't follow. Are these mandatory now? They were not in the old
> > > impl. either.
> >
> > See ether_setup() which is called indirectly via alloc_etherdev().
> >
> > Yawn...
>
> Same here, getting tiered. Should have seen that. Here goes,
> attatched as well as explained earlier.
I'll apply this, thanks.
Please provide a proper "Signed-off-by:" line with future
patch submissions, thanks.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: Joakim Tjernlund @ 2009-03-24 23:08 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090324.154902.206324978.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
David Miller <davem@davemloft.net> wrote on 24/03/2009 23:49:02:
>
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 24 Mar 2009 23:45:13 +0100
>
> > I don't follow. Are these mandatory now? They were not in the old
> > impl. either.
>
> See ether_setup() which is called indirectly via alloc_etherdev().
>
> Yawn...
Same here, getting tiered. Should have seen that. Here goes,
attatched as well as explained earlier.
Jocke
>From 651fcd7d1ba494f2e2f20da51196b1b3dccdcd68 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Fri, 20 Mar 2009 21:09:14 +0100
Subject: [PATCH] ucc_geth: Convert to net_device_ops
---
drivers/net/ucc_geth.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 7716239..097aed8 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3501,6 +3501,20 @@ static phy_interface_t to_phy_interface(const char
*phy_connection_type)
return PHY_INTERFACE_MODE_MII;
}
+static const struct net_device_ops ucc_geth_netdev_ops = {
+ .ndo_open = ucc_geth_open,
+ .ndo_stop = ucc_geth_close,
+ .ndo_start_xmit = ucc_geth_start_xmit,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_set_multicast_list = ucc_geth_set_multi,
+ .ndo_tx_timeout = ucc_geth_timeout,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = ucc_netpoll,
+#endif
+};
+
static int ucc_geth_probe(struct of_device* ofdev, const struct
of_device_id *match)
{
struct device *device = &ofdev->dev;
@@ -3716,19 +3730,11 @@ static int ucc_geth_probe(struct of_device* ofdev,
const struct of_device_id *ma
/* Fill in the dev structure */
uec_set_ethtool_ops(dev);
- dev->open = ucc_geth_open;
- dev->hard_start_xmit = ucc_geth_start_xmit;
- dev->tx_timeout = ucc_geth_timeout;
+ dev->netdev_ops = &ucc_geth_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
INIT_WORK(&ugeth->timeout_work, ucc_geth_timeout_work);
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll,
UCC_GETH_DEV_WEIGHT);
-#ifdef CONFIG_NET_POLL_CONTROLLER
- dev->poll_controller = ucc_netpoll;
-#endif
- dev->stop = ucc_geth_close;
-// dev->change_mtu = ucc_geth_change_mtu;
dev->mtu = 1500;
- dev->set_multicast_list = ucc_geth_set_multi;
ugeth->msg_enable = netif_msg_init(debug.msg_enable,
UGETH_MSG_DEFAULT);
ugeth->phy_interface = phy_interface;
--
1.6.1.3
[-- Attachment #2: 0001-ucc_geth-Convert-to-net_device_ops.patch --]
[-- Type: application/octet-stream, Size: 2041 bytes --]
From 651fcd7d1ba494f2e2f20da51196b1b3dccdcd68 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Fri, 20 Mar 2009 21:09:14 +0100
Subject: [PATCH] ucc_geth: Convert to net_device_ops
---
drivers/net/ucc_geth.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 7716239..097aed8 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3501,6 +3501,20 @@ static phy_interface_t to_phy_interface(const char *phy_connection_type)
return PHY_INTERFACE_MODE_MII;
}
+static const struct net_device_ops ucc_geth_netdev_ops = {
+ .ndo_open = ucc_geth_open,
+ .ndo_stop = ucc_geth_close,
+ .ndo_start_xmit = ucc_geth_start_xmit,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = eth_mac_addr,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_set_multicast_list = ucc_geth_set_multi,
+ .ndo_tx_timeout = ucc_geth_timeout,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = ucc_netpoll,
+#endif
+};
+
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
struct device *device = &ofdev->dev;
@@ -3716,19 +3730,11 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
/* Fill in the dev structure */
uec_set_ethtool_ops(dev);
- dev->open = ucc_geth_open;
- dev->hard_start_xmit = ucc_geth_start_xmit;
- dev->tx_timeout = ucc_geth_timeout;
+ dev->netdev_ops = &ucc_geth_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
INIT_WORK(&ugeth->timeout_work, ucc_geth_timeout_work);
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
-#ifdef CONFIG_NET_POLL_CONTROLLER
- dev->poll_controller = ucc_netpoll;
-#endif
- dev->stop = ucc_geth_close;
-// dev->change_mtu = ucc_geth_change_mtu;
dev->mtu = 1500;
- dev->set_multicast_list = ucc_geth_set_multi;
ugeth->msg_enable = netif_msg_init(debug.msg_enable, UGETH_MSG_DEFAULT);
ugeth->phy_interface = phy_interface;
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH] powerpc/wdrtas: Update wdrtas_get_interval to use rtas_data_buf
From: Mark Nelson @ 2009-03-24 22:53 UTC (permalink / raw)
To: Utz Bacher; +Cc: linuxppc-dev
In-Reply-To: <OF2EBA91DF.87037392-ONC1257583.004A2432-C1257583.004FC7A9@de.ibm.com>
On Wed, 25 Mar 2009 01:31:32 am Utz Bacher wrote:
> Adrian Reber <adrian@lisas.de> wrote on 24.03.2009 13:31:31:
> > On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> > > The buffer passed to the ibm,get-system-parameter RTAS call must be
> > > in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
> > > for the actual RTAS call and then copy the result to value. We can't
> > > just make it static because this can be compiled in as a module.
> > >
> > > Also add the WDRTAS_SP_SPI_LEN so we don't litter '4' throughout the
> > > function.
> > >
> > > Signed-off-by: Mark Nelson <markn@au1.ibm.com>
> > > ---
> > >
> > > Adrian, does this patch cause any problems for your pxcabs?
> >
> > No, it even helps. I have no tried the watchdog until now, but without
> the
> > patch I get:
> >
> > wdrtas: could not get sp_spi watchdog timeout (0). Continuing
> >
> > and with the patch it reads the correct value. So only with your patch
> > it works like it is supposed to. Thanks!
> >
> > Tested-by: Adrian Reber <adrian@lisas.de>
>
> looks good to me.
>
> Acked-by: Utz Bacher <utz.bacher@de.ibm.com>
Thanks for looking over it!
Mark
^ permalink raw reply
* Re: [PATCH] powerpc/wdrtas: Update wdrtas_get_interval to use rtas_data_buf
From: Mark Nelson @ 2009-03-24 22:51 UTC (permalink / raw)
To: Adrian Reber; +Cc: linuxppc-dev, Utz Bacher
In-Reply-To: <20090324123131.GC24724@lisas.de>
On Tue, 24 Mar 2009 11:31:31 pm Adrian Reber wrote:
> On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> > The buffer passed to the ibm,get-system-parameter RTAS call must be
> > in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
> > for the actual RTAS call and then copy the result to value. We can't
> > just make it static because this can be compiled in as a module.
> >
> > Also add the WDRTAS_SP_SPI_LEN so we don't litter '4' throughout the
> > function.
> >
> > Signed-off-by: Mark Nelson <markn@au1.ibm.com>
> > ---
> >
> > Adrian, does this patch cause any problems for your pxcabs?
>
> No, it even helps. I have no tried the watchdog until now, but without the
> patch I get:
>
> wdrtas: could not get sp_spi watchdog timeout (0). Continuing
>
> and with the patch it reads the correct value. So only with your patch
> it works like it is supposed to. Thanks!
>
> Tested-by: Adrian Reber <adrian@lisas.de>
Good to hear
Thanks for testing!
Mark
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: David Miller @ 2009-03-24 22:49 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <OF603BDF0B.B740DD77-ONC1257583.007CAD9B-C1257583.007CFD35@transmode.se>
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 24 Mar 2009 23:45:13 +0100
> I don't follow. Are these mandatory now? They were not in the old
> impl. either.
See ether_setup() which is called indirectly via alloc_etherdev().
Yawn...
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: Joakim Tjernlund @ 2009-03-24 22:45 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <20090324.142209.234280606.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 24/03/2009 22:22:09:
>
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 24 Mar 2009 11:37:11 +0100
>
> > David Miller <davem@davemloft.net> wrote on 23/03/2009 19:49:28:
> > >
> > > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > > Date: Mon, 23 Mar 2009 11:17:39 +0100
> > >
> > > > Sorry for the WS damaged patch, but my current company mailer
cannot
> > > > handle inline patches. Due to this we are setting up a new mail
system
> > > > but it will be a few days before this is ready.
> > > > Therefore I am attaching this patch as well, use that one
> > > > to apply instaed of the inline variant.
> > >
> > > This patch has other problems, anyways.
> > >
> > > > +#if 0
> > > > +/* not yet */
> > > > + .ndo_set_mac_address = ucc_geth_set_mac_address,
> > > > + .ndo_change_mtu = ucc_geth_change_mtu,
> > > > + .ndo_do_ioctl = ucc_geth_do_ioctl,
> > > > +#endif
> > >
> > > Don't do stuff like this, please. Even the code you are
> > > copying from doesn't have the set_mac_address method
> > > assignment proceted by #if 0 stuff.
> > >
> > > Just get rid of all the unused stuff completely.
> >
> > OK, here is a new version. The #if 0 ..#endif has been removed.
>
> Missing ".ndo_set_mac_address = eth_set_mac_address," and
> also ".ndo_change_mtu = eth_change_mtu".
I don't follow. Are these mandatory now? They were not in the old
impl. either.
>
> Also please inline your patches so that people can quote them in
> replies.
I know, but my mail system is screwing up WS ATM so I can't. Working
on it though.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Convert to net_device_ops
From: David Miller @ 2009-03-24 21:22 UTC (permalink / raw)
To: Joakim.Tjernlund; +Cc: linuxppc-dev, leoli, netdev
In-Reply-To: <OFA0B803BB.DEC93B9A-ONC1257583.0039CF3E-C1257583.003A55BA@transmode.se>
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 24 Mar 2009 11:37:11 +0100
> David Miller <davem@davemloft.net> wrote on 23/03/2009 19:49:28:
> >
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Mon, 23 Mar 2009 11:17:39 +0100
> >
> > > Sorry for the WS damaged patch, but my current company mailer cannot
> > > handle inline patches. Due to this we are setting up a new mail system
> > > but it will be a few days before this is ready.
> > > Therefore I am attaching this patch as well, use that one
> > > to apply instaed of the inline variant.
> >
> > This patch has other problems, anyways.
> >
> > > +#if 0
> > > +/* not yet */
> > > + .ndo_set_mac_address = ucc_geth_set_mac_address,
> > > + .ndo_change_mtu = ucc_geth_change_mtu,
> > > + .ndo_do_ioctl = ucc_geth_do_ioctl,
> > > +#endif
> >
> > Don't do stuff like this, please. Even the code you are
> > copying from doesn't have the set_mac_address method
> > assignment proceted by #if 0 stuff.
> >
> > Just get rid of all the unused stuff completely.
>
> OK, here is a new version. The #if 0 ..#endif has been removed.
Missing ".ndo_set_mac_address = eth_set_mac_address," and
also ".ndo_change_mtu = eth_change_mtu".
Also please inline your patches so that people can quote them in
replies.
^ permalink raw reply
* Re: PCIe interrupts in the device tree
From: Johns Daniel @ 2009-03-24 21:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <651BE815-4BF6-4AA3-AA43-C0B7C98A0FCC@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
On Tue, Mar 24, 2009 at 3:54 PM, Kumar Gala <galak@kernel.crashing.org>wrote:
>
> On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
>
> Could somebody please explain the declaration of the PCIe interrupts
>> in the device tree?
>>
>> I was under the impression that PCIe interrupts in the PowerPC Linux
>> kernel default to using INTx signaling (vs. external IRQ pin assertion
>> and MSI signaling). Am I right?
>>
>> If so, then do the interrupt-map lines in the DTS refer to the
>> internal IRQ used by Freescale processors to implement INTx virtual
>> wire interrupts?
>>
>> For example, in the mpc8536ds.dts file, under "pci1: pcie@ffe09000" we
>> have:
>> interrupt-map = <
>> /* IDSEL 0x0 */
>> 0000 0 0 1 &mpic 4 1
>> 0000 0 0 2 &mpic 5 1
>> 0000 0 0 3 &mpic 6 1
>> 0000 0 0 4 &mpic 7 1
>> >;
>> Are the 4, 5, 6, and 7 internal or external IRQs?
>>
>
> The .dts and linux make no distinction between internal & external IRQs.
> This is a silly artifact of Freescale UMs. IRQ 0 starts at offset 0x50000
> and each 0x20 offset is another IRQ. So typically External 0 == IRQ0,
> Internal 0 == IRQ16.
>
> So this says that Ext 4, 5, 6, 7 and wired to INTA, INTB, INTC, INTD for
> this particular PCIe controller.
>
When you say "wired", do you mean hard-wired?
If so, how would you specify and use INTx message interrupts?
>
>
> And the "msi@41600" section in the same mpc8536ds.dts file does NOT
>> affect PCIe interrupts unless a driver calls pci_enable_msi()?
>>
>
> correct.
>
> - k
>
[-- Attachment #2: Type: text/html, Size: 2603 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix RTAS watchdog driver temperature read functionality
From: Benjamin Herrenschmidt @ 2009-03-24 21:00 UTC (permalink / raw)
To: Adrian Reber; +Cc: linuxppc-dev
In-Reply-To: <20090324114505.GB24724@lisas.de>
On Tue, 2009-03-24 at 12:45 +0100, Adrian Reber wrote:
> On Tue, Mar 24, 2009 at 03:27:18PM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-03-16 at 13:35 +0100, Adrian Reber wrote:
> > > Using the RTAS watchdog driver to read out the temperature crashes
> > > on a PXCAB:
> > >
> > > Unable to handle kernel paging request for data at address 0xfe347b50
> > > Faulting instruction address: 0xc00000000001af64
> > > Oops: Kernel access of bad area, sig: 11 [#1]
> > >
> > > This (removing "(void *)__pa") fixes it.
> >
> > Looks correct, but why not use rtas_get_sensor() instead ? (Exported by
> > arch/powerpc/kernel/rtas.c
>
> Ah, you mean something like?
Right, now turn it into a proper patch submission :-)
Cheers,
Ben.
> drivers/watchdog/wdrtas.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
> index 5d3b1a8..af2bbfa 100644
> --- a/drivers/watchdog/wdrtas.c
> +++ b/drivers/watchdog/wdrtas.c
> @@ -214,16 +214,14 @@ static void wdrtas_timer_keepalive(void)
> */
> static int wdrtas_get_temperature(void)
> {
> - long result;
> + int result;
> int temperature = 0;
>
> - result = rtas_call(wdrtas_token_get_sensor_state, 2, 2,
> - (void *)__pa(&temperature),
> - WDRTAS_THERMAL_SENSOR, 0);
> + result = rtas_get_sensor(WDRTAS_THERMAL_SENSOR, 0, &temperature);
>
> if (result < 0)
> printk(KERN_WARNING "wdrtas: reading the thermal sensor "
> - "faild: %li\n", result);
> + "faild: %i\n", result);
> else
> temperature = ((temperature * 9) / 5) + 32; /* fahrenheit */
>
> Adrian
^ permalink raw reply
* Re: PCIe interrupts in the device tree
From: Kumar Gala @ 2009-03-24 20:54 UTC (permalink / raw)
To: Johns Daniel; +Cc: linuxppc-dev
In-Reply-To: <ba5d9360903241324n57aa74caq2dd2bcdd2a885e19@mail.gmail.com>
On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
> Could somebody please explain the declaration of the PCIe interrupts
> in the device tree?
>
> I was under the impression that PCIe interrupts in the PowerPC Linux
> kernel default to using INTx signaling (vs. external IRQ pin assertion
> and MSI signaling). Am I right?
>
> If so, then do the interrupt-map lines in the DTS refer to the
> internal IRQ used by Freescale processors to implement INTx virtual
> wire interrupts?
>
> For example, in the mpc8536ds.dts file, under "pci1: pcie@ffe09000"
> we have:
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0 0 1 &mpic 4 1
> 0000 0 0 2 &mpic 5 1
> 0000 0 0 3 &mpic 6 1
> 0000 0 0 4 &mpic 7 1
> >;
> Are the 4, 5, 6, and 7 internal or external IRQs?
The .dts and linux make no distinction between internal & external
IRQs. This is a silly artifact of Freescale UMs. IRQ 0 starts at
offset 0x50000 and each 0x20 offset is another IRQ. So typically
External 0 == IRQ0, Internal 0 == IRQ16.
So this says that Ext 4, 5, 6, 7 and wired to INTA, INTB, INTC, INTD
for this particular PCIe controller.
> And the "msi@41600" section in the same mpc8536ds.dts file does NOT
> affect PCIe interrupts unless a driver calls pci_enable_msi()?
correct.
- k
^ permalink raw reply
* PCIe interrupts in the device tree
From: Johns Daniel @ 2009-03-24 20:24 UTC (permalink / raw)
To: linuxppc-dev
Could somebody please explain the declaration of the PCIe interrupts
in the device tree?
I was under the impression that PCIe interrupts in the PowerPC Linux
kernel default to using INTx signaling (vs. external IRQ pin assertion
and MSI signaling). Am I right?
If so, then do the interrupt-map lines in the DTS refer to the
internal IRQ used by Freescale processors to implement INTx virtual
wire interrupts?
For example, in the mpc8536ds.dts file, under "pci1: pcie@ffe09000" we have:
interrupt-map = <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 4 1
0000 0 0 2 &mpic 5 1
0000 0 0 3 &mpic 6 1
0000 0 0 4 &mpic 7 1
>;
Are the 4, 5, 6, and 7 internal or external IRQs?
And the "msi@41600" section in the same mpc8536ds.dts file does NOT
affect PCIe interrupts unless a driver calls pci_enable_msi()?
TIA!
-- Johns
^ permalink raw reply
* Re: [PATCH] ucc_geth: Fix build breakage caused by a merge
From: David Miller @ 2009-03-24 19:07 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, afleming, Joakim.Tjernlund, netdev
In-Reply-To: <20090324153734.GA8276@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue, 24 Mar 2009 18:37:34 +0300
> This patch fixes following build error:
>
> CC ucc_geth.o
> ucc_geth.c: In function 'ucc_geth_probe':
> ucc_geth.c:3644: error: implicit declaration of function 'uec_mdio_bus_name'
> make[2]: *** [ucc_geth.o] Error 1
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks Anton.
^ permalink raw reply
* Re: [PATCH v2 4/5] powerpc: NAND: FSL UPM: document new bindings
From: Wolfgang Grandegger @ 2009-03-24 18:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20090319170530.GA2744@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> On Thu, Mar 19, 2009 at 04:16:07PM +0100, Wolfgang Grandegger wrote:
>> +Optional properties:
>> +- fsl,upm-mar-offset : use the UPM machine address register to drive a
>> + custom chip select logic using the specified
>> + offset.
>
> Your example uses the name fsl,upm-mar-chip-offset instead.
I need to fix the documentation then.
>> +- chip-offset : address offset between chips for multi-chip support.
>
> How is this different from fsl,upm-mar-offset?
Well, after a closer look, it's the same, hardware-wise. The offset sets
the corresponding address lines, which are used to select the chip. As
it is currently, "chip-offset" is used for:
chip->IO_ADDR_R = chip->IO_ADDR_W =
fun->upm.io_addr + fun->chip_offset * chip_nr;
and "upm-mar-chip-offset" to set the address lines through the MAR
register when running the command or address patterns:
mar += fun->upm_mar_chip_offset * fun->chip_nr;
I'm going to remove "upm_mar_chip_offset" and use "chip_offset" instead,
also for the U-Boot version. Thanks for pointing that out.
Wolfgang.
^ permalink raw reply
* [PATCH v2 2/2] powerpc/5200: add LocalPlus bus FIFO device driver
From: Grant Likely @ 2009-03-24 18:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jean-philippe.jacquemin
In-Reply-To: <20090324180248.31372.22557.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This is a driver for the LocalPlus bus FIFO device
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/mpc52xx.h | 11 +
arch/powerpc/platforms/52xx/Kconfig | 4
arch/powerpc/platforms/52xx/Makefile | 1
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 285 +++++++++++++++++++++++++
4 files changed, 301 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
index 9eac3d9..ded652a 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -283,6 +283,17 @@ extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
int continuous);
extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+/* mpc52xx_lpbfifo.c */
+extern int mpc52xx_lpbfifo_write(void *src, unsigned int cs,
+ size_t offset, size_t size, int flags,
+ void (*callback)(void *, size_t, int),
+ void *callback_data);
+extern int mpc52xx_lpbfifo_read(void *dest, unsigned int cs,
+ size_t offset, size_t size, int flags,
+ void (*callback)(void *, size_t, int),
+ void *callback_data);
+extern void mpc52xx_lpbfifo_abort(void *callback_data);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 75f82ab..ba1348e 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -62,3 +62,7 @@ config PPC_MPC5200_GPIO
select GENERIC_GPIO
help
Enable gpiolib support for mpc5200 based boards
+
+config PPC_MPC5200_LPBFIFO
+ tristate "MPC5200 LocalPlus bus FIFO driver"
+ depends on PPC_MPC52xx
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index bfd4f52..2bc8cd0 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -15,3 +15,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
endif
obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
+obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
new file mode 100644
index 0000000..0d51515
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -0,0 +1,285 @@
+/*
+ * LocalPlus Bus FIFO driver for the Freescale MPC52xx.
+ *
+ * Copyright (C) 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is released under the GPLv2
+ *
+ * Todo:
+ * - Implement mpc52xx_lpbfifo_write
+ * - Add Bestcomm DMA support
+ * - Add support for multiple requests to be queued.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/spinlock.h>
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/mpc52xx.h>
+
+MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
+MODULE_DESCRIPTION("MPC5200 LocalPlus FIFO device driver");
+MODULE_LICENSE("GPL");
+
+#define LPBFIFO_REG_PACKET_SIZE (0x00)
+#define LPBFIFO_REG_START_ADDRESS (0x04)
+#define LPBFIFO_REG_CONTROL (0x08)
+#define LPBFIFO_REG_ENABLE (0x0C)
+#define LPBFIFO_REG_BYTES_DONE_STATUS (0x14)
+#define LPBFIFO_REG_FIFO_DATA (0x40)
+#define LPBFIFO_REG_FIFO_STATUS (0x44)
+#define LPBFIFO_REG_FIFO_CONTROL (0x48)
+#define LPBFIFO_REG_FIFO_ALARM (0x4C)
+
+struct mpc52xx_lpbfifo {
+ struct device *dev;
+ void __iomem *regs;
+ int irq;
+ spinlock_t lock;
+
+ /* Current transfer data */
+ void *data;
+ int cs;
+ size_t offset;
+ size_t size;
+ size_t remaining;
+ void (*callback)(void *, size_t, int);
+ void *callback_data;
+};
+
+/* The MPC5200 has only one fifo, so only need one instance structure */
+static struct mpc52xx_lpbfifo lpbfifo;
+
+/**
+ * mpc52xx_lpbfifo_kick - Trigger the next block of data to be transfered
+ */
+static void mpc52xx_lpbfifo_kick(void)
+{
+ size_t transfer_size = lpbfifo.remaining;
+
+ /* While the FIFO can be setup for transfer sizes as large as 16M-1,
+ * the FIFO itself is only 512 bytes deep and it does not generate
+ * interrupts for FIFO full events (only transfer complete will
+ * raise an IRQ). Therefore when not using Bestcomm to drive the
+ * FIFO it needs to either be polled, or transfers need to constrained
+ * to the size of the fifo.
+ *
+ * Here we choose to restrict the size of the transfer
+ */
+ if (transfer_size > 512)
+ transfer_size = 512;
+
+ /* Set and clear the reset bits; is good practice in User Manual */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x00000301);
+
+ /* Set transfer size, width, chip select and READ mode */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_START_ADDRESS, lpbfifo.offset);
+ out_be32(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, transfer_size);
+ out_be32(lpbfifo.regs + LPBFIFO_REG_CONTROL,
+ lpbfifo.cs << 24 | 0x00010008);
+
+ /* Kick it off */
+ out_8(lpbfifo.regs + LPBFIFO_REG_PACKET_SIZE, 0x01);
+}
+
+/**
+ * mpc52xx_lpbfifo_irq - IRQ handler for LPB FIFO
+ */
+static irqreturn_t mpc52xx_lpbfifo_irq(int irq, void *dev_id)
+{
+ u8 status = in_8(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS);
+ u32 *data;
+ int count, i;
+ void (*callback)(void *, size_t, int);
+ void *callback_data;
+
+ spin_lock(&lpbfifo.lock);
+
+ if (status & 0x10) { /* check abort bit */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ } else if (status & 0x01) { /* check transaction done bit */
+ /* Read result from hardware */
+ count = in_be32(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS);
+ count &= 0x00ffffff;
+
+ data = lpbfifo.data;
+ for (i = 0; i < count; i += 4)
+ *data++ = in_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_DATA);
+
+ /* Update transfer position and count */
+ lpbfifo.remaining -= count;
+ lpbfifo.offset += count;
+ lpbfifo.data += count;
+
+ /* Clear the IRQ */
+ out_8(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS, 0x01);
+
+ if (lpbfifo.remaining) {
+ /* More work to do. Kick of the next block and exit */
+ mpc52xx_lpbfifo_kick();
+ spin_unlock(&lpbfifo.lock);
+ return IRQ_HANDLED;
+ }
+ }
+
+ /* Mark the FIFO as idle */
+ lpbfifo.data = NULL;
+ callback = lpbfifo.callback;
+ callback_data = lpbfifo.callback_data;
+ count = lpbfifo.size - lpbfifo.remaining;
+
+ /* Release the lock before calling out to the callback. */
+ spin_unlock(&lpbfifo.lock);
+
+ /* If control reaches this point then the transfer is finished,
+ * either normal completion or due to abort */
+ callback(callback_data, count, (status & 0x10) != 0);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * mpc52xx_lpbfifo_read - Initiate an LPB fifo READ transaction
+ * @data: location to copy data into
+ * @cs: LocalPlus bus chip select number for transfer
+ * @offset: Location of data to read as an offset from the CS base address
+ * @size: Size of transfer in bytes
+ * @callback: Callback function for FIFO events. Will be called when the
+ * FIFO high watermark is reached, when the transfer finishes,
+ * and if a FIFO error occurs.
+ * @data: Private data pointer to be passed to callback function.
+ */
+int mpc52xx_lpbfifo_read(void *dest, unsigned int cs,
+ size_t offset, size_t size, int mode_flags,
+ void (*callback)(void *, size_t, int),
+ void *callback_data)
+{
+ int rc = -EBUSY;
+ unsigned long flags;
+
+ if (!lpbfifo.regs)
+ return -ENODEV;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+ /* If the data pointer is already set then a transfer is in progress */
+ if (lpbfifo.data)
+ goto out;
+
+ /* Setup the transfer */
+ lpbfifo.data = dest;
+ lpbfifo.cs = cs;
+ lpbfifo.offset = offset;
+ lpbfifo.remaining = lpbfifo.size = size;
+ lpbfifo.callback = callback;
+ lpbfifo.callback_data = callback_data;
+
+ mpc52xx_lpbfifo_kick();
+ rc = 0;
+
+ out:
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+ return rc;
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_read);
+
+void mpc52xx_lpbfifo_abort(void *callback_data)
+{
+ unsigned long flags;
+
+ if (lpbfifo.callback_data != callback_data)
+ return;
+
+ spin_lock_irqsave(&lpbfifo.lock, flags);
+ /* Put it into reset and clear the state */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ lpbfifo.data = NULL;
+ spin_unlock_irqrestore(&lpbfifo.lock, flags);
+}
+EXPORT_SYMBOL(mpc52xx_lpbfifo_abort);
+
+static int __devinit
+mpc52xx_lpbfifo_probe(struct of_device *op, const struct of_device_id *match)
+{
+ int rc;
+
+ if (lpbfifo.dev != NULL)
+ return -ENOSPC;
+
+ lpbfifo.regs = of_iomap(op->node, 0);
+ if (!lpbfifo.regs)
+ return -ENOMEM;
+
+ lpbfifo.irq = irq_of_parse_and_map(op->node, 0);
+ if (!lpbfifo.irq) {
+ lpbfifo.regs = NULL;
+ iounmap(lpbfifo.regs);
+ return -ENOMEM;
+ }
+
+ spin_lock_init(&lpbfifo.lock);
+
+ /* Put FIFO into reset */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+
+ /* Register the interrupt handler */
+ rc = request_irq(lpbfifo.irq, mpc52xx_lpbfifo_irq, 0,
+ "mpc52xx-lpbfifo", &lpbfifo);
+ if (rc) {
+ pr_err("request_irq() failed. rc=%i\n", rc);
+ lpbfifo.regs = NULL;
+ free_irq(lpbfifo.irq, &lpbfifo);
+ iounmap(lpbfifo.regs);
+ }
+
+ lpbfifo.dev = &op->dev;
+ pr_info("LPB FIFO ready; regs=%p irq=%i\n", lpbfifo.regs, lpbfifo.irq);
+ return 0;
+}
+
+
+static int __devexit mpc52xx_lpbfifo_remove(struct of_device *op)
+{
+ if (lpbfifo.dev == &op->dev) {
+ /* Put FIFO in reset */
+ out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x01010000);
+ lpbfifo.regs = NULL;
+ free_irq(lpbfifo.irq, &lpbfifo);
+ iounmap(lpbfifo.regs);
+ lpbfifo.dev = NULL;
+ }
+ return 0;
+}
+
+static struct of_device_id mpc52xx_lpbfifo_match[] __devinitdata = {
+ { .compatible = "fsl,mpc5200-lpbfifo", },
+ {},
+};
+
+static struct of_platform_driver mpc52xx_lpbfifo_driver = {
+ .owner = THIS_MODULE,
+ .name = "mpc52xx-lpbfifo",
+ .match_table = mpc52xx_lpbfifo_match,
+ .probe = mpc52xx_lpbfifo_probe,
+ .remove = __devexit_p(mpc52xx_lpbfifo_remove),
+};
+
+/***********************************************************************
+ * Module init/exit
+ */
+static int __init mpc52xx_lpbfifo_init(void)
+{
+ pr_debug("Registering LocalPlus bus FIFO driver\n");
+ return of_register_platform_driver(&mpc52xx_lpbfifo_driver);
+}
+module_init(mpc52xx_lpbfifo_init);
+
+static void __exit mpc52xx_lpbfifo_exit(void)
+{
+ pr_debug("Unregistering LocalPlus bus FIFO driver\n");
+ of_unregister_platform_driver(&mpc52xx_lpbfifo_driver);
+}
+module_exit(mpc52xx_lpbfifo_exit);
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/5200: add general purpose timer API for the MPC5200
From: Grant Likely @ 2009-03-24 18:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jean-philippe.jacquemin
In-Reply-To: <20090324180248.31372.22557.stgit@localhost.localdomain>
From: Grant Likely <grant.likely@secretlab.ca>
This patch adds an interface for controlling the timer function of the
MPC5200 GPT devices.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/include/asm/mpc52xx.h | 7 ++
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 133 +++++++++++++++++++++++++++--
2 files changed, 130 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
index 52e049c..9eac3d9 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -276,6 +276,13 @@ extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
extern void mpc52xx_restart(char *cmd);
+/* mpc52xx_gpt.c */
+struct mpc52xx_gpt_priv;
+extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
+extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
+ int continuous);
+extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index bfbcd41..c702e70 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -46,13 +46,17 @@
* the output mode. This driver does not change the output mode setting.
*/
+#include <linux/device.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/of_gpio.h>
#include <linux/kernel.h>
+#include <asm/div64.h>
#include <asm/mpc52xx.h>
MODULE_DESCRIPTION("Freescale MPC52xx gpt driver");
@@ -68,16 +72,21 @@ MODULE_LICENSE("GPL");
* @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
*/
struct mpc52xx_gpt_priv {
+ struct list_head list; /* List of all GPT devices */
struct device *dev;
struct mpc52xx_gpt __iomem *regs;
spinlock_t lock;
struct irq_host *irqhost;
+ u32 ipb_freq;
#if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
#endif
};
+LIST_HEAD(mpc52xx_gpt_list);
+DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
+
#define MPC52xx_GPT_MODE_MS_MASK (0x07)
#define MPC52xx_GPT_MODE_MS_IC (0x01)
#define MPC52xx_GPT_MODE_MS_OC (0x02)
@@ -88,6 +97,9 @@ struct mpc52xx_gpt_priv {
#define MPC52xx_GPT_MODE_GPIO_OUT_LOW (0x20)
#define MPC52xx_GPT_MODE_GPIO_OUT_HIGH (0x30)
+#define MPC52xx_GPT_MODE_COUNTER_ENABLE (0x1000)
+#define MPC52xx_GPT_MODE_CONTINUOUS (0x0400)
+#define MPC52xx_GPT_MODE_OPEN_DRAIN (0x0200)
#define MPC52xx_GPT_MODE_IRQ_EN (0x0100)
#define MPC52xx_GPT_MODE_ICT_MASK (0x030000)
@@ -190,7 +202,7 @@ static int mpc52xx_gpt_irq_xlate(struct irq_host *h, struct device_node *ct,
dev_dbg(gpt->dev, "%s: flags=%i\n", __func__, intspec[0]);
- if ((intsize < 1) || (intspec[0] < 1) || (intspec[0] > 3)) {
+ if ((intsize < 1) || (intspec[0] > 3)) {
dev_err(gpt->dev, "bad irq specifier in %s\n", ct->full_name);
return -EINVAL;
}
@@ -211,13 +223,11 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
{
int cascade_virq;
unsigned long flags;
-
- /* Only setup cascaded IRQ if device tree claims the GPT is
- * an interrupt controller */
- if (!of_find_property(node, "interrupt-controller", NULL))
- return;
+ u32 mode;
cascade_virq = irq_of_parse_and_map(node, 0);
+ if (!cascade_virq)
+ return;
gpt->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR, 1,
&mpc52xx_gpt_irq_ops, -1);
@@ -227,14 +237,16 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt, struct device_node *node)
}
gpt->irqhost->host_data = gpt;
-
set_irq_data(cascade_virq, gpt);
set_irq_chained_handler(cascade_virq, mpc52xx_gpt_irq_cascade);
- /* Set to Input Capture mode */
+ /* If the GPT is currently disabled, then change it to be in Input
+ * Capture mode. If the mode is non-zero, then the pin could be
+ * already in use for something. */
spin_lock_irqsave(&gpt->lock, flags);
- clrsetbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_MS_MASK,
- MPC52xx_GPT_MODE_MS_IC);
+ mode = in_be32(&gpt->regs->mode);
+ if ((mode & MPC52xx_GPT_MODE_MS_MASK) == 0)
+ out_be32(&gpt->regs->mode, mode | MPC52xx_GPT_MODE_MS_IC);
spin_unlock_irqrestore(&gpt->lock, flags);
dev_dbg(gpt->dev, "%s() complete. virq=%i\n", __func__, cascade_virq);
@@ -335,6 +347,102 @@ static void
mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) { }
#endif /* defined(CONFIG_GPIOLIB) */
+/***********************************************************************
+ * Timer API
+ */
+
+/**
+ * mpc52xx_gpt_from_irq - Return the GPT device associated with an IRQ number
+ * @irq: irq of timer.
+ */
+struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq)
+{
+ struct mpc52xx_gpt_priv *gpt;
+ struct list_head *pos;
+
+ /* Iterate over the list of timers looking for a matching device */
+ mutex_lock(&mpc52xx_gpt_list_mutex);
+ list_for_each(pos, &mpc52xx_gpt_list) {
+ gpt = container_of(pos, struct mpc52xx_gpt_priv, list);
+ if (gpt->irqhost && irq == irq_linear_revmap(gpt->irqhost, 0)) {
+ mutex_unlock(&mpc52xx_gpt_list_mutex);
+ return gpt;
+ }
+ }
+ mutex_unlock(&mpc52xx_gpt_list_mutex);
+
+ return NULL;
+}
+EXPORT_SYMBOL(mpc52xx_gpt_from_irq);
+
+/**
+ * mpc52xx_gpt_start_timer - Set and enable the GPT timer
+ * @gpt: Pointer to gpt private data structure
+ * @period: period of timer
+ * @continuous: set to 1 to make timer continuous free running
+ *
+ * An interrupt will be generated every time the timer fires
+ */
+int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
+ int continuous)
+{
+ u32 clear, set;
+ u64 clocks;
+ u32 prescale;
+ unsigned long flags;
+
+ clear = MPC52xx_GPT_MODE_MS_MASK | MPC52xx_GPT_MODE_CONTINUOUS;
+ set = MPC52xx_GPT_MODE_MS_GPIO | MPC52xx_GPT_MODE_COUNTER_ENABLE;
+ if (continuous)
+ set |= MPC52xx_GPT_MODE_CONTINUOUS;
+
+ /* Determine the number of clocks in the requested period. 64 bit
+ * arithmatic is done here to preserve the precision until the value
+ * is scaled back down into the u32 range. Period is in 'ns', bus
+ * frequency is in Hz. */
+ clocks = (u64)period * (u64)gpt->ipb_freq;
+ do_div(clocks, 1000000000); /* Scale it down to ns range */
+
+ /* This device cannot handle a clock count greater than 32 bits */
+ if (clocks > 0xffffffff)
+ return -EINVAL;
+
+ /* Calculate the prescaler and count values from the clocks value.
+ * 'clocks' is the number of clock ticks in the period. The timer
+ * has 16 bit precision and a 16 bit prescaler. Prescaler is
+ * calculated by integer dividing the clocks by 0x10000 (shifting
+ * down 16 bits) to obtain the smallest possible divisor for clocks
+ * to get a 16 bit count value.
+ *
+ * Note: the prescale register is '1' based, not '0' based. ie. a
+ * value of '1' means divide the clock by one. 0xffff divides the
+ * clock by 0xffff. '0x0000' does not divide by zero, but wraps
+ * around and divides by 0x10000. That is why prescale must be
+ * a u32 variable, not a u16, for this calculation. */
+ prescale = (clocks >> 16) + 1;
+ do_div(clocks, prescale);
+ if (clocks > 0xffff) {
+ pr_err("calculation error; prescale:%x clocks:%llx\n",
+ prescale, clocks);
+ return -EINVAL;
+ }
+
+ /* Set and enable the timer */
+ spin_lock_irqsave(&gpt->lock, flags);
+ out_be32(&gpt->regs->count, prescale << 16 | clocks);
+ clrsetbits_be32(&gpt->regs->mode, clear, set);
+ spin_unlock_irqrestore(&gpt->lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(mpc52xx_gpt_start_timer);
+
+void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt)
+{
+ clrbits32(&gpt->regs->mode, MPC52xx_GPT_MODE_COUNTER_ENABLE);
+}
+EXPORT_SYMBOL(mpc52xx_gpt_stop_timer);
+
/* ---------------------------------------------------------------------
* of_platform bus binding code
*/
@@ -349,6 +457,7 @@ static int __devinit mpc52xx_gpt_probe(struct of_device *ofdev,
spin_lock_init(&gpt->lock);
gpt->dev = &ofdev->dev;
+ gpt->ipb_freq = mpc52xx_find_ipb_freq(ofdev->node);
gpt->regs = of_iomap(ofdev->node, 0);
if (!gpt->regs) {
kfree(gpt);
@@ -360,6 +469,10 @@ static int __devinit mpc52xx_gpt_probe(struct of_device *ofdev,
mpc52xx_gpt_gpio_setup(gpt, ofdev->node);
mpc52xx_gpt_irq_setup(gpt, ofdev->node);
+ mutex_lock(&mpc52xx_gpt_list_mutex);
+ list_add(&gpt->list, &mpc52xx_gpt_list);
+ mutex_unlock(&mpc52xx_gpt_list_mutex);
+
return 0;
}
^ permalink raw reply related
* [RFC PATCH v2 0/2] Second posting of RFC patches
From: Grant Likely @ 2009-03-24 18:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jean-philippe.jacquemin
These aren't actually done yet, but I've received some interest in them,
so I'm posting the current state.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Update ranges in gianfar node to match other dts
From: Kumar Gala @ 2009-03-24 17:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090324160032.GB24778@ld0162-tx32.am.freescale.net>
On Mar 24, 2009, at 11:00 AM, Scott Wood wrote:
> On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
>> The gianfar node @ 25000 was missing its ranges prop for the mdio bus
>> and provided an explicit ranges property on gianfar@24000 to match
>> all other .dts
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>> arch/powerpc/boot/dts/mpc8313erdb.dts | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/
>> boot/dts/mpc8313erdb.dts
>> index 3ebf7ec..20a0fa8 100644
>> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
>> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
>> @@ -180,7 +180,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>> sleep = <&pmc 0x20000000>;
>> - ranges;
>> + ranges = <0x0 0x24000 0x1000>;
>>
>> cell-index = <0>;
>> device_type = "network";
>
> You need to fix the reg property of the child node to match this
> change
> in ranges. Was this boot-tested (or is it a case of Linux's device
> tree
> parsing being excessively tolerant of broken trees)?
>
I didn't boot test.. Anton pointed this issue out as well.
- k
^ permalink raw reply
* Re: physmap_of and partitions (mtd concat support)
From: Grant Likely @ 2009-03-24 16:28 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <200903241639.56637.sr@denx.de>
On Tue, Mar 24, 2009 at 9:39 AM, Stefan Roese <sr@denx.de> wrote:
> On Tuesday 24 March 2009, Grant Likely wrote:
>> >> Sounds to me like a physmap_of driver bug. =A0I don't think there is =
any
>> >> advantage in changing the partition syntax since concatenated flash
>> >> will always be used as a single device. =A0It doesn't make any sense =
to
>> >> try and span partitions over two nodes.
>> >
>> > Yes, I would really love to make this possible with only one flash nod=
e.
>> > But just think about the following system configuration:
>> >
>> > One Intel Strataflash (compatible =3D "cfi-flash") and one non-cfi
>> > compatible flash (e.g. compatible =3D "jedec-flash"). And the user wan=
ts to
>> > define a partition that spans over both flash chips. How could this be
>> > described in one flash node?
>> >
>> >> Do additional properties need to be added to describe the concat layo=
ut?
>> >
>> > Not sure. If we have multiple identical devices they can currently be
>> > described in one flash node. So with some changes to the physmap_of
>> > driver this configuration will work with concat as well. But more comp=
lex
>> > is a system configuration as described above. Meaning two or more
>> > non-identical chips. I don't see how this could be described in a sane
>> > way in one flash node.
>>
>> Are there any such platforms?
>
> Yes, I know some. Even though they are currently not used with a partitio=
n
> spanning over those multiple chips (jedec and cfi).
OK
>> Is there much likelihood that such a
>> platform will be created? =A0Would it even be a good idea to span
>> partitions across such an arrangement given that different devices
>> will behave differently?
>
> OK, in the example above such a spanning partition is not so likely. But =
think
> about my original example, the Intel P30 with two different cfi compatibl=
e
> chips on one die. Here a partition spanning over both devices is very lik=
ely.
I agree. Same thing when two or more flash chips are put on a board
in consecutive addresses. I've worked on plenty of these arrangements
myself.
This case really does sound like a driver bug and that the existing
cfi-flash binding is sufficient to describe the hardware. IIUC, when
all the flash chips are of the same type the physmap_of driver should
be smart enough to detect each of the flash chips within the reg
range.
If I'm wrong and it cannot do this, then it would be a simple matter
of adding an additional tuple to reg for each discrete chip. A
simple, backwards compatible extension which doesn't require a new
binding.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Update ranges in gianfar node to match other dts
From: Scott Wood @ 2009-03-24 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1237901745-27418-1-git-send-email-galak@kernel.crashing.org>
On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
> The gianfar node @ 25000 was missing its ranges prop for the mdio bus
> and provided an explicit ranges property on gianfar@24000 to match
> all other .dts
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 3ebf7ec..20a0fa8 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -180,7 +180,7 @@
> #address-cells = <1>;
> #size-cells = <1>;
> sleep = <&pmc 0x20000000>;
> - ranges;
> + ranges = <0x0 0x24000 0x1000>;
>
> cell-index = <0>;
> device_type = "network";
You need to fix the reg property of the child node to match this change
in ranges. Was this boot-tested (or is it a case of Linux's device tree
parsing being excessively tolerant of broken trees)?
-Scott
^ permalink raw reply
* Re: of_serial and device trees
From: Scott Wood @ 2009-03-24 15:55 UTC (permalink / raw)
To: Simon Kagstrom; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20090324094959.447a3a31@seasc0532.dyn.rnd.as.sw.ericsson.se>
On Tue, Mar 24, 2009 at 09:49:59AM +0100, Simon Kagstrom wrote:
> My problem is that I can't figure out how to express this correctly in
> the device tree for the board. My device tree looks like this ("isf" is
> the name of the FPGA):
>
> isf@c0020000 {
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <c0020000 00020000>;
>
Change this line to: ranges = <0 c0020000 00020000>;
This causes reg resources in child nodes to be properly translated. What
you have above indicates that all 0x20000 bytes are for the driver of *this*
node.
Add compatible = "simple-bus". This lets children of this node be probed
by of_platform drivers (make sure you list simple-bus when calling
of_platform_bus_probe), and in a few other places (like legacy_serial.c).
> isf_pic: isf_pic@4000 {
> device_type = "isf-pic";
> compatible = "isf-pic";
> interrupt-controller;
> clock-frequency = <0>;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <4000 100>;
> built-in;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
Ged rid of built-in, clock-frequency, and device_type.
Compatible should be of the form "vendor,device" -- and does "isf"
uniquely identify the specific FPGA logic, or are there other versions
out there (or likely to exist in the future)? Note that there are some
bad examples in existing device trees that have yet to be fixed.
Node name should be interrupt-controller, not isf_pic.
> clock-frequency = <13ab6680>; /* 330Mhz */
Note that dts-v1 syntax has C-like constants, with decimal by default.
I'm guessing you're working with a relatively old kernel?
> and thereafter calling a custom setup function for the FPGA interrupt
> controller. That appears to work fine, but I'm wondering how to get the
> serial ports detected properly by of_serial.
The simple-bus compatible, and ranges property, should do it. I'm
guessing that your FPGA PIC driver isn't getting its register address
from the device tree, given that it works without the ranges property?
-Scott
^ permalink raw reply
* Re: physmap_of and partitions (mtd concat support)
From: Stefan Roese @ 2009-03-24 15:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <fa686aa40903240757n569f2b04t1309e817fd30728d@mail.gmail.com>
On Tuesday 24 March 2009, Grant Likely wrote:
> >> Sounds to me like a physmap_of driver bug. =A0I don't think there is a=
ny
> >> advantage in changing the partition syntax since concatenated flash
> >> will always be used as a single device. =A0It doesn't make any sense to
> >> try and span partitions over two nodes.
> >
> > Yes, I would really love to make this possible with only one flash node.
> > But just think about the following system configuration:
> >
> > One Intel Strataflash (compatible =3D "cfi-flash") and one non-cfi
> > compatible flash (e.g. compatible =3D "jedec-flash"). And the user want=
s to
> > define a partition that spans over both flash chips. How could this be
> > described in one flash node?
> >
> >> Do additional properties need to be added to describe the concat layou=
t?
> >
> > Not sure. If we have multiple identical devices they can currently be
> > described in one flash node. So with some changes to the physmap_of
> > driver this configuration will work with concat as well. But more compl=
ex
> > is a system configuration as described above. Meaning two or more
> > non-identical chips. I don't see how this could be described in a sane
> > way in one flash node.
>
> Are there any such platforms?
Yes, I know some. Even though they are currently not used with a partition=
=20
spanning over those multiple chips (jedec and cfi).
> Is there much likelihood that such a=20
> platform will be created? Would it even be a good idea to span
> partitions across such an arrangement given that different devices
> will behave differently?
OK, in the example above such a spanning partition is not so likely. But th=
ink=20
about my original example, the Intel P30 with two different cfi compatible=
=20
chips on one die. Here a partition spanning over both devices is very likel=
y.
As a sidenote: All this (concat over different chips) is possible with the=
=20
physmap.c mapping driver which was used on most of my platforms in the "old=
"=20
arch/ppc days.
> I think just leave that arrangement as hypothetical until the
> situation actually occurs. If it does occur, then strongly recommend
> to not span a partition across the boundary. If someone really
> insists on doing this then we can create a new binding for the
> purpose; but leave the old binding as is. Maybe something like:
>
> mtd {
> #address-cells =3D <1>;
> #size-cells =3D <1>;
> compatibly =3D "weird-mtd-concat";
> devices =3D <&mtd1 &mtd2 &mtd3>;
> partition1@0 {
> reg =3D <0 0x100000>;
> };
> partition2@100000 {
> reg =3D <0x100000 0x100000>;
> };
> }
>
> Where mtd1, 2 & 3 point to real flash nodes. That way the
> concatenated MTD devices could be anything NAND, NOR, SRAM, whatever
> and it doesn't have to try and overload the existing device bindings.
I think I like this idea. If nobody objects or has a better idea then I cou=
ld=20
start implementing it this way in a while.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] ucc_geth: Fix build breakage caused by a merge
From: Anton Vorontsov @ 2009-03-24 15:37 UTC (permalink / raw)
To: David Miller
Cc: LinuxPPC Mailing List, Andy Fleming, Joakim Tjernlund, netdev
In-Reply-To: <382F4B5D-93C4-41BB-A00A-8A6C240CD170@kernel.crashing.org>
This patch fixes following build error:
CC ucc_geth.o
ucc_geth.c: In function 'ucc_geth_probe':
ucc_geth.c:3644: error: implicit declaration of function 'uec_mdio_bus_name'
make[2]: *** [ucc_geth.o] Error 1
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Tue, Mar 24, 2009 at 08:15:13AM -0500, Kumar Gala wrote:
> Anton, Andy
>
> Can you take a look at the recent net-next tree and make sure that the
> merge between the fsl_pq_mdio.c support and the patch that went into
> 2.6.29 to fix fixed-link support in ucc_geth.c is correct and still
> works.
>
> See commits:
> Merge branch master... (8be7cdccacfbfc707e7370cad9bb168defed636f)
> ucc_geth: Fix merge error. (039a6f6a39d2aa30ee53afdb213ea6dd4482928b)
Thanks for heads up, there is indeed a small issue.
drivers/net/ucc_geth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 5f866e2..0b67512 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3641,7 +3641,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
if (err)
return -1;
- uec_mdio_bus_name(bus_name, mdio);
+ fsl_pq_mdio_bus_name(bus_name, mdio);
snprintf(ug_info->phy_bus_id, sizeof(ug_info->phy_bus_id),
"%s:%02x", bus_name, *prop);
}
--
1.5.6.5
^ permalink raw reply related
* Re: physmap_of and partitions (mtd concat support)
From: Grant Likely @ 2009-03-24 14:57 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <200903241007.51321.sr@denx.de>
On Tue, Mar 24, 2009 at 3:07 AM, Stefan Roese <sr@denx.de> wrote:
> On Monday 23 March 2009, Grant Likely wrote:
>> On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese <sr@denx.de> wrote:
>> > I just noticed that physmap_of can't handle multiple devices of differ=
ent
>> > type described in one device node. For example the Intel P30 48F4400
>> > (64MByte) consists internally of 2 non-identical NOR chips. So a "simp=
le"
>>
>> [...]
>>
>> > Now the real problem: How should I describe a partition in the device
>> > tree spanning over both devices (concat)?. The current physmap_of driv=
er
>> > doesn't handle concat at all (physmap.c does). I already have some ide=
as
>> > on how to implement this concat support in physmap_of. But ideas about=
a
>> > device-tree syntax for such partitions are very welcome.
>>
>> Sounds to me like a physmap_of driver bug. =A0I don't think there is any
>> advantage in changing the partition syntax since concatenated flash
>> will always be used as a single device. =A0It doesn't make any sense to
>> try and span partitions over two nodes.
>
> Yes, I would really love to make this possible with only one flash node. =
But
> just think about the following system configuration:
>
> One Intel Strataflash (compatible =3D "cfi-flash") and one non-cfi compat=
ible
> flash (e.g. compatible =3D "jedec-flash"). And the user wants to define a
> partition that spans over both flash chips. How could this be described i=
n
> one flash node?
>
>> Do additional properties need to be added to describe the concat layout?
>
> Not sure. If we have multiple identical devices they can currently be
> described in one flash node. So with some changes to the physmap_of drive=
r
> this configuration will work with concat as well. But more complex is a
> system configuration as described above. Meaning two or more non-identica=
l
> chips. I don't see how this could be described in a sane way in one flash
> node.
Are there any such platforms? Is there much likelihood that such a
platform will be created? Would it even be a good idea to span
partitions across such an arrangement given that different devices
will behave differently?
I think just leave that arrangement as hypothetical until the
situation actually occurs. If it does occur, then strongly recommend
to not span a partition across the boundary. If someone really
insists on doing this then we can create a new binding for the
purpose; but leave the old binding as is. Maybe something like:
mtd {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatibly =3D "weird-mtd-concat";
devices =3D <&mtd1 &mtd2 &mtd3>;
partition1@0 {
reg =3D <0 0x100000>;
};
partition2@100000 {
reg =3D <0x100000 0x100000>;
};
}
Where mtd1, 2 & 3 point to real flash nodes. That way the
concatenated MTD devices could be anything NAND, NOR, SRAM, whatever
and it doesn't have to try and overload the existing device bindings.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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