Re: [DTV-TABLE] lu-all
On Thu, Feb 14, 2013 at 8:53 AM, Oliver Schinagl oliver+l...@schinagl.nl wrote: Applied in c57839aad2260306e6adecc0058fb683a8b34bc4 Thanks If everybody could push to the repo, it would become a huge mess ;) If a scanfile would needed to be updated on a regular basis (very unlikely) someone could maintain it of course. For now it is based on user contributions. got it. You can always do this to your local clone and have a pull request to your branch. But it's much easier to review on the mailing list using a patch. btw, git send-email or git format-patch help greatly in that regard. Thanks, I'm very new to git so I will study 'pull request' and 'git send-email' or 'git format-patch' I don't have accurate scan for Bordeaux, I believe fr-Bordeaux should been deleted like all region was deleted in July 2011 in one batch by Christoph Pfister. this if all region should have been deleted.. it is strange that decision was made. it is like initial scan files are not needed in fact. (why not needed for france?) I have no clue what the current situation is in France and why certain decisions where made. If anybody has accurate information to fix things, we can happily fix things. Regards, Michael -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
Hi Tomi, Tomi Valkeinen wrote on 2013-02-07: FIFO underflow means that the DSS hardware wasn't able to fetch enough pixel data in time to output them to the panel. Sometimes this happens because of plain misconfiguration, but usually it happens because of the hardware just can't do things fast enough with the configuration the user has set. In this case I see that you are using VRFB rotation on fb0, and the rotation is 270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees. It may be that when the DSS is resumed, there's a peak in the mem usage as DSS suddenly needs to fetch lots of data. Another issue that could be involved is power management. After the DSS is suspended, parts of OMAP may be put to sleep. When the DSS is resumed, these parts need to be woken up, and it may be that there's a higher mem latency for a short period of time right after resume. Which could again cause DSS not getting enough pixel data. You say the issue doesn't happen if you disable fb0. What happens if you disable fb0, blank the screen, then unblank the screen, and after that enable fb0 again? By disable fb0 do you mean disconnect fb0 from ovl0 or disable ovl0? I have done both: http://pastebin.com/Bxm1Z2RY This works as expected. Further tests I have done: Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the background causes a fifo underflow too: http://pastebin.com/f3JnMLsV This happens only, if I enable the vrfb (rotate=3). So the whole thing seems to be a rotation issue. Do you have some hints to trace down the problem? How about if you disable VRFB rotation, either totally, or set the rotation to 0 or 180 degrees? Disable rotation is not an option for me, as we have a wrong oriented portrait display with 480x800 which we must use in landscape mode... And you can also tune the PM so that deeper sleep states are prevented. I don't remember right away how this is done, though. Tomi Regards, Florian P.S. @Laurent: Do you use your streamer on a headless device? What is your DSS-config? Do you have a framebuffer-console on fb0? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] soc_camera: Add RGB666 RGB888 formats
Based on work done by Katsuya Matsubara.
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
drivers/media/platform/soc_camera/soc_mediabus.c | 42 ++
include/media/soc_camera.h |6 +++-
include/media/soc_mediabus.h |3 ++
include/uapi/linux/v4l2-mediabus.h |6 +++-
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c
b/drivers/media/platform/soc_camera/soc_mediabus.c
index a397812..d8acfd3 100644
--- a/drivers/media/platform/soc_camera/soc_mediabus.c
+++ b/drivers/media/platform/soc_camera/soc_mediabus.c
@@ -97,6 +97,42 @@ static const struct soc_mbus_lookup mbus_fmt[] = {
.layout = SOC_MBUS_LAYOUT_PACKED,
},
}, {
+ .code = V4L2_MBUS_FMT_RGB666_1X18,
+ .fmt = {
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .name = RGB666/32bpp,
+ .bits_per_sample= 18,
+ .packing= SOC_MBUS_PACKING_EXTEND32,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+}, {
+ .code = V4L2_MBUS_FMT_RGB888_1X24,
+ .fmt = {
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .name = RGB888/32bpp,
+ .bits_per_sample= 24,
+ .packing= SOC_MBUS_PACKING_EXTEND32,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+}, {
+ .code = V4L2_MBUS_FMT_RGB888_2X12_BE,
+ .fmt = {
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .name = RGB888/32bpp,
+ .bits_per_sample= 12,
+ .packing= SOC_MBUS_PACKING_EXTEND32,
+ .order = SOC_MBUS_ORDER_BE,
+ },
+}, {
+ .code = V4L2_MBUS_FMT_RGB888_2X12_LE,
+ .fmt = {
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .name = RGB888/32bpp,
+ .bits_per_sample= 12,
+ .packing= SOC_MBUS_PACKING_EXTEND32,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+}, {
.code = V4L2_MBUS_FMT_SBGGR8_1X8,
.fmt = {
.fourcc = V4L2_PIX_FMT_SBGGR8,
@@ -358,6 +394,10 @@ int soc_mbus_samples_per_pixel(const struct
soc_mbus_pixelfmt *mf,
*numerator = 1;
*denominator = 1;
return 0;
+ case SOC_MBUS_PACKING_EXTEND32:
+ *numerator = 1;
+ *denominator = 1;
+ return 0;
case SOC_MBUS_PACKING_2X8_PADHI:
case SOC_MBUS_PACKING_2X8_PADLO:
*numerator = 2;
@@ -395,6 +435,8 @@ s32 soc_mbus_bytes_per_line(u32 width, const struct
soc_mbus_pixelfmt *mf)
return width * 3 / 2;
case SOC_MBUS_PACKING_VARIABLE:
return 0;
+ case SOC_MBUS_PACKING_EXTEND32:
+ return width * 4;
}
return -EINVAL;
}
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 6442edc..c820be2 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -231,10 +231,14 @@ struct soc_camera_sense {
#define SOCAM_DATAWIDTH_10 SOCAM_DATAWIDTH(10)
#define SOCAM_DATAWIDTH_15 SOCAM_DATAWIDTH(15)
#define SOCAM_DATAWIDTH_16 SOCAM_DATAWIDTH(16)
+#define SOCAM_DATAWIDTH_18 SOCAM_DATAWIDTH(18)
+#define SOCAM_DATAWIDTH_24 SOCAM_DATAWIDTH(24)
#define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_4 | SOCAM_DATAWIDTH_8 | \
SOCAM_DATAWIDTH_9 | SOCAM_DATAWIDTH_10 | \
- SOCAM_DATAWIDTH_15 | SOCAM_DATAWIDTH_16)
+ SOCAM_DATAWIDTH_12 | SOCAM_DATAWIDTH_15 | \
+ SOCAM_DATAWIDTH_16 | SOCAM_DATAWIDTH_18 | \
+ SOCAM_DATAWIDTH_24)
static inline void soc_camera_limit_side(int *start, int *length,
unsigned int start_min,
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index 0dc6f46..eea98d1 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -26,6 +26,8 @@
* @SOC_MBUS_PACKING_VARIABLE: compressed formats with variable packing
* @SOC_MBUS_PACKING_1_5X8:used for packed YUV 4:2:0 formats, where 4
* pixels occupy 6 bytes in RAM
+ * @SOC_MBUS_PACKING_EXTEND32: sample width (e.g., 24 bits) has to be extended
+ * to 32 bits
*/
enum soc_mbus_packing {
SOC_MBUS_PACKING_NONE,
@@ -34,6 +36,7 @@ enum soc_mbus_packing {
SOC_MBUS_PACKING_EXTEND16,
SOC_MBUS_PACKING_VARIABLE,
SOC_MBUS_PACKING_1_5X8,
+ SOC_MBUS_PACKING_EXTEND32,
};
/**
diff --git a/include/uapi/linux/v4l2-mediabus.h
Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
On 2013-02-14 11:30, Florian Neuhaus wrote: Hi Tomi, Tomi Valkeinen wrote on 2013-02-07: FIFO underflow means that the DSS hardware wasn't able to fetch enough pixel data in time to output them to the panel. Sometimes this happens because of plain misconfiguration, but usually it happens because of the hardware just can't do things fast enough with the configuration the user has set. In this case I see that you are using VRFB rotation on fb0, and the rotation is 270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees. It may be that when the DSS is resumed, there's a peak in the mem usage as DSS suddenly needs to fetch lots of data. Another issue that could be involved is power management. After the DSS is suspended, parts of OMAP may be put to sleep. When the DSS is resumed, these parts need to be woken up, and it may be that there's a higher mem latency for a short period of time right after resume. Which could again cause DSS not getting enough pixel data. You say the issue doesn't happen if you disable fb0. What happens if you disable fb0, blank the screen, then unblank the screen, and after that enable fb0 again? By disable fb0 do you mean disconnect fb0 from ovl0 or disable ovl0? I have done both: http://pastebin.com/Bxm1Z2RY This works as expected. I think both disconnecting fb0 and ovl0, and disabling ovl0 end up doing the same, which is disabling ovl0. Which is what I meant. So, if I understand correctly, this only happens at unblank, and can be circumvented by temporarily keeping ovl0 disabled during the unblank, and enabling ovl0 afterwards works fine. So for some reason the time of unblank is extra heavy for the memory bus. Archit, I have a feeling that enabling the LCD is heavier on the memory bus than what happens at VBLANK, even if both start fetching the pixels for a fresh frame. You've been twiddling with the FIFO stuff, am I right there? Further tests I have done: Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the background causes a fifo underflow too: http://pastebin.com/f3JnMLsV This happens only, if I enable the vrfb (rotate=3). So the whole thing seems to be a rotation issue. Do you have some hints to trace down the problem? Not rotation issue as such, but memory bandwidth issue. How about if you disable VRFB rotation, either totally, or set the rotation to 0 or 180 degrees? Disable rotation is not an option for me, as we have a wrong oriented portrait display with 480x800 which we must use in landscape mode... I understand, I only meant that for testing purposes. VRFB rotation with 0 and 180 cause a slight impact on the mem bus, whereas 90 and 270 rotation cause a large impact. Also, as I mentioned earlier, the PM may also affect this, as things may have been shut down in the OMAP. So disabling PM related features could also fix the problem. In many cases underflows are rather hard to debug and solve. There are things in the DSS hardware like FIFO thresholds and prefetch, and VRFB tile sizes, which can be changed (although unfortunately only by modifying the drivers). How they should be changed if a difficult question, though, and whether it'll help is also a question mark. If you want to tweak those, I suggest you study them from the TRM. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Thu, Feb 14, 2013 at 8:12 AM, Hans Verkuil hverk...@xs4all.nl wrote: Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd like to know if the upside-down changes are now OK. Thanks, Hi Hans Everything is working fine now - dmesg is clean, LED lights on and off when needed, viewport angle is correct. Thanks for the fixes. Arvydas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
Functions:
--
mutex_reserve_lock, and mutex_reserve_lock_interruptible:
Lock a buffer with a reservation_id set. reservation_id must not be
set to 0, since this is a special value that means no reservation_id.
I think the entire description should go into a file in the Documentation
directory, to make it easier to find without looking up the git history.
For the purpose of documenting this, it feels a little strange to
talk about buffers here. Obviously this is what you are using the
locks for, but it sounds like that is not the only possible use
case.
These functions will return -EDEADLK instead of -EAGAIN if
reservation_id is the same as the reservation_id that's attempted to
lock the mutex with, since in that case you presumably attempted to
lock the same lock twice.
Since the user always has to check the return value, would it be
possible to provide only the interruptible kind of this function
but not the non-interruptible one? In general, interruptible locks
are obviously harder to use, but they are much user friendlier when
something goes wrong.
mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
This is useful when mutex_reserve_lock failed with -EAGAIN, and you
unreserved all buffers so no deadlock can occur.
Are these meant to be used a lot? If not, maybe prefix them with __mutex_
instead of mutex_.
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 9121595..602c247 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -62,6 +62,11 @@ struct mutex {
#endif
};
+struct ticket_mutex {
+ struct mutex base;
+ atomic_long_t reservation_id;
+};
Have you considered changing the meaning of the count member
of the mutex in the case where a ticket mutex is used? That would
let you use an unmodified structure.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
On Tue, Feb 12, 2013 at 2:50 AM, s...@google.com wrote:
From: John Sheu s...@google.com
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Signed-off-by: John Sheu s...@google.com
Yeah, makes sense that this little helper here cleans up any damage it
caused when the callback fails.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/base/dma-buf.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 09e6878..06c6225 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -536,6 +536,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ struct file *oldfile;
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -549,15 +552,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- if (vma-vm_file)
- fput(vma-vm_file);
-
+ get_file(dmabuf-file);
+ oldfile = vma-vm_file;
vma-vm_file = dmabuf-file;
- get_file(vma-vm_file);
-
vma-vm_pgoff = pgoff;
- return dmabuf-ops-mmap(dmabuf, vma);
+ ret = dmabuf-ops-mmap(dmabuf, vma);
+ if (ret) {
+ /* restore old parameters on failure */
+ vma-vm_file = oldfile;
+ fput(dmabuf-file);
+ } else {
+ if (oldfile)
+ fput(oldfile);
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
1.7.8.6
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
On 14 February 2013 16:16, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, Feb 12, 2013 at 2:50 AM, s...@google.com wrote:
From: John Sheu s...@google.com
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Signed-off-by: John Sheu s...@google.com
Yeah, makes sense that this little helper here cleans up any damage it
caused when the callback fails.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Thanks John, Daniel!
I'll pull it in the for-next soon.
Best regards,
~Sumit.
---
drivers/base/dma-buf.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 09e6878..06c6225 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -536,6 +536,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ struct file *oldfile;
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -549,15 +552,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- if (vma-vm_file)
- fput(vma-vm_file);
-
+ get_file(dmabuf-file);
+ oldfile = vma-vm_file;
vma-vm_file = dmabuf-file;
- get_file(vma-vm_file);
-
vma-vm_pgoff = pgoff;
- return dmabuf-ops-mmap(dmabuf, vma);
+ ret = dmabuf-ops-mmap(dmabuf, vma);
+ if (ret) {
+ /* restore old parameters on failure */
+ vma-vm_file = oldfile;
+ fput(dmabuf-file);
+ } else {
+ if (oldfile)
+ fput(oldfile);
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
1.7.8.6
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Thanks and regards,
Sumit Semwal
Linaro Kernel Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
Hi Tomi, On Thursday 14 February 2013 12:08:18 Tomi Valkeinen wrote: On 2013-02-14 11:30, Florian Neuhaus wrote: Tomi Valkeinen wrote on 2013-02-07: FIFO underflow means that the DSS hardware wasn't able to fetch enough pixel data in time to output them to the panel. Sometimes this happens because of plain misconfiguration, but usually it happens because of the hardware just can't do things fast enough with the configuration the user has set. In this case I see that you are using VRFB rotation on fb0, and the rotation is 270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees. It may be that when the DSS is resumed, there's a peak in the mem usage as DSS suddenly needs to fetch lots of data. Another issue that could be involved is power management. After the DSS is suspended, parts of OMAP may be put to sleep. When the DSS is resumed, these parts need to be woken up, and it may be that there's a higher mem latency for a short period of time right after resume. Which could again cause DSS not getting enough pixel data. You say the issue doesn't happen if you disable fb0. What happens if you disable fb0, blank the screen, then unblank the screen, and after that enable fb0 again? By disable fb0 do you mean disconnect fb0 from ovl0 or disable ovl0? I have done both: http://pastebin.com/Bxm1Z2RY This works as expected. I think both disconnecting fb0 and ovl0, and disabling ovl0 end up doing the same, which is disabling ovl0. Which is what I meant. So, if I understand correctly, this only happens at unblank, and can be circumvented by temporarily keeping ovl0 disabled during the unblank, and enabling ovl0 afterwards works fine. So for some reason the time of unblank is extra heavy for the memory bus. Archit, I have a feeling that enabling the LCD is heavier on the memory bus than what happens at VBLANK, even if both start fetching the pixels for a fresh frame. You've been twiddling with the FIFO stuff, am I right there? Further tests I have done: Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the background causes a fifo underflow too: http://pastebin.com/f3JnMLsV This happens only, if I enable the vrfb (rotate=3). So the whole thing seems to be a rotation issue. Do you have some hints to trace down the problem? Not rotation issue as such, but memory bandwidth issue. How about if you disable VRFB rotation, either totally, or set the rotation to 0 or 180 degrees? Disable rotation is not an option for me, as we have a wrong oriented portrait display with 480x800 which we must use in landscape mode... I understand, I only meant that for testing purposes. VRFB rotation with 0 and 180 cause a slight impact on the mem bus, whereas 90 and 270 rotation cause a large impact. Also, as I mentioned earlier, the PM may also affect this, as things may have been shut down in the OMAP. So disabling PM related features could also fix the problem. In many cases underflows are rather hard to debug and solve. There are things in the DSS hardware like FIFO thresholds and prefetch, and VRFB tile sizes, which can be changed (although unfortunately only by modifying the drivers). How they should be changed if a difficult question, though, and whether it'll help is also a question mark. Naive question here, instead of killing the overlay completely when an underflow happens, couldn't the DSS driver somehow recover from that condition by restarting whatever needs to be restarted ? If you want to tweak those, I suggest you study them from the TRM. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
On 2013-02-14 13:07, Laurent Pinchart wrote: In many cases underflows are rather hard to debug and solve. There are things in the DSS hardware like FIFO thresholds and prefetch, and VRFB tile sizes, which can be changed (although unfortunately only by modifying the drivers). How they should be changed if a difficult question, though, and whether it'll help is also a question mark. Naive question here, instead of killing the overlay completely when an underflow happens, couldn't the DSS driver somehow recover from that condition by restarting whatever needs to be restarted ? Yes. Killing the overlay is just the safest choice. Presumably if an underflow happens, the problem is still there, and it'll just happen again if you re-enable the overlay. Obviously this is not always the case, as this problem at hand shows. There's much to improve with the DSS driver's error handling, though. I think first step would be to remove it totally from DSS, and move it to omapfb/omapdrm. It's a bit difficult to handle the errors at the lowest level. Tomi signature.asc Description: OpenPGP digital signature
Re: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann a...@arndb.de wrote: These functions will return -EDEADLK instead of -EAGAIN if reservation_id is the same as the reservation_id that's attempted to lock the mutex with, since in that case you presumably attempted to lock the same lock twice. Since the user always has to check the return value, would it be possible to provide only the interruptible kind of this function but not the non-interruptible one? In general, interruptible locks are obviously harder to use, but they are much user friendlier when something goes wrong. At least in drm/i915 we only use _interruptible locking on the command-submission ioctls for all locks which could be held while waiting for the gpu. We need unwind paths and ioctl restarting anyway to bail out on catastrophic events like gpu hangs, so signal interrupt handling comes for free. Otoh in the modeset code we generally don't bother with that, since unwinding a modeset sequence mid-way is something you don't want to do really if your sanity is dear to you. But we also never need mutli-object reservations in the modeset code, neither can I imagine a future need for it. So from my side we could drop the non-interruptible interface. But I have not checked whether dropping this would complicate the ttm conversion. mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN. This is useful when mutex_reserve_lock failed with -EAGAIN, and you unreserved all buffers so no deadlock can occur. Are these meant to be used a lot? If not, maybe prefix them with __mutex_ instead of mutex_. If you detect an inversion in a multi-buffer reservation you have to drop all locks and call these functions on the buffer which failed (that's the contention point, hence it's the right lock to sleep on). So every place using ticket locks will also call the above slowpath functions by necessity. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
Hi Mr. Lee,
thanks for the review.
On 14 February 2013 07:30, Donghwa Lee dh09@samsung.com wrote:
On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
It also removes the dependency on backlight and lcd framework
Signed-off-by: Vikas Sajjanvikas.saj...@linaro.org
---
drivers/video/exynos/s6e8ax0.c | 848
+---
1 file changed, 444 insertions(+), 404 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c
b/drivers/video/exynos/s6e8ax0.c
index 7f7b25f..5a17e3c 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -25,6 +25,7 @@
#include linux/backlight.h
#include linux/regulator/consumer.h
+#include video/display.h
#include video/mipi_display.h
#include video/exynos_mipi_dsim.h
@@ -38,8 +39,7 @@
#define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
#define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
-#define lcd_to_master(a) (a-dsim_dev-master)
-#define lcd_to_master_ops(a) ((lcd_to_master(a))-master_ops)
+#define to_panel(p) container_of(p, struct s6e8ax0, entity)
enum {
DSIM_NONE_STATE = 0,
@@ -47,20 +47,34 @@ enum {
DSIM_FRAME_DONE = 2,
};
+/* This structure defines all the properties of a backlight */
+struct backlight_prop {
+ /* Current User requested brightness (0 - max_brightness) */
+ int brightness;
+ /* Maximal value for brightness (read-only) */
+ int max_brightness;
+};
+
+struct panel_platform_data {
+ unsigned intreset_delay;
+ unsigned intpower_on_delay;
+ unsigned intpower_off_delay;
+ const char *video_source_name;
+};
+
struct s6e8ax0 {
- struct device *dev;
- unsigned intpower;
- unsigned intid;
- unsigned intgamma;
- unsigned intacl_enable;
- unsigned intcur_acl;
-
- struct lcd_device *ld;
- struct backlight_device *bd;
-
- struct mipi_dsim_lcd_device *dsim_dev;
- struct lcd_platform_data*ddi_pd;
+ struct platform_device *pdev;
+ struct video_source *src;
+ struct display_entity entity;
+ unsigned intpower;
+ unsigned intid;
+ unsigned intgamma;
+ unsigned intacl_enable;
+ unsigned intcur_acl;
+ boolpanel_reverse;
+ struct lcd_platform_data*plat_data;
struct mutexlock;
+ struct backlight_prop bl_prop;
bool enabled;
};
Could this panel driver use only CDF?
Does not consider the compatibility with backlight and lcd framework?
as of now CDF does not support backlight and lcd framework functionalities.
Once CDF has the support, we modify the driver to support both CDF and
non CDF way, there by maintaining the backward compatibility with
backlight and lcd framework.
-static const unsigned char s6e8ax0_22_gamma_30[] = {
+static unsigned char s6e8ax0_22_gamma_30[] = {
0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
};
In all case, you had changed data type to 'static unsigned char'.
Is it need to change all case? Otherwise, for the unity of the code?
in the CDF-T proposed by Mr. Tomi Valkeinen, the prototype for
dcs_write looks as below
int (*dcs_write)(struct video_source *src, int channel, u8 *data, size_t len);
It does not have const for the 3rd parameter (u8 *data ), and in our
driver we have all the arrays as const.
Just to silence the compiler warnings, i had removed the const keyword.
Thank you,
Donghwa Lee
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB_T2 Multistream support (PLP)
Hi Michael, In terms of Linux support I think you will struggle. The 290e is the only DVB-T2 device with (open) driver support in Linux. I haven't tried a TBS5880 myself but the linuxtv Wiki page doesn't look promising http://www.linuxtv.org/wiki/index.php/TBS5880_USB_DVB-T2/T/C_CI_hybrid_TV_Box In any case, that device will have the same demod (CXD2820R), and if what Antti says about the Windows driver not supporting multi-PLP either (if I've read his remarks correctly), you're probably out of luck. As far as I know the CXD2820R is the only T2 demod that's made it into any USB/PCI receivers so there are no other options. There might be a datasheet somewhere that would hint at how to provide PLP selection and then it would need implementing. The question is where to find it and how much effort would be required. Regards, Steve. On 31/01/13 15:02, Michael Stilmant-Rovi wrote: Thanks, Looking for a tuner supporting multiple PLP, is it conceivable to add to the driver the possibility to pass to the hardware that value? (I don't know if that need other math though) ( I will look the sources anyway but I don't have good knowledge) If I want to look for another USB stick how could I know if the driver will support that feature? For example is TBS5880 DVB-T2 USB TV Tuner ? I understand here that the difficulties is that few people are in a MultiPLP DVB_T2 range. even myself.. . Regards, On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari cr...@iki.fi wrote: On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote: Hello, I would like to know the support status of Multiple PLPs in DVB-T2. Is someone know if tests were performed in a broadcast with an effective Multistream? (PLP Id: 0 and 1 for example) I'm out of range of such multiplex but I'm trying some tunes on London DVB-T2 (CrystalPalace tower) unfortunately that mux seems Single PLP and everything work well :-( ( yes tune always succeed :-D ) I'm using DVB API 5.6. If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to 0, 1 or 15. the tune succeed. I'm not sure of the expected behavior, I was expecting if I tune with plp_id 1 that the tuner would fail somewhere finding that stream. So in short I don't understand what is the requirements to be able to use the DVB_T2 Multistream support proposed in APIs: o I see that the DVB API 5.8(?) had some patch at that level and so it is maybe requested? o How can I know if my driver support that feature on DVB API 5.6? (PCTV nanoStick T2 290e)? Thank you for all indications. -Michael nanoStick T2 290e Linux driver does not support multiple PLPs. I did that driver and I has only Live signal with single TS. What I think Windows driver either supports that feature. It just tunes to first PLP regardless of whole property and that's it. regards Antti -- http://palosaari.fi/ On Thu, Jan 31, 2013 at 3:39 PM, Antti Palosaari cr...@iki.fi wrote: On 01/31/2013 04:27 PM, Michael Stilmant-Rovi wrote: Hello, I would like to know the support status of Multiple PLPs in DVB-T2. Is someone know if tests were performed in a broadcast with an effective Multistream? (PLP Id: 0 and 1 for example) I'm out of range of such multiplex but I'm trying some tunes on London DVB-T2 (CrystalPalace tower) unfortunately that mux seems Single PLP and everything work well :-( ( yes tune always succeed :-D ) I'm using DVB API 5.6. If I tune with FE_SET_PROPERTY without or with DTV_DVBT2_PLP_ID set to 0, 1 or 15. the tune succeed. I'm not sure of the expected behavior, I was expecting if I tune with plp_id 1 that the tuner would fail somewhere finding that stream. So in short I don't understand what is the requirements to be able to use the DVB_T2 Multistream support proposed in APIs: o I see that the DVB API 5.8(?) had some patch at that level and so it is maybe requested? o How can I know if my driver support that feature on DVB API 5.6? (PCTV nanoStick T2 290e)? Thank you for all indications. -Michael nanoStick T2 290e Linux driver does not support multiple PLPs. I did that driver and I has only Live signal with single TS. What I think Windows driver either supports that feature. It just tunes to first PLP regardless of whole property and that's it. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
On Thursday 14 February 2013 03:38 PM, Tomi Valkeinen wrote: On 2013-02-14 11:30, Florian Neuhaus wrote: Hi Tomi, Tomi Valkeinen wrote on 2013-02-07: FIFO underflow means that the DSS hardware wasn't able to fetch enough pixel data in time to output them to the panel. Sometimes this happens because of plain misconfiguration, but usually it happens because of the hardware just can't do things fast enough with the configuration the user has set. In this case I see that you are using VRFB rotation on fb0, and the rotation is 270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees. It may be that when the DSS is resumed, there's a peak in the mem usage as DSS suddenly needs to fetch lots of data. Another issue that could be involved is power management. After the DSS is suspended, parts of OMAP may be put to sleep. When the DSS is resumed, these parts need to be woken up, and it may be that there's a higher mem latency for a short period of time right after resume. Which could again cause DSS not getting enough pixel data. You say the issue doesn't happen if you disable fb0. What happens if you disable fb0, blank the screen, then unblank the screen, and after that enable fb0 again? By disable fb0 do you mean disconnect fb0 from ovl0 or disable ovl0? I have done both: http://pastebin.com/Bxm1Z2RY This works as expected. I think both disconnecting fb0 and ovl0, and disabling ovl0 end up doing the same, which is disabling ovl0. Which is what I meant. So, if I understand correctly, this only happens at unblank, and can be circumvented by temporarily keeping ovl0 disabled during the unblank, and enabling ovl0 afterwards works fine. So for some reason the time of unblank is extra heavy for the memory bus. Archit, I have a feeling that enabling the LCD is heavier on the memory bus than what happens at VBLANK, even if both start fetching the pixels for a fresh frame. You've been twiddling with the FIFO stuff, am I right there? I don't think it's heavier in terms of memory bandwidth when you enable the LCD compared to the fetch of new frame content on a VBLANK. In both cases, the DSS tries to preload a few set of lines. In terms of responsiveness from the interconnect, it's possible that DSS has a lower priority(in the round robin queue of initiators) compared to when it was active. I don't know if LCD enable vs VBLANK has some sort of difference with VRFB. Further tests I have done: Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the background causes a fifo underflow too: http://pastebin.com/f3JnMLsV This happens only, if I enable the vrfb (rotate=3). So the whole thing seems to be a rotation issue. Do you have some hints to trace down the problem? Not rotation issue as such, but memory bandwidth issue. How about if you disable VRFB rotation, either totally, or set the rotation to 0 or 180 degrees? Disable rotation is not an option for me, as we have a wrong oriented portrait display with 480x800 which we must use in landscape mode... I understand, I only meant that for testing purposes. VRFB rotation with 0 and 180 cause a slight impact on the mem bus, whereas 90 and 270 rotation cause a large impact. Also, as I mentioned earlier, the PM may also affect this, as things may have been shut down in the OMAP. So disabling PM related features could also fix the problem. In many cases underflows are rather hard to debug and solve. There are things in the DSS hardware like FIFO thresholds and prefetch, and VRFB tile sizes, which can be changed (although unfortunately only by modifying the drivers). How they should be changed if a difficult question, though, and whether it'll help is also a question mark. One thing which might help to debug this is to comment out the underflow error handling, and see if it continues to happen, this will tell if it was just a temporary bandwidth issue, or it's some consistent PM related thing Archit -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? Should a caller check against both EOPNOTSUPP *and* ENOTTY? I searched through linux/drivers/media and found that both values are used (EOPNOTSUPP 57 times and ENOTTY 71 times in the version I have in use). While ENOTTY seems to apply here (at least from its description, not from its name) ENOTTY Inappropriate ioctl for device (originally Not a typewriter) and I can see why this would be a reason for changing this, EOPNOTSUPP doesn't really seem to apply, since there is, I assume, no socket involved here: EOPNOTSUPP Operation not supported on socket The value I would actually expect to be used in case an operation is not supported by a device is ENOTSUP Operation not supported Interestingly the driver source uses ENOTSUPP (note the double 'P') 8 times, but that name is not defined according to man errno(3). So the bottom line is that there appears to be some confusion as to which errno value to return in case an operation is not supported. Maybe all these return values should be set to ENOTSUP (with a single 'P' at the end)? Klaus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
Hey,
Op 14-02-13 11:22, Arnd Bergmann schreef:
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
Functions:
--
mutex_reserve_lock, and mutex_reserve_lock_interruptible:
Lock a buffer with a reservation_id set. reservation_id must not be
set to 0, since this is a special value that means no reservation_id.
I think the entire description should go into a file in the Documentation
directory, to make it easier to find without looking up the git history.
For the purpose of documenting this, it feels a little strange to
talk about buffers here. Obviously this is what you are using the
locks for, but it sounds like that is not the only possible use
case.
It is the idea it will end up in Documentation, however I had a hard time even
getting people to
review the code, so I found it easier to keep code and documentation in sync by
keeping it into
the commit log when I was amending things.
But yes it's the use case I use it for. The generic use case would be if you
had a number of equal
locks you want to take in an arbitrary order without deadlocking or a lock
protecting all those locks*.
*) In the eyes of lockdep you still take one of those locks, and nest all those
locks you take into that lock.
These functions will return -EDEADLK instead of -EAGAIN if
reservation_id is the same as the reservation_id that's attempted to
lock the mutex with, since in that case you presumably attempted to
lock the same lock twice.
Since the user always has to check the return value, would it be
possible to provide only the interruptible kind of this function
but not the non-interruptible one? In general, interruptible locks
are obviously harder to use, but they are much user friendlier when
something goes wrong.
I agree that in general you want to use the interruptible versions as much as
possible,
but there are some cases in ttm where it is desirable to lock non-interruptibly.
mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
This is useful when mutex_reserve_lock failed with -EAGAIN, and you
unreserved all buffers so no deadlock can occur.
Are these meant to be used a lot? If not, maybe prefix them with __mutex_
instead of mutex_.
It is a common path in case of contestion. The example lock_execbuf from the
commit log used
it. When you use the mutex_reserve_lock calls, you'll have to add calls to the
*_slow variants
too when those return -EAGAIN.
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 9121595..602c247 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -62,6 +62,11 @@ struct mutex {
#endif
};
+struct ticket_mutex {
+struct mutex base;
+atomic_long_t reservation_id;
+};
Have you considered changing the meaning of the count member
of the mutex in the case where a ticket mutex is used? That would
let you use an unmodified structure.
I have considered it, but I never found a good way to make that happen.
mutex_lock and mutex_unlock are currently still used when only a single
buffer needs to be locked.
Thanks for the review!
~Maarten
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. Should a caller check against both EOPNOTSUPP *and* ENOTTY? Current situation is a big mess. All the drivers are returning what error codes they wish. You simply cannot trust any error code. I searched through linux/drivers/media and found that both values are used (EOPNOTSUPP 57 times and ENOTTY 71 times in the version I have in use). While ENOTTY seems to apply here (at least from its description, not from its name) ENOTTY Inappropriate ioctl for device (originally Not a typewriter) and I can see why this would be a reason for changing this, EOPNOTSUPP doesn't really seem to apply, since there is, I assume, no socket involved here: EOPNOTSUPP Operation not supported on socket EOPNOTSUPP is usually used for unsupported I2C messages and that error should not be returned to the userspace. As mentioned, situation is total mess as there is very different error codes returned for unimplemented IOCTLs currently. The value I would actually expect to be used in case an operation is not supported by a device is ENOTSUP Operation not supported Interestingly the driver source uses ENOTSUPP (note the double 'P') 8 times, but that name is not defined according to man errno(3). So the bottom line is that there appears to be some confusion as to which errno value to return in case an operation is not supported. Maybe all these return values should be set to ENOTSUP (with a single 'P' at the end)? Klaus Currently, for those old statistic IOCTLs there is two errors documented: ENOTTY = IOCTL is not supported at all EAGAIN = fronted is unable to perform IOCTL at the time (eg it is sleeping) But in real life, drivers are returning very many different error codes and you could not trust. Maybe this will be changed slowly to documented error codes, during 5 or 10 years or so. Surely it will not happen anytime soon unless someone has time to start looking demod driver by driver and changing error codes. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to break User ABI. https://lkml.org/lkml/2012/12/23/75 Should a caller check against both EOPNOTSUPP *and* ENOTTY? Current situation is a big mess. All the drivers are returning what error codes they wish. You simply cannot trust any error code. As you stated above, If a device doesn't have an IOCTL implemented, it was returning EOPNOTSUPP for *any* driver that doesn't implement that IOCTL. By changing it to ENOTTY, you broke existing applications. How can a driver return an error code, for an IOCTL that is *not* implemented ? AFAICS, your statement is bogus. :-) Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On 02/14/2013 08:05 PM, Manu Abraham wrote: On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to break User ABI. https://lkml.org/lkml/2012/12/23/75 Yes, it will change API, that's clear. But the hell, how you will get anything fixed unless you change it? Introduce totally new API every-time when bug is found? You should also understand that changing that single error code on that place will not change all the drivers and there will be still some other error statuses returned by individual drivers. It is about 100% clear that ENOTTY is proper error code for unimplemented IOCTL. I remember maybe more than one discussion about that unimplemented IOCTL error code. It seems to be defined by POSIX [1] standard. If you do some searching you will easily find out a lot of discussions: [1] http://www.makelinux.net/ldd3/chp-6-sect-1 [2] http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg14981.html [3] http://linux.about.com/library/cmd/blcmdl2_ioctl.htm Should a caller check against both EOPNOTSUPP *and* ENOTTY? Current situation is a big mess. All the drivers are returning what error codes they wish. You simply cannot trust any error code. As you stated above, If a device doesn't have an IOCTL implemented, it was returning EOPNOTSUPP for *any* driver that doesn't implement that IOCTL. By changing it to ENOTTY, you broke existing applications. There is a lot of drivers implementing stub callbacks and returning own values. Likely much more than those which does not implement it at all. How can a driver return an error code, for an IOCTL that is *not* implemented ? AFAICS, your statement is bogus. :-) Just implementing IOCTL and returning some value! Have you looked those drivers?) There is very many different errors returned, especially in cases where hardware is not able to provide asked value at the time, example sleeping. Maybe the most common status is just to return 0 as status and some random numbers as data - but there has been some discussion it is bad idea too. It is just easy to fix back these few cases by implementing missing callbacks and return EOPNOTSUPP. But it will not fix all the drivers, only those which were totally without a callback. And I ran RFC before started harmonizing error codes. There was not too many people commenting how to standardize these error codes regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp IRQs
2013/2/13 Adriano Martins adrianomatosmart...@gmail.com: Hi Laurent, I think my messages are not sent to linux-media. can you help? 2013/2/13 Adriano Martins adrianomatosmart...@gmail.com: Hi, Please, help me :-) I trying capture frames from my new sensor, ov5640. I already capture images from a mt9p031 camera, but I have some problems with ov5640. Someone can explain me what are the CCDC_VD0_IRQ and CCDC_VD1_IRQ? In the mt9p031 sensor, I get all interrupts (including HS_VS_IRQ) and I can capture frames. In other sensor, I can't capture any frame. I get many HS_VS_IRQ only, then yavta app hangs and I need stop it. Then I get CCDC stop timeout! Is it necessary get CCDC_VD0_IRQ and CCDC_VD1_IRQ ever to capture a frame? I think all signal from ov5640 sensor are ok. A question about it: vsync may be in high level until the frame is transmitted? On my case I see just a pulse of vsync before hsync pulses. Is it correct? I can capture frames now, and get all interrupts. But, The image has only green color. I solved my problem. The .data_lane_shift and yuv sequence were wrong. I have configured the CCDC module as V4L2_MBUS_FMT_UYVY8_2X8, and the sensor output format is configured as YUV422 with sequence UYVY. somebody has any idea? Thanks Regards Adriano Martins -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 08:05 PM, Manu Abraham wrote: On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to break User ABI. https://lkml.org/lkml/2012/12/23/75 Yes, it will change API, that's clear. But the hell, how you will get anything fixed unless you change it? Introduce totally new API every-time when bug is found? You should also understand that changing that single error code on that place will not change all the drivers and there will be still some other error statuses returned by individual drivers. It is about 100% clear that ENOTTY is proper error code for unimplemented IOCTL. I remember maybe more than one discussion about that unimplemented IOCTL error code. It seems to be defined by POSIX [1] standard. It could be. But what I stated is thus: There existed commonality where all unimplemented IOCTL's returned EOPNOTSUPP when the corresponding callback wasn't implemented. So, this was kind of standardized though it was not the ideal thing, though it was not a big issue, it just stated socket additionally. You changed it to ENOTTY to make it fit for the idealistic world. All applications that depended for ages, on those error are now broken. Some drivers, have callbacks which are dummy as you state which return different error codes ? It would have been easier, or correct to fix those drivers, rather than blowing up all user applications. There is a lot of drivers implementing stub callbacks and returning own values. Likely much more than those which does not implement it at all. How can a driver return an error code, for an IOCTL that is *not* implemented ? AFAICS, your statement is bogus. :-) Just implementing IOCTL and returning some value! Have you looked those drivers?) There is very many different errors returned, especially in cases where hardware is not able to provide asked value at the time, example sleeping. When you implement an IOCTL callback, then you have an implemented IOCTL. I still don't understand by what you state: ENOTTY is correct error code for the case IOCTL is not implemented. in comparison to your above statement. As i stated just above, it would be sensible to fix the drivers, rather than causing even more confusion. Maybe the most common status is just to return 0 as status and some random numbers as data - but there has been some discussion it is bad idea too. It is just easy to fix back these few cases by implementing missing callbacks and return EOPNOTSUPP. But it will not fix all the drivers, only those which were totally without a callback. And I ran RFC before started harmonizing error codes. There was not too many people commenting how to standardize these error codes Just because no one commented, doesn't make it right to blow up userspace applications. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp IRQs
Hi Adriano, On Thursday 14 February 2013 17:17:40 Adriano Martins wrote: 2013/2/13 Adriano Martins adrianomatosmart...@gmail.com: 2013/2/13 Adriano Martins adrianomatosmart...@gmail.com: Hi, Please, help me :-) I trying capture frames from my new sensor, ov5640. I already capture images from a mt9p031 camera, but I have some problems with ov5640. Someone can explain me what are the CCDC_VD0_IRQ and CCDC_VD1_IRQ? Those two interrupts are generated by the CCDC using programmable line counters. The ISP driver programs the CCDC to generate the VD0 interrupt on the last line of the image and the VD1 interrupt at 2/3 of the image. In the mt9p031 sensor, I get all interrupts (including HS_VS_IRQ) and I can capture frames. In other sensor, I can't capture any frame. I get many HS_VS_IRQ only, then yavta app hangs and I need stop it. Then I get CCDC stop timeout! Is it necessary get CCDC_VD0_IRQ and CCDC_VD1_IRQ ever to capture a frame? Yes. A failure to get them usually indicates that the number of lines generated by the sensor doesn't match the number of lines expected by the CCDC (possibly because the HS signal is completely missing). I think all signal from ov5640 sensor are ok. A question about it: vsync may be in high level until the frame is transmitted? On my case I see just a pulse of vsync before hsync pulses. Is it correct? I can capture frames now, and get all interrupts. But, The image has only green color. I solved my problem. The .data_lane_shift and yuv sequence were wrong. Glad to know you've solved the problem :-) I have configured the CCDC module as V4L2_MBUS_FMT_UYVY8_2X8, and the sensor output format is configured as YUV422 with sequence UYVY. somebody has any idea? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Feb 14 19:00:37 CET 2013 git branch: for_v3.9 git hash: ed72d37a33fdf43dc47787fe220532cdec9da528 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On 14.02.2013 20:50, Manu Abraham wrote: On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 08:05 PM, Manu Abraham wrote: On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to break User ABI. https://lkml.org/lkml/2012/12/23/75 Yes, it will change API, that's clear. But the hell, how you will get anything fixed unless you change it? Introduce totally new API every-time when bug is found? You should also understand that changing that single error code on that place will not change all the drivers and there will be still some other error statuses returned by individual drivers. It is about 100% clear that ENOTTY is proper error code for unimplemented IOCTL. I remember maybe more than one discussion about that unimplemented IOCTL error code. It seems to be defined by POSIX [1] standard. It could be. But what I stated is thus: There existed commonality where all unimplemented IOCTL's returned EOPNOTSUPP when the corresponding callback wasn't implemented. So, this was kind of standardized though it was not the ideal thing, though it was not a big issue, it just stated socket additionally. You changed it to ENOTTY to make it fit for the idealistic world. All applications that depended for ages, on those error are now broken. I'm sorry I stirred up this topic again. I wasn't aware that *this* was the reason for https://lkml.org/lkml/2012/12/23/75. As an application developer myself I don't mind if bugs in drivers are fixed, I just wanted to understand the rationale. So now I've learned that bugs in drivers can't be fixed, because some software might rely on the bug. Oh well... In this particular function of VDR I have now changed things to no longer check for any particular not supported errno value, just EINTR. I hope that one is standardized enough... Klaus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp omap3isp: CCDC stop timeout!
Hi Adriano,
(Cc Laurent.)
On Thu, Jan 31, 2013 at 05:40:38PM -0200, Adriano Martins wrote:
Hi all,
I'm trying capture images from an ov5640 sensor on parallel mode. The
sensor output format is UYVY8_2X8.
And the CCDC input is configured as UYVY8_2X8 too. I can do it, after
I applied the Laurent's patches:
[PATCH 0/6] YUV input support for the OMAP3 ISP.
I have my sensor configured:
{
.subdevs = cm-t35_ov5640_primary_subdevs,
.interface = ISP_INTERFACE_PARALLEL,
.bus = {
.parallel = {
.data_lane_shift = 2,
.clk_pol = 0,
.hs_pol = 1,
.vs_pol = 1,
.data_pol = 1,
},
},
I defined ISP_ISR_DEBUG and DEBUG in the isp.c
Then, I configure the media-controller pipeline and try to capture:
media-ctl -v -r -l 'ov5640 3-003c:0-OMAP3 ISP CCDC:0[1]'
media-ctl -v -l 'OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
media-ctl -v -V 'ov5640 3-003c:0 [UYVY2X8 640x480]'
media-ctl -v -V 'OMAP3 ISP CCDC:0 [UYVY2X8 640x480]'
yavta -f UYVY -s 640x480 --capture=5 --file=image# /dev/video2
In this point, it hangs, and I need hit ctrol-c.
I get this message:
[ 1640.308807] omap3isp omap3isp: CCDC stop timeout!
The CCDC needs to receive a complete frames before it can stop.
I have observed that I don't get any interrupt messages. However, the
This suggests that the ISP doesn't receive any data from the sensor. You
should see at least the HS_VS interrupt.
Do you see any ISP interrupts in /proc/interrupts?
DATA0:7, PCLK, HSYNC and VSYNC is working fine, I guess.
NOTE: the sensor has externel 24 MHz oscillator, and the signals never
stop into CCDC:
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/13/2013 09:42 PM, Stephen Warren wrote: On 02/12/2013 03:39 PM, Sylwester Nawrocki wrote: [...] The whole subsystem topology is exposed to user space through the Media Controller API. OK, stable user-visible names are a reasonable use for device tree. I still don't think you should use those user-visible IDs for making any other kind of decision though. OK, I will update the bindings so all variant details are placed in the device tree. Then the routing information would mostly be coming from the device specific dt properties/the common media bindings and the state of links between the media entities, set by the user. It's a bit simpler than that. We would need only to look for the reg property in a local port subnode. MIPI-CSIS correspond to physical MIPI CSI-2 bus interface of an SoC, hence it has to have specific reg values that identify each camera input interface. Oh I see. I guess if a device is using its own node to determine its own identify, that's reasonable. OK, I'm going to post an updated patch series in a week or two. I thought you were talking about a situation like: FIMC -- XXX where FIMC wanted to determine what ID XXX knew that particular FIMC as. Ah, no. Sorry for the poor explanation. FIMC are on a sort if interconnect bus and they can be attached to a single data source, even in parallel, and the data source entity don't even need to be fully aware of it. I can see aliases used in bindings of multiple devices: uart, spi, sound interfaces, gpio, ... And all bindings seem to impose some rules on how their aliases are created. Do you have specific examples? I really don't think the bindings should be dictating the alias values. I just grepped through the existing bindings documentation: ... I think correctly numbered in the above statements means there are some specific rules on how the aliases are created, however those seem not clearly communicated. A binding specifying that an alias must (or even should) exist for each node seems odd to me. In the absence of an explicit rule for how to determine the alias IDs to use, I think the rule would simply be that the aliases must be unique? I guess so. Inspecting of_alias_get_id() call sites tells us that most drivers just fail when alias is not present and only rarely it is not treated as an error condition. And there is a new patch series that allows I2C bus controller enumeration by means of the aliases: http://www.spinics.net/lists/arm-kernel/msg224162.html That's not enumerating controllers by alias (they're still enumerated by scanning the DT nodes for buses in the normal way). The change simply assigns the bus ID of each controller from an alias; exactly what aliases are for. OK, that clarifies a bit my understanding of the aliases. Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DMB-H USB Sticks: MagicPro ProHDTV Mini 2 USB
Hi, frustrated that I couldn't watch the Chinese New Years' Fireworks on TVB Jade using my RTL2832U based DVB-T stick in Hong Kong, I just bought a MagicPro ProHDTV Mini 2 USB stick. Given that HK is now part of China (somehow), they decided to follow the mainland DTV standard, so it's DTMB (DMB-T/H) over here. The package says it only supports Windows, but I never believe the packaging, and I believe in Linux hackers :) lsusb -v says: Bus 001 Device 008: ID 1b80:d39f Afatech This looks *very* similar to the RTL2832U, in fact dmesg says it's a Realtek chip: [58773.739843] usb 1-1.1: new high-speed USB device number 8 using ehci_hcd [58773.835657] usb 1-1.1: New USB device found, idVendor=1b80, idProduct=d39f [58773.835665] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [58773.835670] usb 1-1.1: Product: usbtv [58773.835673] usb 1-1.1: Manufacturer: realtek Full lsusb -v output is attached. I checked here but it's not listed, but other (PCIe) devices from the same manufacturer are: http://linuxtv.org/wiki/index.php/DMB-T/H_PCIe_Cards I'm more than willing to get this thing supported under Linux - just let me know what I can do to help. I have a) the stick b) the Windows driver/software CD (soon as an ISO) What I can provide is a) help getting more info on the hardware (taking it apart etc.) b) provide remote access to a box with the stick plugged in if necessary c) test new code / patches Cheers Alex Bus 001 Device 008: ID 1b80:d39f Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xd39f bcdDevice1.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0
Re: [PATCH v5 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
2013/2/6 Vikas Sajjan vikas.saj...@linaro.org:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
+++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..978e866 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+ if (!fbmode) {
+ DRM_ERROR(memory allocation for fbmode failed\n);
+ return -ENOMEM;
+ }
It doesn't need to allocate fbmode.
+
+ ret = of_get_fb_videomode(dev-of_node, fbmode, -1);
What is -1? use OF_USE_NATIVE_MODE instead including
of_display_timing.h and just change the above code like below,
fbmode = pdata-panel.timing;
ret = of_get_fb_videomode(dev-of_node, fbmode,
OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+ pdata-panel.timing = (struct fb_videomode) *fbmode;
remove the above line.
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi Mr. Inki Dae,
Thanks for review.
On 15 February 2013 08:50, Inki Dae inki@samsung.com wrote:
2013/2/6 Vikas Sajjan vikas.saj...@linaro.org:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
+++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..978e866 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+ if (!fbmode) {
+ DRM_ERROR(memory allocation for fbmode failed\n);
+ return -ENOMEM;
+ }
It doesn't need to allocate fbmode.
+
+ ret = of_get_fb_videomode(dev-of_node, fbmode, -1);
What is -1? use OF_USE_NATIVE_MODE instead including
of_display_timing.h and just change the above code like below,
fbmode = pdata-panel.timing;
ret = of_get_fb_videomode(dev-of_node, fbmode,
OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+ pdata-panel.timing = (struct fb_videomode) *fbmode;
remove the above line.
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed:
devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
Will modify, test and resend V6.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] [media] davinci: do not include mach/hardware.h
Hi Arnd, Thanks for the patch. On Fri, Feb 15, 2013 at 4:17 AM, Arnd Bergmann a...@arndb.de wrote: It is now possible to build the davinci vpss code on multiplatform kernels, which causes a problem since the driver tries to incude the davinci platform specific mach/hardware.h file. Fortunately that file is not required at all in the driver, so we can simply remove the #include statement. Without this patch, building allyesconfig results in: drivers/media/platform/davinci/vpss.c:28:27: fatal error: mach/hardware.h: No such file or directory compilation terminated. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Lad, Prabhakar prabhakar@ti.com Cc: Tony Lindgren t...@atomide.com Acked-by: Lad, Prabhakar prabhakar@ti.com Regards, --Prabhakar --- drivers/media/platform/davinci/vpss.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c index 494d322..a19c552 100644 --- a/drivers/media/platform/davinci/vpss.c +++ b/drivers/media/platform/davinci/vpss.c @@ -25,7 +25,6 @@ #include linux/spinlock.h #include linux/compiler.h #include linux/io.h -#include mach/hardware.h #include media/davinci/vpss.h MODULE_LICENSE(GPL); -- 1.8.1.2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: ths7353: add support for ths7353 video amplifier
Hi Mauro,
Thanks for the review.
On Thu, Feb 14, 2013 at 12:47 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Thu, 7 Feb 2013 11:10:28 +0530
Prabhakar lad prabhakar.cse...@gmail.com escreveu:
From: Lad, Prabhakar prabhakar@ti.com
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Chaithrika U S chaithr...@ti.com
---
Changes for v3:
1: Fixed review comments pointed out by Hans.
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |6 +-
drivers/media/i2c/ths7303.c | 353
---
include/media/ths7303.h | 42 +
include/media/v4l2-chip-ident.h |3 +
4 files changed, 343 insertions(+), 61 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ecdf7e3..bd08541 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -576,10 +576,10 @@ config VIDEO_UPD64083
comment Miscelaneous helper chips
config VIDEO_THS7303
- tristate THS7303 Video Amplifier
- depends on I2C
+ tristate THS7303/53 Video Amplifier
+ depends on VIDEO_V4L2 I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..7300abc 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S chaithr...@ti.com
+ *
+ * Contributors:
+ * Lad, Prabhakar prabhakar@ti.com
+ * Hans Verkuil hans.verk...@cisco.com
+ * Martin Bugge marbu...@cisco.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ctype.h
-#include linux/slab.h
#include linux/i2c.h
-#include linux/device.h
-#include linux/delay.h
#include linux/module.h
-#include linux/uaccess.h
-#include linux/videodev2.h
+#include linux/slab.h
-#include media/v4l2-device.h
-#include media/v4l2-subdev.h
+#include media/ths7303.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
#define THS7303_CHANNEL_11
#define THS7303_CHANNEL_22
#define THS7303_CHANNEL_33
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_datapdata;
+ struct v4l2_bt_timings bt;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,84 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level 0-1);
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = state-pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
[PATCH v6 0/1] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (1): video: drm: exynos: Add display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++ 1 file changed, 33 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37 ++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ fbmode = pdata-panel.timing;
+ ret = of_get_fb_videomode(dev-of_node, fbmode,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode()\n
+ with return value: %d\n, ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default()\n
+ with return value: %d\n, PTR_RET(pctrl));
+ return PTR_RET(pctrl);
+ }
+
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
