* Re: [PATCH 2/2] powerpc: pseries: Use generic dma-window parsing function
From: Olof Johansson @ 2006-05-18 17:13 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933975.516311.850847048300.qpush@pokey>
On Thu, May 18, 2006 at 04:32:55PM +1000, Jeremy Kerr wrote:
> Change the pseries iommu init code to use the new of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Olof Johansson @ 2006-05-18 17:12 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933975.484840.681634501201.qpush@pokey>
On Thu, May 18, 2006 at 04:32:55PM +1000, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
Acked-by: Olof Johansson <olof@lixom.net>
(replied to the wrong email last time)
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Olof Johansson @ 2006-05-18 17:11 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933251.463191.267166640873.qpush@pokey>
On Thu, May 18, 2006 at 04:20:51PM +1000, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Olof Johansson <olof@lixom.net>
(I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
have access to either to make sure it doesn't break there. Main worry
would be if it lacked ibm,#dma*-properties for some reason.)
>
> arch/powerpc/kernel/prom_parse.c | 23 +++++++++++++++++++++++
> include/asm-powerpc/prom.h | 6 ++++++
> 2 files changed, 29 insertions(+)
>
> Index: linux-2.6/arch/powerpc/kernel/prom_parse.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/prom_parse.c
> +++ linux-2.6/arch/powerpc/kernel/prom_parse.c
> @@ -548,3 +548,26 @@ int of_pci_address_to_resource(struct de
> return __of_address_to_resource(dev, addrp, size, flags, r);
> }
> EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size)
> +{
> + u32 *dma_window, cells;
> + unsigned char *prop;
> +
> + dma_window = (u32 *)dma_window_prop;
> +
> + /* busno is always one cell */
> + *busno = *(dma_window++);
> +
> + prop = get_property(dn, "ibm,#dma-address-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
> + *phys = of_read_addr(dma_window, cells);
> +
> + dma_window += cells;
> +
> + prop = get_property(dn, "ibm,#dma-size-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_size_cells(dn);
> + *size = of_read_addr(dma_window, cells);
> +}
> +EXPORT_SYMBOL_GPL(of_parse_dma_window);
> Index: linux-2.6/include/asm-powerpc/prom.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/prom.h
> +++ linux-2.6/include/asm-powerpc/prom.h
> @@ -230,6 +230,12 @@ extern int of_address_to_resource(struct
> extern int of_pci_address_to_resource(struct device_node *dev, int bar,
> struct resource *r);
>
> +/* Parse the ibm,dma-window property of an OF node into the busno, phys and
> + * size parameters.
> + */
> +void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size);
> +
> extern void kdump_move_device_tree(void);
>
> #endif /* __KERNEL__ */
>
> To: linuxppc-dev@ozlabs.org
> From: Jeremy Kerr <jk@ozlabs.org>
> Date: Thu, 18 May 2006 16:20:51 +1000
> Subject: [PATCH 2/2] powerpc: pseries: Use generic dma-window parsing function
> Message-Id: <1147933251.472945.297063284077.qpush@pokey>
>
> Change the pseries iommu init code to use the new of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/platforms/pseries/iommu.c | 29 ++++++++++-------------------
> arch/powerpc/platforms/pseries/vio.c | 32 ++++++++++++++------------------
> 2 files changed, 24 insertions(+), 37 deletions(-)
>
> Index: linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> @@ -299,30 +299,22 @@ static void iommu_table_setparms(struct
> * iommu_table_setparms_lpar
> *
> * Function: On pSeries LPAR systems, return TCE table info, given a pci bus.
> - *
> - * ToDo: properly interpret the ibm,dma-window property. The definition is:
> - * logical-bus-number (1 word)
> - * phys-address (#address-cells words)
> - * size (#cell-size words)
> - *
> - * Currently we hard code these sizes (more or less).
> */
> static void iommu_table_setparms_lpar(struct pci_controller *phb,
> struct device_node *dn,
> struct iommu_table *tbl,
> - unsigned int *dma_window)
> + unsigned char *dma_window)
> {
> + unsigned long offset, size;
> +
> tbl->it_busno = PCI_DN(dn)->bussubno;
> + of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
>
> - /* TODO: Parse field size properties properly. */
> - tbl->it_size = (((unsigned long)dma_window[4] << 32) |
> - (unsigned long)dma_window[5]) >> PAGE_SHIFT;
> - tbl->it_offset = (((unsigned long)dma_window[2] << 32) |
> - (unsigned long)dma_window[3]) >> PAGE_SHIFT;
> tbl->it_base = 0;
> - tbl->it_index = dma_window[0];
> tbl->it_blocksize = 16;
> tbl->it_type = TCE_PCI;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> }
>
> static void iommu_bus_setup_pSeries(struct pci_bus *bus)
> @@ -414,7 +406,7 @@ static void iommu_bus_setup_pSeriesLP(st
> struct iommu_table *tbl;
> struct device_node *dn, *pdn;
> struct pci_dn *ppci;
> - unsigned int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
>
> DBG("iommu_bus_setup_pSeriesLP, bus %p, bus->self %p\n", bus, bus->self);
>
> @@ -422,7 +414,7 @@ static void iommu_bus_setup_pSeriesLP(st
>
> /* Find nearest ibm,dma-window, walking up the device tree */
> for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
> - dma_window = (unsigned int *)get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window != NULL)
> break;
> }
> @@ -516,7 +508,7 @@ static void iommu_dev_setup_pSeriesLP(st
> {
> struct device_node *pdn, *dn;
> struct iommu_table *tbl;
> - int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
> struct pci_dn *pci;
>
> DBG("iommu_dev_setup_pSeriesLP, dev %p (%s)\n", dev, pci_name(dev));
> @@ -531,8 +523,7 @@ static void iommu_dev_setup_pSeriesLP(st
>
> for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->iommu_table;
> pdn = pdn->parent) {
> - dma_window = (unsigned int *)
> - get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window)
> break;
> }
> Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
> @@ -108,32 +108,28 @@ __initcall(vio_bus_init_pseries);
> */
> static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
> {
> - unsigned int *dma_window;
> - struct iommu_table *newTceTable;
> - unsigned long offset;
> - int dma_window_property_size;
> + unsigned char *dma_window;
> + struct iommu_table *tbl;
> + unsigned long offset, size;
>
> - dma_window = (unsigned int *) get_property(dev->dev.platform_data, "ibm,my-dma-window", &dma_window_property_size);
> - if(!dma_window) {
> + dma_window = get_property(dev->dev.platform_data,
> + "ibm,my-dma-window", NULL);
> + if (!dma_window)
> return NULL;
> - }
>
> - newTceTable = (struct iommu_table *) kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
> + tbl = (struct iommu_table *)kmalloc(sizeof(*tbl), GFP_KERNEL);
>
> - /* There should be some code to extract the phys-encoded offset
> - using prom_n_addr_cells(). However, according to a comment
> - on earlier versions, it's always zero, so we don't bother */
> - offset = dma_window[1] >> PAGE_SHIFT;
> + of_parse_dma_window(dev->dev.platform_data, dma_window,
> + &tbl->it_index, &offset, &size);
>
> /* TCE table size - measured in tce entries */
> - newTceTable->it_size = dma_window[4] >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> /* offset for VIO should always be 0 */
> - newTceTable->it_offset = offset;
> - newTceTable->it_busno = 0;
> - newTceTable->it_index = (unsigned long)dma_window[0];
> - newTceTable->it_type = TCE_VB;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_busno = 0;
> + tbl->it_type = TCE_VB;
>
> - return iommu_init_table(newTceTable);
> + return iommu_init_table(tbl);
> }
>
> /**
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] dtc: add setting of physical boot cpu
From: Michael Neuling @ 2006-05-18 16:59 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <7AC7793A-74F3-4596-BF28-19BCA9E388CF@watson.ibm.com>
> How does this interact with "linux,boot-cpu"?
Currently, the -b option only changes the value in blob header.
linux,boot-cpu is still taken from whatever the input dts/dtb/fs
specifies.
> If -b is defined then the absence of "linux,boot-cpu" should no
> longer cause a warning.
For version 2 of the blob, this property should be in the header.
Perhaps we should warn if linux,boot-cpu is _missing_ when using <
version 2 and warn if it's _there_ for >= version 2.
I should add an error if someone specifies -b with version < 2.
> Perhaps if -b is missing the header value is set from "linux,boot-
> cpu" property?
I believe they're suppose to be mutually exclusive, so probably not a
good idea.
> Should we extend the "linux,boot-cpu" to actually contain a thread-id
> or are we deprecating this prop?
Yeah, the linux,boot-cpu is deprecated in version >= 2.
The dtc docs say that the boot_cpuid_phys field should match the "reg"
property in the CPU node. Their should be a "reg" property for each
thread, which I think solves your problem.
On a different note, dtc reading blobs on little endian machines is
broken. Just look at reserve mem entries in the output. I think the
main issue is with flat_read_chunk using memcpy.
Mikey
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Jimi Xenidis @ 2006-05-18 16:52 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1147967806.8469.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
On May 18, 2006, at 11:56 AM, Michael Ellerman wrote:
>
> I'm actually hoping to get rid of udbg_printf(), but if I can't we
> should stick this in I guess. The real problem IMHO is that debug
> printks rot because they're rarely compiled, not sure what to do about
> that.
Yeah, debug code always has that problem. But I must say, whenever I
work with the x86 guys and I see how long they are _blind_ when they
boot it blows my mind. Lets hope we don't go there.
-JX
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: MPC8xx: resolution of gettimeofday() ?
From: Eugene Surovegin @ 2006-05-18 16:48 UTC (permalink / raw)
To: Steven Scholz; +Cc: linuxppc-embedded
In-Reply-To: <446C8E70.3040601@imc-berlin.de>
On Thu, May 18, 2006 at 05:10:40PM +0200, Steven Scholz wrote:
> Hi all,
>
> what is the resolution of gettimeofday() for an MPC8xx?
>
> IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
>
> This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
> resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
>
> But is this decrementer used to update xtime?
> Will gettimeofday() have a resolution of 200ns?
>
> How about linux 2.4 where xtime is a "struct timeval" rather then "struct
> timespec"?
>
> This trivial test programm
>
> struct timeval first, next;
> double diff;
>
> gettimeofday(&first, NULL);
> do {
> gettimeofday(&next, NULL);
> } while (first.tv_usec == next.tv_usec &&
> first.tv_sec == next.tv_sec);
>
> diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
> diff += (double) (next.tv_usec - first.tv_usec);
>
> printf ("Resolution gettimeofday() = %g ?s\n", diff);
>
> says it's between 13 - 16 ?s on a linux-2.4.20. Could that be? how does this
> relate to the decrementer frequency?
Usually on PPC we use timebase to interpolate time between Decrementer
interrupts. In this case gettimeofday resolution is determined by
timebase resolution which is quite high (megahertz range).
--
Eugene
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:43 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C05CC@zch01exm40.ap.freescale.net>
On May 18, 2006, at 1:57 AM, Zang Roy-r61911 wrote:
>
>> On Wed, 2006-05-17 at 08:45 -0500, Kumar Gala wrote:
>>
>>>> +#ifdef TSI108_ETH
>>>> +hw_info hw_info_table[TSI108_ETH_MAX_PORTS + 1] = {
>>>> + {TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_PHY0_ADDR, IRQ_TSI108_GIGE0},
>>>> +
>>>> + {TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET + 0x400,
>>>> + TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_PHY1_ADDR, IRQ_TSI108_GIGE1},
>>>> +
>>>> + {TBL_END, TBL_END, TBL_END, TBL_END}
>>>> +};
>>>> +#endif
>>>
>>> This table looks problematic. Look at using something like a
>>> platform device.
>>
>> Bzzzt ... wrong answer :) That's a textbook example of stuff
>> that should
>> be provided via the device-tree.
>>
>>
>
> Well , should I register this data to a platform device or the
> Ethernet
> driver get the information from device-tree directly?
I'd say the later. Ben mentioned use of of_device which will allow
you to do that more directly. I used platform_device to maintain the
fact that we had existing drivers to support that were using it already.
- k
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <1147936929.17679.106.camel@localhost.localdomain>
>> I will get rid of those tables. I can see that in file
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
>> a similar table. Should it be removed in future :)?
>
> Yes. And somebody beaten up for letting that stuff leak into
> arch/powerpc :)
>
>>> Yes, please do so, we will not accept a board that does the above :)
>>
>> I just do the same thing as 85xx :).
>
> Yes and I intend to LART Kumar seriously for that next time I meet
> him :)
Get in line ;) [lets be fair, I didn't actually do the 85xx/ads.c
port, but it was based on the 83xx which I did do]
The problem with the irq mapping is we dont have any code yet that
handles the "static" tables.
>>> We need a generic add_bridge that goes through PCI bridges and
>>> instanciate based on their type as provided by the device-tree. You
>>> should try to work in that direction...
>
> I suggest you also read my comments to Mark A. Greer as most of that
> stuff overlaps... I wish I had more times to work myself on that
> but I'm
> fairly overflowed at the moment...
>
> Ben
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:36 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C07EC@zch01exm40.ap.freescale.net>
On May 18, 2006, at 3:05 AM, Zang Roy-r61911 wrote:
>>
>>> The tsi108 serial port is not a sub node of "soc". well, any way,
>>> I can try soc!
>>
>> What is it ? Where is it ? "soc" is a bit of a generic name for
>> something in the device-tree in fact... we might want to
>> define a way to
>> expose any bus via some kind of soc mecanism even if it's not a root
>> bus.
>>
>>
> Should I just use add_legacy_soc_port() instead of a new function
> add_legacy_tsi_port()?
I think seeing your dts will help here. We need to have a concept of
a "bridge" that may be similar to an "soc".
> --- arch/powerpc/kernel/legacy_serial.c.orig Thu May 18 15:35:19 2006
> +++ arch/powerpc/kernel/legacy_serial.c Thu May 18 15:50:38 2006
> @@ -302,6 +302,17 @@ void __init find_legacy_serial_ports(voi
> of_node_put(isa);
> }
>
> + /* First fill our array with tsi-bridge ports */
> + for (np = NULL; (np = of_find_compatible_node(np, "serial",
> "ns16550")) != NULL;) {
> + struct device_node *tsi = of_get_parent(np);
> + if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
> + index = add_legacy_soc_port(np, np);
> + if (index >= 0 && np == stdout)
> + legacy_serial_console = index;
> + }
> + of_node_put(tsi);
> + }
> +
> #ifdef CONFIG_PCI
> /* Next, try to locate PCI ports */
> for (np = NULL; (np = of_find_all_nodes(np));)
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:35 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
On May 18, 2006, at 5:21 AM, Zang Roy-r61911 wrote:
>
>> On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
>>>> I'm not repeating Kumar's comments about that CONFIG_7xxx
>>>> thing and that
>>>> 7xxx/ directory, it should all go.
>>>>
>>>
>>> Should I move my code to embedded6xx?
>>
>> Probably for now yes.
>
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
We should rename the files so they are 7448 specific. I dont see any
reason if FSL comes up with a 7449 that it wouldn't run on the same
board.
- k
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-18 15:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, linux-kernel, linux-ide,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <1147935734.17679.93.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: 2006年5月17日 21:28
>> To: Zang Roy-r61911
>> Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; Yang Xin-Xin-r48390
>> Subject: Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerpc pl atform
>
> Copying here the comments I already made so Jeff gets them...
>
>> @@ -1032,6 +1032,9 @@ static inline void mv_crqb_pack_cmd(u16
>> {
>> *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
>> (last ? CRQB_CMD_LAST : 0);
>> +#ifdef CONFIG_PPC
>> + *cmdw = cpu_to_le16(*cmdw);
>> +#endif
>> }
>
> Why an ifdef here ? The cpu_to_le16 should probably be unconditional.
> And even if for some weird reason you wanted to ifdef it, why PPC ? and
> what about other BE architectures ?
>
>> /**
>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
> *mmio)
>> {
>> u32 tmp;
>> -
>> +#ifndef CONFIG_PPC
>> writel(0, mmio + MV_GPIO_PORT_CTL);
>> +#endif
>
> You'll have to do better here too... I don't wee why when compiled on
> PPC, this driver should "magically" not clear those bits... At the very
> least, you should test the machine type if you want to do something
> specific to your platform, but first, you'll have to convince Jeff why
> this change has to be done in the first place and if there is a better
> way to handle it.
Correct... it does seem some bugs were found, but #ifdef powerpc is
certainly out of the question. We want the driver to work without
ifdefs on all platforms.
Jeff
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Michael Ellerman @ 2006-05-18 15:56 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <34FAC3E5-F717-4640-B094-312C8773852E@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Thu, 2006-05-18 at 08:22 -0400, Jimi Xenidis wrote:
> On May 17, 2006, at 7:36 PM, Michael Ellerman wrote:
>
> > On Wed, 2006-05-17 at 12:00 -0400, jimix@watson.ibm.com wrote:
> >> - pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
> >> + pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
> >> __FUNCTION__, current_entitled, current_weight);
> >>
> >> - pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
> >> + pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
> >> __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
> >
> > But pr_debug() calls printk, not udbg_printf() ?
>
> Now _thats_ funny!
> Then I'm so happy to have found and fixed this compiler warning :)
Haha, nice one Jimi :D
> >> -extern void udbg_printf(const char *fmt, ...);
> >> +extern void udbg_printf(const char *fmt, ...)
> >> + __attribute__ ((format (printf, 1, 2)));
>
> I believe this chunk is still goodness as it will catch format issues
> for developers.
I'm actually hoping to get rid of udbg_printf(), but if I can't we
should stick this in I guess. The real problem IMHO is that debug
printks rot because they're rarely compiled, not sure what to do about
that.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* MPC8xx: resolution of gettimeofday() ?
From: Steven Scholz @ 2006-05-18 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
what is the resolution of gettimeofday() for an MPC8xx?
IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
But is this decrementer used to update xtime?
Will gettimeofday() have a resolution of 200ns?
How about linux 2.4 where xtime is a "struct timeval" rather then "struct
timespec"?
This trivial test programm
struct timeval first, next;
double diff;
gettimeofday(&first, NULL);
do {
gettimeofday(&next, NULL);
} while (first.tv_usec == next.tv_usec &&
first.tv_sec == next.tv_sec);
diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
diff += (double) (next.tv_usec - first.tv_usec);
printf ("Resolution gettimeofday() = %g µs\n", diff);
says it's between 13 - 16 µs on a linux-2.4.20. Could that be? how does this
relate to the decrementer frequency?
Thanks a million!
--
Steven
^ permalink raw reply
* [RFD] Hugetlb: Allowing hugetlb regions to be closed
From: Adam Litke @ 2006-05-18 15:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libhugetlbfs-devel
Please correct me if I am wrong in any of the following...
On powerpc, once a region of the address space has been 'opened' for use
with hugetlb pages this region can never again contain normal pages for
the remaining life of the process -- even if all hugetlb mappings have
been unmapped from this region.
The above approach is nice and simple, but a bit restrictive too. Would
people be opposed to a patch which provides methods for closing low/high
hugetlb areas and logic in arch_get_unmapped_area() to perform the
closing? My thought would be to try closing only in the full_search:
case (so the fast path is left untouched.
As for why I want this... I have an application (libhugetlbfs), which
provides hugetlb pages to applications in an abstracted manner. There
are situations where the library creates a hugetlb area and needs to
later replace it with normal pages. The main case this will happen is
for a hugetlb-backed malloc area.
Thoughts?
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* MPC8xx USB SOF microcode patch
From: Josef Angermeier @ 2006-05-18 14:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.6.15 and try to get the MPC875 USB controller
working. I just checked if the microcode patch in
arch/ppc/8xx_io/micropatch.c for CONFIG_USB_SOF_UCODE_PATCH set
corresponds with the newest microcode patch for mpc8xx, downloadable
from freescale: They differ slighly, is it an older (working) version or
where is it from ?
ciao
josef
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Mark Chambers @ 2006-05-18 14:22 UTC (permalink / raw)
To: Gosiuua, linuxppc-embedded
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> Hello List..
>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
>
<snip>
> - Waiting for target stop failed
> - TARGET: Break at boot vector failed, freeze forced
> /*****/
>
>
> BDI can't bread the CPU and i don't know what can i do!
> Any one can help me?
> _______________________________________________
I have had the same issue. You need lines similar to the following
in your bdi config file to stop the watchdog timer. Then you will
need other lines to set various registers to match your hardware
bus widths, etc.
[INIT]
; init core register
WREG MSR 0x00001042 ;MSR : ME,RI, exceptions high
WM32 0x000101a8 0xf0000000 ;move internal space
WM32 0xf0010004 0xFFFFFFC1 ;SYPCR: disable watchdog
Mark C.
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Laurent Pinchart @ 2006-05-18 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Gosiuua
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
[...]
You should tell the BDI to initialize the SYPCR register, otherwise the
internal watchdog timer will keep resetting the CPU.
[INIT]
; *** Initialize the core internal registers
; Program the SYPCR - Disable the watchdog timer
WM32 0xf0010004 0xffff2081
You will need to initiliaze other internal registers as well (BCR, SIUMCR,
BRx, ORx, ...).
I'm not sure if this will be enough to solve your problem, but it should at
least be a start.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 0/10] powerpc: add mpc7448hpc2 (Taiga) board support
From: Kumar Gala @ 2006-05-18 14:08 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626D618@zch01exm40.ap.freescale.net>
On May 17, 2006, at 5:13 AM, Zang Roy-r61911 wrote:
> Hi, Paul
>
> This series of patch adds mpc7448hpc2 (taiga) board support in
> arch/powerpc.
> Tsi108 chip of Tundra Semiconductor is also supported.
>
> Roy Zang
Can you post your .dts for us to take a look at. I know Mark Greer
is looking at support for the 105/6/7 family of bridges and the 10x
family should have consistent flat device trees.
- kumar
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <17516.20191.490360.852876@cargo.ozlabs.ibm.com>
On May 18, 2006, at 5:39 AM, Paul Mackerras wrote:
> Zang Roy-r61911 writes:
>
>> I can migrate my code to embedded6xx technically. In fact,
>> I can move it into anywhere in the arch/powerpc/platforms.
>> While for mpc7448hpc2(taiga) board, it is not a embedded
>> application board. It is a high performance server! It seems
>> odd to put code there :). What's your opinion?
>
> What sort of machine(s) is this board used in? Or what machines will
> it be in?
Its a reference board from Freescale with a MPC7448 + TSI108.
Similar in concept to sandpoint.
- kumar
^ permalink raw reply
* About BDI2000 and mpc8247
From: Gosiuua @ 2006-05-18 13:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ee10e9f40605180640g12a2671bo530c3ccbba8b3829@mail.gmail.com>
Hello List..
i have a develop board based on mpc8247. It has no eeprom to restore
hareware configure word and i have to use default config word
0x00000000.
my bdi config file:
[TARGET]
CPUTYPE 8270 ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK 1 ;use 16 MHz JTAG clock
BOOTADDR 0xfff00100 ;boot address used for start-up break
WORKSPACE 0x00000000 ;workspace in target RAM for fast
download and data cache flushing
BDIMODE AGENT ;the BDI working mode (LOADONLY |
AGENT | GATEWAY)
BAUDRATE 115200 ;baudrate for gateway mode or
virtual IO
BREAKMODE SOFT ;<AGENT> SOFT or HARD, HARD uses PPC
hardware breakpoint
VECTOR CATCH ;<AGENT> catch unhandled exceptions
DCACHE NOFLUSH ;<AGENT> data cache flushing (FLUSH |
NOFLUSH)
MEMBASE 0 ;<AGENT> base of target memory
MEMSIZE 0x00004000 ;<AGENT> size of target memory, 64M
POOLBASE 0x00000000 ;<AGENT> base of host controlled target mem=
ory
POOLSIZE 0x00004000 ;<AGENT> size of host controlled
target memory
When i connect BDI2000(bdiwind_cop, firmware 1.13, logic 1.02 ) to
the board, the following messages
are printed, then it have no response!
/************************************************************/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- Target SVR is 0x00000000
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
/***/
When i set CPUTYPE to 8260, the following messages are printed continously=
:
/**************************************************************************=
****/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
*** TARGET: reset detected, restarting target
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
/*****/
BDI can't bread the CPU and i don't know what can i do!
Any one can help me?
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147930376.17679.72.camel@localhost.localdomain>
Do you have any comments about how you envision updating the "virtual"
mode image with information passed from the boot loader? I am asking
this from the standpoint of updating the "virtual" flat tree with
correct values, in order to boot from older firmware.
-Matthew
On Thu, 2006-05-18 at 15:32 +1000, Benjamin Herrenschmidt wrote:
> That is why, I think, what we should do is have rules for building
> separate zImage wrappers. The basic OF one (which exists in both real
> and virtual mode versions and that I'd like to make capable of also
> working if a flat device-tree is passed in), the zImage.sandpoint, the
> zImage.prep, and whatever...
>
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060518002142.GA23182@mag.az.mvista.com>
On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> +void *
> +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
Is there a reason you are not using of_get_flat_dt_prop() instead of
implementing your own version?
-Matthew
^ permalink raw reply
* Re: [PATCH] dtc: add setting of physical boot cpu
From: Jimi Xenidis @ 2006-05-18 13:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20060518035734.2B2CA67A6D@ozlabs.org>
Hey Michael, a few questions:
How does this interact with "linux,boot-cpu"?
If -b is defined then the absence of "linux,boot-cpu" should no
longer cause a warning.
Perhaps if -b is missing the header value is set from "linux,boot-
cpu" property?
Should we extend the "linux,boot-cpu" to actually contain a thread-id
or are we deprecating this prop?
-JX
On May 17, 2006, at 11:56 PM, Michael Neuling wrote:
> dtc always sets the physical boot CPU to 0xfeedbeef. Add a -b
> option to
> set this.
>
> ---
> I've tested the blob output but not asm output.
>
> ---
> dtc.c | 12 +++++++++---
> dtc.h | 6 ++++--
> flattree.c | 16 ++++++++++------
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> Index: dtc/dtc.c
> ===================================================================
> --- dtc.orig/dtc.c
> +++ dtc/dtc.c
> @@ -95,6 +95,8 @@ static void usage(void)
> fprintf(stderr, "\t\tBlob version to produce, defaults to 3
> (relevant for dtb\n\t\tand asm output only)\n");
> fprintf(stderr, "\t-R <number>\n");
> fprintf(stderr, "\t\tMake space for <number> reserve map entries
> (relevant for \n\t\tdtb and asm output only)\n");
> + fprintf(stderr, "\t-b <number>\n");
> + fprintf(stderr, "\t\tSet the physical boot cpu\n");
> fprintf(stderr, "\t-f\n");
> fprintf(stderr, "\t\tForce - try to produce output even if the
> input tree has errors\n");
> exit(2);
> @@ -113,8 +115,9 @@ int main(int argc, char *argv[])
> FILE *outf = NULL;
> int outversion = 3;
> int reservenum = 1;
> + int boot_cpuid_phys = 0xfeedbeef;
>
> - while ((opt = getopt(argc, argv, "I:O:o:V:R:f")) != EOF) {
> + while ((opt = getopt(argc, argv, "I:O:o:V:R:fb:")) != EOF) {
> switch (opt) {
> case 'I':
> inform = optarg;
> @@ -134,6 +137,9 @@ int main(int argc, char *argv[])
> case 'f':
> force = 1;
> break;
> + case 'b':
> + boot_cpuid_phys = strtol(optarg, NULL, 0);
> + break;
> default:
> usage();
> }
> @@ -185,9 +191,9 @@ int main(int argc, char *argv[])
> if (streq(outform, "dts")) {
> dt_to_source(outf, bi);
> } else if (streq(outform, "dtb")) {
> - dt_to_blob(outf, bi, outversion);
> + dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "asm")) {
> - dt_to_asm(outf, bi, outversion);
> + dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "null")) {
> /* do nothing */
> } else {
> Index: dtc/dtc.h
> ===================================================================
> --- dtc.orig/dtc.h
> +++ dtc/dtc.h
> @@ -207,8 +207,10 @@ struct boot_info *build_boot_info(struct
>
> /* Flattened trees */
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version);
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version);
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
>
> struct boot_info *dt_from_blob(FILE *f);
>
> Index: dtc/flattree.c
> ===================================================================
> --- dtc.orig/flattree.c
> +++ dtc/flattree.c
> @@ -301,7 +301,8 @@ static struct data flatten_reserve_list(
> }
> static void make_bph(struct boot_param_header *bph,
> struct version_info *vi,
> - int reservesize, int dtsize, int strsize)
> + int reservesize, int dtsize, int strsize,
> + int boot_cpuid_phys)
> {
> int reserve_off;
>
> @@ -324,12 +325,13 @@ static void make_bph(struct boot_param_h
> + dtsize + strsize);
>
> if (vi->flags & FTF_BOOTCPUID)
> - bph->boot_cpuid_phys = 0xfeedbeef;
> + bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
> if (vi->flags & FTF_STRTABSIZE)
> bph->size_dt_strings = cpu_to_be32(strsize);
> }
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version)
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -355,7 +357,8 @@ void dt_to_blob(FILE *f, struct boot_inf
> reservebuf = flatten_reserve_list(bi->reservelist, vi);
>
> /* Make header */
> - make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len);
> + make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len,
> + boot_cpuid_phys);
>
> fwrite(&bph, vi->hdr_size, 1, f);
>
> @@ -395,7 +398,7 @@ static void dump_stringtable_asm(FILE *f
> }
> }
>
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version)
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version, int
> boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -434,7 +437,8 @@ void dt_to_asm(FILE *f, struct boot_info
> vi->last_comp_version);
>
> if (vi->flags & FTF_BOOTCPUID)
> - fprintf(f, "\t.long\t0xdeadbeef\t/*boot_cpuid_phys*/\n");
> + fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
> + boot_cpuid_phys);
>
> if (vi->flags & FTF_STRTABSIZE)
> fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/*
> size_dt_strings */\n",
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-18 12:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1147948758.15507.52.camel@johannes>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2006-05-17 at 21:32 +0200, Andreas Schwab wrote:
>
>> I have the following sound resources in /proc/iomem:
>>
>> 80008000-800083ff : 0.00010000:i2s
>> 80008000-800083ff : Sound DMA
>> 80010000-80010fff : 0.00010000:i2s
>> 80010000-80010fff : Sound Control
>>
>> I'm not sure whether the first mapping should be split, but I don't know
>> much about how resource mappings work.
>
> That looks like you have snd-powermac loaded
Yes, that's while I had that loaded. Of course, I unloaded it before I
tried snd-aoa.
>> The layout id is 36, and it has both line out and headphone, detected as a
>> Snapper.
>
> Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
> file.
I think it's a tas3004.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* I2C bus issues on MPC8248
From: Laurent Pinchart @ 2006-05-18 12:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The mailing
list archives mention a driver for the MPC8260
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I
modified to reflect the memory map differences between the MPC8260 and the
MPC8248, as mentionned in the e-mail.
The good news is that the driver works. The bad news is that it doesn't work
correctly.
The Linux I2C layer probes the I2C bus for peripherals when drivers are
loaded. The probing function writes a single byte with the device address and
check if the data is acked. I monitored the SCL and SDA lines using an
oscilloscope, and found out that 5 bytes are written to the device (address +
4 data bytes) instead of a single one. The first 4 bytes are acked, the last
isn't. After further investigation, I found out that the cpm_iic_write()
function in drivers/i2c/busses/i2c-mpc8260.c fills two buffer descriptors,
the second one having cbd_datlen set to zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START;
tbdf[1].cbd_bufaddr = __pa(buf);
tbdf[1].cbd_datlen = count;
tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP;
Still, 5 bytes are sent on the bus. I suspected a CPM bug when cbd_datlen is
equal to zero, so I modified the first buffer descriptor to set the
BD_SC_LAST in cbd_sc when count is zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
Using that code, no data is sent on the bus, the BD_SC_READY bit is never
cleared and no interrupt is generated. Once again I suspected a CPM bug when
writing a single byte on the bus, so I increased cbd_datlen to 2:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 2;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
This worked, and two bytes were written on the bus, leading me to believe that
the CPM was at fault.
Has anyone noticed the same behaviour ? Is there a workaround available ? I
tried searching Freescale's website for CPM microcode updates but haven't
found anything related to the I2C controller.
Laurent Pinchart
^ 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