* Re: [PATCH 1/2] cdma-netreg: Add various cdma-netreg watches
From: Guillaume Zajac @ 2011-10-31 14:55 UTC (permalink / raw)
To: ofono
In-Reply-To: <4EACFA2D.70902@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Denis,
On 30/10/2011 08:18, Denis Kenzior wrote:
> Hi Guillaume,
>
> On 10/20/2011 10:41 AM, Guillaume Zajac wrote:
>> ---
>> include/cdma-netreg.h | 1 +
>> src/cdma-netreg.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++
>> src/ofono.h | 13 +++++++++++
>> 3 files changed, 72 insertions(+), 0 deletions(-)
>>
> Please follow patch submission guidelines outlined in HACKING. Namely
> the include/ changes should be in a separate patch.
Ok sorry for that.
> I cherry picked the chunks dealing with ofono_cdma_netreg_get_status and
> pushed them upstream.
Kind regards,
Guillaume
^ permalink raw reply
* [Qemu-devel] [PATCH] Error check find_ram_offset
From: Alex Williamson @ 2011-10-31 14:54 UTC (permalink / raw)
To: qemu-devel; +Cc: alex.williamson, armbru
Spotted via code review, we initialize offset to 0 to avoid a
compiler warning, but in the unlikely case that offset is
never set to something else, we should abort instead of return
a value that will almost certainly cause problems.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
exec.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 9dc4edb..70f6fb8 100644
--- a/exec.c
+++ b/exec.c
@@ -2874,7 +2874,7 @@ static void *file_ram_alloc(RAMBlock *block,
static ram_addr_t find_ram_offset(ram_addr_t size)
{
RAMBlock *block, *next_block;
- ram_addr_t offset = 0, mingap = RAM_ADDR_MAX;
+ ram_addr_t offset = RAM_ADDR_MAX, mingap = RAM_ADDR_MAX;
if (QLIST_EMPTY(&ram_list.blocks))
return 0;
@@ -2890,10 +2890,17 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
}
}
if (next - end >= size && next - end < mingap) {
- offset = end;
+ offset = end;
mingap = next - end;
}
}
+
+ if (offset == RAM_ADDR_MAX) {
+ fprintf(stderr, "Failed to find gap of requested size: %" PRIu64 "\n",
+ (uint64_t)size);
+ abort();
+ }
+
return offset;
}
^ permalink raw reply related
* Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Luiz Augusto von Dentz @ 2011-10-31 14:53 UTC (permalink / raw)
To: Ajay Pillai
Cc: Anderson Lizardo, Ganir, Chen, Mat Martineau, Claudio Takahasi,
linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
ingas@codeaurora.org
In-Reply-To: <8DCFA6B89B9E70418E47A2348D55495A4790C33B@banasiexm01.ASIA.ROOT.PRI>
Hi,
On Mon, Oct 31, 2011 at 3:35 PM, Ajay Pillai <Ajay.Pillai@csr.com> wrote:
> Hi Anderson,
> Hello Chen,
>
>> What about writing the value? Should we allow the user to set the value with either Write request/Write Command/Write signed or do we >really want to keep that internal (like read/read blob) ?
>
>>Again, If I were to implement it, I would stick with the core spec requirements, and checking Characteristic Properties and the link >encryption status for deciding which operation to use. But if you really think it is useful to allow D-Bus clients "break" spec >requirements some times, you can provide this control. This particular detail is not my main concern :).
>
>
> Can we detail out the "write" API design once again, please? There has been too much discussion and hence I am not sure, which way it is going.
>
> There are two main aspects to write"
>
> 1) The write mechanism -
> a) Do we do a setproperty() or do we add a new API writeValue()?
> b) Is the method blocking or non-blocking?
> c) If non-blocking,what is the mechanism like?
> My understanding - if the write is called while the connection is not active, then the value is going to be buffered in BlueZ while BlueZ tries to get the connection up. When the connection comes up, after the write operation is complete, BlueZ will emit a signal indicating that it is written.
Do you guys really know what you are talking about? D-Bus does not
support blocking calls, it basically waits the reply to return but it
can get other messages while waiting which will be reorder to be
dispatched after, so using pseudo blocking calls on production
software is _not_ recommended. Besides we will always have to signal
if there are multiple application watching the same characteristic,
the user of SetProperty can use that to catch when the value was
finally written but if an error occur then it is better to handle the
return of SetProperty, or actually a method like Write would be better
in this case so that a method can be given and an error can be
returned. (btw this was part of Chen's initial suggestion).
> 2) The choice of write operation - Does it lie within BlueZ or is it given to DBUS Apps. I guess Anderson is okay with giving some control to the DBUS App.
> a) write without response, write with response, signed write without response -
> I believe the DBUS App must be allowed to indicate its preference among these to BlueZ. BlueZ must be able to meet this preference in most of the cases, but in cases where it cannot, BlueZ must throw an error. It would in most cases be a wrong request from App (using signed write on a long characteristic, for instance)
> b) Write long characteristics value
> This, I believe, is a value add to Apps, if done autonomously within BlueZ.
> c) reliable write of one characteristic
> Not covered in this discussion so far. But worth having a separate API like writeReliable(offset, value, {"prepare","execute"})?
> d) reliable write used for atomic write of multiple characteristics
> Not covered in this discussion so far. Same API as above. But an "execute" operation on any char object will do complete the reliable write operation.
>
> Regarding reliable writes, we will need to figure out a state machine within BlueZ that blocks out other operations on a remote server during a prepare-execute cycle and also an exit criteria from that "block-other-operations" state to cater to Aps that disappear after doing a "prepare".
You guys do realize D-Bus is an IPC so that round trips are expensive
and does follow some standards when defining API, also blocking
operations/returning errors is probably a bad idea we should probably
queue the operation and send when the server is no longer busy.
So IMO we basically need Read/Write methods, those need a connection
and do not access the cache but they do always need to update the
cache and emit PropertyChanged when the value has changed so Value
property must stay so that GetProperties can be used as a lazy read
which is very useful in case the characteristic doesn't change or the
server notify its updates. Read method can be use to keep values in
sync with the server, but keep in mind that polling will always have a
interval where the value is not in sync so notification should be
always preferable.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [Buildroot] [Bug 4429] buildroot 2011.08 does not build on Ubuntu 11.10
From: Michael S. Zick @ 2011-10-31 14:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111031140530.94A078F3E2@busybox.osuosl.org>
On Mon October 31 2011, bugzilla at busybox.net wrote:
> https://bugs.busybox.net/show_bug.cgi?id=4429
>
> --- Comment #3 from Robert Berger <busybox@reliableembeddedsystems.com> 2011-10-31 14:05:30 UTC ---
> When I'm __not__ running screen or byubo, but, just ssh to a machine:
>
> echo $SHELL
> /bin/bash
>
> it compiles.
>
> ---------------------------
>
> When I'm running byubo (and bash)
>
> echo $SHELL
> /bin/bash
>
> it breaks with the funny errors from above.
>
Check the environment(s) in each case, like:
set | less
and compare them.
Here, on various different installations, I can
see a lot of differences.
Each of ssh/screen/byobu modifies and 'filters'
environment settings in their own way.
You might find something modified in the environment
settings that is causing the problems.
Also take note about file ownership(s) not being what
you might expect in some uses of byobu that is mentioned
in their documentation.
Mike
^ permalink raw reply
* [Bug 42435] Suspected loss of varyings between shaders
From: bugzilla-daemon @ 2011-10-31 14:50 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42435-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #2 from Alexander Sabourenkov <screwdriver@lxnt.info> 2011-10-31 07:50:58 PDT ---
core did not fit: >3000K size
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [lm-sensors] max1111 doesn't implement the standard sysfs
From: Eric Miao @ 2011-10-31 14:50 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031141642.0ed2ccc1@endymion.delvare>
Hi Jean,
Sorry for the non-standard interfaces. I'll work on that soon.
- eric
On Mon, Oct 31, 2011 at 9:18 PM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Eric,
>
> It was pointed to me that the max1111 driver doesn't implement the
> standard sysfs interface for hwmon drivers (as described in
> Documentation/hwmon/sysfs-interface). It exports files adc[0-3]_in, which
> aren't part of the standard interface. Presumably these should be
> renamed to in[0-3]_input. Renaming them is probably not sufficient
> though, as I see no scaling done in the driver. As the MAX1111 chip has
> a documented full scale of 2.048V, I take it that the LSB of the ADC
> has a weight of 8 mV. Exporting raw register values to user-space is
> not OK.
>
> So I would appreciate a fixup patch quickly. Otherwise we'll have to
> remove the max1111 driver completely, so that it doesn't get used as a
> (bad) example by other driver authors [1]. I'm sorry I did not spot the
> problem when reviewing the driver originally.
>
> [1] http://lists.lm-sensors.org/pipermail/lm-sensors/2011-October/034070.html
>
> --
> Jean Delvare
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* (unknown),
From: ygardi @ 2011-10-31 14:47 UTC (permalink / raw)
To: to; +Cc: a_ygardi
subscribe linux-mmc
thanks,
Yaniv
^ permalink raw reply
* [U-Boot] [PATCH] miiphy: Note that miiphy_* API is deprecated
From: Andy Fleming @ 2011-10-31 14:46 UTC (permalink / raw)
To: u-boot
We want to move everything to phylib, and we definitely don't want
new drivers using the miiphy infrastructure.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
common/miiphyutil.c | 10 ++++++++++
doc/feature-removal-schedule.txt | 11 +++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/common/miiphyutil.c b/common/miiphyutil.c
index 35ad357..2cc23b4 100644
--- a/common/miiphyutil.c
+++ b/common/miiphyutil.c
@@ -102,6 +102,7 @@ static int legacy_miiphy_write(struct mii_dev *bus, int addr, int devad,
/*****************************************************************************
*
* Register read and write MII access routines for the device <name>.
+ * This API is now deprecated. Please use mdio_alloc and mdio_register, instead.
*/
void miiphy_register(const char *name,
int (*read)(const char *devname, unsigned char addr,
@@ -281,6 +282,8 @@ static struct mii_dev *miiphy_get_active_dev(const char *devname)
* Read to variable <value> from the PHY attached to device <devname>,
* use PHY address <addr> and register <reg>.
*
+ * This API is deprecated. Use phy_read on a phy_device found via phy_connect
+ *
* Returns:
* 0 on success
*/
@@ -307,6 +310,8 @@ int miiphy_read(const char *devname, unsigned char addr, unsigned char reg,
* Write <value> to the PHY attached to device <devname>,
* use PHY address <addr> and register <reg>.
*
+ * This API is deprecated. Use phy_write on a phy_device found by phy_connect
+ *
* Returns:
* 0 on success
*/
@@ -350,6 +355,8 @@ void miiphy_listdev(void)
* Model: 6 bits (unsigned char)
* Revision: 4 bits (unsigned char)
*
+ * This API is deprecated.
+ *
* Returns:
* 0 on success
*/
@@ -389,6 +396,9 @@ int miiphy_info(const char *devname, unsigned char addr, unsigned int *oui,
/*****************************************************************************
*
* Reset the PHY.
+ *
+ * This API is deprecated. Use PHYLIB.
+ *
* Returns:
* 0 on success
*/
diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt
index 00d87e4..e04ba2d 100644
--- a/doc/feature-removal-schedule.txt
+++ b/doc/feature-removal-schedule.txt
@@ -7,6 +7,17 @@ file.
---------------------------
+What: Users of the legacy miiphy_* code
+When: undetermined
+
+Why: We now have a PHY library, which allows everyone to share PHY
+ drivers. All new drivers should use this infrastructure, and
+ all old drivers should get converted to use it.
+
+Who: Andy Fleming <afleming@freescale.com> and driver maintainers
+
+---------------------------
+
What: boards with xxx_config targets in top level Makefile
When: Release v2012.03
--
1.7.3.4
^ permalink raw reply related
* Re: [ANNOUNCE] xf86-video-intel 2.16.901
From: Chris Wilson @ 2011-10-31 14:45 UTC (permalink / raw)
To: Chun-Yu Shei, intel-gfx
In-Reply-To: <4EADDE00.9050806@cs.indiana.edu>
On Sun, 30 Oct 2011 19:30:08 -0400, Chun-Yu Shei <cshei@cs.indiana.edu> wrote:
> I had to disable sna in 2.16.0 when running compiz or I'd get some
> graphics corruption, and the problem seems to still exist in 2.16.901 as
> well. Here's a screenshot I just took on the RC with sna enabled:
> http://i.imgur.com/UtQpv.png
>
> I'm on a ThinkPad X220 (i5-2540M) running Gentoo with the following:
>
> pixman 0.23.6
> mesa 7.11
> libdrm 2.4.26
> xorg-server 1.10.4
>
> Similar reports:
>
> http://forums.gentoo.org/viewtopic-t-890280-highlight-sna.html
> http://forums.gentoo.org/viewtopic-t-898012-highlight-sna.html
>
> Is there anything I can do to help track this down?
There's a few known Composite bugs in the Xserver that affect SNA in
particular. Look forward to the xorg-1.12 release with hope.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Rabin Vincent @ 2011-10-31 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031143904.GM19187@n2100.arm.linux.org.uk>
On Mon, Oct 31, 2011 at 20:09, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 31, 2011 at 08:03:26PM +0530, Rabin Vincent wrote:
>> The above patch will apply with gnu patch if you use -p0.
>
> $ patch -p0 -i arch_reset-1.diff --dry-run
> patch: **** rejecting absolute target file name: /tmp/cocci-output-380-f841cc-system.h
Works for me, maybe a version difference?
~/kernel/arm$ cat arch_reset-1.diff | head
--- arch/arm/mach-ep93xx/include/mach/system.h 2011-10-31
20:11:04.496237799 +0530
+++ /tmp/cocci-output-3559-9e5748-system.h 2011-10-31 20:12:08.120235486 +0530
@@ -11,8 +11,6 @@ static inline void arch_idle(void)
static inline void arch_reset(char mode, const char *cmd)
{
- local_irq_disable();
-
/*
* Set then clear the SWRST bit to initiate a software reset
~/kernel/arm$ patch -p0 -i arch_reset-1.diff --dry-run
patching file arch/arm/mach-ep93xx/include/mach/system.h
patching file arch/arm/mach-iop32x/include/mach/system.h
patching file arch/arm/mach-ixp2000/include/mach/system.h
~/kernel/arm$ patch --version
patch 2.6.1
Copyright (C) 1988 Larry Wall
Copyright (C) 2003, 2009 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
written by Larry Wall and Paul Eggert
~/kernel/arm$
^ permalink raw reply
* [U-Boot] [PATCH 3/7] omap/spl: actually enable the console
From: Tom Rini @ 2011-10-31 14:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE970D.5020900@emcraft.com>
On Mon, Oct 31, 2011 at 5:39 AM, Ilya Yanok <yanok@emcraft.com> wrote:
> Hi Tom,
>
>>> Currently OMAP SPL code does all the initialization but does not set the
>>> gd->have_console value so no output is actually performed. This patch
>>> sets gd->have_console to 1 if CONFIG_SPL_CONSOLE is defined.
>>>
>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>
>> So, this is because of a behavior change. ?Do we want an SPL_CONSOLE variable?
>> Or should we just bring back the previous behavior? ?I kind of think
>> the previous
>> behavior... ?Others?
>
> So what will be your decision? Should I remove SPL_CONSOLE and repost
> the patch? Or should I drop it completely?
I would say just drop the #ifdef part.
--
Tom
^ permalink raw reply
* [U-Boot] [PATCH 2/7] omap/spl: don't assume u-boot.bin size, use CONFIG_SYS_NAND_U_BOOT_SIZE
From: Tom Rini @ 2011-10-31 14:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE96D1.1080507@emcraft.com>
On Mon, Oct 31, 2011 at 5:38 AM, Ilya Yanok <yanok@emcraft.com> wrote:
> Hi Tom, All,
>
> On 18.10.2011 03:43, Tom Rini wrote:
>>> Don't hardcode u-boot.bin size for the case where mkimage signature is
>>> missing, use CONFIG_SYS_NAND_U_BOOT_SIZE for this.
>>>
>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>
> So what about this patch? Should I drop it?
That would be my vote, but I don't have a MAINTAINER hat anywhere here ;)
--
Tom
^ permalink raw reply
* [Bug 42435] Suspected loss of varyings between shaders
From: bugzilla-daemon @ 2011-10-31 14:43 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-42435-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42435
--- Comment #1 from Alexander Sabourenkov <screwdriver@lxnt.info> 2011-10-31 07:43:44 PDT ---
Created attachment 52954
--> https://bugs.freedesktop.org/attachment.cgi?id=52954
Test case and stuff
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: couple questions about cleaning up the Quick Start Guide
From: Rifenbark, Scott M @ 2011-10-31 14:43 UTC (permalink / raw)
To: Robert P. J. Day, Yocto discussion list
In-Reply-To: <alpine.DEB.2.02.1110301030050.32341@localhost6.localdomain6>
Robert,
Thanks for the stuff and the look here. Regarding your first point - I don't have a problem using the real link over the redirect. The only things that come to mind are if they work why change them? But, if the community wants the downloads.yoctoproject.org/releases URL in there I can certainly go in and make changes to master.
On the second point - you are absolutely correct here. I will fix that in master to reflect where the tarball really is. I think as the project moves forward there will be more consistency. Early life jitters I guess :)
Thanks for your input.
Scott
-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Robert P. J. Day
Sent: Sunday, October 30, 2011 7:34 AM
To: Yocto discussion list
Subject: [yocto] couple questions about cleaning up the Quick Start Guide
perusing the QS guide in prep for giving a yocto talk this week to
my local LUG and some cosmetic changes i can submit a patch for:
1) www.yoctoproject.org/downloads clearly redirects to
downloads.yoctoproject.org/releases these days. any objection
to my just changing the former references to the latter throughout
the QS guide?
2) there's a reference to the edison tarball
http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
but there's no such tarball, it's at
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
although *older* tarballs are under the "downloads" directory.
what's the proper directory location for this stuff? can it be made
consistent? thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply
* [Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
From: bugzilla-daemon @ 2011-10-31 14:43 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-41592-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=41592
--- Comment #16 from mirandir@orange.fr 2011-10-31 07:43:07 PDT ---
Thanks for the link.
You are right, this problem seems very very close to mine.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] dma: Avoid reentrancy in DMA transfer handlers
From: Kevin Wolf @ 2011-10-31 14:46 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4EAAD9B4.7040206@redhat.com>
Am 28.10.2011 18:35, schrieb Paolo Bonzini:
> On 10/28/2011 04:18 PM, Kevin Wolf wrote:
>> With the conversion of the block layer to coroutines, bdrv_read/write
>> have changed to run a nested event loop that calls qemu_bh_poll.
>> Consequently a scheduled BH can be called while a DMA transfer handler
>> runs and this means that DMA_run becomes reentrant.
>>
>> Devices haven't been designed to cope with that, so instead of running a
>> nested transfer handler just wait for the next invocation of the BH from the
>> main loop.
>>
>> This fixes some problems with the floppy device.
>>
>> Signed-off-by: Kevin Wolf<kwolf@redhat.com>
>> ---
>> hw/dma.c | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/dma.c b/hw/dma.c
>> index 8a7302a..e8d6341 100644
>> --- a/hw/dma.c
>> +++ b/hw/dma.c
>> @@ -358,6 +358,13 @@ static void DMA_run (void)
>> struct dma_cont *d;
>> int icont, ichan;
>> int rearm = 0;
>> + static int running = 0;
>> +
>> + if (running) {
>> + goto out;
>> + } else {
>> + running = 1;
>> + }
>>
>> d = dma_controllers;
>>
>> @@ -374,6 +381,8 @@ static void DMA_run (void)
>> }
>> }
>>
>> +out:
>> + running = 0;
>> if (rearm)
>> qemu_bh_schedule_idle(dma_bh);
>> }
>
> Hmm, I think you should set rearm = 1 to ensure the BH is run when
> ultimately you leave the sync read. Sorry for not spotting this before.
I was about to agree, but in fact adding a rearm = 1; line leads to
crashes, whereas in the version I posted it just works. So it looks like
something is wrong with doing it, even though it seemed to make perfect
sense at the first sight.
Kevin
^ permalink raw reply
* [PATCH 5/5] kvm tools: Remove dead code virt_queue__trigger_irq()
From: Asias He @ 2011-10-31 14:39 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Cyrill Gorcunov, Ingo Molnar, Sasha Levin, kvm, Asias He
In-Reply-To: <1320071982-21560-1-git-send-email-asias.hejun@gmail.com>
This function is not used anymore. Instead, We are using
virtio_pci__signal_vq() to trigger interrupt right now.
Signed-off-by: Asias He <asias.hejun@gmail.com>
---
tools/kvm/include/kvm/virtio.h | 3 ---
tools/kvm/virtio/core.c | 12 ------------
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
index 3442338..c6c380d 100644
--- a/tools/kvm/include/kvm/virtio.h
+++ b/tools/kvm/include/kvm/virtio.h
@@ -57,9 +57,6 @@ u16 virt_queue__get_iov(struct virt_queue *queue, struct iovec iov[], u16 *out,
u16 virt_queue__get_inout_iov(struct kvm *kvm, struct virt_queue *queue,
struct iovec in_iov[], struct iovec out_iov[],
u16 *in, u16 *out);
-
-void virt_queue__trigger_irq(struct virt_queue *vq, int irq, u8 *isr, struct kvm *kvm);
-
int virtio__get_dev_specific_field(int offset, bool msix, bool features_hi, u32 *config_off);
#endif /* KVM__VIRTIO_H */
diff --git a/tools/kvm/virtio/core.c b/tools/kvm/virtio/core.c
index d7c132b..0466e07 100644
--- a/tools/kvm/virtio/core.c
+++ b/tools/kvm/virtio/core.c
@@ -89,18 +89,6 @@ u16 virt_queue__get_inout_iov(struct kvm *kvm, struct virt_queue *queue,
return head;
}
-
-void virt_queue__trigger_irq(struct virt_queue *vq, int irq, u8 *isr, struct kvm *kvm)
-{
- if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
- return;
-
- if (*isr == VIRTIO_IRQ_LOW) {
- *isr = VIRTIO_IRQ_HIGH;
- kvm__irq_line(kvm, irq, VIRTIO_IRQ_HIGH);
- }
-}
-
int virtio__get_dev_specific_field(int offset, bool msix, bool features_hi, u32 *config_off)
{
if (msix) {
--
1.7.7.1
^ permalink raw reply related
* [PATCH 4/5] kvm tools: Fix ndev mutex and condition variable initialization
From: Asias He @ 2011-10-31 14:39 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Cyrill Gorcunov, Ingo Molnar, Sasha Levin, kvm, Asias He
In-Reply-To: <1320071982-21560-1-git-send-email-asias.hejun@gmail.com>
This patch fixes the initialization of the following variables:
ndev->io_tx_lock
ndev->io_rx_lock
ndev->io_tx_cond
ndev->io_rx_cond
Signed-off-by: Asias He <asias.hejun@gmail.com>
---
tools/kvm/virtio/net.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
index 1b59972..7cd6794 100644
--- a/tools/kvm/virtio/net.c
+++ b/tools/kvm/virtio/net.c
@@ -248,14 +248,14 @@ fail:
static void virtio_net__io_thread_init(struct kvm *kvm, struct net_dev *ndev)
{
+ pthread_mutex_init(&ndev->io_tx_lock, NULL);
pthread_mutex_init(&ndev->io_rx_lock, NULL);
- pthread_cond_init(&ndev->io_tx_cond, NULL);
- pthread_mutex_init(&ndev->io_rx_lock, NULL);
pthread_cond_init(&ndev->io_tx_cond, NULL);
+ pthread_cond_init(&ndev->io_rx_cond, NULL);
- pthread_create(&ndev->io_rx_thread, NULL, virtio_net_rx_thread, ndev);
pthread_create(&ndev->io_tx_thread, NULL, virtio_net_tx_thread, ndev);
+ pthread_create(&ndev->io_rx_thread, NULL, virtio_net_rx_thread, ndev);
}
static inline int tap_ops_tx(struct iovec *iov, u16 out, struct net_dev *ndev)
--
1.7.7.1
^ permalink raw reply related
* [PATCH 3/5] kvm tools: Fix a vertical indentation for net/uip/udp.c
From: Asias He @ 2011-10-31 14:39 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Cyrill Gorcunov, Ingo Molnar, Sasha Levin, kvm, Asias He
In-Reply-To: <1320071982-21560-1-git-send-email-asias.hejun@gmail.com>
Signed-off-by: Asias He <asias.hejun@gmail.com>
---
tools/kvm/net/uip/udp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/net/uip/udp.c b/tools/kvm/net/uip/udp.c
index 39c2b57..d4518b2 100644
--- a/tools/kvm/net/uip/udp.c
+++ b/tools/kvm/net/uip/udp.c
@@ -182,7 +182,7 @@ static void *uip_udp_socket_thread(void *p)
/*
* Get free buffer to send data to guest
*/
- buf = uip_buf_get_free(info);
+ buf = uip_buf_get_free(info);
uip_udp_make_pkg(info, sk, buf, payload, payload_len);
--
1.7.7.1
^ permalink raw reply related
* [PATCH 2/5] kvm tools: Use macro in uip_tx_do_ipv4()
From: Asias He @ 2011-10-31 14:39 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Cyrill Gorcunov, Ingo Molnar, Sasha Levin, kvm, Asias He
In-Reply-To: <1320071982-21560-1-git-send-email-asias.hejun@gmail.com>
Use marcro instead of magic number in uip_tx_do_ipv4()
Signed-off-by: Asias He <asias.hejun@gmail.com>
---
tools/kvm/include/kvm/uip.h | 1 +
tools/kvm/net/uip/ipv4.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/include/kvm/uip.h b/tools/kvm/include/kvm/uip.h
index bded986..4497f6a 100644
--- a/tools/kvm/include/kvm/uip.h
+++ b/tools/kvm/include/kvm/uip.h
@@ -19,6 +19,7 @@
#define UIP_IP_TTL 0X40
#define UIP_IP_P_UDP 0X11
#define UIP_IP_P_TCP 0X06
+#define UIP_IP_P_ICMP 0X01
#define UIP_TCP_HDR_LEN 0x50
#define UIP_TCP_WIN_SIZE 14600
diff --git a/tools/kvm/net/uip/ipv4.c b/tools/kvm/net/uip/ipv4.c
index 4def129..58373fd 100644
--- a/tools/kvm/net/uip/ipv4.c
+++ b/tools/kvm/net/uip/ipv4.c
@@ -12,13 +12,13 @@ int uip_tx_do_ipv4(struct uip_tx_arg *arg)
}
switch (ip->proto) {
- case 0x01: /* ICMP */
+ case UIP_IP_P_ICMP:
uip_tx_do_ipv4_icmp(arg);
break;
- case 0x06: /* TCP */
+ case UIP_IP_P_TCP:
uip_tx_do_ipv4_tcp(arg);
break;
- case 0x11: /* UDP */
+ case UIP_IP_P_UDP:
uip_tx_do_ipv4_udp(arg);
break;
default:
--
1.7.7.1
^ permalink raw reply related
* [Bug 42435] New: Suspected loss of varyings between shaders
From: bugzilla-daemon @ 2011-10-31 14:40 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=42435
Bug #: 42435
Summary: Suspected loss of varyings between shaders
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: screwdriver@lxnt.info
Longer description, the test case, screenshots, and core from i965 crash are
in attached archive.
In short:
I try to draw a 2D screenful of point sprites, emulating an ansi-colored
terminal. Fragment shader receives texture coordinates for the character, its
color and size of graphic in the texture via varyings.
R600g draws a black screen, while llvmpipe and fglrx draw what is supposed to
be drawn. i965 crashes. non-llvm swrast fails to set gl_PointSize. R600c also
draws a black screen.
Drawing varying values themselves I get bogus values for some of them.
Mesa version: 7.12.0~git20111027.0fbc8d30-0ubuntu0sarvatt~natty
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 1/5] kvm tools: Drop unused variable in struct uip_buf
From: Asias He @ 2011-10-31 14:39 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Cyrill Gorcunov, Ingo Molnar, Sasha Levin, kvm, Asias He
'u32 payload' is not used, so drop it.
Signed-off-by: Asias He <asias.hejun@gmail.com>
---
tools/kvm/include/kvm/uip.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/include/kvm/uip.h b/tools/kvm/include/kvm/uip.h
index 3501d36..bded986 100644
--- a/tools/kvm/include/kvm/uip.h
+++ b/tools/kvm/include/kvm/uip.h
@@ -209,7 +209,6 @@ struct uip_info {
struct uip_buf {
struct list_head list;
struct uip_info *info;
- u32 payload;
int vnet_len;
int eth_len;
int status;
--
1.7.7.1
^ permalink raw reply related
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-31 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFDM_spE8jg4K5awBPZvPyEmdhSnQ9Zt=v2U4PmFQeRLOw@mail.gmail.com>
On Mon, Oct 31, 2011 at 08:03:26PM +0530, Rabin Vincent wrote:
> On Mon, Oct 31, 2011 at 19:43, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > $ spatch -sp_file arch_reset-1.cocci arch/arm/*/include/*/system.h > arch_reset-1.diff
> >
> > The diff it created contains:
> >
> > --- arch/arm/mach-ep93xx/include/mach/system.h ?2011-03-04 19:52:46.419272878 +0000
> > +++ /tmp/cocci-output-380-f841cc-system.h ? ? ? 2011-10-31 13:54:52.066705107 +0000
> > ...
> > --- arch/arm/mach-iop32x/include/mach/system.h ?2011-03-04 19:52:46.445272534 +0000
> > +++ /tmp/cocci-output-380-c0e3f4-system.h ? ? ? 2011-10-31 13:54:52.072705051 +0000
> > ...
> > --- arch/arm/mach-ixp2000/include/mach/system.h 2011-03-04 19:52:46.449272482 +0000
> > +++ /tmp/cocci-output-380-467f17-system.h ? ? ? 2011-10-31 13:54:52.079704984 +0000
> > ...
> >
> > which in total deletes 6 lines. ?However, the patch is rejected by
> > git apply and gnu patch as it stands - it needs the filenames to be
> > edited to something more reasonable. ?So that also takes six edits.
>
> The above patch will apply with gnu patch if you use -p0.
$ patch -p0 -i arch_reset-1.diff --dry-run
patch: **** rejecting absolute target file name: /tmp/cocci-output-380-f841cc-system.h
^ permalink raw reply
* [U-Boot] [PATCH V2] ARM: orion5x: reduce dependence of including platform file
From: Lei Wen @ 2011-10-31 14:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A14D1C865@SC-VEXCH4.marvell.com>
Hi Prafulla,
On Thu, Oct 27, 2011 at 5:02 PM, Prafulla Wadaskar <prafulla@marvell.com> wrote:
>
>
>> -----Original Message-----
>> From: Lei Wen [mailto:leiwen at marvell.com]
>> Sent: Wednesday, October 26, 2011 7:52 AM
>> To: Wolfgang Denk; Albert ARIBAUD; Prafulla Wadaskar; u-
>> boot at lists.denx.de
>> Subject: [PATCH V2] ARM: orion5x: reduce dependence of
>> including platform file
>>
>> For files like the drivers/serial/serial.c, it must include the
>> platform file, as the CONFIG_SYS_NS16550_COM1 must reference to
>> the definition in the platform definition files.
>>
>> Include the platform definition file in the config file, so
>> that it
>> would decouple the dependence for the driver files.
>>
>> Signed-off-by: Lei Wen <leiwen@marvell.com>
>> ---
>> Changelog:
>> V2: seperate orion5x define structure as kirkwood and armada
>> does
>>
>> ?arch/arm/cpu/arm926ejs/orion5x/cpu.c ? ? ? ?| ? ?2 +
>> ?arch/arm/cpu/arm926ejs/orion5x/dram.c ? ? ? | ? ?1 +
>> ?arch/arm/cpu/arm926ejs/orion5x/timer.c ? ? ?| ? ?1 +
>> ?arch/arm/include/asm/arch-orion5x/config.h ?| ?135
>> ++++++++++++++++++++++
>> ?arch/arm/include/asm/arch-orion5x/orion5x.h | ? ?6 -
>> ?common/cmd_ide.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?6 -
>> ?include/configs/edminiv2.h ? ? ? ? ? ? ? ? ?| ?166 +--------
>
> I think you are mixing two objective in one patch here.
>
> 1. using mv-common.h for orion5x platforms.
> 2. orion5x: reduce dependence of including platform file (i.e. ide, serial)
>
> May you please split them accordingly?
>
> ...snip....
>> diff --git a/arch/arm/include/asm/arch-orion5x/config.h
>> b/arch/arm/include/asm/arch-orion5x/config.h
>> new file mode 100644
>> index 0000000..6db3554
>> --- /dev/null
>> +++ b/arch/arm/include/asm/arch-orion5x/config.h
>> @@ -0,0 +1,135 @@
>> +/*
>> + * (C) Copyright 2011
>> + * Marvell Semiconductor <www.marvell.com>
>> + * Written-by: Lei Wen <leiwen@marvell.com>
>> + *
>> + * See file CREDITS for list of people who contributed to this
>> + * project.
>> + *
>> + * This program is free software; you can redistribute it
>> and/or
>> + * modify it under the terms of the GNU General Public License
>> as
>> + * published by the Free Software Foundation; either version 2
>> of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be
>> useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty
>> of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
>> the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public
>> License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>> + * MA 02110-1301 USA
>> + */
>> +
>> +/*
>> + * This file should be included in board config header file.
>> + *
>> + * It supports common definitions for Orion platform
>> + */
>> +
>> +#ifndef _ORION_CONFIG_H
>> +#define _ORION_CONFIG_H
>> +
>> +#include <asm/arch/orion5x.h>
>> +#define MV_UART_CONSOLE_BASE ORION5X_UART0_BASE
>> +
>> +/*
>> + * Board-specific values for Orion5x MPP low level init:
>> + * - MPPs 12 to 15 are SATA LEDs (mode 5)
>> + * - Others are GPIO/unused (mode 3 for MPP0, mode 5 for
>> + * ? MPP16 to MPP19, mode 0 for others
>> + */
>> +
>> +#define ORION5X_MPP0_7 ? ? ? ? ? ? ? 0x00000003
>> +#define ORION5X_MPP8_15 ? ? ? ? ? ? ?0x55550000
>> +#define ORION5X_MPP16_23 ? ? 0x00005555
>> +
>> +/*
>> + * Board-specific values for Orion5x GPIO low level init:
>> + * - GPIO3 is input (RTC interrupt)
>> + * - GPIO16 is Power LED control (0 = on, 1 = off)
>> + * - GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16)
>> + * - GPIO18 is Power Button status (0 = Released, 1 = Pressed)
>> + * - Last GPIO is 26, further bits are supposed to be 0.
>> + * Enable mask has ones for INPUT, 0 for OUTPUT.
>> + * Default is LED ON.
>> + */
>> +
>> +#define ORION5X_GPIO_OUT_ENABLE ? ? ?0x03fcffff
>> +#define ORION5X_GPIO_OUT_VALUE ? ? ? 0x03fcffff
>
> MPP and GPIO configs are specific to each board and must go to board config file
>
It seems to me that orion5x fixing patch already merged in both
u-boot-marvell.git
and u-boot-arm.git. And I try to build the edminiv2_config in both
git, no preview warning
at all...
So it seems this v2 patch could be abondoned...
Best regards,
Lei
^ permalink raw reply
* Re: [ANNOUNCE] xf86-video-intel 2.16.901
From: Julien Cristau @ 2011-10-31 14:37 UTC (permalink / raw)
To: Bojan Smojver; +Cc: intel-gfx
In-Reply-To: <1320023745.1989.2.camel@shrek.rexursive.com>
On Mon, Oct 31, 2011 at 12:15:45 +1100, Bojan Smojver wrote:
> On Sun, 2011-10-30 at 16:57 +0000, Chris Wilson wrote:
> > Bugs fixed in this snapshot (compared to 2.16.0)
>
> No hibernation memory corruption fix. Sniff, sniff... :-(
>
Pretty sure what you should be looking for is in the kernel, not the X
driver.
Cheers,
Julien
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.