TDM driver
Hi, I am working on Custom MPC8360 Target board. I have four devices connected through the TDM interface. Does any one has written TDM driver for this Processor. I have seen some patches for MPC8323. Is this TDM driver is included in any latest versions of kernel. Regards Surendra ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: TDM driver
Surendra, I've worked on TDM drivers on MPC8360 for a custom board. You could send the patches for verification. - Srivatsan 2008/9/11 <[EMAIL PROTECTED]> > Hi, > > I am working on Custom MPC8360 Target board. > I have four devices connected through the TDM interface. > Does any one has written TDM driver for this Processor. > I have seen some patches for MPC8323. Is this TDM driver is included in > any latest versions of kernel. > > Regards > Surendra > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- - Srivatsan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: TDM driver
Hi Srivatsan, I have got these patches in google. i have not yet used these for MPV8360. If you have already workded on TDM drivers for MPC8360. Can you please send me the driver code . Regards Surendra > Surendra, > > I've worked on TDM drivers on MPC8360 for a custom board. You could send > the > patches for verification. > > - Srivatsan > > 2008/9/11 <[EMAIL PROTECTED]> > >> Hi, >> >> I am working on Custom MPC8360 Target board. >> I have four devices connected through the TDM interface. >> Does any one has written TDM driver for this Processor. >> I have seen some patches for MPC8323. Is this TDM driver is included in >> any latest versions of kernel. >> >> Regards >> Surendra >> >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> > > > > -- > - Srivatsan > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] UCC TDM driver for QE based MPC83xx platforms.
From: Poonam Agarwal-b10812 <[EMAIL PROTECTED]>
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of devices
to receive TDM data demultiplex it and send to upper modules. At the
transmit end it receives data for different channels multiplexes it and
sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
which does multiplexing and demultiplexing, UCC to perform SDMA between
host buffers and the TSA, CMX to connect TSA to UCC.
It can be used by a kernel module which can call tdm_register_client to
get access to a TDM device.
The driver is right now a misc driver with no subsystem as such.
There can be a platform independent TDM layer which is planned to be
done after this. TDM bus sort of thing.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of a TDM
client to bind with a TDM device, a free driver instance is allocated to
the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is of
type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- client_id: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to be
used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the client
keeps on sleeping, and the TDM driver wakes it up periodically. The driver
is configured to
wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
This driver will run on MPC8323E-RDB platforms.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig | 14 +
drivers/misc/Makefile |1 +
drivers/misc/ucc_tdm.c | 1000
drivers/misc/ucc_tdm.h | 221 +++
4 files changed, 1236 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ucc_tdm.c
create mode 100644 drivers/misc/ucc_tdm.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..628b14b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -232,4 +232,18 @@ config ATMEL_SSC
If unsure, say N.
+config UCC_TDM
+ bool "Freescale UCC TDM Driver"
+ depends on QUICC_ENGINE && UCC_FAST
+ default n
+ ---help---
+ The TDM driver is for UCC based TDM devices for example, TDM device on
+ MPC832x RDB. Select it to run PowerVoIP on MPC832x RDB board.
+ The TDM driver can interface with SLIC kind of devices to transmit
+ and receive TDM samples. The TDM driver receives Time Division
+ multiplexed samples(for different channels) from the SLIC device,
+ demutiplexes them and sends them to the upper layers. At the transmit
+ end the TDM drivers receives samples for different channels, it
+ multiplexes them and sends them to the SLIC device.
+
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 87f2685..6f0c49d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
obj-$(CONFIG_FUJITSU_LAPTOP) += fujitsu-laptop.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
+obj-$(CONFIG_UCC_TDM) += ucc_tdm.o
diff --git a/drivers/misc/ucc_tdm.c b/drivers/misc/ucc_tdm.c
new file mode 100644
index 000..98e7c72
--- /dev/null
+++ b/drivers/misc/ucc_tdm.c
@@ -0,0 +1,1000 @@
+/*
+ * drivers/misc/ucc_tdm.c
+ *
+ * UCC Based Linux TDM Driver
+ * This driver is designed to support UCC based TDM for PowerPC processors.
+ * This driver can interface with SLIC device to run VOIP kind of
+ * applications.
+ *
+ * Author: Ashish Kalra & Poonam Aggrwal
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms
FW: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Gala Kumar
Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard
Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout
-b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update
origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All
The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some other client as such. Please suggest on this.
But you are right as far as Freescale PowerPC platforms are concerned
which have TDM devices. Like, 8315 also has a TDM driver which also
exposes similar interface as 8323 because the client it is talking to is
the same.
Following is the small description of the TDM driver along with
interface details:
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of
the TDM client to bind with a TDM device, a free driver instance is
allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 driver_handle;
u32 (*tdm_read)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 driver_handle, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data form a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients
through some APIs.
I need your feedback on the interface details. Some changes were
suggested by Andrew for 32 bit tdm handle which I will modify.(Thanks
Andrew)
Please give your ideas about a TDM framework in the kernel and the
interface.
Waiting for your feedback.
Thanks and Regards
Poonam
-Original Message-
From: Kumar Gala [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 9:01 AM
To: Andrew Morton
Cc: Phillips Kim; Aggrwal Poonam; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Barkowski Michael;
Kalra Ashish; Cutler Richard
Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:
> On Mon, 14 Jan 2008 12:00:51 -0600
> Kim Phillips <[EMAIL PROTECTED]> wrote:
>
>> On Thu, 10 Jan 2008 21:41:20 -0700
>> "Aggrwal Poonam" <[EMAIL PROTECTED]> wrote:
>>
>>> Hello All
>>>
>>> I am waiting for more feedback on the patches.
>>>
>>> If there are no objections please consider them for 2.6.25.
>>>
>> if this isn't going to go through Alessandro Rubini/misc drivers, can
>> it go through the akpm/mm tree?
>>
>
> That would work. But it might be more appropriate to go Kumar-
> >paulus->Linus.
I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about
the driver itself. I'm wondering if we need a TDM framework in the
kernel.
I guess if Poonam could possibly describe how this driver is actually
used that would be helpful. I see we have 8315 with a discrete TDM
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM
as well.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Fri, 2008-01-18 at 17:28 +0530, Aggrwal Poonam wrote:
> Hello All
>
> The TDM driver just now does not have a proper framework. Probably the
> interface cannot be generalised as such. Hence we could not decide
> whether it would be right to think of a TDM framework. Infact the
> interface this TDM driver(for MPC8323ERDB) supplies may not be usable
> for some other client as such. Please suggest on this.
>
> But you are right as far as Freescale PowerPC platforms are concerned
> which have TDM devices. Like, 8315 also has a TDM driver which also
> exposes similar interface as 8323 because the client it is talking to is
> the same.
>
> Following is the small description of the TDM driver along with
> interface details:
>
> The dts file keeps a track of the TDM devices present on the board.
> Depending on them the TDM driver initializes those many driver instances
> while coming up.
>
> The driver on the upper level can plug to more than one tdm clients
> depending on the availablity of TDM devices. At every new request of
> the TDM client to bind with a TDM device, a free driver instance is
> allocated to the client.
>
> The interface can be described as follows.
>
> tdm_register_client(struct tdm_client *)
> This API returns a pointer to the structure tdm_client which is
> of type
> struct tdm_client {
> u32 driver_handle;
> u32 (*tdm_read)(u32 driver_handle, short chn_id, short
> *pcm_buffer, short len);
> u32 (*tdm_write)(u32 driver_handle, short chn_id, short
> *pcm_buffer, short len);
> wait_queue_head_t *wakeup_event;
> }
>
>It consists of:
>- driver_handle: It is basically to identify the particular TDM
> device/driver instance.
>- tdm_read: It is a function pointer returned by the TDM driver to be
> used to read TDM data form a particular TDM channel.
>- tdm_write: It is a function pointer returned by the TDM driver to
> be used to write TDM data to a particular TDM channel.
>- wakeup_event: It is address of a wait_queue event on which the
> client keeps on sleeping, and the TDM driver wakes it up periodically.
> The driver is configured to wake up the client after every 10ms.
>
> Once the TDM client gets registered to a TDM driver instance and a TDM
> device, it interfaces with the driver using tdm_read, tdm_write and
> wakeup_event.
>
> Note: The TDM driver can be used by only kernel level modules. The
> driver does not expose any file interface for User Applications. Can be
> compared to the spi driver which interfaces with the SPI clients
> through some APIs.
>
>
> I need your feedback on the interface details. Some changes were
> suggested by Andrew for 32 bit tdm handle which I will modify.(Thanks
> Andrew)
>
> Please give your ideas about a TDM framework in the kernel and the
> interface.
>
> Waiting for your feedback.
>
> Thanks and Regards
> Poonam
Hi Poonam
I may have to write a HDLC over QMC driver for 832x in the near future.
Although I haven't looked at much at the UCCs programming i/f I noticed
that QMC is supposed to run over TDM. Is your TDM driver suitable for
hooking up such a driver on top?
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] UCC TDM driver for QE based MPC83xx platforms.
On Thu, 24 Jan 2008 10:16:42 +0530 (IST) Poonam_Aggrwal-b10812 <[EMAIL
PROTECTED]> wrote:
>
> +static int ucc_tdm_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct device_node *np = ofdev->node;
> + struct resource res;
> + const unsigned int *prop;
> + u32 ucc_num, device_num, err, ret = 0;
> + struct device_node *np_tmp = NULL;
You don't need to initialise this.
> + dma_addr_t physaddr;
> + void *tdm_buff;
> + struct ucc_tdm_info *ut_info;
> +
> + prop = of_get_property(np, "device-id", NULL);
You should check for (prop == NULL).
> + ucc_num = *prop - 1;
> + if ((ucc_num < 0) || (ucc_num > 7))
> + return -ENODEV;
> +
> + ut_info = &utdm_info[ucc_num];
> + if (ut_info == NULL) {
This cannot be NULL as you have just taken the address of an array
element.
> + tdm_ctrl[device_num]->ut_info = ut_info;
> +
> + tdm_ctrl[device_num]->ut_info->uf_info.ucc_num = ucc_num;
^
This is the same as "ut_info".
> + tdm_ctrl[device_num]->ut_info->uf_info.tdm_tx_clk =
> + (char *) of_get_property(np, "fsl,tdm-tx-clk", NULL);
^
We don't normall put spaces here.
> + tdm_ctrl[device_num]->ut_info->uf_info.tdm_rx_clk =
> + (char *) of_get_property(np, "fsl,tdm-rx-clk", NULL);
^
Ditto. And later as well.
> + tdm_ctrl[device_num]->ut_info->uf_info.irq =
> + irq_of_parse_and_map(np, 0);
> + err = of_address_to_resource(np, 0, &res);
> + if (err) {
> + ret = EINVAL;
This should be -EINVAL or err.
> + goto get_property_error;
You need to do something about unmapping the irq in the error path.
> + tdm_ctrl[device_num]->uf_regs = of_iomap(np, 0);
> +
> + np_tmp = of_find_compatible_node(np_tmp, "slic", "legerity-slic");
> + if (np_tmp != NULL)
> + tdm_ctrl[device_num]->leg_slic = 1;
> + else
> + tdm_ctrl[device_num]->leg_slic = 0;
of_node_ut(np_tmp);
> + tdm_buff = dma_alloc_coherent(NULL, 2 * NR_BUFS * SAMPLE_DEPTH *
> + tdm_ctrl[device_num]->cfg_ctrl.active_num_ts,
> + &physaddr, GFP_KERNEL);
> + if (!tdm_buff) {
> + printk(KERN_ERR "ucc-tdm: could not allocate buffer"
> + "descriptors\n");
> + ret = -ENOMEM;
> + goto get_property_error;
You need to unmap the uf_regs in the error path.
> +get_property_error:
> + kfree(tdm_ctrl[device_num]);
Do you need to set "tdm_ctrl[device_num]" to NULL and decrement
num_tdm_devices?
> + return ret;
> +}
> +
> +static int ucc_tdm_remove(struct of_device *ofdev)
> +{
> + struct tdm_ctrl *tdm_c;
> + struct ucc_tdm_info *ut_info;
> + u32 ucc_num;
> +
> + tdm_c = dev_get_drvdata(&(ofdev->dev));
dev_set_drvdata(&of_dev->dev, NULL);
> + ucc_num = tdm_c->ut_info->uf_info.ucc_num;
> + ut_info = &utdm_info[ucc_num];
> + tdm_stop(tdm_c);
> + tdm_deinit(tdm_c);
> +
> + ucc_fast_free(tdm_c->uf_private);
> +
> + dma_free_coherent(NULL, 2 * NR_BUFS * SAMPLE_DEPTH *
> + tdm_c->cfg_ctrl.active_num_ts,
> + tdm_c->tdm_input_data,
> + tdm_c->dma_input_addr);
> +
You need to unmap the uf_reg and the irq.
> +static struct of_device_id ucc_tdm_match[] = {
const, please.
> + {
> + .type = "tdm",
> + .compatible = "fsl,ucc-tdm",
> + }, {},
We euld normall format this like:
{ .type = "tdm", .compatible = "fsl,ucc-tdm", },
{},
> +static struct of_platform_driver ucc_tdm_driver = {
.driver = {
> + .name = DRV_NAME,
},
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpf2TDW8prWJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] UCC TDM driver for QE based MPC83xx platforms.
Stephen Rothwell wrote: >> +tdm_ctrl[device_num]->ut_info->uf_info.tdm_tx_clk = >> +(char *) of_get_property(np, "fsl,tdm-tx-clk", NULL); > ^ > We don't normall put spaces here. Since when? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of devices
to receive TDM data demultiplex it and send to upper applications. At the
transmit end it receives data for different channels multiplexes it and
sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
which does multiplexing and demultiplexing, UCC to perform SDMA between
host buffers and the TSA, CMX to connect TSA to UCC.
This driver will run on MPC8323E-RDB platforms.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig | 21 +
drivers/misc/Makefile |1 +
drivers/misc/ucc_tdm.c | 1068
drivers/misc/ucc_tdm.h | 227 ++
4 files changed, 1317 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ucc_tdm.c
create mode 100644 drivers/misc/ucc_tdm.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..698a72c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -219,6 +219,27 @@ config THINKPAD_ACPI_BAY
If you are not sure, say Y here.
+config UCC_TDM
+ bool "Freescale UCC TDM Driver"
+ depends on QUICC_ENGINE && UCC_FAST
+ default n
+ ---help---
+ The TDM driver is for UCC based TDM devices for example, TDM device on
+ MPC832x RDB. Select it to run PowerVoIP on MPC832x RDB board.
+ The TDM driver can interface with SLIC kind of devices to transmit
+ and receive TDM samples. The TDM driver receives Time Division
+ multiplexed samples(for different channels) from the SLIC device,
+ demutiplexes them and sends them to the upper layers. At the transmit
+ end the TDM drivers receives samples for different channels, it
+ multiplexes them and sends them to the SLIC device.
+
+config TDM_LINEAR_PCM
+ bool "Linear PCM mode"
+ depends on UCC_TDM
+ ---help---
+ This mode should be selected if the TDM driver interface with the
+ SLIC device is linear PCM(e.g. 16 bit samples). If not selected the
+ interface will be 8 bit u-law.
config ATMEL_SSC
tristate "Device driver for Atmel SSC peripheral"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 87f2685..6f0c49d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
obj-$(CONFIG_FUJITSU_LAPTOP) += fujitsu-laptop.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
+obj-$(CONFIG_UCC_TDM) += ucc_tdm.o
diff --git a/drivers/misc/ucc_tdm.c b/drivers/misc/ucc_tdm.c
new file mode 100644
index 000..232d537
--- /dev/null
+++ b/drivers/misc/ucc_tdm.c
@@ -0,0 +1,1068 @@
+/*
+ * drivers/misc/ucc_tdm.c
+ *
+ * UCC Based Linux TDM Driver
+ * This driver is designed to support UCC based TDM for PowerPC processors.
+ * This driver can interface with SLIC device to run VOIP kind of
+ * applications.
+ *
+ * Author: Ashish Kalra & Poonam Aggrwal
+ *
+ * Copyright (c) 2007 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ucc_tdm.h"
+#define DRV_DESC "Freescale QE UCC TDM Driver"
+#define DRV_NAME "ucc_tdm"
+
+/*
+ * define the following #define if snooping or hardware-based cache coherency
+ * is disabled on the UCC transparent controller.This flag enables
+ * software-based cache-coherency support by explicitly flushing data cache
+ * contents after setting up the TDM output buffer(s) and invalidating the
+ * data cache contents before the TDM input buffer(s) are read.
+ */
+#undef UCC_CACHE_SNOOPING_DISABLED
+
+#define MAX_NUM_TDM_DEVICES 8
+
+static struct tdm_ctrl *tdm_ctrl[MAX_NUM_TDM_DEVICES];
+
+static int num_tdm_devices;
+static int num_tdm_clients;
+
+#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1))
+#define NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
+
+static struct ucc_tdm_info utdm_primary_info = {
+ .uf_info = {
+ .tsa = 1,
+ .cdp = 1,
+ .cds = 1,
+ .ctsp = 1,
+
[PATCH 3/3] Modified Documentation to explain dts entries for UCC TDM driver.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
Modified Documentation to explain new properties introduced for UCC TDM
driver. Also two new nodes have been added "brg" and "clocks" to configure
a BRG from device tree.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 96 +-
1 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..94a6b4b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1613,8 +1613,8 @@ platforms are moved over to use the flattened-device-tree
model.
Required properties:
- device_type : should be "network", "hldc", "uart", "transparent"
-"bisync" or "atm".
- - compatible : could be "ucc_geth" or "fsl_atm" and so on.
+"bisync", "atm" or "tdm".
+ - compatible : could be "ucc_geth", "fsl_atm" or "fsl,ucc_tdm" and so on.
- model : should be "UCC".
- device-id : the ucc number(1-8), corresponding to UCCx in UM.
- reg : Offset and length of the register set for the device
@@ -1666,7 +1666,44 @@ platforms are moved over to use the
flattened-device-tree model.
pio-handle = <140001>;
};
+ Required properties for tdm device_type:
+ - instead of tx-clock and rx-clock following clock properties are
+ required:
+ - fsl,tdm-tx-clk : This property selects the TX clock source for TDM
+ from a bank of clocks.
+ - fsl,tdm-rx-clk : This property selects the RX clock source for TDM
+ from a bank of clocks.
+ - fsl,tdm-tx-sync : This property selects the TX Frame sync source
+ for TDM from a bank of clocks.
+ - fsl,tdm-rx-sync : This property selects the TX Frame sync source
+ for TDM from a bank of clocks.
+
+ All the above mentioned properties are string type with possible
+ values
+ "CLK1", "CLK2", "CLK3"..."CLK24" and so on
+ "BRG1", "BRG2", "BRG3"..."BRG16" and so on
+
+ - fsl,tdm-num : TDM to be used (1,2,3 or 4 for TDMA TDMB TDMC TDMD)
+ - fsl,si-num : Serial Interface to be used.
+ Example:
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
v) Parallel I/O Ports
This node configures Parallel I/O ports for CPUs with QE support.
@@ -1772,6 +1809,61 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ viii) Clocks (clocks)
+ This node specifies the frequency values for all the external clocks
+ viz CLK1 to CLK24 in Hz.
+
+ Required Properties:
+ - compatible : should be "fsl,cpm-clocks".
+ - #clock-cells : It specifies the number of cells occupied by clock-frequency
+property. Currently #clock-cells = 1 is only supported and implemented.
+This property is kept for future in case we need frequencies higher than
+4 GHz.
+ - clock-frequency : It is a list of u32 values to represent the frequency
+of each external clock(CLK1 to CLK24) in Hz.Each entry occupies
+number of cells specified by #clock-cells property(1 for now).
+
+ Example:
+
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ #clock-cells = <1>;
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+*/
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ ix) Baud Rate Generator (BRG)
+
+ Required properties:
+ - compatible : shpuld be "fsl,cpm-brg"
+ - fsl,brg-sources : def
Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <[EMAIL PROTECTED]> wrote:
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> The UCC TDM driver basically multiplexes and demultiplexes data from
> different channels. It can interface with for example SLIC kind of devices
> to receive TDM data demultiplex it and send to upper applications. At the
> transmit end it receives data for different channels multiplexes it and
> sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
> which does multiplexing and demultiplexing, UCC to perform SDMA between
> host buffers and the TSA, CMX to connect TSA to UCC.
>
> This driver will run on MPC8323E-RDB platforms.
>
> ...
>
> +#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1))
> +#define NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info = {
> + .uf_info = {
> + .tsa = 1,
> + .cdp = 1,
> + .cds = 1,
> + .ctsp = 1,
> + .ctss = 1,
> + .revd = 1,
> + .urfs = 0x128,
> + .utfs = 0x128,
> + .utfet = 0,
> + .utftt = 0x128,
> + .ufpt = 256,
> + .ttx_trx = UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc = UCC_FAST_TX_ENCODING_NRZ,
> + .renc = UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc = UCC_FAST_16_BIT_CRC,
> + .synl = UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy = 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c)
> +{
> +#if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts = tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log)
> +{
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp = log ^ 0xFF;
> + sign = (temp & 0x80) >> 7;
> + segment = (temp & 0x70) >> 4;
> + quant = temp & 0x0F;
> + quant <<= 1;
> + quant += 33;
> + quant <<= segment;
> + if (sign)
> + val = 33 - quant;
> + else
> + val = quant - 33;
> +
> + val *= 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear)
> +{
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret = 0;
> + if (linear >= 0)
> + linear = (linear >> 2);
> + else
> + linear = (0xc000 | (linear >> 2));
> +
> + absol = abs(linear) + 33;
> + temp = absol;
> + sign = (linear >= 0) ? 1 : 0;
> + for (i = 0; i < 16; i++) {
> + output = temp & 0x8000;
> + if (output)
> + break;
> + temp <<= 1;
> + }
> + segment = 11 - i;
> + quant = (absol >> segment) & 0x0F;
> + segment--;
> + segment <<= 4;
> + output = segment + quant;
> + if (absol > 8191)
> + output = 0x7F;
> + if (sign)
> + ret ^= 0xFF;
> + else
> +
RE: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx platforms.
Thanks Morton for your comments,
I shall incorporate them and reesnd the patch.
With Regards
Poonam
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 2:45 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Barkowski Michael; Phillips Kim; Kalra Ashish;
Cutler Richard
Subject: Re: [PATCH 1/3] drivers/misc :UCC based TDM driver for MPC83xx
platforms.
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 <[EMAIL PROTECTED]> wrote:
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> The UCC TDM driver basically multiplexes and demultiplexes data from
> different channels. It can interface with for example SLIC kind of
> devices to receive TDM data demultiplex it and send to upper
> applications. At the transmit end it receives data for different
> channels multiplexes it and sends them on the TDM channel. It
> internally uses TSA( Time Slot Assigner) which does multiplexing and
> demultiplexing, UCC to perform SDMA between host buffers and the TSA,
CMX to connect TSA to UCC.
>
> This driver will run on MPC8323E-RDB platforms.
>
> ...
>
> +#define PREV_PHASE(x) ((x == 0) ? MAX_PHASE : (x - 1)) #define
> +NEXT_PHASE(x) (((x + 1) > MAX_PHASE) ? 0 : (x + 1))
These macros can reference their arg more than once and are hence
dangerous. What does PREV_PHASE(foo++) do to foo?
And, in general: do not implement in cpp that which could have been
implemented in C.
> +static struct ucc_tdm_info utdm_primary_info = {
> + .uf_info = {
> + .tsa = 1,
> + .cdp = 1,
> + .cds = 1,
> + .ctsp = 1,
> + .ctss = 1,
> + .revd = 1,
> + .urfs = 0x128,
> + .utfs = 0x128,
> + .utfet = 0,
> + .utftt = 0x128,
> + .ufpt = 256,
> + .ttx_trx =
UCC_FAST_GUMR_TRANSPARENT_TTX_TRX_TRANSPARENT,
> + .tenc = UCC_FAST_TX_ENCODING_NRZ,
> + .renc = UCC_FAST_RX_ENCODING_NRZ,
> + .tcrc = UCC_FAST_16_BIT_CRC,
> + .synl = UCC_FAST_SYNC_LEN_NOT_USED,
> + },
> + .ucc_busy = 0,
> +};
> +
> +static struct ucc_tdm_info utdm_info[8];
> +
> +static void dump_siram(struct tdm_ctrl *tdm_c) { #if defined(DEBUG)
Microscopic note: kernel code tends to do
#ifdef FOO
if only one identifier is being tested and
#if defined(FOO) && defined(BAR)
if more than one is being tested.
There is no rational reason for this ;)
> + int i;
> + u16 phy_num_ts;
> +
> + phy_num_ts = tdm_c->physical_num_ts;
> +
> + pr_debug("SI TxRAM dump\n");
> + /* each slot entry in SI RAM is of 2 bytes */
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.tx[i]));
> + pr_debug("\nSI RxRAM dump\n");
> + for (i = 0; i < phy_num_ts * 2; i++)
> + pr_debug("%x ", in_8(&qe_immr->sir.rx[i]));
> + pr_debug("\n");
> +#endif
> +}
> +
> +/*
> + * converts u-law compressed samples to linear PCM
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver receives u-law compressed data from the
> + * SLIC device. This function converts the compressed
> + * data to linear PCM and sends it to upper layers.
> + */
> +static inline int ulaw2int(unsigned char log) {
> + u32 sign, segment, temp, quant;
> + int val;
> +
> + temp = log ^ 0xFF;
> + sign = (temp & 0x80) >> 7;
> + segment = (temp & 0x70) >> 4;
> + quant = temp & 0x0F;
> + quant <<= 1;
> + quant += 33;
> + quant <<= segment;
> + if (sign)
> + val = 33 - quant;
> + else
> + val = quant - 33;
> +
> + val *= 4;
> + return val;
> +}
> +
> +/*
> + * converts linear PCM samples to u-law compressed format.
> + * If the CONFIG_TDM_LINEAR_PCM flag is not set the
> + * TDM driver calls this function to convert the PCM samples
> + * to u-law compressed format before sending them to SLIC
> + * device.
> + */
> +static inline u8 int2ulaw(short linear) {
> + u8 quant, ret;
> + u16 output, absol, temp;
> + u32 i, sign;
> + char segment;
> +
> + ret = 0;
> + if (linear >= 0)
> + linear = (linear >> 2);
> + else
> + linear = (0xc000 | (linear >> 2));
> +
> + absol = abs(linear) + 33;
> + temp = absol;
> + sign = (linear >= 0) ? 1 : 0;
> + for (i = 0; i < 16; i++) {
> + outpu
[PATCH] Platform Changes for UCC TDM driver for MPC8323ERDB. Also includes related QE changes.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
Incorporated comments of Stephen and Tabi. Please review if they look
fine.
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 205 --
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 568 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:[EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+* #clock-cells define number of cells
+* used by the clock-frequency.
+* right now only #clock cells=1 is
+* implemented. Provision is there to
+* handle frequencies >4Gig
+*/
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+* 1-24 for CLK1 to CLK24.
+* BRG9 uses CLK11,BRG1 and BRG2-8 use
+* the QE clock.
+*/
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
[EMAIL PROTECTED] {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
[EMAIL PROTECTED] {
device_type = "network";
compatible =
[PATCH UCC TDM 0/3] UCC based TDM driver for QE based MPC83xx platforms
Reworked patches after incorporating comments of Andrew, Stephen and
Tabi and Kumar.
Kumar could you please consider them for linux-2.6.25.
There are three patches
[PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This
driver is usable in VoIP iind of applications to interface with SLIC
kind of devices to exchange TDM voice samples.
The driver is right now in misc category and exposes a kind of non
standard interface to the clients.
TDM Driver Interface Details
The TDM driver right now is a misc driver with no subsystem as such.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices.
At every new request of the TDM client to bind with a TDM device, a free
driver instance is allocated to the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is
of type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- driver_handle: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to
be used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the
client keeps on sleeping, and the TDM driver wakes it up periodically.
The driver is configured to wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
Note: The TDM driver can be used by only kernel level modules. The
driver does not expose any file interface for User Applications. Can be
compared to the spi driver which interfaces with the SPI clients(kernel
mode clients) through some APIs.
This interface can be improved by writing a platform independent TDM
layer. Then all the TDM platforms can be supported below this wrapper
layer. This is planned to be done later.
[PATCH 2/3] arch/ : Platform changes
- device tree entries for UCC TDM driver for MPC8323ERDB platform.
- QE changes related to TDM , like,
1) Modified ucc_fast_init so that it can be used by fast UCC
based TDM driver. Mainly changes have been made to configure TDM clocks
and Fsyncs.
2) Modified get_brg_clk so that it can return the input frequncy
and input source of any BRG by reading the corresponding entries from
device tree.
3) Added new nodes brg and clocks in the device tree which
represent input clocks for different BRGs.
4) Modified qe_setbrg accordingly.
- new device tree entries added for "clocks" and "brg"
[PATCH 3/3] Documentation
- Modified Documentation to explain the device tree entries related to
UCC TDM driver and the new nodes added("clocks" and "brg")
The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24
plus of_doc_update branches.
In brief the steps were
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-galak
git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24
origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update
git pull . for-2.6.24# merge the other two
git pull . for-2.6.25
git checkout -b tdm # clean slate for tdm rebase work
Also after applying the patches changes have to be made corresponding to
Tabi's patch "qe: add function qe_clock_source".
The driver has been tested with a VoIP stack and application on
MPC8323ERDB.
With Regards
Poonam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH UCC TDM 3/3 ] Modified Documentation to explain dts entries for TDM driver
From: Poonam Aggrwal <[EMAIL PROTECTED]>
Modified Documentation to explain new properties introduced for UCC TDM
driver. Also two new nodes have been added "brg" and "clocks" to configure
a BRG from device tree.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 96 +-
1 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..94a6b4b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1613,8 +1613,8 @@ platforms are moved over to use the flattened-device-tree
model.
Required properties:
- device_type : should be "network", "hldc", "uart", "transparent"
-"bisync" or "atm".
- - compatible : could be "ucc_geth" or "fsl_atm" and so on.
+"bisync", "atm" or "tdm".
+ - compatible : could be "ucc_geth", "fsl_atm" or "fsl,ucc_tdm" and so on.
- model : should be "UCC".
- device-id : the ucc number(1-8), corresponding to UCCx in UM.
- reg : Offset and length of the register set for the device
@@ -1666,7 +1666,44 @@ platforms are moved over to use the
flattened-device-tree model.
pio-handle = <140001>;
};
+ Required properties for tdm device_type:
+ - instead of tx-clock and rx-clock following clock properties are
+ required:
+ - fsl,tdm-tx-clk : This property selects the TX clock source for TDM
+ from a bank of clocks.
+ - fsl,tdm-rx-clk : This property selects the RX clock source for TDM
+ from a bank of clocks.
+ - fsl,tdm-tx-sync : This property selects the TX Frame sync source
+ for TDM from a bank of clocks.
+ - fsl,tdm-rx-sync : This property selects the TX Frame sync source
+ for TDM from a bank of clocks.
+
+ All the above mentioned properties are string type with possible
+ values
+ "CLK1", "CLK2", "CLK3"..."CLK24" and so on
+ "BRG1", "BRG2", "BRG3"..."BRG16" and so on
+
+ - fsl,tdm-num : TDM to be used (1,2,3 or 4 for TDMA TDMB TDMC TDMD)
+ - fsl,si-num : Serial Interface to be used.
+ Example:
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
v) Parallel I/O Ports
This node configures Parallel I/O ports for CPUs with QE support.
@@ -1772,6 +1809,61 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ viii) Clocks (clocks)
+ This node specifies the frequency values for all the external clocks
+ viz CLK1 to CLK24 in Hz.
+
+ Required Properties:
+ - compatible : should be "fsl,cpm-clocks".
+ - #clock-cells : It specifies the number of cells occupied by clock-frequency
+property. Currently #clock-cells = 1 is only supported and implemented.
+This property is kept for future in case we need frequencies higher than
+4 GHz.
+ - clock-frequency : It is a list of u32 values to represent the frequency
+of each external clock(CLK1 to CLK24) in Hz.Each entry occupies
+number of cells specified by #clock-cells property(1 for now).
+
+ Example:
+
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ #clock-cells = <1>;
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+*/
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ ix) Baud Rate Generator (BRG)
+
+ Required properties:
+ - compatible : shpuld be "fsl,cpm-brg"
+ - fsl,brg-sources : def
[PATCH UCC TDM 2/3 ]Updated: UCC TDM driver for QE based MPC83xx platforms.
Incorporated Stephen's comments.
From: Poonam Agarwal-b10812 <[EMAIL PROTECTED]>
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of devices
to receive TDM data demultiplex it and send to upper modules. At the
transmit end it receives data for different channels multiplexes it and
sends them on the TDM channel. It internally uses TSA( Time Slot Assigner)
which does multiplexing and demultiplexing, UCC to perform SDMA between
host buffers and the TSA, CMX to connect TSA to UCC.
It can be used by a kernel module which can call tdm_register_client to
get access to a TDM device.
The driver is right now a misc driver with no subsystem as such.
There can be a platform independent TDM layer which is planned to be
done after this. TDM bus sort of thing.
The dts file keeps a track of the TDM devices present on the board.
Depending on them the TDM driver initializes those many driver instances
while coming up.
The driver on the upper level can plug to more than one tdm clients
depending on the availablity of TDM devices. At every new request of a TDM
client to bind with a TDM device, a free driver instance is allocated to
the client.
The interface can be described as follows.
tdm_register_client(struct tdm_client *)
This API returns a pointer to the structure tdm_client which is of
type
struct tdm_client {
u32 client_id;
u32 (*tdm_read)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
u32 (*tdm_write)(u32 client_id, short chn_id, short
*pcm_buffer, short len);
wait_queue_head_t *wakeup_event;
}
It consists of:
- client_id: It is basically to identify the particular TDM
device/driver instance.
- tdm_read: It is a function pointer returned by the TDM driver to be
used to read TDM data from a particular TDM channel.
- tdm_write: It is a function pointer returned by the TDM driver to be
used to write TDM data to a particular TDM channel.
- wakeup_event: It is address of a wait_queue event on which the client
keeps on sleeping, and the TDM driver wakes it up periodically. The driver
is configured to
wake up the client after every 10ms.
Once the TDM client gets registered to a TDM driver instance and a TDM
device, it interfaces with the driver using tdm_read, tdm_write and
wakeup_event.
This driver will run on MPC8323E-RDB platforms.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig | 14 +
drivers/misc/Makefile |1 +
drivers/misc/ucc_tdm.c | 1017
drivers/misc/ucc_tdm.h | 221 +++
4 files changed, 1253 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ucc_tdm.c
create mode 100644 drivers/misc/ucc_tdm.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b5e67c0..628b14b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -232,4 +232,18 @@ config ATMEL_SSC
If unsure, say N.
+config UCC_TDM
+ bool "Freescale UCC TDM Driver"
+ depends on QUICC_ENGINE && UCC_FAST
+ default n
+ ---help---
+ The TDM driver is for UCC based TDM devices for example, TDM device on
+ MPC832x RDB. Select it to run PowerVoIP on MPC832x RDB board.
+ The TDM driver can interface with SLIC kind of devices to transmit
+ and receive TDM samples. The TDM driver receives Time Division
+ multiplexed samples(for different channels) from the SLIC device,
+ demutiplexes them and sends them to the upper layers. At the transmit
+ end the TDM drivers receives samples for different channels, it
+ multiplexes them and sends them to the SLIC device.
+
endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 87f2685..6f0c49d 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
obj-$(CONFIG_FUJITSU_LAPTOP) += fujitsu-laptop.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
+obj-$(CONFIG_UCC_TDM) += ucc_tdm.o
diff --git a/drivers/misc/ucc_tdm.c b/drivers/misc/ucc_tdm.c
new file mode 100644
index 000..2181132
--- /dev/null
+++ b/drivers/misc/ucc_tdm.c
@@ -0,0 +1,1017 @@
+/*
+ * drivers/misc/ucc_tdm.c
+ *
+ * UCC Based Linux TDM Driver
+ * This driver is designed to support UCC based TDM for PowerPC processors.
+ * This driver can interface with SLIC device to run VOIP kind of
+ * applications.
+ *
+ * Author: Ashish Kalra & Poonam Aggrwal
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
RE: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver
Hi Scott The device tree already has a brg-frequency property in qe node which is the value of BRGCLK. The function get_brg_clk uses this property to find the value of BRGCLK. In case this value is 0(some older u-boots populate bus-frequency property of qe and not the brg-frequency), get_brg_clk uses bus-frequency/2 as BRGCLK. With Regards Poonam -Original Message- From: Wood Scott Sent: Friday, January 25, 2008 1:42 AM To: Aggrwal Poonam Cc: Gala Kumar; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Barkowski Michael; Cutler Richard; Tabi Timur; Kalra Ashish Subject: Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver On Thu, Jan 24, 2008 at 10:24:13AM +0530, Poonam_Aggrwal-b10812 wrote: > + ix) Baud Rate Generator (BRG) > + > + Required properties: > + - compatible : shpuld be "fsl,cpm-brg" > + - fsl,brg-sources : define the input clock for all 16 BRGs. The input > +clock source could be 1 to 24 for CLK1 to CLK24. Zero means that the > +particular BRG will be driven by QE clock(BRGCLK). Should also have a clock-frequency property to specify what BRGCLK is. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver
Aggrwal Poonam wrote: > The device tree already has a brg-frequency property in qe node which > is the value of BRGCLK. Yes, I'm saying it belongs as brg/clock-frequency. :-) CPM1/2 already do this. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dts entries for TDM driver
On Thu, Jan 24, 2008 at 10:24:13AM +0530, Poonam_Aggrwal-b10812 wrote: > + ix) Baud Rate Generator (BRG) > + > + Required properties: > + - compatible : shpuld be "fsl,cpm-brg" > + - fsl,brg-sources : define the input clock for all 16 BRGs. The input > +clock source could be 1 to 24 for CLK1 to CLK24. Zero means that the > +particular BRG will be driven by QE clock(BRGCLK). Should also have a clock-frequency property to specify what BRGCLK is. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 128 ++--
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 492 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..333408c 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:[EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+* #clock-cells define number of cells
+* used by the clock-frequency.
+* right now only #clock cells=1 is
+* implemented. Provision is there to
+* handle frequencies >4Gig
+*/
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+* 1-24 for CLK1 to CLK24.
+* BRG9 uses CLK11,BRG1 and BRG2-8 use
+* the QE clock.
+*/
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
[EMAIL PROTECTED] {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
[EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/q
Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
Poonam_Aggrwal-b10812 wrote:
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency", &size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
> + }
Only very recent versions of U-Boot set the brg-frequency property, so you need
to check for situations where "*prop" is 0. If it is, then you need to take
the
QE's bus-frequency property and divide it by two. See my ucc_uart driver for
an
example.
And PowerPC-specific patches should not be cross-posted to linux-kernel.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812 <[EMAIL
PROTECTED]> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk = 0;
>
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + const unsigned int *prop;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + prop = of_get_property(brg,
> + "fsl,brg-sources", &size);
> +
> + brg_src = *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency", &size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> + "fsl,cpm-clocks");
> + prop = of_get_property(clocks,
> + "#clock-cells", &size);
> + /*
> + * clock-cells = 1 only supported right now.
> + */
> + if (*prop != 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop = of_get_property(clocks,
> + "clock-frequency", &size);
> +
> + brg_input_freq = *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpgeYhuyZRoy.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
Thanx Tabi for your comments.
Sorry I was on leave for the last week, so could not reply in time.
Shall make the changes you suggested and repost the patch.
Regards
Poonam
On 12/11/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
>
> Poonam_Aggrwal-b10812 wrote:
>
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (qe) {
> > + unsigned int size;
> > + prop = of_get_property
> > + (qe, "brg-frequency",
> &size);
> > + of_node_put(qe);
> > + of_node_put(brg);
> > + return *prop;
> > + }
>
> Only very recent versions of U-Boot set the brg-frequency property, so you
> need
> to check for situations where "*prop" is 0. If it is, then you need to
> take the
> QE's bus-frequency property and divide it by two. See my ucc_uart driver
> for an
> example.
>
> And PowerPC-specific patches should not be cross-posted to linux-kernel.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.
Sorry for late reply as I was on leave for the last week.
With Regards
Poonam
-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Gala Kumar; linuxppc-dev@ozlabs.org; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk = 0;
>
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + const unsigned int *prop;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency",
&size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + prop = of_get_property(brg,
> + "fsl,brg-sources", &size);
> +
> + brg_src = *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency",
&size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> + prop = of_get_property(clocks,
> + "#clock-cells", &size);
> + /*
> + * clock-cells = 1 only supported right now.
> + */
> + if (*prop != 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop = of_get_property(clocks,
> + "clock-frequency",
&size);
> +
> + brg_input_freq = *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes and dts entries.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 205 --
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 568 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:[EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+* #clock-cells define number of cells
+* used by the clock-frequency.
+* right now only #clock cells=1 is
+* implemented. Provision is there to
+* handle frequencies >4Gig
+*/
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+* 1-24 for CLK1 to CLK24.
+* BRG9 uses CLK11,BRG1 and BRG2-8 use
+* the QE clock.
+*/
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
[EMAIL PROTECTED] {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
[EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc
Re: [PATCH 2/3] Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes and dts entries.
This patch needs to come before the previous one ("UCC TDM driver for
QE based MPC83xx platforms") as that uses some of the fields defined here.
On Thu, 24 Jan 2008 10:19:44 +0530 (IST) Poonam_Aggrwal-b10812 <[EMAIL
PROTECTED]> wrote:
>
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq = 0;
> + u32 brg_num;
> + int ret;
> + const unsigned int *prop;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source = 0;
> +
> + brg_num = brgclk - QE_BRG1;
> + brg = of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
If you did
if (!brg) {
.
.
goto err;
}
Then you would save indenting all the rest of this function.
> + prop = of_get_property(brg,
> + "fsl,brg-sources", &size);
Join these lines.
> + of_node_put(brg);
> +
> + if (prop)
> + brg_src = *(prop + brg_num);
> + else {
> + printk(KERN_ERR "%s: invalid fsl,brg-sources in device "
> + "tree\n", __FUNCTION__);
> + ret = -EINVAL;
> + goto err;
> + }
> + if (brg_src == 0) {
> + *brg_source = 0;
> + if (brg_clk > 0)
> + return brg_clk;
> + qe = of_find_node_by_type(NULL, "qe");
> + if (qe) {
Again testing (!qe) and jumping to err would save another level if
indentation.
> + unsigned int size;
> + prop = of_get_property
> + (qe, "brg-frequency", &size);
And you wouldn't have to split things like this.
> + if (!prop) {
> + printk(KERN_ERR "%s: QE brg-frequency"
> + "not present in device tree\n",
> + __FUNCTION__);
> + ret = -EINVAL;
> + of_node_put(qe);
> + goto err;
> + }
> + if (*prop) {
> + of_node_put(qe);
> + brg_clk = *prop;
> + return *prop;
> + } else {
This else (and indentation) is unnecessary as you just returned above.
> + } else {
> + *brg_source = brg_src + QE_CLK1 - 1;
> + clocks = of_find_compatible_node(NULL, NULL,
> + "fsl,cpm-clocks");
> + if (!clocks) {
> + printk(KERN_ERR "%s: no clocks node in device"
> + " tree \n", __FUNCTION__);
> + ret = -EINVAL;
> + goto err;
> + } else {
Same here.
> + } else {
> + printk(KERN_ERR "%s: no brg node in device tree\n",
> + __FUNCTION__);
> + ret = -EINVAL;
> + goto err;
This goto is redundant.
> + }
> +err: return ret;
Put the label on a line by itself and indent it one space (that means that
"diff -p will reference the funstion anem instead of the label).
> @@ -152,6 +152,10 @@ struct ucc_fast_info {
> enum ucc_fast_rx_decoding_method renc;
> enum ucc_fast_transparent_tcrc tcrc;
> enum ucc_fast_sync_len synl;
> + char *tdm_rx_clk;
> + char *tdm_tx_clk;
> + char *tdm_rx_sync;
> + char *tdm_tx_sync;
If you make these "const char *" you won't have to cast the results of
of_get_property() that you assign to them.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpUDZFMhyZeO.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Thanks Stephen for your comments, incorporated them.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 184 +--
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 548 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:[EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+* #clock-cells define number of cells
+* used by the clock-frequency.
+* right now only #clock cells=1 is
+* implemented. Provision is there to
+* handle frequencies >4Gig
+*/
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+* 1-24 for CLK1 to CLK24.
+* BRG9 uses CLK11,BRG1 and BRG2-8 use
+* the QE clock.
+*/
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
[EMAIL PROTECTED] {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
[EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
di
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Poonam,
On Thu, Jan 24, 2008 at 04:00:06PM +0530, Poonam_Aggrwal-b10812 wrote:
> Thanks Stephen for your comments, incorporated them.
> From: Poonam Aggrwal <[EMAIL PROTECTED]>
>
> This patch makes necessary changes in the QE and UCC framework to support
> TDM. It also adds support to configure the BRG properly through device
> tree entries. Includes the device tree changes for UCC TDM driver as well.
> It also includes device tree entries for UCC TDM driver.
>
> Tested on MPC8323ERDB platform.
>
> Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
> Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
> Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
> Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
> arch/powerpc/sysdev/qe_lib/qe.c | 184 +--
> arch/powerpc/sysdev/qe_lib/ucc.c | 265
> +
> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
> include/asm-powerpc/qe.h |8 +
> include/asm-powerpc/ucc.h |4 +
> include/asm-powerpc/ucc_fast.h|4 +
> 7 files changed, 548 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> index 388c8a7..c0e6283 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -105,6 +105,17 @@
> device_type = "par_io";
> num-ports = <7>;
>
> + ucc1pio:[EMAIL PROTECTED] {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 0 e 2 0 1 0/* CLK11 */
> + 3 16 1 0 2 0/* BRG9 */
> + 3 1b 1 0 2 0/* BRG3 */
> + 0 0 3 0 2 0/* TDMATxD0 */
> + 0 4 3 0 2 0/* TDMARxD0 */
> + 3 1b 2 0 1 0>; /* CLK1 */
> + };
> +
Can we not introduce new pio-maps in the device trees? There
were debates regarding this, and if I understood everything
correctly, pio-maps considered as a bad taste. Better
do bunch of par_io_config_pin() in the board file. Better
yet fixup the firmware (u-boot) to set up dedicated pins
correctly.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Anton Vorontsov wrote: > Can we not introduce new pio-maps in the device trees? There > were debates regarding this, and if I understood everything > correctly, pio-maps considered as a bad taste. Better > do bunch of par_io_config_pin() in the board file. Better > yet fixup the firmware (u-boot) to set up dedicated pins > correctly. I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. The problem is that the configuration of these pins is board-specific, but pins are used by devices. A device driver can't call par_io_config_pin(), because the calls are different depending on which SoC and which UCC you're using. The platform code can't call par_io_config_pin(), because that configuration depends on which drivers are loaded. In other words, the pin configurations are dependent on the UCC configurations, and the UCC configurations are stored in the device tree. So it makes sense to put the pin configurations in the device tree, too. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 09:55:31AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Can we not introduce new pio-maps in the device trees? There > >were debates regarding this, and if I understood everything > >correctly, pio-maps considered as a bad taste. Better > >do bunch of par_io_config_pin() in the board file. Better > >yet fixup the firmware (u-boot) to set up dedicated pins > >correctly. > > I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls. > The problem is that the configuration of these pins is board-specific, but > pins are used by devices. A device driver can't call par_io_config_pin(), > because the calls are different depending on which SoC and which UCC you're > using. The platform code can't call par_io_config_pin(), because that > configuration depends on which drivers are loaded. Are you saying that TDM is sharing same pins with the other QE device, and we can choose to use/not use some device depending on which driver is loaded? I think this particular board and patch isn't that case. Even if someday there will be the case when drivers are mutually exclusive, i.e. presence of some driver should trigger pins reconfiguration, then anyway this should be handled differently. That is, we should not _register_ two mutually exclusive devices in the first place, so drivers will not probe them. That's board setup code authority, and pins configuration still should happen there. [ Irrelevant to UCCs and this particular case: lately I've encountered one interesting case of Par IO usage. FHCI USB needs switching between pin's dedicated functions and GPIO functions. So, firstly it is using pins as dedicated, and later (at the bus reset) driver turns them to act as GPIOs. This is still handled without pio-map though, via gpios = <> property for that driver. ] > In other words, the pin configurations are dependent on the UCC > configurations, and the UCC configurations are stored in the device tree. > So it makes sense to put the pin configurations in the device tree, too. In that particular case UCC configuration is static, for every UCC. So, we can set up all pins in the firmware/board file. Please correct me if I'm wrong. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Are you saying that TDM is sharing same pins with the other QE device, > >and we can choose to use/not use some device depending on which driver > >is loaded? > > No. I'd have to closely examine the DTS, but I don't think that UCC > devices share pins at all. But that isn't my point. > > >In that particular case UCC configuration is static, for every UCC. > >So, we can set up all pins in the firmware/board file. > > Yes, but deciding what the UCC does might not be static. At what point do > we declare, "UCC5 is for eth0 and eth0 only"? > > The advantage of putting the pin configurations in the device tree is that > they now become configurable. I can envision a scenario where UCC5 could > be either an Ethernet or a UART, depending on the setting of some jumpers > on the board. That's what the QE was designed for: any UCC can do any task, > and you can even have a UCC change its purpose while the system is running. > So I don't want the pin configurations hard-coded into the kernel. Having > them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. > For instance, I have a plan (that I keep postponing) to introduce a new > feature in U-Boot where U-Boot can determine the settings of some board > jumpers and modify the device tree accordingly. The instructions on how to > modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... > I can't > support this feature if the kernel calls par_io_config_pin() regardless of > what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Anton Vorontsov wrote: > Are you saying that TDM is sharing same pins with the other QE device, > and we can choose to use/not use some device depending on which driver > is loaded? No. I'd have to closely examine the DTS, but I don't think that UCC devices share pins at all. But that isn't my point. > In that particular case UCC configuration is static, for every UCC. > So, we can set up all pins in the firmware/board file. Yes, but deciding what the UCC does might not be static. At what point do we declare, "UCC5 is for eth0 and eth0 only"? The advantage of putting the pin configurations in the device tree is that they now become configurable. I can envision a scenario where UCC5 could be either an Ethernet or a UART, depending on the setting of some jumpers on the board. That's what the QE was designed for: any UCC can do any task, and you can even have a UCC change its purpose while the system is running. So I don't want the pin configurations hard-coded into the kernel. Having them in the device tree gives me some flexibility. For instance, I have a plan (that I keep postponing) to introduce a new feature in U-Boot where U-Boot can determine the settings of some board jumpers and modify the device tree accordingly. The instructions on how to modify the device tree would be embedded in the tree itself. I can't support this feature if the kernel calls par_io_config_pin() regardless of what's in the device tree. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: Yes, but > deciding what the UCC does might not be static. At what point do we > declare, "UCC5 is for eth0 and eth0 only"? When the board designer decides to hook eth0 up to UCC5. If the board designer decides to hook multiple devices up to UCC5, we first smack the board designer, and then set it up to whichever configuration has been jumpered. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.
Hello Anton/Tabi I am not sure which is the best place to configure the pins. Because some drivers do it in one way and some in the other. I actually tried to make the driver similar to ucc_geth because it is a QE driver. The driver has no platform code in the platform files similar to ucc_geth. It is probed along with all the QE devices thorugh of_platform_bus_probe. And the pins are configured for all the QE devices using par_io_init. I thought this to be the most consistent way at that time. How should we close this point? Can we go ahead with the pio-map? Infact the discussion in this thread was very good and I got to know a lot of rationales behind this. Please suggest. Thanks and Regards Poonam From: Anton Vorontsov [mailto:[EMAIL PROTECTED] Sent: Thursday, January 24, 2008 10:53 PM To: Tabi Timur Cc: Aggrwal Poonam; Gala Kumar; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Barkowski Michael; Cutler Richard; Kalra Ashish Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries. On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote: > Anton Vorontsov wrote: > > >Are you saying that TDM is sharing same pins with the other QE > >device, and we can choose to use/not use some device depending on > >which driver is loaded? > > No. I'd have to closely examine the DTS, but I don't think that UCC > devices share pins at all. But that isn't my point. > > >In that particular case UCC configuration is static, for every UCC. > >So, we can set up all pins in the firmware/board file. > > Yes, but deciding what the UCC does might not be static. At what > point do we declare, "UCC5 is for eth0 and eth0 only"? > > The advantage of putting the pin configurations in the device tree is > that they now become configurable. I can envision a scenario where > UCC5 could be either an Ethernet or a UART, depending on the setting > of some jumpers on the board. That's what the QE was designed for: any > UCC can do any task, and you can even have a UCC change its purpose while the system is running. > So I don't want the pin configurations hard-coded into the kernel. > Having them in the device tree gives me some flexibility. If hardware configuration is selected at the bootup time, by jumpers or switches, it's even easier to do it right. Without pio-map. > For instance, I have a plan (that I keep postponing) to introduce a > new feature in U-Boot where U-Boot can determine the settings of some > board jumpers and modify the device tree accordingly. The instructions > on how to modify the device tree would be embedded in the tree itself. Why you need to modify the device tree for that? Let the U-Boot simply setup pins for the kernel. Regarding kernel overwriting pins configuration... > I can't > support this feature if the kernel calls par_io_config_pin() > regardless of what's in the device tree. What I've understood from the previous debates, is that ideally kernel should not touch pins' configuration. Today we're using pio-map solely to fix up some old firmware misconfiguration. And we can do this in the board file still. To determine if we need to fixup the firmware or not, we can use some device tree property instead (firmware version?). p.s. I'm neither for pio-map nor against. I just want some consequence regarding this. Last thread ended with consequence that pio-map is a bad thing to use... -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
