Re: [PATCH v2] Staging : android: binder.c: Prefer seq_puts to seq_printf
On Tue, 2013-10-01 at 23:57 -0400, Mathieu Rhéaume wrote:
> Changes since v2:
> * Fixed the indent problems (2 tab and 1 space) by Joe Perches.
> * Found more calls to convert from seq_printf to seq_puts
[]
> diff --git a/drivers/staging/android/binder.c
> b/drivers/staging/android/binder.c
[]
> @@ -3272,33 +3272,33 @@ binder_defer_work(struct binder_proc *proc, enum
> binder_deferred_state defer)
> static void print_binder_transaction(struct seq_file *m, const char *prefix,
>struct binder_transaction *t)
> {
> - seq_printf(m,
> -"%s %d: %p from %d:%d to %d:%d code %x flags %x pri %ld r%d",
> -prefix, t->debug_id, t,
> -t->from ? t->from->proc->pid : 0,
> -t->from ? t->from->pid : 0,
> -t->to_proc ? t->to_proc->pid : 0,
> -t->to_thread ? t->to_thread->pid : 0,
> -t->code, t->flags, t->priority, t->need_reply);
> + seq_puts(m, "%s %d: %p from %d:%d to %d:%d code %x flags %x pri
> %ld r%d",
Only indent the subsequent lines
not the initial seq_puts.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: android: binder.c: Fixed 80 characters warnings from checkpatch.pl
On Tue, Oct 01, 2013 at 09:39:48PM -0400, Mathieu Rhéaume wrote: > Fixed a lot of warnings from checkpatch.pl about the 80 characters per line > limitation. > The code was better in the original, sorry. Also this doesn't apply to linux-next from Friday. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough
The hardware offers a 4-bit register containing the number of host
channels. However, the values of these register mean 1-16 host channels,
not 0-15. Since the dwc2_hw_params struct stores the actual number of
host channels supported instead of the raw register value, it should be
5 bits wide instead of 4.
Before this commit, hardware with 16 host channels would overflow the
field, making it appear as 0 channels.
This bug was introduced in commit 9badec2 (staging: dwc2: interpret all
hwcfg and related register at init time).
Reported-by: Dinh Nguyen
Signed-off-by: Matthijs Kooijman
---
drivers/staging/dwc2/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dwc2/core.h b/drivers/staging/dwc2/core.h
index f7ba34b..fab718d 100644
--- a/drivers/staging/dwc2/core.h
+++ b/drivers/staging/dwc2/core.h
@@ -294,7 +294,7 @@ struct dwc2_hw_params {
unsigned dev_token_q_depth:5;
unsigned max_transfer_size:26;
unsigned max_packet_count:11;
- unsigned host_channels:4;
+ unsigned host_channels:5;
unsigned hs_phy_type:2;
unsigned fs_phy_type:2;
unsigned i2c_enable:1;
--
1.8.4.rc1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : android: binder.c: Prefer seq_puts to seq_printf
On Tue, Oct 01, 2013 at 09:57:36PM -0400, Mathieu Rhéaume wrote: > This patch changes seq_printf for seq_puts in binder.c. > It fixes the warnings emitted by checkpatch.pl. Which warnings? Seems like a false positive somehow because seq_puts() is totally wrong here. This doesn't compile. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : android: binder.c: Prefer seq_puts to seq_printf
On Wed, 2013-10-02 at 15:15 +1000, Ryan Mallon wrote: > On 02/10/13 11:57, Mathieu Rhéaume wrote: > > This patch changes seq_printf for seq_puts in binder.c. > > It fixes the warnings emitted by checkpatch.pl. [] > Umm, this won't compile. seq_puts() is defined as: > > int seq_puts(struct seq_file *m, const char *s); > > checkpatch.pl does indeed complain about uses of seq_printf() in > drivers/staging/android/binder.c which are passing formatted strings. At > a quick glance it looks like checkpatch.pl is only checking for the > format string on the same line as seq_printf(), so this files ugly > coding style confuses the check. Joe? True. This patch should have fixed it. It's in -next already. https://lkml.org/lkml/2013/9/13/698 > Anyway, please don't blindly change things in the kernel without at > least compile testing them. Yes, please. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] Staging : android: binder.c: Prefer seq_puts to seq_printf
On Wed, Oct 02, 2013 at 01:02:39AM -0400, Mathieu Rhéaume wrote: > Changes since v2: > * Fixed the indent in the method calls that had too many tab. > > >8--8< > > This patch changes seq_printf for seq_puts in binder.c. > It fixes the warnings emitted by checkpatch.pl. Checkpatch.pl is wrong here and this doesn't compile. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough
Hey Dinh, > >Reported-by: Dinh Nguyen > Can you please use: > Dinh Nguyen Sorry, I just used your sender address, should have checked your patch instead. Paul, if you can ack this patch, I'll resend it with the proper tag and include your acked-by as well. Gr. Matthijs signature.asc Description: Digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 20/21] staging: comedi: ni_at_ao: fix analog output ranges
On 2013-10-01 18:14, Hartley Sweeten wrote:
On Tuesday, October 01, 2013 3:27 AM, Ian Abbott wrote:
On 2013-10-01 01:55, H Hartley Sweeten wrote:
Each analog output channel is individually configurable. The current
analog output 'range_table' selection in this driver assumes that all
the channels are configured as either bipolar or unipolar. User option[2]
is then used during the attach to select the range_table to use.
Add a comedi_lrange table to allow the user to specify the actual range
to use for each channel.
Make sure the approriate DAC2S bit is set in the CFG2 register when writing
straight binary unipolar values to the DAC. Also, the data only needs to
be munged to two's complement when writing bipolar values.
Since this bit only affects how the hardware interprets values written
to the DAC, and all comedi data values are straight binary already,
can't you just leave it initialized to straight binary (already done by
atao_reset()) and write the comedi data values as is without munging?
Ian,
This is the comment in the at-ao-6/10 user manual about the DAC2S*<8..0>
bits in the CFG2 register:
DAC Input Data Format Select Bits.
When DAC2S0* is cleared, a two's complement format is used for
the 16-bit data written to DAC0 and DAC1. This format is useful
for the bipolar analog output mode. When DAC2S0* is set, a
straight binary format is used for the 16-bit data written to DAC0
and DC1. This format is useful for the unipolar analog output
mode. Bit DAC2S2* controls the data format of DAC2 and DAC3,
and in the same way bits DAC2S4* to DAC2S8* control the
corresponding DACs.
Ah, so the driver is currently broken. I'd assumed the register was
already being initialized to match comedi's data format.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/ni_at_ao.c | 41
++-
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_at_ao.c
b/drivers/staging/comedi/drivers/ni_at_ao.c
index 10e3e947..e483c7e 100644
--- a/drivers/staging/comedi/drivers/ni_at_ao.c
+++ b/drivers/staging/comedi/drivers/ni_at_ao.c
@@ -29,9 +29,6 @@
* [0] - I/O port base address
* [1] - IRQ (unused)
* [2] - DMA (unused)
- * [3] - analog output range, set by jumpers on hardware
- * 0 for -10 to 10V bipolar
- * 1 for 0V to 10V unipolar
*/
#include
@@ -99,6 +96,32 @@
#define ATAO_2_RTSISHFT_RSI (1 << 0)
#define ATAO_2_RTSISTRB_REG 0x07
+/*
+ * Each Analog Output channel can be configured indepentently to
+ * have either a bipolar (factory setting) or unipolar output.
+ * This selection is done with jumpers on the board.
+ *
+ * There are also jumpers to select if the channel uses the internal
+ * 10V reference voltage (factory default) or an exteral reference
+ * voltage applied to the EXTREFx pin on the I/O connector. Each
+ * EXTREFx signal is shared by two DACs that are in the same chip;
+ * that is DAC0 and DAC1 share EXTREF0, DAC2 and DAC3 share EXTREF2,
+ * etc. Each channel is individually configured.
+ *
+ * The following ranges cover all the configuration options. The user
+ * must select the correct range, based on the board configuration,
+ * to correctly calculate the values needed to produce a given output
+ * voltage.
+ */
+static const struct comedi_lrange atao_range = {
+ 4, {
+ BIP_RANGE(10), /* internal bipolar */
+ UNI_RANGE(10), /* internal unipolar */
+ RANGE_ext(-1, 1), /* external bipolar */
+ RANGE_ext(0, 1) /* external unipolar */
+ }
+};
+
struct atao_board {
const char *name;
int n_ao_chans;
@@ -143,9 +166,14 @@ static int atao_ao_insn_write(struct comedi_device *dev,
{
struct atao_private *devpriv = dev->private;
unsigned int chan = CR_CHAN(insn->chanspec);
+ unsigned int range = CR_RANGE(insn->chanspec);
unsigned int val;
int i;
+ /* enable straight binary format for unipolar ranges */
+ if (comedi_range_is_unipolar(s, range))
+ outw(ATAO_CFG2_DACS(chan), dev->iobase + ATAO_CFG2_REG);
+
I don't think you need this of the munging of bipolar range values
below, but the above bit of code only seems to be half-working as it
doesn't write anything to the register for bipolar ranges.
Based on the information in the user manual, and since the data from the comedi
core is already in straight binary format, when the specified range is unipolar
I set
the corresponding DAC2S* bit in the CFG register. This means the data does not
need to be munged.
But, I did miss clearing the DAC2S* bit for bipolar values. Good catch.
if (chan == 0)
atao_select_reg_group(dev, 1);
@@ -153,8 +181,9 @@ static int atao_ao_insn_write(struct comedi_device *dev,
val = data[i];
devpriv->ao_readbac
Re: [PATCH 18/22] staging: comedi: ni_6527: tidy up the interrupt subdevice
On 2013-10-01 23:14, H Hartley Sweeten wrote:
Do the request_irq() before setting up the subdevices. Only initialize
the interrupt subdevice if the irq is actually available.
Since it's using IRQ_SHARED, you'll need add a test to the start of
ni6527_interrupt() to check dev->attached before accessing the subdevice:
if (!dev->attached)
return IRQ_NONE;
Tidy up the whitespace in the subdevice init.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/ni_6527.c | 39 +---
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_6527.c
b/drivers/staging/comedi/drivers/ni_6527.c
index 7ad8a4b..af35b78 100644
--- a/drivers/staging/comedi/drivers/ni_6527.c
+++ b/drivers/staging/comedi/drivers/ni_6527.c
@@ -381,6 +381,11 @@ static int ni6527_auto_attach(struct comedi_device *dev,
ni6527_reset(dev);
+ ret = request_irq(pcidev->irq, ni6527_interrupt, IRQF_SHARED,
+ dev->board_name, dev);
+ if (ret == 0)
+ dev->irq = pcidev->irq;
+
ret = comedi_alloc_subdevices(dev, 3);
if (ret)
return ret;
@@ -402,25 +407,23 @@ static int ni6527_auto_attach(struct comedi_device *dev,
s->maxdata = 1;
s->insn_bits = ni6527_do_insn_bits;
+ /* Edge detection interrupt subdevice */
s = &dev->subdevices[2];
- dev->read_subdev = s;
- s->type = COMEDI_SUBD_DI;
- s->subdev_flags = SDF_READABLE | SDF_CMD_READ;
- s->n_chan = 1;
- s->range_table = &range_unknown;
- s->maxdata = 1;
- s->do_cmdtest = ni6527_intr_cmdtest;
- s->do_cmd = ni6527_intr_cmd;
- s->cancel = ni6527_intr_cancel;
- s->insn_bits = ni6527_intr_insn_bits;
- s->insn_config = ni6527_intr_insn_config;
-
- ret = request_irq(pcidev->irq, ni6527_interrupt,
- IRQF_SHARED, dev->board_name, dev);
- if (ret < 0)
- dev_warn(dev->class_dev, "irq not available\n");
- else
- dev->irq = pcidev->irq;
+ if (dev->irq) {
+ dev->read_subdev = s;
+ s->type = COMEDI_SUBD_DI;
+ s->subdev_flags = SDF_READABLE | SDF_CMD_READ;
+ s->n_chan= 1;
+ s->maxdata = 1;
+ s->range_table = &range_digital;
+ s->insn_config = ni6527_intr_insn_config;
+ s->insn_bits = ni6527_intr_insn_bits;
+ s->do_cmdtest= ni6527_intr_cmdtest;
+ s->do_cmd= ni6527_intr_cmd;
+ s->cancel= ni6527_intr_cancel;
+ } else {
+ s->type = COMEDI_SUBD_UNUSED;
+ }
return 0;
}
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/22] staging: comedi: ni_6527: cleanup driver
On 2013-10-01 23:07, H Hartley Sweeten wrote:
Cleanup another comedi driver.
H Hartley Sweeten (22):
staging: comedi: ni_6527: remove DRIVER_NAME define
staging: comedi: ni_6527: remove unused NI6527_*_SIZE defines
staging: comedi: ni_6527: remove unused DEBUG* defines
staging: comedi: ni_6527: remove extra probe noise
staging: comedi: ni_6527: factor out the code that sets the filter interval
staging: comedi: ni_6527: factor out the code that sets the filter enables
staging: comedi: ni_6527: tidy up ni6527_di_insn_config()
staging: comedi: ni_6527: tidy up ni6527_{di,do}_insn_bits()
staging: comedi: ni_6527: use dev->read_subdev in interrupt handler
staging: comedi: ni_6527: tidy up ni6527_interrupt()
staging: comedi: ni_6527: rename CamelCase defines for the clear register
staging: comedi: ni_6527: rename CamelCase defines for the control register
staging: comedi: ni_6527: tidy up ni6527_intr_cmd()
staging: comedi: ni_6527: tidy up ni6527_intr_cancel()
staging: comedi: ni_6527: tidy up ni6527_intr_insn_config()
staging: comedi: ni_6527: remove COMEDI_MITE dependancy
staging: comedi: ni_6527: introduce ni6527_reset()
staging: comedi: ni_6527: tidy up the interrupt subdevice
staging: comedi: ni_6527: tidy up ni6527_auto_attach()
staging: comedi: ni_6527: tidy up the comedi_driver declaration
staging: comedi: ni_6527: tidy up multi-line comments
staging: comedi: ni_6527: change MODULE_DESCRIPTION
drivers/staging/comedi/Kconfig | 2 -
drivers/staging/comedi/drivers/ni_6527.c | 457 ---
2 files changed, 239 insertions(+), 220 deletions(-)
Looks good. It could possibly do with an additional safety check in the
interrupt routine to make damn sure it cannot access the subdevice
before it is set up, rather than relying completely on the value read
from the hardware's interrupt status register.
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 18/22] staging: comedi: ni_6527: tidy up the interrupt subdevice
On 2013-10-02 12:17, Ian Abbott wrote: On 2013-10-01 23:14, H Hartley Sweeten wrote: Do the request_irq() before setting up the subdevices. Only initialize the interrupt subdevice if the irq is actually available. Since it's using IRQ_SHARED, you'll need add a test to the start of ni6527_interrupt() to check dev->attached before accessing the subdevice: if (!dev->attached) return IRQ_NONE; Actually, the first thing the interrupt does is read the status register, which should indicate that the device is not asserting a reset since the hardware has just been initialized by ni6527_reset() to disable and clear interrupts. So it should be safe. It may still be worth checking one of dev->attached or dev->read_subdev for additional safety. -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] hyperv-fb: add blanking support
Signed-off-by: Gerd Hoffmann
---
drivers/video/hyperv_fb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 8d456dc..130708f 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -575,6 +575,10 @@ static int hvfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
return 0;
}
+static int hvfb_blank(int blank, struct fb_info *info)
+{
+ return 1; /* get fb_blank to set the colormap to all black */
+}
static struct fb_ops hvfb_ops = {
.owner = THIS_MODULE,
@@ -584,6 +588,7 @@ static struct fb_ops hvfb_ops = {
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
+ .fb_blank = hvfb_blank,
};
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] hyperv-fb: add pci stub
This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
driver will bind to the pci device then, so linux kernel and userspace
know there is a proper kernel driver for the device active. lspci shows
this for example:
[root@dhcp231 ~]# lspci -vs8
00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
VGA (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f800 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at [disabled]
Kernel driver in use: hyperv_fb
Another effect is that the xorg vesa driver will not attach to the
device and thus the Xorg server will automatically use the fbdev
driver instead.
Signed-off-by: Gerd Hoffmann
---
drivers/video/hyperv_fb.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 8ac99b8..8d456dc 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -795,12 +795,21 @@ static int hvfb_remove(struct hv_device *hdev)
}
+static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
+ {
+ .vendor = PCI_VENDOR_ID_MICROSOFT,
+ .device = PCI_DEVICE_ID_HYPERV_VIDEO,
+ },
+ { /* end of list */ }
+};
+
static const struct hv_vmbus_device_id id_table[] = {
/* Synthetic Video Device GUID */
{HV_SYNTHVID_GUID},
{}
};
+MODULE_DEVICE_TABLE(pci, pci_stub_id_table);
MODULE_DEVICE_TABLE(vmbus, id_table);
static struct hv_driver hvfb_drv = {
@@ -810,14 +819,43 @@ static struct hv_driver hvfb_drv = {
.remove = hvfb_remove,
};
+static int hvfb_pci_stub_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ return 0;
+}
+
+static void hvfb_pci_stub_remove(struct pci_dev *pdev)
+{
+}
+
+static struct pci_driver hvfb_pci_stub_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = pci_stub_id_table,
+ .probe =hvfb_pci_stub_probe,
+ .remove = hvfb_pci_stub_remove,
+};
static int __init hvfb_drv_init(void)
{
- return vmbus_driver_register(&hvfb_drv);
+ int ret;
+
+ ret = vmbus_driver_register(&hvfb_drv);
+ if (ret != 0)
+ return ret;
+
+ ret = pci_register_driver(&hvfb_pci_stub_driver);
+ if (ret != 0) {
+ vmbus_driver_unregister(&hvfb_drv);
+ return ret;
+ }
+
+ return 0;
}
static void __exit hvfb_drv_exit(void)
{
+ pci_unregister_driver(&hvfb_pci_stub_driver);
vmbus_driver_unregister(&hvfb_drv);
}
--
1.8.3.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging : android: binder.c: Prefer seq_puts to seq_printf
On Tue, 2013-10-01 at 21:57 -0400, Mathieu Rhéaume wrote:
> This patch changes seq_printf for seq_puts in binder.c.
> It fixes the warnings emitted by checkpatch.pl.
Please realign function argument to the open parenthesis.
> diff --git a/drivers/staging/android/binder.c
> b/drivers/staging/android/binder.c
[]
> @@ -3272,7 +3272,7 @@ binder_defer_work(struct binder_proc *proc, enum
> binder_deferred_state defer)
> static void print_binder_transaction(struct seq_file *m, const char *prefix,
>struct binder_transaction *t)
> {
> - seq_printf(m,
> + seq_puts(m,
> "%s %d: %p from %d:%d to %d:%d code %x flags %x pri %ld r%d",
> prefix, t->debug_id, t,
> t->from ? t->from->proc->pid : 0,
This should be
seq_puts(m, "%s..."
prefix, etc...
using two tabs then 1 space to align to open parenthesis
> @@ -3287,7 +3287,7 @@ static void print_binder_transaction(struct seq_file
> *m, const char *prefix,
> if (t->buffer->target_node)
> seq_printf(m, " node %d",
> t->buffer->target_node->debug_id);
> - seq_printf(m, " size %zd:%zd data %p\n",
> + seq_puts(m, " size %zd:%zd data %p\n",
> t->buffer->data_size, t->buffer->offsets_size,
seq_puts(m, " size...",
t->buffer->etc...
etc...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice
The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
currently writes (optionally) and reads back up to 5 "ports" consisting
of 8 channels each. It reads up to 32 1-bit channels but can only read
and write a whole port at once - it needs to handle up to 5 ports as the
first channel it reads might not be aligned on a port boundary. It
breaks out of the loop early if the next port it handles is beyond the
final port on the card. It also breaks out early on the 5th port in the
loop if the first channel was aligned. Unfortunately, it doesn't check
that the current port it is dealing with belongs to the comedi subdevice
the `insn_bits` handler is acting on. That's a bug.
Redo the `for` loop to terminate after the final port belonging to the
subdevice, changing the loop variable in the process to simplify things
a bit. The `for` loop could now try and handle more than 5 ports if the
subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
ensures it will break out early after 4 or 5 ports (depending on whether
the first channel is aligned on a port boundary). (`bitshift` will be
between -7 and 7 inclusive on the first iteration, increasing by 8 for
each subsequent operation.)
Signed-off-by: Ian Abbott
Cc: # 3.10.y 3.11.y 3.12.y
---
Needs backporting for longterm kernels before 3.10.y
---
drivers/staging/comedi/drivers/ni_65xx.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_65xx.c
b/drivers/staging/comedi/drivers/ni_65xx.c
index 3ba4c57..853f62b 100644
--- a/drivers/staging/comedi/drivers/ni_65xx.c
+++ b/drivers/staging/comedi/drivers/ni_65xx.c
@@ -369,28 +369,23 @@ static int ni_65xx_dio_insn_bits(struct comedi_device
*dev,
{
const struct ni_65xx_board *board = comedi_board(dev);
struct ni_65xx_private *devpriv = dev->private;
- unsigned base_bitfield_channel;
- const unsigned max_ports_per_bitfield = 5;
+ int base_bitfield_channel;
unsigned read_bits = 0;
- unsigned j;
+ int last_port_offset = ni_65xx_port_by_channel(s->n_chan - 1);
+ int port_offset;
base_bitfield_channel = CR_CHAN(insn->chanspec);
- for (j = 0; j < max_ports_per_bitfield; ++j) {
- const unsigned port_offset =
- ni_65xx_port_by_channel(base_bitfield_channel) + j;
- const unsigned port =
- sprivate(s)->base_port + port_offset;
- unsigned base_port_channel;
+ for (port_offset = ni_65xx_port_by_channel(base_bitfield_channel);
+port_offset <= last_port_offset; port_offset++) {
+ unsigned port = sprivate(s)->base_port + port_offset;
+ int base_port_channel = port_offset * ni_65xx_channels_per_port;
unsigned port_mask, port_data, port_read_bits;
- int bitshift;
- if (port >= ni_65xx_total_num_ports(board))
+ int bitshift = base_port_channel - base_bitfield_channel;
+
+ if (bitshift >= 32)
break;
- base_port_channel = port_offset * ni_65xx_channels_per_port;
port_mask = data[0];
port_data = data[1];
- bitshift = base_port_channel - base_bitfield_channel;
- if (bitshift >= 32 || bitshift <= -32)
- break;
if (bitshift > 0) {
port_mask >>= bitshift;
port_data >>= bitshift;
--
1.8.3.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/2] hyperv-fb: add pci stub
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Wednesday, October 02, 2013 4:55 AM
> Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol-
> Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open list:FRAMEBUFFER
> LAYER; open list
> Subject: [PATCH 1/2] hyperv-fb: add pci stub
>
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
> driver will bind to the pci device then, so linux kernel and userspace
> know there is a proper kernel driver for the device active. lspci shows
> this for example:
>
> [root@dhcp231 ~]# lspci -vs8
> 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual
> VGA (prog-if 00 [VGA controller])
> Flags: bus master, fast devsel, latency 0, IRQ 11
> Memory at f800 (32-bit, non-prefetchable) [size=64M]
> Expansion ROM at [disabled]
> Kernel driver in use: hyperv_fb
>
> Another effect is that the xorg vesa driver will not attach to the
> device and thus the Xorg server will automatically use the fbdev
> driver instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/video/hyperv_fb.c | 40
> +++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
> index 8ac99b8..8d456dc 100644
> --- a/drivers/video/hyperv_fb.c
> +++ b/drivers/video/hyperv_fb.c
> @@ -795,12 +795,21 @@ static int hvfb_remove(struct hv_device *hdev)
> }
>
>
> +static DEFINE_PCI_DEVICE_TABLE(pci_stub_id_table) = {
> + {
> + .vendor = PCI_VENDOR_ID_MICROSOFT,
> + .device = PCI_DEVICE_ID_HYPERV_VIDEO,
> + },
> + { /* end of list */ }
> +};
> +
> static const struct hv_vmbus_device_id id_table[] = {
> /* Synthetic Video Device GUID */
> {HV_SYNTHVID_GUID},
> {}
> };
>
> +MODULE_DEVICE_TABLE(pci, pci_stub_id_table);
> MODULE_DEVICE_TABLE(vmbus, id_table);
>
> static struct hv_driver hvfb_drv = {
> @@ -810,14 +819,43 @@ static struct hv_driver hvfb_drv = {
> .remove = hvfb_remove,
> };
>
> +static int hvfb_pci_stub_probe(struct pci_dev *pdev,
> +const struct pci_device_id *ent)
> +{
> + return 0;
> +}
> +
> +static void hvfb_pci_stub_remove(struct pci_dev *pdev)
> +{
> +}
> +
> +static struct pci_driver hvfb_pci_stub_driver = {
> + .name = KBUILD_MODNAME,
> + .id_table = pci_stub_id_table,
> + .probe =hvfb_pci_stub_probe,
> + .remove = hvfb_pci_stub_remove,
> +};
>
> static int __init hvfb_drv_init(void)
> {
> - return vmbus_driver_register(&hvfb_drv);
> + int ret;
> +
> + ret = vmbus_driver_register(&hvfb_drv);
> + if (ret != 0)
> + return ret;
> +
> + ret = pci_register_driver(&hvfb_pci_stub_driver);
> + if (ret != 0) {
> + vmbus_driver_unregister(&hvfb_drv);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static void __exit hvfb_drv_exit(void)
> {
> + pci_unregister_driver(&hvfb_pci_stub_driver);
> vmbus_driver_unregister(&hvfb_drv);
> }
>
> --
> 1.8.3.1
Gerd,
Thanks for doing this. This certainly will address some of the issues that are
reported. I do have a question though - how would this work if we don't have
PCI bus in the guest.
Regards,
K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: dgap: tty.c: adds error handing in tty driver allocations
On Tue, Oct 1, 2013 at 1:59 PM, Dan Carpenter wrote:
> On Tue, Oct 01, 2013 at 12:32:06PM -0400, Lidza Louina wrote:
>> On Tue, Oct 1, 2013 at 12:09 PM, Dan Carpenter
>> wrote:
>> > On Tue, Oct 01, 2013 at 12:00:23PM -0400, Lidza Louina wrote:
>> >> @@ -306,7 +316,16 @@ int dgap_tty_register(struct board_t *brd)
>> >>
>> >> DPR_INIT(("DGAP REGISTER TTY: MAJORS: %d %d\n",
>> >> brd->SerialDriver->major,
>> >> brd->PrintDriver->major));
>> >> -
>> >
>> > You need a "return 0;" here otherwise we release everything on success
>> > when we worked so hard to allocate it.
>> >
>> > regards,
>> > dan carpenter
>>
>> When I add that I get these smatch warnings:
>>
>> drivers/staging/dgap/dgap_tty.c:323 dgap_tty_register() info: ignoring
>> unreachable code.
>> drivers/staging/dgap/dgap_tty.c:323 dgap_tty_register() info: ignoring
>> unreachable code.
>>
>> Ignore these warnings?
>
> No. The warnings are correct and show a bug. The last two errors
> aren't handled correctly. Also I see I left out an if statement
> from my previous instructions...
Alrighty. I'm going to learn to differentiate between false smatch
warnings and real ones. >_<
> You know what? This function is never called, let's just delete it
> instead of messing about.
This function isn't called because there isn't a
dgap_tty_unregister(). The both of them would be called in the
dgap_found_board() in dgap_driver.c. dgap_tty_register() is where the
driver is where the driver is allocates space and registered. It needs
it. I want to make sure it's right, before I create a
dgap_tty_unregister().
Lidza
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: Drivers: scsi: FLUSH timeout
> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: Wednesday, September 25, 2013 1:40 AM
> To: KY Srinivasan
> Cc: Mike Christie; Jack Wang; Greg KH; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> h...@infradead.org; linux-s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
>
> On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan wrote:
> > I am not sure how that magic number was arrived at (the 60HZ number). We
> want this to be little higher -
>
> "60 * HZ" means "60 seconds".
>
> > would there be any issues raising this to say 180 seconds. This is the
> > value we
> currently have for I/O
> > timeout.
>
> So you want to replace it by "180 * HZ", which is ... another magic number?
Ideally, I want this to be adjustable like the way we can change the I/O
timeout.
Since that has been attempted earlier and rejected (not clear what the reasons
were),
I was suggesting that we pick a larger number. James, let me know how I should
proceed here.
Regards,
K. Y
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: MTD: Micron SPINAND Driver support
On Tue, Oct 01, 2013 at 03:03:58PM +0530, Kamlakant Patel wrote:
> This patch adds support for Micron SPINAND via MTD.
>
> Signed-off-by: Mona Anonuevo
> Signed-off-by: Kamlakant Patel
> ---
> This patch has to be merged via staging tree.
>
> This is a driver from Micron for MT29F1G01ZACH4 SPI based NAND chips. This
> driver had
> been posted multiple times to the mtd list.
> 1. http://lists.infradead.org/pipermail/linux-mtd/2010-May/031975.html
> 2. http://lists.infradead.org/pipermail/linux-mtd/2010-April/029523.html
> 3. patchwork.ozlabs.org/patch/258697/
> This has not been merged into the main kernel yet.
>
> I have cleaned and updated it for current kernel. Since there are many users
> for
> this driver, it may be useful to add it to the staging tree, where further
> fixes and
> cleanups can be done. Once it reaches to the standard will be moved to the
> mtd.
>
> This driver has been tested with Micron SPINAND MT29F1G01ZACH4 chip on kernel
> 3.12 on
> the Netlogic XLP platforms.
>
> Mona Anonuevo, I have retained your sign-offs from the original patch.
>
> v1:
> * Added MTD_SPINAND_MT29F and MTD_NAND dependencies to avoid build errors.
> * Some more code cleanup.
>
> drivers/staging/Kconfig | 2 +
> drivers/staging/Makefile | 1 +
> drivers/staging/mt29f_spinand/Kconfig | 16 +
> drivers/staging/mt29f_spinand/Makefile| 1 +
> drivers/staging/mt29f_spinand/TODO| 13 +
> drivers/staging/mt29f_spinand/mt29f_spinand.c | 962
> ++
> drivers/staging/mt29f_spinand/mt29f_spinand.h | 107 +++
> 7 files changed, 1102 insertions(+)
> create mode 100644 drivers/staging/mt29f_spinand/Kconfig
> create mode 100644 drivers/staging/mt29f_spinand/Makefile
> create mode 100644 drivers/staging/mt29f_spinand/TODO
> create mode 100644 drivers/staging/mt29f_spinand/mt29f_spinand.c
> create mode 100644 drivers/staging/mt29f_spinand/mt29f_spinand.h
...
> diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c
> b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> new file mode 100644
> index 000..8e95a57
> --- /dev/null
> +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> @@ -0,0 +1,962 @@
...
> +#define MAX_WAIT_JIFFIES (40 * HZ)
> +static int wait_till_ready(struct spi_device *spi_nand)
> +{
> + unsigned long deadline;
> + int retval;
> + u8 stat = 0;
> +
> + deadline = jiffies + MAX_WAIT_JIFFIES;
> + do {
> + retval = spinand_read_status(spi_nand, &stat);
> + if (retval < 0)
> + return -1;
You might want to look at using proper error codes here.
> + else if (!(stat & 0x1))
> + break;
> +
> + cond_resched();
> + } while (!time_after_eq(jiffies, deadline));
> +
> + if ((stat & 0x1) == 0)
> + return 0;
> +
> + return -1;
Same.
> +}
...
> +static int spinand_wait(struct mtd_info *mtd, struct nand_chip *chip)
> +{
> + struct spinand_info *info = (struct spinand_info *)chip->priv;
> +
> + unsigned long timeo = jiffies;
> + int retval, state = chip->state;
> + u8 status;
> +
> + if (state == FL_ERASING)
> + timeo += (HZ * 400) / 1000;
> + else
> + timeo += (HZ * 20) / 1000;
msecs_to_jiffies()?
> +
> + while (time_before(jiffies, timeo)) {
> + retval = spinand_read_status(info->spi, &status);
> + if ((status & STATUS_OIP_MASK) == STATUS_READY)
> + return 0;
> +
> + cond_resched();
> + }
> + return 0;
> +}
> +
You can address these comments in follow up patches after it's included
in staging, though. There's probably more review needed anyway
eventually (I see that no one really has reviewed this on the MTD
mailing list yet).
Brian
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/2] hyperv-fb: add pci stub
> -Original Message- > From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- > ow...@vger.kernel.org] On Behalf Of Gerd Hoffmann > Sent: Wednesday, October 2, 2013 7:55 AM > Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol- > Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open > list:FRAMEBUFFER LAYER; open list > Subject: [PATCH 1/2] hyperv-fb: add pci stub > > This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer driver > will bind to the pci device then, so linux kernel and userspace know there is > a > proper kernel driver for the device active. lspci shows this for example: > > [root@dhcp231 ~]# lspci -vs8 > 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual > VGA (prog-if 00 [VGA controller]) > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at f800 (32-bit, non-prefetchable) [size=64M] > Expansion ROM at [disabled] > Kernel driver in use: hyperv_fb > > Another effect is that the xorg vesa driver will not attach to the device and > thus the Xorg server will automatically use the fbdev driver instead. > > Signed-off-by: Gerd Hoffmann Acked-by: Haiyang Zhang Thank you for fixing this! - Haiyang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] ARM: dts: imx6qdl-sabresd: Add HDMI support
Signed-off-by: Fabio Estevam
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 64e454b..55f261c 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -243,3 +243,17 @@
wp-gpios = <&gpio2 1 0>;
status = "okay";
};
+
+
+&i2c2 {
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2_2>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc = <&i2c2>;
+ status = "okay";
+};
+
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support
Signed-off-by: Fabio Estevam
---
arch/arm/boot/dts/imx6dl.dtsi| 4
arch/arm/boot/dts/imx6q.dtsi | 4
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 13 +
arch/arm/boot/dts/imx6qdl.dtsi | 10 ++
4 files changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..65e54b4 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -88,3 +88,7 @@
crtcs = <&ipu1 0>, <&ipu1 1>;
};
};
+
+&hdmi {
+ crtcs = <&ipu1 0>, <&ipu1 1>;
+}
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..d2467f5 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -159,3 +159,7 @@
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
};
};
+
+&hdmi {
+ crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index df42d3c..624a9ce 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -58,6 +58,19 @@
status = "okay";
};
+
+&hdmi {
+ ddc = <&i2c1>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1_1>;
+ status = "okay";
+};
+
&i2c2 {
clock-frequency = <10>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ef51342..df54505 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1352,6 +1352,16 @@
};
};
+ hdmi: hdmi@012 {
+ compatible = "fsl,imx6q-hdmi";
+ reg = <0x0012 0x9000>;
+ interrupts = <0 115 0x04>;
+ gpr = <&gpr>;
+ clocks = <&clks 123>, <&clks 124>;
+ clock-names = "iahb", "isfr";
+ status = "disabled";
+ };
+
dcic1: dcic@020e4000 {
reg = <0x020e4000 0x4000>;
interrupts = <0 124 0x04>;
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
> -Original Message- > From: H. Peter Anvin [mailto:h...@zytor.com] > Sent: Monday, September 23, 2013 8:50 AM > To: KY Srinivasan > Cc: Gleb Natapov; x...@kernel.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de; > jbeul...@suse.com; b...@alien8.de; dmitry.torok...@gmail.com > Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency > from the hypervisor > > On 09/23/2013 06:02 AM, KY Srinivasan wrote: > > > > Peter, > > Please let me know if there are other issues I need to address here. Now > > that > Dmitry has queued up the > > Hyper-V keyboard driver, with this patch we can fully support Linux on our > > uefi > firmware. > > > > I just got back from Plumber's -- this is on my short list of things to > look at. If you haven't heard anything by Wednesday, ping me. Ping. K. Y > > -hpa > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 2/2] hyperv-fb: add blanking support
> -Original Message- > From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- > ow...@vger.kernel.org] On Behalf Of Gerd Hoffmann > Sent: Wednesday, October 2, 2013 7:55 AM > Cc: Gerd Hoffmann; KY Srinivasan; Haiyang Zhang; Jean-Christophe Plagniol- > Villard; Tomi Valkeinen; open list:Hyper-V CORE AND...; open > list:FRAMEBUFFER LAYER; open list > Subject: [PATCH 2/2] hyperv-fb: add blanking support > > Signed-off-by: Gerd Hoffmann Acked-by: Haiyang Zhang ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices
From: Sergio Aguirre
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds video devices support.
Signed-off-by: Sergio Aguirre
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4iss/iss_video.c | 1129
drivers/staging/media/omap4iss/iss_video.h | 201 +
2 files changed, 1330 insertions(+)
create mode 100644 drivers/staging/media/omap4iss/iss_video.c
create mode 100644 drivers/staging/media/omap4iss/iss_video.h
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c
new file mode 100644
index 000..31f1b88
--- /dev/null
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -0,0 +1,1129 @@
+/*
+ * TI OMAP4 ISS V4L2 Driver - Generic video node
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Author: Sergio Aguirre
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "iss_video.h"
+#include "iss.h"
+
+
+/*
-
+ * Helper functions
+ */
+
+static struct iss_format_info formats[] = {
+ { V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_PIX_FMT_GREY, 8, },
+ { V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_PIX_FMT_Y10, 10, },
+ { V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_PIX_FMT_Y12, 12, },
+ { V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_PIX_FMT_SBGGR8, 8, },
+ { V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_PIX_FMT_SGBRG8, 8, },
+ { V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_PIX_FMT_SGRBG8, 8, },
+ { V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_PIX_FMT_SRGGB8, 8, },
+ { V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SGRBG10_1X10, 0,
+ V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
+ { V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_PIX_FMT_SBGGR10, 10, },
+ { V4L2_MBUS_FMT_SGBRG10_1X10, V4L2_MBUS_FMT_SGBRG10_1X10,
+ V4L2_MBUS_FMT_SGBRG10_1X10, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_PIX_FMT_SGBRG10, 10, },
+ { V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_MBUS_FMT_SGRBG10_1X10,
+ V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_PIX_FMT_SGRBG10, 10, },
+ { V4L2_MBUS_FMT_SRGGB10_1X10, V4L2_MBUS_FMT_SRGGB10_1X10,
+ V4L2_MBUS_FMT_SRGGB10_1X10, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_PIX_FMT_SRGGB10, 10, },
+ { V4L2_MBUS_FMT_SBGGR12_1X12, V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_SBGGR12_1X12, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_PIX_FMT_SBGGR12, 12, },
+ { V4L2_MBUS_FMT_SGBRG12_1X12, V4L2_MBUS_FMT_SGBRG10_1X10,
+ V4L2_MBUS_FMT_SGBRG12_1X12, V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_PIX_FMT_SGBRG12, 12, },
+ { V4L2_MBUS_FMT_SGRBG12_1X12, V4L2_MBUS_FMT_SGRBG10_1X10,
+ V4L2_MBUS_FMT_SGRBG12_1X12, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_PIX_FMT_SGRBG12, 12, },
+ { V4L2_MBUS_FMT_SRGGB12_1X12, V4L2_MBUS_FMT_SRGGB10_1X10,
+ V4L2_MBUS_FMT_SRGGB12_1X12, V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_PIX_FMT_SRGGB12, 12, },
+ { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
+ V4L2_MBUS_FMT_UYVY8_1X16, 0,
+ V4L2_PIX_FMT_UYVY, 16, },
+ { V4L2_MBUS_FMT_YUYV8_1X16, V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_YUYV8_1X16, 0,
+ V4L2_PIX_FMT_YUYV, 16, },
+ { V4L2_MBUS_FMT_YUYV8_1_5X8, V4L2_MBUS_FMT_YUYV8_1_5X8,
+ V4L2_MBUS_FMT_YUYV8_1_5X8, 0,
+ V4L2_PIX_FMT_NV12, 8, },
+};
+
+const struct iss_format_info *
+omap4iss_video_format_info(enum v4l2_mbus_pixelcode code)
+{
+ unsigned int i;
+
[PATCH 0/6] OMAP4 ISS driver
Hello, The OMAP4 ISS driver has lived out of tree for more than two years now. This situation is both sad and resource-wasting, as the driver has been used (and thus) hacked since then with nowhere to send patches to. Time has come to fix the problem. As the code is mostly, but not quite ready for prime time, I'd like to request its addition to drivers/staging/. I've added a (pretty small) TODO file and I commit to cleaning up the code and get it to drivers/media/ where it belongs. I've split the driver in six patches to avoid getting caught in vger's size and to make review slightly easier. Sergio Aguirre is the driver author (huge thanks for that!), I've thus kept his authorship on patches 1/6 to 5/6. I don't have much else to add here, let's get this beast to mainline and allow other developers to use the driver and contribute patches. Laurent Pinchart (1): v4l: omap4iss: Add support for OMAP4 camera interface - Build system Sergio Aguirre (5): v4l: omap4iss: Add support for OMAP4 camera interface - Core v4l: omap4iss: Add support for OMAP4 camera interface - Video devices v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF) v4l: omap4iss: Add support for OMAP4 camera interface - Resizer Documentation/video4linux/omap4_camera.txt | 63 ++ drivers/staging/media/Kconfig|2 + drivers/staging/media/Makefile |1 + drivers/staging/media/omap4iss/Kconfig | 12 + drivers/staging/media/omap4iss/Makefile |6 + drivers/staging/media/omap4iss/TODO |4 + drivers/staging/media/omap4iss/iss.c | 1477 ++ drivers/staging/media/omap4iss/iss.h | 153 +++ drivers/staging/media/omap4iss/iss_csi2.c| 1368 drivers/staging/media/omap4iss/iss_csi2.h| 156 +++ drivers/staging/media/omap4iss/iss_csiphy.c | 278 + drivers/staging/media/omap4iss/iss_csiphy.h | 51 + drivers/staging/media/omap4iss/iss_ipipe.c | 581 ++ drivers/staging/media/omap4iss/iss_ipipe.h | 67 ++ drivers/staging/media/omap4iss/iss_ipipeif.c | 847 +++ drivers/staging/media/omap4iss/iss_ipipeif.h | 92 ++ drivers/staging/media/omap4iss/iss_regs.h| 883 +++ drivers/staging/media/omap4iss/iss_resizer.c | 905 drivers/staging/media/omap4iss/iss_resizer.h | 75 ++ drivers/staging/media/omap4iss/iss_video.c | 1129 drivers/staging/media/omap4iss/iss_video.h | 201 include/media/omap4iss.h | 65 ++ 22 files changed, 8416 insertions(+) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 drivers/staging/media/omap4iss/Kconfig create mode 100644 drivers/staging/media/omap4iss/Makefile create mode 100644 drivers/staging/media/omap4iss/TODO create mode 100644 drivers/staging/media/omap4iss/iss.c create mode 100644 drivers/staging/media/omap4iss/iss.h create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h create mode 100644 drivers/staging/media/omap4iss/iss_regs.h create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h create mode 100644 drivers/staging/media/omap4iss/iss_video.c create mode 100644 drivers/staging/media/omap4iss/iss_video.h create mode 100644 include/media/omap4iss.h -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/6] v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers
From: Sergio Aguirre
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds CSI receivers support.
Signed-off-by: Sergio Aguirre
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4iss/iss_csi2.c | 1368 +++
drivers/staging/media/omap4iss/iss_csi2.h | 156 +++
drivers/staging/media/omap4iss/iss_csiphy.c | 278 ++
drivers/staging/media/omap4iss/iss_csiphy.h | 51 +
4 files changed, 1853 insertions(+)
create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c
create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h
create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c
create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h
diff --git a/drivers/staging/media/omap4iss/iss_csi2.c
b/drivers/staging/media/omap4iss/iss_csi2.c
new file mode 100644
index 000..0ee8381
--- /dev/null
+++ b/drivers/staging/media/omap4iss/iss_csi2.c
@@ -0,0 +1,1368 @@
+/*
+ * TI OMAP4 ISS V4L2 Driver - CSI PHY module
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Author: Sergio Aguirre
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "iss.h"
+#include "iss_regs.h"
+#include "iss_csi2.h"
+
+/*
+ * csi2_if_enable - Enable CSI2 Receiver interface.
+ * @enable: enable flag
+ *
+ */
+static void csi2_if_enable(struct iss_csi2_device *csi2, u8 enable)
+{
+ struct iss_csi2_ctrl_cfg *currctrl = &csi2->ctrl;
+
+ writel((readl(csi2->regs1 + CSI2_CTRL) & ~CSI2_CTRL_IF_EN) |
+ (enable ? CSI2_CTRL_IF_EN : 0),
+ csi2->regs1 + CSI2_CTRL);
+
+ currctrl->if_enable = enable;
+}
+
+/*
+ * csi2_recv_config - CSI2 receiver module configuration.
+ * @currctrl: iss_csi2_ctrl_cfg structure
+ *
+ */
+static void csi2_recv_config(struct iss_csi2_device *csi2,
+struct iss_csi2_ctrl_cfg *currctrl)
+{
+ u32 reg = 0;
+
+ if (currctrl->frame_mode)
+ reg |= CSI2_CTRL_FRAME;
+ else
+ reg &= ~CSI2_CTRL_FRAME;
+
+ if (currctrl->vp_clk_enable)
+ reg |= CSI2_CTRL_VP_CLK_EN;
+ else
+ reg &= ~CSI2_CTRL_VP_CLK_EN;
+
+ if (currctrl->vp_only_enable)
+ reg |= CSI2_CTRL_VP_ONLY_EN;
+ else
+ reg &= ~CSI2_CTRL_VP_ONLY_EN;
+
+ reg &= ~CSI2_CTRL_VP_OUT_CTRL_MASK;
+ reg |= currctrl->vp_out_ctrl << CSI2_CTRL_VP_OUT_CTRL_SHIFT;
+
+ if (currctrl->ecc_enable)
+ reg |= CSI2_CTRL_ECC_EN;
+ else
+ reg &= ~CSI2_CTRL_ECC_EN;
+
+ /*
+* Set MFlag assertion boundaries to:
+* Low: 4/8 of FIFO size
+* High: 6/8 of FIFO size
+*/
+ reg &= ~(CSI2_CTRL_MFLAG_LEVH_MASK | CSI2_CTRL_MFLAG_LEVL_MASK);
+ reg |= (2 << CSI2_CTRL_MFLAG_LEVH_SHIFT) |
+ (4 << CSI2_CTRL_MFLAG_LEVL_SHIFT);
+
+ /* Generation of 16x64-bit bursts (Recommended) */
+ reg |= CSI2_CTRL_BURST_SIZE_EXPAND;
+
+ /* Do Non-Posted writes (Recommended) */
+ reg |= CSI2_CTRL_NON_POSTED_WRITE;
+
+ /*
+* Enforce Little endian for all formats, including:
+* YUV4:2:2 8-bit and YUV4:2:0 Legacy
+*/
+ reg |= CSI2_CTRL_ENDIANNESS;
+
+ writel(reg, csi2->regs1 + CSI2_CTRL);
+}
+
+static const unsigned int csi2_input_fmts[] = {
+ V4L2_MBUS_FMT_SGRBG10_1X10,
+ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SRGGB10_1X10,
+ V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SGBRG10_1X10,
+ V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SGBRG8_1X8,
+ V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SRGGB8_1X8,
+ V4L2_MBUS_FMT_UYVY8_1X16,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+};
+
+/* To set the format on the CSI2 requires a mapping function that takes
+ * the following inputs:
+ * - 3 different formats (at this time)
+ * - 2 destinations (mem, vp+mem) (vp only handled separately)
+ * - 2 decompression options (on, off)
+ * Output should be CSI2 frame format code
+ * Array indices as follows: [format][dest][decompr]
+ * Not all combinations are valid. 0 means invalid.
+ */
+static const u16 __csi2_fmt_map[][2][2] = {
+ /
[PATCH 4/6] v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF)
From: Sergio Aguirre
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds the IPIPEIF and IPIPE processing blocks support.
Signed-off-by: Sergio Aguirre
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4iss/iss_ipipe.c | 581 ++
drivers/staging/media/omap4iss/iss_ipipe.h | 67 +++
drivers/staging/media/omap4iss/iss_ipipeif.c | 847 +++
drivers/staging/media/omap4iss/iss_ipipeif.h | 92 +++
4 files changed, 1587 insertions(+)
create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c
create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h
create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c
create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h
diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c
b/drivers/staging/media/omap4iss/iss_ipipe.c
new file mode 100644
index 000..fc38a5c5
--- /dev/null
+++ b/drivers/staging/media/omap4iss/iss_ipipe.c
@@ -0,0 +1,581 @@
+/*
+ * TI OMAP4 ISS V4L2 Driver - ISP IPIPE module
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Author: Sergio Aguirre
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "iss.h"
+#include "iss_regs.h"
+#include "iss_ipipe.h"
+
+static struct v4l2_mbus_framefmt *
+__ipipe_get_format(struct iss_ipipe_device *ipipe, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which);
+
+static const unsigned int ipipe_fmts[] = {
+ V4L2_MBUS_FMT_SGRBG10_1X10,
+ V4L2_MBUS_FMT_SRGGB10_1X10,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_SGBRG10_1X10,
+};
+
+/*
+ * ipipe_print_status - Print current IPIPE Module register values.
+ * @ipipe: Pointer to ISS ISP IPIPE device.
+ *
+ * Also prints other debug information stored in the IPIPE module.
+ */
+#define IPIPE_PRINT_REGISTER(iss, name)\
+ dev_dbg(iss->dev, "###IPIPE " #name "=0x%08x\n", \
+ readl(iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_##name))
+
+static void ipipe_print_status(struct iss_ipipe_device *ipipe)
+{
+ struct iss_device *iss = to_iss_device(ipipe);
+
+ dev_dbg(iss->dev, "-IPIPE Register dump-\n");
+
+ IPIPE_PRINT_REGISTER(iss, SRC_EN);
+ IPIPE_PRINT_REGISTER(iss, SRC_MODE);
+ IPIPE_PRINT_REGISTER(iss, SRC_FMT);
+ IPIPE_PRINT_REGISTER(iss, SRC_COL);
+ IPIPE_PRINT_REGISTER(iss, SRC_VPS);
+ IPIPE_PRINT_REGISTER(iss, SRC_VSZ);
+ IPIPE_PRINT_REGISTER(iss, SRC_HPS);
+ IPIPE_PRINT_REGISTER(iss, SRC_HSZ);
+ IPIPE_PRINT_REGISTER(iss, GCK_MMR);
+ IPIPE_PRINT_REGISTER(iss, YUV_PHS);
+
+ dev_dbg(iss->dev, "---\n");
+}
+
+/*
+ * ipipe_enable - Enable/Disable IPIPE.
+ * @enable: enable flag
+ *
+ */
+static void ipipe_enable(struct iss_ipipe_device *ipipe, u8 enable)
+{
+ struct iss_device *iss = to_iss_device(ipipe);
+
+ writel((readl(iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_EN) &
+ ~IPIPE_SRC_EN_EN) |
+ enable ? IPIPE_SRC_EN_EN : 0,
+ iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_EN);
+}
+
+/*
-
+ * Format- and pipeline-related configuration helpers
+ */
+
+static void ipipe_configure(struct iss_ipipe_device *ipipe)
+{
+ struct iss_device *iss = to_iss_device(ipipe);
+ struct v4l2_mbus_framefmt *format;
+
+ /* IPIPE_PAD_SINK */
+ format = &ipipe->formats[IPIPE_PAD_SINK];
+
+ /* NOTE: Currently just supporting pipeline IN: RGB, OUT: YUV422 */
+ writel(IPIPE_SRC_FMT_RAW2YUV,
+ iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_FMT);
+
+ /* Enable YUV444 -> YUV422 conversion */
+ writel(IPIPE_YUV_PHS_LPF,
+ iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_YUV_PHS);
+
+ writel(0, iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_VPS);
+ writel(0, iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_HPS);
+ writel((format->height - 2) & IPIPE_SRC_VSZ_MASK,
+ iss->regs[OMAP4_ISS_MEM_ISP_IPIPE] + IPIPE_SRC_VSZ);
+ writel((format->width - 1) & IPIPE_SRC_HSZ_MASK,
+ iss->regs[OMAP4_ISS_MEM_IS
[PATCH 6/6] v4l: omap4iss: Add support for OMAP4 camera interface - Build system
This adds a very simplistic driver to utilize the CSI2A interface inside the ISS subsystem in OMAP4, and dump the data to memory. Check Documentation/video4linux/omap4_camera.txt for details. This commit adds and updates Kconfig's and Makefile's, as well as a TODO list. Signed-off-by: Laurent Pinchart --- drivers/staging/media/Kconfig | 2 ++ drivers/staging/media/Makefile | 1 + drivers/staging/media/omap4iss/Kconfig | 12 drivers/staging/media/omap4iss/Makefile | 6 ++ drivers/staging/media/omap4iss/TODO | 4 5 files changed, 25 insertions(+) create mode 100644 drivers/staging/media/omap4iss/Kconfig create mode 100644 drivers/staging/media/omap4iss/Makefile create mode 100644 drivers/staging/media/omap4iss/TODO diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index 46f1e61..bc4c798 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -33,6 +33,8 @@ source "drivers/staging/media/msi3101/Kconfig" source "drivers/staging/media/solo6x10/Kconfig" +source "drivers/staging/media/omap4iss/Kconfig" + # Keep LIRC at the end, as it has sub-menus source "drivers/staging/media/lirc/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index eb7f30b..a528d3f 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_VIDEO_DT3155) += dt3155v4l/ obj-$(CONFIG_VIDEO_GO7007) += go7007/ obj-$(CONFIG_USB_MSI3101) += msi3101/ obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/ +obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig new file mode 100644 index 000..b9fe753 --- /dev/null +++ b/drivers/staging/media/omap4iss/Kconfig @@ -0,0 +1,12 @@ +config VIDEO_OMAP4 + bool "OMAP 4 Camera support" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C && ARCH_OMAP4 + select VIDEOBUF2_DMA_CONTIG + ---help--- + Driver for an OMAP 4 ISS controller. + +config VIDEO_OMAP4_DEBUG + bool "OMAP 4 Camera debug messages" + depends on VIDEO_OMAP4 + ---help--- + Enable debug messages on OMAP 4 ISS controller driver. diff --git a/drivers/staging/media/omap4iss/Makefile b/drivers/staging/media/omap4iss/Makefile new file mode 100644 index 000..a716ce9 --- /dev/null +++ b/drivers/staging/media/omap4iss/Makefile @@ -0,0 +1,6 @@ +# Makefile for OMAP4 ISS driver + +omap4-iss-objs += \ + iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o iss_video.o + +obj-$(CONFIG_VIDEO_OMAP4) += omap4-iss.o diff --git a/drivers/staging/media/omap4iss/TODO b/drivers/staging/media/omap4iss/TODO new file mode 100644 index 000..fcde888 --- /dev/null +++ b/drivers/staging/media/omap4iss/TODO @@ -0,0 +1,4 @@ +* Make the driver compile as a module +* Fix FIFO/buffer overflows and underflows +* Replace dummy resizer code with a real implementation +* Fix checkpatch errors and warnings -- 1.8.1.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] v4l: omap4iss: Add support for OMAP4 camera interface - Resizer
From: Sergio Aguirre
This adds a very simplistic driver to utilize the CSI2A interface inside
the ISS subsystem in OMAP4, and dump the data to memory.
Check Documentation/video4linux/omap4_camera.txt for details.
This commit adds resizer support.
Signed-off-by: Sergio Aguirre
[Port the driver to v3.12-rc3, including the following changes
- Don't include plat/ headers
- Don't use cpu_is_omap44xx() macro
- Don't depend on EXPERIMENTAL
- Fix s_crop operation prototype
- Update link_notify prototype
- Rename media_entity_remote_source to media_entity_remote_pad]
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4iss/iss_resizer.c | 905 +++
drivers/staging/media/omap4iss/iss_resizer.h | 75 +++
2 files changed, 980 insertions(+)
create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c
create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h
diff --git a/drivers/staging/media/omap4iss/iss_resizer.c
b/drivers/staging/media/omap4iss/iss_resizer.c
new file mode 100644
index 000..cb5df52
--- /dev/null
+++ b/drivers/staging/media/omap4iss/iss_resizer.c
@@ -0,0 +1,905 @@
+/*
+ * TI OMAP4 ISS V4L2 Driver - ISP RESIZER module
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Author: Sergio Aguirre
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "iss.h"
+#include "iss_regs.h"
+#include "iss_resizer.h"
+
+static struct v4l2_mbus_framefmt *
+__resizer_get_format(struct iss_resizer_device *resizer, struct v4l2_subdev_fh
*fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which);
+
+static const unsigned int resizer_fmts[] = {
+ V4L2_MBUS_FMT_UYVY8_1X16,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+};
+
+/*
+ * resizer_print_status - Print current RESIZER Module register values.
+ * @resizer: Pointer to ISS ISP RESIZER device.
+ *
+ * Also prints other debug information stored in the RESIZER module.
+ */
+#define RSZ_PRINT_REGISTER(iss, name)\
+ dev_dbg(iss->dev, "###RSZ " #name "=0x%08x\n", \
+ readl(iss->regs[OMAP4_ISS_MEM_ISP_RESIZER] + RSZ_##name))
+
+#define RZA_PRINT_REGISTER(iss, name)\
+ dev_dbg(iss->dev, "###RZA " #name "=0x%08x\n", \
+ readl(iss->regs[OMAP4_ISS_MEM_ISP_RESIZER] + RZA_##name))
+
+static void resizer_print_status(struct iss_resizer_device *resizer)
+{
+ struct iss_device *iss = to_iss_device(resizer);
+
+ dev_dbg(iss->dev, "-RESIZER Register dump-\n");
+
+ RSZ_PRINT_REGISTER(iss, SYSCONFIG);
+ RSZ_PRINT_REGISTER(iss, IN_FIFO_CTRL);
+ RSZ_PRINT_REGISTER(iss, FRACDIV);
+ RSZ_PRINT_REGISTER(iss, SRC_EN);
+ RSZ_PRINT_REGISTER(iss, SRC_MODE);
+ RSZ_PRINT_REGISTER(iss, SRC_FMT0);
+ RSZ_PRINT_REGISTER(iss, SRC_FMT1);
+ RSZ_PRINT_REGISTER(iss, SRC_VPS);
+ RSZ_PRINT_REGISTER(iss, SRC_VSZ);
+ RSZ_PRINT_REGISTER(iss, SRC_HPS);
+ RSZ_PRINT_REGISTER(iss, SRC_HSZ);
+ RSZ_PRINT_REGISTER(iss, DMA_RZA);
+ RSZ_PRINT_REGISTER(iss, DMA_RZB);
+ RSZ_PRINT_REGISTER(iss, DMA_STA);
+ RSZ_PRINT_REGISTER(iss, GCK_MMR);
+ RSZ_PRINT_REGISTER(iss, GCK_SDR);
+ RSZ_PRINT_REGISTER(iss, IRQ_RZA);
+ RSZ_PRINT_REGISTER(iss, IRQ_RZB);
+ RSZ_PRINT_REGISTER(iss, YUV_Y_MIN);
+ RSZ_PRINT_REGISTER(iss, YUV_Y_MAX);
+ RSZ_PRINT_REGISTER(iss, YUV_C_MIN);
+ RSZ_PRINT_REGISTER(iss, YUV_C_MAX);
+ RSZ_PRINT_REGISTER(iss, SEQ);
+
+ RZA_PRINT_REGISTER(iss, EN);
+ RZA_PRINT_REGISTER(iss, MODE);
+ RZA_PRINT_REGISTER(iss, 420);
+ RZA_PRINT_REGISTER(iss, I_VPS);
+ RZA_PRINT_REGISTER(iss, I_HPS);
+ RZA_PRINT_REGISTER(iss, O_VSZ);
+ RZA_PRINT_REGISTER(iss, O_HSZ);
+ RZA_PRINT_REGISTER(iss, V_PHS_Y);
+ RZA_PRINT_REGISTER(iss, V_PHS_C);
+ RZA_PRINT_REGISTER(iss, V_DIF);
+ RZA_PRINT_REGISTER(iss, V_TYP);
+ RZA_PRINT_REGISTER(iss, V_LPF);
+ RZA_PRINT_REGISTER(iss, H_PHS);
+ RZA_PRINT_REGISTER(iss, H_DIF);
+ RZA_PRINT_REGISTER(iss, H_TYP);
+ RZA_PRINT_REGISTER(iss, H_LPF);
+ RZA_PRINT_REGISTER(iss, DWN_EN);
+ RZA_PRINT_REGISTER(iss, SDR_Y_BAD_H);
+ RZA_PRINT_REGISTER(iss, SDR_Y_BAD_L);
+ RZA_PRINT_REGISTER(iss, SDR_Y_SAD_H);
+ RZA_PRINT_REGISTER(iss, SDR_Y_SAD_L);
+ RZA_PRINT_REGISTER(iss, SDR_Y_OFT);
+ RZA_PRINT_REGISTER(iss, SDR_Y_PTR_S);
+ RZA_PRINT_REGISTER(iss, SDR_Y_PTR_E);
+ RZA_PRINT_REGISTER(iss, SDR_C_BAD_H);
+ RZA_PRINT_REGISTER(iss, SDR_C_BAD_L);
+ RZA_PRINT_REGISTER(iss, SDR_C_SAD_H);
+ RZA_PRINT_REGISTER(iss, SDR_C_SAD_L);
+ RZA_PRINT_REGISTER(iss, SDR_C_OFT);
+ R
Re: [dm-devel] Reworking dm-writeboost [was: Re: staging: Add dm-writeboost]
On Tue, 1 Oct 2013, Joe Thornber wrote: > > Alternatively, delaying them will stall the filesystem because it's > > waiting for said REQ_FUA IO to complete. For example, journal writes > > in XFS are extremely IO latency sensitive in workloads that have a > > signifincant number of ordering constraints (e.g. O_SYNC writes, > > fsync, etc) and delaying even one REQ_FUA/REQ_FLUSH can stall the > > filesystem for the majority of that barrier_deadline_ms. > > Yes, this is a valid concern, but I assume Akira has benchmarked. > With dm-thin, I delay the REQ_FUA/REQ_FLUSH for a tiny amount, just to > see if there are any other FUA requests on my queue that can be > aggregated into a single flush. I agree with you that the target > should never delay waiting for new io; that's asking for trouble. > > - Joe You could send the first REQ_FUA/REQ_FLUSH request directly to the disk and aggregate all the requests that were received while you processed the initial request. This way, you can do request batching without introducing artifical delays. Mikulas ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Tuesday, October 01, 2013 2:43 PM
>
> The hardware offers a 4-bit register containing the number of host
> channels. However, the values of these register mean 1-16 host channels,
> not 0-15. Since the dwc2_hw_params struct stores the actual number of
> host channels supported instead of the raw register value, it should be
> 5 bits wide instead of 4.
>
> Before this commit, hardware with 16 host channels would overflow the
> field, making it appear as 0 channels.
>
> This bug was introduced in commit 9badec2 (staging: dwc2: interpret all
> hwcfg and related register at init time).
>
> Reported-by: Dinh Nguyen
> Signed-off-by: Matthijs Kooijman
> ---
> drivers/staging/dwc2/core.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/dwc2/core.h b/drivers/staging/dwc2/core.h
> index f7ba34b..fab718d 100644
> --- a/drivers/staging/dwc2/core.h
> +++ b/drivers/staging/dwc2/core.h
> @@ -294,7 +294,7 @@ struct dwc2_hw_params {
> unsigned dev_token_q_depth:5;
> unsigned max_transfer_size:26;
> unsigned max_packet_count:11;
> - unsigned host_channels:4;
> + unsigned host_channels:5;
> unsigned hs_phy_type:2;
> unsigned fs_phy_type:2;
> unsigned i2c_enable:1;
> --
Acked-by: Paul Zimmerman
By the way, it looks like 'num_dev_ep' would have the same problem,
except it is not used because we don't support device mode yet.
That one and also 'num_dev_perio_in_ep' and 'dev_token_q_depth' should
be removed, I think.
--
Paul
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
dm-writeboost testing
Hi I tested dm-writeboost and I found these problems: Performance problems: I tested dm-writeboost with disk as backing device and ramdisk as cache device. When I run mkfs.ext4 on the dm-writeboost device, it writes data to the cache on the first time. However, on next mkfs.ext4 invocations, dm-writeboost writes data to the disk, not to the cache. mkfs.ext4 on raw disk: 1.5s mkfs.ext4 on dm-cache using raw disk and ramdisk: 1st time - 0.15s next time - 0.12s mkfs.ext4 on dm-writeboost using raw disk and ramdisk: 1st time - 0.11s next time - 1.71s, 1.31s, 0.91s, 0.86s, 0.82s - there seems to be some error in logic in dm-writeboost that makes it not cache writes if these writes are already placed in the cache. In real-world scenarios where the same piece of disk is overwritten over and over again (for example journal), this could cause performance problems. dm-cache doesn't have this problem, if you overwrite the same piece of data again and again, it goes to the cache device. Reliability problems (these problems are reproducible, they happen every time). Tests were done on 3.10.13 on Opteron and 3.11.3 on PA-RISC. On 3.10.13 on Opteron on preemptible kernel, I get "BUG: workqueue leaked lock or atomic" when unloading the device with dmsetup remove. Also, on this machine, I see a bug, if I load dm-writeboost and terminate X server - Xorg hangs flusing workqueue. On 3.11.3 on PA-RISC without preemption, the device unloads (although it takes many seconds and vmstat shows that the machine is idle during this time), but I get deadlock when I load the device the second time. The deadlock happens either on load on when writing to the newly loaded device. deadlock when the device is loaded the second time: [ 8336.212499] SysRq : Show Blocked State [ 8336.212499] taskPC stack pid father [ 8336.212499] dmsetup D 401040c0 0 1594 1572 0x0010 [ 8336.212499] Backtrace: [ 8336.212499] [<40111608>] __schedule+0x280/0x678 [ 8336.212499] [<40111e88>] schedule+0x38/0x90 [ 8336.212499] [<4010ed1c>] schedule_timeout+0x1b4/0x208 [ 8336.212499] [<40111c1c>] wait_for_common+0x124/0x1e8 [ 8336.212499] [<40111d04>] wait_for_completion+0x24/0x38 [ 8336.212499] [<107d9778>] wait_for_migration+0x38/0xb0 [dm_writeboost] [ 8336.212499] [<107d7cf8>] resume_cache+0x1100/0x16f8 [dm_writeboost] Another deadlock when loaded the second time and running mkfs.ex3 on the writeboost device (it got cut off in the scrollback buffer): [ 782.579921] [<40112280>] schedule_preempt_disabled+0x20/0x38 [ 782.579921] [<40110764>] __mutex_lock_slowpath+0x15c/0x290 [ 782.579921] [<40110928>] mutex_lock+0x90/0x98 [ 782.579921] [<107f8b74>] flush_current_buffer+0x2c/0xb0 [dm_writeboost] [ 782.579921] [<107fecbc>] sync_proc+0x7c/0xc8 [dm_writeboost] [ 782.579921] [<401591d0>] process_one_work+0x160/0x460 [ 782.579921] [<40159bb8>] worker_thread+0x300/0x478 [ 782.579921] [<40161a68>] kthread+0x118/0x128 [ 782.579921] [<40104020>] end_fault_vector+0x20/0x28 [ 782.579921] timer_interrupt(CPU 0): delayed! cycles A099A8C1 rem 22345C next/now CDFE401953/CDFE1DE4F7 [ 785.403254] [ 785.403254] mkfs.ext3 D 401040c0 0 2309 2237 0x0010 [ 785.403254] Backtrace: [ 785.403254] [<40111608>] __schedule+0x280/0x678 [ 785.403254] [<40111e88>] schedule+0x38/0x90 [ 785.403254] [<4010ed1c>] schedule_timeout+0x1b4/0x208 [ 785.403254] [<40111c1c>] wait_for_common+0x124/0x1e8 [ 785.403254] [<40111d04>] wait_for_completion+0x24/0x38 [ 785.403254] [<107fe778>] wait_for_migration+0x38/0xb0 [dm_writeboost] [ 785.403254] [<107f7fe8>] queue_current_buffer+0x78/0x3c8 [dm_writeboost] [ 785.403254] [<107f96b8>] writeboost_map+0x660/0x970 [dm_writeboost] [ 785.403254] [<1079477c>] __map_bio+0x9c/0x148 [dm_mod] [ 785.403254] [<10794cf0>] __clone_and_map_data_bio+0x188/0x288 [dm_mod] [ 785.403254] [<10795594>] __split_and_process_bio+0x474/0x6c8 [dm_mod] [ 785.403254] [<10796180>] dm_request+0x118/0x278 [dm_mod] [ 785.403254] [<402d8360>] generic_make_request+0x128/0x1a0 [ 785.403254] [<402d8448>] submit_bio+0x70/0x140 [ 785.403254] [<40231c68>] _submit_bh+0x200/0x3b8 [ 785.403254] [<40231e34>] submit_bh+0x14/0x20 A leaked prermpt count on unload (with preemptible kernel): BUG: workqueue leaked lock or atomic: kworker/u26:1/0x0001/1031 last function: flush_proc [dm_writeboost] CPU: 10 PID: 1031 Comm: kworker/u26:1 Tainted: P O 3.10.13 #9 Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 Workqueue: flushwq flush_proc [dm_writeboost] 8134e746 81052c1d 3e5428c0 88023f578c00 88023f578c18 88044
Re: [PATCH v4 1/2] staging: dgap: tty.c: adds error handing in tty driver allocations
On Tue, Oct 01, 2013 at 12:54:20PM -0400, Lidza Louina wrote: > + return 0; > + > +err_unregister_serial: > +tty_unregister_driver(brd->SerialDriver); > +err_free_print_ttys: > +kfree(brd->PrintDriver->ttys); > +err_put_tty_print: > +put_tty_driver(brd->PrintDriver); > +err_free_serial_ttys: > +kfree(brd->SerialDriver->ttys); > +err_put_tty_serial: > +put_tty_driver(brd->SerialDriver); > return (rc); You forgot to run this patch through checkpatch.pl :( This series has been a major pain, why not set it aside for a few days and do something easier before picking it up and trying it again? thanks, greg "I need a vacation too" k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: MTD: Micron SPINAND Driver support
On Tue, Oct 01, 2013 at 03:03:58PM +0530, Kamlakant Patel wrote: > > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/mt29f_spinand/Kconfig | 16 + > drivers/staging/mt29f_spinand/Makefile| 1 + > drivers/staging/mt29f_spinand/TODO| 13 + > drivers/staging/mt29f_spinand/mt29f_spinand.c | 962 > ++ > drivers/staging/mt29f_spinand/mt29f_spinand.h | 107 +++ Why do you need a separate .h file for a single driver? It's not a reason to reject this, just curious if it's that way for a reason. I'll look at this closer tomorrow and apply it if it passes my minor amount of build testing. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: MTD: Micron SPINAND Driver support
On Tue, Oct 01, 2013 at 03:03:58PM +0530, Kamlakant Patel wrote: > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -136,6 +136,8 @@ source "drivers/staging/goldfish/Kconfig" > > source "drivers/staging/netlogic/Kconfig" > > +source "drivers/staging/mt29f_spinand/Kconfig" > + Any reason you don't put it at the end of the file, and need it here in the middle? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] Staging: MTD: Micron SPINAND Driver support
> From: linux-mtd On Behalf Of Brian Norris > > On Tue, Oct 01, 2013 at 03:03:58PM +0530, Kamlakant Patel wrote: > > This patch adds support for Micron SPINAND via MTD. > > > > Signed-off-by: Mona Anonuevo > > Signed-off-by: Kamlakant Patel > > --- > > This patch has to be merged via staging tree. > > > > This is a driver from Micron for MT29F1G01ZACH4 SPI based NAND chips. > This driver had > > been posted multiple times to the mtd list. > > 1. http://lists.infradead.org/pipermail/linux-mtd/2010-May/031975.html > > 2. http://lists.infradead.org/pipermail/linux-mtd/2010-April/029523.html > > 3. patchwork.ozlabs.org/patch/258697/ > > This has not been merged into the main kernel yet. > > > > I have cleaned and updated it for current kernel. Since there are many > users for > > this driver, it may be useful to add it to the staging tree, where further > > fixes > and > > cleanups can be done. Once it reaches to the standard will be moved to the > mtd. > > > > This driver has been tested with Micron SPINAND MT29F1G01ZACH4 chip > on kernel 3.12 on > > the Netlogic XLP platforms. > > > > Mona Anonuevo, I have retained your sign-offs from the original patch. > > I see that major portion (especially the generic framework) is ported from http://lists.infradead.org/pipermail/linux-mtd/2010-May/031975.html So shouldn't you just maintain the original authorship ? And the original headers ? > > You can address these comments in follow up patches after it's included > in staging, though. There's probably more review needed anyway > eventually (I see that no one really has reviewed this on the MTD > mailing list yet). > The original version of this patch in 2010 added *generic spinand* framework. And support for m29f (Micron devices) should have been added using that generic framework. But due to lack of response generic framework never went in. Therefore I think this patch series adds a customized driver just for 'm29f' (Micron serial NAND) devices, removing the generalization. There was a refreshed version of original patch (with generic framework) but no response on that too. I don't want to hold this patch, but it would be good, if you can review generic framework also .. https://lkml.org/lkml/2013/6/26/88 with regards, pekon ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/6] v4l: omap4iss: Add support for OMAP4 camera interface - Core
A few small comments below... On 10/03/2013 01:55 AM, Laurent Pinchart wrote: > From: Sergio Aguirre > > This adds a very simplistic driver to utilize the CSI2A interface inside > the ISS subsystem in OMAP4, and dump the data to memory. > > Check Documentation/video4linux/omap4_camera.txt for details. > > This commit adds the driver core, registers definitions and > documentation. > > Signed-off-by: Sergio Aguirre > > [Port the driver to v3.12-rc3, including the following changes > - Don't include plat/ headers > - Don't use cpu_is_omap44xx() macro > - Don't depend on EXPERIMENTAL > - Fix s_crop operation prototype > - Update link_notify prototype > - Rename media_entity_remote_source to media_entity_remote_pad] > > Signed-off-by: Laurent Pinchart > --- > Documentation/video4linux/omap4_camera.txt | 63 ++ > drivers/staging/media/omap4iss/iss.c | 1477 > > drivers/staging/media/omap4iss/iss.h | 153 +++ > drivers/staging/media/omap4iss/iss_regs.h | 883 + > include/media/omap4iss.h | 65 ++ > 5 files changed, 2641 insertions(+) > create mode 100644 Documentation/video4linux/omap4_camera.txt > create mode 100644 drivers/staging/media/omap4iss/iss.c > create mode 100644 drivers/staging/media/omap4iss/iss.h > create mode 100644 drivers/staging/media/omap4iss/iss_regs.h > create mode 100644 include/media/omap4iss.h > > diff --git a/Documentation/video4linux/omap4_camera.txt > b/Documentation/video4linux/omap4_camera.txt > new file mode 100644 > index 000..2ebbd1d > --- /dev/null > +++ b/Documentation/video4linux/omap4_camera.txt > @@ -0,0 +1,63 @@ > + OMAP4 ISS Driver > + > + > +Introduction > + > + > +The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS), > +Which contains several components that can be categorized in 3 big groups: > + > +- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2) > +- ISP (Image Signal Processor) > +- SIMCOP (Still Image Coprocessor) > + > +For more information, please look in [1] for latest version of: > + "OMAP4430 Multimedia Device Silicon Revision 2.x" > + > +As of Revision AB, the ISS is described in detail in section 8. > + > +This driver is supporting _only_ the CSI2-A/B interfaces for now. > + > +It makes use of the Media Controller framework [2], and inherited most of the > +code from OMAP3 ISP driver (found under drivers/media/video/omap3isp/*), > except Update the omap3isp path. > +that it doesn't need an IOMMU now for ISS buffers memory mapping. > + > +Supports usage of MMAP buffers only (for now). > + > +IMPORTANT: It is recommended to have this patchset: > + Contiguous Memory Allocator (v22) [3]. This note can be removed as CMA has been merged. > + > +Tested platforms > + > + > +- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in > + which only the last one is supported, outputting YUV422 frames). > + > +- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, > in > + which only the OV5650 are supported, outputting RAW10 frames). > + > +- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with > + following sensors: > + * OV5640 > + * OV5650 > + > +- Tested on mainline kernel: > + > + > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary > + > + Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7) > + > +File list > +- > +drivers/media/video/omap4iss/ Wrong path. > +include/media/omap4iss.h > + > +References > +-- > + > +[1] > http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62 > +[2] http://lwn.net/Articles/420485/ > +[3] http://www.spinics.net/lists/linux-media/msg44370.html > +-- > +Author: Sergio Aguirre > +Copyright (C) 2012, Texas Instruments > diff --git a/drivers/staging/media/omap4iss/iss.c > b/drivers/staging/media/omap4iss/iss.c > new file mode 100644 > index 000..d054d9b > --- /dev/null > +++ b/drivers/staging/media/omap4iss/iss.c > @@ -0,0 +1,1477 @@ > +/* > + * TI OMAP4 ISS V4L2 Driver > + * > + * Copyright (C) 2012, Texas Instruments > + * > + * Author: Sergio Aguirre > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include "iss.h" > +#include "iss_regs.h" > + > +#define ISS_PRINT_REGISTER(iss, name)\ > + dev_dbg(iss->dev, "###ISS " #name "=0x%08x\n", \ > + readl(iss->regs[OMAP4_ISS_MEM_TOP] + ISS_##name)) > + > +s
Re: [PATCH 2/6] v4l: omap4iss: Add support for OMAP4 camera interface - Video devices
On 10/03/2013 01:55 AM, Laurent Pinchart wrote:
> From: Sergio Aguirre
>
> This adds a very simplistic driver to utilize the CSI2A interface inside
> the ISS subsystem in OMAP4, and dump the data to memory.
>
> Check Documentation/video4linux/omap4_camera.txt for details.
>
> This commit adds video devices support.
>
> Signed-off-by: Sergio Aguirre
>
> [Port the driver to v3.12-rc3, including the following changes
> - Don't include plat/ headers
> - Don't use cpu_is_omap44xx() macro
> - Don't depend on EXPERIMENTAL
> - Fix s_crop operation prototype
> - Update link_notify prototype
> - Rename media_entity_remote_source to media_entity_remote_pad]
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/staging/media/omap4iss/iss_video.c | 1129
>
> drivers/staging/media/omap4iss/iss_video.h | 201 +
> 2 files changed, 1330 insertions(+)
> create mode 100644 drivers/staging/media/omap4iss/iss_video.c
> create mode 100644 drivers/staging/media/omap4iss/iss_video.h
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c
> new file mode 100644
> index 000..31f1b88
> --- /dev/null
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> +/*
> -
> + * V4L2 ioctls
> + */
> +
> +static int
> +iss_video_querycap(struct file *file, void *fh, struct v4l2_capability *cap)
> +{
> + struct iss_video *video = video_drvdata(file);
> +
> + strlcpy(cap->driver, ISS_VIDEO_DRIVER_NAME, sizeof(cap->driver));
> + strlcpy(cap->card, video->video.name, sizeof(cap->card));
> + strlcpy(cap->bus_info, "media", sizeof(cap->bus_info));
> +
> + if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
> + else
> + cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
Set device_caps instead of capabilities and add:
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
> +
> + return 0;
> +}
> +
> +static int
> +iss_video_get_format(struct file *file, void *fh, struct v4l2_format *format)
> +{
> + struct iss_video_fh *vfh = to_iss_video_fh(fh);
> + struct iss_video *video = video_drvdata(file);
> +
> + if (format->type != video->type)
> + return -EINVAL;
> +
> + mutex_lock(&video->mutex);
> + *format = vfh->format;
> + mutex_unlock(&video->mutex);
> +
> + return 0;
> +}
> +
> +static int
> +iss_video_set_format(struct file *file, void *fh, struct v4l2_format *format)
> +{
> + struct iss_video_fh *vfh = to_iss_video_fh(fh);
> + struct iss_video *video = video_drvdata(file);
> + struct v4l2_mbus_framefmt fmt;
> +
> + if (format->type != video->type)
> + return -EINVAL;
> +
> + mutex_lock(&video->mutex);
> +
> + /* Fill the bytesperline and sizeimage fields by converting to media bus
> + * format and back to pixel format.
> + */
> + iss_video_pix_to_mbus(&format->fmt.pix, &fmt);
> + iss_video_mbus_to_pix(video, &fmt, &format->fmt.pix);
> +
> + vfh->format = *format;
> +
> + mutex_unlock(&video->mutex);
> + return 0;
> +}
> +
> +static int
> +iss_video_try_format(struct file *file, void *fh, struct v4l2_format *format)
> +{
> + struct iss_video *video = video_drvdata(file);
> + struct v4l2_subdev_format fmt;
> + struct v4l2_subdev *subdev;
> + u32 pad;
> + int ret;
> +
> + if (format->type != video->type)
> + return -EINVAL;
> +
> + subdev = iss_video_remote_subdev(video, &pad);
> + if (subdev == NULL)
> + return -EINVAL;
> +
> + iss_video_pix_to_mbus(&format->fmt.pix, &fmt.format);
> +
> + fmt.pad = pad;
> + fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
> + if (ret)
> + return ret == -ENOIOCTLCMD ? -EINVAL : ret;
Return ENOTTY instead of EINVAL. Even better, use v4l2_subdev_has_op() +
v4l2_disable_ioctl()
to just disable ioctls based on the available subdev ops in probe().
> +
> + iss_video_mbus_to_pix(video, &fmt.format, &format->fmt.pix);
> + return 0;
> +}
> +
> +static int
> +iss_video_cropcap(struct file *file, void *fh, struct v4l2_cropcap *cropcap)
> +{
> + struct iss_video *video = video_drvdata(file);
> + struct v4l2_subdev *subdev;
> + int ret;
> +
> + subdev = iss_video_remote_subdev(video, NULL);
> + if (subdev == NULL)
> + return -EINVAL;
> +
> + mutex_lock(&video->mutex);
> + ret = v4l2_subdev_call(subdev, video, cropcap, cropcap);
> + mutex_unlock(&video->mutex);
> +
> + return ret == -ENOIOCTLCMD ? -EINVAL : ret;
> +}
> +
> +static int
> +iss_video_get_crop(struct file *file, void *fh, struct v4l2_crop *crop)
> +{
> + struct iss_video *video = video_drvdata(file);
> + struct v4l2_subdev_format format;
> +
