* [PATCH] Offer PCI as a CONFIG choice for PPC_86xx.
From: Jon Loeliger @ 2006-08-09 15:37 UTC (permalink / raw)
To: linuxppc-dev
Also fix 80-column run-over.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
I misspoke myself on the earlier, ill-formed version of this patch. :-)
arch/powerpc/Kconfig | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..abb325e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -836,9 +836,10 @@ config MCA
bool
config PCI
- bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) \
- || MPC7448HPC2
- default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !PPC_85xx && !PPC_86xx
+ bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
+ || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) || MPC7448HPC2
+ default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx \
+ && !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && APUS
default PCI_QSPAN if !4xx && !CPM2 && 8xx
help
^ permalink raw reply related
* Re: SystemAce Driver.
From: sudheer @ 2006-08-09 15:06 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <44C4BE5B.3000002@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]
Hello Ameet Patil
I am looking for linux kernel source 2.6.16 with system ace controller
support. I downloaded the linux-2.6.16 and linux-2.6.17-1 source from
kernel.org but could not find any files related to system ace
controller ( No xilinx_sysace directory in drivers/block/) . I have
checked penguinppc.org also but could not get it.
Can you please send to me the link where i could download the
linuxppc-2.6.16 source with system ace support.
Thanks & Regards
Sudheer
Ameet Patil wrote:
> Hi Raja,
> I have ported the Xilinx System ACE driver to 2.6 kernel. Find the
> latest one here:
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
> which case use the -after-TEMAC patch found in the patches folder above.
>
> Check the following discussions (threads) for more details:
> 1. "Xilinx SystemACE driver for 2.6"
> 2. "Xilinx BSP for linux 2.6"
> 3. "Kernel hangs after "Now booting the kernel"."
>
> cheers,
> -Ameet
>
> Raja Chidambaram wrote:
>
>> Hi all,
>> We are working on customized board with amcc 440SPe
>> processor & xilinx System Ace controller. The System
>> Ace controller is connected to compact flash driver.
>>
>> We use u-boot 1.2 as bootloader & linux kernel
>> 2.6.16-2.
>>
>> On the process the u-boot is able to detect compact
>> flash through Xilinx SystemAce controller & able to
>> load the kernel image into compact flash.But when the
>> linux boot's up it not able to detect the System Ace
>> controller or compact flash.
>>
>> Note:we need to have the root file system in compact
>> flash.
>>
>> Is their any drivers available for SystemAce
>> controller on linux 2.6,if their how to get it.please
>> help me in this
>> with regards
>> raja
>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 3351 bytes --]
^ permalink raw reply
* RE: Who cares about PReP?
From: Matt Sealey @ 2006-08-09 15:00 UTC (permalink / raw)
To: 'Paul Mackerras', linuxppc-dev
In-Reply-To: <17622.58559.879330.496619@cargo.ozlabs.ibm.com>
QEMU PPC implements a PReP system too.
Probably a good place to test without needing a real system.
However it's the kind of thing you'd want to throw a CHRP
ROM onto in the end, and forget PReP for emulation (after
all, nobody makes 'em anymore).
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
> -----Original Message-----
> From: linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org]
> On Behalf Of Paul Mackerras
> Sent: Monday, August 07, 2006 8:59 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Who cares about PReP?
>
> I started looking at moving the PReP code over to
> arch/powerpc. I am struck by how many ifdefs there are in
> there to set things up for particular individual PReP
> implementations. We can do better than that, I'm sure, but
> the issue becomes one of testing. The only PReP I have here
> is an RS/6000 43p-140.
>
> Who else has a PReP system and would be willing to do some
> testing and debugging? If so, what sort of PReP is it?
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Wolfgang Denk @ 2006-08-09 14:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155122309.4040.94.camel@localhost.localdomain>
In message <1155122309.4040.94.camel@localhost.localdomain> you wrote:
>
> > Where should we place the sources for the OF Flat Device
> > Tree source files? They used to be in U-Boot, but that
> > isn't happening any more.
>
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...
Ben, you are mixing two things here.
I have nothing against U-Boot passing the DT to the kernel. On
contrary, if DT's are used, than I think this is how it should be
done.
It's just that I think that the DT *sources* should not be part of
the U-Boot soutrce tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.
This has been discussed before (see archives), and the agreement (?)
was to use U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image into one file
bootable by U-Boot.
Jon's question was where the source code of the DT should be placed.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* Re: .tc entries question
From: Alan Modra @ 2006-08-09 13:55 UTC (permalink / raw)
To: Jonathan Bartlett; +Cc: linuxppc-dev
In-Reply-To: <Pine.SUN.4.58.0608090611460.14141@eskimo.com>
On Wed, Aug 09, 2006 at 06:15:06AM -0700, Jonathan Bartlett wrote:
> Another 64-bit Elf question, this one about the TOC. In many examples,
> for defining toc entries, there is some syntax like this:
>
> name_to_refer_to_this:
> .tc seemingly_unused_name[TC], data_here
>
> I haven't figured out what the purpose of the name immediately preceding
> [TC] is. In fact, it seems that in most cases it can simply be left out.
> Is this just a holdover from a previous binary format, or does
> "seemingly_unused_name" actually get used in some fashion?
It is just a syntax we inherited from PowerPC64 XCOFF.
seemingly_unused_name and the bracketed class qualifier are completely
ingored.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Arnd Bergmann @ 2006-08-09 13:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, netdev, linux-kernel, Christoph Raisch, Marcus Eder
In-Reply-To: <44D99F56.7010201@de.ibm.com>
On Wednesday 09 August 2006 10:39, Jan-Bernd Themann wrote:
> +extern int ehea_trace_level;
> +
> +#ifdef EHEA_NO_EDEB
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> +=A0=A0=A0=A0=A0=A0=A0while (0 =3D=3D 1) { \
> +=A0=A0=A0=A0=A0=A0=A0 =A0 =A0if(unlikely (level <=3D ehea_trace_level)) =
{ \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
ntk("%s " idstring " "format "\n", \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0__func__, ##args); \
> +=A0=A0=A0=A0=A0=A0=A0 =A0} \
> +=A0=A0=A0=A0=A0=A0=A0} \
> +
> +#else
> +
> +#define EDEB_P_GENERIC(level,idstring,format,args...) \
> +if (level < KEEP_EDEBS_BELOW) { \
> +=A0=A0=A0=A0=A0=A0=A0do { \
> +=A0=A0=A0=A0=A0=A0=A0 =A0 =A0if(unlikely (level <=3D ehea_trace_level)) =
{ \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
ntk("%s " idstring " "format "\n", \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0__func__, ##args); \
> +=A0=A0=A0=A0=A0=A0=A0 =A0} \
> +=A0=A0=A0=A0=A0=A0=A0} while (1 =3D=3D 0); \
> +}
> +#endif
> +
> +#define EDEB(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "", format, ##args)
> +
> +#define EDEB_ERR(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "EHEA_ERROR", format, ##args)
> +
> +#define EDEB_EN(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, ">>>", format, ##args)
> +
> +#define EDEB_EX(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "<<<", format, ##args)
Please don't invent your own debugging macros. You can either use the
pr_debug/pr_info facility from <linux/kernel.h> or get rid of those
completely. The latter is probably preferred for most of your calls.
Arnd <><
^ permalink raw reply
* .tc entries question
From: Jonathan Bartlett @ 2006-08-09 13:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060725140634.GH6872@bubble.grove.modra.org>
Another 64-bit Elf question, this one about the TOC. In many examples,
for defining toc entries, there is some syntax like this:
name_to_refer_to_this:
.tc seemingly_unused_name[TC], data_here
I haven't figured out what the purpose of the name immediately preceding
[TC] is. In fact, it seems that in most cases it can simply be left out.
Is this just a holdover from a previous binary format, or does
"seemingly_unused_name" actually get used in some fashion?
Thanks,
Jon
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Arnd Bergmann @ 2006-08-09 13:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, netdev, linux-kernel, Christoph Raisch, Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
On Wednesday 09 August 2006 10:38, Jan-Bernd Themann wrote:
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_hcall.h=A01969-12-31 16:0=
0:00.000000000 -0800
> +++ kernel/drivers/net/ehea/ehea_hcall.h=A0=A0=A0=A0=A0=A0=A0=A02006-08-0=
8 23:59:38.111462960 -0700
> @@ -0,0 +1,52 @@
> +
> +/**
> + * This file contains HCALL defines that are to be included in the appro=
priate
> + * kernel files later
> + */
> +
> +#define H_ALLOC_HEA_RESOURCE =A0 0x278
> +#define H_MODIFY_HEA_QP =A0 =A0 =A0 =A00x250
> +#define H_QUERY_HEA_QP =A0 =A0 =A0 =A0 0x254
> +#define H_QUERY_HEA =A0 =A0 =A0 =A0 =A0 =A00x258
> +#define H_QUERY_HEA_PORT =A0 =A0 =A0 0x25C
> +#define H_MODIFY_HEA_PORT =A0 =A0 =A00x260
> +#define H_REG_BCMC =A0 =A0 =A0 =A0 =A0 =A0 0x264
> +#define H_DEREG_BCMC =A0 =A0 =A0 =A0 =A0 0x268
> +#define H_REGISTER_HEA_RPAGES =A00x26C
> +#define H_DISABLE_AND_GET_HEA =A00x270
> +#define H_GET_HEA_INFO =A0 =A0 =A0 =A0 0x274
> +#define H_ADD_CONN =A0 =A0 =A0 =A0 =A0 =A0 0x284
> +#define H_DEL_CONN =A0 =A0 =A0 =A0 =A0 =A0 0x288
I guess these should go to include/asm-powerpc/hvcall.h instead.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Alexey Dobriyan @ 2006-08-09 13:06 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linuxppc-dev,
Christoph Raisch, Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
On Wed, Aug 09, 2006 at 10:38:20AM +0200, Jan-Bernd Themann wrote:
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c
> +++ kernel/drivers/net/ehea/ehea_main.c
> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
> +{
> + u64 addr;
> + addr = tmp_addr;
> + return addr;
> +}
> +
> +static inline u64 get_rwqe_addr(u64 tmp_addr)
> +{
> + return tmp_addr;
> +}
The point of this exercise?
> +static inline int ehea_refill_rq3_def(struct ehea_port_res *pr, int nr_of_wqes)
Way too big to be inline function.
> +{
> + int i;
> + int ret = 0;
> + struct ehea_qp *qp;
> + struct ehea_rwqe *rwqe;
> + int skb_arr_rq3_len = pr->skb_arr_rq3_len;
> + struct sk_buff **skb_arr_rq3 = pr->skb_arr_rq3;
> + EDEB_EN(8, "pr=%p, nr_of_wqes=%d", pr, nr_of_wqes);
> + if (nr_of_wqes == 0)
> + return -EINVAL;
> + qp = pr->qp;
> + for (i = 0; i < nr_of_wqes; i++) {
> + int index = pr->skb_rq3_index++;
> + struct sk_buff *skb = dev_alloc_skb(EHEA_MAX_PACKET_SIZE
> + + NET_IP_ALIGN);
> +
> + if (!skb) {
> + EDEB_ERR(4, "No memory for skb. Only %d rwqe
> filled.",
> + i);
> + ret = -ENOMEM;
> + break;
> + }
> + skb_reserve(skb, NET_IP_ALIGN);
> +
> + rwqe = ehea_get_next_rwqe(qp, 3);
> + pr->skb_rq3_index %= skb_arr_rq3_len;
> + skb_arr_rq3[index] = skb;
> + rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE,
> EHEA_RWQE3_TYPE)
> + | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
> + rwqe->sg_list[0].l_key = ehea_get_recv_lkey(pr);
> + rwqe->sg_list[0].vaddr = get_rwqe_addr((u64)skb->data);
> + rwqe->sg_list[0].len = EHEA_MAX_PACKET_SIZE;
> + rwqe->data_segments = 1;
> + }
> +
> + /* Ring doorbell */
> + iosync();
> + ehea_update_rq3a(qp, i);
> + EDEB_EX(8, "");
> + return ret;
> +}
> +
> +
> +static inline int ehea_refill_rq3(struct ehea_port_res *pr, int nr_of_wqes)
> +{
> + return ehea_refill_rq3_def(pr, nr_of_wqes);
> +}
ehea_refill_rq3[123] appears to be 1:1 wrappers around
ehea_refill_rq3[123]_def. Any idea behind them?
> + init_attr = (struct ehea_qp_init_attr*)
> + kzalloc(sizeof(struct ehea_qp_init_attr), GFP_KERNEL);
Useless cast.
> + pr->skb_arr_sq = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
Useless cast
> + pr->skb_arr_rq1 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> + pr->skb_arr_rq2 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> + pr->skb_arr_rq3 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> +static int ehea_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> + EDEB_ERR(4, "ioctl not supported: dev=%s cmd=%d", dev->name, cmd);
Then copy NULL into ->do_ioctl!
> + return -EOPNOTSUPP;
> +}
> + ehea_port_cb_0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
> +
> + if (!ehea_port_cb_0) {
> + EDEB_ERR(4, "No memory for ehea_port control block");
> + ret = -ENOMEM;
> + goto kzalloc_failed;
> + }
> +
> + memcpy((u8*)(&(ehea_port_cb_0->port_mac_addr)),
> + (u8*)&(mac_addr->sa_data[0]), 6);
No casts on memcpy arguments.
> + memcpy((u8*)&ehea_mcl_entry->macaddr, mc_mac_addr, ETH_ALEN);
> +static inline void ehea_xmit2(struct sk_buff *skb,
> + struct net_device *dev, struct ehea_swqe *swqe,
> + u32 lkey)
> +{
> + int nfrags;
> + unsigned short skb_protocol = skb->protocol;
Useless variable. And it should be __be16, FYI.
> + nfrags = skb_shinfo(skb)->nr_frags;
> + EDEB_EN(7, "skb->nfrags=%d (0x%X)", nfrags, nfrags);
> +
> + if (skb_protocol == ETH_P_IP) {
ITYM, htons(ETH_P_IP).
> +static inline void ehea_xmit3(struct sk_buff *skb,
> + struct net_device *dev, struct ehea_swqe *swqe)
> +{
> + int i;
> + skb_frag_t *frag;
> + int nfrags = skb_shinfo(skb)->nr_frags;
> + u8 *imm_data = &swqe->u.immdata_nodesc.immediate_data[0];
> + u64 skb_protocol = skb->protocol;
Useless var.
> +
> + EDEB_EN(7, "");
> + if (likely(skb_protocol == ETH_P_IP)) {
htons(ETH_P_IP)
^ permalink raw reply
* Re: PowerPC Local Bus
From: Kumar Gala @ 2006-08-09 13:05 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060809122904.GE3918@igloo.df.lth.se>
On Aug 9, 2006, at 7:29 AM, Fredrik Roubert wrote:
> On Tue 08 Aug 17:03 CEST 2006, Kumar Gala wrote:
>
>> The reason you haven't seen any code is due to several reasons. One,
>> FPGA/localbus implementations can be very specific and thus reuse is
>> difficult. Two, some of this code tends to end up it boot loaders to
>> setup the UPM (take a look at U-boot for possible UPM config code).
>
> OK, so you do all the setup in the boot loader and then the driver
> just
> needs to ioremap() the FPGA? That sounds reasonable and explains why I
> haven't found any kernel source code relating to this ...
>
> I just didn't expect the kernel to rely on the boot loader to
> configure
> this. Is that the recommended way to to it?
I don't think there is any recommendation one way or the other. Its
just that the boards that are currently supported in the kernel doing
have FGPAs needing UPM config and thus there isn't any code one way
or the other.
- kumar
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Segher Boessenkool @ 2006-08-09 13:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sfr, Michael Neuling, linuxppc-dev, paulus, anton
In-Reply-To: <1155122580.4040.96.camel@localhost.localdomain>
>> What is a SLB shadow buffer and why do we need it? (I don't want to
>> question the patch but rather learn a little more about lowlevel
>> ppc64
>> mmu details)
>
> Yeah, same question :) I don't have my PAPR at hand and I'm still
> travellling but I'm curious about that one...
>
> I would suspect it allows the HV to save/restore SLBs when sharing a
> processor between partitions but then... the kernel requires that
> anyway
> so either the current code is bogus and that's pretty bad (which I
> don't
> think so) or maybe the fact that we didn't register the shadow
> caused HV
> to always save/restore the entire SLB, while by using the shadow,
> we let
> it save/restore only the bolted entries we put in there (and just
> re-fault the other ones). If it's not that, then what ? :)
Yep, that's it (and I do have a PAPR at hand ;-) )
Note that we could also store "volatile" entries in the shadow buffer;
that's supposed to improve performance.
Segher
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Josh Boyer @ 2006-08-09 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155122309.4040.94.camel@localhost.localdomain>
On Wed, 2006-08-09 at 13:18 +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> > Folks,
> >
> > Where should we place the sources for the OF Flat Device
> > Tree source files? They used to be in U-Boot, but that
> > isn't happening any more.
>
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...
We're only talking about the _source_ files. The .dts files. Not the
binary trees themselves.
The basic summary is that having a .dts in the kernel for every
defconfig would be good. (I think that was the summary anyway.)
josh
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Takashi Iwai @ 2006-08-09 12:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <44D9D74E.6010009@sipsolutions.net>
At Wed, 09 Aug 2006 14:38:38 +0200,
Johannes Berg wrote:
>
> Takashi Iwai wrote:
> > A relevant question: do we need I2C_POWERMAC for both onyx and tas?
> >
> Yes, there are PowerBooks and G5s with either. Actually, a bit more
> thinking about this I'm pretty sure that it is used on all G5s by way of
> how things are hooked up. There are SMU I2C busses too but they surely
> don't connect any sound i2c stuff.
OK, now I added both I2C and I2C_POWERMAC and committed to ALSA tree.
Takashi
diff -r 67e0e0ca5f65 -r f72c2a462f76 aoa/codecs/Kconfig
--- a/aoa/codecs/Kconfig Wed Aug 09 14:33:27 2006 +0200
+++ b/aoa/codecs/Kconfig Wed Aug 09 14:51:14 2006 +0200
@@ -1,6 +1,8 @@ config SND_AOA_ONYX
config SND_AOA_ONYX
tristate "support Onyx chip"
depends on SND_AOA
+ select I2C
+ select I2C_POWERMAC
---help---
This option enables support for the Onyx (pcm3052)
codec chip found in the latest Apple machines
@@ -18,6 +20,8 @@ config SND_AOA_TAS
config SND_AOA_TAS
tristate "support TAS chips"
depends on SND_AOA
+ select I2C
+ select I2C_POWERMAC
---help---
This option enables support for the tas chips
found in a lot of Apple Machines, especially
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-08-09 9:50 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154509462.26242.9.camel@localhost.localdomain>
> I'm only just starting to get benh's new irq code, but I think
> irq_find_host(dn) isn't doing what we want here. It's probably harmless,
> but AFAICT irq_find_host() is only meant to be called when you have the
> node of the irq controller, not for an arbitrary dn. The doco's a bit
> ambiguous:
>
> * irq_find_host - Locates a host for a given device node
> * @node: device-tree node of the interrupt controller
>
> But looking at the implementation, it doesn't do a search up the tree or
> anything, it just checks node against each host.
For pSeries, passing NULL is fine for host anyway as there is only one
domain that is relevant for MSIs (there might be a 8259 legacy domain
too but it's not relevant) and that domain is set to be the default
host.
> Also, since's benh's latest patch went in we'll have to split this into
> two calls, I think we want:
>
> virq = irq_create_mapping(NULL ???, ret[0]);
> set_irq_type(virq, ret[1] ? IRQ_TYPE_EDGE_RISING : IRQ_TYPE_LEVEL_LOW);
MSIs are always edge (though there might be an issue with some P5IOC
errata lurking here...). The xics code doesn't care much at this point
though.
Ben.
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Johannes Berg @ 2006-08-09 12:38 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <s5h4pwmdr9o.wl%tiwai@suse.de>
Takashi Iwai wrote:
> A relevant question: do we need I2C_POWERMAC for both onyx and tas?
>
Yes, there are PowerBooks and G5s with either. Actually, a bit more
thinking about this I'm pretty sure that it is used on all G5s by way of
how things are hooked up. There are SMU I2C busses too but they surely
don't connect any sound i2c stuff.
johannes
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Benjamin Herrenschmidt @ 2006-08-09 11:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Michael Neuling, paulus, anton, sfr
In-Reply-To: <20060805124544.GB23494@lst.de>
On Sat, 2006-08-05 at 14:45 +0200, Christoph Hellwig wrote:
> On Fri, Aug 04, 2006 at 03:53:19PM +1000, Michael Neuling wrote:
> > This adds a shadow buffer for the SLBs and regsiters it with PHYP.
> > Only the bolted SLB entries (first 3) are saved.
>
> What is a SLB shadow buffer and why do we need it? (I don't want to
> question the patch but rather learn a little more about lowlevel ppc64
> mmu details)
Yeah, same question :) I don't have my PAPR at hand and I'm still
travellling but I'm curious about that one...
I would suspect it allows the HV to save/restore SLBs when sharing a
processor between partitions but then... the kernel requires that anyway
so either the current code is bogus and that's pretty bad (which I don't
think so) or maybe the fact that we didn't register the shadow caused HV
to always save/restore the entire SLB, while by using the shadow, we let
it save/restore only the bolted entries we put in there (and just
re-fault the other ones). If it's not that, then what ? :)
Ben.
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Benjamin Herrenschmidt @ 2006-08-09 11:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154464346.19994.4.camel@cashmere.sps.mot.com>
On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> Folks,
>
> Where should we place the sources for the OF Flat Device
> Tree source files? They used to be in U-Boot, but that
> isn't happening any more.
Why ? While having device-tree's in zImages is good to handle firmwares
that can't pass them, I still think that the proper thing to do is to
have the firmware provide the DT to the kernel. Did Denk decide once for
all against having DTs passed by uboot at all ? In which case, it's
probably time to consider a fork...
> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
>
> Are there other suggestions or better ideas?
>
> Thanks,
> jdl
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Fix loop logic in irq_alloc_virt()
From: Benjamin Herrenschmidt @ 2006-08-09 9:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev list
In-Reply-To: <20060802004852.C66FB67B7F@ozlabs.org>
On Wed, 2006-08-02 at 10:48 +1000, Michael Ellerman wrote:
> There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
> if it can't find a slot it might look past the end of the irq_map.
>
> I think this is a fix. No one in the kernel actually calls this with
> count > 1, so it's not critical.
Good catch. /me stupid.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/kernel/irq.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> Index: to-merge/arch/powerpc/kernel/irq.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/irq.c
> +++ to-merge/arch/powerpc/kernel/irq.c
> @@ -728,7 +728,6 @@ unsigned int irq_alloc_virt(struct irq_h
> {
> unsigned long flags;
> unsigned int i, j, found = NO_IRQ;
> - unsigned int limit = irq_virq_count - count;
>
> if (count == 0 || count > (irq_virq_count - NUM_ISA_INTERRUPTS))
> return NO_IRQ;
> @@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
> /* Look for count consecutive numbers in the allocatable
> * (non-legacy) space
> */
> - for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
> - for (j = i; j < (i + count); j++)
> - if (irq_map[j].host != NULL) {
> - i = j + 1;
> - continue;
> - }
> - found = i;
> - break;
> + for (i = NUM_ISA_INTERRUPTS, j = 0; i < irq_virq_count; i++) {
> + if (irq_map[i].host != NULL)
> + j = 0;
> + else
> + j++;
> +
> + if (j == count) {
> + found = i - count + 1;
> + break;
> + }
> }
> if (found == NO_IRQ) {
> spin_unlock_irqrestore(&irq_big_lock, flags);
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Takashi Iwai @ 2006-08-09 12:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <44D9D532.9010200@sipsolutions.net>
At Wed, 09 Aug 2006 14:29:38 +0200,
Johannes Berg wrote:
>
> Takashi Iwai wrote:
> >> Yeah, I really should know :) But I'm not sure at the moment, and the
> >> powermac I own is a few hundred kilometers away...
> >>
> >
> > Don't worry, we can wait :)
> >
> Maybe someone on linuxppc-dev can quickly check? Does a G5 use
> I2C_POWERMAC for access to the codecs? I think it does, but there are
> other I2C busses as well.
> >> That looks good to me, and should get rid of the build failure. However,
> >> if one doesn't configure I2C_POWERMAC, no codec will ever be found at
> >> runtime.
> >>
> >
> > Yes, that's my concern, too.
> >
> I'm not sure how much we should force the users to a sensible
> configuration ;) But I suppose selecting I2C_POWERMAC is fine for all
> relevant machines for now.
Agreed.
A relevant question: do we need I2C_POWERMAC for both onyx and tas?
Takashi
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Johannes Berg @ 2006-08-09 12:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <s5h7j1idrvf.wl%tiwai@suse.de>
Takashi Iwai wrote:
>> Yeah, I really should know :) But I'm not sure at the moment, and the
>> powermac I own is a few hundred kilometers away...
>>
>
> Don't worry, we can wait :)
>
Maybe someone on linuxppc-dev can quickly check? Does a G5 use
I2C_POWERMAC for access to the codecs? I think it does, but there are
other I2C busses as well.
>> That looks good to me, and should get rid of the build failure. However,
>> if one doesn't configure I2C_POWERMAC, no codec will ever be found at
>> runtime.
>>
>
> Yes, that's my concern, too.
>
I'm not sure how much we should force the users to a sensible
configuration ;) But I suppose selecting I2C_POWERMAC is fine for all
relevant machines for now.
johannes
^ permalink raw reply
* Re: PowerPC Local Bus
From: Fredrik Roubert @ 2006-08-09 12:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <5C1C19D6-8FC8-46AF-9C4B-B9989B1A997B@kernel.crashing.org>
On Tue 08 Aug 17:03 CEST 2006, Kumar Gala wrote:
> The reason you haven't seen any code is due to several reasons. One,
> FPGA/localbus implementations can be very specific and thus reuse is
> difficult. Two, some of this code tends to end up it boot loaders to
> setup the UPM (take a look at U-boot for possible UPM config code).
OK, so you do all the setup in the boot loader and then the driver just
needs to ioremap() the FPGA? That sounds reasonable and explains why I
haven't found any kernel source code relating to this ...
I just didn't expect the kernel to rely on the boot loader to configure
this. Is that the recommended way to to it?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
^ permalink raw reply
* Re: boot problems on pseries
From: Olaf Hering @ 2006-08-09 11:51 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linuxppc-dev
In-Reply-To: <20060809013609.GA10876@ca-server1.us.oracle.com>
On Tue, Aug 08, 2006 at 06:36:09PM -0700, Mark Fasheh wrote:
> Recently, I discovered that newer kernels would no longer fully boot.
The IDE controller got irq32 in older kernels, now it gets irq17.
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:04.1
AMD8111: chipset revision 3
AMD8111: 0000:00:04.1 (rev 03) UDMA133 controller
AMD8111: 100% native mode on irq 17
ide0: BM-DMA at 0x7c00-0x7c07, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x7c08-0x7c0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: TOSHIBA MK6026GAXB, ATA DISK drive
ide0 at 0x7400-0x7407,0x6c02 on irq 17
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: lost interrupt
hda: lost interrupt
...
^ permalink raw reply
* RE: Trouble on building crossover compiler for Synology 8041 PPCbased NAS
From: Li Yang-r58472 @ 2006-08-09 11:30 UTC (permalink / raw)
To: David Hawkins, chun fung siu; +Cc: linuxppc-embedded
In-Reply-To: <44D8C02D.1070205@ovro.caltech.edu>
http://images.tomshardware.com/2006/06/28/not_going_wrong_with_the_synol
ogy_ds/synology_ds106e_main_board_big.jpg
Here is a picture of the exact model. I can confirm that it's a
MPC8241.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> David Hawkins
> Sent: Wednesday, August 09, 2006 12:48 AM
> To: chun fung siu
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Trouble on building crossover compiler for Synology 8041
PPCbased NAS
>=20
> chun fung siu wrote:
> > Hi,
> >
> > I recently bought a Synology Network Attached Server DS-106e, run
using
> > a "Linux 2. 4.22-uc-0" Kernel, under 8041 PPC, no "gcc" installed. I
> > want to build a crosslink gcc compiler for it in another "debian 2.6
> > kernel" linux. I find many options in the crosslink build script on
ppc,
> > but can't find any option for 8041 PPC. So what option should I
choose?
> > And further can I put the artifacts just compiled in my Network
Attached
> > Server? So that I can compile anything directly in my NAS.
>=20
> The processor is probably an *MPC8241*.
>=20
> The DS101g is also an MPC8241. So this should provide you with
> some useful info:
>=20
> http://www.nslu2-linux.org/wiki/DS101/HomePage
> http://www.nslu2-linux.org/wiki/DS101/DS101GHardware
>=20
> Dave
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC] Debugging with a HW probe.
From: Jimi Xenidis @ 2006-08-09 10:44 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <311550865236b8b45674.846930886.miltonm@bga.com>
On Aug 8, 2006, at 9:22 PM, Milton Miller wrote:
> On Sun Aug 6 2006 09:42:16 AM CDT, Jimi Xenidis wrote:
>> On the XenPPC project we've been playing around with using GDB to
>> source debug Linux (and Xen) using a RiscWatch HW probe.
>
>> We have found it useful to teach xmon to make this call so we can
>> then
>> debug the SW thru the probe. Is this useful to anyone else
>
> Since you only invoke the attention on command from the debugger, how
> is this better than just invoking the stop command from the probe?
> Is it you
> are not dispatched out? That you are not at a random point in the
> input
> polling?
Thats exactly it!
If I get the probe to stop the CPU I could stop in the OS or in a
user app. Since we are working on Xen it could be Xen or any number
of OSes or user apps on OSes.
When interrogating the machine state, the probe (almost) respects the
modes of the CPU and MMU so memory accesses are translated (if xlate
is on). Since, probe "soft breakpoints" are ATTN instructions as
well they get written into memory by the probe.
Having SW "call out" allows me to make sure that I'm in the address
space I care about.
Since I only invoke it from xmon it assumes you have xmon support and
to really be useful you need to SysReq to xmon.
I could be useful to make this part of SysReq, but I think we want to
make sure that its use is entirely intentional.
You can also insert 'asm volatile(".long 0x200;nop");' in you own
code or even add it to BUG()/panic() and skip the suffering the xmon/
SysReq trap.
BTW: I say "almost" because the probe does not respect the truncating
of the upper bits when xlate is off and 0xC00... addresses are
useless, we hacked the gdb stub to work around that.
BTW2: (I'm sure obvious to some), Since the probe writes ATTN
instructions, I do not know what would happen if the probe wrote ATTN
to an unmapped page, this is why debugging user space might be useless.
-JX
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Michael Ellerman @ 2006-08-09 10:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <F5E5EF18-6452-4E9D-8A43-6D1CE9C3E43E@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
On Wed, 2006-08-09 at 11:52 +0200, Segher Boessenkool wrote:
> > I was just re-reading this thread and this got me thinking. I think
> > the
> > current code does violate this rule if firmware has allocated more
> > than
> > one MSI to the device.
> >
> > In rtas_enable_msi() we ask firmware how many MSIs the device has been
> > given (by firmware), we then return one to the driver, but leave any
> > extras configured.
> >
> > So this might lead to the state where the card has been configured to
> > use x MSIs, but we only tell the driver about 1 of them. I don't know
> > enough PCI to grok if that's going to be a problem.
>
> A device could in principle happily start using all MSIs it has been
> assigned as soon as its global interrupt enable bit is set. So lying
> to the driver about what MSIs are enabled can in principle cause nasty
> problems.
>
> In reality however, on any (recent) device, every interrupt cause also
> has its own enable bits that the driver needs to set. So we're sort-of
> safe here.
Yeah ok, I thought that was probably the answer - it's possible, but
probably not a problem IRL.
> Eventually, we should change the API for pci_enable_msi() so that it
> can enable multiple MSIs as well; an arch implementation can always
> choose to do just one. This lets us roll the APIs for MSI and MSI-X
> into one as well btw -- always a good thing!
Yeah. Looking at the way drivers use the current API (and there's only a
few), they generally seem to try to enable n MSI-X vectors, then
fallback to a single MSI then LSI. And then there's some that just want
a single MSI as a drop-in replacement for LSI.
So I think we could have pci_enable_msi(dev), which would enable a
single MSI _or_ MSI-X vector, depending on what's available. That'd be
used by drivers that just want a simple replacement for LSI. And then
pci_enable_multi_msi(dev, num_irqs) which would give the driver num_irqs
MSI or MSI-X vectors.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
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