* Redwood-6 and 2.6
From: Otto Solares @ 2005-08-12 3:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
Redwood-6 support in 2.6 is broken. I subscribed to this
list just to know if somebody is working on it? 2.4.30
works ok.
If nobody is working on it please just tell me what is wrong
and I would try to figure out:
---
CC arch/ppc/syslib/ppc4xx_dma.o
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_enable_burst': arch/ppc/syslib/ppc4xx_dma.c:638: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c:638: error: (Each undeclared identifier is reported only once arch/ppc/syslib/ppc4xx_dma.c:638: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_disable_burst': arch/ppc/syslib/ppc4xx_dma.c:657: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_set_burst_size': arch/ppc/syslib/ppc4xx_dma.c:682: error: `DMA_CTC_BSIZ_MSK' undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_dma.o] Error 1
make: *** [arch/ppc/syslib] Error 2
---
In 2.4 'DMA_CTC_BTEN' does not exists.
Thanks.
-otto
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-12 3:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <9C2E830E-288C-4373-BDE3-49C5FE47A01C@freescale.com>
On Thu, Aug 11, 2005 at 09:34:57PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:
>
> >On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> >[snip]
> >
> >>I think this causes confusion. the reason we suggested pq2 and
> >>classic32 was to handle things like sandpoint. Sandpoint would live
> >>in classic32. The confusion partial comes from the fact that we can
> >>run 8240/1/5 on a Sandpoint. The thinking was everything that was
> >>6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
> >>10x bridge would be classic32.
> >>
> >
> >Thanks for the explanation. But I think this is overkill for the
> >sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> >which are in the kernel tree). I think we can field the "I wanna hack
> >on my Sandpoint/8240, but don't see the code under 82xx/!"
> >question. :)
>
> So where do you suggest Sandpoint goes in this directory structure?
classic32/
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-12 2:34 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811231948.GA3187@smtp.west.cox.net>
On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:
> On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> [snip]
>
>> I think this causes confusion. the reason we suggested pq2 and
>> classic32 was to handle things like sandpoint. Sandpoint would live
>> in classic32. The confusion partial comes from the fact that we can
>> run 8240/1/5 on a Sandpoint. The thinking was everything that was
>> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
>> 10x bridge would be classic32.
>>
>
> Thanks for the explanation. But I think this is overkill for the
> sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> which are in the kernel tree). I think we can field the "I wanna hack
> on my Sandpoint/8240, but don't see the code under 82xx/!"
> question. :)
So where do you suggest Sandpoint goes in this directory structure?
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Josh Boyer @ 2005-08-12 2:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
On Thu, 2005-08-11 at 12:59 -0700, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>
> [snip]
> > platforms/
> > - platform-specific code laid out in the following
> > directories:
> > pSeries/
> > iSeries/
> > pmac/ (both 32 and 64-bit)
> > classic32/ (platforms containing
> > 6xx/7xx/74xx/8240/8241/8245)
> > classic64/ (Maple?)
>
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
> (which is a class of its own).
I myself am also pretty ppc64 ignorant, but I do know that not all
pSeries are 9xx based. There are POWER 4 and POWER 5 pSeries boxes too.
josh
^ permalink raw reply
* Update your account information
From: service @ 2005-08-11 23:54 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 8514 bytes --]
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Dan Malek @ 2005-08-11 23:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev, Tom Rini
In-Reply-To: <DE2CC80C-91A2-4860-B452-6AD171F3588A@freescale.com>
On Aug 11, 2005, at 7:07 PM, Kumar Gala wrote:
> ...... The idea being that we might be able to build kernels in
> either directory that supported a large number of boards with one
> image.
Please don't go there :-) I'm having enough trouble meeting reasonable
performance goals in 2.6 on embedded systems that I don't need the
overhead
of code bloat or extra cycles to determine what board I'm on. Contrary
to
the belief of developers, products don't have the resource wealth we see
on these evaluation and ODM boards. Embedded products still require
we build kernels (and everything else) as concisely and efficient as
possible.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 23:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <DE2CC80C-91A2-4860-B452-6AD171F3588A@freescale.com>
On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
[snip]
> I think this causes confusion. the reason we suggested pq2 and
> classic32 was to handle things like sandpoint. Sandpoint would live
> in classic32. The confusion partial comes from the fact that we can
> run 8240/1/5 on a Sandpoint. The thinking was everything that was
> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
> 10x bridge would be classic32.
Thanks for the explanation. But I think this is overkill for the
sandpoint or true like a sandpoint (Zynx something, Willow, neither of
which are in the kernel tree). I think we can field the "I wanna hack
on my Sandpoint/8240, but don't see the code under 82xx/!" question. :)
> If it was 82xx w/o a CPM it went into classic32. If it was a 82xx w/
> CPM it went into pq2. The idea being that we might be able to build
> kernels in either directory that supported a large number of boards
> with one image.
We can certainly investigate just how many distinct boards can be
supported with one image when infos are passed dynamically. If we can
simplify things enough, maybe we can break the rule of no .[ch] files in
arch/powerpc/platforms since it'll just be 82xx.[ch], 83xx.[ch] and so
on, execept for that damn pmac. ;)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Eugene Surovegin @ 2005-08-11 23:17 UTC (permalink / raw)
To: Shawn Jin, ppcembed
In-Reply-To: <20050811231454.GA5796@gate.ebshome.net>
On Thu, Aug 11, 2005 at 04:14:54PM -0700, Eugene Surovegin wrote:
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> > ??????
>
> Try disabling early text debugging (all that "MMU:..." stuff).
>
Also, make sure you pass correct "console=..." line to the kernel
(with correct device name and baud rate).
--
Eugene
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Eugene Surovegin @ 2005-08-11 23:14 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050811154148164691@mail.gmail.com>
On Thu, Aug 11, 2005 at 03:41:21PM -0700, Shawn Jin wrote:
> Hi,
>
> I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
> is 16550 compatible. U-Boot is already running fine.
>
> When the kernel is booting, it gets to the point where console_init()
> is called, which calls individual early console initialization
> functions. In my case it's serial8250_console_init(). Before
> register_console() is called in serial8250_console_init(), everything
> seems fine because the debugging logs are printed on the serial port.
> But once register_console() is called, the serial port continues
> spitting out ?. See the following message. What's wrong?
>
> Any hints are appreciated!
>
> Boot reached stage 4
> Boot reached stage 5
> Boot reached stage 6
> OK
> Boot reached stage 7
> Boot reached stage 8
> ## Current stack ends at 0x01FC6B80 => set upper limit to 0x00800000
> ## cmdline at 0x007FFF00 ... 0x007FFF10
> bd address = 0x01FC6F90
> memstart = 0x00000000
> memsize = 0x02000000
> flashstart = 0x00000000
> flashsize = 0x00000000
> flashoffset = 0x00000000
> sramstart = 0x00000000
> sramsize = 0x00000000
> bootflags = 0x00000000
> intfreq = 400 MHz
> busfreq = 266 MHz
> ethaddr = 00:00:00:00:00:00
> IP addr = 0.0.0.0
> baudrate = 115200 bps
> Boot reached stage 14
> No initrd
> ## Transferring control to Linux (at address 00000000) ...
> Boot reached stage 15
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> arch: exit
> ??????
Try disabling early text debugging (all that "MMU:..." stuff).
--
Eugene
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-11 23:07 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811201821.GY3187@smtp.west.cox.net>
On Aug 11, 2005, at 3:18 PM, Tom Rini wrote:
> On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
>
>>
>> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
>>
>>
>>> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>>>
>>> [snip]
>>>
> [snip]
>
>>>> 83xx/ (may collapse into classic 32 at some point)
>>>> 86xx/ (may collapse into classic 32 at some point)
>>>> pq2/ (may collapse into classic 32 at some point)
>>>>
>>>>
>>>
>>> PQ2 is the marketing name for 82xx, lets just call it 82xx.
>>>
>>
>> The problem is that PQ2 describes a subset of 82xx (it nots
>> 8240/8241/8245).
>>
>
> All the more reason imho to stick all 82xx stuff under '82xx', rather
> than classic32 or 'pq2'.
I think this causes confusion. the reason we suggested pq2 and
classic32 was to handle things like sandpoint. Sandpoint would live
in classic32. The confusion partial comes from the fact that we can
run 8240/1/5 on a Sandpoint. The thinking was everything that was
6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
10x bridge would be classic32.
If it was 82xx w/o a CPM it went into classic32. If it was a 82xx w/
CPM it went into pq2. The idea being that we might be able to build
kernels in either directory that supported a large number of boards
with one image.
Anyways, that was the thought process to try and keep things sane.
(Which it may not ;)
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Becky Bruce @ 2005-08-11 22:41 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050811201821.GY3187@smtp.west.cox.net>
>
>>> I don't like the idea of sticking subdirs in classic32/ either, but
>>> also
>>> can't think of a better name for the catchall of 7xx and 74xx boards.
>>
>> I dont think we where planning on subdirs in classic32.
>
> I took "may collapse into classic 32 at some point" to mean "move into
> classic32/ at some point", for some reason. collapsing the content
> into
> classic32/ will bring us back to the bad-old-days of everything in
> platforms/ (or kernel/).
My apologies - this wasn't at all clear in the proposal. The plan at
present is to not have subdirs under classic32. By "collapsing into
classic32", I meant a move to a more common code base, not a wholescale
copy of the existing files into classic32.
Cheers,
-B
^ permalink raw reply
* What's wrong with the serial port?
From: Shawn Jin @ 2005-08-11 22:41 UTC (permalink / raw)
To: ppcembed
Hi,
I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
is 16550 compatible. U-Boot is already running fine.
When the kernel is booting, it gets to the point where console_init()
is called, which calls individual early console initialization
functions. In my case it's serial8250_console_init(). Before
register_console() is called in serial8250_console_init(), everything
seems fine because the debugging logs are printed on the serial port.
But once register_console() is called, the serial port continues
spitting out =E0. See the following message. What's wrong?
Any hints are appreciated!
Boot reached stage 4 =
=20
Boot reached stage 5 =
=20
Boot reached stage 6 =
=20
OK =
=20
Boot reached stage 7 =
=20
Boot reached stage 8 =
=20
## Current stack ends at 0x01FC6B80 =3D> set upper limit to 0x00800000 =
=20
## cmdline at 0x007FFF00 ... 0x007FFF10 =
=20
bd address =3D 0x01FC6F90 =
=20
memstart =3D 0x00000000 =
=20
memsize =3D 0x02000000 =
=20
flashstart =3D 0x00000000 =
=20
flashsize =3D 0x00000000 =
=20
flashoffset =3D 0x00000000 =
=20
sramstart =3D 0x00000000 =
=20
sramsize =3D 0x00000000 =
=20
bootflags =3D 0x00000000 =
=20
intfreq =3D 400 MHz =
=20
busfreq =3D 266 MHz =
=20
ethaddr =3D 00:00:00:00:00:00 =
=20
IP addr =3D 0.0.0.0 =
=20
baudrate =3D 115200 bps =
=20
Boot reached stage 14 =
=20
No initrd =
=20
## Transferring control to Linux (at address 00000000) ... =
=20
Boot reached stage 15 =
=20
id mach(): done =
=20
MMU:enter =
=20
MMU:hw init =
=20
MMU:mapin =
=20
MMU:setio =
=20
MMU:exit =
=20
setup_arch: enter =
=20
setup_arch: bootmem =
=20
arch: exit =
=20
=E0=E0=E0=E0=E0=E0 =20
-Shawn.
^ permalink raw reply
* Re: 8260 fcc_enet driver newbie question
From: Dan Malek @ 2005-08-11 21:00 UTC (permalink / raw)
To: vijaykumar; +Cc: dmalek, linuxppc-embedded
In-Reply-To: <1123739278.19079.13.camel@localhost.localdomain>
On Aug 11, 2005, at 1:47 AM, Vijay Kumar wrote:
> I was going through the fcc_enet driver
> (linux-2.6.12.2/arch/ppc/8260_io/fcc_enet.c).
This has been replaced by the new net/fs_enet, right?
> The driver accesses the CPM memory map using
> immap = (cpm2_map_t *)CPM_MAP_ADDR;
Yes, and that's wrong. You should at least use
ioremap(), and we recently had discussions about
whether to create some properly named functions
or macros to return common addresses like the
CPM space.
> There is also a global variable cpm2_immr defined in
> arch/ppc/syslib/cpm2_common.c
I know, but we shouldn't be doing that any longer.
> If I were to write a new driver which one should I use
> to access the CPM memory map?
For now, at least ioremap() the space in your driver
and cache the pointer. I'd like to quickly get a couple of
these other supporting functions done to use, though.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] add field to struct ocp_func_emac_data for platform-specific unsupported PHY features
From: Wade Farnsworth @ 2005-08-11 20:42 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050808164457.C9951@cox.net>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Mon, 2005-08-08 at 16:44, Matt Porter wrote:
(snip)
>
> Could you update this field (and related usages) to be "phy_ftr_exc"?
> For "Excluded phy features". Eugene and I discussed this on IRC and
> think it's a better name...for one it starts with the phy_ prefix like
> other related phy data. Except for that, it's ready for upstream.
>
> Thanks,
> Matt
Here is the updated patch with the field renamed to "phy_ftr_exc"
instead of "feat_unsupp".
-Wade Farnsworth
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: ibm-emac-phy-feat-exc-ppc.patch --]
[-- Type: text/x-patch, Size: 3264 bytes --]
diff -upr linux-2.6/arch/ppc/platforms/4xx/bamboo.c linux-2.6-dev/arch/ppc/platforms/4xx/bamboo.c
--- linux-2.6/arch/ppc/platforms/4xx/bamboo.c 2005-08-11 13:29:30.000000000 -0700
+++ linux-2.6-dev/arch/ppc/platforms/4xx/bamboo.c 2005-08-11 13:15:59.000000000 -0700
@@ -123,33 +123,69 @@ bamboo_map_irq(struct pci_dev *dev, unsi
static void __init bamboo_set_emacdata(void)
{
- unsigned char * selection1_base;
+ u8 * base_addr;
struct ocp_def *def;
struct ocp_func_emac_data *emacdata;
- u8 selection1_val;
+ u8 val;
int mode;
+ u32 excluded = 0;
- selection1_base = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
- selection1_val = readb(selection1_base);
- iounmap((void *) selection1_base);
- if (BAMBOO_SEL_MII(selection1_val))
+ base_addr = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (BAMBOO_SEL_MII(val))
mode = PHY_MODE_MII;
- else if (BAMBOO_SEL_RMII(selection1_val))
+ else if (BAMBOO_SEL_RMII(val))
mode = PHY_MODE_RMII;
else
mode = PHY_MODE_SMII;
- /* Set mac_addr and phy mode for each EMAC */
+ /*
+ * SW2 on the Bamboo is used for ethernet configuration and is accessed
+ * via the CONFIG2 register in the FPGA. If the ANEG pin is set,
+ * overwrite the supported features with the settings in SW2.
+ *
+ * This is used as a workaround for the improperly biased RJ-45 sockets
+ * on the Rev. 0 Bamboo. By default only 10baseT is functional.
+ * Removing inductors L17 and L18 from the board allows 100baseT, but
+ * disables 10baseT. The Rev. 1 has no such limitations.
+ */
+
+ base_addr = ioremap64(BAMBOO_FPGA_CONFIG2_REG_ADDR, 8);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (!BAMBOO_AUTONEGOTIATE(val)) {
+ excluded |= SUPPORTED_Autoneg;
+ if (BAMBOO_FORCE_100Mbps(val)) {
+ excluded |= SUPPORTED_10baseT_Full;
+ excluded |= SUPPORTED_10baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ excluded |= SUPPORTED_100baseT_Half;
+ else
+ excluded |= SUPPORTED_100baseT_Full;
+ } else {
+ excluded |= SUPPORTED_100baseT_Full;
+ excluded |= SUPPORTED_100baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ excluded |= SUPPORTED_10baseT_Half;
+ else
+ excluded |= SUPPORTED_10baseT_Full;
+ }
+ }
+
+ /* Set mac_addr, phy mode and unsupported phy features for each EMAC */
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
emacdata->phy_mode = mode;
+ emacdata->phy_feat_exc = excluded;
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
emacdata->phy_mode = mode;
+ emacdata->phy_feat_exc = excluded;
}
static int
diff -upr linux-2.6/include/asm-ppc/ibm_ocp.h linux-2.6-dev/include/asm-ppc/ibm_ocp.h
--- linux-2.6/include/asm-ppc/ibm_ocp.h 2005-08-11 13:30:02.000000000 -0700
+++ linux-2.6-dev/include/asm-ppc/ibm_ocp.h 2005-08-11 13:12:34.000000000 -0700
@@ -67,6 +67,7 @@ struct ocp_func_emac_data {
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6]; /* EMAC mac address */
u32 phy_map; /* EMAC phy map */
+ u32 phy_feat_exc; /* Excluded PHY features */
};
/* Sysfs support */
^ permalink raw reply
* 8260 fcc_enet driver newbie question
From: Vijay Kumar @ 2005-08-11 5:47 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: dmalek
I was going through the fcc_enet driver
(linux-2.6.12.2/arch/ppc/8260_io/fcc_enet.c).
The driver accesses the CPM memory map using
immap = (cpm2_map_t *)CPM_MAP_ADDR;
There is also a global variable cpm2_immr defined in
arch/ppc/syslib/cpm2_common.c
If I were to write a new driver which one should I use
to access the CPM memory map?
Vijay
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Olaf Hering @ 2005-08-11 20:25 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Wed, Aug 10, Becky Bruce wrote:
> boot/
> - Pre-kernel execution shims and pre-passes.
> - Convert firmware reprensentations (bi_recs, OF Dev-Trees,
> bootx,bd_t) to flat-dev-trees.
> - Includes merged files from arch/ppc*/boot/ trees, plus
> prom_init.c from arch/ppc64/kernel.
This should live outside the kernel source, in a $mkzimage project.
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 20:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <BF36E655-9534-4FCD-9EB3-A1CD36C7981D@freescale.com>
On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
>
> >On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
> >
> >[snip]
[snip]
> >> 83xx/ (may collapse into classic 32 at some point)
> >> 86xx/ (may collapse into classic 32 at some point)
> >> pq2/ (may collapse into classic 32 at some point)
> >>
> >
> >PQ2 is the marketing name for 82xx, lets just call it 82xx.
>
> The problem is that PQ2 describes a subset of 82xx (it nots
> 8240/8241/8245).
All the more reason imho to stick all 82xx stuff under '82xx', rather
than classic32 or 'pq2'.
> >I don't like the idea of sticking subdirs in classic32/ either, but
> >also
> >can't think of a better name for the catchall of 7xx and 74xx boards.
>
> I dont think we where planning on subdirs in classic32.
I took "may collapse into classic 32 at some point" to mean "move into
classic32/ at some point", for some reason. collapsing the content into
classic32/ will bring us back to the bad-old-days of everything in
platforms/ (or kernel/).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-11 20:13 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>
> [snip]
>
>> platforms/
>> - platform-specific code laid out in the following
>> directories:
>> pSeries/
>> iSeries/
>> pmac/ (both 32 and 64-bit)
>> classic32/ (platforms containing
>> 6xx/7xx/74xx/8240/8241/8245)
>> classic64/ (Maple?)
>>
>
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't
> pmac
> (which is a class of its own).
>
>
>> 83xx/ (may collapse into classic 32 at some point)
>> 86xx/ (may collapse into classic 32 at some point)
>> pq2/ (may collapse into classic 32 at some point)
>>
>
> PQ2 is the marketing name for 82xx, lets just call it 82xx.
The problem is that PQ2 describes a subset of 82xx (it nots
8240/8241/8245).
> I don't like the idea of sticking subdirs in classic32/ either, but
> also
> can't think of a better name for the catchall of 7xx and 74xx boards.
I dont think we where planning on subdirs in classic32.
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 19:59 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
[snip]
> platforms/
> - platform-specific code laid out in the following
> directories:
> pSeries/
> iSeries/
> pmac/ (both 32 and 64-bit)
> classic32/ (platforms containing
> 6xx/7xx/74xx/8240/8241/8245)
> classic64/ (Maple?)
I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
(which is a class of its own).
> 83xx/ (may collapse into classic 32 at some point)
> 86xx/ (may collapse into classic 32 at some point)
> pq2/ (may collapse into classic 32 at some point)
PQ2 is the marketing name for 82xx, lets just call it 82xx.
I don't like the idea of sticking subdirs in classic32/ either, but also
can't think of a better name for the catchall of 7xx and 74xx boards.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Tom Rini @ 2005-08-11 19:43 UTC (permalink / raw)
To: Matt Porter, Leigh Brown; +Cc: linuxppc-dev
In-Reply-To: <20050810093735.B22586@cox.net>
On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
> This restores behavior from 2.4 where PReP platforms identified
> as Motorola would calibrate the decrementer using the RTC. On
> real Motorola PReP hardware this isn't needed. However, in order
> to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> PReP system) it is necessary to allow it to calibrate the decrementer
> using an emulated RTC. If the decrementer rate is read from
> residual data then timing is screwed since a qemu PReP system typically
> runs much faster than the original hardware.
>
> If anybody has objections to this as the default, let me know. It
> still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> affect the IBM PReP paths. My goal with this is to be able to run
> a stock 2.6 defconfig PReP build on qemu.
So, I like this, and not just because I'm playing with qemu as well.
Leigh, can you run this on any 'interesting' PReP you've got that might
tickle a bug here? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-11 18:48 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050810103750.253a2b74.kim.phillips@freescale.com>
Hi Kim,
While browsing the SIU came across TESCR1(0x10040) & TESTCR2(0x10044). I
dumped it during module_init (00000000::00000000) and also in the ISR
after RNG was submitted to SEC core, this time I got
(0x814a0000::00000000).
TESCR1 after RNG descriptor submitted and SEC-ISR invoked=0x814a0000
bit 0 set -- 60x bus monitor timeout
bit 7-9= 101 --- SEC transaction
bit 11-15=01010 -- TT -- Single-beat-read or burst.
Now looking more into SIU -- SIU-BCR(bus Configuration register=0x10024)
has EBM bit , i set that. Did'nt make any difference. :(
I want to ask -- To make SEC 1.0 as master do i have to do several other
modifications to the SIU configurations so that 60x bus mode is enabled
for internal master. Like PPC_ACR(0x10028) has 4-7 bits as PRKM-parking
master and PPC_ACR=0100 stands for SEC engine.
-vikas
> On Tue, 9 Aug 2005 16:52:04 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> The address returned by kmalloc=0x009ffc5c is 4 byte aligned.
>> Are u advicing that dma_map_single() should return 8 byte aligned ,
>> becuase thats what gets written into the Data-Paclet_descriptor later.
>>
> I wouldn't worry about alignment as much as the register write trace and
> checking the System Interface Unit and individual eu status registers.
>
> --
> Kim
>
^ permalink raw reply
* 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Tjernlund @ 2005-08-11 17:50 UTC (permalink / raw)
To: linuxppc-embedded
Try changing all
i2c->i2c_i2com |= 0x80; /* Begin transmission */
to
i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
That should remove the need to do force_reinit(cpm) I hope.
See http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019600.html for a litte more info.
Also, I think you should remove the busy wait code. Its not needed IMHO.
Jocke
^ permalink raw reply
* FW: CLOCK_TICK_RATE
From: Rune Torgersen @ 2005-08-11 16:19 UTC (permalink / raw)
To: linuxppc-dev
CLOCK_TICK_RATE is the basis for TIME_NSEC which is used to update xtime
on every timer interrupt, so it is very relevant for PPC.
CLOCK_TICK_RATE is used for LATCH which is used for ACTHZ which in turn
is used for TIME_NSEC
=20
> -----Original Message-----
> From: Andreas Schwab [mailto:schwab@suse.de]=20
> Sent: Thursday, August 11, 2005 11:15
> To: Rune Torgersen
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: CLOCK_TICK_RATE
>=20
> "Rune Torgersen" <runet@innovsys.com> writes:
>=20
> > Hi
> >
> > I have found that I need to set CLOCK_TICK_RATE (currently=20
> defined in
> > include/asm-ppc/timex.h) to something else.
>=20
> I can't find any use of CLOCK_TICK_RATE in the kernel that is=20
> relevant for
> ppc.
>From a previous thread in linux-ppc-embedded (Wall clock accuracy)
> -----Original Message-----
> From: George Anzinger [mailto:george@mvista.com]=20
> Sent: Tuesday, August 09, 2005 19:07
>
> The problem here is that the CLOCK_TICK_RATE is not correctly=20
> defined.=20
> This should be the rate at which the decrementer is clocked in hertz.=20
> If this is properly defined the tick_nsec value will be what=20
> works to to=20
> be an integral number of these that gives an nsec value less than or=20
> equal to what LATCH says you should be using for the number of=20
> decrementer counts in a jiffie. It is important that this be=20
> correctly=20
> defined so that a) LATCH is right and b) the jiffies to/from=20
> conversions=20
> are done right. These conversions rely on TICK_NSEC to get the right=20
> answer. (Also, so you don't step into a computing mess, it=20
> is important=20
> that these be defined at compile time so the compiler can do=20
> the heavy=20
> lifting. If defined as variables the conversions will take a=20
> LOT longer=20
> (and use more code to boot).)
>=20
> If you are getting 999848, it would appear that you are using the x86=20
> value which, I assume, is NOT right for a PPC, but then the=20
> PPC is NOT=20
> my strong suit...
>
^ permalink raw reply
* [PATCH] MPC52xxx I2C: make algo use of I2C_RSTA
From: Bertrand BAUDET @ 2005-08-11 18:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
This patch makes use of I2C RESTART sequence when sending severals i2c_msg
instead of the STOP and START sequence.
Some I2C component reset there internal values when a STOP is sent.
(like the Ricoh rs5c372b I2C RTC)
Patch is against DENX linuxppc CVS
Regards,
Bertrand
[-- Attachment #2: mpc52xx_i2c-algo.patch --]
[-- Type: text/x-diff, Size: 1421 bytes --]
--- linuxppc_2_4_devel_new/drivers/i2c/i2c-algo-mpc5xxx.c 2004-05-08 18:49:39.000000000 +0200
+++ linuxppc_2_4_devel-lacie6/drivers/i2c/i2c-algo-mpc5xxx.c 2004-12-13 15:53:37.000000000 +0100
@@ -62,6 +62,14 @@
return;
}
+static void i2c_restart(struct i2c_algo_mpc5xxx_data *algo_data)
+{
+ struct mpc5xxx_i2c *regs = algo_data->regs;
+
+ mpc5xxx_out(®s->mcr, MPC5xxx_I2C_RSTA, MPC5xxx_I2C_RSTA);
+
+ return;
+}
static void i2c_stop(struct i2c_algo_mpc5xxx_data *algo_data)
{
@@ -311,13 +319,14 @@
int status;
int i;
+ if (wait_for_bb(algo_data))
+ return -EREMOTEIO;
+
+ i2c_start(algo_data);
+
for (i = 0; i < num; i++) {
pmsg = &msgs[i];
- if (wait_for_bb(algo_data))
- return -EREMOTEIO;
-
- i2c_start(algo_data);
mpc5xxx_do_address(algo_data, pmsg, adap->retries);
if (wait_for_pin(algo_data, &status)) {
@@ -332,17 +341,21 @@
if (pmsg->flags & I2C_M_RD) {
ret = mpc5xxx_readbytes(adap, pmsg->buf, pmsg->len);
- if (ret != pmsg->len)
+ if (ret != pmsg->len) {
+ i2c_stop(algo_data);
return (ret < 0) ? ret : -EREMOTEIO;
+ }
} else {
ret = mpc5xxx_sendbytes(adap, pmsg->buf, pmsg->len);
- if (ret != pmsg->len)
+ if (ret != pmsg->len) {
+ i2c_stop(algo_data);
return (ret < 0) ? ret : -EREMOTEIO;
+ }
}
-
- i2c_stop(algo_data);
+ if (i+1 < num) i2c_restart(algo_data);
}
-
+
+ i2c_stop(algo_data);
return num;
}
^ permalink raw reply
* Re: CLOCK_TICK_RATE
From: Andreas Schwab @ 2005-08-11 16:14 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859421@ismail.innsys.innovsys.com>
"Rune Torgersen" <runet@innovsys.com> writes:
> Hi
>
> I have found that I need to set CLOCK_TICK_RATE (currently defined in
> include/asm-ppc/timex.h) to something else.
I can't find any use of CLOCK_TICK_RATE in the kernel that is relevant for
ppc.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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