* Re: Proposed prom parse fix + moving.
From: Grant Likely @ 2009-04-18 5:35 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Michal Simek, Arnd Bergmann, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0904180057290.2522@wrl-59.cs.helsinki.fi>
On Fri, Apr 17, 2009 at 4:07 PM, Ilpo J=E4rvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Fri, 17 Apr 2009, Ilpo J=E4rvinen wrote:
>
>> On Fri, 17 Apr 2009, Michal Simek wrote:
>>
>> > Grant Likely wrote:
>> > > On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wr=
ote:
>> > >> Hi All,
>> > >>
>> > >> I have got email from Ilpo about prom_parse file.
>> > >> I take this file from powerpc. Who did write prom_parse file and ta=
ke care about?
>> > >
>> > > Posting to the linuxppc-dev list is sufficient to start. =A0There ar=
e
>> > > several people who may be interested.
>> > >
>> > >> BTW: What about to move prom_parse file to any generic location as =
we discussed in past?
>> > >> Any volunteer?
>> > >
>> > > I'm kind of working on it. =A0More specifically, I'm looking at
>> > > factoring out fdt stuff into common code (drivers/of/of_fdt.c). But =
I
>> > > haven't made a whole lot of progress yet.
>> > >
>> > >> -------- Original Message --------
>> > >> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
>> > >> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
>> > >> From: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
>> > >> To: monstr@monstr.eu
>> > >> CC: microblaze-uclinux@itee.uq.edu.au
>> > >>
>> > >> While some version of the patches were on the lkml I read
>> > >> some part of the code briefly through but my feedback got
>> > >> stuck into postponed emails, so here's one correctness
>> > >> related issue I might have found (the rest were just
>> > >> cosmetic things).
>> > >>
>> > >> I'm not sure if the latter return needs the of_node_put or not
>> > >> but it seems more likely than not.
>> > >
>> > > Yes, it does. =A0This change is applicable to
>> > > arch/powerpc/kernel/prom_parse.c too.
>> >
>> > ok.
>> > Ilpo: Can you create patch for both architectures?
>>
>> Sure, but tomorrow as today is a deadline day :-).
>
> Ok, here's combined patch for both. I came up with slightly
> shorter and (IMHO) nicer variant for -EINVAL assignment than
> in the first version.
>
> --
> [PATCH] powerpc & microblaze: add missing of_node_put to error handling
>
> While reviewing some microblaze patches a while ago, I noticed
> a suspicious error handling in of_irq_map_one(), which turned
> out to be a copy from arch/powerpc. Grant Likely
> <grant.likely@secretlab.ca> confirmed that this is a real bug.
>
> Merge error handling paths using goto with the normal return
> path.
>
> Powerppc compile tested.
>
> Signed-off-by: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
Looks right to me (but I haven't tested).
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/microblaze/kernel/prom_parse.c | =A0 11 +++++------
> =A0arch/powerpc/kernel/prom_parse.c =A0 =A0| =A0 11 +++++------
> =A02 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index ae0352e..d16c32f 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -903,7 +903,7 @@ int of_irq_map_one(struct device_node *device,
> =A0 =A0 =A0 =A0struct device_node *p;
> =A0 =A0 =A0 =A0const u32 *intspec, *tmp, *addr;
> =A0 =A0 =A0 =A0u32 intsize, intlen;
> - =A0 =A0 =A0 int res;
> + =A0 =A0 =A0 int res =3D -EINVAL;
>
> =A0 =A0 =A0 =A0pr_debug("of_irq_map_one: dev=3D%s, index=3D%d\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device->full_name, index);
> @@ -926,21 +926,20 @@ int of_irq_map_one(struct device_node *device,
>
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> - =A0 =A0 =A0 if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 if (tmp =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0pr_debug(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> =A0 =A0 =A0 =A0if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addr, out_=
irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_=
parse.c
> index 8f0856f..8362620 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -971,7 +971,7 @@ int of_irq_map_one(struct device_node *device, int in=
dex, struct of_irq *out_irq
> =A0 =A0 =A0 =A0struct device_node *p;
> =A0 =A0 =A0 =A0const u32 *intspec, *tmp, *addr;
> =A0 =A0 =A0 =A0u32 intsize, intlen;
> - =A0 =A0 =A0 int res;
> + =A0 =A0 =A0 int res =3D -EINVAL;
>
> =A0 =A0 =A0 =A0DBG("of_irq_map_one: dev=3D%s, index=3D%d\n", device->full=
_name, index);
>
> @@ -995,21 +995,20 @@ int of_irq_map_one(struct device_node *device, int =
index, struct of_irq *out_irq
>
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> - =A0 =A0 =A0 if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 if (tmp =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0DBG(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> =A0 =A0 =A0 =A0if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addr, out_irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> --
> 1.5.6.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: Update Warp to use leds-gpio driver
From: Grant Likely @ 2009-04-18 5:07 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Trent Piepho
In-Reply-To: <20090418003745.7dce8f47@lappy.seanm.ca>
On Fri, Apr 17, 2009 at 10:37 PM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> On Fri, 17 Apr 2009 20:12:50 -0700 (PDT)
> "Trent Piepho" <xyzzy@speakeasy.org> wrote:
>
>> On Mon, 6 Apr 2009, Sean MacLennan wrote:
>> > Now that leds-gpio is a proper OF platform driver, the Warp can use
>> > the leds-gpio driver rather than the old out-of-kernel driver.
>> >
>> > One side-effect is the leds-gpio driver always turns the leds off
>> > while the old driver left them alone. So we have to set them back to
>> > the correct settings.
>>
>> Originally, I had the OF bindings support this feature, see
>> http://article.gmane.org/gmane.linux.kernel/749094
>>
>> Maybe this would be a better way to do it? =A0It avoids the glitch in
>> the leds, is less code overall, and can be use by other devices that
>> might want this same behavior.
>
> Yes, that is a cleaner way to handle the LEDs. Do you know why this
> patch wasn't accepted at the time? A quick google shows that Grant
> Likely acked it.
>
> The patch will no longer apply since default state does not exist.
It got left here:
On Sun, Jan 11, 2009 at 7:39 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Sun, 2009-01-11 at 04:58 -0800, Trent Piepho wrote:
>> It doesn't seem right to merge someone's patches together, make a very
>> small change, and then no longer credit them as the author. Seems like =
it
>> defeats the purpose of the SOB lines for tracing the train of custody to=
o.
>> If someone looks to see where the code came from, it will look like you
>> wrote it. Maybe Freescale will say Intel stole our code? Without the S=
OB,
>> what record is there in git that Freescale gave permission to put the co=
de
>> in the kernel?
>>
>> I also put some significant effort into writing informative commit
>> messages, which have been lost. Along with Grant's acks for my patches.
>
> It also doesn't make sense to make three changes adding different
> interfaces and rearranging the same section of code three different
> times. I'm dropping the patch, please send me a merged version of those
> patches with a commit message you're happy with. If you want Acked-by
> lines, we'll have to wait for them on the new patch as I'm going to do
> this exactly by the book regardless of time pressures now. Please
> indicate who you want Ack-ed by lines from so I know who to wait for.
> Also, you'd better exclude the suspend/resume change and credit me for
> the bitfield change, just to be 100% sure this is all legally accurate.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: Update Warp to use leds-gpio driver
From: Sean MacLennan @ 2009-04-18 4:37 UTC (permalink / raw)
To: Trent Piepho; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0904172008310.5178@t2.domain.actdsltmp>
On Fri, 17 Apr 2009 20:12:50 -0700 (PDT)
"Trent Piepho" <xyzzy@speakeasy.org> wrote:
> On Mon, 6 Apr 2009, Sean MacLennan wrote:
> > Now that leds-gpio is a proper OF platform driver, the Warp can use
> > the leds-gpio driver rather than the old out-of-kernel driver.
> >
> > One side-effect is the leds-gpio driver always turns the leds off
> > while the old driver left them alone. So we have to set them back to
> > the correct settings.
>
> Originally, I had the OF bindings support this feature, see
> http://article.gmane.org/gmane.linux.kernel/749094
>
> Maybe this would be a better way to do it? It avoids the glitch in
> the leds, is less code overall, and can be use by other devices that
> might want this same behavior.
Yes, that is a cleaner way to handle the LEDs. Do you know why this
patch wasn't accepted at the time? A quick google shows that Grant
Likely acked it.
The patch will no longer apply since default state does not exist.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] powerpc: Update Warp to use leds-gpio driver
From: Trent Piepho @ 2009-04-18 3:12 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090406175825.76bb969c__7633.03726348585$1239055251$gmane$org@lappy.seanm.ca>
On Mon, 6 Apr 2009, Sean MacLennan wrote:
> Now that leds-gpio is a proper OF platform driver, the Warp can use
> the leds-gpio driver rather than the old out-of-kernel driver.
>
> One side-effect is the leds-gpio driver always turns the leds off
> while the old driver left them alone. So we have to set them back to
> the correct settings.
Originally, I had the OF bindings support this feature, see
http://article.gmane.org/gmane.linux.kernel/749094
Maybe this would be a better way to do it? It avoids the glitch in the
leds, is less code overall, and can be use by other devices that might want
this same behavior.
^ permalink raw reply
* Re: mpc5200 and dma_ops
From: Jon Smirl @ 2009-04-18 1:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910904171758m1e09087fld63b28db1d0352c2@mail.gmail.com>
On Fri, Apr 17, 2009 at 8:58 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> Inside the ASoC code there a dma_alloc_coherent() call. This call is
> failing because dma_ops is null.
> --kernel BUG at /home/jonsmirl/fs/arch/powerpc/include/asm/dma-mapping.h:237!
> The device is soc-audio which is a platform_device.
>
> How do I get dma_ops filled in for a mpc5200 platform device?
That was a wild goose chase. If the device pointer is null it will
trigger this bug_on() which has nothing to do with the real problem.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* mpc5200 and dma_ops
From: Jon Smirl @ 2009-04-18 0:58 UTC (permalink / raw)
To: linuxppc-dev
Inside the ASoC code there a dma_alloc_coherent() call. This call is
failing because dma_ops is null.
--kernel BUG at /home/jonsmirl/fs/arch/powerpc/include/asm/dma-mapping.h:237!
The device is soc-audio which is a platform_device.
How do I get dma_ops filled in for a mpc5200 platform device?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Example dts file
From: David Gibson @ 2009-04-18 0:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eddie Dawydiuk
In-Reply-To: <fa686aa40904171012i7f67f6b6sae9a7fd4ff8e3807@mail.gmail.com>
On Fri, Apr 17, 2009 at 11:12:43AM -0600, Grant Likely wrote:
> On Fri, Apr 17, 2009 at 11:04 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
> > Hello,
> >
> > I'm working on creating a dts file for a custom board based on the Yosemite
> > AMCC 440EP evaluation board. We have an FPGA connected to the PCI bus, and
> > I'm a bit unsure how to describe this in the dts file. The FPGA implements
> > an SD card core, RTC core, Nand core... Can anyone point me to an example
> > dts file I can refer to?
>
> If it is attached to the PCI bus, then you don't need to describe it
> in the .dts file. PCI can reliably probe for devices. Your driver
> should know what devices are present based on the PCI vendor and
> device IDs.
However, for onboard PCI devices it's often necessary to have a node
giving at least the interrupt routing information, because this can't
generally be probed by PCI.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Update Warp to use leds-gpio driver
From: Sean MacLennan @ 2009-04-18 0:41 UTC (permalink / raw)
To: Josh Boyer, linuxppc-dev
In-Reply-To: <20090406175825.76bb969c@lappy.seanm.ca>
Any status update on this? The patch has actually been in use since
2.6.29. I wrote a stub LED driver that mimiced leds-gpio with the of
patch.
All I had to do when the leds-gpio of patch went in was drop the stub
driver.
I'd like to get this in then update the warp defconfig for 2.6.30.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
From: Sean MacLennan @ 2009-04-18 0:36 UTC (permalink / raw)
To: ben-linux; +Cc: Jean Delvare, linuxppc-dev
In-Reply-To: <20090202120159.2478d7af@lappy.seanm.ca>
Any update on the status of this patch? This patch was acked by Jean.
The patchwork entry is http://patchwork.ozlabs.org/patch/21576/ and the
original patch message is below.
Cheers,
Sean
On Mon, 2 Feb 2009 12:01:59 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> This is a trivial patch that does not need to be in 2.6.29. While
> tracking down an EEPROM problem, I found the messages confusing... it
> looked like the EEPROM was being started before the I2C driver!
>
> Here is an example:
>
> at24 0-0052: 512 byte 24c04 EEPROM (writable)
> ibm-iic ef600700.i2c: using standard (100 kHz) mode
> ad7414 0-004a: chip found
>
> It looks like the at24 starts first, then the i2c driver, then the
> ad7414. By moving the message to after the of scan, we always get the
> driver, then the devices.
>
> Cheers,
> Sean
>
> Print the i2c driver message before scanning for devices so that the
> logs show the driver, then the devices. Currently you can get
> device(s), driver, device(s).
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c
> b/drivers/i2c/busses/i2c-ibm_iic.c index 88f0db7..7fc0729 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -756,12 +756,12 @@ static int __devinit iic_probe(struct of_device
> *ofdev, goto error_cleanup;
> }
>
> - /* Now register all the child nodes */
> - of_register_i2c_devices(adap, np);
> -
> dev_info(&ofdev->dev, "using %s mode\n",
> dev->fast_mode ? "fast (400 kHz)" : "standard (100
> kHz)");
> + /* Now register all the child nodes */
> + of_register_i2c_devices(adap, np);
> +
> return 0;
>
> error_cleanup:
>
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Ilpo Järvinen @ 2009-04-17 22:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Michal Simek, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.64.0904171601020.10088@wrl-59.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4686 bytes --]
On Fri, 17 Apr 2009, Ilpo Järvinen wrote:
> On Fri, 17 Apr 2009, Michal Simek wrote:
>
> > Grant Likely wrote:
> > > On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wrote:
> > >> Hi All,
> > >>
> > >> I have got email from Ilpo about prom_parse file.
> > >> I take this file from powerpc. Who did write prom_parse file and take care about?
> > >
> > > Posting to the linuxppc-dev list is sufficient to start. There are
> > > several people who may be interested.
> > >
> > >> BTW: What about to move prom_parse file to any generic location as we discussed in past?
> > >> Any volunteer?
> > >
> > > I'm kind of working on it. More specifically, I'm looking at
> > > factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
> > > haven't made a whole lot of progress yet.
> > >
> > >> -------- Original Message --------
> > >> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
> > >> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
> > >> From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> > >> To: monstr@monstr.eu
> > >> CC: microblaze-uclinux@itee.uq.edu.au
> > >>
> > >> While some version of the patches were on the lkml I read
> > >> some part of the code briefly through but my feedback got
> > >> stuck into postponed emails, so here's one correctness
> > >> related issue I might have found (the rest were just
> > >> cosmetic things).
> > >>
> > >> I'm not sure if the latter return needs the of_node_put or not
> > >> but it seems more likely than not.
> > >
> > > Yes, it does. This change is applicable to
> > > arch/powerpc/kernel/prom_parse.c too.
> >
> > ok.
> > Ilpo: Can you create patch for both architectures?
>
> Sure, but tomorrow as today is a deadline day :-).
Ok, here's combined patch for both. I came up with slightly
shorter and (IMHO) nicer variant for -EINVAL assignment than
in the first version.
--
[PATCH] powerpc & microblaze: add missing of_node_put to error handling
While reviewing some microblaze patches a while ago, I noticed
a suspicious error handling in of_irq_map_one(), which turned
out to be a copy from arch/powerpc. Grant Likely
<grant.likely@secretlab.ca> confirmed that this is a real bug.
Merge error handling paths using goto with the normal return
path.
Powerppc compile tested.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
arch/microblaze/kernel/prom_parse.c | 11 +++++------
arch/powerpc/kernel/prom_parse.c | 11 +++++------
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c
index ae0352e..d16c32f 100644
--- a/arch/microblaze/kernel/prom_parse.c
+++ b/arch/microblaze/kernel/prom_parse.c
@@ -903,7 +903,7 @@ int of_irq_map_one(struct device_node *device,
struct device_node *p;
const u32 *intspec, *tmp, *addr;
u32 intsize, intlen;
- int res;
+ int res = -EINVAL;
pr_debug("of_irq_map_one: dev=%s, index=%d\n",
device->full_name, index);
@@ -926,21 +926,20 @@ int of_irq_map_one(struct device_node *device,
/* Get size of interrupt specifier */
tmp = of_get_property(p, "#interrupt-cells", NULL);
- if (tmp == NULL) {
- of_node_put(p);
- return -EINVAL;
- }
+ if (tmp == NULL)
+ goto out;
intsize = *tmp;
pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
/* Check index */
if ((index + 1) * intsize > intlen)
- return -EINVAL;
+ goto out;
/* Get new specifier and map it */
res = of_irq_map_raw(p, intspec + index * intsize, intsize,
addr, out_irq);
+out:
of_node_put(p);
return res;
}
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 8f0856f..8362620 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -971,7 +971,7 @@ int of_irq_map_one(struct device_node *device, int index, struct of_irq *out_irq
struct device_node *p;
const u32 *intspec, *tmp, *addr;
u32 intsize, intlen;
- int res;
+ int res = -EINVAL;
DBG("of_irq_map_one: dev=%s, index=%d\n", device->full_name, index);
@@ -995,21 +995,20 @@ int of_irq_map_one(struct device_node *device, int index, struct of_irq *out_irq
/* Get size of interrupt specifier */
tmp = of_get_property(p, "#interrupt-cells", NULL);
- if (tmp == NULL) {
- of_node_put(p);
- return -EINVAL;
- }
+ if (tmp == NULL)
+ goto out;
intsize = *tmp;
DBG(" intsize=%d intlen=%d\n", intsize, intlen);
/* Check index */
if ((index + 1) * intsize > intlen)
- return -EINVAL;
+ goto out;
/* Get new specifier and map it */
res = of_irq_map_raw(p, intspec + index * intsize, intsize,
addr, out_irq);
+out:
of_node_put(p);
return res;
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH] ucc_geth: Move freeing of TX packets to NAPI context
From: Anton Vorontsov @ 2009-04-17 22:03 UTC (permalink / raw)
To: David Miller
Cc: netdev, Li Yang, Andy Fleming, Joakim Tjernlund, linuxppc-dev
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
This will make the system alot more responsive while ping flooding the
ucc_geth ethernet interface.
Also set NAPI weight to 64 as this is a common value.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 31 +++++++++++--------------------
drivers/net/ucc_geth.h | 1 -
2 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d3f39e8..98f961e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3216,7 +3216,7 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
dev->stats.tx_packets++;
/* Free the sk buffer associated with this TxBD */
- dev_kfree_skb_irq(ugeth->
+ dev_kfree_skb(ugeth->
tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] = NULL;
ugeth->skb_dirtytx[txQ] =
@@ -3250,9 +3250,15 @@ static int ucc_geth_poll(struct napi_struct *napi, int budget)
for (i = 0; i < ug_info->numQueuesRx; i++)
howmany += ucc_geth_rx(ugeth, i, budget - howmany);
+ /* Tx event processing */
+ spin_lock(&ugeth->lock);
+ for (i = 0; i < ug_info->numQueuesTx; i++)
+ ucc_geth_tx(ugeth->ndev, i);
+ spin_unlock(&ugeth->lock);
+
if (howmany < budget) {
napi_complete(napi);
- setbits32(ugeth->uccf->p_uccm, UCCE_RX_EVENTS);
+ setbits32(ugeth->uccf->p_uccm, UCCE_RX_EVENTS | UCCE_TX_EVENTS);
}
return howmany;
@@ -3266,8 +3272,6 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
struct ucc_geth_info *ug_info;
register u32 ucce;
register u32 uccm;
- register u32 tx_mask;
- u8 i;
ugeth_vdbg("%s: IN", __func__);
@@ -3281,27 +3285,14 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
out_be32(uccf->p_ucce, ucce);
/* check for receive events that require processing */
- if (ucce & UCCE_RX_EVENTS) {
+ if (ucce & (UCCE_RX_EVENTS | UCCE_TX_EVENTS)) {
if (napi_schedule_prep(&ugeth->napi)) {
- uccm &= ~UCCE_RX_EVENTS;
+ uccm &= ~(UCCE_RX_EVENTS | UCCE_TX_EVENTS);
out_be32(uccf->p_uccm, uccm);
__napi_schedule(&ugeth->napi);
}
}
- /* Tx event processing */
- if (ucce & UCCE_TX_EVENTS) {
- spin_lock(&ugeth->lock);
- tx_mask = UCC_GETH_UCCE_TXB0;
- for (i = 0; i < ug_info->numQueuesTx; i++) {
- if (ucce & tx_mask)
- ucc_geth_tx(dev, i);
- ucce &= ~tx_mask;
- tx_mask <<= 1;
- }
- spin_unlock(&ugeth->lock);
- }
-
/* Errors and other events */
if (ucce & UCCE_OTHER) {
if (ucce & UCC_GETH_UCCE_BSY)
@@ -3734,7 +3725,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
dev->netdev_ops = &ucc_geth_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
INIT_WORK(&ugeth->timeout_work, ucc_geth_timeout_work);
- netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
+ netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, 64);
dev->mtu = 1500;
ugeth->msg_enable = netif_msg_init(debug.msg_enable, UGETH_MSG_DEFAULT);
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 2f8ee7c..6027647 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -852,7 +852,6 @@ struct ucc_geth_hardware_statistics {
/* Driver definitions */
#define TX_BD_RING_LEN 0x10
#define RX_BD_RING_LEN 0x10
-#define UCC_GETH_DEV_WEIGHT TX_BD_RING_LEN
#define TX_RING_MOD_MASK(size) (size-1)
#define RX_RING_MOD_MASK(size) (size-1)
--
1.6.2.2
^ permalink raw reply related
* Re: [v2 PATCH 2/3] EDAC: Add edac_device_alloc_index()
From: Doug Thompson @ 2009-04-17 21:42 UTC (permalink / raw)
To: Harry Ciao, Andrew Morton; +Cc: linuxppc-dev, bluesmoke-devel, linux-kernel
--- On Wed, 4/15/09, Andrew Morton <akpm@linux-foundation.org> wrote:=0A=0A=
> From: Andrew Morton <akpm@linux-foundation.org>=0A> Subject: Re: [v2 PATC=
H 2/3] EDAC: Add edac_device_alloc_index()=0A> To: "Harry Ciao" <qingtao.ca=
o@windriver.com>=0A> Cc: norsk5@yahoo.com, michael@ellerman.id.au, bluesmok=
e-devel@lists.sourceforge.net, linuxppc-dev@ozlabs.org, linux-kernel@vger.k=
ernel.org=0A> Date: Wednesday, April 15, 2009, 4:27 PM=0A> On Mon, 13 Apr 2=
009 14:05:15 +0800=0A> Harry Ciao <qingtao.cao@windriver.com>=0A> wrote:=0A=
> =0A> > Add edac_device_alloc_index(), because for MAPLE=0A> platform ther=
e may=0A> > exist several EDAC driver modules that could make use=0A> of=0A=
> > edac_device_ctl_info structure at the same time. The=0A> index allocati=
on=0A> > for these structures should be taken care of by EDAC=0A> core.=0A>=
> =0A> =0A> From: Andrew Morton <akpm@linux-foundation.org>=0A> =0A> keep =
things neat.=A0 Also avoids having global=0A> identifier device_index=0A> s=
hadowed by local identifier device_index.=0A> =0A> Cc: Benjamin Herrenschmi=
dt <benh@kernel.crashing.org>=0A=0AAcked-by: Doug Thompson <dougthompson@xm=
ission.com>=0A=0A> Cc: Harry Ciao <qingtao.cao@windriver.com>=0A> Cc: Kumar=
Gala <galak@gate.crashing.org>=0A> Cc: Michael Ellerman <michael@ellerman.=
id.au>=0A> Cc: Paul Mackerras <paulus@samba.org>=0A> Signed-off-by: Andrew =
Morton <akpm@linux-foundation.org>=0A> ---=0A> =0A> drivers/edac/edac_devi=
ce.c |=A0 =A0 3 ++-=0A> 1 file changed, 2 insertions(+), 1 deletion(-)=0A>=
=0A> diff -puN=0A> drivers/edac/amd8111_edac.c~edac-add-edac_device_alloc_=
index-cleanup=0A> drivers/edac/amd8111_edac.c=0A> diff -puN=0A> drivers/eda=
c/edac_core.h~edac-add-edac_device_alloc_index-cleanup=0A> drivers/edac/eda=
c_core.h=0A> diff -puN=0A> drivers/edac/edac_device.c~edac-add-edac_device_=
alloc_index-cleanup=0A> drivers/edac/edac_device.c=0A> ---=0A> a/drivers/ed=
ac/edac_device.c~edac-add-edac_device_alloc_index-cleanup=0A> +++ a/drivers=
/edac/edac_device.c=0A> @@ -37,7 +37,6 @@=0A> =A0 */=0A> static DEFINE_MUT=
EX(device_ctls_mutex);=0A> static LIST_HEAD(edac_device_list);=0A> -static=
atomic_t device_indexes =3D ATOMIC_INIT(0);=0A> =0A> #ifdef CONFIG_EDAC_=
DEBUG=0A> static void edac_device_dump_device(struct=0A> edac_device_ctl_i=
nfo *edac_dev)=0A> @@ -499,6 +498,8 @@ void=0A> edac_device_reset_delay_per=
iod(stru=0A> =A0 */=0A> int edac_device_alloc_index(void)=0A> {=0A> +=A0=
=A0=A0 static atomic_t device_indexes =3D=0A> ATOMIC_INIT(0);=0A> +=0A> =
=A0=A0=A0 return=0A> atomic_inc_return(&device_indexes) - 1;=0A> }=0A> EX=
PORT_SYMBOL_GPL(edac_device_alloc_index);=0A> _=0A> =0A>
^ permalink raw reply
* Re: PowerPC iotable_init equivalent?
From: Kumar Gala @ 2009-04-17 21:32 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49E8F2D7.3050603@embeddedarm.com>
On Apr 17, 2009, at 4:21 PM, Eddie Dawydiuk wrote:
> Hello,
>
> In the past I've worked with ARM architectures where I could setup
> virtual / physical address mappings so I don't have to ioremap then
> pass around pointers. Does PowerPC have an equivalent abstraction?
> If not whats the recommended approach?
>
> That is, is there a better approach to the following...
>
> volatile static unsigned char *my_reg = NULL;
>
> static inline void read_func() {
>
> if (!my_reg)
> my_reg = (unsigned char *)
> ioremap(REG_PHYS_BASE, REG_SIZE);
> //do something with the reg
> }
>
>
> static inline void write_func() {
>
> if (!my_reg)
> my_reg = (unsigned char *)
> ioremap(REG_PHYS_BASE, REG_SIZE);
> //do something with the reg
> }
Yes have a struct that keeps track of the virt addr and do the mapping
once at init time. This is what most drivers do.
- k
^ permalink raw reply
* Re: PowerPC iotable_init equivalent?
From: Roderick Colenbrander @ 2009-04-17 21:31 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49E8F2D7.3050603@embeddedarm.com>
On Fri, Apr 17, 2009 at 11:21 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wr=
ote:
> Hello,
>
> In the past I've worked with ARM architectures where I could setup virtua=
l /
> physical address mappings so I don't have to ioremap then pass around
> pointers. Does PowerPC have an equivalent abstraction? If not whats the
> recommended approach?
>
> That is, is there a better approach to the following...
>
> volatile static unsigned char *my_reg =3D NULL;
>
> static inline void read_func() {
>
> =A0 =A0 =A0 =A0if (!my_reg)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my_reg =3D (unsigned char *)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ioremap(REG_PHYS_BASE, REG=
_SIZE);
> //do something with the reg
> }
>
>
> static inline void write_func() {
>
> =A0 =A0 =A0 =A0if (!my_reg)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my_reg =3D (unsigned char *)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ioremap(REG_PHYS_BASE, REG=
_SIZE);
> //do something with the reg
> }
>
> --
> Best Regards,
> ________________________________________________________________
> =A0Eddie Dawydiuk, Technologic Systems | voice: =A0(480) 837-5200
> =A016525 East Laser Drive =A0 =A0 =A0 =A0 =A0 =A0 =A0| fax: =A0 =A0(480) =
837-5300
> =A0Fountain Hills, AZ 85268 =A0 =A0 =A0 =A0 =A0 =A0| web: www.embeddedARM=
.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
In general you set devices up a dts file. You can reach its contents
using openfirmware functions (of_*). In general you use an of_*
function to look up your periperhal in the device tree. Once you have
its node you would able to do e.g. of_iomap (which uses ioremap with
the right offsets behind its back) to map the device. So you don't
hard code physical addresses anymore in the code.
Regards,
Roderick Colenbrander
^ permalink raw reply
* PowerPC iotable_init equivalent?
From: Eddie Dawydiuk @ 2009-04-17 21:21 UTC (permalink / raw)
To: linuxppc-dev, Grant Likely
Hello,
In the past I've worked with ARM architectures where I could setup virtual /
physical address mappings so I don't have to ioremap then pass around pointers.
Does PowerPC have an equivalent abstraction? If not whats the recommended approach?
That is, is there a better approach to the following...
volatile static unsigned char *my_reg = NULL;
static inline void read_func() {
if (!my_reg)
my_reg = (unsigned char *)
ioremap(REG_PHYS_BASE, REG_SIZE);
//do something with the reg
}
static inline void write_func() {
if (!my_reg)
my_reg = (unsigned char *)
ioremap(REG_PHYS_BASE, REG_SIZE);
//do something with the reg
}
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 20:57 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Tirumala Reddy Marri, linuxppc-dev
In-Reply-To: <200904171550.19625.hollisb@us.ibm.com>
> -----Original Message-----
> From: Hollis Blanchard [mailto:hollisb@us.ibm.com] =
> Sent: Friday, April 17, 2009 2:50 PM
> To: John Linn
> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt; =
> linuxppc-dev@ozlabs.org; Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =
> On Friday 17 April 2009 15:30:45 John Linn wrote:
> > We think that we still need that conditional as the code is =
> not Oring in the =
> enable such that it would
> > disable external debug mode for the BDI. But we need it =
> this way for our =
> Xilinx pod.
> > =
> > #if !defined(CONFIG_BDI_SWITCH)
> > /*
> > * The Abatron BDI JTAG debugger does not =
> tolerate others
> > * mucking with the debug registers.
> > */
> > lis r2,DBCR0_IDM@h
> > mtspr SPRN_DBCR0,r2
> > isync
> > /* clear any residual debug events */
> > li r2,-1
> > mtspr SPRN_DBSR,r2
> > #endif
> =
> So change the code to OR in your bits. What's the problem?
The Xilinx pod uses external mode and we don't want it set when running
Linux on the board. It is targeted more to stand alone (non-OS)
applications with different debug requirements.
> =
> -- =
> Hollis Blanchard
> IBM Linux Technology Center
> =
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Josh Boyer @ 2009-04-17 20:54 UTC (permalink / raw)
To: John Linn; +Cc: Tirumala Reddy Marri, Hollis Blanchard, linuxppc-dev
In-Reply-To: <20090417204133.36D4EB80057@mail167-dub.bigfish.com>
On Fri, Apr 17, 2009 at 02:41:26PM -0600, John Linn wrote:
>
>
>> -----Original Message-----
>> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
>> Sent: Friday, April 17, 2009 2:36 PM
>> To: John Linn
>> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt;
>> linuxppc-dev@ozlabs.org; Hollis Blanchard; Tirumala Reddy Marri
>> Subject: Re: Question about DBCR0 initialization for 440
>>
>> On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
>> >> > Might be worth checking if external debug is enabled, and
>> >> override it
>> >> > only if it's not.
>> >>
>> >> ppc440x5_um.pdf says that both can be enabled.
>> >>
>> >
>> >The code that I started the thread with, from the fsl file,
>> has conditional for the BDI around it.
>> >
>> >We think that we still need that conditional as the code is
>> not Oring in the enable such that it would
>> >disable external debug mode for the BDI. But we need it this
>> way for our Xilinx pod.
>>
>> EDM is a read-only bit according to the docs I have. You
>> can't set it (or
>> clear it) at all. It's only set by external hardware.
>
>That's strange, my 440x4_um.pdf does not say it's read-only unless it's
>in some obscure place.
Gah. I think that was my mistake. I don't see that in x4 or x5 manuals, but
it came up on IRC.
josh
^ permalink raw reply
* [PATCH] [V5] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: John Linn @ 2009-04-17 20:51 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, linux-fbdev-devel, akonovalov,
adaplas, jwboyer
Cc: Suneel, John Linn
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Removed platform device support as both MicroBlaze and PowerPC
use device tree.
Previously, the dcr interface was assumed to be used in mmio mode,
and the register space of the dcr interface was precomputed and stuffed
into the device tree. This driver now makes use of the new dcr
infrastructure to represent the dcr interface. This enables the dcr
interface to be connected directly to a native dcr interface in a clean
way.
Added compatibility for ml507 dvi core.
Signed-off-by: Suneel <suneelg@xilinx.com>
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
V2 - cleanup based on review
V3 - update to be based on top of tree rather than Xilinx tree, sorry for the
confusion with this, update the name of the patch slightly to be more accurate
V4 - update based on Grant's comments to simplify it, the binding wasn't changed
as the conversation seemed to verify it's acceptable
V5 - I guess I didn't read the binding conversation thread well, my apologies,
it's now changed to not use the dcr-splb-slave-if property.
drivers/video/xilinxfb.c | 260 +++++++++++++++++++++-------------------------
1 files changed, 118 insertions(+), 142 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 40a3a2a..43db758 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -1,13 +1,13 @@
/*
- * xilinxfb.c
*
- * Xilinx TFT LCD frame buffer driver
+ * Xilinx TFT frame buffer driver
*
* Author: MontaVista Software, Inc.
* source@mvista.com
*
* 2002-2007 (c) MontaVista Software, Inc.
* 2007 (c) Secret Lab Technologies, Ltd.
+ * 2009 (c) Xilinx Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -24,33 +24,38 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/version.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#if defined(CONFIG_OF)
#include <linux/of_device.h>
#include <linux/of_platform.h>
-#endif
-#include <asm/io.h>
+#include <linux/io.h>
#include <linux/xilinxfb.h>
+#include <asm/dcr.h>
#define DRIVER_NAME "xilinxfb"
-#define DRIVER_DESCRIPTION "Xilinx TFT LCD frame buffer driver"
+
/*
* Xilinx calls it "PLB TFT LCD Controller" though it can also be used for
- * the VGA port on the Xilinx ML40x board. This is a hardware display controller
- * for a 640x480 resolution TFT or VGA screen.
+ * the VGA port on the Xilinx ML40x board. This is a hardware display
+ * controller for a TFT or VGA screen.
*
* The interface to the framebuffer is nice and simple. There are two
* control registers. The first tells the LCD interface where in memory
* the frame buffer is (only the 11 most significant bits are used, so
* don't start thinking about scrolling). The second allows the LCD to
* be turned on or off as well as rotated 180 degrees.
+ *
+ * In case of direct PLB access the second control register will be at
+ * an offset of 4 as compared to the DCR access where the offset is 1
+ * i.e. REG_CTRL. So this is taken care in the function
+ * xilinx_fb_out_be32 where it left shifts the offset 2 times in case of
+ * direct PLB access.
*/
#define NUM_REGS 2
#define REG_FB_ADDR 0
@@ -111,8 +116,14 @@ struct xilinxfb_drvdata {
struct fb_info info; /* FB driver info record */
- u32 regs_phys; /* phys. address of the control registers */
- u32 __iomem *regs; /* virt. address of the control registers */
+ phys_addr_t regs_phys; /* phys. address of the control
+ registers */
+ void __iomem *regs; /* virt. address of the control
+ registers */
+
+ dcr_host_t dcr_host;
+ unsigned int dcr_start;
+ unsigned int dcr_len;
void *fb_virt; /* virt. address of the frame buffer */
dma_addr_t fb_phys; /* phys. address of the frame buffer */
@@ -128,14 +139,18 @@ struct xilinxfb_drvdata {
container_of(_info, struct xilinxfb_drvdata, info)
/*
- * The LCD controller has DCR interface to its registers, but all
- * the boards and configurations the driver has been tested with
- * use opb2dcr bridge. So the registers are seen as memory mapped.
- * This macro is to make it simple to add the direct DCR access
- * when it's needed.
+ * The XPS TFT Controller can be accessed through PLB or DCR interface.
+ * To perform the read/write on the registers we need to check on
+ * which bus its connected and call the appropriate write API.
*/
-#define xilinx_fb_out_be32(driverdata, offset, val) \
- out_be32(driverdata->regs + offset, val)
+static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
+ u32 val)
+{
+ if (drvdata->regs)
+ out_be32(drvdata->regs + (offset << 2), val);
+ else
+ dcr_write(drvdata->dcr_host, offset, val);
+}
static int
xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
@@ -173,7 +188,8 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
switch (blank_mode) {
case FB_BLANK_UNBLANK:
/* turn on panel */
- xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata->reg_ctrl_default);
break;
case FB_BLANK_NORMAL:
@@ -189,8 +205,7 @@ xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
return 0; /* success */
}
-static struct fb_ops xilinxfb_ops =
-{
+static struct fb_ops xilinxfb_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = xilinx_fb_setcolreg,
.fb_blank = xilinx_fb_blank,
@@ -203,35 +218,34 @@ static struct fb_ops xilinxfb_ops =
* Bus independent setup/teardown
*/
-static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
+static int xilinxfb_assign(struct device *dev,
+ struct xilinxfb_drvdata *drvdata,
+ unsigned long physaddr,
struct xilinxfb_platform_data *pdata)
{
- struct xilinxfb_drvdata *drvdata;
int rc;
int fbsize = pdata->xvirt * pdata->yvirt * BYTES_PER_PIXEL;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(dev, "Couldn't allocate device private record\n");
- return -ENOMEM;
- }
- dev_set_drvdata(dev, drvdata);
-
- /* Map the control registers in */
- if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
- dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
- physaddr);
- rc = -ENODEV;
- goto err_region;
- }
- drvdata->regs_phys = physaddr;
- drvdata->regs = ioremap(physaddr, 8);
- if (!drvdata->regs) {
- dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
- physaddr);
- rc = -ENODEV;
- goto err_map;
+ if (physaddr) {
+ /*
+ * Map the control registers in if the controller
+ * is on direct PLB interface.
+ */
+ if (!request_mem_region(physaddr, 8, DRIVER_NAME)) {
+ dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+ physaddr);
+ rc = -ENODEV;
+ goto err_region;
+ }
+
+ drvdata->regs_phys = physaddr;
+ drvdata->regs = ioremap(physaddr, 8);
+ if (!drvdata->regs) {
+ dev_err(dev, "Couldn't lock memory region at 0x%08lX\n",
+ physaddr);
+ rc = -ENODEV;
+ goto err_map;
+ }
}
/* Allocate the framebuffer memory */
@@ -260,7 +274,8 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
drvdata->reg_ctrl_default = REG_CTRL_ENABLE;
if (pdata->rotate_screen)
drvdata->reg_ctrl_default |= REG_CTRL_ROTATE;
- xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+ xilinx_fb_out_be32(drvdata, REG_CTRL,
+ drvdata->reg_ctrl_default);
/* Fill struct fb_info */
drvdata->info.device = dev;
@@ -296,11 +311,14 @@ static int xilinxfb_assign(struct device *dev, unsigned long physaddr,
goto err_regfb;
}
+ if (drvdata->regs) {
+ /* Put a banner in the log (for DEBUG) */
+ dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr,
+ drvdata->regs);
+ }
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, "regs: phys=%lx, virt=%p\n", physaddr, drvdata->regs);
- dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
- (unsigned long long) drvdata->fb_phys, drvdata->fb_virt,
- fbsize);
+ dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
+ (void *)drvdata->fb_phys, drvdata->fb_virt, fbsize);
return 0; /* success */
@@ -311,14 +329,19 @@ err_cmap:
if (drvdata->fb_alloced)
dma_free_coherent(dev, PAGE_ALIGN(fbsize), drvdata->fb_virt,
drvdata->fb_phys);
+ else
+ iounmap(drvdata->fb_virt);
+
/* Turn off the display */
xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
err_fbmem:
- iounmap(drvdata->regs);
+ if (drvdata->regs)
+ iounmap(drvdata->regs);
err_map:
- release_mem_region(physaddr, 8);
+ if (physaddr)
+ release_mem_region(physaddr, 8);
err_region:
kfree(drvdata);
@@ -342,12 +365,18 @@ static int xilinxfb_release(struct device *dev)
if (drvdata->fb_alloced)
dma_free_coherent(dev, PAGE_ALIGN(drvdata->info.fix.smem_len),
drvdata->fb_virt, drvdata->fb_phys);
+ else
+ iounmap(drvdata->fb_virt);
/* Turn off the display */
xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
- iounmap(drvdata->regs);
- release_mem_region(drvdata->regs_phys, 8);
+ /* Release the resources, as allocated based on interface */
+ if (drvdata->regs) {
+ iounmap(drvdata->regs);
+ release_mem_region(drvdata->regs_phys, 8);
+ } else
+ dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
kfree(drvdata);
dev_set_drvdata(dev, NULL);
@@ -356,79 +385,25 @@ static int xilinxfb_release(struct device *dev)
}
/* ---------------------------------------------------------------------
- * Platform bus binding
- */
-
-static int
-xilinxfb_platform_probe(struct platform_device *pdev)
-{
- struct xilinxfb_platform_data *pdata;
- struct resource *res;
-
- /* Find the registers address */
- res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (!res) {
- dev_err(&pdev->dev, "Couldn't get registers resource\n");
- return -ENODEV;
- }
-
- /* If a pdata structure is provided, then extract the parameters */
- pdata = &xilinx_fb_default_pdata;
- if (pdev->dev.platform_data) {
- pdata = pdev->dev.platform_data;
- if (!pdata->xres)
- pdata->xres = xilinx_fb_default_pdata.xres;
- if (!pdata->yres)
- pdata->yres = xilinx_fb_default_pdata.yres;
- if (!pdata->xvirt)
- pdata->xvirt = xilinx_fb_default_pdata.xvirt;
- if (!pdata->yvirt)
- pdata->yvirt = xilinx_fb_default_pdata.yvirt;
- }
-
- return xilinxfb_assign(&pdev->dev, res->start, pdata);
-}
-
-static int
-xilinxfb_platform_remove(struct platform_device *pdev)
-{
- return xilinxfb_release(&pdev->dev);
-}
-
-
-static struct platform_driver xilinxfb_platform_driver = {
- .probe = xilinxfb_platform_probe,
- .remove = xilinxfb_platform_remove,
- .driver = {
- .owner = THIS_MODULE,
- .name = DRIVER_NAME,
- },
-};
-
-/* ---------------------------------------------------------------------
* OF bus binding
*/
-#if defined(CONFIG_OF)
static int __devinit
xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
{
- struct resource res;
const u32 *prop;
struct xilinxfb_platform_data pdata;
+ struct resource res;
int size, rc;
+ int start = 0, len = 0;
+ dcr_host_t dcr_host;
+ struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
pdata = xilinx_fb_default_pdata;
dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
- rc = of_address_to_resource(op->node, 0, &res);
- if (rc) {
- dev_err(&op->dev, "invalid address\n");
- return rc;
- }
-
prop = of_get_property(op->node, "phys-size", &size);
if ((prop) && (size >= sizeof(u32)*2)) {
pdata.screen_width_mm = prop[0];
@@ -450,7 +425,32 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
if (of_find_property(op->node, "rotate-display", NULL))
pdata.rotate_screen = 1;
- return xilinxfb_assign(&op->dev, res.start, &pdata);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(&op->dev, "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+ dev_set_drvdata(&op->dev, drvdata);
+
+ /* Check for a DCR interface 1st since it has a reg property also */
+ start = dcr_resource_start(op->node, 0);
+ len = dcr_resource_len(op->node, 0);
+ dcr_host = dcr_map(op->node, start, len);
+ if ((start != 0) && (len != 0)) {
+ drvdata->dcr_start = start;
+ drvdata->dcr_len = len;
+ drvdata->dcr_host = dcr_host;
+ return xilinxfb_assign(&op->dev, drvdata, 0, &pdata);
+ }
+
+ /* It wasn't a DCR interface, so it must be PLB */
+ rc = of_address_to_resource(op->node, 0, &res);
+ if (rc) {
+ dev_err(&op->dev, "invalid address\n");
+ return -ENODEV;
+ }
+ return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
}
static int __devexit xilinxfb_of_remove(struct of_device *op)
@@ -460,7 +460,9 @@ static int __devexit xilinxfb_of_remove(struct of_device *op)
/* Match table for of_platform binding */
static struct of_device_id xilinxfb_of_match[] __devinitdata = {
+ { .compatible = "xlnx,xps-tft-1.00.a", },
{ .compatible = "xlnx,plb-tft-cntlr-ref-1.00.a", },
+ { .compatible = "xlnx,plb-dvi-cntlr-ref-1.00.c", },
{},
};
MODULE_DEVICE_TABLE(of, xilinxfb_of_match);
@@ -476,22 +478,6 @@ static struct of_platform_driver xilinxfb_of_driver = {
},
};
-/* Registration helpers to keep the number of #ifdefs to a minimum */
-static inline int __init xilinxfb_of_register(void)
-{
- pr_debug("xilinxfb: calling of_register_platform_driver()\n");
- return of_register_platform_driver(&xilinxfb_of_driver);
-}
-
-static inline void __exit xilinxfb_of_unregister(void)
-{
- of_unregister_platform_driver(&xilinxfb_of_driver);
-}
-#else /* CONFIG_OF */
-/* CONFIG_OF not enabled; do nothing helpers */
-static inline int __init xilinxfb_of_register(void) { return 0; }
-static inline void __exit xilinxfb_of_unregister(void) { }
-#endif /* CONFIG_OF */
/* ---------------------------------------------------------------------
* Module setup and teardown
@@ -500,28 +486,18 @@ static inline void __exit xilinxfb_of_unregister(void) { }
static int __init
xilinxfb_init(void)
{
- int rc;
- rc = xilinxfb_of_register();
- if (rc)
- return rc;
-
- rc = platform_driver_register(&xilinxfb_platform_driver);
- if (rc)
- xilinxfb_of_unregister();
-
- return rc;
+ return of_register_platform_driver(&xilinxfb_of_driver);
}
static void __exit
xilinxfb_cleanup(void)
{
- platform_driver_unregister(&xilinxfb_platform_driver);
- xilinxfb_of_unregister();
+ of_unregister_platform_driver(&xilinxfb_of_driver);
}
module_init(xilinxfb_init);
module_exit(xilinxfb_cleanup);
MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
-MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
+MODULE_DESCRIPTION("Xilinx TFT frame buffer driver");
MODULE_LICENSE("GPL");
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: Question about DBCR0 initialization for 440
From: Hollis Blanchard @ 2009-04-17 20:50 UTC (permalink / raw)
To: John Linn; +Cc: Tirumala Reddy Marri, linuxppc-dev
In-Reply-To: <20090417203053.1D692F88052@mail119-dub.bigfish.com>
On Friday 17 April 2009 15:30:45 John Linn wrote:
> We think that we still need that conditional as the code is not Oring in the
enable such that it would
> disable external debug mode for the BDI. But we need it this way for our
Xilinx pod.
>
> #if !defined(CONFIG_BDI_SWITCH)
> /*
> * The Abatron BDI JTAG debugger does not tolerate others
> * mucking with the debug registers.
> */
> lis r2,DBCR0_IDM@h
> mtspr SPRN_DBCR0,r2
> isync
> /* clear any residual debug events */
> li r2,-1
> mtspr SPRN_DBSR,r2
> #endif
So change the code to OR in your bits. What's the problem?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 20:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: Tirumala Reddy Marri, Hollis Blanchard, linuxppc-dev
In-Reply-To: <20090417203531.GB3776@zod.rchland.ibm.com>
=
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com] =
> Sent: Friday, April 17, 2009 2:36 PM
> To: John Linn
> Cc: grant.likely@secretlab.ca; Benjamin Herrenschmidt; =
> linuxppc-dev@ozlabs.org; Hollis Blanchard; Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =
> On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
> >> > Might be worth checking if external debug is enabled, and =
> >> override it
> >> > only if it's not.
> >> =
> >> ppc440x5_um.pdf says that both can be enabled.
> >> =
> >
> >The code that I started the thread with, from the fsl file, =
> has conditional for the BDI around it.
> >
> >We think that we still need that conditional as the code is =
> not Oring in the enable such that it would
> >disable external debug mode for the BDI. But we need it this =
> way for our Xilinx pod.
> =
> EDM is a read-only bit according to the docs I have. You =
> can't set it (or
> clear it) at all. It's only set by external hardware.
That's strange, my 440x4_um.pdf does not say it's read-only unless it's
in some obscure place.
> =
> josh
> =
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Question about DBCR0 initialization for 440
From: Josh Boyer @ 2009-04-17 20:35 UTC (permalink / raw)
To: John Linn; +Cc: Tirumala Reddy Marri, Hollis Blanchard, linuxppc-dev
In-Reply-To: <20090417203053.1D692F88052@mail119-dub.bigfish.com>
On Fri, Apr 17, 2009 at 02:30:45PM -0600, John Linn wrote:
>> > Might be worth checking if external debug is enabled, and
>> override it
>> > only if it's not.
>>
>> ppc440x5_um.pdf says that both can be enabled.
>>
>
>The code that I started the thread with, from the fsl file, has conditional for the BDI around it.
>
>We think that we still need that conditional as the code is not Oring in the enable such that it would
>disable external debug mode for the BDI. But we need it this way for our Xilinx pod.
EDM is a read-only bit according to the docs I have. You can't set it (or
clear it) at all. It's only set by external hardware.
josh
^ permalink raw reply
* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 20:30 UTC (permalink / raw)
To: Grant Likely, Benjamin Herrenschmidt
Cc: linuxppc-dev, Hollis Blanchard, Tirumala Reddy Marri
In-Reply-To: <fa686aa40904171210y56835f98jfa4f3e08d97930aa@mail.gmail.com>
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca] =
> Sent: Friday, April 17, 2009 1:10 PM
> To: Benjamin Herrenschmidt
> Cc: Hollis Blanchard; linuxppc-dev@ozlabs.org; John Linn; =
> Tirumala Reddy Marri
> Subject: Re: Question about DBCR0 initialization for 440
> =
> On Fri, Apr 17, 2009 at 1:04 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Fri, 2009-04-17 at 13:07 -0500, Hollis Blanchard wrote:
> >> On Friday 17 April 2009 12:22:37 Josh Boyer wrote:
> >> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn =
> <John.Linn@xilinx.com> wrote:
> >> > > Josh, any thoughts on putting this into head_44x.S?
> >> >
> >> > The code in the fsl file looks like the right solution. =A0
I do have an
> >> > odd question though, in that it's hard for the
> >> > kernel to really know if something like a BDI is =
> running. =A0Namely,
> >> > that config option doesn't cover RiscWatch in an obvious manner.
> >>
> >> Yeah, setting DBCR0 would interfere with all JTAG probes. =
> The ifdef meands you
> >> can't support both a JTAG debugger and hardware =
> breakpoints in the same
> >> binary? Now that's an annoying restriction.
> >
> > Might be worth checking if external debug is enabled, and =
> override it
> > only if it's not.
> =
> ppc440x5_um.pdf says that both can be enabled.
> =
The code that I started the thread with, from the fsl file, has conditional=
for the BDI around it.
We think that we still need that conditional as the code is not Oring in th=
e enable such that it would
disable external debug mode for the BDI. But we need it this way for our Xi=
linx pod.
#if !defined(CONFIG_BDI_SWITCH)
/*
* The Abatron BDI JTAG debugger does not tolerate others
* mucking with the debug registers.
*/
lis r2,DBCR0_IDM@h
mtspr SPRN_DBCR0,r2
isync
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
#endif =
> g.
> =
> -- =
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> =
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [ELDK] ELDK / U-Boot on the Emerson Network Power mvme5100
From: Wolfgang Denk @ 2009-04-17 20:22 UTC (permalink / raw)
To: Kirby Cartwright; +Cc: linuxppc-dev@ozlabs.org, eldk@lists.denx.de
In-Reply-To: <716D25C422F36949847885F3D11CA0DB387DFCC759@postoffice.lintek.local>
Dear Kirby Cartwright,
In message <716D25C422F36949847885F3D11CA0DB387DFCC755@postoffice.lintek.local> you wrote:
>
> Does anyone know of a BSP or board directory or configuration for the ELDK
> and especially U-Boot on the mvme5100.
Patches to fix MVME5100 support in 2.6.5 have been posted on lkml
some 5 years ago; I gues the board is dead since.
> I have searched the ELDK and LinuxPPC mailing lists and have not found anything
> yet.
Let me know if you need help to revive that old code...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is not best to swap horses while crossing the river.
- Abraham Lincoln
^ permalink raw reply
* [PATCH] powerpc: adjust oprofile_cpu_type
From: Mike Wolf @ 2009-04-17 19:48 UTC (permalink / raw)
To: linuxppc-dev
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-power<x>, oprofile will go to family naming
convention and use compat-v<x>. Currently only compat-v1 will be
defined.
Signed off by: Mike Wolf <mjw@linux.vnet.ibm.com>
---
--- mainline.orig/arch/powerpc/kernel/cputable.c 2009-04-16
09:47:49.000000000 -0500
+++ mainline/arch/powerpc/kernel/cputable.c 2009-04-16
14:28:28.000000000 -0500
@@ -382,7 +382,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power5+",
+ .oprofile_cpu_type = "ppc64/compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
},
{ /* Power6 */
@@ -416,7 +417,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power6",
+ .oprofile_cpu_type = "ppc64/compat-v1",
+ .oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power6",
},
{ /* 2.06-compliant processor, i.e. Power7 "architected" mode */
@@ -429,7 +431,8 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.machine_check = machine_check_generic,
- .oprofile_cpu_type = "ppc64/compat-power7",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_cpu_type = "ppc64/compat-v1",
.platform = "power7",
},
{ /* Power7 */
@@ -1833,8 +1836,10 @@
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (old.oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL) {
t->oprofile_cpu_type = s->oprofile_cpu_type;
+ t->oprofile_type = s->oprofile_type;
+ }
}
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
^ permalink raw reply
* RE: Question about DBCR0 initialization for 440
From: John Linn @ 2009-04-17 18:58 UTC (permalink / raw)
To: Grant Likely, Josh Boyer; +Cc: linuxppc-dev, hollisb, Tirumala Reddy Marri
In-Reply-To: <fa686aa40904171157x207d6493v9a37e2d8c61113d3@mail.gmail.com>
Thanks everyone, will do.
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Friday, April 17, 2009 12:58 PM
> To: Josh Boyer
> Cc: John Linn; Tirumala Reddy Marri; linuxppc-dev@ozlabs.org; hollisb@us.=
ibm.com
> Subject: Re: Question about DBCR0 initialization for 440
> =
> Hey John
> =
> We just discussed this on IRC. Go ahead and generate a patch to
> unconditionally turn on DBCR0[IDM] in head_44x.S. Don't even bother
> wrapping it in an #ifdef CONFIG_somthing block. It should be safe,
> but we'll throw it into -next and see if anyone complains. If it does
> cause problems, then it can be reworked to something a wee bit more
> conservative.
> =
> g.
> =
> On Fri, Apr 17, 2009 at 11:22 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com>=
wrote:
> > On Fri, Apr 17, 2009 at 11:46 AM, John Linn <John.Linn@xilinx.com> wrot=
e:
> >> Josh, any thoughts on putting this into head_44x.S?
> >
> > The code in the fsl file looks like the right solution. =A0I do have an=
> > odd question though, in that it's hard for the
> > kernel to really know if something like a BDI is running. =A0Namely,
> > that config option doesn't cover RiscWatch in an obvious manner.
> >
> > I also wonder if it's possible to have a host system be setting those
> > registers in a guest KVM system so the guest could be debugged with
> > gdb... =A0Hollis, any idea on that?
> >
> > josh
> >
> =
> =
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ 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