* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 7:22 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C064E@zch01exm40.ap.freescale.net>
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 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 :)
> > 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
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-18 7:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147860564.14395.6.camel@johannes>
T24gNS8xNy8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAo+Cj4gQ3VycmVudGx5IHNuZC1hb2EgaXMga25vd24gdG8gd29yayBvbiB0aGUg
Zm9sbG93aW5nIG1hY2hpbmVzOgo+ICogUG93ZXJCb29rNSw4Cj4gKiBQb3dlckJvb2s1LDcKPiAq
IFBvd2VyTWFjOCwxCj4gKiBQb3dlck1hYzgsMgo+ICogMTciIE9jdG9iZXIgMjAwNSBQb3dlckJv
b2sgKGRvbid0IGtub3cgdGhlIG51bWJlcikKPiAqIFBvd2VyTWFjMTEsMgo+ICogUG93ZXJCb29r
Niw4Cj4gYW5kIG15Cj4gKiBQb3dlckJvb2s1LDYKCkFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQg
aXMgbmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==
^ permalink raw reply
* mm/rmap.c incompatible with ppc/kernel/dma-mapping.c?
From: Gerhard Pircher @ 2006-05-18 8:03 UTC (permalink / raw)
To: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2037 bytes --]
Hi,
Since I managed to compile in not cache coherent DMA support in the AmigaOne
Linux kernel, the system crashes whenever I try to view a movie for example
in totem or VLC. The following log snipped is the only debug information I
could extract, because most of the time the system hard locks and can only
be reactivated with a hardware reset.
May 12 00:04:17 localhost kernel: kernel BUG in page_add_file_rmap at
mm/rmap.c:387!
May 12 00:04:17 localhost kernel: Oops: Exception in kernel mode, sig: 5
[#1]
May 12 00:04:17 localhost kernel: NIP: C004968C LR: C0044CB8 SP: D2C77E20
REGS: d2c77d70 TRAP: 0700 Not tainted
May 12 00:04:17 localhost kernel: MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1
IR/DR: 11
May 12 00:04:17 localhost kernel: TASK = d4918000[2900] 'totem' THREAD:
d2c76000Last syscall: 246
May 12 00:04:17 localhost kernel: GPR00: 00000001 D2C77E20 D4918000 C0D02720
00000000 D27B02A0 02000000 D4FE4400
May 12 00:04:17 localhost kernel: GPR08: C03D0000 38139785 00000000 38139785
24048444 10054698 00000000 10171158
May 12 00:04:17 localhost kernel: GPR16: 00000000 00000000 0EADDD7C 00015F90
000001F6 315B1970 33CA8000 D4D6BBA0
May 12 00:04:17 localhost kernel: GPR24: 00000000 00000000 02000000 D4B7D33C
33CA8000 C0D02720 38139785 D2888220
May 12 00:04:17 localhost kernel: NIP [c004968c] page_add_file_rmap+0x8/0x78
May 12 00:04:17 localhost kernel: LR [c0044cb8] do_no_page+0x1cc/0x37c
May 12 00:04:17 localhost kernel: Call trace:
May 12 00:04:17 localhost kernel: [c004503c] handle_mm_fault+0xf4/0x174
May 12 00:04:17 localhost kernel: [c0012100] do_page_fault+0x140/0x398
May 12 00:04:17 localhost kernel: [c0008178] handle_page_fault+0xc/0x80
I tested this with kernel 2.6.8 and 2.6.14.2. Both show the same behavior.
Is this a known problem on PPC systems with desktop CPUs? What about others
PPC boards that have 6xx/7xxx cpus and not cache coherent northbridges?
Thanks in advance!
regards,
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* [PATCH] powerpc: Add of_parse_dma_window()
From: Jeremy Kerr @ 2006-05-18 8:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1147933975.484840.681634501201.qpush@pokey>
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>
---
Update: don't EXPORT_SYMBOL - dma-window won't be needed by a module
arch/powerpc/kernel/prom_parse.c | 22 ++++++++++++++++++++++
include/asm-powerpc/prom.h | 6 ++++++
2 files changed, 28 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,25 @@ 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);
+}
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__ */
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
>
> > 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()?
--- 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
* [PATCH] powerpc: pseries: Use generic dma-window parsing function
From: Jeremy Kerr @ 2006-05-18 8:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1147933975.516311.850847048300.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>
---
Update: rebase to current powerpc head: vio driver has been merged
arch/powerpc/kernel/vio.c | 36 ++++++++++++---------------------
arch/powerpc/platforms/pseries/iommu.c | 29 +++++++++-----------------
2 files changed, 24 insertions(+), 41 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
@@ -281,30 +281,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)
@@ -396,7 +388,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);
@@ -404,7 +396,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;
}
@@ -498,7 +490,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));
@@ -513,8 +505,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/kernel/vio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/vio.c
+++ linux-2.6/arch/powerpc/kernel/vio.c
@@ -77,36 +77,28 @@ static struct iommu_table *vio_build_iom
} else
#endif
{
- unsigned int *dma_window;
- struct iommu_table *newTceTable;
- unsigned long offset;
- int dma_window_property_size;
-
- dma_window = (unsigned int *)get_property(
- dev->dev.platform_data, "ibm,my-dma-window",
- &dma_window_property_size);
+ unsigned char *dma_window;
+ struct iommu_table *tbl;
+ unsigned long offset, size;
+
+ dma_window = get_property(dev->dev.platform_data,
+ "ibm,my-dma-window", NULL);
if (!dma_window)
return NULL;
- newTceTable = kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
+ tbl = 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);
}
}
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Rene Rebe @ 2006-05-18 8:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Johannes Berg
In-Reply-To: <1147860564.14395.6.camel@johannes>
Hi,
thanks for the update. Is record/capture supost to work now?
Yours,
=2D-=20
Ren=E9 Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 7/10] Powerpc: workaround for tsi108 pci c onfi g read exception
From: Zang Roy-r61911 @ 2006-05-18 9:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
>
> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
> > Workaround for Tundra Semiconductor tsi108 host bridge pci
> config read
> > exception
>
> Use ppc_md.machine_check_exception instead of modifying the generic
> traps.c. Also make sure you can't configure your chip not to issue
> machine checks on target/master aborts on config space accesses....
>
> Ben.
I will try ppc_md.machine_check_exception. I am sure this machine check is
needed. I can not pass the pci probe, if I comment off this code.
Roy.
>
> > Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> >
> > ---
> >
> > arch/powerpc/kernel/traps.c | 13 +++++++++++++
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> > 0575fbe21e4f1045528bb91ec4b34bb7955c4a92
> > diff --git a/arch/powerpc/kernel/traps.c
> b/arch/powerpc/kernel/traps.c
> > index 064a525..7468d76 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -262,6 +262,19 @@ #if defined(CONFIG_PPC_PMAC) && defined(
> > }
> > }
> > #endif /* CONFIG_PPC_PMAC && CONFIG_PPC32 */
> > +
> > +#ifdef CONFIG_TSI108_BRIDGE
> > + extern void tsi108_clear_pci_cfg_error(void);
> > + const struct exception_table_entry *entry;
> > +
> > + /* Are we prepared to handle this fault? */
> > + if ((entry = search_exception_tables(regs->nip)) != NULL) {
> > + tsi108_clear_pci_cfg_error();
> > + regs->msr |= MSR_RI;
> > + regs->nip = entry->fixup;
> > + return 1;
> > + }
> > +#endif /* CONFIG_TSI108_BRIDGE */
> > return 0;
> > }
> >
>
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:08 UTC (permalink / raw)
To: Rene Rebe; +Cc: linuxppc-dev
In-Reply-To: <200605181056.35768.rene@exactcode.de>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Thu, 2006-05-18 at 10:56 +0200, Rene Rebe wrote:
> thanks for the update. Is record/capture supost to work now?
Yes, that was a pretty stupid bug.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:13 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060517221945.GA2902@localhost>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:
> changed /etc/modules to explicitly load only i2sbus:
Even that should not be necessary.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <jey7x04edq.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
On Wed, 2006-05-17 at 21:53 +0200, Andreas Schwab wrote:
> /* PowerBook6,7 */
> { .layout_id = 92,
> .codecs[0] = {
> .name = "tas",
> .connections = tas_connections_nolineout,
> },
> },
Thanks, I'll add that.
Autodetection will come some time too :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 10:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> 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?
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-18 10:23 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <60381eeb0605180025v2495715scb345d7067518ecc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote:
> Any chance for 5,2 ? What is needed for it? Codec only?
I don't know. If you try loading the modules, the kernel will tell you
something about an unhandled layout id. Alternatively, you can find the
layout-id file in your /proc/device-tree/ and tell me the number in it.
The rest I can figure out.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Zang Roy-r61911 @ 2006-05-18 10:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Mark A. Greer; +Cc: linuxppc-dev
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 6729c98..de09eac 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -323,7 +323,10 @@ config PPC_ISERIES
> >
> > config EMBEDDED6xx
> > bool "Embedded 6xx/7xx/7xxx-based board"
> > - depends on PPC32 && BROKEN
> > + depends on PPC32
> > + select PPC_UDBG_16550
> > + select MPIC
> > + select MPIC_SERIAL
>
> Not totally related to your patch but I'm tempted to turn that into a
> "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> avoid board specific code most of the time, but instead add necessary
> bits in the device-tree. We still need a per-board Kconfig option I
> think that will just select the necessary bits and pieces
> (and more than
> one can be selected at one time). Also, I think right now,
> the embedded
> stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> must be fixed
> asap. We are all living in the same kernel now :)
config Embedded6xx is not accurate. It can not cover all the
board with 7xx/7xxx based processor.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 10:35 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:21 +0800, 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?
I think we should do a platform/generic for boards that don't need more
than a single platform file, which I think will be the case once we are
done with your port ;)
Ben.
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Benjamin Herrenschmidt @ 2006-05-18 10:36 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A9D@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 6729c98..de09eac 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > >
> > > config EMBEDDED6xx
> > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > - depends on PPC32 && BROKEN
> > > + depends on PPC32
> > > + select PPC_UDBG_16550
> > > + select MPIC
> > > + select MPIC_SERIAL
> >
> > Not totally related to your patch but I'm tempted to turn that into a
> > "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> > avoid board specific code most of the time, but instead add necessary
> > bits in the device-tree. We still need a per-board Kconfig option I
> > think that will just select the necessary bits and pieces
> > (and more than
> > one can be selected at one time). Also, I think right now,
> > the embedded
> > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > must be fixed
> > asap. We are all living in the same kernel now :)
>
> config Embedded6xx is not accurate. It can not cover all the
> board with 7xx/7xxx based processor.
Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
derivative.
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Paul Mackerras @ 2006-05-18 10:39 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: Yang Xin-Xin-r48390, Alexandre.Bounine, linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
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?
Paul.
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-18 10:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je3bf85twf.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
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, or some other driver,
otherwise it shouldn't show up in /proc/iomem at all. It isn't my
driver, because it would generated 'i2sbus ...' names there.
> 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.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Zang Roy-r61911 @ 2006-05-18 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
> On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > > index 6729c98..de09eac 100644
> > > > --- a/arch/powerpc/Kconfig
> > > > +++ b/arch/powerpc/Kconfig
> > > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > > >
> > > > config EMBEDDED6xx
> > > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > > - depends on PPC32 && BROKEN
> > > > + depends on PPC32
> > > > + select PPC_UDBG_16550
> > > > + select MPIC
> > > > + select MPIC_SERIAL
> > >
> > > Not totally related to your patch but I'm tempted to turn
> that into a
> > > "Generic 6xx/7xx/7xxx" rather than "embedded" if we
> manage to always
> > > avoid board specific code most of the time, but instead
> add necessary
> > > bits in the device-tree. We still need a per-board
> Kconfig option I
> > > think that will just select the necessary bits and pieces
> > > (and more than
> > > one can be selected at one time). Also, I think right now,
> > > the embedded
> > > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > > must be fixed
> > > asap. We are all living in the same kernel now :)
> >
> > config Embedded6xx is not accurate. It can not cover all the
> > board with 7xx/7xxx based processor.
>
> Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
> now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
> derivative.
>
> Ben.
>
>
I can just do as your suggestion!
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 10:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> On Thu, 2006-05-18 at 18:21 +0800, 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?
>
> I think we should do a platform/generic for boards that don't
> need more
> than a single platform file, which I think will be the case
> once we are
> done with your port ;)
>
> Ben.
>
>
I will implement my board port as early as I can
according to the feedback :).
^ permalink raw reply
* Re: [PATCH] Fix do_mlock so page alignment is to hugepage boundries when needed
From: Hugh Dickins @ 2006-05-18 11:13 UTC (permalink / raw)
To: Eric Paris; +Cc: discuss, linux-kernel, wli, linuxppc-dev
In-Reply-To: <1147895964.26468.35.camel@localhost.localdomain>
On Wed, 17 May 2006, Eric Paris wrote:
>
> This patch still solves the problem of the kernel currently being more
> restrictive on what we accept from userspace for the length of the mlock
> if it is a hugepage rather than a regular page. With a regular page we
> will round the value from userspace and happily go about our business of
> mlocking. For a hugepage it just rejects it if userspace doesn't align
> it themselves. This allows the kernel to do the same work for hugepages
> that it does for normal pages.
You do have a point that there's an inconsistency there. But we could
argue a long time what's inconsistent with what - I'd say it's mlock
being inconsistent with mprotect, munmap, msync, madvise, etc. I
don't see an outright reason to change from the current behaviour.
You do realize that there's almost no point in mlocking a hugepage area
anyway? (I wrote that first without the "almost", but now with hugepage
faulting, it does provide another way to fault in all the pages at once.)
Hugh
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 8/10] Add tsi108 8250 serial support
From: Zang Roy-r61911 @ 2006-05-18 4:00 UTC (permalink / raw)
To: rmk+serial
Cc: Alexandre.Bounine, linux-kernel, linuxppc-dev list,
Paul Mackerras, linux-serial, Yang Xin-Xin-r48390
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: 2006=E5=B9=B45=E6=9C=8817=E6=97=A5 21:26
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 8/10] Add tsi108 8250 serial support
On May 17, 2006, at 5:14 AM, Zang Roy-r61911 wrote:
> This patch contains changes to the serial device driver specific =20
> for integrated
> serial port in Tsi108 Host Bridge.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>
>> From nobody Mon Sep 17 00:00:00 2001
> From: roy zang <tie-fei.zang@freescale.com>
> Date: Tue May 16 15:26:02 2006 +0800
> Subject: [PATCH] Add tsi108 serial support
This patch needs to go to Russell King as uart/8250 driver maintainer.
- kumar
>
> ---
>
> drivers/serial/8250.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> 6cb950357e9970afa671d59f172dbc4b03f11560
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index bbf78aa..c12f516 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -723,7 +723,9 @@ static int broken_efr(struct uart_8250_p
> static void autoconfig_16550a(struct uart_8250_port *up)
> {
> unsigned char status1, status2;
> +#ifndef CONFIG_TSI108_BRIDGE
> unsigned int iersave;
> +#endif
>
> up->port.type =3D PORT_16550A;
> up->capabilities |=3D UART_CAP_FIFO;
> @@ -833,6 +835,7 @@ static void autoconfig_16550a(struct uar
> * trying to write and read a 1 just to make sure it's not
> * already a 1 and maybe locked there before we even start start.
> */
> +#ifndef CONFIG_TSI108_BRIDGE
> iersave =3D serial_in(up, UART_IER);
> serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
> if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
> @@ -859,6 +862,7 @@ static void autoconfig_16550a(struct uar
> DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
> }
> serial_outp(up, UART_IER, iersave);
> +#endif
> }
>
> /*
> @@ -1348,7 +1352,12 @@ static irqreturn_t serial8250_interrupt(
>
> up =3D list_entry(l, struct uart_8250_port, list);
>
> +#ifdef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> + /* read IIR as part of 32-bit word */
> + iir =3D (in_be32((u32 *)(up->port.membase + UART_RX)) >> 8) & =
0xff;
> +#else
> iir =3D serial_in(up, UART_IIR);
> +#endif
> if (!(iir & UART_IIR_NO_INT)) {
> serial8250_handle_port(up, regs);
>
> @@ -1529,7 +1538,9 @@ static int serial8250_startup(struct uar
> {
> struct uart_8250_port *up =3D (struct uart_8250_port *)port;
> unsigned long flags;
> +#ifndef CONFIG_TSI108_BRIDGE
> unsigned char lsr, iir;
> +#endif
> int retval;
>
> up->capabilities =3D uart_config[up->port.type].flags;
> @@ -1567,7 +1578,9 @@ #endif
> */
> (void) serial_inp(up, UART_LSR);
> (void) serial_inp(up, UART_RX);
> +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> (void) serial_inp(up, UART_IIR);
> +#endif
> (void) serial_inp(up, UART_MSR);
>
> /*
> @@ -1634,6 +1647,7 @@ #endif
>
> serial8250_set_mctrl(&up->port, up->port.mctrl);
>
> +#ifndef CONFIG_TSI108_BRIDGE
> /*
> * Do a quick test to see if we receive an
> * interrupt when we enable the TX irq.
> @@ -1652,6 +1666,7 @@ #endif
> } else {
> up->bugs &=3D ~UART_BUG_TXEN;
> }
> +#endif
>
> spin_unlock_irqrestore(&up->port.lock, flags);
>
> @@ -1678,7 +1693,9 @@ #endif
> */
> (void) serial_inp(up, UART_LSR);
> (void) serial_inp(up, UART_RX);
> +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> (void) serial_inp(up, UART_IIR);
> +#endif
> (void) serial_inp(up, UART_MSR);
>
> return 0;
> --=20
> 1.3.0
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Ric Wheeler @ 2006-05-18 12:01 UTC (permalink / raw)
To: Zang Roy-r61911, Mark Lord
Cc: Alexandre.Bounine, linuxppc-dev list, linux-kernel, linux-ide,
Paul Mackerras, Yang Xin-Xin-r48390, jgarzik
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626DE6E@zch01exm40.ap.freescale.net>
Mark Lord has been actively working on the sata_mv driver recently,
ric
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
>
>
>
>On May 17, 2006, at 5:14 AM, Zang Roy-r61911 wrote:
>
>
>
>>Fix Marvell SATA driver bugs on PowerPC platform:
>>SATA device can't work for the problem on little-endian mode.
>>U-Boot can't find SATA device after kernel reboots.
>>
>>Signed-off-by: Hongjun cheng <hong-jun.chen@reescale.com>
>>Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>>
>>
>>
>>>From nobody Mon Sep 17 00:00:00 2001
>>>
>>>
>>From: roy zang <tie-fei.zang@freescale.com>
>>Date: Tue May 16 15:25:23 2006 +0800
>>Subject: [PATCH] Fix bugs on powerpc platform for mv sata driver
>>
>>
>
>This needs to go to Jeff Garzik as SATA driver maintainer.
>
>- kumar
>
>
>
>> drivers/scsi/sata_mv.c | 10 +++++++++-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>>d82ac19d259f8487a31105eaf844a93cbd9008e8
>>diff --git a/drivers/scsi/sata_mv.c b/drivers/scsi/sata_mv.c
>>index d5fdcb9..4166422 100644
>>--- a/drivers/scsi/sata_mv.c
>>+++ b/drivers/scsi/sata_mv.c
>>@@ -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
>> }
>>
>> /**
>>@@ -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
>>
>> /* FIXME: handle MV_HP_ERRATA_50XXB2 errata */
>>
>> tmp = readl(mmio + MV_PCI_EXP_ROM_BAR_CTL);
>>+#ifdef CONFIG_PPC
>>+ tmp &= ~(1 << 0);
>>+#else
>> tmp |= ~(1 << 0);
>>+#endif
>> writel(tmp, mmio + MV_PCI_EXP_ROM_BAR_CTL);
>> }
>>
>>--
>>1.3.0
>>_______________________________________________
>>Linuxppc-dev mailing list
>>Linuxppc-dev@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Jimi Xenidis @ 2006-05-18 12:22 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1147908963.7360.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
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 :)
>> -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.
-JX
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ 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