* [PATCH net-next 3/3] gianfar: delete orphaned version strings and dead macros
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
There were two version strings, and neither one was being used.
Also in the same proximity were some unused #define that were
left over from the past. Delete them all.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar.c | 3 ---
drivers/net/ethernet/freescale/gianfar.h | 3 ---
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index a4c934b..6e66cc3 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -104,10 +104,7 @@
#include "fsl_pq_mdio.h"
#define TX_TIMEOUT (1*HZ)
-#undef BRIEF_GFAR_ERRORS
-#undef VERBOSE_GFAR_ERRORS
-const char gfar_driver_name[] = "Gianfar Ethernet";
const char gfar_driver_version[] = "1.3";
static int gfar_enet_open(struct net_device *dev);
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index 4fe0f34..fc2488a 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -78,11 +78,8 @@ struct ethtool_rx_list {
#define INCREMENTAL_BUFFER_SIZE 512
#define PHY_INIT_TIMEOUT 100000
-#define GFAR_PHY_CHANGE_TIME 2
-#define DEVICE_NAME "%s: Gianfar Ethernet Controller Version 1.2, "
#define DRV_NAME "gfar-enet"
-extern const char gfar_driver_name[];
extern const char gfar_driver_version[];
/* MAXIMUM NUMBER OF QUEUES SUPPORTED */
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next 2/3] gianfar: constify giant block of status descriptor strings
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 5a78d55..8d74efd 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -58,7 +58,7 @@ static void gfar_gringparam(struct net_device *dev, struct ethtool_ringparam *rv
static int gfar_sringparam(struct net_device *dev, struct ethtool_ringparam *rvals);
static void gfar_gdrvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo);
-static char stat_gstrings[][ETH_GSTRING_LEN] = {
+static const char stat_gstrings[][ETH_GSTRING_LEN] = {
"rx-dropped-by-kernel",
"rx-large-frame-errors",
"rx-short-frame-errors",
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next 1/3] gianfar: Add support for byte queue limits.
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
In-Reply-To: <1332089787-24086-1-git-send-email-paul.gortmaker@windriver.com>
Add support for byte queue limits (BQL), based on the similar
modifications made to intel/igb/igb_main.c from Eric Dumazet
in commit bdbc063129e811264cd6c311d8c2d9b95de01231
"igb: Add support for byte queue limits."
A local variable for tx_queue->qindex was introduced in
gfar_clean_tx_ring, since it is now used often enough to warrant it,
and it cleans up the readability somewhat as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index adb0ae4..a4c934b 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1755,9 +1755,12 @@ static void free_skb_resources(struct gfar_private *priv)
/* Go through all the buffer descriptors and free their data buffers */
for (i = 0; i < priv->num_tx_queues; i++) {
+ struct netdev_queue *txq;
tx_queue = priv->tx_queue[i];
+ txq = netdev_get_tx_queue(tx_queue->dev, tx_queue->qindex);
if(tx_queue->tx_skbuff)
free_skb_tx_queue(tx_queue);
+ netdev_tx_reset_queue(txq);
}
for (i = 0; i < priv->num_rx_queues; i++) {
@@ -2217,6 +2220,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
lstatus |= BD_LFLAG(TXBD_CRC | TXBD_READY) | skb_headlen(skb);
}
+ netdev_tx_sent_queue(txq, skb->len);
+
/*
* We can work in parallel with gfar_clean_tx_ring(), except
* when modifying num_txbdfree. Note that we didn't grab the lock
@@ -2460,6 +2465,7 @@ static void gfar_align_skb(struct sk_buff *skb)
static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
{
struct net_device *dev = tx_queue->dev;
+ struct netdev_queue *txq;
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_rx_q *rx_queue = NULL;
struct txbd8 *bdp, *next = NULL;
@@ -2471,10 +2477,13 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
int frags = 0, nr_txbds = 0;
int i;
int howmany = 0;
+ int tqi = tx_queue->qindex;
+ unsigned int bytes_sent = 0;
u32 lstatus;
size_t buflen;
- rx_queue = priv->rx_queue[tx_queue->qindex];
+ rx_queue = priv->rx_queue[tqi];
+ txq = netdev_get_tx_queue(dev, tqi);
bdp = tx_queue->dirty_tx;
skb_dirtytx = tx_queue->skb_dirtytx;
@@ -2533,6 +2542,8 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
bdp = next_txbd(bdp, base, tx_ring_size);
}
+ bytes_sent += skb->len;
+
/*
* If there's room in the queue (limit it to rx_buffer_size)
* we add this skb back into the pool, if it's the right size
@@ -2557,13 +2568,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
}
/* If we freed a buffer, we can restart transmission, if necessary */
- if (__netif_subqueue_stopped(dev, tx_queue->qindex) && tx_queue->num_txbdfree)
- netif_wake_subqueue(dev, tx_queue->qindex);
+ if (__netif_subqueue_stopped(dev, tqi) && tx_queue->num_txbdfree)
+ netif_wake_subqueue(dev, tqi);
/* Update dirty indicators */
tx_queue->skb_dirtytx = skb_dirtytx;
tx_queue->dirty_tx = bdp;
+ netdev_tx_completed_queue(txq, howmany, bytes_sent);
+
return howmany;
}
--
1.7.9.1
^ permalink raw reply related
* [PATCH net-next 0/3] Gianfar byte queue limits
From: Paul Gortmaker @ 2012-03-18 16:56 UTC (permalink / raw)
To: davem, eric.dumazet, therbert; +Cc: netdev, linuxppc-dev, Paul Gortmaker
The BQL support here is unchanged from what I posted earlier as an
RFC[1] -- with the exception of the fact that I'm now happier with
the runtime testing vs. the simple "hey it boots" that I'd done
for the RFC. Plus I added a couple trivial cleanup patches.
For testing, I made a couple spiders homeless by reviving an ancient
10baseT hub. I connected an sbc8349 into that, and connected the
yellowing hub into a GigE 16port, which was also connected to the
recipient x86 box.
Gianfar saw the interface as follows:
fsl-gianfar e0024000.ethernet: eth0: mac: 00:a0:1e:a0:26:5a
fsl-gianfar e0024000.ethernet: eth0: Running with NAPI enabled
fsl-gianfar e0024000.ethernet: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar e0024000.ethernet: eth0: TX BD ring size for Q[0]: 256
PHY: mdio@e0024520:19 - Link is Up - 10/Half
With the sbc8349 being diskless, I simply used an scp of /proc/kcore
to the connected x86 box as a rudimentary Tx heavy workload.
BQL data was collected by changing into the dir:
/sys/devices/e0000000.soc8349/e0024000.ethernet/net/eth0/queues/tx-0/byte_queue_limits
and running the following:
for i in * ; do echo -n $i": " ; cat $i ; done
Running with the defaults, data like below was typical:
hold_time: 1000
inflight: 4542
limit: 3456
limit_max: 1879048192
limit_min: 0
hold_time: 1000
inflight: 4542
limit: 3378
limit_max: 1879048192
limit_min: 0
i.e. 2 or 3 MTU sized packets in flight and the limit value lying
somewhere between those two values.
The interesting thing is that the interactive speed reported by scp
seemed somewhat erratic, ranging from ~450 to ~700kB/s. (This was
the only traffic on the old junk - perhaps expected oscillations such
as those seen in isolated ARED tests?) Average speed for 100M was:
104857600 bytes (105 MB) copied, 172.616 s, 607 kB/s
Anyway, back to BQL testing; setting the values as follows:
hold_time: 1000
inflight: 1514
limit: 1400
limit_max: 1400
limit_min: 1000
had the effect of serializing the interface to a single packet, and
the crusty old hub seemed much happier with this arrangement, keeping
a constant speed and achieving the following on a 100MB Tx block:
104857600 bytes (105 MB) copied, 112.52 s, 932 kB/s
It might be interesting to know more about why the defaults suffer
the slowdown, but the hub could possibly be ancient spec violating
trash. Definitely something that nobody would ever use for anything
today. (aside from contrived tests like this)
But it did give me an example of where I could see the effects of
changing the BQL settings, and I'm reasonably confident they are
working as expected.
Paul.
---
[1] http://lists.openwall.net/netdev/2012/01/06/64
Paul Gortmaker (3):
gianfar: Add support for byte queue limits.
gianfar: constify giant block of status descriptor strings
gianfar: delete orphaned version strings and dead macros
drivers/net/ethernet/freescale/gianfar.c | 22 ++++++++++++++++------
drivers/net/ethernet/freescale/gianfar.h | 3 ---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 2 +-
3 files changed, 17 insertions(+), 10 deletions(-)
--
1.7.9.1
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-18 16:14 UTC (permalink / raw)
To: Grant Likely
Cc: dbaryshkov@gmail.com, devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <20120318090804.C70493E060A@localhost>
Grant Likely wrote:
> That's because you're using it wrong. of_platform_bus_probe() creates
> platform devices at the starting level and every level below it as
> described by the bus ids. It is illegal to call of_platform_bus_probe()
> twice at the same level in the DT.
Well, *I* am not using it wrong. Notice that my patch fixes (or works=20
around) the commit that *did* do it wrong:
http://patchwork.ozlabs.org/patch/126289/
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-18 14:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Florian Tobias Schandinat, Tony Breeds, linuxppc-dev
In-Reply-To: <1332031585.3105.197.camel@pasglop>
On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
>> Hello,
>>
>> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>>
>> The peculiarity of this platform is the fact that it has
>> sizeof(unsigned long) = 4,
>> but physical address on it is 36 bits width. It is a common to various pieces
>> of the code to expect that unsigned long variable is able to contain physical
>> address. Most of those places are easy to fix.
>
> Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
> infrastructure (we have radeon KMS working on a similar platform).
That is interesting! Are those patches published or otherwise available
somewhere? We are also very interested in enabling Canyonlands
with Radeon KMS!
>
>> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
>> it uses information from struct fb_fix_screeninfo provided by the driver.
>> This structure uses two unsigned long fields to hold physical addresses
>> (smem_start and mmio_start). It would be easy to change that structure
>> to use phys_addr_t instead of unsigned long, but this structure is a part
>> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
>> And now I'm stuck with it.
>
> It's an old problem, which I think we described a while back on the
> list. Back then the conclusion was to make a new version with a proper
> __u64, a new ioctl to access is, and a "compatible" ioctl that blanks
> the address fields (or fails) if they contain a value >32-bit.
>
> We just never got to actually implement it.
I see. I will try to prepare patches.
>
> In fact, we could make the new structure such that it doesn't break
> userspace compatibility with 64-bit architectures at all, ie, the "new"
> and "compat" ioctl could remain entirely equivalent on 64-bit.
I remember stuff about compat_ioctl, but I have never used/implemented
that. Are there any details of requirements for the structures being passed?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-18 9:08 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <4F649304.9010001@freescale.com>
On Sat, 17 Mar 2012 13:35:02 +0000, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> Grant Likely wrote:
> >>> > > Are you aware of any reason that we can't call of_platform_bus_probe()
> >>> > > or multiple times. Timur's run into an issue in which all devices
> >>> > > don't get registered properly if we call of_platform_bus_probe() times
> >>> > > with different of_device_id struct's.
> >> >
> >> > Nothing comes to mind... Grant ?
> > Neither for me. Should work.
>
> I posted a work-around patch here:
>
> http://patchwork.ozlabs.org/patch/128533/
>
> Without this patch, drivers cannot probe on DMA *channels*, or any other
> grandchildren of the root node.
That's because you're using it wrong. of_platform_bus_probe() creates
platform devices at the starting level and every level below it as
described by the bus ids. It is illegal to call of_platform_bus_probe()
twice at the same level in the DT.
g.
^ permalink raw reply
* Re: Problem with framebuffer mmap on platforms with large addressing
From: Benjamin Herrenschmidt @ 2012-03-18 0:46 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linux-fbdev-devel, Florian Tobias Schandinat, Tony Breeds,
linuxppc-dev
In-Reply-To: <CALT56yO05UBY6=KqK94=_sC4hd3ranj5J5CXOAo5hSjVAdkgkA@mail.gmail.com>
On Sat, 2012-03-17 at 20:04 +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
>
> The peculiarity of this platform is the fact that it has
> sizeof(unsigned long) = 4,
> but physical address on it is 36 bits width. It is a common to various pieces
> of the code to expect that unsigned long variable is able to contain physical
> address. Most of those places are easy to fix.
Yes. In fact, Tony (CC) has some patches to fix a lot of the DRM
infrastructure (we have radeon KMS working on a similar platform).
> The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
> it uses information from struct fb_fix_screeninfo provided by the driver.
> This structure uses two unsigned long fields to hold physical addresses
> (smem_start and mmio_start). It would be easy to change that structure
> to use phys_addr_t instead of unsigned long, but this structure is a part
> of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
> And now I'm stuck with it.
It's an old problem, which I think we described a while back on the
list. Back then the conclusion was to make a new version with a proper
__u64, a new ioctl to access is, and a "compatible" ioctl that blanks
the address fields (or fails) if they contain a value >32-bit.
We just never got to actually implement it.
In fact, we could make the new structure such that it doesn't break
userspace compatibility with 64-bit architectures at all, ie, the "new"
and "compat" ioctl could remain entirely equivalent on 64-bit.
> In my driver code I have just overwritten the fb_mmap function with
> driver-private
> fb_mmap callback supporting 64-bit addressing, but this doesn't look like
> a generic and correct solution.
>
> What is the best way to fix this problem? Should we break ABI with the goal
> of correctness? Should we add new FBIOGET_FSCREENINFO2, which will
> return a correct structure with phys_addr_t (or simply u64) fields and make
> FBIOGET_FSCREENINFO a wrapper returning partially bogus structure
> (with smem_start and mmio_start fields being truncated to just unsigned long)?
> What would developers recommend?
Cheers,
Ben.
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-17 23:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1332026973.3105.191.camel@pasglop>
Benjamin Herrenschmidt wrote:
> Why don't you track down the actual bug instead ?
I was hoping that someone who is very familiar with the code would take a=20
look. I don't know the OF layer that well.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Benjamin Herrenschmidt @ 2012-03-17 23:29 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <4F649304.9010001@freescale.com>
On Sat, 2012-03-17 at 13:35 +0000, Tabi Timur-B04825 wrote:
> >>> > > Are you aware of any reason that we can't call
> of_platform_bus_probe()
> >>> > > or multiple times. Timur's run into an issue in which all
> devices
> >>> > > don't get registered properly if we call
> of_platform_bus_probe() times
> >>> > > with different of_device_id struct's.
> >> >
> >> > Nothing comes to mind... Grant ?
> > Neither for me. Should work.
>
> I posted a work-around patch here:
>
> http://patchwork.ozlabs.org/patch/128533/
>
> Without this patch, drivers cannot probe on DMA *channels*, or any
> other
> grandchildren of the root node.
Why don't you track down the actual bug instead ?
Cheers,
Ben.
^ permalink raw reply
* Re: fsl pci edac patches
From: Dmitry Eremin-Solenikov @ 2012-03-17 17:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: Lan Chunhe-B25806, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <31B0E63E-923D-4022-8B27-76CFF2189817@kernel.crashing.org>
Hello,
On Sat, Mar 17, 2012 at 1:13 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Guys,
>
> I'm not sure what the state of the EDAC patches and latest kernel are.. I'm going to mark the ones in patch works as 'dead' and hopefully you guys will resend if there is still an interest.
I don't have mpc85xx hardware to test at this point, so probably I
don't care about 85xx EDAC binding right now.
Strictly speaking I forgot about these patches :(
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] Device Tree Bindings for Freescale TDM controller
From: Tabi Timur-B04825 @ 2012-03-17 16:07 UTC (permalink / raw)
To: Aggrwal Poonam-B10812
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D09D518@039-SN2MPN1-013.039d.mgd.msft.net>
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812
<B10812@freescale.com> wrote:
>
>> > + =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,p1010-tdm", "fsl,mpc8315-tdm=
";
>> > + =A0 =A0 =A0 =A0 =A0 reg =3D <0x16000 0x200 0x2c000 0x2000>;
>> > + =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <0>;
>>
>> Show a real clock-frequency, perhaps with a comment saying it's typicall=
y
>> filled in by boot software.
> Okay.
Scott, are you suggesting that Poonam put a non-zero number in the DTS
for clock-frequency? If so, then I don't think that's a good idea, if
U-Boot will always override it.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] Device Tree Bindings for Freescale TDM controller
From: Tabi Timur-B04825 @ 2012-03-17 16:04 UTC (permalink / raw)
To: Aggrwal Poonam-B10812
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D09D518@039-SN2MPN1-013.039d.mgd.msft.net>
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812
<B10812@freescale.com> wrote:
>
>> > + =A0- clock-frequency
>> > + =A0 =A0 =A0Usage: optional
>> > + =A0 =A0 =A0Value type: <u32>
>> > + =A0 =A0 =A0Definition: The frequency at which the TDM block is opera=
ting.
>>
>> Will this frequency ever need to be > 4GHz?
> Don't think so, at max this will be CCB, not sure if CCB on our platforms=
may get bigger than 4G ever.
Apparently, 4GB is the new 640K.
In Poonam's defense, every clock frequency property in the device tree
is a 32-bit integer. I've never seen a 64-bit one.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Problem with framebuffer mmap on platforms with large addressing
From: Dmitry Eremin-Solenikov @ 2012-03-17 16:04 UTC (permalink / raw)
To: linux-fbdev-devel, linuxppc-dev, Florian Tobias Schandinat,
Josh Boyer, Matt Porter
Hello,
I'm trying to make framebuffer to work on PPC460EX board (canyonlands).
The peculiarity of this platform is the fact that it has
sizeof(unsigned long) = 4,
but physical address on it is 36 bits width. It is a common to various pieces
of the code to expect that unsigned long variable is able to contain physical
address. Most of those places are easy to fix.
The problem I'm stuck with is a fb_mmap() code. To find a right memory to map
it uses information from struct fb_fix_screeninfo provided by the driver.
This structure uses two unsigned long fields to hold physical addresses
(smem_start and mmio_start). It would be easy to change that structure
to use phys_addr_t instead of unsigned long, but this structure is a part
of userspace ABI. It is returned to userspace on FBIOGET_FSCREENINFO ioctl.
And now I'm stuck with it.
In my driver code I have just overwritten the fb_mmap function with
driver-private
fb_mmap callback supporting 64-bit addressing, but this doesn't look like
a generic and correct solution.
What is the best way to fix this problem? Should we break ABI with the goal
of correctness? Should we add new FBIOGET_FSCREENINFO2, which will
return a correct structure with phys_addr_t (or simply u64) fields and make
FBIOGET_FSCREENINFO a wrapper returning partially bogus structure
(with smem_start and mmio_start fields being truncated to just unsigned long)?
What would developers recommend?
Thank you.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Tabi Timur-B04825 @ 2012-03-17 15:47 UTC (permalink / raw)
To: Leekha Shaveta-B20052; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1331974801-15845-1-git-send-email-shaveta@freescale.com>
On Sat, Mar 17, 2012 at 4:00 AM, Shaveta Leekha <shaveta@freescale.com> wro=
te:
> Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
> ---
Where's the patch description? You need to explain WHY this change is
a good idea.
And you should change all defconfigs in one patch.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Tabi Timur-B04825 @ 2012-03-17 13:35 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <20120317072717.738953E08CE@localhost>
Grant Likely wrote:
>>> > > Are you aware of any reason that we can't call of_platform_bus_pr=
obe()
>>> > > or multiple times. Timur's run into an issue in which all device=
s
>>> > > don't get registered properly if we call of_platform_bus_probe() =
times
>>> > > with different of_device_id struct's.
>> >
>> > Nothing comes to mind... Grant ?
> Neither for me. Should work.
I posted a work-around patch here:
http://patchwork.ozlabs.org/patch/128533/
Without this patch, drivers cannot probe on DMA *channels*, or any other=20
grandchildren of the root node.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH]corenet32_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 9:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..91db656 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=y
--
1.5.5.6
^ permalink raw reply related
* [PATCH] mpc85xx_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 9:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index abdcd31..f95b302 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -118,6 +118,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_QE=m
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
CONFIG_SPI=y
--
1.5.5.6
^ permalink raw reply related
* [PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 9:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/mpc85xx_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index f37a2ab..28378e8 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_QE=m
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
CONFIG_SPI=y
--
1.5.5.6
^ permalink raw reply related
* [PATCH] corenet64_smp_defconfig:Added I2C_CHARDEV and I2C_MPC options in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 8:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/corenet64_smp_defconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 7ed8d4c..8a42ebb 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -71,6 +71,8 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MPC=y
# CONFIG_HWMON is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
# CONFIG_HID_SUPPORT is not set
--
1.5.5.6
^ permalink raw reply related
* [PATCH][v2] powerpc/85xx:Add BSC9131 RDB Support
From: Prabhakar Kushwaha @ 2012-03-17 8:39 UTC (permalink / raw)
To: linuxppc-dev, devicetree-discuss
Cc: Poonam Aggrwal, Priyanka Jain, Ramneek Mehresh, Rajan Srivastava,
Akhil Goyal, Prabhakar Kushwaha
BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131 is
integrated SoC that targets Femto base station market. It combines Power
Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F
baseband acceleration processing elements.
The BSC9131 SoC includes the following function and features:
. Power Architecture subsystem including a e500 processor with 256-Kbyte shared
L2 cache
. StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache
. The Multi Accelerator Platform Engine for Femto BaseStation Baseband
Processing (MAPLE-B2F)
. A multi-standard baseband algorithm accelerator for Channel Decoding/Encoding,
Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel processing,
and CRC algorithms
. Consists of accelerators for Convolution, Filtering, Turbo Encoding,
Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix Inversion
operations
. DDR3/3L memory interface with 32-bit data width without ECC and 16-bit with
ECC, up to 400-MHz clock/800 MHz data rate
. Dedicated security engine featuring trusted boot
. DMA controller
. OCNDMA with four bidirectional channels
. Interfaces
. Two triple-speed Gigabit Ethernet controllers featuring network acceleration
including IEEE 1588. v2 hardware support and virtualization (eTSEC)
. eTSEC 1 supports RGMII/RMII
. eTSEC 2 supports RGMII
. High-speed USB 2.0 host and device controller with ULPI interface
. Enhanced secure digital (SD/MMC) host controller (eSDHC)
. Antenna interface controller (AIC), supporting three industry standard
JESD207/three custom ADI RF interfaces (two dual port and one single port)
and three MAXIM's MaxPHY serial interfaces
. ADI lanes support both full duplex FDD support and half duplex TDD support
. Universal Subscriber Identity Module (USIM) interface that facilitates
communication to SIM cards or Eurochip pre-paid phone cards
. TDM with one TDM port
. Two DUART, four eSPI, and two I2C controllers
. Integrated Flash memory controller (IFC)
. TDM with 256 channels
. GPIO
. Sixteen 32-bit timers
The DSP portion of the SoC consists of DSP core (SC3850) and various
accelerators pertaining to DSP operations.
BSC9131RDB Overview
----------------------
BSC9131 SoC
1Gbyte DDR3 (on board DDR)
128Mbyte 2K page size NAND Flash
256 Kbit M24256 I2C EEPROM
128 Mbit SPI Flash memory
USB-ULPI
eTSEC1: Connected to RGMII PHY
eTSEC2: Connected to RGMII PHY
DUART interface: supports one UARTs up to 115200 bps for console display
Linux runs on e500v2 core and access some DSP peripherals like AIC
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Akhil Goyal <Akhil.Goyal@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Rajan Srivastava <rajan.srivastava@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Note: Name of PSC9131 has been changed to BSC9131 because of new nomenclature
Please reject earlier patch"powerpc/85xx:Add PSC9131 RDB Support"
http://patchwork.ozlabs.org/patch/146349/
Beased on http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
branch master
Changes for v2:
- Change board file name as bsc913x_rdb.c
- Removed all I2C's board device. A separate patch will be send.
- Combined SPI's 2 RFS partition into single RFS parition
- Added SEC/crypto node in dts
arch/powerpc/boot/dts/bsc9131rdb.dts | 34 +++++
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 142 ++++++++++++++++++
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 193 +++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi | 59 ++++++++
arch/powerpc/platforms/85xx/Kconfig | 9 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/bsc913x_rdb.c | 95 ++++++++++++
7 files changed, 533 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dts
create mode 100644 arch/powerpc/boot/dts/bsc9131rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi
create mode 100644 arch/powerpc/platforms/85xx/bsc913x_rdb.c
diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dts b/arch/powerpc/boot/dts/bsc9131rdb.dts
new file mode 100644
index 0000000..e13d2d4
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dts
@@ -0,0 +1,34 @@
+/*
+ * BSC9131 RDB Device Tree Source
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "fsl/bsc9131si-pre.dtsi"
+
+/ {
+ model = "fsl,bsc9131rdb";
+ compatible = "fsl,bsc9131rdb";
+
+ memory {
+ device_type = "memory";
+ };
+
+ board_ifc: ifc: ifc@ff71e000 {
+ /* NAND Flash on board */
+ ranges = <0x0 0x0 0x0 0xff800000 0x00004000>;
+ reg = <0x0 0xff71e000 0x0 0x2000>;
+ };
+
+ board_soc: soc: soc@ff700000 {
+ ranges = <0x0 0x0 0xff700000 0x100000>;
+ };
+};
+
+/include/ "bsc9131rdb.dtsi"
+/include/ "fsl/bsc9131si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
new file mode 100644
index 0000000..8906562
--- /dev/null
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
@@ -0,0 +1,142 @@
+/*
+ * BSC9131 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&board_ifc {
+
+ nand@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x0 0x0 0x4000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 3MB for u-boot Bootloader Image */
+ reg = <0x0 0x00300000>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@300000 {
+ /* 1MB for DTB Image */
+ reg = <0x00300000 0x00100000>;
+ label = "NAND DTB Image";
+ };
+
+ partition@400000 {
+ /* 8MB for Linux Kernel Image */
+ reg = <0x00400000 0x00800000>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@c00000 {
+ /* Rest space for Root file System Image */
+ reg = <0x00c00000 0x07400000>;
+ label = " NAND RFS Image";
+ };
+ };
+};
+
+&board_soc {
+ /* BSC9131RDB does not have any device on i2c@3100 */
+ i2c@3100 {
+ status = "disabled";
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+
+ /* 512KB for u-boot Bootloader Image */
+ partition@0 {
+ reg = <0x0 0x00080000>;
+ label = "SPI Flash U-Boot Image";
+ read-only;
+ };
+
+ /* 512KB for DTB Image */
+ partition@80000 {
+ reg = <0x00080000 0x00080000>;
+ label = "SPI Flash DTB Image";
+ };
+
+ /* 4MB for Linux Kernel Image */
+ partition@100000 {
+ reg = <0x00100000 0x00400000>;
+ label = "SPI Flash Kernel Image";
+ };
+
+ /*11MB for RFS Image */
+ partition@500000 {
+ reg = <0x00500000 0x00B00000>;
+ label = "SPI Flash RFS Image";
+ };
+
+ };
+ };
+
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts = <3 1 0 0>;
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupts = <2 1 0 0>;
+ reg = <0x3>;
+ };
+ };
+
+ sdhci@2e000 {
+ status = "disabled";
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
new file mode 100644
index 0000000..5180d9d
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi
@@ -0,0 +1,193 @@
+/*
+ * BSC9131 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <16 2 0 0 20 2 0 0>;
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,bsc9131-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,bsc9131-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,bsc9131-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "pq3-i2c-0.dtsi"
+ i2c@3000 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-i2c-1.dtsi"
+ i2c@3100 {
+ interrupts = <17 2 0 0>;
+ };
+
+/include/ "pq3-duart-0.dtsi"
+ serial0: serial@4500 {
+ interrupts = <18 2 0 0>;
+ };
+
+ serial1: serial@4600 {
+ interrupts = <18 2 0 0 >;
+ };
+/include/ "pq3-espi-0.dtsi"
+ spi0: spi@7000 {
+ fsl,espi-num-chipselects = <1>;
+ interrupts = <22 0x2 0 0>;
+ };
+
+/include/ "pq3-gpio-0.dtsi"
+ gpio-controller@f000 {
+ interrupts = <19 0x2 0 0>;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,bsc9131-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x40000>; // L2,256K
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "pq3-dma-0.dtsi"
+
+dma@21300 {
+
+ dma-channel@0 {
+ interrupts = <62 2 0 0>;
+ };
+
+ dma-channel@80 {
+ interrupts = <63 2 0 0>;
+ };
+
+ dma-channel@100 {
+ interrupts = <64 2 0 0>;
+ };
+
+ dma-channel@180 {
+ interrupts = <65 2 0 0>;
+ };
+};
+
+/include/ "pq3-usb2-dr-0.dtsi"
+usb@22000 {
+ compatible = "fsl-usb2-dr","fsl-usb2-dr-v2.2";
+ interrupts = <40 0x2 0 0>;
+};
+
+/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ fsl,sdhci-auto-cmd12;
+ interrupts = <41 0x2 0 0>;
+ };
+
+/include/ "pq3-sec4.4-0.dtsi"
+crypto@30000 {
+ interrupts = <57 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ interrupts = <58 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ interrupts = <59 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ interrupts = <60 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ interrupts = <61 2 0 0>;
+ };
+};
+
+/include/ "pq3-mpic.dtsi"
+
+timer@41100 {
+ compatible = "fsl,mpic-v1.2-msgr", "fsl,mpic-msg";
+ reg = <0x41400 0x200>;
+ interrupts = <
+ 0xb0 2
+ 0xb1 2
+ 0xb2 2
+ 0xb3 2>;
+};
+
+/include/ "pq3-etsec2-0.dtsi"
+enet0: ethernet@b0000 {
+ queue-group@b0000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <26 2 0 0 27 2 0 0 28 2 0 0>;
+ };
+};
+
+/include/ "pq3-etsec2-1.dtsi"
+enet1: ethernet@b1000 {
+ queue-group@b1000 {
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ interrupts = <33 2 0 0 34 2 0 0 35 2 0 0>;
+ };
+};
+
+global-utilities@e0000 {
+ compatible = "fsl,bsc9131-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi b/arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi
new file mode 100644
index 0000000..743e4ae
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi
@@ -0,0 +1,59 @@
+/*
+ * BSC9131 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+/ {
+ compatible = "fsl,BSC9131";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,BSC9131@0 {
+ device_type = "cpu";
+ compatible = "fsl,e500v2";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index d7946be..9fb5b03 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -91,6 +91,15 @@ config P1023_RDS
help
This option enables support for the P1023 RDS board
+config BSC9131_RDB
+ bool "Freescale BSC9131RDB"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the Freescale BSC9131RDB board.
+ The BSC9131 is a heterogeneous SoC containing an e500v2 powerpc and a
+ StarCore SC3850 DSP
+ Manufacturer : Freescale Semiconductor, Inc
+
config SOCRATES
bool "Socrates"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 9cb2d43..25b376c 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
obj-$(CONFIG_P3060_QDS) += p3060_qds.o corenet_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS) += p5020_ds.o corenet_ds.o
+obj-$(CONFIG_BSC9131_RDB) += bsc913x_rdb.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
new file mode 100644
index 0000000..611c289
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/bsc913x_rdb.c
@@ -0,0 +1,95 @@
+/*
+ * BSC913xRDB Board Setup
+ *
+ * Author: Priyanka Jain <Priyanka.Jain@freescale.com>
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <asm/mpic.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/udbg.h>
+
+void __init bsc913x_rdb_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (!np) {
+ pr_err("bsc913x: Could not find open-pic node\n");
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, &r)) {
+ pr_err("bsc913x: Failed to map mpic register space\n");
+ of_node_put(np);
+ return;
+ }
+
+ mpic = mpic_alloc(np, r.start, MPIC_WANTS_RESET |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS | MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ of_node_put(np);
+
+ if (!mpic)
+ pr_err("bsc913x: Failed to allocate MPIC structure\n");
+ else
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init bsc913x_rdb_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("bsc913x_rdb_setup_arch()", 0);
+
+ pr_info("bsc913x board from Freescale Semiconductor\n");
+}
+
+static struct of_device_id __initdata bsc913x_rdb_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ { .compatible = "simple-bus", },
+ { .compatible = "gianfar", },
+ {},
+};
+
+static int __init bsc913x_rdb_publish_devices(void)
+{
+ return of_platform_bus_probe(NULL, bsc913x_rdb_ids, NULL);
+}
+machine_device_initcall(bsc9131_rdb, bsc913x_rdb_publish_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+
+static int __init bsc9131_rdb_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,bsc9131rdb");
+}
+
+define_machine(bsc9131_rdb) {
+ .name = "BSC9131 RDB",
+ .probe = bsc9131_rdb_probe,
+ .setup_arch = bsc913x_rdb_setup_arch,
+ .init_IRQ = bsc913x_rdb_pic_init,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.5.4
^ permalink raw reply related
* [PATCH]corenet32_smp_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
From: Shaveta Leekha @ 2012-03-17 8:36 UTC (permalink / raw)
To: linuxppc-dev, list; +Cc: Shaveta Leekha
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..91db656 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -116,6 +116,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=y
--
1.5.5.6
^ permalink raw reply related
* RE: [PATCH] Device Tree Bindings for Freescale TDM controller
From: Aggrwal Poonam-B10812 @ 2012-03-17 7:33 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, Singh Sandeep-B37400
In-Reply-To: <4F63868D.1030507@freescale.com>
Thanks Scott for the review.
Will send an updated revision with the comments taken care.
Regards
Poonam
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Saturday, March 17, 2012 12:00 AM
> To: Aggrwal Poonam-B10812
> Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org;
> Singh Sandeep-B37400
> Subject: Re: [PATCH] Device Tree Bindings for Freescale TDM controller
>=20
> On 03/15/2012 08:30 PM, Poonam Aggrwal wrote:
> > From: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> >
> > This TDM controller is available in various Freescale SOCs like
> > MPC8315, P1020, P1022, P1010.
> >
> > Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
> > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> > ---
> > Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 71
> +++++++++++++++++++++
> > 1 files changed, 71 insertions(+), 0 deletions(-) create mode 100644
> > Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> >
> > diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> > b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> > new file mode 100644
> > index 0000000..61431e3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
> > @@ -0,0 +1,71 @@
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > +TDM Device Tree Binding
> > +Copyright (C) 2012 Freescale Semiconductor Inc.
> > +
> > +NOTE: The bindings described in this document are preliminary and
> > +subject to change.
> > +
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > +TDM (Time Division Multiplexing)
> > +
> > +DESCRIPTION
> > +
> > +The TDM is full duplex serial port designed to allow various devices
> > +including digital signal processors (DSPs) to communicate with a
> > +variety of serial devices including industry standard framers, codecs,
> other DSPs and microprocessors.
> > +
> > +The below properties describe the device tree bindings for Freescale
> > +TDM controller.
> > +This TDM controller is available on various Freescale Processors like
> > +MPC8313, P1020, P1022 and P1010.
> > +
> > +PROPERTIES
> > +
> > + - compatible
> > + Usage: required
> > + Value type: <string>
> > + Definition: Should contain "fsl,mpc8315-tdm".
> > + So mpc8313 will have compatible =3D "fsl,mpc8315-tdm";
> > + p1010 will have compatible "fsl,p1010-tdm", "fsl,mpc8315-tdm";
>=20
> Shouldn't mpc8313 have:
> compatible =3D "fsl,mpc8313-tdm", "fsl,mpc8315-tdm"?
>=20
> I thought we were going to use 8313 as the canonical implementation, not
> 8315.
MPC8315 was the first FSL platform to have this controller.
MPC8313 does not have TDM.
>=20
> > + - reg
> > + Usage: required
> > + Value type: <tdm-reg-offset tdm-reg-size dmac-reg-offset dmac-
> reg-size>
> > + Definition: A standard property. Specifies the physical address
> > + offset and length of the TDM registers and TDM DMAC registers for
> > + the device.
>=20
> Just say there's two reg resources, and that the first is the TDM
> registers and the second is the TDM DMAC registers.
>=20
> It's typically not going to be the actual physical address, but rather an
> offset that gets translated through a parent node's ranges.
Okay, I think we missed this comment, you already gave this earlier.
Sorry for that.
>=20
> Remove "value type"; it's standard.
>=20
Okay. So just definition must suffice, right?
> > + - clock-frequency
> > + Usage: optional
> > + Value type: <u32>
> > + Definition: The frequency at which the TDM block is operating.
>=20
> Will this frequency ever need to be > 4GHz?
Don't think so, at max this will be CCB, not sure if CCB on our platforms m=
ay get bigger than 4G ever.
>=20
> Might want to specify as u32 or u64, as ePAPR suggests.
Means Value type: <u32 or u64>?
In this case the driver must always use 64bit data structure to read this. =
Is this correct?
>=20
> > + - interrupts
> > + Usage: required
> > + Value type: <tdm-err-intr tdm-err-intr-type dmac-intr dmac-intr-
> type>
> > + Definition: This field defines two interrupt specifiers namely
> interrupt
> > + number and interrupt type for TDM error and TDM DMAC.
>=20
> What is "tdm-err-intr-type"? The interrupt specifier encoding is defined
> by the interrupt controller. There might be one cell, two cells, four
> cells, etc. Remove "value type", it's standard.
>=20
okay
> > + - phy-handle
> > + Usage: optional
> > + Value type: <phandle>
> > + Definition: Phandle of the line controller node or framer node
> eg. SLIC,
> > + E1\T1 etc.
>=20
> Use a forward slash -- this isn't a Windows filesystem path. :-)
>=20
Okay, agreed.
> > + - fsl-max-time-slots
> > + Usage: required
> > + Value type: <u32>
> > + Definition: Maximum number of 8-bit time slots in one TDM frame.
> > + This is the maximum number which TDM hardware supports.
>=20
> fsl,tdm-max-time-slots
Sure. This again got missed.
>=20
> > +
> > +EXAMPLE
> > +
> > + tdm@16000 {
> > + device_type =3D "tdm";
>=20
> No device_type
Okay.
>=20
> > + compatible =3D "fsl,p1010-tdm", "fsl,mpc8315-tdm";
> > + reg =3D <0x16000 0x200 0x2c000 0x2000>;
> > + clock-frequency =3D <0>;
>=20
> Show a real clock-frequency, perhaps with a comment saying it's typically
> filled in by boot software.
Okay.
>=20
> > + interrupts =3D <16 8 62 8>;
> > + phy-handle =3D <zarlink1>
>=20
> That phy-handle is invalid syntax, perhaps you meant:
>=20
> phy-handle =3D <&zarlink1>;
Yes. Will correct it.
>=20
> > + fsl-max-time-slots =3D <128>
>=20
> Missing semicolons on the last two properties.
>=20
Ok.
> -Scott
^ permalink raw reply
* Re: issues calling of_platform_bus_probe() twice
From: Grant Likely @ 2012-03-17 7:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala
Cc: devicetree-discuss@lists.ozlabs.org Discuss,
linuxppc-dev@lists.ozlabs.org list, Timur Tabi
In-Reply-To: <1331933034.3105.171.camel@pasglop>
On Sat, 17 Mar 2012 08:23:54 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2012-03-16 at 16:21 -0500, Kumar Gala wrote:
> > Guys,
> >
> > Are you aware of any reason that we can't call of_platform_bus_probe()
> > or multiple times. Timur's run into an issue in which all devices
> > don't get registered properly if we call of_platform_bus_probe() times
> > with different of_device_id struct's.
>
> Nothing comes to mind... Grant ?
Neither for me. Should work.
g.
^ permalink raw reply
* RE: [PATCH] p1010rdb: gianfar config does not have queues.
From: Aggrwal Poonam-B10812 @ 2012-03-17 5:37 UTC (permalink / raw)
To: Kumar Gala, Chauhan Pankaj-B32944, Srivastava Rajan-B34330
Cc: PPC list, U Bhaskar-B22300, Robin Holt, Eric Dumazet
In-Reply-To: <22426CFF-79AE-4F2B-86C2-EB90F70630B0@kernel.crashing.org>
Hello Pankaj, Rajan
DO you have any comments on the below patch of gianfar?
> > - fsl,num_rx_queues =3D <0x8>;
> > - fsl,num_tx_queues =3D <0x8>;
Have been removed from P1010RDB device tree to avoid a kernel panic.
Kumar, as such I see this is the old dts format. Also in the latest sdk tre=
e these properties are defined, not sure it is working on P1010RDB.
I can check on this and get back.
Regards
Poonam
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, March 16, 2012 8:50 PM
> To: Aggrwal Poonam-B10812
> Cc: Robin Holt; U Bhaskar-B22300; PPC list; Eric Dumazet
> Subject: Re: [PATCH] p1010rdb: gianfar config does not have queues.
>=20
>=20
> On Aug 11, 2011, at 9:25 AM, Robin Holt wrote:
>=20
> > If I have the the fsl,num_rx_queues and fsl,num_tx_queues properties
> > defined in the p1010's device tree file, I get a kernel panic very
> > shortly after boot. The failure indicates we are configuring the
> > gianfar.c driver for a queue depth greater than actual. Removing the
> > properties got the problem resolved.
> >
> > Signed-off-by: Robin Holt <holt@sgi.com>
> > To: U Bhaskar-B22300 <B22300@freescale.com>
> > Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
>=20
> Poonam,
>=20
> Can you comment on this patch, does it look correct?
>=20
> - k
>=20
> >
> > diff --git a/arch/powerpc/boot/dts/p1010si.dtsi
> > b/arch/powerpc/boot/dts/p1010si.dtsi
> > index 7f51104..91566aa 100644
> > --- a/arch/powerpc/boot/dts/p1010si.dtsi
> > +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> > @@ -258,8 +258,6 @@
> > device_type =3D "network";
> > model =3D "eTSEC";
> > compatible =3D "fsl,etsec2";
> > - fsl,num_rx_queues =3D <0x8>;
> > - fsl,num_tx_queues =3D <0x8>;
> > local-mac-address =3D [ 00 00 00 00 00 00 ];
> > interrupt-parent =3D <&mpic>;
> >
> > @@ -280,8 +278,6 @@
> > device_type =3D "network";
> > model =3D "eTSEC";
> > compatible =3D "fsl,etsec2";
> > - fsl,num_rx_queues =3D <0x8>;
> > - fsl,num_tx_queues =3D <0x8>;
> > local-mac-address =3D [ 00 00 00 00 00 00 ];
> > interrupt-parent =3D <&mpic>;
> >
> > @@ -302,8 +298,6 @@
> > device_type =3D "network";
> > model =3D "eTSEC";
> > compatible =3D "fsl,etsec2";
> > - fsl,num_rx_queues =3D <0x8>;
> > - fsl,num_tx_queues =3D <0x8>;
> > local-mac-address =3D [ 00 00 00 00 00 00 ];
> > interrupt-parent =3D <&mpic>;
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ 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