Re: [PATCH] media: coda: fix comparision of decoded frames' indexes

2017-11-23 Thread Martin Kepplinger 

Am 22.11.2017 14:43 schrieb Philipp Zabel:

Hi Martin,

On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote:

At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).

Now what is saved in ctx->display_idx is an older value at this point!


Yes. The rotator that copies out the decoded frame runs in parallel 
with

the decoding of the next frame. So the decoder signals with display_idx
which decoded frame should be presented next, but it is only copied out
into the vb2 buffer during the following run. The same happens with the
VDOA, but manually, in prepare_decode.

That means that at this point display_idx is the index of the 
previously

decoded internal frame that should be presented next, and ctx-

display_idx is the index of the internal frame that was just copied

into the externally visible vb2 buffer.

The logic reads someting like this:

if (no frame was decoded) {
if (a frame will be copied out next time) {
adapt sequence number offset;
} else if (no frame was copied out this time) {
hold until further input;
}
}

Basically, it will just wait one more run until it stops the stream,
assuming that there is really nothing useful in the bitstream
ringbuffer.


During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.


display_idx is already checked later in the same function.
According to the i.MX6 VPU API document, it can be -2 (never seen) or 
-3

during sequence start (if there is frame reordering, depending on
whether decoder skip is enabled), and I think I've seen -3 as prescan
failure on i.MX5. -1 means EOS according to that document, that's why 
we

always hold in that case.


ctx->display_idx is updated later in the same function.

Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---

Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!


Maybe it would be less confusing to move this into the display_idx
checks below, given that we already hold unconditionally
on display_idx == -1.


I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.


I think this shouldn't happen at all if you feed it a well formed h.264
stream. But if you have a skip because of broken data while there is
still no display frame at the beginning of the stream or after an IDR,
this might be hit.


Right. Let's leave it this way. In case of real changes, one can think 
about

cleanup.

Thanks for clarification and helping to understand this thing! I 
appreciate it.


 martin

Re: media: coda: sources of coda_regs.h?

2017-11-22 Thread Martin Kepplinger 

Am 22.11.2017 11:40 schrieb Philipp Zabel:

Hi Martin,

On Thu, 2017-11-09 at 23:14 +0100, Martin Kepplinger wrote:

Hi Philipp,

As I'm reading up on the coda driver a little, I can't seem to find 
the
vendor's sources for the coda_regs.h definitions. Could you point me 
to

them?


I don't know for sure what information Javier based the CodaDx6 
register

names on, but I assume that he used the old LGPLed i.MX VPU libraries
that Freescale once distributed. At least that's what I looked at for
the CODA960 additions: The BSP "L3.0.35_12.09.01.01_GA_source.tar.gz"
contained a tarball "pkgs/imx-lib-12.09.01.tar.gz" with a header file
"imx-lib-12.09.01/vpu/vpu_reg.h" inside. I believe the current BSP
versions distributed by NXP do not include this library anymore.


Great! Thanks for the details.

[PATCH] media: coda: fix comparision of decoded frames' indexes

2017-11-17 Thread Martin Kepplinger 
At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).

Now what is saved in ctx->display_idx is an older value at this point!
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.

ctx->display_idx is updated later in the same function.

Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---

Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!

I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.

thanks

   martin


 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index bfc4ecf6f068..fe38527a90e2 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2089,7 +2089,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
/* no frame was decoded, but we might have a display frame */
if (display_idx >= 0 && display_idx < ctx->num_internal_frames)
ctx->sequence_offset++;
-   else if (ctx->display_idx < 0)
+   else if (display_idx < 0)
ctx->hold = true;
} else if (decoded_idx == -2) {
/* no frame was decoded, we still return remaining buffers */
-- 
2.11.0

media: coda: sources of coda_regs.h?

2017-11-09 Thread Martin Kepplinger 
Hi Philipp,

As I'm reading up on the coda driver a little, I can't seem to find the
vendor's sources for the coda_regs.h definitions. Could you point me to
them?

As they don't seem to be in the imx reference manual nor the vpu API
manual, I think it would be worth including a comment about the source
in the header file.

and thanks for this driver. It seems to make the best possible use of
this remaining firmware binary, really :)

   martin

[PATCH] media: coda: remove definition of CODA_STD_MJPG

2017-11-08 Thread Martin Kepplinger 
According to i.MX VPU API Reference Manuals the MJPG video codec is
refernced to by number 7, not 3.

Also Philipp pointed out that this value is only meant to fill in
CMD_ENC_SEQ_COD_STD for encoding, only on i.MX53. It was never written
to any register, and even if defined correctly, wouldn't be needed
for i.MX6.

So avoid confusion and remove this definition.

Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---
 drivers/media/platform/coda/coda_regs.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda_regs.h 
b/drivers/media/platform/coda/coda_regs.h
index 38df5fd9a2fa..35e620c7f1f4 100644
--- a/drivers/media/platform/coda/coda_regs.h
+++ b/drivers/media/platform/coda/coda_regs.h
@@ -254,7 +254,6 @@
 #defineCODA9_STD_H264  0
 #defineCODA_STD_H263   1
 #defineCODA_STD_H264   2
-#defineCODA_STD_MJPG   3
 #defineCODA9_STD_MPEG4 3
 
 #define CODA_CMD_ENC_SEQ_SRC_SIZE  0x190
-- 
2.11.0

[PATCH] media: coda: Fix definition of CODA_STD_MJPG

2017-11-08 Thread Martin Kepplinger 
According to i.MX 6 VPU API Reference Manual Rev. L3.0.35_1.1.0, 01/2013
chapter 3.2.1.5, the MJPG video codec is refernced to by number 7, not 3.
So change this accordingly.

This isn't yet being used right now and therefore probably hasn't been
noticed. Fixing this avoids causing trouble in the future.

Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---
 drivers/media/platform/coda/coda_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda_regs.h 
b/drivers/media/platform/coda/coda_regs.h
index 38df5fd9a2fa..8d726faaf86e 100644
--- a/drivers/media/platform/coda/coda_regs.h
+++ b/drivers/media/platform/coda/coda_regs.h
@@ -254,7 +254,7 @@
 #defineCODA9_STD_H264  0
 #defineCODA_STD_H263   1
 #defineCODA_STD_H264   2
-#defineCODA_STD_MJPG   3
+#defineCODA_STD_MJPG   7
 #defineCODA9_STD_MPEG4 3
 
 #define CODA_CMD_ENC_SEQ_SRC_SIZE  0x190
-- 
2.11.0

Re: platform: coda: how to use firmware-imx binary releases?

2017-10-05 Thread Martin Kepplinger 
On 2017-10-05 17:45, Philipp Zabel wrote:
> On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
>> Hi,
>>
>> Commit
>>
>>  be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
>> and 
>> 3.1.1 as supported
>>
>> says firmware version 3.1.1 revision 46072 is contained in 
>> "firmware-imx-5.4.bin", that's probably
>>
>>  sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-
>> 5.4.bin
>>
>> How do I use this in order to get a VPU firmware blob that the coda 
>> platform driver can work with?
>>
>>
>>
>> (Maybe it'd be worth adding some short documentation on this. There 
>> doesn't seem to be a devicetree bindings doc for coda in 
>> Documentation/devicetree/bindings/media 
> 
> I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
> It was added in commit 657eee7d25fb ("media: coda: use genalloc API").

Right. Not greppable with "coda". If you've also missed it because of
that, it might likely help others when "coda" is mendtioned in it :)

Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?

2017-10-05 Thread Martin Kepplinger 

Am 05.10.2017 16:10 schrieb Nicolas Dufresne:

Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit :

> This message is most likely just a result of the VDOA not supporting
> the
> selected capture format. In vdoa_context_configure, you can see that
> the
> VDOA only writes YUYV or NV12.

ok. I'll have to look into it, and just in case you see a problem on
first sight:
this is what coda says with debug level 1, when doing

gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264
video-sink=fbdevsink


A bit unrelated, but kmssink remains a better choice here.



True, but I'm currently not yet interested in the other end of the pipe 
:) Decoding
works in principal. VDOA is still disabled however :( I don't see what I 
can do
about this right now, which is a bit odd. It is definitely probed (and 
not removed).
I see at least a few frames of the video, so I guess the video file is 
fine? Or could

it be a file (or pixel) format that isn't supported? Again, ffprobe says

Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 
24 tbr, 1200k tbn, 48 tbc


thanks


After this, I want to have video conversion (color space) via a v4l2 
interface that
in turn uses the imx6 IPU. I guess gst-inspect-1.0 should see a V4L2 
Converter,

which it currently doesn't here:

# gst-inspect-1.0 | grep v4l2
video4linux2:  v4l2video1dec: V4L2 Video Decoder
video4linux2:  v4l2deviceprovider (GstDeviceProviderFactory)
video4linux2:  v4l2radio: Radio (video4linux2) Tuner
video4linux2:  v4l2sink: Video (video4linux2) Sink
video4linux2:  v4l2src: Video (video4linux2) Source

# dmesg | grep ipu
[1.394717] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 
0xc07d4b60)
[1.402258] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 
0xc07d4b60)

[1.514984] imx-ipuv3 240.ipu: IPUv3H probed

should imx-ipuv3 provide a video4linux2 interface for video conversion? 
At least I don't
see it yet. (or other V4L2 Linux config options than I already have 
enabled)

Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?

2017-10-05 Thread Martin Kepplinger 

Am 05.10.2017 10:19 schrieb Philipp Zabel:

Hi Martin,

On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote:
I'm running a little off-topic here, but with the newest firmware 
too, 

my
coda driver says "Video Data Order Adapter: Disabled" when started
by video playback via v4l2.


This message is most likely just a result of the VDOA not supporting 
the
selected capture format. In vdoa_context_configure, you can see that 
the

VDOA only writes YUYV or NV12.


ok. I'll have to look into it, and just in case you see a problem on 
first sight:

this is what coda says with debug level 1, when doing

gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 
video-sink=fbdevsink


with the video file being (ffprobe)

Input #0, h264, from 'test2_hd480.h264':
  Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 
fps, 24 tbr, 1200k tbn, 48 tbc



after some s_ctrl: id/val printings:

[   98.833023] coda 204.vpu: Created instance 0 (cefc5000)
[   98.837550] coda 204.vpu: Releasing instance cefc5000
[   98.839080] coda 204.vpu: s_ctrl: id = 9963796, val = 0
[   98.839091] coda 204.vpu: s_ctrl: id = 9963797, val = 0
[   98.839100] coda 204.vpu: Created instance 0 (ceeb2000)
[   98.842867] coda 204.vpu: Releasing instance ceeb2000
[   98.845435] coda 204.vpu: s_ctrl: id = 9963796, val = 0
[   98.845447] coda 204.vpu: s_ctrl: id = 9963797, val = 0
[   98.845458] coda 204.vpu: Created instance 0 (cefc5000)
[   98.851652] coda 204.vpu: Setting format for type 2, wxh: 
852x480, fmt: H264 L
[   98.851670] coda 204.vpu: Setting format for type 1, wxh: 
852x480, fmt: NV12 T

[   98.854800] coda 204.vpu: get 2 buffer(s) of size 819200 each.
[   99.022191] coda 204.vpu: get 2 buffer(s) of size 622080 each.
[   99.025904] coda 204.vpu: Video Data Order Adapter: Disabled
[   99.025922] coda 204.vpu: H264 Profile/Level: High L3
[   99.026214] coda 204.vpu: __coda_start_decoding instance 0 now: 
864x480
[   99.036277] coda 204.vpu: 0: not ready: need 2 buffers available 
(1, 0)

[   99.063157] coda 204.vpu: job ready


so while the video is shown, the VDOA is "disabled".

  thanks a lot for your help


(it's shown far from fluent yet, almost frame by frame, but that's ok 
for now... I'll still need to

took into the v4l2 interface for the imx6 IPU)





(imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
a dev_info "probed" would maybe be useful for others too?)

It supsequently fails with

cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12


That is -ENOMEM. Is CMA enabled and sufficiently large? For example,

CONFIG_CMA=y
CONFIG_CMA_DEBUGFS=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=256
CONFIG_CMA_SIZE_SEL_MBYTES=y



My cma buffer size was indeed just too small.

Re: platform: coda: how to use firmware-imx binary releases?

2017-10-05 Thread Martin Kepplinger 

Am 04.10.2017 11:22 schrieb Philipp Zabel:

Hi Martin,

On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:

Hi,

Commit

 be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 
and 3.1.1 as supported


says firmware version 3.1.1 revision 46072 is contained in 
"firmware-imx-5.4.bin", that's probably

 sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-5.4.bin


Yes.


How do I use this in order to get a VPU firmware blob that the coda 
platform driver can work with?


These are self-extracting shell scripts with an attached compressed tar
archive. This particular file can be extracted by skipping the first
34087 bytes:

dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv



thanks!


(Maybe it'd be worth adding some short documentation on this. There 
doesn't seem to be a devicetree bindings doc for coda in 
Documentation/devicetree/bindings/media which would
be a good place for documenting how to use these binaries too)


Thank you for pointing this out, the device tree binding docs for coda
are indeed missing.
I'm not sure the device tree binding docs are the right place to
document driver and firmware though. For that, adding a coda.rst entry
to Documentation/media/v4l-drivers would probably be a better place.



True. That'd be great. Some firmware-handling and maybe even firmware
version changelogs would definitely be useful.


I'm running a little off-topic here, but with the newest firmware too, 
my

coda driver says "Video Data Order Adapter: Disabled" when started
by video playback via v4l2.

(imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
a dev_info "probed" would maybe be useful for others too?)

It supsequently fails with

cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12

which may or may not be related to having the vdoa (is it?), but 
shouldn't

the VDOA module be active by default?

# cat /sys/module/coda/parameters/disable_vdoa
0

thanks

martin

platform: coda: how to use firmware-imx binary releases?

2017-10-04 Thread Martin Kepplinger 

Hi,

Commit

be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 
3.1.1 as supported


says firmware version 3.1.1 revision 46072 is contained in 
"firmware-imx-5.4.bin", that's probably


sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-5.4.bin

How do I use this in order to get a VPU firmware blob that the coda 
platform driver can work with?




(Maybe it'd be worth adding some short documentation on this. There 
doesn't seem to be a
devicetree bindings doc for coda in 
Documentation/devicetree/bindings/media which would

be a good place for documenting how to use these binaries too)

thanks

   martin

[PATCH] media: dvb-frontends: drx39xyj: remove obsolete sign extend macros

2017-05-03 Thread Martin Kepplinger 
DRX_S9TOS16 and DRX_S24TODRXFREQ are simply not used. Furthermore,
sign_extend32() should be used for sign extension. (Also, the comment
describing DRX_S24TODRXFREQ was wrong). So remove these macros.

Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---
 drivers/media/dvb-frontends/drx39xyj/drx_driver.h | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/media/dvb-frontends/drx39xyj/drx_driver.h 
b/drivers/media/dvb-frontends/drx39xyj/drx_driver.h
index 4442e47..afa702c 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drx_driver.h
+++ b/drivers/media/dvb-frontends/drx39xyj/drx_driver.h
@@ -450,19 +450,6 @@ MACROS
((u8)u16)x)>>8)&0xFF))
 
 /**
-* \brief Macro to sign extend signed 9 bit value to signed  16 bit value
-*/
-#define DRX_S9TOS16(x) u16)x)&0x100) ? ((s16)((u16)(x)|0xFF00)) : (x))
-
-/**
-* \brief Macro to sign extend signed 9 bit value to signed  16 bit value
-*/
-#define DRX_S24TODRXFREQ(x) u32) x) & 0x0080UL) ? \
-((s32) \
-   (((u32) x) | 0xFF00)) : \
-((s32) x))
-
-/**
 * \brief Macro to convert 16 bit register value to a s32
 */
 #define DRX_U16TODRXFREQ(x)   ((x & 0x8000) ? \
-- 
2.1.4

[PATCH v2] media: (stb0899) use sign_extend32() for sign extension

2015-01-25 Thread Martin Kepplinger 
Signed-off-by: Martin Kepplinger mart...@posteo.de
---
Sorry. I should have at least built my change. This is the correct version.


 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..3012f19 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include linux/bitops.h
 #include stb0899_drv.h
 #include stb0899_priv.h
 #include stb0899_reg.h
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq  (1  29))
-   offsetfreq |= -1  30;
+   offsetfreq = sign_extend32(offsetfreq, 29);
 
offsetfreq = offsetfreq / ((1  30) / 1000);
offsetfreq *= (internal-master_clk / 100);
-- 
2.1.4

--
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] media: (stb0899) use sign_extend32() for sign extension

2015-01-25 Thread Martin Kepplinger 
Signed-off-by: Martin Kepplinger mart...@posteo.de
---
 drivers/media/dvb-frontends/stb0899_algo.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 93596e0..7bbcfde 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -19,6 +19,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */
 
+#include linux/bitops.h
 #include stb0899_drv.h
 #include stb0899_priv.h
 #include stb0899_reg.h
@@ -1490,9 +1491,7 @@ enum stb0899_status stb0899_dvbs2_algo(struct 
stb0899_state *state)
/* Store signal parameters  */
offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
 
-   /* sign extend 30 bit value before using it in calculations */
-   if (offsetfreq  (1  29))
-   offsetfreq |= -1  30;
+   offsetfreq = sign_extend32(offset_freq, 29);
 
offsetfreq = offsetfreq / ((1  30) / 1000);
offsetfreq *= (internal-master_clk / 100);
-- 
2.1.4

--
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

[PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-08-04 Thread Martin Kepplinger 
remove dprintk() and replace it with dev_dbg() in order to
use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
Thanks Dan. And since it continues to succeed if (dev == NULL),
differntiate if (dev) or not.

 drivers/staging/media/as102/as102_drv.c |   15 +++---
 drivers/staging/media/as102/as102_drv.h |7 ---
 drivers/staging/media/as102/as102_fe.c  |   73 ---
 drivers/staging/media/as102/as102_usb_drv.c |   41 ---
 4 files changed, 86 insertions(+), 50 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..e0ee618 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -31,10 +31,6 @@
 #include as102_fw.h
 #include dvbdev.h
 
-int as102_debug;
-module_param_named(debug, as102_debug, int, 0644);
-MODULE_PARM_DESC(debug, Turn on/off debugging (default: off));
-
 int dual_tuner;
 module_param_named(dual_tuner, dual_tuner, int, 0644);
 MODULE_PARM_DESC(dual_tuner, Activate Dual-Tuner config (default: off));
@@ -74,7 +70,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
 
if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);
 
mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +109,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
 
if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}
 
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +130,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
 
ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;
diff --git a/drivers/staging/media/as102/as102_drv.h 
b/drivers/staging/media/as102/as102_drv.h
index a06837d..49d0c42 100644
--- a/drivers/staging/media/as102/as102_drv.h
+++ b/drivers/staging/media/as102/as102_drv.h
@@ -27,17 +27,10 @@
 #define DRIVER_FULL_NAME Abilis Systems as10x usb driver
 #define DRIVER_NAME as10x_usb
 
-extern int as102_debug;
 #define debug  as102_debug
 extern struct usb_driver as102_usb_driver;
 extern int elna_enable;
 
-#define dprintk(debug, args...) \
-   do { if (debug) {   \
-   pr_debug(%s: , __func__); \
-   printk(args);   \
-   } } while (0)
-
 #define AS102_DEVICE_MAJOR 192
 
 #define AS102_USB_BUF_SIZE 512
diff --git a/drivers/staging/media/as102/as102_fe.c 
b/drivers/staging/media/as102/as102_fe.c
index b686b76..4c4c47d 100644
--- a/drivers/staging/media/as102/as102_fe.c
+++ b/drivers/staging/media/as102/as102_fe.c
@@ -46,7 +46,8 @@ static int as102_fe_set_frontend(struct dvb_frontend *fe)
/* send abilis command: SET_TUNE */
ret =  as10x_cmd_set_tune(dev-bus_adap, tune_args);
if (ret != 0)
-   dprintk(debug, as10x_cmd_set_tune failed. (err = %d)\n, ret);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_set_tune failed. (err = %d)\n, ret);
 
mutex_unlock(dev-bus_adap.lock);
 
@@ -82,10 +83,17 @@ static int as102_fe_get_tune_settings(struct dvb_frontend 
*fe,
struct dvb_frontend_tune_settings *settings) {
 
 #if 0
-   dprintk(debug, step_size= %d\n, settings-step_size);
-   dprintk(debug, max_drift= %d\n, settings-max_drift);
-   dprintk(debug, min_delay_ms = %d - %d\n, settings-min_delay_ms,
-   1000);
+   struct as102_dev_t *dev;
+
+   dev = (struct as102_dev_t *) fe-tuner_priv;
+   if (dev == NULL)
+   return -EINVAL;
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   step_size= %d\n, settings-step_size);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   max_drift= %d\n, settings-max_drift);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   min_delay_ms = %d - %d\n, settings-min_delay_ms, 1000);
 #endif
 
settings

[PATCHv3] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-08-04 Thread Martin Kepplinger 
remove dprintk() and replace it with dev_dbg() or pr_debug()
in order to use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
Thanks for looking at it. So this doesn't add anything and actually does
what it says. If I haven't understood what you meant, or if I should try
to add struct_device info, I'll look again in a few hours.

 drivers/staging/media/as102/as102_drv.c |   15 +-
 drivers/staging/media/as102/as102_drv.h |7 -
 drivers/staging/media/as102/as102_fe.c  |   25 +++-
 drivers/staging/media/as102/as102_usb_drv.c |   41 ---
 4 files changed, 41 insertions(+), 47 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..e0ee618 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -31,10 +31,6 @@
 #include as102_fw.h
 #include dvbdev.h
 
-int as102_debug;
-module_param_named(debug, as102_debug, int, 0644);
-MODULE_PARM_DESC(debug, Turn on/off debugging (default: off));
-
 int dual_tuner;
 module_param_named(dual_tuner, dual_tuner, int, 0644);
 MODULE_PARM_DESC(dual_tuner, Activate Dual-Tuner config (default: off));
@@ -74,7 +70,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
 
if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);
 
mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +109,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
 
if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}
 
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +130,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
 
ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;
diff --git a/drivers/staging/media/as102/as102_drv.h 
b/drivers/staging/media/as102/as102_drv.h
index a06837d..49d0c42 100644
--- a/drivers/staging/media/as102/as102_drv.h
+++ b/drivers/staging/media/as102/as102_drv.h
@@ -27,17 +27,10 @@
 #define DRIVER_FULL_NAME Abilis Systems as10x usb driver
 #define DRIVER_NAME as10x_usb
 
-extern int as102_debug;
 #define debug  as102_debug
 extern struct usb_driver as102_usb_driver;
 extern int elna_enable;
 
-#define dprintk(debug, args...) \
-   do { if (debug) {   \
-   pr_debug(%s: , __func__); \
-   printk(args);   \
-   } } while (0)
-
 #define AS102_DEVICE_MAJOR 192
 
 #define AS102_USB_BUF_SIZE 512
diff --git a/drivers/staging/media/as102/as102_fe.c 
b/drivers/staging/media/as102/as102_fe.c
index b686b76..67e55b8 100644
--- a/drivers/staging/media/as102/as102_fe.c
+++ b/drivers/staging/media/as102/as102_fe.c
@@ -46,7 +46,8 @@ static int as102_fe_set_frontend(struct dvb_frontend *fe)
/* send abilis command: SET_TUNE */
ret =  as10x_cmd_set_tune(dev-bus_adap, tune_args);
if (ret != 0)
-   dprintk(debug, as10x_cmd_set_tune failed. (err = %d)\n, ret);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_set_tune failed. (err = %d)\n, ret);
 
mutex_unlock(dev-bus_adap.lock);
 
@@ -81,13 +82,6 @@ static int as102_fe_get_frontend(struct dvb_frontend *fe)
 static int as102_fe_get_tune_settings(struct dvb_frontend *fe,
struct dvb_frontend_tune_settings *settings) {
 
-#if 0
-   dprintk(debug, step_size= %d\n, settings-step_size);
-   dprintk(debug, max_drift= %d\n, settings-max_drift);
-   dprintk(debug, min_delay_ms = %d - %d\n, settings-min_delay_ms,
-   1000);
-#endif
-
settings-min_delay_ms = 1000;
 
return 0;
@@ -110,7 +104,8 @@ static int as102_fe_read_status(struct dvb_frontend *fe, 
fe_status_t *status)
/* send abilis command: GET_TUNE_STATUS */
ret = as10x_cmd_get_tune_status(dev-bus_adap, tstate);
if (ret  0

[PATCH] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-08-03 Thread Martin Kepplinger 
remove dprintk() and replace it with dev_dbg() in order to
use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
I don't have the device but this builds.
I think this is ok when it gets reviewed.

applies to -next20140801

 drivers/staging/media/as102/as102_drv.c |   15 +
 drivers/staging/media/as102/as102_drv.h |7 -
 drivers/staging/media/as102/as102_fe.c  |   44 +++
 drivers/staging/media/as102/as102_usb_drv.c |   41 ++---
 4 files changed, 62 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..e0ee618 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -31,10 +31,6 @@
 #include as102_fw.h
 #include dvbdev.h
 
-int as102_debug;
-module_param_named(debug, as102_debug, int, 0644);
-MODULE_PARM_DESC(debug, Turn on/off debugging (default: off));
-
 int dual_tuner;
 module_param_named(dual_tuner, dual_tuner, int, 0644);
 MODULE_PARM_DESC(dual_tuner, Activate Dual-Tuner config (default: off));
@@ -74,7 +70,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
 
if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);
 
mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +109,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
 
if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}
 
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +130,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
 
ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;
diff --git a/drivers/staging/media/as102/as102_drv.h 
b/drivers/staging/media/as102/as102_drv.h
index a06837d..49d0c42 100644
--- a/drivers/staging/media/as102/as102_drv.h
+++ b/drivers/staging/media/as102/as102_drv.h
@@ -27,17 +27,10 @@
 #define DRIVER_FULL_NAME Abilis Systems as10x usb driver
 #define DRIVER_NAME as10x_usb
 
-extern int as102_debug;
 #define debug  as102_debug
 extern struct usb_driver as102_usb_driver;
 extern int elna_enable;
 
-#define dprintk(debug, args...) \
-   do { if (debug) {   \
-   pr_debug(%s: , __func__); \
-   printk(args);   \
-   } } while (0)
-
 #define AS102_DEVICE_MAJOR 192
 
 #define AS102_USB_BUF_SIZE 512
diff --git a/drivers/staging/media/as102/as102_fe.c 
b/drivers/staging/media/as102/as102_fe.c
index b686b76..69ffd51 100644
--- a/drivers/staging/media/as102/as102_fe.c
+++ b/drivers/staging/media/as102/as102_fe.c
@@ -46,7 +46,8 @@ static int as102_fe_set_frontend(struct dvb_frontend *fe)
/* send abilis command: SET_TUNE */
ret =  as10x_cmd_set_tune(dev-bus_adap, tune_args);
if (ret != 0)
-   dprintk(debug, as10x_cmd_set_tune failed. (err = %d)\n, ret);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_set_tune failed. (err = %d)\n, ret);
 
mutex_unlock(dev-bus_adap.lock);
 
@@ -82,10 +83,17 @@ static int as102_fe_get_tune_settings(struct dvb_frontend 
*fe,
struct dvb_frontend_tune_settings *settings) {
 
 #if 0
-   dprintk(debug, step_size= %d\n, settings-step_size);
-   dprintk(debug, max_drift= %d\n, settings-max_drift);
-   dprintk(debug, min_delay_ms = %d - %d\n, settings-min_delay_ms,
-   1000);
+   struct as102_dev_t *dev;
+
+   dev = (struct as102_dev_t *) fe-tuner_priv;
+   if (dev == NULL)
+   return -EINVAL;
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   step_size= %d\n, settings-step_size);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   max_drift= %d\n, settings-max_drift);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   min_delay_ms = %d - %d\n, settings-min_delay_ms, 1000);
 #endif

Re: [BUG] rc1 rc2 rc3 not bootable - black screen after kernel loading

2014-07-24 Thread Martin Kepplinger 
Am 2014-06-30 12:39, schrieb Martin Kepplinger:
 back to aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
 commit. why is this not revertable exactly? how can I show a complete
 list of commits this merge introduces?
 

It seems that _nobody_ is running a simple 32 bit i915 (acer) laptop.
rc6 is still unusable. Black screen directly after kernel-loading. no
change since rc1.

Seems like I won't be able to use 3.16. I'm happy to test patches and am
happy for any advice what to do, when time permits.

 martin
--
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: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

2014-06-30 Thread Martin Kepplinger 
I now booted 3.16-rc3 and suddenly see an oops during boot:

the oops during boot: http://tny.cz/2301e393
also below

lshw if interesting: http://tny.cz/3c9a7609

the full boot log: http://tny.cz/88260b19

does anyone have an idea?
   thanks

the oops:

Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
really_probe: probing driver coretemp with device coretemp.0
Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
kernel NULL pointer dereference at 074c
Jun 30 08:35:08 laptop kernel: [5.246145] IP: [c10325d9]
is_highmem+0x1/0x2b
Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
*pde = 
Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
modprobe Not tainted 3.16.0-rc3 #83
Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
f3e88000 task.ti: f3e88000
Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[c10325d9]
EFLAGS: 00010206 CPU: 1
Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
ffb76000 ECX: 0001 EDX: 03c0
Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
 EBP: f3e89c10 ESP: f3e89c04
Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
074c CR3: 2e3fc000 CR4: 000407f0
Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
f3cbcc60 f3e89c4c f86b52bf 0005  0448
Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
00165000 ffb76000 0113 f870f010 ee881128 ee881128
Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
Jun 30 08:35:08 laptop kernel: [5.246500]  [c1032889] ?
kunmap+0x3b/0x4e
Jun 30 08:35:08 laptop kernel: [5.246578]  [f86b52bf] ?
i915_gem_render_state_init+0x24f/0x28c [i915]
Jun 30 08:35:08 laptop kernel: [5.246634]  [f86b4e5c] ?
i915_switch_context+0x348/0x387 [i915]
Jun 30 08:35:08 laptop kernel: [5.246684]  [f86b4f0f] ?
i915_gem_context_enable+0x74/0x7c [i915]
Jun 30 08:35:08 laptop kernel: [5.246742]  [f86bcd38] ?
i915_gem_init_hw+0x23e/0x285 [i915]
Jun 30 08:35:08 laptop kernel: [5.246818]  [f86bce7e] ?
i915_gem_init+0xff/0x179 [i915]
Jun 30 08:35:08 laptop kernel: [5.246924]  [f87047d9] ?
i915_driver_load+0x989/0xc1d [i915]
Jun 30 08:35:08 laptop kernel: [5.246940]  [c1267429] ?
get_device+0x14/0x1d
Jun 30 08:35:08 laptop kernel: [5.246955]  [c1268832] ?
device_add+0x3b7/0x4a9
Jun 30 08:35:08 laptop kernel: [5.246996]  [f8619c80] ?
drm_minor_register+0x104/0x15c [drm]
Jun 30 08:35:08 laptop kernel: [5.247033]  [f8619d44] ?
drm_dev_register+0x6c/0xce [drm]
Jun 30 08:35:08 laptop kernel: [5.247072]  [f861bbb4] ?
drm_get_pci_dev+0xde/0x174 [drm]
Jun 30 08:35:08 laptop kernel: [5.247088]  [c11dcc58] ?
local_pci_probe+0x33/0x6c
Jun 30 08:35:08 laptop kernel: [5.247101]  [c11dcd39] ?
pci_device_probe+0xa8/0xca
Jun 30 08:35:08 laptop kernel: [5.247115]  [c126a75a] ?
driver_probe_device+0xd3/0x225
Jun 30 08:35:08 laptop kernel: [5.247128]  [c126a8f8] ?
__driver_attach+0x4c/0x68
Jun 30 08:35:08 laptop kernel: [5.247141]  [c1269260] ?
bus_for_each_dev+0x41/0x6b
Jun 30 08:35:08 laptop kernel: [5.247155]  [c126a26c] ?
driver_attach+0x19/0x1b
Jun 30 08:35:08 laptop kernel: [5.247166]  [c126a8ac] ?
driver_probe_device+0x225/0x225
Jun 30 08:35:08 laptop kernel: [5.247176]  [c126a027] ?
bus_add_driver+0xcf/0x192
Jun 30 08:35:08 laptop kernel: [5.247184]  [c126ae69] ?
driver_register+0x73/0xa5
Jun 30 08:35:08 laptop kernel: [5.247193]  [f85ee000] ? 0xf85edfff
Jun 30 08:35:08 laptop kernel: [5.247200]  [c100045e] ?
do_one_initcall+0xe0/0x17a
Jun 30 08:35:08 laptop kernel: [5.247209]  [c10fadf8] ?
__cache_free+0x369/0x371
Jun 30 08:35:08 laptop kernel: [5.247216]  [c10fadf8] ?

Re: [BUG] rc3 Oops: unable to handle kernel NULL pointer dereference at 0000074c

2014-06-30 Thread Martin Kepplinger 
Am 2014-06-30 10:20, schrieb Zhang Rui:
 On Mon, 2014-06-30 at 16:18 +0800, Zhang Rui wrote:
 On Mon, 2014-06-30 at 09:52 +0200, Martin Kepplinger wrote:
 I now booted 3.16-rc3 and suddenly see an oops during boot:

 the oops during boot: http://tny.cz/2301e393
 also below

 lshw if interesting: http://tny.cz/3c9a7609

 the full boot log: http://tny.cz/88260b19

 does anyone have an idea?

 what if you rebuild the kernel with CONFIG_SENSORS_CORETEMP=n?

 BTW, can this be 100% reproduced on a rc3 kernel?

no I can't -.- Booted again a few times, no oops now. just the black
screen as 'usual' for 3.16.

 
 thanks,
 rui
 thanks,
 rui
thanks

 the oops:

 Jun 30 08:35:08 laptop kernel: [5.245811] bus: 'platform':
 really_probe: probing driver coretemp with device coretemp.0
 Jun 30 08:35:08 laptop kernel: [5.246134] BUG: unable to handle
 kernel NULL pointer dereference at 074c
 Jun 30 08:35:08 laptop kernel: [5.246145] IP: [c10325d9]
 is_highmem+0x1/0x2b
 Jun 30 08:35:08 laptop kernel: [5.246158] *pdpt = 33e49001
 *pde = 
 Jun 30 08:35:08 laptop kernel: [5.246167] Oops:  [#1] SMP
 Jun 30 08:35:08 laptop kernel: [5.246175] Modules linked in:
 coretemp(+) kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek
 snd_hda_codec_generic microcode snd_hda_intel i915(+) snd_hda_controller
 evdev psmouse snd_hda_codec serio_raw snd_hwdep snd_pcm iwlwifi i2c_i801
 lpc_ich mfd_core snd_seq drm_kms_helper snd_timer battery ehci_pci
 snd_seq_device drm cfg80211 ehci_hcd snd i2c_algo_bit ac video i2c_core
 rfkill soundcore wmi acpi_cpufreq button processor thermal_sys ext4
 crc16 jbd2 mbcache sg sd_mod crct10dif_generic crc_t10dif
 crct10dif_common ahci libahci crc32c_intel tg3 ptp libata pps_core
 sdhci_pci sdhci scsi_mod mmc_core libphy xhci_hcd usbcore usb_common
 Jun 30 08:35:08 laptop kernel: [5.246320] CPU: 1 PID: 491 Comm:
 modprobe Not tainted 3.16.0-rc3 #83
 Jun 30 08:35:08 laptop kernel: [5.246330] Hardware name: Acer
 TravelMate B113/BA10_HX   , BIOS V1.09 10/30/2012
 Jun 30 08:35:08 laptop kernel: [5.246344] task: f3828a90 ti:
 f3e88000 task.ti: f3e88000
 Jun 30 08:35:08 laptop kernel: [5.246355] EIP: 0060:[c10325d9]
 EFLAGS: 00010206 CPU: 1
 Jun 30 08:35:08 laptop kernel: [5.246367] EIP is at is_highmem+0x1/0x2b
 Jun 30 08:35:08 laptop kernel: [5.246376] EAX: 03c0 EBX:
 ffb76000 ECX: 0001 EDX: 03c0
 Jun 30 08:35:08 laptop kernel: [5.246386] ESI: f86cd279 EDI:
  EBP: f3e89c10 ESP: f3e89c04
 Jun 30 08:35:08 laptop kernel: [5.246396]  DS: 007b ES: 007b FS:
 00d8 GS: 00e0 SS: 0068
 Jun 30 08:35:08 laptop kernel: [5.246405] CR0: 80050033 CR2:
 074c CR3: 2e3fc000 CR4: 000407f0
 Jun 30 08:35:08 laptop kernel: [5.246414] Stack:
 Jun 30 08:35:08 laptop kernel: [5.246421]  f3e89c10 c1032889
 f3cbcc60 f3e89c4c f86b52bf 0005  0448
 Jun 30 08:35:08 laptop kernel: [5.246442]  f3e89c30 0006
 00165000 ffb76000 0113 f870f010 ee881128 ee881128
 Jun 30 08:35:08 laptop kernel: [5.246465]  0001 f418b980
 f3e89c74 f86b4e5c  f3911e00 f3911e00 ee881128
 Jun 30 08:35:08 laptop kernel: [5.246487] Call Trace:
 Jun 30 08:35:08 laptop kernel: [5.246500]  [c1032889] ?
 kunmap+0x3b/0x4e
 Jun 30 08:35:08 laptop kernel: [5.246578]  [f86b52bf] ?
 i915_gem_render_state_init+0x24f/0x28c [i915]
 Jun 30 08:35:08 laptop kernel: [5.246634]  [f86b4e5c] ?
 i915_switch_context+0x348/0x387 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246684]  [f86b4f0f] ?
 i915_gem_context_enable+0x74/0x7c [i915]
 Jun 30 08:35:08 laptop kernel: [5.246742]  [f86bcd38] ?
 i915_gem_init_hw+0x23e/0x285 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246818]  [f86bce7e] ?
 i915_gem_init+0xff/0x179 [i915]
 Jun 30 08:35:08 laptop kernel: [5.246924]  [f87047d9] ?
 i915_driver_load+0x989/0xc1d [i915]
 Jun 30 08:35:08 laptop kernel: [5.246940]  [c1267429] ?
 get_device+0x14/0x1d
 Jun 30 08:35:08 laptop kernel: [5.246955]  [c1268832] ?
 device_add+0x3b7/0x4a9
 Jun 30 08:35:08 laptop kernel: [5.246996]  [f8619c80] ?
 drm_minor_register+0x104/0x15c [drm]
 Jun 30 08:35:08 laptop kernel: [5.247033]  [f8619d44] ?
 drm_dev_register+0x6c/0xce [drm]
 Jun 30 08:35:08 laptop kernel: [5.247072]  [f861bbb4] ?
 drm_get_pci_dev+0xde/0x174 [drm]
 Jun 30 08:35:08 laptop kernel: [5.247088]  [c11dcc58] ?
 local_pci_probe+0x33/0x6c
 Jun 30 08:35:08 laptop kernel: [5.247101]  [c11dcd39] ?
 pci_device_probe+0xa8/0xca
 Jun 30 08:35:08 laptop kernel: [5.247115]  [c126a75a] ?
 driver_probe_device+0xd3/0x225
 Jun 30 08:35:08 laptop kernel: [5.247128]  [c126a8f8] ?
 __driver_attach+0x4c/0x68
 Jun 30 08:35:08 laptop kernel: [5.247141]  [c1269260] ?
 bus_for_each_dev+0x41/0x6b
 Jun 30 08:35:08 laptop kernel: [5.247155]  [c126a26c] ?
 driver_attach+0x19/0x1b
 Jun 30 08:35:08 laptop kernel: [5.247166]  [c126a8ac] ?
 driver_probe_device

Re: [BUG] rc1 rc2 rc3 not bootable - black screen after kernel loading

2014-06-30 Thread Martin Kepplinger 
back to aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
commit. why is this not revertable exactly? how can I show a complete
list of commits this merge introduces?
--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

2014-06-27 Thread Martin Kepplinger 
Am 2014-06-27 17:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 16:46 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 15:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 03:10, schrieb Zhang, Rui:


 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-ker...@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High

 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.

 This looks like a duplicate of
 https://bugzilla.kernel.org/show_bug.cgi?id=78601

 thanks,
 rui
 I'm not sure about that. I have no problem with v3.15 and the screen
 goes black way before a display manager is started. It's right after the
 kernel loaded and usually the screen is set to native resolution.

 Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
 one. Although, checking that out and running it, works good. not sure if
 that makes sense.

 could you please check if the comment in
 https://bugzilla.kernel.org/show_bug.cgi?id=78601#c5 solves your problem
 or not?
 
 thanks,
 rui

thanks for checking. This does not change anything though. I tested the
following on top of v3.16-rc2 and linus's tree as of today, almost -rc3.

---
 drivers/gpu/drm/i915/intel_fbdev.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 088fe93..1e2f9ae 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -453,7 +453,6 @@ out:
 }

 static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
-   .initial_config = intel_fb_initial_config,
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
-- 
1.7.10.4



 Do you have other people complain about that? Bisecting didn't lead to
 a good result. I could be wrong but I somehow suspect the mistake to be
 somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85

 In order to confirm if the problem is introduced by the above commit,
 why not checkout the kernel just before and after this commit and see if 
 the problem exists?

 Thanks,
 rui

 So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
 good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
 This is a big v4l merge. I added the linux-media list in cc now.

 What could be the problem here?


 There is nothing unusual in the kernel log.

 This is quite unusual for an -rc2. Hence my question. I'm happy to test
 changes.

  martin
 --
 Martin Kepplinger
 e-mailmartink AT posteo DOT at
 chat (XMPP)   martink AT jabber DOT at




 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

2014-06-27 Thread Martin Kepplinger 
Am 2014-06-27 20:09, schrieb Martin Kepplinger:
 Am 2014-06-27 17:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 16:46 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 15:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 03:10, schrieb Zhang, Rui:


 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-ker...@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High

 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.

 This looks like a duplicate of
 https://bugzilla.kernel.org/show_bug.cgi?id=78601

 thanks,
 rui
 I'm not sure about that. I have no problem with v3.15 and the screen
 goes black way before a display manager is started. It's right after the
 kernel loaded and usually the screen is set to native resolution.

 Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
 one. Although, checking that out and running it, works good. not sure if
 that makes sense.

 could you please check if the comment in
 https://bugzilla.kernel.org/show_bug.cgi?id=78601#c5 solves your problem
 or not?

 thanks,
 rui
 
 thanks for checking. This does not change anything though. I tested the
 following on top of v3.16-rc2 and linus's tree as of today, almost -rc3.
 
 ---
  drivers/gpu/drm/i915/intel_fbdev.c |1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
 b/drivers/gpu/drm/i915/intel_fbdev.c
 index 088fe93..1e2f9ae 100644
 --- a/drivers/gpu/drm/i915/intel_fbdev.c
 +++ b/drivers/gpu/drm/i915/intel_fbdev.c
 @@ -453,7 +453,6 @@ out:
  }
 
  static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
 -   .initial_config = intel_fb_initial_config,
 .gamma_set = intel_crtc_fb_gamma_set,
 .gamma_get = intel_crtc_fb_gamma_get,
 .fb_probe = intelfb_create,
 

I also tested the following patch from
http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html
now, with no results. No change in my case :(

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index efd3cf5..5aee08e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11087,6 +11087,22 @@ const char *intel_output_name(int output)
return names[output];
 }

+static bool intel_crt_present(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   if (IS_ULT(dev))
+   return false;
+
+   if (IS_CHERRYVIEW(dev))
+   return false;
+
+   if (IS_VALLEYVIEW(dev)  !dev_priv-vbt.int_crt_support)
+   return false;
+
+   return true;
+}
+
 static void intel_setup_outputs(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -11095,7 +1,7 @@ static void intel_setup_outputs(struct
drm_device *dev)

intel_lvds_init(dev);

-   if (!IS_ULT(dev)  !IS_CHERRYVIEW(dev) 
dev_priv-vbt.int_crt_support)
+   if (intel_crt_present(dev))
intel_crt_init(dev);

if (HAS_DDI(dev)) {
-- 
1.7.10.4
--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

2014-06-27 Thread Martin Kepplinger 
Am 2014-06-27 21:51, schrieb Martin Kepplinger:
 Am 2014-06-27 20:09, schrieb Martin Kepplinger:
 Am 2014-06-27 17:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 16:46 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 15:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 03:10, schrieb Zhang, Rui:


 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-ker...@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High

 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.

 This looks like a duplicate of
 https://bugzilla.kernel.org/show_bug.cgi?id=78601

 thanks,
 rui
 I'm not sure about that. I have no problem with v3.15 and the screen
 goes black way before a display manager is started. It's right after the
 kernel loaded and usually the screen is set to native resolution.

 Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
 one. Although, checking that out and running it, works good. not sure if
 that makes sense.

 could you please check if the comment in
 https://bugzilla.kernel.org/show_bug.cgi?id=78601#c5 solves your problem
 or not?

 thanks,
 rui

 thanks for checking. This does not change anything though. I tested the
 following on top of v3.16-rc2 and linus's tree as of today, almost -rc3.

 ---
  drivers/gpu/drm/i915/intel_fbdev.c |1 -
  1 file changed, 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
 b/drivers/gpu/drm/i915/intel_fbdev.c
 index 088fe93..1e2f9ae 100644
 --- a/drivers/gpu/drm/i915/intel_fbdev.c
 +++ b/drivers/gpu/drm/i915/intel_fbdev.c
 @@ -453,7 +453,6 @@ out:
  }

  static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
 -   .initial_config = intel_fb_initial_config,
 .gamma_set = intel_crtc_fb_gamma_set,
 .gamma_get = intel_crtc_fb_gamma_get,
 .fb_probe = intelfb_create,

 
 I also tested the following patch from
 http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html
 now, with no results. No change in my case :(
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index efd3cf5..5aee08e 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -11087,6 +11087,22 @@ const char *intel_output_name(int output)
 return names[output];
  }
 
 +static bool intel_crt_present(struct drm_device *dev)
 +{
 +   struct drm_i915_private *dev_priv = dev-dev_private;
 +
 +   if (IS_ULT(dev))
 +   return false;
 +
 +   if (IS_CHERRYVIEW(dev))
 +   return false;
 +
 +   if (IS_VALLEYVIEW(dev)  !dev_priv-vbt.int_crt_support)
 +   return false;
 +
 +   return true;
 +}
 +
  static void intel_setup_outputs(struct drm_device *dev)
  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 @@ -11095,7 +1,7 @@ static void intel_setup_outputs(struct
 drm_device *dev)
 
 intel_lvds_init(dev);
 
 -   if (!IS_ULT(dev)  !IS_CHERRYVIEW(dev) 
 dev_priv-vbt.int_crt_support)
 +   if (intel_crt_present(dev))
 intel_crt_init(dev);
 
 if (HAS_DDI(dev)) {
 
I'm on i686 and also the following from
https://bugzilla.redhat.com/show_bug.cgi?id=1110968#c16 does not help :(
this is bad.

---
 arch/x86/kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/signal.c  
+++ a/arch/x86/kernel/signal.c  
@@ -363,7 +363,7 @@ static int __setup_rt_frame(int sig, struct ksignal
*ksig,

/* Set up to return from userspace.  */
restorer = current-mm-context.vdso +
-   selected_vdso32-sym___kernel_sigreturn;
+   selected_vdso32-sym___kernel_rt_sigreturn;
if (ksig-ka.sa.sa_flags  SA_RESTORER)
restorer = ksig-ka.sa.sa_restorer;
put_user_ex(restorer, frame-pretcode);
-- 
--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

2014-06-23 Thread Martin Kepplinger 
Am 2014-06-23 03:10, schrieb Zhang, Rui:
 
 
 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-ker...@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High

 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.

 Do you have other people complain about that? Bisecting didn't lead to
 a good result. I could be wrong but I somehow suspect the mistake to be
 somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85

 In order to confirm if the problem is introduced by the above commit,
 why not checkout the kernel just before and after this commit and see if the 
 problem exists?
 
 Thanks,
 rui
 
So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
This is a big v4l merge. I added the linux-media list in cc now.

What could be the problem here?

 
 There is nothing unusual in the kernel log.

 This is quite unusual for an -rc2. Hence my question. I'm happy to test
 changes.

  martin
 --
 Martin Kepplinger
 e-mailmartink AT posteo DOT at
 chat (XMPP)   martink AT jabber DOT at

--
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: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black instead of native resolution

2014-06-23 Thread Martin Kepplinger 
Am 2014-06-23 15:14, schrieb Zhang Rui:
 On Mon, 2014-06-23 at 14:22 +0200, Martin Kepplinger wrote:
 Am 2014-06-23 03:10, schrieb Zhang, Rui:


 -Original Message-
 From: Martin Kepplinger [mailto:mart...@posteo.de]
 Sent: Sunday, June 22, 2014 10:25 PM
 To: Zhang, Rui
 Cc: r...@rjwysocki.net; l...@kernel.org; linux-a...@vger.kernel.org;
 linux-ker...@vger.kernel.org
 Subject: [BUG] rc1 and rc2: Laptop unusable: on boot,screen black
 instead of native resolution
 Importance: High

 Since 3.16-rc1 my laptop's just goes black while booting, instead of
 switching to native screen resolution and showing me the starting
 system there. It's an Acer TravelMate B113 with i915 driver and
 acer_wmi. It stays black and is unusable.

 This looks like a duplicate of
 https://bugzilla.kernel.org/show_bug.cgi?id=78601
 
 thanks,
 rui
I'm not sure about that. I have no problem with v3.15 and the screen
goes black way before a display manager is started. It's right after the
kernel loaded and usually the screen is set to native resolution.

Bisect told me aaeb2554337217dfa4eac2fcc90da7be540b9a73 as the first bad
one. Although, checking that out and running it, works good. not sure if
that makes sense.

 Do you have other people complain about that? Bisecting didn't lead to
 a good result. I could be wrong but I somehow suspect the mistake to be
 somewhere in commit 99678ed73a50d2df8b5f3c801e29e9b7a3e5aa85

 In order to confirm if the problem is introduced by the above commit,
 why not checkout the kernel just before and after this commit and see if 
 the problem exists?

 Thanks,
 rui

 So maybe I was wrong. d27050641e9bc056446deb0814e7ba1aa7911f5a is still
 good and aaeb2554337217dfa4eac2fcc90da7be540b9a73 is the fist bad one.
 This is a big v4l merge. I added the linux-media list in cc now.

 What could be the problem here?


 There is nothing unusual in the kernel log.

 This is quite unusual for an -rc2. Hence my question. I'm happy to test
 changes.

  martin
 --
 Martin Kepplinger
 e-mailmartink AT posteo DOT at
 chat (XMPP)   martink AT jabber DOT at

 
 

--
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] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-05-17 Thread Martin Kepplinger 
don't reinvent dev_dbg(). use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
this applies to next-20140516.

 drivers/staging/media/as102/as102_drv.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..99c3ed93 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -74,7 +74,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
 
if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);
 
mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +113,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
 
if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}
 
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +134,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
 
ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;
-- 
1.7.10.4

--
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

[PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-05-17 Thread Martin Kepplinger 
don't reinvent dev_dbg(). remove dprintk() in as102_drv.c.
use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
this applies to next-20140516. any more suggestions?
more cleanup can be done when dprintk() is completely gone.

 drivers/staging/media/as102/as102_drv.c |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..e0ee618 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -31,10 +31,6 @@
 #include as102_fw.h
 #include dvbdev.h
 
-int as102_debug;
-module_param_named(debug, as102_debug, int, 0644);
-MODULE_PARM_DESC(debug, Turn on/off debugging (default: off));
-
 int dual_tuner;
 module_param_named(dual_tuner, dual_tuner, int, 0644);
 MODULE_PARM_DESC(dual_tuner, Activate Dual-Tuner config (default: off));
@@ -74,7 +70,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;
 
if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);
 
mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +109,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;
 
if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}
 
switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +130,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;
 
ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;
-- 
1.7.10.4

--
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: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()

2014-05-17 Thread Martin Kepplinger 
Am 2014-05-17 19:21, schrieb Antti Palosaari:
 On 05/17/2014 07:05 PM, Martin Kepplinger wrote:
 don't reinvent dev_dbg(). remove dprintk() in as102_drv.c.
 use the common kernel coding style.

 Signed-off-by: Martin Kepplinger mart...@posteo.de
 
 Reviewed-by: Antti Palosaari cr...@iki.fi
 
 ---
 this applies to next-20140516. any more suggestions?
 more cleanup can be done when dprintk() is completely gone.
 
 Do you have the device? I am a bit reluctant patching that driver
 without any testing as it has happened too many times something has gone
 totally broken.
I don't have the device and will, at most, change such style issues.

 
 IIRC Devin said it is in staging because of style issues and nothing
 more. Is that correct?
I haven't heard anything. A TODO file would help.

 
 regards
 Antti
 

--
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