* [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
From: Russell King - ARM Linux @ 2010-10-07 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286444662-16843-1-git-send-email-felipe.contreras@gmail.com>
On Thu, Oct 07, 2010 at 12:44:22PM +0300, Felipe Contreras wrote:
> Many drivers are broken, and there's no alternative in sight. Such a big
> change should stay as a warning for now, and only later should it
> actually fail.
>
> The drivers are not doing something correct, we get it, but for now it's
> better to allow them to work (they do 99% of the time anyway) rather
> than to force everyone to revert this patch in their internal trees
> until there's a solution. A slightly broken functionality is better than
> no functionality at all.
>
> A warning lets people know that what they are doing is not right, and
> they should fix it.
So what are _you_ going to do to fix these drivers? Continue reverting
this patch? Or are you just going to ignore the issue entirely?
Unless people can come up with a plan to fix their drivers using ioremap
on system RAM thereby violating the architecture specification, I'm
_not_ going to apply this patch.
^ permalink raw reply
* Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
From: Russell King - ARM Linux @ 2010-10-07 19:22 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-main, linux-arm, Arnd Hannemann, Han Jonghun,
Uwe Kleine-König, Hemant Pedanekar
In-Reply-To: <1286444662-16843-1-git-send-email-felipe.contreras@gmail.com>
On Thu, Oct 07, 2010 at 12:44:22PM +0300, Felipe Contreras wrote:
> Many drivers are broken, and there's no alternative in sight. Such a big
> change should stay as a warning for now, and only later should it
> actually fail.
>
> The drivers are not doing something correct, we get it, but for now it's
> better to allow them to work (they do 99% of the time anyway) rather
> than to force everyone to revert this patch in their internal trees
> until there's a solution. A slightly broken functionality is better than
> no functionality at all.
>
> A warning lets people know that what they are doing is not right, and
> they should fix it.
So what are _you_ going to do to fix these drivers? Continue reverting
this patch? Or are you just going to ignore the issue entirely?
Unless people can come up with a plan to fix their drivers using ioremap
on system RAM thereby violating the architecture specification, I'm
_not_ going to apply this patch.
^ permalink raw reply
* [PATCH] let dmeventd unmount invalid snapshots (BZ 189462)
From: Alasdair G Kergon @ 2010-10-07 19:23 UTC (permalink / raw)
To: lvm-devel
In-Reply-To: <877hhujgh8.fsf_-_@twilight.int.mornfall.net.>
On Thu, Oct 07, 2010 at 03:10:43PM +0200, Peter Rockai wrote:
> There are some trade-offs involved. I have opted for using an umount
> syscall directly since it's simpler and more robust. The downside is
> that /etc/mtab will go out of sync and people may actually think that
I'm not keen on leaving /etc/mtab out-of-date, or missing out anything
else that /bin/umount might actually do (with an errored-out device).
Would this patch need an update to the selinux context to allow umount?
> the snapshot is still mounted (mount(8) just prints mtab without
> thinking twice about it). We could just fork off umount(8) instead, but
> that can fail in new and interesting ways.
Yes, even if moved outside the locking. But even umount2() within
the lock might have deadlock possibilities, as might syslog() as
you point out.
The options/problems here need a bit more investigation.
> The other possible issue with the patch is that I am not sure whether
> it's actually safe to read /proc/mounts incrementally, with possibly
kabi found problems like that with another /proc file.
Alasdair
^ permalink raw reply
* Re: [Qemu-devel] [STATUS] static instrumentation
From: Blue Swirl @ 2010-10-07 19:23 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <8762xdyhha.fsf@ginnungagap.bsc.es>
On Thu, Oct 7, 2010 at 6:40 PM, Lluís <xscript@gmx.net> wrote:
> All virtual memory accesses should now be instrumented on all
> architectures.
>
> Next steps (in order):
>
> * Separately instrument physical memory addresses for executed
> instructions, regular memory accesses and memory accesses to I/O
> space (if possible). This will need to add an extra field on
> CPUTLBEntry with the physical address of the page.
>
> * Instrument memory accesses performed by DMA operations.
>
> * See how it plays with KVM. The objective is to make it switch from
> KVM to emulation (and the other way around) when a backdoor
> instruction is found.
>
> * Finish implementation of used/defined register usage in x86.
>
> As always:
> git clone https://code.gso.ac.upc.edu/git/qemu-instrument
> https://projects.gso.ac.upc.edu/projects/qemu-instrument
The patches there seem to be fixes or small changes to your other
patches. This makes any review very difficult.
But I'm not sure the architecture is what we'd like to see integrated
in QEMU, though I may have missed the whole picture because of the
patch fragmentation problem. Before doing any work to possibly go
further in wrong direction, please try to submit early some preview
version for comments and review.
Just as an example, perhaps the existing tracing framework could be
extended to cover also your needs.
^ permalink raw reply
* Re: [PATCH 3/3] pnfs_submit: enforce requested DS only pNFS role
From: Benny Halevy @ 2010-10-07 19:23 UTC (permalink / raw)
To: andros; +Cc: linux-nfs, Fred Isaman
In-Reply-To: <4CAE145F.5070809@panasas.com>
On 2010-10-07 14:41, Benny Halevy wrote:
> On 2010-10-07 14:08, Benny Halevy wrote:
>> On 2010-10-07 13:06, Benny Halevy wrote:
>>> On 2010-10-07 15:37, andros@netapp.com wrote:
>>>> From: Andy Adamson <andros@netapp.com>
>>>>
>>>> Signed-off-by: Andy Adamson <andros@netapp.com>
>>>> ---
>>>> fs/nfs/nfs4filelayoutdev.c | 5 -----
>>>> fs/nfs/nfs4state.c | 5 +++++
>>>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/fs/nfs/nfs4filelayoutdev.c b/fs/nfs/nfs4filelayoutdev.c
>>>> index e0edf93..1f0ab62 100644
>>>> --- a/fs/nfs/nfs4filelayoutdev.c
>>>> +++ b/fs/nfs/nfs4filelayoutdev.c
>>>> @@ -183,11 +183,6 @@ nfs4_pnfs_ds_create(struct nfs_server *mds_srv, struct nfs4_pnfs_ds *ds)
>>>> goto out_put;
>>>> }
>>>> /*
>>>> - * Mask the (possibly) returned EXCHGID4_FLAG_USE_PNFS_MDS pNFS role
>>>> - * The is_ds_only_session depends on this.
>>>> - */
>>>> - clp->cl_exchange_flags &= ~EXCHGID4_FLAG_USE_PNFS_MDS;
>>>> - /*
>>>> * Set DS lease equal to the MDS lease, renewal is scheduled in
>>>> * create_session
>>>> */
>>>> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
>>>> index 91584ad..e2fc175 100644
>>>> --- a/fs/nfs/nfs4state.c
>>>> +++ b/fs/nfs/nfs4state.c
>>>> @@ -188,6 +188,7 @@ static int nfs4_begin_drain_session(struct nfs_client *clp)
>>>> int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>>>> {
>>>> int status;
>>>> + u32 req_exchange_flags = clp->cl_exchange_flags;
>>>>
>>>> nfs4_begin_drain_session(clp);
>>>> status = nfs4_proc_exchange_id(clp, cred);
>>>> @@ -196,6 +197,10 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
>>>> status = nfs4_proc_create_session(clp);
>>>> if (status != 0)
>>>> goto out;
>>>> + if (is_ds_only_session(req_exchange_flags))
>>>> + /* Mask the (possibly) returned MDS and non-pNFS roles */
>>>
>>> This comment does not really add anything substantial that the code doesn't tell you :)
>>>
>>>> + clp->cl_exchange_flags &=
>>>> + ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);
>>>
>>> I'm not why you want to mask out EXCHGID4_FLAG_USE_NON_PNFS.
>>> If the server is not a DS why not just return an error?
>>
>> So Andy convinced me and the spec. says that USE_PNFS_DS | USE_NON_PNFS
>> is a valid response.
>> However, if USE_PNFS_DS is unset in the response in this case
>> we need not create the client and better return an error.
>> I'll send a patch that does that.
>
> So this is what I have in mind:
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index e2fc175..4723c41 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -197,10 +197,14 @@ int nfs41_init_clientid(struct nfs_client *clp, struct rpc_cred *cred)
> status = nfs4_proc_create_session(clp);
> if (status != 0)
> goto out;
> - if (is_ds_only_session(req_exchange_flags))
> - /* Mask the (possibly) returned MDS and non-pNFS roles */
> + if (is_ds_only_session(req_exchange_flags)) {
> clp->cl_exchange_flags &=
> ~(EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_NON_PNFS);
> + if (!is_ds_only_session(clp->cl_exchange_flags)) {
> + nfs4_proc_destroy_session(clp);
This should be {
nfs4_destroy_session(clp->cl_session);
clp->cl_session = NULL;
}
> + status = -ENOTSUPP;
> + }
> + }
> nfs41_setup_state_renewal(clp);
> nfs_mark_client_ready(clp, NFS_CS_READY);
> out:
>
>>
>> Benny
>>
>>>
>>> Benny
>>>
>>>> nfs41_setup_state_renewal(clp);
>>>> nfs_mark_client_ready(clp, NFS_CS_READY);
>>>> out:
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Mike Frysinger @ 2010-10-07 19:25 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <1286476616-3373-1-git-send-email-dwalker@codeaurora.org>
On Thu, Oct 7, 2010 at 14:36, Daniel Walker wrote:
> Many of JTAG debuggers for ARM support DCC protocol over JTAG
> connection, which is very useful to debug hardwares which has no
> serial port. This patch adds DCC serial emulation and the console
> support. System timer based polling method is used for the
> emulation of serial input interrupt handling.
why use serial_core at all ? seems like you could just use the tty
layer directly. i did that with drivers/char/bfin_jtag_comm.c.
although, there's the suggestion in the air that my jtag driver could
be converted to the HVC framework to even further simplify things.
but no one thinks it should be serial_core :).
-mike
^ permalink raw reply
* RE: [git:v4l-dvb/v2.6.37] V4L/DVB: Staging: cx25821: fix braces and space coding style issues
From: Palash Bandyopadhyay @ 2010-10-07 19:09 UTC (permalink / raw)
To: linux-media@vger.kernel.org, linuxtv-commits@linuxtv.org; +Cc: Ruslan Pisarev
In-Reply-To: <E1P3vN0-0002Qf-9Z@www.linuxtv.org>
Thanks.
Looks ok.
Signed off by Palash Bandyopadhyay
-----Original Message-----
From: Mauro Carvalho Chehab [mailto:mchehab@redhat.com]
Sent: Thursday, October 07, 2010 11:37 AM
To: linuxtv-commits@linuxtv.org
Cc: Ruslan Pisarev; Palash Bandyopadhyay
Subject: [git:v4l-dvb/v2.6.37] V4L/DVB: Staging: cx25821: fix braces and space coding style issues
This is an automatic generated email to let you know that the following patch were queued at the
http://git.linuxtv.org/media-tree.git tree:
Subject: V4L/DVB: Staging: cx25821: fix braces and space coding style issues
Author: Ruslan Pisarev <ruslanpisarev@gmail.com>
Date: Mon Sep 27 10:01:36 2010 -0300
Errors found by the checkpatch.pl tool.
[mchehab@redhat.com: merged a series of CodingStyle cleanup patches for cx25851. They're all from the same author, and patches the same driver]
Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua>
Cc: Palash Bandyopadhyay <Palash.Bandyopadhyay@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/staging/cx25821/cx25821-audio-upstream.c | 13 +-
drivers/staging/cx25821/cx25821-audio.h | 10 +-
drivers/staging/cx25821/cx25821-core.c | 62 +++++-----
drivers/staging/cx25821/cx25821-i2c.c | 2 +-
drivers/staging/cx25821/cx25821-medusa-reg.h | 10 +-
drivers/staging/cx25821/cx25821-medusa-video.c | 8 +-
drivers/staging/cx25821/cx25821-reg.h | 4 +-
.../staging/cx25821/cx25821-video-upstream-ch2.c | 135 +++++++++-----------
.../staging/cx25821/cx25821-video-upstream-ch2.h | 14 +-
drivers/staging/cx25821/cx25821-video-upstream.c | 28 ++--
drivers/staging/cx25821/cx25821-video-upstream.h | 10 +-
drivers/staging/cx25821/cx25821.h | 51 ++++----
12 files changed, 168 insertions(+), 179 deletions(-)
---
http://git.linuxtv.org/media-tree.git?a=commitdiff;h=b9a1211dff08aa73fc26db66980ec0710a6c7134
diff --git a/drivers/staging/cx25821/cx25821-audio-upstream.c b/drivers/staging/cx25821/cx25821-audio-upstream.c
index cdff49f..6f32006 100644
--- a/drivers/staging/cx25821/cx25821-audio-upstream.c
+++ b/drivers/staging/cx25821/cx25821-audio-upstream.c
@@ -40,8 +40,8 @@ MODULE_AUTHOR("Hiep Huynh <hiep.huynh@conexant.com>");
MODULE_LICENSE("GPL");
static int _intr_msk =
- FLD_AUD_SRC_RISCI1 | FLD_AUD_SRC_OF | FLD_AUD_SRC_SYNC |
- FLD_AUD_SRC_OPC_ERR;
+ FLD_AUD_SRC_RISCI1 | FLD_AUD_SRC_OF | FLD_AUD_SRC_SYNC |
+ FLD_AUD_SRC_OPC_ERR;
int cx25821_sram_channel_setup_upstream_audio(struct cx25821_dev *dev,
struct sram_channel *ch,
@@ -506,7 +506,7 @@ int cx25821_audio_upstream_irq(struct cx25821_dev *dev, int chan_num,
{
int i = 0;
u32 int_msk_tmp;
- struct sram_channel *channel = dev->channels[chan_num].sram_channels;
+ struct sram_channel *channel = dev->channels[chan_num].sram_channels;
dma_addr_t risc_phys_jump_addr;
__le32 *rp;
@@ -608,7 +608,7 @@ static irqreturn_t cx25821_upstream_irq_audio(int irq, void *dev_id)
if (!dev)
return -1;
- sram_ch = dev->channels[dev->_audio_upstream_channel_select].
+ sram_ch = dev->channels[dev->_audio_upstream_channel_select].
sram_channels;
msk_stat = cx_read(sram_ch->int_mstat);
@@ -733,7 +733,7 @@ int cx25821_audio_upstream_init(struct cx25821_dev *dev, int channel_select)
}
dev->_audio_upstream_channel_select = channel_select;
- sram_ch = dev->channels[channel_select].sram_channels;
+ sram_ch = dev->channels[channel_select].sram_channels;
/* Work queue */
INIT_WORK(&dev->_audio_work_entry, cx25821_audioups_handler);
@@ -764,9 +764,8 @@ int cx25821_audio_upstream_init(struct cx25821_dev *dev, int channel_select)
str_length + 1);
/* Default if filename is empty string */
- if (strcmp(dev->input_audiofilename, "") == 0) {
+ if (strcmp(dev->input_audiofilename, "") == 0)
dev->_audiofilename = "/root/audioGOOD.wav";
- }
} else {
str_length = strlen(_defaultAudioName);
dev->_audiofilename = kmalloc(str_length + 1, GFP_KERNEL);
diff --git a/drivers/staging/cx25821/cx25821-audio.h b/drivers/staging/cx25821/cx25821-audio.h
index 434b2a3..a702a0d 100644
--- a/drivers/staging/cx25821/cx25821-audio.h
+++ b/drivers/staging/cx25821/cx25821-audio.h
@@ -31,18 +31,18 @@
#define NUMBER_OF_PROGRAMS 8
/*
- Max size of the RISC program for a buffer. - worst case is 2 writes per line
- Space is also added for the 4 no-op instructions added on the end.
-*/
+ * Max size of the RISC program for a buffer. - worst case is 2 writes per line
+ * Space is also added for the 4 no-op instructions added on the end.
+ */
#ifndef USE_RISC_NOOP
#define MAX_BUFFER_PROGRAM_SIZE \
- (2*LINES_PER_BUFFER*RISC_WRITE_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE*4)
+ (2*LINES_PER_BUFFER*RISC_WRITE_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE*4)
#endif
/* MAE 12 July 2005 Try to use NOOP RISC instruction instead */
#ifdef USE_RISC_NOOP
#define MAX_BUFFER_PROGRAM_SIZE \
- (2*LINES_PER_BUFFER*RISC_WRITE_INSTRUCTION_SIZE + RISC_NOOP_INSTRUCTION_SIZE*4)
+ (2*LINES_PER_BUFFER*RISC_WRITE_INSTRUCTION_SIZE + RISC_NOOP_INSTRUCTION_SIZE*4)
#endif
/* Sizes of various instructions in bytes. Used when adding instructions. */
diff --git a/drivers/staging/cx25821/cx25821-core.c b/drivers/staging/cx25821/cx25821-core.c
index 03391f4..ca1eece 100644
--- a/drivers/staging/cx25821/cx25821-core.c
+++ b/drivers/staging/cx25821/cx25821-core.c
@@ -42,7 +42,7 @@ static unsigned int card[] = {[0 ... (CX25821_MAXBOARDS - 1)] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, "card type");
-static unsigned int cx25821_devcount = 0;
+static unsigned int cx25821_devcount;
static DEFINE_MUTEX(devlist);
LIST_HEAD(cx25821_devlist);
@@ -781,14 +781,14 @@ static void cx25821_shutdown(struct cx25821_dev *dev)
/* Disable Video A/B activity */
for (i = 0; i < VID_CHANNEL_NUM; i++) {
- cx_write(dev->channels[i].sram_channels->dma_ctl, 0);
- cx_write(dev->channels[i].sram_channels->int_msk, 0);
+ cx_write(dev->channels[i].sram_channels->dma_ctl, 0);
+ cx_write(dev->channels[i].sram_channels->int_msk, 0);
}
- for (i = VID_UPSTREAM_SRAM_CHANNEL_I; i <= VID_UPSTREAM_SRAM_CHANNEL_J;
- i++) {
- cx_write(dev->channels[i].sram_channels->dma_ctl, 0);
- cx_write(dev->channels[i].sram_channels->int_msk, 0);
+ for (i = VID_UPSTREAM_SRAM_CHANNEL_I;
+ i <= VID_UPSTREAM_SRAM_CHANNEL_J; i++) {
+ cx_write(dev->channels[i].sram_channels->dma_ctl, 0);
+ cx_write(dev->channels[i].sram_channels->int_msk, 0);
}
/* Disable Audio activity */
@@ -806,9 +806,9 @@ void cx25821_set_pixel_format(struct cx25821_dev *dev, int channel_select,
u32 format)
{
if (channel_select <= 7 && channel_select >= 0) {
- cx_write(dev->channels[channel_select].
- sram_channels->pix_frmt, format);
- dev->channels[channel_select].pixel_formats = format;
+ cx_write(dev->channels[channel_select].
+ sram_channels->pix_frmt, format);
+ dev->channels[channel_select].pixel_formats = format;
}
}
@@ -829,7 +829,7 @@ static void cx25821_initialize(struct cx25821_dev *dev)
cx_write(PCI_INT_STAT, 0xffffffff);
for (i = 0; i < VID_CHANNEL_NUM; i++)
- cx_write(dev->channels[i].sram_channels->int_stat, 0xffffffff);
+ cx_write(dev->channels[i].sram_channels->int_stat, 0xffffffff);
cx_write(AUD_A_INT_STAT, 0xffffffff);
cx_write(AUD_B_INT_STAT, 0xffffffff);
@@ -843,22 +843,22 @@ static void cx25821_initialize(struct cx25821_dev *dev)
mdelay(100);
for (i = 0; i < VID_CHANNEL_NUM; i++) {
- cx25821_set_vip_mode(dev, dev->channels[i].sram_channels);
- cx25821_sram_channel_setup(dev, dev->channels[i].sram_channels,
- 1440, 0);
- dev->channels[i].pixel_formats = PIXEL_FRMT_422;
- dev->channels[i].use_cif_resolution = FALSE;
+ cx25821_set_vip_mode(dev, dev->channels[i].sram_channels);
+ cx25821_sram_channel_setup(dev, dev->channels[i].sram_channels,
+ 1440, 0);
+ dev->channels[i].pixel_formats = PIXEL_FRMT_422;
+ dev->channels[i].use_cif_resolution = FALSE;
}
/* Probably only affect Downstream */
- for (i = VID_UPSTREAM_SRAM_CHANNEL_I; i <= VID_UPSTREAM_SRAM_CHANNEL_J;
- i++) {
- cx25821_set_vip_mode(dev, dev->channels[i].sram_channels);
+ for (i = VID_UPSTREAM_SRAM_CHANNEL_I;
+ i <= VID_UPSTREAM_SRAM_CHANNEL_J; i++) {
+ cx25821_set_vip_mode(dev, dev->channels[i].sram_channels);
}
- cx25821_sram_channel_setup_audio(dev,
- dev->channels[SRAM_CH08].sram_channels,
- 128, 0);
+ cx25821_sram_channel_setup_audio(dev,
+ dev->channels[SRAM_CH08].sram_channels,
+ 128, 0);
cx25821_gpio_init(dev);
}
@@ -931,8 +931,8 @@ static int cx25821_dev_setup(struct cx25821_dev *dev)
/* Apply a sensible clock frequency for the PCIe bridge */
dev->clk_freq = 28000000;
- for (i = 0; i < MAX_VID_CHANNEL_NUM; i++)
- dev->channels[i].sram_channels = &cx25821_sram_channels[i];
+ for (i = 0; i < MAX_VID_CHANNEL_NUM; i++)
+ dev->channels[i].sram_channels = &cx25821_sram_channels[i];
if (dev->nr > 1)
CX25821_INFO("dev->nr > 1!");
@@ -1003,11 +1003,11 @@ static int cx25821_dev_setup(struct cx25821_dev *dev)
cx25821_card_setup(dev);
- if (medusa_video_init(dev) < 0)
- CX25821_ERR("%s() Failed to initialize medusa!\n"
- , __func__);
+ if (medusa_video_init(dev) < 0)
+ CX25821_ERR("%s() Failed to initialize medusa!\n"
+ , __func__);
- cx25821_video_register(dev);
+ cx25821_video_register(dev);
/* register IOCTL device */
dev->ioctl_dev =
@@ -1342,12 +1342,12 @@ static irqreturn_t cx25821_irq(int irq, void *dev_id)
for (i = 0; i < VID_CHANNEL_NUM; i++) {
if (pci_status & mask[i]) {
- vid_status = cx_read(dev->channels[i].
- sram_channels->int_stat);
+ vid_status = cx_read(dev->channels[i].
+ sram_channels->int_stat);
if (vid_status)
handled +=
- cx25821_video_irq(dev, i, vid_status);
+ cx25821_video_irq(dev, i, vid_status);
cx_write(PCI_INT_STAT, mask[i]);
}
diff --git a/drivers/staging/cx25821/cx25821-i2c.c b/drivers/staging/cx25821/cx25821-i2c.c
index e43572e..2b14bcc 100644
--- a/drivers/staging/cx25821/cx25821-i2c.c
+++ b/drivers/staging/cx25821/cx25821-i2c.c
@@ -283,7 +283,7 @@ static struct i2c_algorithm cx25821_i2c_algo_template = {
.master_xfer = i2c_xfer,
.functionality = cx25821_functionality,
#ifdef NEED_ALGO_CONTROL
- .algo_control = dummy_algo_control,
+ .algo_control = dummy_algo_control,
#endif
};
diff --git a/drivers/staging/cx25821/cx25821-medusa-reg.h b/drivers/staging/cx25821/cx25821-medusa-reg.h
index f7f33b3..1c1c228 100644
--- a/drivers/staging/cx25821/cx25821-medusa-reg.h
+++ b/drivers/staging/cx25821/cx25821-medusa-reg.h
@@ -443,13 +443,13 @@
/*****************************************************************************/
/* LUMA_CTRL register fields */
#define VDEC_A_BRITE_CTRL 0x1014
-#define VDEC_A_CNTRST_CTRL 0x1015
-#define VDEC_A_PEAK_SEL 0x1016
+#define VDEC_A_CNTRST_CTRL 0x1015
+#define VDEC_A_PEAK_SEL 0x1016
/*****************************************************************************/
/* CHROMA_CTRL register fields */
-#define VDEC_A_USAT_CTRL 0x1018
-#define VDEC_A_VSAT_CTRL 0x1019
-#define VDEC_A_HUE_CTRL 0x101A
+#define VDEC_A_USAT_CTRL 0x1018
+#define VDEC_A_VSAT_CTRL 0x1019
+#define VDEC_A_HUE_CTRL 0x101A
#endif
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c b/drivers/staging/cx25821/cx25821-medusa-video.c
index ef9f2b8..1e11e0c 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -778,9 +778,9 @@ int medusa_set_saturation(struct cx25821_dev *dev, int saturation, int decoder)
int medusa_video_init(struct cx25821_dev *dev)
{
- u32 value = 0, tmp = 0;
- int ret_val = 0;
- int i = 0;
+ u32 value = 0, tmp = 0;
+ int ret_val = 0;
+ int i = 0;
mutex_lock(&dev->lock);
@@ -829,7 +829,7 @@ int medusa_video_init(struct cx25821_dev *dev)
/* select AFE clock to output mode */
value = cx25821_i2c_read(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL, &tmp);
value &= 0x83FFFFFF;
- ret_val =
+ ret_val =
cx25821_i2c_write(&dev->i2c_bus[0], AFE_AB_DIAG_CTRL,
value | 0x10000000);
diff --git a/drivers/staging/cx25821/cx25821-reg.h b/drivers/staging/cx25821/cx25821-reg.h
index cfe0f32..a3fc25a 100644
--- a/drivers/staging/cx25821/cx25821-reg.h
+++ b/drivers/staging/cx25821/cx25821-reg.h
@@ -163,8 +163,8 @@
#define FLD_VID_DST_RISC2 0x00000010
#define FLD_VID_SRC_RISC1 0x00000002
#define FLD_VID_DST_RISC1 0x00000001
-#define FLD_VID_SRC_ERRORS FLD_VID_SRC_OPC_ERR | FLD_VID_SRC_SYNC | FLD_VID_SRC_UF
-#define FLD_VID_DST_ERRORS FLD_VID_DST_OPC_ERR | FLD_VID_DST_SYNC | FLD_VID_DST_OF
+#define FLD_VID_SRC_ERRORS (FLD_VID_SRC_OPC_ERR | FLD_VID_SRC_SYNC | FLD_VID_SRC_UF)
+#define FLD_VID_DST_ERRORS (FLD_VID_DST_OPC_ERR | FLD_VID_DST_SYNC | FLD_VID_DST_OF)
/* ***************************************************************************** */
#define AUD_A_INT_MSK 0x0400C0 /* Audio Int interrupt mask */
diff --git a/drivers/staging/cx25821/cx25821-video-upstream-ch2.c b/drivers/staging/cx25821/cx25821-video-upstream-ch2.c
index d12dbb5..405e2db 100644
--- a/drivers/staging/cx25821/cx25821-video-upstream-ch2.c
+++ b/drivers/staging/cx25821/cx25821-video-upstream-ch2.c
@@ -32,17 +32,17 @@
#include <linux/file.h>
#include <linux/fcntl.h>
#include <linux/slab.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
MODULE_DESCRIPTION("v4l2 driver module for cx25821 based TV cards");
MODULE_AUTHOR("Hiep Huynh <hiep.huynh@conexant.com>");
MODULE_LICENSE("GPL");
static int _intr_msk =
- FLD_VID_SRC_RISC1 | FLD_VID_SRC_UF | FLD_VID_SRC_SYNC | FLD_VID_SRC_OPC_ERR;
+ FLD_VID_SRC_RISC1 | FLD_VID_SRC_UF | FLD_VID_SRC_SYNC | FLD_VID_SRC_OPC_ERR;
static __le32 *cx25821_update_riscprogram_ch2(struct cx25821_dev *dev,
- __le32 * rp, unsigned int offset,
+ __le32 *rp, unsigned int offset,
unsigned int bpl, u32 sync_line,
unsigned int lines,
int fifo_enable, int field_type)
@@ -53,9 +53,8 @@ static __le32 *cx25821_update_riscprogram_ch2(struct cx25821_dev *dev,
*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
if (USE_RISC_NOOP_VIDEO) {
- for (i = 0; i < NUM_NO_OPS; i++) {
+ for (i = 0; i < NUM_NO_OPS; i++)
*(rp++) = cpu_to_le32(RISC_NOOP);
- }
}
/* scan lines */
@@ -75,7 +74,7 @@ static __le32 *cx25821_update_riscprogram_ch2(struct cx25821_dev *dev,
}
static __le32 *cx25821_risc_field_upstream_ch2(struct cx25821_dev *dev,
- __le32 * rp,
+ __le32 *rp,
dma_addr_t databuf_phys_addr,
unsigned int offset,
u32 sync_line, unsigned int bpl,
@@ -88,14 +87,12 @@ static __le32 *cx25821_risc_field_upstream_ch2(struct cx25821_dev *dev,
int dist_betwn_starts = bpl * 2;
/* sync instruction */
- if (sync_line != NO_SYNC_LINE) {
+ if (sync_line != NO_SYNC_LINE)
*(rp++) = cpu_to_le32(RISC_RESYNC | sync_line);
- }
if (USE_RISC_NOOP_VIDEO) {
- for (i = 0; i < NUM_NO_OPS; i++) {
+ for (i = 0; i < NUM_NO_OPS; i++)
*(rp++) = cpu_to_le32(RISC_NOOP);
- }
}
/* scan lines */
@@ -133,7 +130,7 @@ int cx25821_risc_buffer_upstream_ch2(struct cx25821_dev *dev,
{
__le32 *rp;
int fifo_enable = 0;
- int singlefield_lines = lines >> 1; /*get line count for single field */
+ int singlefield_lines = lines >> 1; /*get line count for single field */
int odd_num_lines = singlefield_lines;
int frame = 0;
int frame_size = 0;
@@ -218,15 +215,15 @@ void cx25821_stop_upstream_video_ch2(struct cx25821_dev *dev)
("cx25821: No video file is currently running so return!\n");
return;
}
- /* Disable RISC interrupts */
+ /* Disable RISC interrupts */
tmp = cx_read(sram_ch->int_msk);
cx_write(sram_ch->int_msk, tmp & ~_intr_msk);
- /* Turn OFF risc and fifo */
+ /* Turn OFF risc and fifo */
tmp = cx_read(sram_ch->dma_ctl);
cx_write(sram_ch->dma_ctl, tmp & ~(FLD_VID_FIFO_EN | FLD_VID_RISC_EN));
- /* Clear data buffer memory */
+ /* Clear data buffer memory */
if (dev->_data_buf_virt_addr_ch2)
memset(dev->_data_buf_virt_addr_ch2, 0,
dev->_data_buf_size_ch2);
@@ -250,9 +247,8 @@ void cx25821_stop_upstream_video_ch2(struct cx25821_dev *dev)
void cx25821_free_mem_upstream_ch2(struct cx25821_dev *dev)
{
- if (dev->_is_running_ch2) {
+ if (dev->_is_running_ch2)
cx25821_stop_upstream_video_ch2(dev);
- }
if (dev->_dma_virt_addr_ch2) {
pci_free_consistent(dev->pci, dev->_risc_size_ch2,
@@ -303,11 +299,10 @@ int cx25821_get_frame_ch2(struct cx25821_dev *dev, struct sram_channel *sram_ch)
file_offset = dev->_frame_count_ch2 * frame_size;
myfile = filp_open(dev->_filename_ch2, O_RDONLY | O_LARGEFILE, 0);
-
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
- printk("%s(): ERROR opening file(%s) with errno = %d! \n",
- __func__, dev->_filename_ch2, open_errno);
+ printk("%s(): ERROR opening file(%s) with errno = %d!\n",
+ __func__, dev->_filename_ch2, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
@@ -371,8 +366,8 @@ static void cx25821_vidups_handler_ch2(struct work_struct *work)
container_of(work, struct cx25821_dev, _irq_work_entry_ch2);
if (!dev) {
- printk("ERROR %s(): since container_of(work_struct) FAILED! \n",
- __func__);
+ printk("ERROR %s(): since container_of(work_struct) FAILED!\n",
+ __func__);
return;
}
@@ -398,8 +393,8 @@ int cx25821_openfile_ch2(struct cx25821_dev *dev, struct sram_channel *sram_ch)
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
- printk("%s(): ERROR opening file(%s) with errno = %d! \n",
- __func__, dev->_filename_ch2, open_errno);
+ printk("%s(): ERROR opening file(%s) with errno = %d!\n",
+ __func__, dev->_filename_ch2, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
@@ -450,9 +445,8 @@ int cx25821_openfile_ch2(struct cx25821_dev *dev, struct sram_channel *sram_ch)
if (i > 0)
dev->_frame_count_ch2++;
- if (vfs_read_retval < line_size) {
+ if (vfs_read_retval < line_size)
break;
- }
}
dev->_file_status_ch2 =
@@ -494,7 +488,7 @@ static int cx25821_upstream_buffer_prepare_ch2(struct cx25821_dev *dev,
return -ENOMEM;
}
- /* Iniitize at this address until n bytes to 0 */
+ /* Iniitize at this address until n bytes to 0 */
memset(dev->_dma_virt_addr_ch2, 0, dev->_risc_size_ch2);
if (dev->_data_buf_virt_addr_ch2 != NULL) {
@@ -502,7 +496,7 @@ static int cx25821_upstream_buffer_prepare_ch2(struct cx25821_dev *dev,
dev->_data_buf_virt_addr_ch2,
dev->_data_buf_phys_addr_ch2);
}
- /* For Video Data buffer allocation */
+ /* For Video Data buffer allocation */
dev->_data_buf_virt_addr_ch2 =
pci_alloc_consistent(dev->pci, dev->upstream_databuf_size_ch2,
&data_dma_addr);
@@ -515,26 +509,26 @@ static int cx25821_upstream_buffer_prepare_ch2(struct cx25821_dev *dev,
return -ENOMEM;
}
- /* Initialize at this address until n bytes to 0 */
+ /* Initialize at this address until n bytes to 0 */
memset(dev->_data_buf_virt_addr_ch2, 0, dev->_data_buf_size_ch2);
ret = cx25821_openfile_ch2(dev, sram_ch);
if (ret < 0)
return ret;
- /* Creating RISC programs */
+ /* Creating RISC programs */
ret =
cx25821_risc_buffer_upstream_ch2(dev, dev->pci, 0, bpl,
dev->_lines_count_ch2);
if (ret < 0) {
printk(KERN_INFO
- "cx25821: Failed creating Video Upstream Risc programs! \n");
+ "cx25821: Failed creating Video Upstream Risc programs!\n");
goto error;
}
return 0;
- error:
+ error:
return ret;
}
@@ -542,7 +536,7 @@ int cx25821_video_upstream_irq_ch2(struct cx25821_dev *dev, int chan_num,
u32 status)
{
u32 int_msk_tmp;
- struct sram_channel *channel = dev->channels[chan_num].sram_channels;
+ struct sram_channel *channel = dev->channels[chan_num].sram_channels;
int singlefield_lines = NTSC_FIELD_HEIGHT;
int line_size_in_bytes = Y422_LINE_SZ;
int odd_risc_prog_size = 0;
@@ -550,13 +544,13 @@ int cx25821_video_upstream_irq_ch2(struct cx25821_dev *dev, int chan_num,
__le32 *rp;
if (status & FLD_VID_SRC_RISC1) {
- /* We should only process one program per call */
+ /* We should only process one program per call */
u32 prog_cnt = cx_read(channel->gpcnt);
- /*
- Since we've identified our IRQ, clear our bits from the
- interrupt mask and interrupt status registers
- */
+ /*
+ * Since we've identified our IRQ, clear our bits from the
+ * interrupt mask and interrupt status registers
+ */
int_msk_tmp = cx_read(channel->int_msk);
cx_write(channel->int_msk, int_msk_tmp & ~_intr_msk);
cx_write(channel->int_stat, _intr_msk);
@@ -612,7 +606,7 @@ int cx25821_video_upstream_irq_ch2(struct cx25821_dev *dev, int chan_num,
dev->_frame_count_ch2);
return -1;
}
- /* ElSE, set the interrupt mask register, re-enable irq. */
+ /* ElSE, set the interrupt mask register, re-enable irq. */
int_msk_tmp = cx_read(channel->int_msk);
cx_write(channel->int_msk, int_msk_tmp |= _intr_msk);
@@ -631,24 +625,22 @@ static irqreturn_t cx25821_upstream_irq_ch2(int irq, void *dev_id)
return -1;
channel_num = VID_UPSTREAM_SRAM_CHANNEL_J;
-
- sram_ch = dev->channels[channel_num].sram_channels;
+ sram_ch = dev->channels[channel_num].sram_channels;
msk_stat = cx_read(sram_ch->int_mstat);
vid_status = cx_read(sram_ch->int_stat);
- /* Only deal with our interrupt */
+ /* Only deal with our interrupt */
if (vid_status) {
handled =
cx25821_video_upstream_irq_ch2(dev, channel_num,
vid_status);
}
- if (handled < 0) {
+ if (handled < 0)
cx25821_stop_upstream_video_ch2(dev);
- } else {
+ else
handled += handled;
- }
return IRQ_RETVAL(handled);
}
@@ -667,22 +659,21 @@ static void cx25821_set_pixelengine_ch2(struct cx25821_dev *dev,
value |= dev->_isNTSC_ch2 ? 0 : 0x10;
cx_write(ch->vid_fmt_ctl, value);
- /*
- set number of active pixels in each line. Default is 720
- pixels in both NTSC and PAL format
- */
+ /*
+ * set number of active pixels in each line. Default is 720
+ * pixels in both NTSC and PAL format
+ */
cx_write(ch->vid_active_ctl1, width);
num_lines = (height / 2) & 0x3FF;
odd_num_lines = num_lines;
- if (dev->_isNTSC_ch2) {
+ if (dev->_isNTSC_ch2)
odd_num_lines += 1;
- }
value = (num_lines << 16) | odd_num_lines;
- /* set number of active lines in field 0 (top) and field 1 (bottom) */
+ /* set number of active lines in field 0 (top) and field 1 (bottom) */
cx_write(ch->vid_active_ctl2, value);
cx_write(ch->vid_cdt_size, VID_CDT_SIZE >> 3);
@@ -694,27 +685,27 @@ int cx25821_start_video_dma_upstream_ch2(struct cx25821_dev *dev,
u32 tmp = 0;
int err = 0;
- /*
- 656/VIP SRC Upstream Channel I & J and 7 - Host Bus Interface
- for channel A-C
- */
+ /*
+ * 656/VIP SRC Upstream Channel I & J and 7 - Host Bus Interface
+ * for channel A-C
+ */
tmp = cx_read(VID_CH_MODE_SEL);
cx_write(VID_CH_MODE_SEL, tmp | 0x1B0001FF);
- /*
- Set the physical start address of the RISC program in the initial
- program counter(IPC) member of the cmds.
- */
+ /*
+ * Set the physical start address of the RISC program in the initial
+ * program counter(IPC) member of the cmds.
+ */
cx_write(sram_ch->cmds_start + 0, dev->_dma_phys_addr_ch2);
- cx_write(sram_ch->cmds_start + 4, 0); /* Risc IPC High 64 bits 63-32 */
+ cx_write(sram_ch->cmds_start + 4, 0); /* Risc IPC High 64 bits 63-32 */
/* reset counter */
cx_write(sram_ch->gpcnt_ctl, 3);
- /* Clear our bits from the interrupt status register. */
+ /* Clear our bits from the interrupt status register. */
cx_write(sram_ch->int_stat, _intr_msk);
- /* Set the interrupt mask register, enable irq. */
+ /* Set the interrupt mask register, enable irq. */
cx_set(PCI_INT_MSK, cx_read(PCI_INT_MSK) | (1 << sram_ch->irq_bit));
tmp = cx_read(sram_ch->int_msk);
cx_write(sram_ch->int_msk, tmp |= _intr_msk);
@@ -727,7 +718,7 @@ int cx25821_start_video_dma_upstream_ch2(struct cx25821_dev *dev,
dev->pci->irq);
goto fail_irq;
}
- /* Start the DMA engine */
+ /* Start the DMA engine */
tmp = cx_read(sram_ch->dma_ctl);
cx_set(sram_ch->dma_ctl, tmp | FLD_VID_RISC_EN);
@@ -736,7 +727,7 @@ int cx25821_start_video_dma_upstream_ch2(struct cx25821_dev *dev,
return 0;
- fail_irq:
+ fail_irq:
cx25821_dev_unregister(dev);
return err;
}
@@ -758,7 +749,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, int channel_select,
}
dev->_channel2_upstream_select = channel_select;
- sram_ch = dev->channels[channel_select].sram_channels;
+ sram_ch = dev->channels[channel_select].sram_channels;
INIT_WORK(&dev->_irq_work_entry_ch2, cx25821_vidups_handler_ch2);
dev->_irq_queues_ch2 =
@@ -769,10 +760,10 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, int channel_select,
("cx25821: create_singlethread_workqueue() for Video FAILED!\n");
return -ENOMEM;
}
- /*
- 656/VIP SRC Upstream Channel I & J and 7 -
- Host Bus Interface for channel A-C
- */
+ /*
+ * 656/VIP SRC Upstream Channel I & J and 7 -
+ * Host Bus Interface for channel A-C
+ */
tmp = cx_read(VID_CH_MODE_SEL);
cx_write(VID_CH_MODE_SEL, tmp | 0x1B0001FF);
@@ -808,7 +799,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, int channel_select,
str_length + 1);
}
- /* Default if filename is empty string */
+ /* Default if filename is empty string */
if (strcmp(dev->input_filename_ch2, "") == 0) {
if (dev->_isNTSC_ch2) {
dev->_filename_ch2 =
@@ -833,7 +824,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, int channel_select,
dev->upstream_riscbuf_size_ch2 = risc_buffer_size * 2;
dev->upstream_databuf_size_ch2 = data_frame_size * 2;
- /* Allocating buffers and prepare RISC program */
+ /* Allocating buffers and prepare RISC program */
retval =
cx25821_upstream_buffer_prepare_ch2(dev, sram_ch,
dev->_line_size_ch2);
@@ -848,7 +839,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev, int channel_select,
return 0;
- error:
+ error:
cx25821_dev_unregister(dev);
return err;
diff --git a/drivers/staging/cx25821/cx25821-video-upstream-ch2.h b/drivers/staging/cx25821/cx25821-video-upstream-ch2.h
index 6234063..029e830 100644
--- a/drivers/staging/cx25821/cx25821-video-upstream-ch2.h
+++ b/drivers/staging/cx25821/cx25821-video-upstream-ch2.h
@@ -88,14 +88,14 @@
#endif
#ifndef USE_RISC_NOOP_VIDEO
-#define PAL_US_VID_PROG_SIZE ((PAL_FIELD_HEIGHT + 1) * 3 * DWORD_SIZE + RISC_WRITECR_INSTRUCTION_SIZE )
-#define PAL_RISC_BUF_SIZE ( 2 * (RISC_SYNC_INSTRUCTION_SIZE + PAL_US_VID_PROG_SIZE) )
+#define PAL_US_VID_PROG_SIZE ((PAL_FIELD_HEIGHT + 1) * 3 * DWORD_SIZE + RISC_WRITECR_INSTRUCTION_SIZE)
+#define PAL_RISC_BUF_SIZE (2 * (RISC_SYNC_INSTRUCTION_SIZE + PAL_US_VID_PROG_SIZE))
#define PAL_VID_PROG_SIZE ((PAL_FIELD_HEIGHT*2) * 3 * DWORD_SIZE + 2*RISC_SYNC_INSTRUCTION_SIZE + \
- RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE )
-#define ODD_FLD_PAL_PROG_SIZE ((PAL_FIELD_HEIGHT) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE )
-#define ODD_FLD_NTSC_PROG_SIZE ((NTSC_ODD_FLD_LINES) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE )
+ RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
+#define ODD_FLD_PAL_PROG_SIZE ((PAL_FIELD_HEIGHT) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE)
+#define ODD_FLD_NTSC_PROG_SIZE ((NTSC_ODD_FLD_LINES) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE)
#define NTSC_US_VID_PROG_SIZE ((NTSC_ODD_FLD_LINES + 1) * 3 * DWORD_SIZE + RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
-#define NTSC_RISC_BUF_SIZE (2 * (RISC_SYNC_INSTRUCTION_SIZE + NTSC_US_VID_PROG_SIZE) )
+#define NTSC_RISC_BUF_SIZE (2 * (RISC_SYNC_INSTRUCTION_SIZE + NTSC_US_VID_PROG_SIZE))
#define FRAME1_VID_PROG_SIZE ((NTSC_ODD_FLD_LINES + NTSC_FIELD_HEIGHT) * 3 * DWORD_SIZE + 2*RISC_SYNC_INSTRUCTION_SIZE + \
- RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE )
+ RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
#endif
diff --git a/drivers/staging/cx25821/cx25821-video-upstream.c b/drivers/staging/cx25821/cx25821-video-upstream.c
index 756a820..16bf74d 100644
--- a/drivers/staging/cx25821/cx25821-video-upstream.c
+++ b/drivers/staging/cx25821/cx25821-video-upstream.c
@@ -39,7 +39,7 @@ MODULE_AUTHOR("Hiep Huynh <hiep.huynh@conexant.com>");
MODULE_LICENSE("GPL");
static int _intr_msk =
- FLD_VID_SRC_RISC1 | FLD_VID_SRC_UF | FLD_VID_SRC_SYNC | FLD_VID_SRC_OPC_ERR;
+ FLD_VID_SRC_RISC1 | FLD_VID_SRC_UF | FLD_VID_SRC_SYNC | FLD_VID_SRC_OPC_ERR;
int cx25821_sram_channel_setup_upstream(struct cx25821_dev *dev,
struct sram_channel *ch,
@@ -346,13 +346,13 @@ int cx25821_get_frame(struct cx25821_dev *dev, struct sram_channel *sram_ch)
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
- printk(KERN_ERR
+ printk(KERN_ERR
"%s(): ERROR opening file(%s) with errno = %d!\n",
__func__, dev->_filename, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
- printk(KERN_ERR
+ printk(KERN_ERR
"%s: File has no file operations registered!",
__func__);
filp_close(myfile, NULL);
@@ -360,7 +360,7 @@ int cx25821_get_frame(struct cx25821_dev *dev, struct sram_channel *sram_ch)
}
if (!myfile->f_op->read) {
- printk(KERN_ERR
+ printk(KERN_ERR
"%s: File has no READ operations registered!",
__func__);
filp_close(myfile, NULL);
@@ -415,7 +415,7 @@ static void cx25821_vidups_handler(struct work_struct *work)
container_of(work, struct cx25821_dev, _irq_work_entry);
if (!dev) {
- printk(KERN_ERR
+ printk(KERN_ERR
"ERROR %s(): since container_of(work_struct) FAILED!\n",
__func__);
return;
@@ -448,7 +448,7 @@ int cx25821_openfile(struct cx25821_dev *dev, struct sram_channel *sram_ch)
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
- printk(KERN_ERR
+ printk(KERN_ERR
"%s: File has no file operations registered!",
__func__);
filp_close(myfile, NULL);
@@ -456,7 +456,7 @@ int cx25821_openfile(struct cx25821_dev *dev, struct sram_channel *sram_ch)
}
if (!myfile->f_op->read) {
- printk(KERN_ERR
+ printk(KERN_ERR
"%s: File has no READ operations registered! \
Returning.",
__func__);
@@ -589,7 +589,7 @@ int cx25821_video_upstream_irq(struct cx25821_dev *dev, int chan_num,
u32 status)
{
u32 int_msk_tmp;
- struct sram_channel *channel = dev->channels[chan_num].sram_channels;
+ struct sram_channel *channel = dev->channels[chan_num].sram_channels;
int singlefield_lines = NTSC_FIELD_HEIGHT;
int line_size_in_bytes = Y422_LINE_SZ;
int odd_risc_prog_size = 0;
@@ -657,12 +657,12 @@ int cx25821_video_upstream_irq(struct cx25821_dev *dev, int chan_num,
Interrupt!\n", __func__);
if (status & FLD_VID_SRC_SYNC)
- printk(KERN_ERR "%s: Video Received Sync Error \
- Interrupt!\n", __func__);
+ printk(KERN_ERR "%s: Video Received Sync Error \
+ Interrupt!\n", __func__);
if (status & FLD_VID_SRC_OPC_ERR)
- printk(KERN_ERR "%s: Video Received OpCode Error \
- Interrupt!\n", __func__);
+ printk(KERN_ERR "%s: Video Received OpCode Error \
+ Interrupt!\n", __func__);
}
if (dev->_file_status == END_OF_FILE) {
@@ -690,7 +690,7 @@ static irqreturn_t cx25821_upstream_irq(int irq, void *dev_id)
channel_num = VID_UPSTREAM_SRAM_CHANNEL_I;
- sram_ch = dev->channels[channel_num].sram_channels;
+ sram_ch = dev->channels[channel_num].sram_channels;
msk_stat = cx_read(sram_ch->int_mstat);
vid_status = cx_read(sram_ch->int_stat);
@@ -811,7 +811,7 @@ int cx25821_vidupstream_init_ch1(struct cx25821_dev *dev, int channel_select,
}
dev->_channel_upstream_select = channel_select;
- sram_ch = dev->channels[channel_select].sram_channels;
+ sram_ch = dev->channels[channel_select].sram_channels;
INIT_WORK(&dev->_irq_work_entry, cx25821_vidups_handler);
dev->_irq_queues = create_singlethread_workqueue("cx25821_workqueue");
diff --git a/drivers/staging/cx25821/cx25821-video-upstream.h b/drivers/staging/cx25821/cx25821-video-upstream.h
index 10dee5c..f0b3ac0 100644
--- a/drivers/staging/cx25821/cx25821-video-upstream.h
+++ b/drivers/staging/cx25821/cx25821-video-upstream.h
@@ -97,13 +97,13 @@
#define PAL_RISC_BUF_SIZE (2 * PAL_US_VID_PROG_SIZE)
#define PAL_VID_PROG_SIZE ((PAL_FIELD_HEIGHT*2) * 3 * DWORD_SIZE + 2*RISC_SYNC_INSTRUCTION_SIZE + \
- RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE )
+ RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
-#define ODD_FLD_PAL_PROG_SIZE ((PAL_FIELD_HEIGHT) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE )
-#define ODD_FLD_NTSC_PROG_SIZE ((NTSC_ODD_FLD_LINES) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE )
+#define ODD_FLD_PAL_PROG_SIZE ((PAL_FIELD_HEIGHT) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE)
+#define ODD_FLD_NTSC_PROG_SIZE ((NTSC_ODD_FLD_LINES) * 3 * DWORD_SIZE + RISC_SYNC_INSTRUCTION_SIZE + RISC_WRITECR_INSTRUCTION_SIZE)
#define NTSC_US_VID_PROG_SIZE ((NTSC_ODD_FLD_LINES + 1) * 3 * DWORD_SIZE + RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
-#define NTSC_RISC_BUF_SIZE ( 2 * (RISC_SYNC_INSTRUCTION_SIZE + NTSC_US_VID_PROG_SIZE) )
+#define NTSC_RISC_BUF_SIZE (2 * (RISC_SYNC_INSTRUCTION_SIZE + NTSC_US_VID_PROG_SIZE))
#define FRAME1_VID_PROG_SIZE ((NTSC_ODD_FLD_LINES + NTSC_FIELD_HEIGHT) * 3 * DWORD_SIZE + 2*RISC_SYNC_INSTRUCTION_SIZE + \
- RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE )
+ RISC_WRITECR_INSTRUCTION_SIZE + JUMP_INSTRUCTION_SIZE)
#endif
diff --git a/drivers/staging/cx25821/cx25821.h b/drivers/staging/cx25821/cx25821.h
index 1b628f6..c940001 100644
--- a/drivers/staging/cx25821/cx25821.h
+++ b/drivers/staging/cx25821/cx25821.h
@@ -91,10 +91,10 @@
/* Currently supported by the driver */
#define CX25821_NORMS (\
- V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_JP | V4L2_STD_NTSC_M_KR | \
- V4L2_STD_PAL_BG | V4L2_STD_PAL_DK | V4L2_STD_PAL_I | \
- V4L2_STD_PAL_M | V4L2_STD_PAL_N | V4L2_STD_PAL_H | \
- V4L2_STD_PAL_Nc )
+ V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_JP | V4L2_STD_NTSC_M_KR | \
+ V4L2_STD_PAL_BG | V4L2_STD_PAL_DK | V4L2_STD_PAL_I | \
+ V4L2_STD_PAL_M | V4L2_STD_PAL_N | V4L2_STD_PAL_H | \
+ V4L2_STD_PAL_Nc)
#define CX25821_BOARD_CONEXANT_ATHENA10 1
#define MAX_VID_CHANNEL_NUM 12
@@ -139,7 +139,7 @@ struct cx25821_fh {
/* video capture */
struct cx25821_fmt *fmt;
unsigned int width, height;
- int channel_id;
+ int channel_id;
/* vbi capture */
struct videobuf_queue vidq;
@@ -238,26 +238,25 @@ struct cx25821_data {
};
struct cx25821_channel {
- struct v4l2_prio_state prio;
+ struct v4l2_prio_state prio;
- int ctl_bright;
- int ctl_contrast;
- int ctl_hue;
- int ctl_saturation;
+ int ctl_bright;
+ int ctl_contrast;
+ int ctl_hue;
+ int ctl_saturation;
+ struct cx25821_data timeout_data;
- struct cx25821_data timeout_data;
+ struct video_device *video_dev;
+ struct cx25821_dmaqueue vidq;
- struct video_device *video_dev;
- struct cx25821_dmaqueue vidq;
+ struct sram_channel *sram_channels;
- struct sram_channel *sram_channels;
-
- struct mutex lock;
- int resources;
+ struct mutex lock;
+ int resources;
- int pixel_formats;
- int use_cif_resolution;
- int cif_width;
+ int pixel_formats;
+ int use_cif_resolution;
+ int cif_width;
};
struct cx25821_dev {
@@ -283,7 +282,7 @@ struct cx25821_dev {
int nr;
struct mutex lock;
- struct cx25821_channel channels[MAX_VID_CHANNEL_NUM];
+ struct cx25821_channel channels[MAX_VID_CHANNEL_NUM];
/* board details */
unsigned int board;
@@ -311,7 +310,7 @@ struct cx25821_dev {
int _audio_lines_count;
int _audioframe_count;
int _audio_upstream_channel_select;
- int _last_index_irq; /* The last interrupt index processed. */
+ int _last_index_irq; /* The last interrupt index processed. */
__le32 *_risc_audio_jmp_addr;
__le32 *_risc_virt_start_addr;
@@ -443,7 +442,7 @@ static inline struct cx25821_dev *get_cx25821(struct v4l2_device *v4l2_dev)
}
#define cx25821_call_all(dev, o, f, args...) \
- v4l2_device_call_all(&dev->v4l2_dev, 0, o, f, ##args)
+ v4l2_device_call_all(&dev->v4l2_dev, 0, o, f, ##args)
extern struct list_head cx25821_devlist;
extern struct cx25821_board cx25821_boards[];
@@ -491,7 +490,7 @@ struct sram_channel {
u32 fld_aud_fifo_en;
u32 fld_aud_risc_en;
- /* For Upstream Video */
+ /* For Upstream Video */
u32 vid_fmt_ctl;
u32 vid_active_ctl1;
u32 vid_active_ctl2;
@@ -511,8 +510,8 @@ extern struct sram_channel cx25821_sram_channels[];
#define cx_write(reg, value) writel((value), dev->lmmio + ((reg)>>2))
#define cx_andor(reg, mask, value) \
- writel((readl(dev->lmmio+((reg)>>2)) & ~(mask)) |\
- ((value) & (mask)), dev->lmmio+((reg)>>2))
+ writel((readl(dev->lmmio+((reg)>>2)) & ~(mask)) |\
+ ((value) & (mask)), dev->lmmio+((reg)>>2))
#define cx_set(reg, bit) cx_andor((reg), (bit), (bit))
#define cx_clear(reg, bit) cx_andor((reg), (bit), 0)
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
^ permalink raw reply related
* Re: memory clobber in rx path, maybe related to ath9k.
From: Johannes Berg @ 2010-10-07 19:27 UTC (permalink / raw)
To: Ben Greear; +Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <4CAE1DFB.303@candelatech.com>
On Thu, 2010-10-07 at 12:22 -0700, Ben Greear wrote:
> After reboot, and re-run of the script,
> I saw this in the logs, and shortly after,
> the SLUB poison warning dumped to screen.
>
> Maybe those DMA errors are serious?
> ath: Failed to stop TX DMA in 100 msec after killing last frame
> ath: Failed to stop TX DMA. Resetting hardware!
That's TX DMA, it can hardly result in invalid memory writes like the
ones you've been seeing.
I'm still convinced something is wrong with ath9k RX DMA, as you've seen
the contents of frames written to already freed memory regions. Since I
don't know anything about ath9k, you should probably not rely on me
though :-)
johannes
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/5] spice: add config options for channel security.
From: Gerd Hoffmann @ 2010-10-07 19:26 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel
In-Reply-To: <4CAE14C4.8090604@mail.berlios.de>
>> + if (strcmp(name, "tls-channel") == 0)
>> + security = SPICE_CHANNEL_SECURITY_SSL;
>
> CODING_STYLE (if (...) { ... })? Same in next lines.
Oops. Slipped through, will fix.
thanks,
Gerd
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Tejun Heo @ 2010-10-07 19:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, just.for.lkml, herbert, hch, neilb,
dm-devel
In-Reply-To: <AANLkTi=LsBNU+O2hqZUcM2nYM_ze6qPq3thwSZBMtY_v@mail.gmail.com>
Hello, Linus.
On 10/06/2010 11:45 PM, Linus Torvalds wrote:
> So I decided to break my a-week-is-eight-days rut, and actually
> release -rc7 after a proper seven-day week instead. Wo-oo!
>
> And yes, that's probably as exciting as it gets, which is just fine by
> me. This should be the last -rc, I'm not seeing any reason to keep
> delaying a real release. There was still more changes to
> drivers/gpu/drm than I really would have hoped for, but they all look
> harmless and good. Famous last words.
I'm afraid there is a possibly workqueue related deadlock under high
memory pressure. It happens on dm-crypt + md raid1 configuration.
I'm not yet sure whether this is caused by workqueue failing to kick
rescuers under memory pressure or the shared workqueue is making an
already existing problem more visible and in the process of setting up
an environment to reproduce the problem.
http://thread.gmane.org/gmane.comp.file-systems.xfs.general/34922/focus=1044784
Thanks.
--
tejun
^ permalink raw reply
* RE: New Hypercall Declaration
From: Nimgaonkar, Satyajeet @ 2010-10-07 19:28 UTC (permalink / raw)
To: Dan Magenheimer, xen-devel@lists.xensource.com
In-Reply-To: <e081449e-ba8d-41d9-9aba-30c493acd268@default>
[-- Attachment #1.1: Type: text/plain, Size: 6826 bytes --]
Hi Dan,
But if you look at xen.h, 48-55 are architecture specific hypercalls, and if I do rept endr from 49-55 as per your advice wouldn't I be overriding those hypercalls?
________________________________
From: Dan Magenheimer [dan.magenheimer@oracle.com]
Sent: Thursday, October 07, 2010 12:07 PM
To: Nimgaonkar, Satyajeet; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration
The hypercall_table and hypercall_args_table are initialized sequences of quads and bytes. Even though you have put 56 in the comment, you are initializing the table entry immediately following the 48th entry, which would be hypercall 49. You need to fill the entries from 49 to 55 in both tables with the appropriate values. (The assembler syntax for these tables is weird, e.g. endr and rept, and I am not an expert on it.)
From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@my.unt.edu]
Sent: Thursday, October 07, 2010 11:37 AM
To: Dan Magenheimer; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration
Hi Dan,
I followed your instruction from the below email, but still I am getting -1 for hypercall invocation. These are the steps I followed.
1. Add my hypercall in xen.h ---- #define __HYPERVISOR_jeet1 56
2. Added it to entry.S - hypercall table ---- .quad do_mca /* 48 */
.quad do_jeet1 /* 56 */
- hypercall_args_table ---- .byte 1 /* do_mca */ /* 48 */
.byte 0 /* do_jeet1 */ /* 56 */
3. Then declared my hypercall in asm-x86/hypercall.h ---- void do_jeet1(void);
4. Then calling it in domctl.c in xen/common --- void do_jeet1(void){
printk ("Successfull Hypercall made to __HYPERVISOR_jeet1");
}
5. Declared a function in xc_domain.c in xen/tools to call this hypercall
int hypercall_test(int handle){
int rc;
int arg=0;
//int cmd=1;
//
//int test;
/* Hypercall definitions */
DECLARE_HYPERCALL;
hypercall.op = __HYPERVISOR_jeet1;
rc = do_xen_hypercall(handle, &hypercall);
hypercall.arg[0] = 0;
hypercall.arg[1] = (unsigned long)&arg;
//printf ("Hypercall Details: %d\n", rc);
//xc_interface_close(handle);
return rc;
}
6. Then wrote a userlevel program to call function hypercall_test and invoke my hypercall.
#include <xenctrl.h>
#include <stdio.h>
int main(){
printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
int handle, rc;
/* Acquire Hypervisor Interface Handle.
This handle goes as the first argument for the function do_xen_hypercall()
*/
handle = xc_interface_open();
printf ("Acquired handle to Xen Hypervisor:%d\n",handle);
rc = hypercall_test(handle);
printf ("Hypercall Details: %d\n", rc);
xc_interface_close(handle);
printf ("Hypervisor handle closed\n");
return 0;
}
I compiled entire xen, installed it and booted into the atest compiled xen. But still my userlevel program compiles error free but returns me a -1 error for hypercall invocation. Can you please tell me what is that I doing wrong.
Thanks.
Regards,
Satyajeet Nimgaonkar
________________________________
From: Dan Magenheimer [dan.magenheimer@oracle.com]
Sent: Thursday, September 30, 2010 4:47 PM
To: Nimgaonkar, Satyajeet; xen-devel@lists.xensource.com
Subject: RE: [Xen-devel] New Hypercall Declaration
Do you understand that you must also change the hypervisor to recognize and do something with your new hypercall? Your userland code may actually be working and the hypercall may actually be resulting in an entry into the hypervisor, but unless the hypervisor is modified to recognize the new hypercall (#56) and do something with it, the hypervisor will generate a return value of -1 (essentially saying “I don’t recognize this hypercall number”).
If you have modified the hypervisor, please share that patch. If not, you will need to modify at least the hypercall_table and the hypercall_args_table in entry.S (under x86, x86_64, and x86_64/compat, or all three, depending on the bit-ness of your hypervisor and guest) and create a do_my_hypercall() routine somewhere. Then of course you will need to ensure that you are properly building, installing, and booting your newly modified hypervisor.
Printk’s done inside the hypervisor can be viewed using “xm dmesg” or via a properly configured serial port.
Use “xm info” and look at cc_compile_date to ensure you are booting your newly modified hypervisor.
Hope that helps,
Dan
From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@my.unt.edu]
Sent: Thursday, September 30, 2010 4:03 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] New Hypercall Declaration
Hello Xen Developers,
I am currently working on declaring a new hypercall in Xen.
For this i have declared my hypercall in xen.h -
#define __HYPERVISOR_jeet1 56
Then I modified the xcom_privcmd.c to accomodate my hypercall -
case __HYPERVISOR_jeet1:
printk("Successfull Hypercall made to
__HYPERVISOR_jeet1");
I defined the structure for the Hypercall in xc_domain.c
int hypercall_test(int handle){
int rc;
/* Hypercall definitions */
DECLARE_HYPERCALL;
hypercall.op = __HYPERVISOR_jeet1;
rc = do_xen_hypercall(handle, &hypercall);
hypercall.arg[0] = 0;
hypercall.arg[1] = 1;
//printf ("Hypercall Details: %d\n", rc);
//xc_interface_close(handle);
return rc;
}
And then I am calling this Hypercall through an user level program-
#include <xenctrl.h>
#include <stdio.h>
int main(){
printf("Attempt to invoke the hypercall: __HYPERVISOR_jeet1\n");
int handle, rc;
/* Acquire Hypervisor Interface Handle.
This handle goes as the first argument for the function do_xen_hypercall()
*/
handle = xc_interface_open();
printf ("Acquired handle to Xen Hypervisor:%d\n",handle);
rc = hypercall_test(handle);
printf ("Hypercall Details: %d\n", rc);
xc_interface_close(handle);
return 0;
}
The program compiles properly but gives me -1 error for rc. I have posted the same query and I got replies on it. But even after trying many things, I am still stuck with this problem. Can anyone please tell me what I am doing wrong here. Also please tell me where
should I view the output of printk in xen.
Thanks in advance.
Regards,
Satyajeet Nimgaonkar
[-- Attachment #1.2: Type: text/html, Size: 17270 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH] Documentation: update-index: -z applies also to --index-info
From: Štěpán Němec @ 2010-10-07 19:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Bert Wesarg, Junio C Hamano, git
In-Reply-To: <20101007191548.GA11955@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Bert Wesarg wrote:
>> On Thu, Oct 7, 2010 at 20:52, Bert Wesarg <bert.wesarg@googlemail.com>
> wrote:
>>> On Thu, Oct 7, 2010 at 20:33, Štěpán Němec <stepnem@gmail.com> wrote:
>
>>>> There is actually at least one more problem with the current SYNOPSIS of
>>>> `update-index'. Obviously the `*' on the third line of the Asciidoc
>>>> source makes the whole `--cacheinfo' line disappear and the rest bold
>>>> (cf. e.g. the result at
>>>> <http://www.kernel.org/pub/software/scm/git/docs/git-update-index.html>).
>>
>> ls-files too:
>> http://www.kernel.org/pub/software/scm/git/docs/git-ls-files.html
>
> Hmph, this is from v1.7.3-rc0~15^2~9 (Documentation: remove backslashes
> in manpage synopses, 2010-08-20). And it still works for me locally
> (for both manpage and HTML generation). :(
>
> Anyway, the "..." fix sounds good to me (or {asterisk} if the stars are
> still wanted).
Yeah, there are some more actually. I'll send in a separate patch shortly.
Štěpán
^ permalink raw reply
* [PATCH] Make it possible to set a uuid if one was not set during DM_DEV_CREATE.
From: Peter Jones @ 2010-10-07 19:28 UTC (permalink / raw)
To: dm-devel; +Cc: Peter Jones
This makes it possible to use DM_DEV_RENAME to add a uuid to a device so
long as one has not been previously set either with DM_DEV_CREATE or
with DM_DEV_RENAME.
Also bump the minor number to 19.
---
drivers/md/dm-ioctl.c | 113 ++++++++++++++++++++++++++++++++-------------
include/linux/dm-ioctl.h | 9 +++-
2 files changed, 87 insertions(+), 35 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 3e39193..bd76846 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -298,7 +298,7 @@ retry:
static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
const char *new)
{
- char *new_name, *old_name;
+ char *new_data, *old_data;
struct hash_cell *hc;
struct dm_table *table;
struct mapped_device *md;
@@ -306,8 +306,8 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
/*
* duplicate new.
*/
- new_name = kstrdup(new, GFP_KERNEL);
- if (!new_name)
+ new_data = kstrdup(new, GFP_KERNEL);
+ if (!new_data)
return ERR_PTR(-ENOMEM);
down_write(&_hash_lock);
@@ -315,14 +315,28 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
/*
* Is new free ?
*/
- hc = __get_name_cell(new);
- if (hc) {
- DMWARN("asked to rename to an already-existing name %s -> %s",
- param->name, new);
- dm_put(hc->md);
- up_write(&_hash_lock);
- kfree(new_name);
- return ERR_PTR(-EBUSY);
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ hc = __get_uuid_cell(new);
+ if (hc) {
+ DMWARN("asked to change uuid to an already-existing uuid"
+ " %s -> %s",
+ param->name, new);
+ dm_put(hc->md);
+ up_write(&_hash_lock);
+ kfree(new_data);
+ return ERR_PTR(-EBUSY);
+ }
+ } else {
+ hc = __get_name_cell(new);
+ if (hc) {
+ DMWARN("asked to rename to an already-existing name "
+ "%s -> %s",
+ param->name, new);
+ dm_put(hc->md);
+ up_write(&_hash_lock);
+ kfree(new_data);
+ return ERR_PTR(-EBUSY);
+ }
}
/*
@@ -333,19 +347,42 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
DMWARN("asked to rename a non-existent device %s -> %s",
param->name, new);
up_write(&_hash_lock);
- kfree(new_name);
+ kfree(new_data);
return ERR_PTR(-ENXIO);
}
- /*
- * rename and move the name cell.
- */
- list_del(&hc->name_list);
- old_name = hc->name;
- mutex_lock(&dm_hash_cells_mutex);
- hc->name = new_name;
- mutex_unlock(&dm_hash_cells_mutex);
- list_add(&hc->name_list, _name_buckets + hash_str(new_name));
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ /*
+ * Does this device already have a uuid?
+ */
+ if (hc->uuid) {
+ DMWARN("asked to change uuid of device with uuid "
+ "already set %s %s -> %s",
+ param->name, hc->uuid, param->uuid);
+ up_write(&_hash_lock);
+ kfree(new_uuid);
+ return ERR_PTR(-EINVAL);
+ }
+ /*
+ * reuuid and move the uuid cell.
+ */
+ list_del(&hc->uuid_list);
+ old_data = hc->uuid;
+ mutex_lock(&dm_hash_cells_mutex);
+ hc->uuid = new_data;
+ mutex_unlock(&dm_hash_cells_mutex);
+ list_add(&hc->uuid_list, _uuid_buckets + hash_str(new_data));
+ } else {
+ /*
+ * rename and move the name cell.
+ */
+ list_del(&hc->name_list);
+ old_data = hc->name;
+ mutex_lock(&dm_hash_cells_mutex);
+ hc->name = new_data;
+ mutex_unlock(&dm_hash_cells_mutex);
+ list_add(&hc->name_list, _name_buckets + hash_str(new_data));
+ }
/*
* Wake up any dm event waiters.
@@ -361,7 +398,7 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
md = hc->md;
up_write(&_hash_lock);
- kfree(old_name);
+ kfree(old_data);
return md;
}
@@ -774,21 +811,31 @@ static int invalid_str(char *str, void *end)
static int dev_rename(struct dm_ioctl *param, size_t param_size)
{
int r;
- char *new_name = (char *) param + param->data_start;
+ char *new_data = (char *) param + param->data_start;
struct mapped_device *md;
- if (new_name < param->data ||
- invalid_str(new_name, (void *) param + param_size) ||
- strlen(new_name) > DM_NAME_LEN - 1) {
- DMWARN("Invalid new logical volume name supplied.");
- return -EINVAL;
- }
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ struct hash_cell *hc;
+ if (new_data < param->data ||
+ invalid_str(new_data, (void *) param + param_size) ||
+ strlen(new_data) > DM_UUID_LEN - 1) {
+ DMWARN("Invalid new logical volume uuid supplied.");
+ return -EINVAL;
+ }
+ } else {
+ if (new_data < param->data ||
+ invalid_str(new_data, (void *) param + param_size) ||
+ strlen(new_data) > DM_NAME_LEN - 1) {
+ DMWARN("Invalid new logical volume name supplied.");
+ return -EINVAL;
+ }
- r = check_name(new_name);
- if (r)
- return r;
+ r = check_name(new_data);
+ if (r)
+ return r;
+ }
- md = dm_hash_rename(param, new_name);
+ md = dm_hash_rename(param, new_data);
if (IS_ERR(md))
return PTR_ERR(md);
diff --git a/include/linux/dm-ioctl.h b/include/linux/dm-ioctl.h
index 49eab36..e369460 100644
--- a/include/linux/dm-ioctl.h
+++ b/include/linux/dm-ioctl.h
@@ -267,9 +267,9 @@ enum {
#define DM_DEV_SET_GEOMETRY _IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD, struct dm_ioctl)
#define DM_VERSION_MAJOR 4
-#define DM_VERSION_MINOR 18
+#define DM_VERSION_MINOR 19
#define DM_VERSION_PATCHLEVEL 0
-#define DM_VERSION_EXTRA "-ioctl (2010-06-29)"
+#define DM_VERSION_EXTRA "-ioctl (2010-10-07)"
/* Status bits */
#define DM_READONLY_FLAG (1 << 0) /* In/Out */
@@ -322,4 +322,9 @@ enum {
*/
#define DM_UEVENT_GENERATED_FLAG (1 << 13) /* Out */
+/*
+ * If set, rename operates on uuid, not name.
+ */
+#define DM_NEW_UUID_FLAG (1 << 14) /* In */
+
#endif /* _LINUX_DM_IOCTL_H */
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH 1/3] pnfs_submit: move layout segment valid test
From: William A. (Andy) Adamson @ 2010-10-07 19:28 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs
In-Reply-To: <4CAE16FA.9040606@panasas.com>
On Thu, Oct 7, 2010 at 2:52 PM, Benny Halevy <bhalevy@panasas.com> wrote:
> On 2010-10-07 15:37, andros@netapp.com wrote:
>> From: Andy Adamson <andros@rhel6-1.androsmac.org>
>>
>> Do not get_lseg for a non-valid lseg.
>> Prepare for calling put_lseg outside of inode i_lock.
>>
>> Signed-off-by: Andy Adamson <andros@netapp.com>
>> ---
>> fs/nfs/pnfs.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
>> index 6b2a95d..24620cf 100644
>> --- a/fs/nfs/pnfs.c
>> +++ b/fs/nfs/pnfs.c
>> @@ -845,7 +845,8 @@ pnfs_has_layout(struct pnfs_layout_hdr *lo,
>> list_for_each_entry(lseg, &lo->segs, fi_list) {
>> if (is_matching_lseg(lseg, range)) {
>> ret = lseg;
>> - get_lseg(ret);
>> + if (lseg->valid)
>> + get_lseg(ret);
>
> We shouldn't be hiding this inside pnfs_has_layout
> and have different side effects in the different cases.
Sorry - I just looked at the pnfs-submit branch. I should have looked
at the pnfs-all branch and seen the other callers of pnfs_has_layout.
> Since we're called under the lock, pnfs_has_layout
> can just return the lseg and never get a reference and its
> caller can take it if necessary before releasing the lock.
>
> Also, it doesn't need to be EXPORT_SYMBOL_GPLed as it's
> not used outside of the nfs client module.
Right - Fred just removed the call in the file layout driver.
I'll fix this.
-->Andy
>
> Benny
>
>> break;
>> }
>> if (cmp_layout(range, &lseg->range) > 0)
>> @@ -889,7 +890,6 @@ pnfs_update_layout(struct inode *ino,
>> /* Check to see if the layout for the given range already exists */
>> lseg = pnfs_has_layout(lo, &arg);
>> if (lseg && !lseg->valid) {
>> - put_lseg_locked(lseg);
>> /* someone is cleaning the layout */
>> lseg = NULL;
>> goto out_unlock;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/5] spice: make compression configurable.
From: Gerd Hoffmann @ 2010-10-07 19:29 UTC (permalink / raw)
To: Blue Swirl; +Cc: Yonit Halperin, qemu-devel
In-Reply-To: <AANLkTi=LnJ0dY7pEGRxdgw5YoG1KTUEh4AcmCQ5MEUOO@mail.gmail.com>
On 10/07/10 20:12, Blue Swirl wrote:
> On Thu, Oct 7, 2010 at 7:55 AM, Gerd Hoffmann<kraxel@redhat.com> wrote:
>> From: Yonit Halperin<yhalperi@redhat.com>
>>
>
> No description?
Detailed description comes here:
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -704,6 +704,15 @@ The x509 file names can also be configured individually.
>> @item tls-ciphers=<list>
>> Specify which ciphers to use.
>>
>> +@item image-compression=[auto_glz|auto_lz|quic|glz|lz|off]
>> +Configure image compression (lossless).
>> +Default is auto_glz.
>> +
>> +@item jpeg-wan-compression=[auto|never|allways]
>> +@item zlib-glz-wan-compression=[auto|never|allways]
>
> 'allways' does not match what the code uses:
>
>> + [ SPICE_WAN_COMPRESSION_ALWAYS ] = "always",
Good catch, will fix.
thanks,
Gerd
^ permalink raw reply
* Re: [PATCH v1 06/16] OMAP3: hwmod DSS: Build omap_device for each DSS HWIP
From: Thomas Petazzoni @ 2010-10-07 19:30 UTC (permalink / raw)
To: Guruswamy Senthilvadivu
Cc: khilman, tomi.valkeinen, paul, hvaibhav, linux-omap
In-Reply-To: <1286363699-9614-7-git-send-email-svadivu@ti.com>
Hello Senthil,
On Wed, 6 Oct 2010 16:44:49 +0530
Guruswamy Senthilvadivu <svadivu@ti.com> wrote:
> void __init omap_display_init(struct omap_dss_board_info
> *board_data)
> {
> + struct omap_hwmod *oh;
> + struct omap_device *od;
> + int l, i;
> + struct omap_display_platform_data pdata;
> + char *oh_name[] = {
> + "dss_dss",
> + "dss_dispc",
> + "dss_dsi1",
> + "dss_rfbi",
> + "dss_venc"
> + };
I think it's more common to write it this way:
char *oh_name[] = { "dss_dss", "dss_dispc", "dss_dsi1",
"dss_rfbi", "dss_venc" };
but I understand that this is just a matter of taste.
> +
> + for (i = 0; i < ARRAY_SIZE(oh_name); i++) {
> + l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
> + oh_name[i]);
> + WARN(l >= MAX_OMAP_DSS_HWMOD_NAME_LEN,
> + "String buffer overflow in DSS device setup\n");
Using snprintf() just to get the length of a string is a bit overkill.
strlen() is part of the kernel API :-)
However, about the name, see below.
> +
> + oh = omap_hwmod_lookup(oh_name[i]);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name[i]);
> + return ;
No space needed between return and the semi-colon.
> + }
> + strncpy(pdata.name, oh_name[i], sizeof(oh_name[i]));
Why do you need this name into the platform_data ? omap_device_build()
will already fill the omap_device->platform_device->name field with
exactly oh_name[i]. So your drivers can just do platform_device->name
to get the name if they need it.
> + pdata.board_data = board_data;
> + pdata.board_data->get_last_off_on_transaction_id = NULL;
> + pdata.device_enable = omap_device_enable;
> + pdata.device_idle = omap_device_idle;
> + pdata.device_shutdown = omap_device_shutdown;
pdata is defined outside of the loop, so you're passing the same pdata
address to each omap_device_build() call. Therefore, there's no need to
initialize pdata at each iteration of the loop.
> +struct omap_display_platform_data {
> + char name[MAX_OMAP_DSS_HWMOD_NAME_LEN];
> + struct omap_dss_board_info *board_data;
> + int (*device_enable)(struct platform_device *pdev);
> + int (*device_shutdown)(struct platform_device *pdev);
> + int (*device_idle)(struct platform_device *pdev);
> +};
I'm probably missing something, but I don't see those new
device_enable, device_shutdown, device_idle fields being used in the
following patches in your series. Did I look at the wrong place ?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] Please pull hwpoison fixes for 2.6.36
From: Andi Kleen @ 2010-10-07 19:30 UTC (permalink / raw)
To: torvalds, linux-kernel
Hi Linus,
Some last minute hwpoison bug fixes. It turned out the address
granuality information for errors was not passed out to user space,
and this broke someone who wanted to use it. Fixed this
with a straight forward change to signal.c. And a couple of other
bug fixes that have accumulated.
Please consider pulling. Thanks,
-Andi
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison-fixes
Andi Kleen (3):
HWPOISON: Copy si_addr_lsb to user
HWPOISON: Report correct address granuality for AO huge page errors
HWPOISON: Stop shrinking at right page count
Naoya Horiguchi (1):
page-types.c: fix name of unpoison interface
Documentation/vm/page-types.c | 2 +-
kernel/signal.c | 8 ++++++++
mm/memory-failure.c | 12 ++++++------
3 files changed, 15 insertions(+), 7 deletions(-)
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] mtd/nand.h: little more cleanup
From: Artem Bityutskiy @ 2010-10-07 19:30 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linux-mtd, Wolfram Sang
In-Reply-To: <20101006210614.GA18551@www.tglx.de>
On Wed, 2010-10-06 at 23:06 +0200, Sebastian Andrzej Siewior wrote:
> - remove tabs between type and name.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> include/linux/mtd/nand.h | 315 +++++++++++++++++++++------------------------
> 1 files changed, 147 insertions(+), 168 deletions(-)
This one was not compile-tested:
[dedekind@brekeke l2-mtd-2.6]$ make -j2
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC [M] drivers/mtd/devices/doc2000.o
CC [M] drivers/mtd/devices/doc2001.o
CC [M] drivers/mtd/devices/doc2001plus.o
CC [M] drivers/mtd/devices/docprobe.o
CC [M] drivers/mtd/nand/nand_base.o
drivers/mtd/nand/nand_base.c: In function ‘nand_command’:
drivers/mtd/nand/nand_base.c:589: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c: In function ‘nand_command_lp’:
drivers/mtd/nand/nand_base.c:680: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c: In function ‘nand_flash_detect_onfi’:
drivers/mtd/nand/nand_base.c:2890: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c: In function ‘nand_get_flash_type’:
drivers/mtd/nand/nand_base.c:2977: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c:3099: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c:3103: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c:3104: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c:3106: error: ‘struct nand_chip’ has no member named ‘chipsize’
drivers/mtd/nand/nand_base.c: In function ‘nand_scan_ident’:
drivers/mtd/nand/nand_base.c:3216: error: ‘struct nand_chip’ has no member named ‘chipsize’
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* [Qemu-devel] [ANNOUNCE] Git User's Survey 2010 is now up!
From: Stefan Weil @ 2010-10-07 19:31 UTC (permalink / raw)
To: QEMU Developers
This might be interesting for users of qemu-devel, too...
-------- Original-Nachricht --------
Betreff: [ANNOUNCE] Git User's Survey 2010 is now up!
Datum: Thu, 30 Sep 2010 01:20:21 +0200
Von: Jakub Narebski <jnareb@gmail.com>
An: Undisclosed.Recipients: ;
Hello all,
This announcement is sent to this mailing list because yout project
uses Git as a version control system.
We would like to ask you a few questions about your use of the Git
version control system. This survey is mainly to understand who is
using Git, how and why.
The results will be published to the Git wiki on the GitSurvey2010
page (https://git.wiki.kernel.org/index.php/GitSurvey2010) and
discussed on the git mailing list (git@vger.kernel.org).
The survey would be open from 1 September till 15 October 2010.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of Git, and of course what you don't like of it.
The survey can be found here:
http://tinyurl.com/GitSurvey2010
https://www.survs.com/survey/MUPYR8UJ4B
Git User's Survey 2010 was originally announced on git mailing list
in the following mail:
http://article.gmane.org/gmane.comp.version-control.git/154986
--
Jakub Narebski
on behalf of
Git Development Community
http://git-scm.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
^ permalink raw reply
* [U-Boot] packed attribute problem
From: Wolfgang Denk @ 2010-10-07 19:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007135257.05a93975@udp111988uds.am.freescale.net>
Dear Scott Wood,
In message <20101007135257.05a93975@udp111988uds.am.freescale.net> you wrote:
>
> > It is a pretty common method to use a pointer to some struct (for
> > example, some form of PDU) and make it point to some I/O buffer.
>
> Yes, but at that point we are not talking about well-defined C, but
> rather implementation-specific behavior. There's nothing wrong with
> it, but the C standard is no longer authoritative on what happens in
> such cases.
Huch? Which part of that is not well-defined (or even not
standard-conforming) C?
> Yes. And there would also be performance complaints if each of those
> accesses were to trap and be emulated (even ignoring weird stuff like
> old ARM). Thus it's nice to have some sort of pointer or data type
> annotation to tell the compiler to be careful.
I also complain about poor performance when instead of a single
instruction (a 32 bit load) at least 4 (8 bit) instructions need to be
executed.
> BTW, I see GCC splitting accesses to bitfields in a packed
> struct into bytes on powerpc, even with -mno-strict-align.
Indeed. Bitfields have always been evil.
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 at denx.de
"And it should be the law: If you use the word `paradigm' without
knowing what the dictionary says it means, you go to jail. No
exceptions." - David Jones @ Megatest Corporation
^ permalink raw reply
* Re: [PATCH] JFFS2: Dynamically choose inocache hash size
From: Artem Bityutskiy @ 2010-10-07 19:32 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-mtd, dwmw2
In-Reply-To: <20101007181402.982199D401B@zog.reactivated.net>
On Thu, 2010-10-07 at 19:14 +0100, Daniel Drake wrote:
> When JFFS2 is used for large volumes, the mount times are quite long.
> Increasing the hash size provides a significant speed boost on the OLPC
> XO-1 laptop.
>
> Add logic that dynamically selects a hash size based on the size of
> the medium. A 64mb medium will result in a hash size of 128, and a 512mb
> medium will result in a hash size of 1024.
>
> Signed-off-by: Daniel Drake <dsd@laptop.org>
Why is this complication needed? Unless there is a very good reason, I'd
just stick with older patch you sent, which I BTW also have in my
l2-mtd-2.6.git tree:
http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/22cf48a8673a8eabfd014de032e426452cce0fc9
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: pvops Dom0 graphics doesnt work with Intel i915
From: Pasi Kärkkäinen @ 2010-10-07 19:33 UTC (permalink / raw)
To: sanjay kushwaha; +Cc: Jeremy Fitzhardinge, xen-devel, Konrad Rzeszutek Wilk
In-Reply-To: <AANLkTi=ofd6F4hN2pp=vmmJu5vfp6kDkVs4MBJw9PLvi@mail.gmail.com>
On Thu, Oct 07, 2010 at 12:12:30PM -0700, sanjay kushwaha wrote:
> Hi Konrad,
> Unfortunately T410 doesnt have a serial port and neither does the docking
> station. I havent had any success with USB-to-Serial port dongles in the
> past. is there any way to get the serial port output?
>
Is that vPro laptop? If yes, then it should have Intel AMT (Active Management Technology),
which provides SOL (Serial Over Lan).
-- Pasi
> Thanks,
> Sanjay
>
> On Thu, Oct 7, 2010 at 11:05 AM, Konrad Rzeszutek Wilk
> <[1]konrad.wilk@oracle.com> wrote:
>
> On Thu, Oct 07, 2010 at 10:36:34AM -0700, sanjay kushwaha wrote:
> > Hi Konrad,
> > I tried your tree. It created a 2.6.32.15 based pvops kernel but
> graphics
> > with VT-d still doesn't work. when I give iommu=0 on xen kernel
> command line
> > in grub menu, graphics works but with iommu=1 it doesnt work (The
> whole
> > screen is garbage).
>
> Are there any warnings/debug messages in the serial log? Please follow
> the PVOPS Wiki on how to enable all the debug options.
> >
> >
> > On Wed, Oct 6, 2010 at 6:07 PM, Konrad Rzeszutek Wilk <
> > [2]konrad.wilk@oracle.com> wrote:
> >
> > > On Wed, Oct 06, 2010 at 04:02:51PM -0700, sanjay kushwaha wrote:
> > > > Thanks Pasi.
> > > >
> > > > Hi Konrad,
> > > > Could you please let me know how to get these backported drivers
> as
> > > > indicated by Pasi? This is the tree that I have.
> > >
> > > Just follow the Wiki. Oh, I need to update it.
> > >
> > > Here do this:
> > >
> > > git remote add konrad git://
> > > [3]git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > >
> > > git pull konrad
> > > git checkout konrad/devel/next.drm
> > >
> > > make
> > >
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$ git show
> > > > commit b297cdac0373625d3cd0e6f2b393570dcf2edba6
> > > > Merge: c6cfd01 64392f6
> > > > Author: Jeremy Fitzhardinge <[4]jeremy.fitzhardinge@citrix.com>
> > > > Date: Mon Sep 13 14:27:24 2010 -0700
> > > >
> > > > Merge branch 'xen/next' into xen/next-2.6.32
> > > >
> > > > * xen/next:
> > > > xen/netfront: Fix another potential race condition
> > > > Revert "xen/netfront: default smartpoll to on"
> > > >
> > > > [evans@vwifi0 linux-2.6.32.x]$
> > > >
> > > >
> > > > Thanks,
> > > > Sanjay
> > > >
> > > > On Wed, Oct 6, 2010 at 1:12 PM, Pasi Kärkkäinen <[5]pasik@iki.fi>
> wrote:
> > > >
> > > > > On Wed, Oct 06, 2010 at 10:50:57AM -0700, sanjay kushwaha wrote:
> > > > > > Hi,
> > > > > > I have run into more problems now. This time with VT-d.
> > > > > > When I enable VT-d on this laptop, graphics again stops
> working in
> > > > > dom0
> > > > > > with pvops (linux 2.6.32.21). the screen starts showing
> garbage as
> > > > > soon as
> > > > > > it switches into graphics mode.this happens when I boot the
> pvops
> > > > > kernel
> > > > > > both as dom0 and native linux. However, when I try 2.6.33
> based
> > > pvops
> > > > > > kernel (stable-2.6.33.x) graphics seems to work fine with
> VT-d
> > > when
> > > > > > running native but it doesnt work when running as Dom0.
> > > > > >
> > > > > > so now the problem is:
> > > > > >
> > > > > > with stable-2.6.32.x: graphics works in Dom0 without Vt-d
> but not
> > > with
> > > > > > VT-d (neither native nor Dom0).
> > > > > > with stable-2.6.33.x: graphics works with VT-d when running
> native
> > > but
> > > > > > doesnt work when running as Dom0 (with or without VT-d).
> > > > > >
> > > > >
> > > > > stable-2.6.33.x is not maintained, and you shouldn't use it.
> > > > >
> > > > > I think Konrad has a backport of the 2.6.34 drm/dri drivers
> > > > > to stable-2.6.32.x somewhere.. that might help.
> > > > >
> > > > > [6]http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > > >
> > > > > -- Pasi
> > > > >
> > > > > > I am experiencing this problem both with Lenovo T410, and
> Dell
> > > > > latitude
> > > > > > E6410.
> > > > > > Has anybody experienced this problem?
> > > > > >
> > > > > > Thanks,
> > > > > > Sanjay
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 11:06 AM, sanjay kushwaha
> > > > > > <[1][7]sanjay.kushwaha@gmail.com> wrote:
> > > > > >
> > > > > > havent tried stable-2.6.32.x on Radeon. It works with
> nomodeset
> > > and
> > > > > > nopat options with stable-2.6.33.x branch.
> > > > > >
> > > > > > On Fri, Oct 1, 2010 at 10:57 AM, Konrad Rzeszutek Wilk
> > > > > > <[2][8]konrad.wilk@oracle.com> wrote:
> > > > > >
> > > > > > On Fri, Oct 01, 2010 at 10:06:48AM -0700, sanjay
> kushwaha
> > > wrote:
> > > > > > > When I dont use nomodeset option, dom0 boots fine X
> runs
> > > > > properly.
> > > > > > So Fedora
> > > > > > > 13 (X86_64) distro with stable-2.6.32.x pvops kernel
> and
> > > > > > xen-unstable works
> > > > > > > fine for i915 without nomodeset option.
> > > > > >
> > > > > > Good to hear it works for you.
> > > > > >
> > > > > > What about your radeon laptop?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Sanjay
> > > > > > >
> > > > > > > On Wed, Sep 29, 2010 at 3:56 PM, sanjay kushwaha
> > > > > > > <[3][9]sanjay.kushwaha@gmail.com>wrote:
> > > > > > >
> > > > > > > > Hi Jeremy,
> > > > > > > > I switched to stable-2.6.32.x branch (which is
> 2.6.32.21
> > > > > based)
> > > > > > but I get
> > > > > > > > the same problem. Attached is the Xorg.0.log file
> when I
> > > > > booted
> > > > > > with
> > > > > > > > nomodeset option.
> > > > > > > >
> > > > > > > > interestingly I did not see any kernel or driver
> crash
> > > > > messages in
> > > > > > the
> > > > > > > > dmesg output. I do see these messages multiple
> times in
> > > > > > /var/log/messages
> > > > > > > > *
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > GdmDisplay:
> > > > > > display
> > > > > > > > lasted 0.048984 seconds
> > > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > > > > GdmLocalDisplayFactory:
> > > > > > > > maximum number of X display failures reached: check
> X
> > > server
> > > > > log
> > > > > > for errors
> > > > > > > > *
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Sanjay
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 29, 2010 at 11:57 AM, Jeremy
> Fitzhardinge
> > > > > > <[4][10]jeremy@goop.org>wrote:
> > > > > > > >
> > > > > > > >> On 09/29/2010 11:12 AM, sanjay kushwaha wrote:
> > > > > > > >> > Hi Folks,
> > > > > > > >> > I am trying to boot latest xen-unstable on my
> laptop
> > > which
> > > > > has
> > > > > > Intel
> > > > > > > >> > i915 graphics. PVOPS dom0 is 2.6.33.6 based
> (from
> > > branch
> > > > > > > >> > xen/stable-2.6.33.x)
> > > > > > > >>
> > > > > > > >> Don't use that branch; it isn't supported (in
> fact, I
> > > deleted
> > > > > it
> > > > > > a while
> > > > > > > >> ago). Use xen/stable-2.6.32.x for now.
> > > > > > > >>
> > > > > > > >> J
> > > > > > > >>
> > > > > > > >> > and the distro is fedora 13 64-bit. The graphics
> doesnt
> > > > > come up
> > > > > > and it
> > > > > > > >> > seems that i915 driver is crashing multiple
> times. If I
> > > > > boot in
> > > > > > > >> > run-level 3 (without X) dom0 boots fine.
> > > > > > > >> > I tried booting the dom0 kernel with nomodeset
> and
> > > nopat
> > > > > > options
> > > > > > > >> > without any success. I searched on internet and
> found
> > > that
> > > > > > multiple
> > > > > > > >> > people have reported similar problem but I could
> not
> > > find
> > > > > any
> > > > > > solution.
> > > > > > > >> >
> > > > > > > >> > Has anybody found a solution or workaround to
> this
> > > problem?
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> > Sanjay
> > > > > > > >> >
> > > > > > > >> > PS: I have another laptop with same version of
> xen and
> > > > > pvops
> > > > > > dom0 but
> > > > > > > >> > it has ATI radeon graphics card. This laptop
> boots dom0
> > > > > with
> > > > > > graphics
> > > > > > > >> > when I give nomodeset and nopat options (but
> fails if I
> > > > > dont
> > > > > > give
> > > > > > > >> > either of those two options).
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > _______________________________________________
> > > > > > > >> > Xen-devel mailing list
> > > > > > > >> > [5][11]Xen-devel@lists.xensource.com
> > > > > > > >> > [6][12]http://lists.xensource.com/xen-devel
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > Xen-devel mailing list
> > > > > > > [7][13]Xen-devel@lists.xensource.com
> > > > > > > [8][14]http://lists.xensource.com/xen-devel
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > --
> > > > > > ----------------------
> > > > > > Dr. Sanjay Kumar
> > > > > > Research Scientist
> > > > > > Intel Corporation
> > > > > >
> > > > > > References
> > > > > >
> > > > > > Visible links
> > > > > > 1. mailto:[15]sanjay.kushwaha@gmail.com
> > > > > > 2. mailto:[16]konrad.wilk@oracle.com
> > > > > > 3. mailto:[17]sanjay.kushwaha@gmail.com
> > > > > > 4. mailto:[18]jeremy@goop.org
> > > > > > 5. mailto:[19]Xen-devel@lists.xensource.com
> > > > > > 6. [20]http://lists.xensource.com/xen-devel
> > > > > > 7. mailto:[21]Xen-devel@lists.xensource.com
> > > > > > 8. [22]http://lists.xensource.com/xen-devel
> > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > [23]Xen-devel@lists.xensource.com
> > > > > > [24]http://lists.xensource.com/xen-devel
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ----------------------
> > > > Dr. Sanjay Kumar
> > > > Research Scientist
> > > > Intel Corporation
> > >
> >
> >
> >
> > --
> > ----------------------
> > Dr. Sanjay Kumar
> > Research Scientist
> > Intel Corporation
>
> > _______________________________________________
> > Xen-devel mailing list
> > [25]Xen-devel@lists.xensource.com
> > [26]http://lists.xensource.com/xen-devel
>
> --
> ----------------------
> Dr. Sanjay Kumar
> Research Scientist
> Intel Corporation
>
> References
>
> Visible links
> 1. mailto:konrad.wilk@oracle.com
> 2. mailto:konrad.wilk@oracle.com
> 3. http://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 4. mailto:jeremy.fitzhardinge@citrix.com
> 5. mailto:pasik@iki.fi
> 6. http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> 7. mailto:sanjay.kushwaha@gmail.com
> 8. mailto:konrad.wilk@oracle.com
> 9. mailto:sanjay.kushwaha@gmail.com
> 10. mailto:jeremy@goop.org
> 11. mailto:Xen-devel@lists.xensource.com
> 12. http://lists.xensource.com/xen-devel
> 13. mailto:Xen-devel@lists.xensource.com
> 14. http://lists.xensource.com/xen-devel
> 15. mailto:sanjay.kushwaha@gmail.com
> 16. mailto:konrad.wilk@oracle.com
> 17. mailto:sanjay.kushwaha@gmail.com
> 18. mailto:jeremy@goop.org
> 19. mailto:Xen-devel@lists.xensource.com
> 20. http://lists.xensource.com/xen-devel
> 21. mailto:Xen-devel@lists.xensource.com
> 22. http://lists.xensource.com/xen-devel
> 23. mailto:Xen-devel@lists.xensource.com
> 24. http://lists.xensource.com/xen-devel
> 25. mailto:Xen-devel@lists.xensource.com
> 26. http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH] Add dm_task_set_newuuid().
From: Peter Jones @ 2010-10-07 19:34 UTC (permalink / raw)
To: lvm-devel
This adds dm_task_set_newuuid(), which allows callers to assign a uuid
to an existing map if a uuid has not been set before. This goes with
the patch sent to dm-devel earlier today to implement the kernel side.
---
libdm/ioctl/libdm-iface.c | 24 ++++++++++++++++++++++++
libdm/ioctl/libdm-targets.h | 1 +
libdm/libdevmapper.h | 1 +
3 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/libdm/ioctl/libdm-iface.c b/libdm/ioctl/libdm-iface.c
index 5ba6634..0c82759 100644
--- a/libdm/ioctl/libdm-iface.c
+++ b/libdm/ioctl/libdm-iface.c
@@ -1185,6 +1185,22 @@ int dm_task_suppress_identical_reload(struct dm_task *dmt)
return 1;
}
+int dm_task_set_newuuid(struct dm_task *dmt, const char *newuuid)
+{
+ if (strlen(newuuid) >= DM_UUID_LEN) {
+ log_error("Uuid \"%s\" too long", newuuid);
+ return 0;
+ }
+
+ if (!(dmt->newname = dm_strdup(newuuid))) {
+ log_error("dm_task_set_newuuid: strdup(%s) failed", newuuid);
+ return 0;
+ }
+ dmt->new_uuid = 1;
+
+ return 1;
+}
+
int dm_task_set_newname(struct dm_task *dmt, const char *newname)
{
if (strchr(newname, '/')) {
@@ -1514,6 +1530,14 @@ static struct dm_ioctl *_flatten(struct dm_task *dmt, unsigned repeat_count)
"by kernel. It will use live table.");
dmi->flags |= DM_QUERY_INACTIVE_TABLE_FLAG;
}
+ if (dmt->new_uuid) {
+ if (_dm_version_minor < 19) {
+ log_error("WARNING: Updating UUID unsupported by "
+ "kernel.");
+ goto bad;
+ }
+ dmi->flags |= DM_NEW_UUID_FLAG;
+ }
dmi->target_count = count;
dmi->event_nr = dmt->event_nr;
diff --git a/libdm/ioctl/libdm-targets.h b/libdm/ioctl/libdm-targets.h
index ea3d14f..d8cee45 100644
--- a/libdm/ioctl/libdm-targets.h
+++ b/libdm/ioctl/libdm-targets.h
@@ -62,6 +62,7 @@ struct dm_task {
int suppress_identical_reload;
uint64_t existing_table_size;
int cookie_set;
+ int new_uuid;
char *uuid;
};
diff --git a/libdm/libdevmapper.h b/libdm/libdevmapper.h
index 34bcf40..7ed60be 100644
--- a/libdm/libdevmapper.h
+++ b/libdm/libdevmapper.h
@@ -167,6 +167,7 @@ struct dm_versions *dm_task_get_versions(struct dm_task *dmt);
int dm_task_set_ro(struct dm_task *dmt);
int dm_task_set_newname(struct dm_task *dmt, const char *newname);
+int dm_task_set_newuuid(struct dm_task *dmt, const char *newuuid);
int dm_task_set_minor(struct dm_task *dmt, int minor);
int dm_task_set_major(struct dm_task *dmt, int major);
int dm_task_set_major_minor(struct dm_task *dmt, int major, int minor, int allow_default_major_fallback);
--
1.7.2.2
^ permalink raw reply related
* Re: [PULL] Pull request from msysGit
From: Peter Harris @ 2010-10-07 19:30 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Pat Thoyts, Junio C Hamano, git, msysgit, sschuberth
In-Reply-To: <4CAE00C5.1050509@ramsay1.demon.co.uk>
On 2010-10-07 13:17, Ramsay Jones wrote:
> Now, Peter Harris has already submitted a fix for this, which is
> currently on the work/msvc-fixes branch, which contains:
>
> 358f1be Modify MSVC wrapper script
> 38bd27d Fix MSVC build
>
> The suggested fix is given in commit 38bd27d. However, I prefer a
> different solution, which is given below:
>
> --- >8 ---
> diff --git a/compat/mingw.h b/compat/mingw.h
> index afedf3a..445d1a1 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -12,12 +12,6 @@ typedef int pid_t;
> #define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
> #define S_ISSOCK(x) 0
>
> -#ifndef _STAT_H_
> -#define S_IRUSR 0
> -#define S_IWUSR 0
> -#define S_IXUSR 0
> -#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
> -#endif
> #define S_IRGRP 0
> #define S_IWGRP 0
> #define S_IXGRP 0
> --- 8< ---
>
> Note that, for *both* MinGW and MSVC, the deleted #defines
> are not wanted, pointless and just plain wrong! :-D
I didn't realize that the defines were not wanted for MinGW either.
I heartily approve of removing code rather than just ifdefing around it.
Please use this version of the patch instead of mine.
Peter Harris
--
Open Text Connectivity Solutions Group
Peter Harris http://connectivity.opentext.com/
Research and Development Phone: +1 905 762 6001
pharris@opentext.com Toll Free: 1 877 359 4866
^ permalink raw reply
* Re: GeForce FX5200 dual DVI & Samsung 204b
From: Grzesiek Sójka @ 2010-10-07 19:34 UTC (permalink / raw)
To: Francisco Jerez; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <87wrpug1d0.fsf-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
On 10/07/10 04:53, Francisco Jerez wrote:
> Grzesiek Sójka<pld-t9zbU3WrWHI@public.gmane.org> writes:
>
>> On 10/05/10 14:55, Francisco Jerez wrote:
>>>> PS. I'm afraid that my system is not very stable when the AGP support
>>>> is turned on both using the nouveau kernel source tree and the PLD
>>>> patched 2.6.35-5 version with an extra amd-k7-agp patch. The Xserver
>>>> uses the driver:
>>> Unstable? How? What's the problem?
>>
>> Here are the logs:
>> http://yen.ipipan.waw.pl/~gs159090/tmp/log.tgz
>>
>> BTW: Sometimes the Xserver freezes during normal work. Unfortunately I
>> was not able to generate such a crush now. I send you logs if it
>> happens again.
>>
>> Regards.
>>
>> [...]
>> [ 197.374498] kernel BUG at drivers/gpu/drm/ttm/ttm_tt.c:420!
>
> Oops, I overlooked that, updated patch attached.
>
The new patch works fine so fare. System seems to be stable.
cheers
greg
^ 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.