Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Wed, Apr 08, 2009 at 03:51:26PM +1000, Tony Breeds wrote: Hmm actually I think you're right. I dont want to push my luck with the gcc hackers though Replying to myself. Yes this is a gcc bug but one introduced by CONFIG_TRACE_ALL_BRANCHES (or whatever that's called). Yours Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally prefer, but this works I
guess.
I was hoping someone would notice and suggest it. tag you're it!
I meant we /could/ change them, but we could also leave them, it's a bit
of a coin-flip which is better. Nathan might have an opinion?
Something like this:
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index bb37b1d..9f3a155 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -191,7 +191,7 @@ static void cache_cpu_set(struct cache *cache, int cpu)
}
}
-static int cache_size(const struct cache *cache, unsigned int *ret)
+static int cache_size(const struct cache *cache)
{
const char *propname;
const u32 *cache_size;
@@ -202,19 +202,18 @@ static int cache_size(const struct cache *cache, unsigned
if (!cache_size)
return -ENODEV;
- *ret = *cache_size;
- return 0;
+ return cache_size;
}
-static int cache_size_kb(const struct cache *cache, unsigned int *ret)
+static int cache_size_kb(const struct cache *cache)
{
unsigned int size;
- if (cache_size(cache, size))
- return -ENODEV;
+ size = cache_size(cache);
+ if (size 0)
+ return size;
- *ret = size / 1024;
- return 0;
+ return size / 1024;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
@@ -515,8 +514,9 @@ static ssize_t size_show(struct kobject *k, struct kobj_attr
cache = index_kobj_to_cache(k);
- if (cache_size_kb(cache, size_kb))
- return -ENODEV;
+ size_kb = cache_size_kb(cache);
+ if (size_kb 0)
+ return size_kb;
return sprintf(buf, %uK\n, size_kb);
}
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
Grant Likely wrote: On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger w...@grandegger.com wrote: Preserve I2C clock settings for the Socrates MPC8544 board. I had thought that the preserve-clocking property was intended for older boards that don't currently have any method of getting the clock setting out of u-boot. Since Socrates is a new board, U-Boot should probably be made to fill in the real clock rate setting. I'm not sure if I understand what you mean. If an old version of U-Boot on an old board sets the I2C clock, it can be used (inherited) by Linux using the property preserve-clocking. It is actually the customers choice to set the I2C clock in U-Boot and re-use it by Linux. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Michael Ellerman wrote: On Tue, 2009-04-07 at 19:36 -0500, Timur Tabi wrote: On Tue, Apr 7, 2009 at 6:57 PM, Tejun Heo t...@kernel.org wrote: Hmmm... that means intx isn't set by default. I'm not sure what is the right thing to do here. I think it's something which should be handled by the PCI layer. Oh well, maybe we should just revert the change and keep setting intx? cc'ing linuxppc-dev I really don't know what should be done. It seems to make sense to have the PCI layer enable interrupts. This seems to be a powerpc-specific bug, but I don't know enough of the PCI subsystem. Have you confirmed that INTX is disabled before that call? The symptoms definitely indicate such, as well as his reversing that commit. My guess is that this is a ULI M1575-specific bug, and the PCI layer needs a quirk that knows this device does -not- disable INTX, when MSI is enabled. But honestly, I never saw any harm in disabling INTX manually. Indeed, I wrote the code that disabled INTX out of now-substantiated paranoia that some PCI devices would be too dumb to follow that particular MSI rule... and the cost of twiddling INTX seemed quite low in comparison the potential problems created by the absence of INTX twiddling. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
Kumar Gala wrote: On Apr 8, 2009, at 12:11 AM, Kumar Gala wrote: On Apr 7, 2009, at 3:20 AM, Wolfgang Grandegger wrote: This patch series makes the I2C bus speed configurable by using the I2C node property clock-frequency. If the property is not defined, the old fixed clock settings will be used for backward compatibility. The property fsl,preserve-clocking allows to inherit the settings from the bootloader. Furthermore, it does some cleanup and uses the new bindings for the Socrates board: i2c: i2c-mpc: various coding style fixes i2c: i2c-mpc: use dev based printout function i2c: i2c-mpc: make I2C bus speed configurable It looks like Ben picked up these patches. powerpc: i2c-mpc: document new FSL I2C bindings and cleanup powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board I would have preferred these two go via me, but it looks like the board one got picked up by Ben. I'll deal with the doc/binding update. Ben, could you please consider this patch series for inclusion into 2.6.30 So I'm a bit concerned with the output we now get: mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49) why 0? is that right? This is the backward compatibility mode using hard-coded FDR values. The output is missleading, I agree. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Wed, 8 Apr 2009, Michael Ellerman wrote:
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally prefer, but this works I
guess.
I was hoping someone would notice and suggest it. tag you're it!
I meant we /could/ change them, but we could also leave them, it's a bit
of a coin-flip which is better. Nathan might have an opinion?
Something like this:
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index bb37b1d..9f3a155 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
-static int cache_size_kb(const struct cache *cache, unsigned int *ret)
+static int cache_size_kb(const struct cache *cache)
{
unsigned int size;
`int size', or Roel will come to get you ;-)
- if (cache_size(cache, size))
- return -ENODEV;
+ size = cache_size(cache);
+ if (size 0)
+ return size;
I can't check the others, due to lacking context...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[2.6.30-rc1] Crash in .hpte_need_flush with hugetlbfs test[shm-fork]
I was executing libhugetlbfs tests on a power6 box [9117-MMA]. One of the sub test (shm-fork) caused the machine to crash. Here is the information : llm62 login: cpu 0x1: Vector: 300 (Data Access) at [c000f9827490] pc: c0038028: .hpte_need_flush+0x1b8/0x2d8 lr: c0037edc: .hpte_need_flush+0x6c/0x2d8 sp: c000f9827710 msr: 80009032 dar: c000d0157260 dsisr: 4000 current = 0xc000f970bc20 paca= 0xc0a82500 pid = 11314, comm = shm-fork enter ? for help [c000f9827710] c0038050 .hpte_need_flush+0x1e0/0x2d8 (unreliable) [c000f98277d0] c0039d78 .huge_ptep_get_and_clear+0x40/0x5c [c000f9827850] c010fe88 .__unmap_hugepage_range+0x178/0x2b8 [c000f9827940] c011001c .unmap_hugepage_range+0x54/0x88 [c000f98279e0] c00f9dc4 .unmap_vmas+0x178/0x8f4 [c000f9827b30] c00ff4f4 .unmap_region+0xfc/0x1d8 [c000f9827c00] c0100c68 .do_munmap+0x2f4/0x38c [c000f9827cc0] c0289a74 .SyS_shmdt+0xc0/0x188 [c000f9827d70] c000c30c .sys_ipc+0x26c/0x2f4 [c000f9827e30] c00084ac syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 0420d2dc SP (fffd23a3c50) is in userspace 1:mon di %pc c0038028 eb898000 ld r28,-32768(r9) c003802c 2f80 cmpwi cr7,r0,0 c0038030 409e0028 bne cr7,c0038058# .hpte_need_flush+0x1e8/0x2d8 c0038034 7fe3fb78 mr r3,r31 c0038038 7f24cb78 mr r4,r25 c003803c 7f85e378 mr r5,r28 c0038040 7f6607b4 extsw r6,r27 c0038044 7fa7eb78 mr r7,r29 c0038048 3900 li r8,0 c003804c 4bffc2cd bl c0034318# .flush_hash_page+0x0/0x1c0 c0038050 6000 nop c0038054 48bc b c0038110# .hpte_need_flush+0x2a0/0x2d8 c0038058 7f0b07b5 extsw. r11,r24 c003805c 41820030 beq c003808c# .hpte_need_flush+0x21c/0x2d8 c0038060 e81e0010 ld r0,16(r30) c0038064 7fba cmpdcr7,r26,r0 1:mon r R00 = R16 = 4f42e5b0 R01 = c000f9827710 R17 = R02 = c098cf58 R18 = 9010 R03 = 0004 R19 = R04 = 03ffec00 R20 = R05 = c000d014f260 R21 = 0400 R06 = 220008000393 R22 = c000d014f260 R07 = 0001 R23 = 0076 R08 = 0004 R24 = R09 = c000d015f260 R25 = 220008000393 R10 = 0003ffec R26 = c000f947ca80 R11 = 0330 R27 = 0004 R12 = 24022422 R28 = c0790430 R13 = c0a82500 R29 = 0001 R14 = 0010 R30 = c0ef0430 R15 = R31 = 0fa89fffec00 pc = c0038028 .hpte_need_flush+0x1b8/0x2d8 lr = c0037edc .hpte_need_flush+0x6c/0x2d8 msr = 80009032 cr = 44022424 ctr = c00fedc0 xer = 0001 trap = 300 dar = c000d0157260 dsisr = 4000 1:mon di %lr c0037edc 6000 nop c0037ee0 7c7b1b78 mr r27,r3 c0037ee4 e8028cd8 ld r0,-29480(r2) c0037ee8 7fbf0040 cmpld cr7,r31,r0 c0037eec 419d00a8 bgt cr7,c0037f94# .hpte_need_flush+0x124/0x2d8 c0037ef0 3800 li r0,-1 c0037ef4 3ba0 li r29,0 c0037ef8 78000600 clrldi r0,r0,24 c0037efc 7fbf0040 cmpld cr7,r31,r0 c0037f00 409d000c ble cr7,c0037f0c# .hpte_need_flush+0x9c/0x2d8 c0037f04 e9228ce0 ld r9,-29472(r2) c0037f08 eba90002 lwa r29,0(r9) c0037f0c 2fbd cmpdi cr7,r29,0 c0037f10 e97a0390 ld r11,912(r26) c0037f14 409e003c bne cr7,c0037f50# .hpte_need_flush+0xe0/0x2d8 c0037f18 796b83e4 rldicr r11,r11,16,47 1:mon CONFIG_PPC_64K_PAGES=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y Have attached the dmesg log extracted via xmon. The libhugetlbfs tests [v2.0] are part of autotest framework [autotest.kernel.org]. The sub test that caused this was shm-fork. I have attached the libhugetlbfs execution log. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - 72 bind 65536). 6TCP reno registered. 6NET: Registered protocol family 1. 6Unpacking initramfs... done. 7irq: irq 655360 on host null mapped to virtual irq 17. 7irq: irq 655362 on host null mapped to virtual irq 18. 6IOMMU table initialized, virtual merging enabled. 7irq: irq 589825 on host null mapped to virtual irq 19. 7RTAS daemon started.
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman mich...@ellerman.id.au wrote: Have you confirmed that INTX is disabled before that call? How do I do that? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards
Anton == Anton Vorontsov avoront...@ru.mvista.com writes:
Hi,
Anton The advantages of this:
Anton - Don't encourage legacy support;
Anton - Less external symbols, less code to compile-in for !MPC832x_RDB
Anton platforms.
It's nice with your cleanups, but I wonder how to handle more
complicated chip select handling than simply toggling a single gpio.
I have a board (or 2 actually, but they are similar in this regard)
with a mpc8347 using SPI to a number of addon boards. For signal
integrity reasons the SPI signals are routed to a MUX, so the chip
select logic has to set the MUX in addition to controlling the CS line
of the device.
I've been using code like this since late 2007, but this patch
ofcourse breaks it:
static void thinx_spi_activate_cs(u8 cs, u8 polarity)
{
static u8 old_cs = 255;
if (cs != old_cs) {
/* mux setup (cs 2:1)*/
gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 1);
gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL0, cs2);
gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL1, cs4);
gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 0);
old_cs = cs;
}
switch (cs) {
case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, polarity); break;
case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, polarity); break;
case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, polarity); break;
case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, polarity); break;
}
}
static void thinx_spi_deactivate_cs(u8 cs, u8 polarity)
{
switch (cs) {
case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, !polarity); break;
case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, !polarity); break;
case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, !polarity); break;
case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, !polarity); break;
}
}
static __init int thinx_spi_init(void)
{
struct device_node *np;
struct of_gpio_chip *gc;
static const int gpios[] = {
GPIO_SPI_CS_BKL1,
GPIO_SPI_CS_BKL2,
GPIO_SPI_CS_OPT1,
GPIO_SPI_CS_OPT2,
GPIO_SPI_MUX_NOE,
GPIO_SPI_MUX_SEL0,
GPIO_SPI_MUX_SEL1
};
int i;
np = of_find_node_by_name(NULL, gpio-controller);
if (!np || !np-data) {
printk(KERN_ERR
gpio1 node not found or controller not registerred\n);
return -ENODEV;
}
gc = np-data;
gpio1 = gc-gc.base;
for (i=0; iARRAY_SIZE(gpios); i++) {
gpio_request(gpio1 + gpios[i], spi);
gpio_direction_output(gpio1 + gpios[i], 1);
}
fsl_spi_init(thinx_spi_boardinfo, ARRAY_SIZE(thinx_spi_boardinfo),
thinx_spi_activate_cs, thinx_spi_deactivate_cs);
return 0;
}
Now, I don't quite see how to handle this with the new OF bindings -
Any ideas?
--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi all,
The legacy i2c model is going away soon, the remaining drivers that
still use it need to be converted very quickly. There are 3 sound
drivers remaining:
sound/aoa/codecs/onyx.c
sound/aoa/codecs/tas.c
sound/ppc/keywest.c
I've given a try to the former two, patch below. I could only
build-test it, so I would appreciate if anyone with supported hardware
could test the patch. I also welcome reviews and comments, of course. I
am not familiar with PowerPC so I might as well have done it wrong.
Basically the idea is to move the I2C device instantiation from the
codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.)
This follows the Linux device driver model, requires slightly less
code, runs faster and and lets the required chip drivers be loaded by
udev or similar automatically.
The last driver to convert, keywest, is a mystery to me. I have a hard
time understanding how it interacts with tumbler and daca. I have the
feeling that it is essentially a glue module to workaround the legacy
i2c model limitations, so probably it could go away entirely now, but
I'm not sure how to do that in practice. Maybe tumbler and daca would
be made separate i2c drivers, I'm not sure.
One thing in particular which I find strange is that tumbler has
references to the TAS3004 device, much like the tas codec driver. It is
unclear to me whether tas is a replacement for tumbler, or if both
drivers work together, or if they are for separate hardware. I would
appreciate clarifications about this.
Thanks.
* * * * *
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Johannes Berg johan...@sipsolutions.net
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/i2c/busses/i2c-powermac.c | 76 +++
sound/aoa/codecs/onyx.c | 77 +++-
sound/aoa/codecs/tas.c| 89 +
3 files changed, 116 insertions(+), 126 deletions(-)
--- linux-2.6.30-rc1.orig/drivers/i2c/busses/i2c-powermac.c 2009-04-08
08:52:48.0 +0200
+++ linux-2.6.30-rc1/drivers/i2c/busses/i2c-powermac.c 2009-04-08
13:48:31.0 +0200
@@ -204,7 +204,7 @@ static int __devexit i2c_powermac_remove
static int __devinit i2c_powermac_probe(struct platform_device *dev)
{
struct pmac_i2c_bus *bus = dev-dev.platform_data;
- struct device_node *parent = NULL;
+ struct device_node *parent = NULL, *busnode, *devnode;
struct i2c_adapter *adapter;
char name[32];
const char *basename;
@@ -212,6 +212,7 @@ static int __devinit i2c_powermac_probe(
if (bus == NULL)
return -EINVAL;
+ busnode = pmac_i2c_get_bus_node(bus);
/* Ok, now we need to make up a name for the interface that will
* match what we used to do in the past, that is basically the
@@ -289,6 +290,79 @@ static int __devinit i2c_powermac_probe(
}
}
+ devnode = NULL;
+ while ((devnode = of_get_next_child(busnode, devnode)) != NULL) {
+ struct i2c_board_info info;
+ const u32 *addr;
+
+ /* Instantiate I2C sound device if present */
+ if (of_device_is_compatible(devnode, pcm3052)) {
+ printk(KERN_DEBUG i2c-powermac: found pcm3052\n);
+ addr = of_get_property(devnode, reg, NULL);
+ if (!addr)
+ continue;
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ info.addr = (*addr) 1;
+ strlcpy(info.type, aoa_codec_onyx, I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_device(adapter, info);
+ continue;
+ }
+
+ if (of_device_is_compatible(devnode, tas3004)) {
+ printk(KERN_DEBUG i2c-powermac: found tas3004\n);
+ addr = of_get_property(devnode, reg, NULL);
+ if (!addr)
+ continue;
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ info.addr = ((*addr) 1) 0x7f;
+ strlcpy(info.type, aoa_codec_tas, I2C_NAME_SIZE);
+ info.platform_data = devnode;
+ i2c_new_device(adapter, info);
+ continue;
+ }
+
+ /* older machines have no 'codec' node with a 'compatible'
+* property that says 'tas3004', they just have a 'deq'
+* node without any such property... */
+ if (strcmp(devnode-name, deq) == 0) {
+ printk(KERN_DEBUG i2c-powermac: found 'deq' node\n);
+ addr = of_get_property(devnode,
any place to mark various compatible strings as deprecated?
Do we have anywhere to list out compatible strings that are deprecated and warn if the kernel sees one? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: any place to mark various compatible strings as deprecated?
On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote: Do we have anywhere to list out compatible strings that are deprecated and warn if the kernel sees one? Wouldn't dtc be a better location for that? The kernel has to be backwards compatible anyway, I don't really see a reason to warn there. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger w...@grandegger.com wrote: Preserve I2C clock settings for the Socrates MPC8544 board. I had thought that the preserve-clocking property was intended for older boards that don't currently have any method of getting the clock setting out of u-boot. Since Socrates is a new board, U-Boot should probably be made to fill in the real clock rate setting. I'm not sure if I understand what you mean. If an old version of U-Boot on an old board sets the I2C clock, it can be used (inherited) by Linux using the property preserve-clocking. It is actually the customers choice to set the I2C clock in U-Boot and re-use it by Linux. Setting it in the register != recording the value in the device tree. I'm saying that since Socrates is a new board it should not use the preserve-clocking dirty trick (and it is a dirty trick) because the correct clocking data can be passed via the device tree. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote: So I'm a bit concerned with the output we now get: mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49) why 0? is that right? This is the backward compatibility mode using hard-coded FDR values. The output is missleading, I agree. Wolfgang. Can the output be fixed. 0 Hz seemed bad to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: any place to mark various compatible strings as deprecated?
On Apr 8, 2009, at 9:48 AM, Olof Johansson wrote: On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote: Do we have anywhere to list out compatible strings that are deprecated and warn if the kernel sees one? Wouldn't dtc be a better location for that? The kernel has to be backwards compatible anyway, I don't really see a reason to warn there. The reason is I want to eventually drop support in the kernel for some of the old compatibles. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
Hello, I found the ibm_newemac driver(2.6.29) makes the assumption that the bootloader has already configured the tx enable pin as it is a multiplexed pin. Unfortuantley I am not using U-Boot and our minimal bootloader does not do this. After finding tx enable was never asserting for Eth0 a quick user space program verified tx enable was configured as a GPIO pin. I would like to eventually submit our changes for upstream support. Based on this would you recommend ensuring tx enable is configured properly in the initialization of the ibm_newemac driver or the platform initialization? On Tue, Apr 7, 2009 at 9:32 AM, Eddie Dawydiuk ed...@embeddedarm.com wrote: Hello, I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm having some difficulty getting both network interfaces working. The first problem I found is the ibm_newemac driver was detecting the two phys at address 0 and 1 where we have them wired for addresses 1 and 3. As a result I hardcoded the phy-address in the dts file. I then found I was able to receive and send data on eth1(phy-address 3) without incident. Although I found eth0 can receive data but I see no packets being transmitted(using a packet sniffer) and I see no indication from a software standpoint of any transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode) where the Yosemite board used Micrel KS8721BL phys. I've reviewed the schematic and it appears both phys are connected identically and I've seen this same failure on multiple boards. I thought the fact that the driver detected a phy at address 0 might be a clue, but I can't make much of the clue. So I thought I'd post this info in the hopes someone else might have run into a similar problem or have a suggestion. Phy address 0 is the broadcast address. All phys will usually respond to address 0 accesses. Off the top of my head, It sounds like one PHY is responding to addresses 0 1, and the other phy isn't responding at all. g. -- Best Regards, Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200 16525 East Laser Drive | fax:(480) 837-5300 Fountain Hills, AZ 85268| web: www.embeddedARM.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: any place to mark various compatible strings as deprecated?
On Wed, Apr 08, 2009 at 09:48:45AM -0500, Olof Johansson wrote: On Wed, Apr 08, 2009 at 09:23:22AM -0500, Kumar Gala wrote: Do we have anywhere to list out compatible strings that are deprecated and warn if the kernel sees one? Wouldn't dtc be a better location for that? The kernel has to be backwards compatible anyway, I don't really see a reason to warn there. It should certainly be in dtc. Whether it should also be in the kernel is debatable. It's also really easy to add this to dtc. Kumar can you point me at the ones you're thinking of, and I'll add appropriate checks to dtc (although probably not for a couple of weeks when I return from vacation). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
On Wednesday 08 April 2009, Eddie Dawydiuk wrote: I found the ibm_newemac driver(2.6.29) makes the assumption that the bootloader has already configured the tx enable pin as it is a multiplexed pin. Unfortuantley I am not using U-Boot and our minimal bootloader does not do this. After finding tx enable was never asserting for Eth0 a quick user space program verified tx enable was configured as a GPIO pin. I would like to eventually submit our changes for upstream support. Based on this would you recommend ensuring tx enable is configured properly in the initialization of the ibm_newemac driver or the platform initialization? This GPIO multiplexing configuration does not belong into the ibm_newemac driver since it is very platform/board specific. The platform code is definitely a better place. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
On Wed, Apr 8, 2009 at 9:01 AM, Stefan Roese s...@denx.de wrote: On Wednesday 08 April 2009, Eddie Dawydiuk wrote: I found the ibm_newemac driver(2.6.29) makes the assumption that the bootloader has already configured the tx enable pin as it is a multiplexed pin. Unfortuantley I am not using U-Boot and our minimal bootloader does not do this. After finding tx enable was never asserting for Eth0 a quick user space program verified tx enable was configured as a GPIO pin. I would like to eventually submit our changes for upstream support. Based on this would you recommend ensuring tx enable is configured properly in the initialization of the ibm_newemac driver or the platform initialization? This GPIO multiplexing configuration does not belong into the ibm_newemac driver since it is very platform/board specific. The platform code is definitely a better place. Even better is the platform specific boot code (firmware or equivalent) g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
On Wed, Apr 08, 2009 at 12:22:29AM -0500, Kumar Gala wrote: hrummm. As I mentioned in my reply, I'm not convinced that the board one is the right thing in this case. I would have preferred it to be deferred. which part? I missed this whole thread as I had it forwarding to my devicetree-discuss folder which I don't normally look at. Can you reorder your filters to check for more frequently read lists first? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi! Basically the idea is to move the I2C device instantiation from the codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.) This follows the Linux device driver model, requires slightly less code, runs faster and and lets the required chip drivers be loaded by udev or similar automatically. Sounds weird -- how do you handle codecs that could be on different buses? This seems to imply that any probing may potentially need to be duplicated across any bus driver they could possibly connected to. But that's not really relevant to this patch. The last driver to convert, keywest, is a mystery to me. I have a hard time understanding how it interacts with tumbler and daca. I have the feeling that it is essentially a glue module to workaround the legacy i2c model limitations, so probably it could go away entirely now, but I'm not sure how to do that in practice. Maybe tumbler and daca would be made separate i2c drivers, I'm not sure. Sorry, I'm not familiar with this code. One thing in particular which I find strange is that tumbler has references to the TAS3004 device, much like the tas codec driver. It is unclear to me whether tas is a replacement for tumbler, or if both drivers work together, or if they are for separate hardware. I would appreciate clarifications about this. Well... tumbler also drives the very similar tas3001 codec. However, I need to start with a little more background. Apple machines can contain various codecs, for example the tas3004, which has various outputs. Due to the way Apple wires up the codec, you need platform fabric to identify which outputs are connected where, cf. sound/aoa/fabrics/layout.c. Note all machines have line-in for instance. The aoa driver, which I wrote, currently supports only i2s buses for actually transferring data, but I think there are some other ways to get data to the codec -- I'm not too familiar with the old machines. Now, aoa will currently automatically load from the layout fabric module, and then pull in the modules for the codecs it _knows_ to be present on the bus. Therefore, it seems that your patch makes things less efficient because you probe for all those codecs, and there's no machine that has all of them. The aoa fabric only loads the modules for those it knows to be present, and they then probe (and in reality the probing never fails because they really are there). Now, since aoa needs information on how the entire system is glued together (the fabric I was talking about with the line-in example), it has to infer that from platform data, in this case the device tree. Because I do not have any older machines, am lazy and snd-powermac works for the old machines, snd-powermac with its tumbler is a driver for the same tas3004 codec, but on a different, older, fabric. Once upon a time the plan was to get rid of snd-powermac entirely and port all its functionality into subdrivers of aoa, but that clearly never happened. No fairy-tale happy ending here, quite obviously. Now, looking at your patch, I think it will break snd-powermac. See, if snd_aoa_codec_tas is automatically loaded on a system with an _old_ fabric that aoa knows nothing about, snd-powermac can no longer be loaded. (Incidentally, snd-powermac cannot be auto-loaded at all currently, while aoa can via the fabric driver's device-tree binding) Therefore, probing the codecs in i2c-powermac and automatically loading the corresponding aoa module will break sound on old machines. I would think that if you removed the MODULE_DEVICE_TABLE from your patch, it may continue to work because the aoa fabric driver loads the modules as before, and on old machines nothing loads automatically and snd-powermac can be loaded manually. However, it will still be less efficient because you will be probing _all_ those codecs, notably the tas family, even on machines that are known to not have it (machines that have onyx). Putting that mutual exclusion information into i2c-powermac would be misplaced, imho. Note also that there's one more codec (topaz) which isn't currently supported. In conclusion, I think that the old/existing/legacy i2c binding model was much better suited to platform knowledge about the way machines are put together, and the new code is, as far as I can tell, less efficient -- contrary to your assertion. Since I'm away from all machines I could test this with I have no data on any that or the module device table thing I pointed out for now. Anyway, some more technical comments on your patch: * I realise you just copied things around but it would be nice to clean up the coding style, especially comment style, a little while at it. (yeah, it's my fault) * aoa_codec_* is the module name, I see no reason to use that as the i2c name, that should be the codec's name instead (aka pcm3052 etc) johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
On Apr 8, 2009, at 12:03 PM, Scott Wood wrote: On Wed, Apr 08, 2009 at 12:22:29AM -0500, Kumar Gala wrote: hrummm. As I mentioned in my reply, I'm not convinced that the board one is the right thing in this case. I would have preferred it to be deferred. which part? I missed this whole thread as I had it forwarding to my devicetree-discuss folder which I don't normally look at. Can you reorder your filters to check for more frequently read lists first? Yeah I did. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
On Wednesday 08 April 2009, Grant Likely wrote: I would like to eventually submit our changes for upstream support. Based on this would you recommend ensuring tx enable is configured properly in the initialization of the ibm_newemac driver or the platform initialization? This GPIO multiplexing configuration does not belong into the ibm_newemac driver since it is very platform/board specific. The platform code is definitely a better place. Even better is the platform specific boot code (firmware or equivalent) Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is using a custom bootloader. Eddie, btw: Why are you not using U-Boot? Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
Grant Likely wrote: On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger w...@grandegger.com wrote: Preserve I2C clock settings for the Socrates MPC8544 board. I had thought that the preserve-clocking property was intended for older boards that don't currently have any method of getting the clock setting out of u-boot. Since Socrates is a new board, U-Boot should probably be made to fill in the real clock rate setting. I'm not sure if I understand what you mean. If an old version of U-Boot on an old board sets the I2C clock, it can be used (inherited) by Linux using the property preserve-clocking. It is actually the customers choice to set the I2C clock in U-Boot and re-use it by Linux. Setting it in the register != recording the value in the device tree. I'm saying that since Socrates is a new board it should not use the preserve-clocking dirty trick (and it is a dirty trick) because the correct clocking data can be passed via the device tree. Why should an old board then use it. fsl, preserve-clocking is a new feature, like using clock-frequency and you have the choice to explicitly set the clocking via device tree or inherit it from the boot loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the registers by Linux. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
Stefan, Ack. We usually do all this setup in U-Boot. But as I understand Eddie, he is using a custom bootloader. Correct, I'll put this code in the platform initialization. Thanks for the suggestions everyone. Eddie, btw: Why are you not using U-Boot? At Technologic Systems, one of our design goals for all of our products is to achieve a very quick boot time(under 2 seconds to a shell prompt). We then provide a user space utility to boot another linux kernel, this allows our customers to use Linux as a bootloader. We boot to an initial ramdisk then use a linuxrc script as a replacement for a typical bootloader(e.g. U-Boot). In the background we can then mount a large filesystem with Debian installed. In my opinion it works out quite nicely in that one can use our boards as more of an appliance(apply power and it's on, rather than waiting for a computer to boot). -- Best Regards, Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200 16525 East Laser Drive | fax:(480) 837-5300 Fountain Hills, AZ 85268| web: www.embeddedARM.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
On Apr 8, 2009, at 1:27 PM, Wolfgang Grandegger wrote: Grant Likely wrote: On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger w...@grandegger.com wrote: Preserve I2C clock settings for the Socrates MPC8544 board. I had thought that the preserve-clocking property was intended for older boards that don't currently have any method of getting the clock setting out of u-boot. Since Socrates is a new board, U-Boot should probably be made to fill in the real clock rate setting. I'm not sure if I understand what you mean. If an old version of U- Boot on an old board sets the I2C clock, it can be used (inherited) by Linux using the property preserve-clocking. It is actually the customers choice to set the I2C clock in U-Boot and re-use it by Linux. Setting it in the register != recording the value in the device tree. I'm saying that since Socrates is a new board it should not use the preserve-clocking dirty trick (and it is a dirty trick) because the correct clocking data can be passed via the device tree. Why should an old board then use it. fsl, preserve-clocking is a new feature, like using clock-frequency and you have the choice to explicitly set the clocking via device tree or inherit it from the boot loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the registers by Linux. I think Grant's point is socrates is a new board with a new u-boot. That u-boot should be able to set the clock-frequency property in i2c. One assumes if you a clock-frequency property you wouldn't use fsl,preserve-clocking. (However -- its feasible they are mutually exclusive). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Michael Ellerman mich...@ellerman.id.au wrote: On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote: On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote: The getter routines in here could really multiplex their return values with a negative error code, which I generally prefer, but this works I guess. I was hoping someone would notice and suggest it. tag you're it! I meant we /could/ change them, but we could also leave them, it's a bit of a coin-flip which is better. Nathan might have an opinion? I think I had some reason for doing it this way, but I'm drawing a blank right now. In the meantime, can someone post the warnings that gcc emits for cacheinfo.c, as well as the gcc version? I can't reproduce them with 4.3.2 on Fedora. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 5/5] powerpc/85xx: i2c-mpc: use new I2C bindings for the Socates board
Kumar Gala wrote: On Apr 8, 2009, at 1:27 PM, Wolfgang Grandegger wrote: Grant Likely wrote: On Wed, Apr 8, 2009 at 12:16 AM, Wolfgang Grandegger w...@grandegger.com wrote: Grant Likely wrote: On Tue, Apr 7, 2009 at 1:20 AM, Wolfgang Grandegger w...@grandegger.com wrote: Preserve I2C clock settings for the Socrates MPC8544 board. I had thought that the preserve-clocking property was intended for older boards that don't currently have any method of getting the clock setting out of u-boot. Since Socrates is a new board, U-Boot should probably be made to fill in the real clock rate setting. I'm not sure if I understand what you mean. If an old version of U-Boot on an old board sets the I2C clock, it can be used (inherited) by Linux using the property preserve-clocking. It is actually the customers choice to set the I2C clock in U-Boot and re-use it by Linux. Setting it in the register != recording the value in the device tree. I'm saying that since Socrates is a new board it should not use the preserve-clocking dirty trick (and it is a dirty trick) because the correct clocking data can be passed via the device tree. Why should an old board then use it. fsl, preserve-clocking is a new feature, like using clock-frequency and you have the choice to explicitly set the clocking via device tree or inherit it from the boot loader. So far, a fixed FDR/DFRSS value (0x1031) was written to the registers by Linux. I think Grant's point is socrates is a new board with a new u-boot. That u-boot should be able to set the clock-frequency property in i2c. One assumes if you a clock-frequency property you wouldn't use fsl,preserve-clocking. (However -- its feasible they are mutually exclusive). OK, now it makes more sense to me even if I never thought that way. My intention was to allow Linux to use a *different* frequency as the bootloader by specifying the clock-frequency property. This would not be possible with a fixup by the bootloader. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
Kumar Gala wrote: On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote: So I'm a bit concerned with the output we now get: mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49) why 0? is that right? This is the backward compatibility mode using hard-coded FDR values. The output is missleading, I agree. Wolfgang. Can the output be fixed. 0 Hz seemed bad to me. Of course. No info message will be printed for the legacy case like it was with the old driver version. I just realized a bug in the MPC52xx part. Will send patches tomorrow, after some more thorough testing. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Johannes, Thanks for the fast answer. On Wed, 08 Apr 2009 17:51:39 +0200, Johannes Berg wrote: Basically the idea is to move the I2C device instantiation from the codec drivers (onyx, tas) to the I2C adapter driver (i2c-powermac.) This follows the Linux device driver model, requires slightly less code, runs faster and and lets the required chip drivers be loaded by udev or similar automatically. Sounds weird -- how do you handle codecs that could be on different buses? This seems to imply that any probing may potentially need to be duplicated across any bus driver they could possibly connected to. But that's not really relevant to this patch. Yes, probing would be duplicated if we had to support more than one bus. But as far as I can see, the onyx and tas devices can only be found on i2c-powermac buses, so this shouldn't be an issue. And there isn't really any probing going on, it's really only a matter of walking a small subset of the device tree (the children of the I2C bus) and instantiating I2C devices. Out of curiosity, are there systems with more than one system I2C buses (supported by i2c-powermac)? If there were a significant amount of duplicated code, it could certainly be addressed one way or another, but it wasn't my top priority, and actually didn't seem that necessary. As a matter of fact, my patch removes (slightly) more code than it adds. The last driver to convert, keywest, is a mystery to me. I have a hard time understanding how it interacts with tumbler and daca. I have the feeling that it is essentially a glue module to workaround the legacy i2c model limitations, so probably it could go away entirely now, but I'm not sure how to do that in practice. Maybe tumbler and daca would be made separate i2c drivers, I'm not sure. Sorry, I'm not familiar with this code. One thing in particular which I find strange is that tumbler has references to the TAS3004 device, much like the tas codec driver. It is unclear to me whether tas is a replacement for tumbler, or if both drivers work together, or if they are for separate hardware. I would appreciate clarifications about this. Well... tumbler also drives the very similar tas3001 codec. However, I need to start with a little more background. Apple machines can contain various codecs, for example the tas3004, which has various outputs. Due to the way Apple wires up the codec, you need platform fabric to identify which outputs are connected where, cf. sound/aoa/fabrics/layout.c. Note all machines have line-in for instance. The aoa driver, which I wrote, currently supports only i2s buses for actually transferring data, but I think there are some other ways to get data to the codec -- I'm not too familiar with the old machines. Now, aoa will currently automatically load from the layout fabric module, and then pull in the modules for the codecs it _knows_ to be present on the bus. Therefore, it seems that your patch makes things less efficient because you probe for all those codecs, and there's no machine that has all of them. The aoa fabric only loads the modules for those it knows to be present, and they then probe (and in reality the probing never fails because they really are there). Can you please point me to the layout fabric / aoa fabric? I'd like to understand how it works. Then I may be able to rewrite my patch completely differently. There are basically two ways to instantiate I2C devices in the new model. The first method is to declare the I2C devices as platform data and let i2c-core instantiate them. The second method is to have the i2c bus driver instantiate the clients. My patch uses the second method because I didn't know how to use the first method. However using the first method would solve the issues you raised. But I need some help from someone more familiar with the powermac platform initialization code to get it right. Now, since aoa needs information on how the entire system is glued together (the fabric I was talking about with the line-in example), it has to infer that from platform data, in this case the device tree. Because I do not have any older machines, am lazy and snd-powermac works for the old machines, snd-powermac with its tumbler is a driver for the same tas3004 codec, but on a different, older, fabric. I think I've found that one by now (snd_pmac_detect in sound/ppc/pmac.c, right?), thanks for the clarification. BTW, that code doesn't seem significantly different from what my patch is adding to i2c-powermac. Once upon a time the plan was to get rid of snd-powermac entirely and port all its functionality into subdrivers of aoa, but that clearly never happened. No fairy-tale happy ending here, quite obviously. Now, looking at your patch, I think it will break snd-powermac. See, if snd_aoa_codec_tas is automatically loaded on a system with an _old_ fabric that aoa knows nothing about, snd-powermac can no longer be loaded.
tracking of PCI address space
I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Timur Tabi wrote: On Tue, Apr 7, 2009 at 9:09 PM, Michael Ellerman mich...@ellerman.id.au wrote: Have you confirmed that INTX is disabled before that call? How do I do that? Running lspci -nnvvvxxx before loading the driver should be enough. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Tejun Heo wrote: Running lspci -nnvvvxxx before loading the driver should be enough. That might be difficult. My root file system is on my SATA drive. It'll be a while before I can build an NFS rootfs. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Timur Tabi wrote:
Tejun Heo wrote:
Running lspci -nnvvvxxx before loading the driver should be enough.
That might be difficult. My root file system is on my SATA drive.
It'll be a while before I can build an NFS rootfs.
Yeah, right. The following patch should do the trick then.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 788bba2..b3f4df7 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -2606,6 +2606,12 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
+ {
+ u16 cmd;
+ pci_read_config_word(pdev, PCI_COMMAND, cmd);
+ printk(XXX PCI_COMMAND=0x%x\n, cmd);
+ }
+
/* The AHCI driver can only drive the SATA ports, the PATA driver
can drive them all so if both drivers are selected make sure
AHCI stays out of the way */
--
tejun
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
From: Suneel [mailto:suneel.garap...@xilinx.com]
Added support for the new xps tft controller.
The new core has PLB interface support in addition to existing
DCR interface.
The driver has been modified to support this new core which
can be connected on PLB or DCR bus.
Signed-off-by: Suneel sune...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com
---
drivers/video/xilinxfb.c | 227 --
1 files changed, 160 insertions(+), 67 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index a82c530..a28a834 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,17 +1,24 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* sou...@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed as is without any warranty of any
- * kind, whether express or implied.
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
+ * 02139, USA.
*/
/*
@@ -31,27 +38,31 @@
#include linux/fb.h
#include linux/init.h
#include linux/dma-mapping.h
-#if defined(CONFIG_OF)
#include linux/of_device.h
#include linux/of_platform.h
-#endif
-#include asm/io.h
+#include linux/io.h
#include linux/xilinxfb.h
#include asm/dcr.h
#define DRIVER_NAMExilinxfb
-#define DRIVER_DESCRIPTION Xilinx TFT LCD frame buffer driver
+
/*
* Xilinx calls it PLB TFT LCD Controller though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display
controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a 640x480 resolution TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR0
@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
+ u32 regs_phys; /* phys. address of the control
+ registers */
+ void __iomem*regs; /* virt. address of the control
+ registers */
+
dcr_host_t dcr_host;
unsigned intdcr_start;
unsigned intdcr_len;
@@ -120,6 +136,10 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
+ u32 dcr_splb_slave_if;
+ /* True, if control interface is
+ connected through plb */
+
u32 reg_ctrl_default;
u32 pseudo_palette[PALETTE_ENTRIES_NO];
@@ -130,14 +150,19 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- dcr_write(driverdata-dcr_host, offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata-dcr_splb_slave_if == 1)
+ out_be32(drvdata-regs + (offset 2), val);
+
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Tejun Heo wrote: Yeah, right. The following patch should do the trick then. Thanks, I appreciate it. I get this output: XXX PCI_COMMAND=0x407 -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Timur Tabi wrote: Tejun Heo wrote: Yeah, right. The following patch should do the trick then. Thanks, I appreciate it. I get this output: XXX PCI_COMMAND=0x407 ^ Yeah, that's INTX disable. Strange that the controller has the bit set on boot. I'm curious where this is from, the controller reset, firmware or the PCI init (in decreasing likelihood). Hmmm... for now, I think it would be best to revert the original change. Jeff, can you please do that? Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: tracking of PCI address space
On Apr 8, 2009, at 4:49 PM, Ira Snyder wrote: On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote: I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. To the best of my knowledge there is no API to set inbound windows in Linux. I've been implementing a virtio-over-PCI driver which needs the inbound windows. I set them up myself during driver probe, using get_immrbase() to get the IMMR registers. This board is a PCI Slave / Agent, it doesn't even have PCI support compiled into the kernel. I'm not concerned explicitly about setting up inbound windows, its more about have a consistent view of the PCI address space which may be different from the CPU physical address space. I'm working on code to actually setup the inbound windows on 85xx/86xx class devices (based on dma-ranges property in the device tree). As I was thinking about this I realized that the send of ranges/dma-ranges in the .dts and what we map to outbound vs inbound changes if we an agent or host. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote: Hmmm... for now, I think it would be best to revert the original change. Jeff, can you please do that? Actually, give me a few days before you do that. A colleague gave me some suggestions to debug this. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Xilinx board and NPTL support lockup
Hi everyone, I have a board similar to the ml410, its been running a linux kernel happily for about a year now, but now the firmware guys want NPTL threading instead of the linuxthread library. I recompiled my gcc 4.0.2 and glibc 2.3.6 library with the NPTL support, and recompiled my kernel with the new tools. Now my kernel gets stuck at the infamous Now Booting the Kernel message. Any thoughts on why this might be happening, or how to verify that my glibc and gcc are functional other than trying to compile things with them (I know this works). Thanks Kevin -- View this message in context: http://www.nabble.com/Xilinx-board-and-NPTL-support-lockup-tp22960621p22960621.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote: I think I had some reason for doing it this way, but I'm drawing a blank right now. In the meantime, can someone post the warnings that gcc emits for cacheinfo.c, as well as the gcc version? I can't reproduce them with 4.3.2 on Fedora. --- [t...@thor ~]$ egrep cacheinfo tmp/build.log /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'associativity_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562: warning: 'associativity' may be used uninitialized in this function /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'size_show': /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:513: warning: 'size_kb' may be used uninitialized in this function t...@sprygo:~/scratch$ /opt/crosstool/gcc-4.4.0-20090216-nolibc/powerpc-linux/bin/powerpc-linux-gcc -v Using built-in specs. Target: powerpc-linux Configured with: /home/tony/buildall/src/gcc/configure --target=powerpc-linux --enable-targets=all --prefix=/opt/crosstool/gcc-4.4.0-20090216-nolibc/powerpc-linux --program-prefix=powerpc-linux- --disable-bootstrap --with-mpfr=/usr --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release Thread model: single gcc version 4.4.0 20090216 (experimental) (GCC) t...@sprygo:~/scratch$ --- That's the compiler in rawhide Yours Tony ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can you
please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
What device did you say it was? A ULI M1575 ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575, hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 126));
..
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)
Hi John, On Wed, 8 Apr 2009 15:11:25 -0600 John Linn john.l...@xilinx.com wrote: * 2002-2007 (c) MontaVista Software, Inc. * 2007 (c) Secret Lab Technologies, Ltd. + * 2009 (c) Xilinx Inc. * - * This file is licensed under the terms of the GNU General Public License - * version 2. This program is licensed as is without any warranty of any - * kind, whether express or implied. + * 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. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the Free + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA + * 02139, USA. This changes the license for this file (from GPLv2 to GPLv2 or later). Have you asked the other copyright owners about that? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpvlWOQzo3Ac.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpic_find() was overloaded to do two things introduce mpic_is_ipi() and simplify mpic_find()
On Wed, 2009-04-08 at 14:26 +1000, Tony Breeds wrote: Also silences the warning: arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority': arch/powerpc/sysdev/mpic.c:1382: warning: 'is_ipi' may be used uninitialized in this function Signed-off-by: Tony Breeds t...@bakeyournoodle.com --- Only compile tested. Not even compile tested, but looks good. Acked-by: Michael Ellerman mich...@ellerman.id.au cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can
you
please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
What device did you say it was? A ULI M1575 ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 126));
..
It is the odd thing is the board he's running on is a mpc86xx_hpcd so
he shouldn't be hitting the code that actually disables INTx.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can
you
please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
What device did you say it was? A ULI M1575 ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 126));
..
It is the odd thing is the board he's running on is a mpc86xx_hpcd so
he shouldn't be hitting the code that actually disables INTx.
Sorry Kumar that's not parsing :)
He is running an mpc86xx_hpcd, so he _should_ be hitting the code that
disables INTX?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
On Apr 8, 2009, at 11:38 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can
you
please do that?
Actually, give me a few days before you do that. A colleague
gave me
some suggestions to debug this.
What device did you say it was? A ULI M1575 ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 126));
..
It is the odd thing is the board he's running on is a mpc86xx_hpcd so
he shouldn't be hitting the code that actually disables INTx.
Sorry Kumar that's not parsing :)
He is running an mpc86xx_hpcd, so he _should_ be hitting the code that
disables INTX?
duh.. reading the !machine_is.. code incorrectly.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ahci: drop intx manipulation on msi enable breaks ULI M1575
Michael Ellerman wrote:
On Wed, 2009-04-08 at 23:23 -0500, Kumar Gala wrote:
On Apr 8, 2009, at 6:53 PM, Michael Ellerman wrote:
On Wed, 2009-04-08 at 17:15 -0500, Timur Tabi wrote:
On Wed, Apr 8, 2009 at 4:31 PM, Tejun Heo t...@kernel.org wrote:
Hmmm... for now,
I think it would be best to revert the original change. Jeff, can
you
please do that?
Actually, give me a few days before you do that. A colleague gave me
some suggestions to debug this.
What device did you say it was? A ULI M1575 ?
Is that this one?
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x1575,
hpcd_quirk_uli1575);
static void __devinit hpcd_quirk_uli1575(struct pci_dev *dev)
{
u32 temp32;
if (!machine_is(mpc86xx_hpcd))
return;
/* Disable INTx */
pci_read_config_dword(dev, 0x48, temp32);
pci_write_config_dword(dev, 0x48, (temp32 | 126));
..
It is the odd thing is the board he's running on is a mpc86xx_hpcd so
he shouldn't be hitting the code that actually disables INTx.
Sorry Kumar that's not parsing :)
He is running an mpc86xx_hpcd, so he _should_ be hitting the code that
disables INTX?
The reversed logic of the PCI bit itself also makes for confusing
discusion. In an attempt to be helpful, here is a restatement of what
is happening:
1) Old 'ahci' used to clear PCI_COMMAND_INTX_DISABLE, thus ensuring INTX
interrupts are enabled... if and only if MSI is unavailable.
2) Current 'ahci' no longer does this
3) As a result, Timur's 'ahci' is no longer receiving interrupts.
Presumably this means that BOTH of the following conditions are true
a) INTX is disabled
b) MSI is not available
Today I am thinking we should either revert the libata commit
(a5bfc4714b3f01365aef89a92673f2ceb1ccf246), or poke PCI to twiddle INTX
for us at pci_enable_device() time, perhaps.
I lean towards the former, but maybe the platform folks prefer a third
solution?
Jeff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
