* 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
* Re: [PATCH 5/6] ehea: makefile
From: Sam Ravnborg @ 2006-08-09 9:50 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F74.1000704@de.ibm.com>
On Wed, Aug 09, 2006 at 10:40:20AM +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
>
> drivers/net/ehea/Makefile | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>
>
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/Makefile 1969-12-31
> 16:00:00.000000000 -0800
> +++ kernel/drivers/net/ehea/Makefile 2006-08-08 23:59:38.083467216 -0700
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the eHEA ethernet device driver for IBM eServer System p
> +#
> +
> +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o
> ehea_phyp.o
> +obj-$(CONFIG_EHEA) += ehea_mod.o
> +
Using -objs is deprecated, please use ehea_mod-y.
This needs to be documented and later warned upon which I will do soon.
Sam
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Segher Boessenkool @ 2006-08-09 9:52 UTC (permalink / raw)
To: michael; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1155090210.7087.4.camel@localhost.localdomain>
> 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.
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!
Segher
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Christian Borntraeger @ 2006-08-09 9:08 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
Hi Jan-Bernd,
I had some minutes, here are some finding after a quick look.
On Wednesday 09 August 2006 10:38, you wrote:
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
> +{
> + int i;
> + u64 hret =3D H_HARDWARE;
> + u64 rx_packets =3D 0;
> + struct ehea_port *port =3D (struct ehea_port*)dev->priv;
dev->priv is a void pointer, this cast is unnecessary. When we are at it, h=
ave=20
you considered the netdev_priv macro? This will require some prep in=20
alloc_netdev and might not always pe possible.=20
> + struct ehea_adapter *adapter =3D port->adapter;
> + struct hcp_query_ehea_port_cb_2 *cb2 =3D NULL;
> + struct net_device_stats *stats =3D &port->stats;
> +
> + EDEB_EN(7, "net_device=3D%p", dev);
> +
> + cb2 =3D kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
> + if (!cb2) {
> + EDEB_ERR(4, "No memory for cb2");
> + goto get_stat_exit;
> + }
> +
> + hret =3D ehea_h_query_ehea_port(adapter->handle,
> + port->logical_port_id,
> + H_PORT_CB2,
> + H_PORT_CB2_ALL,
> + cb2);
> +
> + if (hret !=3D H_SUCCESS) {
> + EDEB_ERR(4, "query_ehea_port failed for cb2");
> + goto get_stat_exit;
> + }
You leak memory here, dont you? (cb2 points to allocated memory and you are=
in=20
an error path.)
> +
> + EDEB_DMP(7, (u8*)cb2,
> + sizeof(struct hcp_query_ehea_port_cb_2), "After HCALL");
> +
> + for (i =3D 0; i < port->num_def_qps; i++) {
> + rx_packets +=3D port->port_res[i].rx_packets;
> + }
> +
> + stats->tx_packets =3D cb2->txucp + cb2->txmcp + cb2->txbcp;
> + stats->multicast =3D cb2->rxmcp;
> + stats->rx_errors =3D cb2->rxuerr;
> + stats->rx_bytes =3D cb2->rxo;
> + stats->tx_bytes =3D cb2->txo;
> + stats->rx_packets =3D rx_packets;
> +
> +get_stat_exit:
> + EDEB_EX(7, "");
> + return stats;
> +}
again, cb2 is not freed.
[...]
> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
> +{
> + u64 addr;
> + addr =3D tmp_addr;
> + return addr;
> +}
This is suppsed to change in the future? If not you can get rid of it.=20
> +
> +static inline u64 get_rwqe_addr(u64 tmp_addr)
> +{
> + return tmp_addr;
> +}
same here.=20
> +
> +static int ehea_poll(struct net_device *dev, int *budget)
> +{
> + struct ehea_port *port =3D (struct ehea_port*)dev->priv;
Again. no cast, maybe netdev_priv macro.=20
> + struct ehea_port_res *port_res =3D &port->port_res[0];
> + struct ehea_cqe *cqe;
> + struct ehea_qp *qp =3D port_res->qp;
> + int wqe_index =3D 0;
> + int last_wqe_index =3D 0;
> + int x =3D 0;
> + int processed =3D 0;
> + int processed_RQ1 =3D 0;
> + int processed_RQ2 =3D 0;
> + int processed_RQ3 =3D 0;
> + int rq;
> + int intreq;
> + struct sk_buff **skb_arr_rq1 =3D port_res->skb_arr_rq1;
> + struct sk_buff **skb_arr_rq2 =3D port_res->skb_arr_rq2;
> + struct sk_buff **skb_arr_rq3 =3D port_res->skb_arr_rq3;
> + int skb_arr_rq1_len =3D port_res->skb_arr_rq1_len;
> + int my_quota =3D min(*budget, dev->quota);
> +
> + EDEB_EN(7, "dev=3D%p, port_res=3D%p, budget=3D%d, quota=3D%d, qp_nr=3D%=
x",
> + dev, port_res, *budget, dev->quota,
> + port_res->qp->init_attr.qp_nr);
> + my_quota =3D min(my_quota, EHEA_MAX_RWQE);
> +
> + /* rq0 is low latency RQ */
> + cqe =3D ehea_poll_rq1(qp, &wqe_index);
> + while ((my_quota > 0) && cqe) {
> + ehea_inc_rq1(qp);
> + processed_RQ1++;
> + processed++;
> + my_quota--;
> +
> + EDEB_DMP(6, (u8*)cqe, 4 * 16, "CQE");
> + last_wqe_index =3D wqe_index;
> + rmb();
> + if (!ehea_check_cqe(cqe, &rq)) {
> + struct sk_buff *skb;
> + if (rq =3D=3D 1) { /* LL RQ1 */
> + void *pref;
> +
> + x =3D (wqe_index + 1) % skb_arr_rq1_len;
> + pref =3D (void*)skb_arr_rq1[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (wqe_index + 1) % skb_arr_rq1_len;
> + pref =3D (void*)(skb_arr_rq1[x]->data);
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + skb =3D skb_arr_rq1[wqe_index];
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "LL SBK=3DNULL, wqe_index=3D%d",
> + wqe_index);
> + skb =3D dev_alloc_skb(EHEA_LL_PKT_SIZE);
> + if (!skb)
> + panic("Alloc SKB failed");
> + }
> + skb_arr_rq1[wqe_index] =3D NULL;
> + ehea_fill_skb_ll(dev, skb, cqe);
> + } else if (rq =3D=3D 2) { /* RQ2 */
> + void *pref;
> + int skb_index =3D EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id);
> + x =3D (skb_index + 1) % port_res->skb_arr_rq2_len;
> + pref =3D (void*)skb_arr_rq2[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (skb_index + 1) % port_res->skb_arr_rq2_len;
> + pref =3D (void*)(skb_arr_rq2[x]->data);
> +
> + prefetch(pref);
> + prefetch(pref + EHEA_CACHE_LINE);
> + prefetch(pref + EHEA_CACHE_LINE * 2);
> + prefetch(pref + EHEA_CACHE_LINE * 3);
> + skb =3D skb_arr_rq2[skb_index];
> +
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "rq2: SKB=3DNULL, index=3D%d",
> + skb_index);
> + break;
> + }
> + skb_arr_rq2[skb_index] =3D NULL;
> + ehea_fill_skb(dev, skb, cqe);
> + processed_RQ2++;
> + } else {
> + void *pref;
> + int skb_index =3D EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id);
> + x =3D (skb_index + 1) % port_res->skb_arr_rq3_len;
> + pref =3D (void*)skb_arr_rq3[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (skb_index + 1) % port_res->skb_arr_rq3_len;
> + pref =3D (void*)(skb_arr_rq3[x]->data);
> + prefetch(pref);
> + prefetch(pref + EHEA_CACHE_LINE);
> + prefetch(pref + EHEA_CACHE_LINE * 2);
> + prefetch(pref + EHEA_CACHE_LINE * 3);
> +
> + skb =3D skb_arr_rq3[skb_index];
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "rq3: SKB=3DNULL, index=3D%d",
> + skb_index);
> + break;
> + }
> + skb_arr_rq3[skb_index] =3D NULL;
> + ehea_fill_skb(dev, skb, cqe);
> + processed_RQ3++;
> + }
> +
> + EDEB(6, "About to pass SKB: dev=3D%p\n"
> + "skb=3D%p skb->data=3D%p skb->len=3D%d"
> + " skb->data_len=3D0x%x nr_frags=3D%d",
> + dev,
> + skb,
> + skb->data,
> + skb->len,
> + skb->data_len, skb_shinfo(skb)->nr_frags);
> + if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) {
> + EDEB(7, "VLAN TAG extracted: %4x, vgrp=3D%p",
> + cqe->vlan_tag, port->vgrp);
> + EDEB(7, "vlan_devices[vlan_tag]=3D%p",
> + port->vgrp->vlan_devices[cqe->vlan_tag]);
> + vlan_hwaccel_receive_skb(skb, port->vgrp,
> + cqe->vlan_tag);
> + } else {
> + EDEB(7, "netif_receive_skb");
> + netif_receive_skb(skb);
> + }
> + EDEB(7, "SKB passed (netif_receive(skb) called)");
> +
> + } else {
> + struct sk_buff *skb;
> +
> + EDEB_ERR(4, "cqe->status indicating error: CQE:");
> + EDEB_DMP(4, (u8*)cqe, 4 * 16, "");
> + if (rq =3D=3D 2) {
> + processed_RQ2++;
> + skb =3D skb_arr_rq2[
> + EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)];
> + skb_arr_rq2[EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)] =3D NULL;
> + dev_kfree_skb(skb);
> + }
> + if (rq =3D=3D 3) {
> + processed_RQ3++;
> + skb =3D skb_arr_rq3[
> + EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)];
> + skb_arr_rq3[EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)] =3D NULL;
> + dev_kfree_skb(skb);
> + }
> + }
> + cqe =3D ehea_poll_rq1(qp, &wqe_index);
> + }
> +
> + dev->quota -=3D processed;
> + *budget -=3D processed;
> +
> + port_res->p_state.ehea_poll +=3D 1;
> +
> + port_res->rx_packets +=3D processed;
> +
> + ehea_refill_rq1(port_res, last_wqe_index, processed_RQ1);
> + ehea_refill_rq2(port_res, processed_RQ2);
> + ehea_refill_rq3(port_res, processed_RQ3);
> +
> + intreq =3D ((port_res->p_state.ehea_poll & 0xF) =3D=3D 0xF);
> +
> + EDEB_EX(7, "processed=3D%d, *budget=3D%d, dev->quota=3D%d",
> + processed, *budget, dev->quota);
> +
> + if (!cqe || intreq) {
> + netif_rx_complete(dev);
> + ehea_reset_cq_ep(port_res->recv_cq);
> + ehea_reset_cq_n1(port_res->recv_cq);
> + cqe =3D ipz_qeit_get_valid(&qp->ipz_rqueue1);
> + EDEB(7, "CQE=3D%p, break ehea_poll while loop", cqe);
> + if (!cqe || intreq)
> + return 0;
> + if (!netif_rx_reschedule(dev, my_quota))
> + return 0;
> + }
> + return 1;
> +}
The poll function seems too long and therefore hard to review. Please consi=
der=20
splitting it.=20
=2D-=20
Mit freundlichen Gr=FC=DFen / Best Regards
Christian Borntraeger
Linux Software Engineer zSeries Linux & Virtualization
^ permalink raw reply
* [PATCH 6/6] ehea: Kernel build (Kconfig / Makefile)
From: Jan-Bernd Themann @ 2006-08-09 8:40 UTC (permalink / raw)
To: netdev; +Cc: Thomas Klein, linux-ppc, Christoph Raisch, linux-kernel,
Marcus Eder
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
drivers/net/Kconfig | 6 ++++++
drivers/net/Makefile | 1 +
2 files changed, 7 insertions(+)
diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Kconfig patched_kernel/drivers/net/Kconfig
--- linux-2.6.18-rc4/drivers/net/Kconfig 2006-08-06 11:20:11.000000000 -0700
+++ patched_kernel/drivers/net/Kconfig 2006-08-08 03:00:49.526421944 -0700
@@ -2277,6 +2277,12 @@ config CHELSIO_T1
To compile this driver as a module, choose M here: the module
will be called cxgb.
+config EHEA
+ tristate "eHEA Ethernet support"
+ depends on IBMEBUS
+ ---help---
+ This driver supports the IBM pSeries ethernet adapter
+
config IXGB
tristate "Intel(R) PRO/10GbE support"
depends on PCI
diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Makefile patched_kernel/drivers/net/Makefile
--- linux-2.6.18-rc4/drivers/net/Makefile 2006-08-06 11:20:11.000000000 -0700
+++ patched_kernel/drivers/net/Makefile 2006-08-08 03:00:30.061451584 -0700
@@ -10,6 +10,7 @@ obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
obj-$(CONFIG_IXGB) += ixgb/
obj-$(CONFIG_CHELSIO_T1) += chelsio/
+obj-$(CONFIG_EHEA) += ehea/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
^ permalink raw reply
* [PATCH 5/6] ehea: makefile
From: Jan-Bernd Themann @ 2006-08-09 8:40 UTC (permalink / raw)
To: netdev; +Cc: Thomas Klein, linux-ppc, Christoph Raisch, linux-kernel,
Marcus Eder
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
drivers/net/ehea/Makefile | 7 +++++++
1 file changed, 7 insertions(+)
--- linux-2.6.18-rc4-orig/drivers/net/ehea/Makefile 1969-12-31 16:00:00.000000000 -0800
+++ kernel/drivers/net/ehea/Makefile 2006-08-08 23:59:38.083467216 -0700
@@ -0,0 +1,7 @@
+#
+# Makefile for the eHEA ethernet device driver for IBM eServer System p
+#
+
+ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o
+obj-$(CONFIG_EHEA) += ehea_mod.o
+
^ 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