* Re: About BDI2000 and mpc8247
From: Mark Chambers @ 2006-05-18 14:22 UTC (permalink / raw)
To: Gosiuua, linuxppc-embedded
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> Hello List..
>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
>
<snip>
> - Waiting for target stop failed
> - TARGET: Break at boot vector failed, freeze forced
> /*****/
>
>
> BDI can't bread the CPU and i don't know what can i do!
> Any one can help me?
> _______________________________________________
I have had the same issue. You need lines similar to the following
in your bdi config file to stop the watchdog timer. Then you will
need other lines to set various registers to match your hardware
bus widths, etc.
[INIT]
; init core register
WREG MSR 0x00001042 ;MSR : ME,RI, exceptions high
WM32 0x000101a8 0xf0000000 ;move internal space
WM32 0xf0010004 0xFFFFFFC1 ;SYPCR: disable watchdog
Mark C.
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Laurent Pinchart @ 2006-05-18 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Gosiuua
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
[...]
You should tell the BDI to initialize the SYPCR register, otherwise the
internal watchdog timer will keep resetting the CPU.
[INIT]
; *** Initialize the core internal registers
; Program the SYPCR - Disable the watchdog timer
WM32 0xf0010004 0xffff2081
You will need to initiliaze other internal registers as well (BCR, SIUMCR,
BRx, ORx, ...).
I'm not sure if this will be enough to solve your problem, but it should at
least be a start.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 0/10] powerpc: add mpc7448hpc2 (Taiga) board support
From: Kumar Gala @ 2006-05-18 14:08 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626D618@zch01exm40.ap.freescale.net>
On May 17, 2006, at 5:13 AM, Zang Roy-r61911 wrote:
> Hi, Paul
>
> This series of patch adds mpc7448hpc2 (taiga) board support in
> arch/powerpc.
> Tsi108 chip of Tundra Semiconductor is also supported.
>
> Roy Zang
Can you post your .dts for us to take a look at. I know Mark Greer
is looking at support for the 105/6/7 family of bridges and the 10x
family should have consistent flat device trees.
- kumar
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <17516.20191.490360.852876@cargo.ozlabs.ibm.com>
On May 18, 2006, at 5:39 AM, Paul Mackerras wrote:
> Zang Roy-r61911 writes:
>
>> I can migrate my code to embedded6xx technically. In fact,
>> I can move it into anywhere in the arch/powerpc/platforms.
>> While for mpc7448hpc2(taiga) board, it is not a embedded
>> application board. It is a high performance server! It seems
>> odd to put code there :). What's your opinion?
>
> What sort of machine(s) is this board used in? Or what machines will
> it be in?
Its a reference board from Freescale with a MPC7448 + TSI108.
Similar in concept to sandpoint.
- kumar
^ permalink raw reply
* About BDI2000 and mpc8247
From: Gosiuua @ 2006-05-18 13:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ee10e9f40605180640g12a2671bo530c3ccbba8b3829@mail.gmail.com>
Hello List..
i have a develop board based on mpc8247. It has no eeprom to restore
hareware configure word and i have to use default config word
0x00000000.
my bdi config file:
[TARGET]
CPUTYPE 8270 ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK 1 ;use 16 MHz JTAG clock
BOOTADDR 0xfff00100 ;boot address used for start-up break
WORKSPACE 0x00000000 ;workspace in target RAM for fast
download and data cache flushing
BDIMODE AGENT ;the BDI working mode (LOADONLY |
AGENT | GATEWAY)
BAUDRATE 115200 ;baudrate for gateway mode or
virtual IO
BREAKMODE SOFT ;<AGENT> SOFT or HARD, HARD uses PPC
hardware breakpoint
VECTOR CATCH ;<AGENT> catch unhandled exceptions
DCACHE NOFLUSH ;<AGENT> data cache flushing (FLUSH |
NOFLUSH)
MEMBASE 0 ;<AGENT> base of target memory
MEMSIZE 0x00004000 ;<AGENT> size of target memory, 64M
POOLBASE 0x00000000 ;<AGENT> base of host controlled target mem=
ory
POOLSIZE 0x00004000 ;<AGENT> size of host controlled
target memory
When i connect BDI2000(bdiwind_cop, firmware 1.13, logic 1.02 ) to
the board, the following messages
are printed, then it have no response!
/************************************************************/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- Target SVR is 0x00000000
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
/***/
When i set CPUTYPE to 8260, the following messages are printed continously=
:
/**************************************************************************=
****/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
*** TARGET: reset detected, restarting target
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
/*****/
BDI can't bread the CPU and i don't know what can i do!
Any one can help me?
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147930376.17679.72.camel@localhost.localdomain>
Do you have any comments about how you envision updating the "virtual"
mode image with information passed from the boot loader? I am asking
this from the standpoint of updating the "virtual" flat tree with
correct values, in order to boot from older firmware.
-Matthew
On Thu, 2006-05-18 at 15:32 +1000, Benjamin Herrenschmidt wrote:
> That is why, I think, what we should do is have rules for building
> separate zImage wrappers. The basic OF one (which exists in both real
> and virtual mode versions and that I'd like to make capable of also
> working if a flat device-tree is passed in), the zImage.sandpoint, the
> zImage.prep, and whatever...
>
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060518002142.GA23182@mag.az.mvista.com>
On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> +void *
> +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
Is there a reason you are not using of_get_flat_dt_prop() instead of
implementing your own version?
-Matthew
^ permalink raw reply
* Re: [PATCH] dtc: add setting of physical boot cpu
From: Jimi Xenidis @ 2006-05-18 13:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20060518035734.2B2CA67A6D@ozlabs.org>
Hey Michael, a few questions:
How does this interact with "linux,boot-cpu"?
If -b is defined then the absence of "linux,boot-cpu" should no
longer cause a warning.
Perhaps if -b is missing the header value is set from "linux,boot-
cpu" property?
Should we extend the "linux,boot-cpu" to actually contain a thread-id
or are we deprecating this prop?
-JX
On May 17, 2006, at 11:56 PM, Michael Neuling wrote:
> dtc always sets the physical boot CPU to 0xfeedbeef. Add a -b
> option to
> set this.
>
> ---
> I've tested the blob output but not asm output.
>
> ---
> dtc.c | 12 +++++++++---
> dtc.h | 6 ++++--
> flattree.c | 16 ++++++++++------
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> Index: dtc/dtc.c
> ===================================================================
> --- dtc.orig/dtc.c
> +++ dtc/dtc.c
> @@ -95,6 +95,8 @@ static void usage(void)
> fprintf(stderr, "\t\tBlob version to produce, defaults to 3
> (relevant for dtb\n\t\tand asm output only)\n");
> fprintf(stderr, "\t-R <number>\n");
> fprintf(stderr, "\t\tMake space for <number> reserve map entries
> (relevant for \n\t\tdtb and asm output only)\n");
> + fprintf(stderr, "\t-b <number>\n");
> + fprintf(stderr, "\t\tSet the physical boot cpu\n");
> fprintf(stderr, "\t-f\n");
> fprintf(stderr, "\t\tForce - try to produce output even if the
> input tree has errors\n");
> exit(2);
> @@ -113,8 +115,9 @@ int main(int argc, char *argv[])
> FILE *outf = NULL;
> int outversion = 3;
> int reservenum = 1;
> + int boot_cpuid_phys = 0xfeedbeef;
>
> - while ((opt = getopt(argc, argv, "I:O:o:V:R:f")) != EOF) {
> + while ((opt = getopt(argc, argv, "I:O:o:V:R:fb:")) != EOF) {
> switch (opt) {
> case 'I':
> inform = optarg;
> @@ -134,6 +137,9 @@ int main(int argc, char *argv[])
> case 'f':
> force = 1;
> break;
> + case 'b':
> + boot_cpuid_phys = strtol(optarg, NULL, 0);
> + break;
> default:
> usage();
> }
> @@ -185,9 +191,9 @@ int main(int argc, char *argv[])
> if (streq(outform, "dts")) {
> dt_to_source(outf, bi);
> } else if (streq(outform, "dtb")) {
> - dt_to_blob(outf, bi, outversion);
> + dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "asm")) {
> - dt_to_asm(outf, bi, outversion);
> + dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "null")) {
> /* do nothing */
> } else {
> Index: dtc/dtc.h
> ===================================================================
> --- dtc.orig/dtc.h
> +++ dtc/dtc.h
> @@ -207,8 +207,10 @@ struct boot_info *build_boot_info(struct
>
> /* Flattened trees */
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version);
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version);
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
>
> struct boot_info *dt_from_blob(FILE *f);
>
> Index: dtc/flattree.c
> ===================================================================
> --- dtc.orig/flattree.c
> +++ dtc/flattree.c
> @@ -301,7 +301,8 @@ static struct data flatten_reserve_list(
> }
> static void make_bph(struct boot_param_header *bph,
> struct version_info *vi,
> - int reservesize, int dtsize, int strsize)
> + int reservesize, int dtsize, int strsize,
> + int boot_cpuid_phys)
> {
> int reserve_off;
>
> @@ -324,12 +325,13 @@ static void make_bph(struct boot_param_h
> + dtsize + strsize);
>
> if (vi->flags & FTF_BOOTCPUID)
> - bph->boot_cpuid_phys = 0xfeedbeef;
> + bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
> if (vi->flags & FTF_STRTABSIZE)
> bph->size_dt_strings = cpu_to_be32(strsize);
> }
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version)
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -355,7 +357,8 @@ void dt_to_blob(FILE *f, struct boot_inf
> reservebuf = flatten_reserve_list(bi->reservelist, vi);
>
> /* Make header */
> - make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len);
> + make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len,
> + boot_cpuid_phys);
>
> fwrite(&bph, vi->hdr_size, 1, f);
>
> @@ -395,7 +398,7 @@ static void dump_stringtable_asm(FILE *f
> }
> }
>
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version)
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version, int
> boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -434,7 +437,8 @@ void dt_to_asm(FILE *f, struct boot_info
> vi->last_comp_version);
>
> if (vi->flags & FTF_BOOTCPUID)
> - fprintf(f, "\t.long\t0xdeadbeef\t/*boot_cpuid_phys*/\n");
> + fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
> + boot_cpuid_phys);
>
> if (vi->flags & FTF_STRTABSIZE)
> fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/*
> size_dt_strings */\n",
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-18 12:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1147948758.15507.52.camel@johannes>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2006-05-17 at 21:32 +0200, Andreas Schwab wrote:
>
>> I have the following sound resources in /proc/iomem:
>>
>> 80008000-800083ff : 0.00010000:i2s
>> 80008000-800083ff : Sound DMA
>> 80010000-80010fff : 0.00010000:i2s
>> 80010000-80010fff : Sound Control
>>
>> I'm not sure whether the first mapping should be split, but I don't know
>> much about how resource mappings work.
>
> That looks like you have snd-powermac loaded
Yes, that's while I had that loaded. Of course, I unloaded it before I
tried snd-aoa.
>> The layout id is 36, and it has both line out and headphone, detected as a
>> Snapper.
>
> Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
> file.
I think it's a tas3004.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* I2C bus issues on MPC8248
From: Laurent Pinchart @ 2006-05-18 12:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The mailing
list archives mention a driver for the MPC8260
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I
modified to reflect the memory map differences between the MPC8260 and the
MPC8248, as mentionned in the e-mail.
The good news is that the driver works. The bad news is that it doesn't work
correctly.
The Linux I2C layer probes the I2C bus for peripherals when drivers are
loaded. The probing function writes a single byte with the device address and
check if the data is acked. I monitored the SCL and SDA lines using an
oscilloscope, and found out that 5 bytes are written to the device (address +
4 data bytes) instead of a single one. The first 4 bytes are acked, the last
isn't. After further investigation, I found out that the cpm_iic_write()
function in drivers/i2c/busses/i2c-mpc8260.c fills two buffer descriptors,
the second one having cbd_datlen set to zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START;
tbdf[1].cbd_bufaddr = __pa(buf);
tbdf[1].cbd_datlen = count;
tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP;
Still, 5 bytes are sent on the bus. I suspected a CPM bug when cbd_datlen is
equal to zero, so I modified the first buffer descriptor to set the
BD_SC_LAST in cbd_sc when count is zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
Using that code, no data is sent on the bus, the BD_SC_READY bit is never
cleared and no interrupt is generated. Once again I suspected a CPM bug when
writing a single byte on the bus, so I increased cbd_datlen to 2:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 2;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
This worked, and two bytes were written on the bus, leading me to believe that
the CPM was at fault.
Has anyone noticed the same behaviour ? Is there a workaround available ? I
tried searching Freescale's website for CPM microcode updates but haven't
found anything related to the I2C controller.
Laurent Pinchart
^ permalink raw reply
* 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
* 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/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] 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 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: [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: 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: [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: [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: 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: 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: 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: [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: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: 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
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