[PATCH 10/21] media: dvb_core: slight optimization of addr compare
Use the recently added and possibly more efficient
ether_addr_equal_unaligned to instead of memcmp.
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Yang Yingliang
Signed-off-by: Ding Tianhong
---
drivers/media/dvb-core/dvb_net.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index f91c80c..ff00f97 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -179,7 +179,7 @@ static __be16 dvb_net_eth_type_trans(struct sk_buff *skb,
eth = eth_hdr(skb);
if (*eth->h_dest & 1) {
- if(memcmp(eth->h_dest,dev->broadcast, ETH_ALEN)==0)
+ if(ether_addr_equal_unaligned(eth->h_dest, dev->broadcast))
skb->pkt_type=PACKET_BROADCAST;
else
skb->pkt_type=PACKET_MULTICAST;
@@ -674,11 +674,11 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
if (priv->rx_mode != RX_MODE_PROMISC) {
if (priv->ule_skb->data[0] &
0x01) {
/* multicast or
broadcast */
- if
(memcmp(priv->ule_skb->data, bc_addr, ETH_ALEN)) {
+ if
(!ether_addr_equal_unaligned(priv->ule_skb->data, bc_addr)) {
/* multicast */
if
(priv->rx_mode == RX_MODE_MULTI) {
int i;
- for(i =
0; i < priv->multi_num && memcmp(priv->ule_skb->data, priv->multi_macs[i],
ETH_ALEN); i++)
+ for(i =
0; i < priv->multi_num && !ether_addr_equal_unaligned(priv->ule_skb->data,
priv->multi_macs[i]); i++)
;
if (i
== priv->multi_num)
drop = 1;
@@ -688,7 +688,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
}
/* else: broadcast */
}
- else if
(memcmp(priv->ule_skb->data, dev->dev_addr, ETH_ALEN))
+ else if
(!ether_addr_equal_unaligned(priv->ule_skb->data, dev->dev_addr))
drop = 1;
/* else: destination address
matches the MAC address of our receiver device */
}
@@ -837,7 +837,7 @@ static void dvb_net_sec(struct net_device *dev,
}
if (pkt[5] & 0x02) {
/* handle LLC/SNAP, see rfc-1042 */
- if (pkt_len < 24 || memcmp(&pkt[12], "\xaa\xaa\x03\0\0\0", 6)) {
+ if (pkt_len < 24 || !ether_addr_equal_unaligned(&pkt[12],
"\xaa\xaa\x03\0\0\0")) {
stats->rx_dropped++;
return;
}
--
1.8.0
--
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: Mon Dec 23 04:00:20 CET 2013 git branch: test git hash: c57f87e62368c33ebda11a4993380c8e5a19a5c5 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: ERRORS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK 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: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK 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-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-rc1-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: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK 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-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
[PATCH] V4L: s5k6a3: Add DT binding documentation
This patch adds DT binding documentation for the Samsung S5K6A3(YX) raw image sensor. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- This patch adds missing documentation [1] for the "samsung,s5k6a3" compatible. Rob, can you please merge it through your tree if it looks OK ? Thanks, Sylwester [1] http://www.spinics.net/lists/devicetree/msg10693.html Changes since v3 (https://linuxtv.org/patch/20429): - rephrased 'clocks' and 'clock-names' properties' description. --- .../devicetree/bindings/media/samsung-s5k6a3.txt | 33 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/samsung-s5k6a3.txt diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt new file mode 100644 index 000..cce01e8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt @@ -0,0 +1,33 @@ +Samsung S5K6A3(YX) raw image sensor +- + +S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces +and CCI (I2C compatible) control bus. + +Required properties: + +- compatible : "samsung,s5k6a3"; +- reg : I2C slave address of the sensor; +- svdda-supply : core voltage supply; +- svddio-supply: I/O voltage supply; +- afvdd-supply : AF (actuator) voltage supply; +- gpios: specifier of a GPIO connected to the RESET pin; +- clocks : should contain list of phandle and clock specifier pairs + according to common clock bindings for the clocks described + in the clock-names property; +- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock; + +Optional properties: + +- clock-frequency : the frequency at which the "extclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be +used to specify link to the image data receiver. The S5K6A3(YX) device +node should contain one 'port' child node with an 'endpoint' subnode. + +Following properties are valid for the endpoint node: + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. The sensor supports only one data lane. -- 1.7.4.1 -- 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 RFC] v4l: disable lockdep on vb2_fop_mmap()
Avoid that lockdep warning:
[ INFO: possible circular locking dependency detected ]
3.13.0-rc1+ #77 Tainted: G C O
---
video_source:sr/32072 is trying to acquire lock:
(&dev->mutex#2){+.+.+.}, at: [] vb2_fop_mmap+0x33/0x90
[videobuf2_core]
but task is already holding
lock:
(&mm->mmap_sem){++}, at: [] vm_mmap_pgoff+0x6f/0xc0
Possible unsafe locking scenario:
CPU0CPU1
lock(&mm->mmap_sem);
lock(&dev->mutex#2);
lock(&mm->mmap_sem);
lock(&dev->mutex#2);
*** DEADLOCK ***
Signed-off-by: Antti Palosaari
---
drivers/media/v4l2-core/videobuf2-core.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 12df9fd..2a74295 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2641,12 +2641,24 @@ int vb2_fop_mmap(struct file *file, struct
vm_area_struct *vma)
struct video_device *vdev = video_devdata(file);
struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock;
int err;
+ /*
+* FIXME: Ugly hack. Disable possible lockdep as it detects possible
+* deadlock. "INFO: possible circular locking dependency detected"
+*/
+ lockdep_off();
- if (lock && mutex_lock_interruptible(lock))
+ if (lock && mutex_lock_interruptible(lock)) {
+ lockdep_on();
return -ERESTARTSYS;
+ }
+
err = vb2_mmap(vdev->queue, vma);
+
if (lock)
mutex_unlock(lock);
+
+ lockdep_on();
+
return err;
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
--
1.8.4.2
--
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 RFC] v4l lockdep error
I know that patch is a little bit stupid, but at least it seems to kill that "INFO: possible circular locking dependency detected" / DEADLOCK warning reported by lockdep. Somehow this kind of warnings are very annoying when you don't know it is a "feature". Like what happens to me; I made my first V4L2 driver and then enabled all kind of Kernel debugs to see if there is possible issues. And kaboom, that jumped to out. It took really a some time to figure it is not my module, but coming from v4l core layers. Antti Palosaari (1): v4l: disable lockdep on vb2_fop_mmap() drivers/media/v4l2-core/videobuf2-core.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) -- 1.8.4.2 -- 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: em28xx DEADLOCK reported by lock debug
Am 22.12.2013 19:14, schrieb Antti Palosaari: > On 22.12.2013 20:02, Frank Schäfer wrote: >> Am 22.12.2013 15:34, schrieb Antti Palosaari: >>> On 22.12.2013 15:51, Frank Schäfer wrote: Am 21.12.2013 20:55, schrieb Antti Palosaari: > On 21.12.2013 18:51, Frank Schäfer wrote: >> Hi Antti, >> >> thank you for reporting this issue. >> >> Am 18.12.2013 17:04, schrieb Antti Palosaari: >>> That same lock debug deadlock is still there (maybe ~4 times I >>> report >>> it during 2 years). Is that possible to fix easily at all? >> >> Patches are always welcome. ;) > > haha, I cannot simply learn every driver I meet some problems... Hint: If you report a bug ~4 times in 2 years but never get a reply, it usually means a) nobody cares b) nobody has the resources (time, knowledge) to fix it. So you either have to live with this issue or to fix it yourself. >>> >>> OK, as you request me to fix it, I will fix that by making DVB USB v2 >>> driver for these em28xx devices I have added. >>> >>> It should not be very much work as em28xx protocol is still relatively >>> easy. >> How would that help to get those lockdep false warnings fixed ? >> Btw: these warnings should appear for _all_ em28xx extensions (dvb, >> input, audio). > > I am already looking to silence that v4l2 lockdep report. It is hard > to say how much it is work as I simply don't know even reasons. > > I suspect that if I start learning and fixing em28xx driver it will > take week or two as a workload. Writing new dvb-usb driver is only max > 2 days of work and as a bonus you will get some missing features for > free: > 1) power-management > 2) suspend/resume > 3) PID filters Sure, but we already have a driver for these devices. I agree with you that em28xx is a big mess, but at least in this case it doesn't do anything wrong. Does this false warning really make you so nervous that you're willing to spent 2 days for it ? I appreciate that, but I suggest to spend these 2 days for fixing the issue instead of just avoiding it. Regards, Frank > > 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
Re: [PATCH] em28xx: fix I2S audio sample rate definitions and info output
Am 22.12.2013 17:09, schrieb Mauro Carvalho Chehab:
> Em Sun, 22 Dec 2013 15:17:46 +0100
> Frank Schäfer escreveu:
>
>> The audio configuration in chip config register 0x00 and eeprom are always
>> consistent. But currently the audio configuration #defines for the chip
>> config
>> register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the
>> eeprom
>> info output says 0x20 means 1 sample rate and 0x30 3 sample rates.
>>
>> I've checked the datasheet excerpts I have and it seems that the meaning of
>> these bits is different for em2820/40 (1 and 3 sample rates) and em2860+
>> (3 and 5 smaple rates).
>> I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom
>> audio config 0x20 matches the sample rates reproted by the USB device
>> descriptor (32k only).
>>
>> Signed-off-by: Frank Schäfer
>> ---
>> drivers/media/usb/em28xx/em28xx-core.c | 24 +---
>> drivers/media/usb/em28xx/em28xx-i2c.c | 10 --
>> drivers/media/usb/em28xx/em28xx-reg.h | 10 ++
>> drivers/media/usb/em28xx/em28xx.h |3 +--
>> 4 Dateien geändert, 28 Zeilen hinzugefügt(+), 19 Zeilen entfernt(-)
>>
>> diff --git a/drivers/media/usb/em28xx/em28xx-core.c
>> b/drivers/media/usb/em28xx/em28xx-core.c
>> index f6076a5..192b657 100644
>> --- a/drivers/media/usb/em28xx/em28xx-core.c
>> +++ b/drivers/media/usb/em28xx/em28xx-core.c
>> @@ -525,17 +525,19 @@ int em28xx_audio_setup(struct em28xx *dev)
>> dev->has_alsa_audio = false;
>> dev->audio_mode.has_audio = false;
>> return 0;
>> -} else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
>> - EM28XX_CHIPCFG_I2S_3_SAMPRATES) {
>> -em28xx_info("I2S Audio (3 sample rates)\n");
>> -dev->audio_mode.i2s_3rates = 1;
>> -} else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
>> - EM28XX_CHIPCFG_I2S_5_SAMPRATES) {
>> -em28xx_info("I2S Audio (5 sample rates)\n");
>> -dev->audio_mode.i2s_5rates = 1;
>> -}
>> -
>> -if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
>> +} else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
>> +if (dev->chip_id < CHIP_ID_EM2860 &&
>> +(cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
>> +EM2820_CHIPCFG_I2S_1_SAMPRATE)
>> +dev->audio_mode.i2s_samplerates = 1;
> No need to store it at all, as, at least currently, this is not used
> anywhere.
Yes, and the same applies to most other members of struct
em28xx_audio_mode. ;)
I'm currently looking deep into the audio code and the whole thing seems
to be hopelessly messed up.
The plan is to send a separate patch that cleans up the audio structures
and variables later when I'm sure which way to go to fix things.
Would that be ok for you or do you want me to drop the samplerate fields
now ?
Regards,
Frank
> This patch could be useful if we could use this to improve em28xx-audio.c.
>
> Otherwise, I would just drop the code that checks it, eventually
> just keeping the registers at em28xx-reg.h
>
>> +else if (dev->chip_id >= CHIP_ID_EM2860 &&
>> + (cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
>> + EM2860_CHIPCFG_I2S_5_SAMPRATES)
>> +dev->audio_mode.i2s_samplerates = 5;
>> +else
>> +dev->audio_mode.i2s_samplerates = 3;
>> +em28xx_info("I2S Audio (%d sample rate(s))\n",
>> + dev->audio_mode.i2s_samplerates);
>> /* Skip the code that does AC97 vendor detection */
>> dev->audio_mode.ac97 = EM28XX_NO_AC97;
>> goto init_audio;
>> diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
>> b/drivers/media/usb/em28xx/em28xx-i2c.c
>> index c4ff973..f2d5f8a 100644
>> --- a/drivers/media/usb/em28xx/em28xx-i2c.c
>> +++ b/drivers/media/usb/em28xx/em28xx-i2c.c
>> @@ -736,10 +736,16 @@ static int em28xx_i2c_eeprom(struct em28xx *dev,
>> unsigned bus,
>> em28xx_info("\tAC97 audio (5 sample rates)\n");
>> break;
>> case 2:
>> -em28xx_info("\tI2S audio, sample rate=32k\n");
>> +if (dev->chip_id < CHIP_ID_EM2860)
>> +em28xx_info("\tI2S audio, sample rate=32k\n");
>> +else
>> +em28xx_info("\tI2S audio, 3 sample rates\n");
>> break;
>> case 3:
>> -em28xx_info("\tI2S audio, 3 sample rates\n");
>> +if (dev->chip_id < CHIP_ID_EM2860)
>> +em28xx_info("\tI2S audio, 3 sample rates\n");
>> +else
>> +em28xx_info("\tI2S audio, 5 sample rates\n");
>> break;
>> }
>>
>> diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
>> b/drivers/media/usb/em28xx/em28xx-reg.h
>> index b769ceb..311fb34 100644
>> --- a/drivers/media/usb/em28xx/em28xx-reg.h
>> +++ b/drivers/media/usb/em28xx/em28xx-reg.h
>> @@ -2
Re: em28xx DEADLOCK reported by lock debug
On 22.12.2013 20:02, Frank Schäfer wrote: Am 22.12.2013 15:34, schrieb Antti Palosaari: On 22.12.2013 15:51, Frank Schäfer wrote: Am 21.12.2013 20:55, schrieb Antti Palosaari: On 21.12.2013 18:51, Frank Schäfer wrote: Hi Antti, thank you for reporting this issue. Am 18.12.2013 17:04, schrieb Antti Palosaari: That same lock debug deadlock is still there (maybe ~4 times I report it during 2 years). Is that possible to fix easily at all? Patches are always welcome. ;) haha, I cannot simply learn every driver I meet some problems... Hint: If you report a bug ~4 times in 2 years but never get a reply, it usually means a) nobody cares b) nobody has the resources (time, knowledge) to fix it. So you either have to live with this issue or to fix it yourself. OK, as you request me to fix it, I will fix that by making DVB USB v2 driver for these em28xx devices I have added. It should not be very much work as em28xx protocol is still relatively easy. How would that help to get those lockdep false warnings fixed ? Btw: these warnings should appear for _all_ em28xx extensions (dvb, input, audio). I am already looking to silence that v4l2 lockdep report. It is hard to say how much it is work as I simply don't know even reasons. I suspect that if I start learning and fixing em28xx driver it will take week or two as a workload. Writing new dvb-usb driver is only max 2 days of work and as a bonus you will get some missing features for free: 1) power-management 2) suspend/resume 3) PID filters 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: em28xx DEADLOCK reported by lock debug
Am 22.12.2013 15:53, schrieb Mauro Carvalho Chehab:
> Em Sun, 22 Dec 2013 14:51:53 +0100
> Frank Schäfer escreveu:
>
>> Am 21.12.2013 20:55, schrieb Antti Palosaari:
>>> On 21.12.2013 18:51, Frank Schäfer wrote:
Hi Antti,
thank you for reporting this issue.
Am 18.12.2013 17:04, schrieb Antti Palosaari:
> That same lock debug deadlock is still there (maybe ~4 times I report
> it during 2 years). Is that possible to fix easily at all?
Patches are always welcome. ;)
>>> haha, I cannot simply learn every driver I meet some problems...
>> Hint:
>>
>> If you report a bug ~4 times in 2 years but never get a reply, it
>> usually means
>> a) nobody cares
>> b) nobody has the resources (time, knowledge) to fix it.
>>
>> So you either have to live with this issue or to fix it yourself.
> It is the latter case: fixing it require lots of efforts.
Yes, I know. ;-)
> One way to fix would be to change em28xx_close_extension() to
> something like:
>
> diff --git a/drivers/media/usb/em28xx/em28xx-core.c
> b/drivers/media/usb/em28xx/em28xx-core.c
> index f6076a512e8f..d938e2bbd62f 100644
> --- a/drivers/media/usb/em28xx/em28xx-core.c
> +++ b/drivers/media/usb/em28xx/em28xx-core.c
> @@ -1350,13 +1350,19 @@ void em28xx_init_extension(struct em28xx *dev)
>
> void em28xx_close_extension(struct em28xx *dev)
> {
> + int (*fini)(struct em28xx *) = NULL;
> const struct em28xx_ops *ops = NULL;
>
> mutex_lock(&em28xx_devlist_mutex);
> list_for_each_entry(ops, &em28xx_extension_devlist, next) {
> - if (ops->fini)
> - ops->fini(dev);
> + fini = ops->fini;
> }
> list_del(&dev->devlist);
> mutex_unlock(&em28xx_devlist_mutex);
> +
> + if (fini) {
> + mutex_lock(&dev->lock);
> + fini(dev);
> + mutex_unlock(&dev->lock);
> + }
> }
>
> Please note that the above is not 100% correct, as one device may have
> more than one extension.
>
> Then, it should be sure that on every place that em28xx_close_extension()
> is called, dev->lock is not taken.
>
> As an alternative, eventually the extension list could be moved to the
> struct em28xx, but a device list is still needed, in order to handle
> extension module removal.
>
> Another way that would probably be better is to convert the em28xx
> code that handles extension (extension here is dvb, rc, alsa) to use
> krefs, And add a kref free code that would call ops->fini. Note that,
> in this case, dev itself would also need to be a kref.
>
> I suspect that using kref would would be cleaner, but a change like that
> would require to rewrite the extensions code.
I have zero knowledge about how the locking correctness stuff works, but
what about improving it ?
Shouldn't it notice that flush_work() waits until the work is done
before the lock is acquired ?
> Btw, there's a related RFC patchset that splits the V4L2 interface from
> em28xx, transforming it also into an extension. With such patch, a DVB
> only device should not call any v4l2 init code, nor require V4L2 to be
> enabled:
> https://patchwork.linuxtv.org/patch/17967/
Yes, I remember it and it would be a big step forward.
> The above RFC requires testing.
>
> I may be able to find some time to do work on it this end of the year,
> starting with the V4L2 split patchset, depending if I finish some other
> things already on my todo list.
I'm going to review the patch within the next days and do some testing.
Regards,
Frank
> Regards,
> Mauro
--
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: em28xx DEADLOCK reported by lock debug
Am 22.12.2013 15:34, schrieb Antti Palosaari: > On 22.12.2013 15:51, Frank Schäfer wrote: >> Am 21.12.2013 20:55, schrieb Antti Palosaari: >>> On 21.12.2013 18:51, Frank Schäfer wrote: Hi Antti, thank you for reporting this issue. Am 18.12.2013 17:04, schrieb Antti Palosaari: > That same lock debug deadlock is still there (maybe ~4 times I report > it during 2 years). Is that possible to fix easily at all? Patches are always welcome. ;) >>> >>> haha, I cannot simply learn every driver I meet some problems... >> Hint: >> >> If you report a bug ~4 times in 2 years but never get a reply, it >> usually means >> a) nobody cares >> b) nobody has the resources (time, knowledge) to fix it. >> >> So you either have to live with this issue or to fix it yourself. > > OK, as you request me to fix it, I will fix that by making DVB USB v2 > driver for these em28xx devices I have added. > > It should not be very much work as em28xx protocol is still relatively > easy. How would that help to get those lockdep false warnings fixed ? Btw: these warnings should appear for _all_ em28xx extensions (dvb, input, audio). Regards, Frank > > 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
Re: em28xx list_add corruption reported by list debug
Em Sun, 22 Dec 2013 18:17:50 +0200 Antti Palosaari escreveu: > On 22.12.2013 17:55, Mauro Carvalho Chehab wrote: > > Em Sun, 22 Dec 2013 13:06:00 -0200 > > Mauro Carvalho Chehab escreveu: > > > >> Em Sun, 22 Dec 2013 00:27:21 +0200 > >> Antti Palosaari escreveu: > >> > >>> I ran also this kind of bug. Device was PCTV 290e, which has that video > >>> unused. I have no any analog em28xx webcam to test if that happens here > >>> too. > >>> > >>> Fortunately I found one video device which does not crash nor dump debug > >>> bug warnings. It is some old gspca webcam. Have to look example how > >>> those videobuf callbacks are implemented there.. > >>> > >>> regards > >>> Antti > >>> > >>> > >>> [crope@localhost linux]$ cat /dev/video0 > >>> cat: /dev/video0: Invalid argument > >>> [crope@localhost linux]$ cat /dev/video0 > >>> cat: /dev/video0: Device or resource busy > >>> [crope@localhost linux]$ > >>> > >>> > >>> joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint > >>> for analog mode and transfer type 0 > >> > >> It seems that there's something bad on em28174 registration: it should not > >> be creating a v4l2 device, if the device is DVB only. > >> > >> The thing is that, when this driver was created, all devices were either > >> analog only or hybrid. Only very recently, pure DVB devices got added. > >> > >> It shouldn't be that hard to split em28xx_init_dev() into a few routines > >> that would only register v4l2 if the device has analog support. > >> > >> Again, this changeset: > >>https://patchwork.linuxtv.org/patch/17967/ > >> > >> Seems to be part of such solution, as it already splits the v4l2 > >> register logic into a separate function. > > > > Ok, if I didn't make any mistake, this changeset should do the trick: > > https://patchwork.linuxtv.org/patch/21282/ > > > > Please notice that this is compile-tested only. > > I started to testing that patch, but now I get following compilation > errors: > > WARNING: "em28xx_detect_sensor" [drivers/media/usb/em28xx/em28xx.ko] > undefined! > WARNING: "em28xx_init_camera" [drivers/media/usb/em28xx/em28xx.ko] > undefined! > WARNING: "em28xx_resolution_set" > [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! > WARNING: "em28xx_colorlevels_set_default" > [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! > WARNING: "em28xx_set_outfmt" [drivers/media/usb/em28xx/em28xx-v4l.ko] > undefined! > WARNING: "em28xx_read_reg_req_len" > [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! > WARNING: "em28xx_wake_i2c" [drivers/media/usb/em28xx/em28xx-v4l.ko] > undefined! > WARNING: "em28xx_set_alternate" [drivers/media/usb/em28xx/em28xx-v4l.ko] > undefined! > WARNING: "em28xx_vbi_supported" [drivers/media/usb/em28xx/em28xx-v4l.ko] > undefined! > WARNING: "em28xx_release_resources" > [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! > WARNING: "em28xx_boards" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! > > anyhow, I am not sure if those are related or not. I will re-compile > whole kernel to see (build only media). That's the lack of exporting symbols or moving the code. I'm currently working on testing this patchset. > > regards > Antti > -- Cheers, Mauro -- 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
VIVI driver DEADLOCK reported by lockdep
Hello!
I started testing locks from my SDR drivers and ended up unexpected
warnings. Now I have looked quite a lot of things and read carefully
many times v4l2 framework documentation [1]. V4L2 locking model is not
very clear for me, but I understand there is 2 mutex, one for
serializing IOCTLs and one for serializing videobuf2 operations. And top
of that there is spinlock inside driver for frame-buffers. It hard to
say very much about those locks which are hidden inside v4l2 - only
pointer passed from driver. Maybe it is possible to get rid of that by
using own locks inside driver (passing NULL mutexes to v4l2/vb2 gives
possibility to use own locking)?
[1] Documentation/video4linux/v4l2-framework.txt
After the MSi3101 SDR driver test failures I decided to test some other
drivers to see what happens. As I don't have many webcams I decided to
test vivi and surprise, same error is reported.
I don't know enough v4l2 / vb2 internals to say much about these. But I
think I don't care to try fix SDR drivers as that same error seems to be
reported other devices too. Maybe it is some corner case or false
positive. Anyhow, it could be nice to get rid of it.
joulu 22 18:26:31 localhost.localdomain kernel: vivi-000: V4L2 device
registered as video0
joulu 22 18:26:31 localhost.localdomain kernel: Video Technology
Magazine Virtual Video Capture Board ver 0.8.1 successfully loaded.
joulu 22 18:26:31 localhost.localdomain colord[630]: Device added:
sysfs-/dev/video0
joulu 22 18:26:43 localhost.localdomain chronyd[563]: Selected source
62.237.86.234
joulu 22 18:26:51 localhost.localdomain kernel: joulu 22 18:26:51
localhost.localdomain kernel:
==
joulu 22 18:26:51 localhost.localdomain kernel: [ INFO: possible
circular locking dependency detected ]
joulu 22 18:26:51 localhost.localdomain kernel: 3.13.0-rc1+ #77 Tainted:
G C O
joulu 22 18:26:51 localhost.localdomain kernel:
---
joulu 22 18:26:51 localhost.localdomain kernel: video_source:sr/32072 is
trying to acquire lock:
joulu 22 18:26:51 localhost.localdomain kernel:
(&dev->mutex#2){+.+.+.}, at: [] vb2_fop_mmap+0x33/0x90
[videobuf2_core]
joulu 22 18:26:51 localhost.localdomain kernel:
but task is already
holding lock:
joulu 22 18:26:51 localhost.localdomain kernel:
(&mm->mmap_sem){++}, at: [] vm_mmap_pgoff+0x6f/0xc0
joulu 22 18:26:51 localhost.localdomain kernel:
which lock already
depends on the new lock.
joulu 22 18:26:51 localhost.localdomain kernel:
the existing dependency
chain (in reverse order) is:
joulu 22 18:26:51 localhost.localdomain kernel:
-> #1
(&mm->mmap_sem){++}:
joulu 22 18:26:51 localhost.localdomain kernel:
[] __lock_acquire+0x3d6/0xc40
joulu 22 18:26:51 localhost.localdomain kernel:
[] lock_acquire+0xb0/0x150
joulu 22 18:26:51 localhost.localdomain kernel:
[] might_fault+0x8c/0xb0
joulu 22 18:26:51 localhost.localdomain kernel:
[] video_usercopy+0x355/0x4e0 [videodev]
joulu 22 18:26:51 localhost.localdomain kernel:
[] video_ioctl2+0x15/0x20 [videodev]
joulu 22 18:26:51 localhost.localdomain kernel:
[] v4l2_ioctl+0x153/0x240 [videodev]
joulu 22 18:26:51 localhost.localdomain kernel:
[] do_vfs_ioctl+0x300/0x520
joulu 22 18:26:51 localhost.localdomain kernel:
[] SyS_ioctl+0x81/0xa0
joulu 22 18:26:51 localhost.localdomain kernel:
[] system_call_fastpath+0x16/0x1b
joulu 22 18:26:51 localhost.localdomain kernel:
-> #0
(&dev->mutex#2){+.+.+.}:
joulu 22 18:26:51 localhost.localdomain kernel:
[] validate_chain.isra.36+0x10d7/0x1130
joulu 22 18:26:51 localhost.localdomain kernel:
[] __lock_acquire+0x3d6/0xc40
joulu 22 18:26:51 localhost.localdomain kernel:
[] lock_acquire+0xb0/0x150
joulu 22 18:26:51 localhost.localdomain kernel:
[] mutex_lock_interruptible_nested+0x77/0x460
joulu 22 18:26:51 localhost.localdomain kernel:
[] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
joulu 22 18:26:51 localhost.localdomain kernel:
[] v4l2_mmap+0x5a/0xa0 [videodev]
joulu 22 18:26:51 localhost.localdomain kernel:
[] mmap_region+0x3cd/0x5a0
joulu 22 18:26:51 localhost.localdomain kernel:
[] do_mmap_pgoff+0x357/0x3e0
joulu 22 18:26:51 localhost.localdomain kernel:
[] vm_mmap_pgoff+0x90/0xc0
joulu 22 18:26:51 localhost.localdomain kernel:
[] SyS_mmap_pgoff+0x1d3/0x270
joulu 22 18:26:51 localhost.localdomain kernel:
[] SyS_mmap+0x22/0x30
joulu 22 18:26:51 localhost.localdomain kernel:
[] system_call_fastpath+0x16/0x1b
joulu 22 18:26:51 localhost.localdomain kernel:
other info that might
help us debug this:
joulu 22 18:26:51 localhost.localdomain kernel: Possible unsafe locking
scenario:
joulu 22 18:26:51 localhost.l
Re: em28xx list_add corruption reported by list debug
On 22.12.2013 18:17, Antti Palosaari wrote: On 22.12.2013 17:55, Mauro Carvalho Chehab wrote: Em Sun, 22 Dec 2013 13:06:00 -0200 Mauro Carvalho Chehab escreveu: Em Sun, 22 Dec 2013 00:27:21 +0200 Antti Palosaari escreveu: I ran also this kind of bug. Device was PCTV 290e, which has that video unused. I have no any analog em28xx webcam to test if that happens here too. Fortunately I found one video device which does not crash nor dump debug bug warnings. It is some old gspca webcam. Have to look example how those videobuf callbacks are implemented there.. regards Antti [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Invalid argument [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Device or resource busy [crope@localhost linux]$ joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint for analog mode and transfer type 0 It seems that there's something bad on em28174 registration: it should not be creating a v4l2 device, if the device is DVB only. The thing is that, when this driver was created, all devices were either analog only or hybrid. Only very recently, pure DVB devices got added. It shouldn't be that hard to split em28xx_init_dev() into a few routines that would only register v4l2 if the device has analog support. Again, this changeset: https://patchwork.linuxtv.org/patch/17967/ Seems to be part of such solution, as it already splits the v4l2 register logic into a separate function. Ok, if I didn't make any mistake, this changeset should do the trick: https://patchwork.linuxtv.org/patch/21282/ Please notice that this is compile-tested only. I started to testing that patch, but now I get following compilation errors: WARNING: "em28xx_detect_sensor" [drivers/media/usb/em28xx/em28xx.ko] undefined! WARNING: "em28xx_init_camera" [drivers/media/usb/em28xx/em28xx.ko] undefined! WARNING: "em28xx_resolution_set" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_colorlevels_set_default" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_set_outfmt" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_read_reg_req_len" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_wake_i2c" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_set_alternate" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_vbi_supported" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_release_resources" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_boards" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! anyhow, I am not sure if those are related or not. I will re-compile whole kernel to see (build only media). It builds very fast as compile caching. Errors are still there. My tree is latest media/master + my SDR patches. CRC d20c387c Kernel: arch/x86/boot/bzImage is ready (#78) ERROR: "em28xx_detect_sensor" [drivers/media/usb/em28xx/em28xx.ko] undefined! ERROR: "em28xx_init_camera" [drivers/media/usb/em28xx/em28xx.ko] undefined! ERROR: "em28xx_resolution_set" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_colorlevels_set_default" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_set_outfmt" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_read_reg_req_len" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_wake_i2c" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_set_alternate" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_vbi_supported" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_release_resources" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! ERROR: "em28xx_boards" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 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: em28xx list_add corruption reported by list debug
On 22.12.2013 17:55, Mauro Carvalho Chehab wrote: Em Sun, 22 Dec 2013 13:06:00 -0200 Mauro Carvalho Chehab escreveu: Em Sun, 22 Dec 2013 00:27:21 +0200 Antti Palosaari escreveu: I ran also this kind of bug. Device was PCTV 290e, which has that video unused. I have no any analog em28xx webcam to test if that happens here too. Fortunately I found one video device which does not crash nor dump debug bug warnings. It is some old gspca webcam. Have to look example how those videobuf callbacks are implemented there.. regards Antti [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Invalid argument [crope@localhost linux]$ cat /dev/video0 cat: /dev/video0: Device or resource busy [crope@localhost linux]$ joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint for analog mode and transfer type 0 It seems that there's something bad on em28174 registration: it should not be creating a v4l2 device, if the device is DVB only. The thing is that, when this driver was created, all devices were either analog only or hybrid. Only very recently, pure DVB devices got added. It shouldn't be that hard to split em28xx_init_dev() into a few routines that would only register v4l2 if the device has analog support. Again, this changeset: https://patchwork.linuxtv.org/patch/17967/ Seems to be part of such solution, as it already splits the v4l2 register logic into a separate function. Ok, if I didn't make any mistake, this changeset should do the trick: https://patchwork.linuxtv.org/patch/21282/ Please notice that this is compile-tested only. I started to testing that patch, but now I get following compilation errors: WARNING: "em28xx_detect_sensor" [drivers/media/usb/em28xx/em28xx.ko] undefined! WARNING: "em28xx_init_camera" [drivers/media/usb/em28xx/em28xx.ko] undefined! WARNING: "em28xx_resolution_set" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_colorlevels_set_default" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_set_outfmt" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_read_reg_req_len" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_wake_i2c" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_set_alternate" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_vbi_supported" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_release_resources" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! WARNING: "em28xx_boards" [drivers/media/usb/em28xx/em28xx-v4l.ko] undefined! anyhow, I am not sure if those are related or not. I will re-compile whole kernel to see (build only media). 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: [PATCH] em28xx: fix I2S audio sample rate definitions and info output
Em Sun, 22 Dec 2013 15:17:46 +0100
Frank Schäfer escreveu:
> The audio configuration in chip config register 0x00 and eeprom are always
> consistent. But currently the audio configuration #defines for the chip config
> register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the
> eeprom
> info output says 0x20 means 1 sample rate and 0x30 3 sample rates.
>
> I've checked the datasheet excerpts I have and it seems that the meaning of
> these bits is different for em2820/40 (1 and 3 sample rates) and em2860+
> (3 and 5 smaple rates).
> I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom
> audio config 0x20 matches the sample rates reproted by the USB device
> descriptor (32k only).
>
> Signed-off-by: Frank Schäfer
> ---
> drivers/media/usb/em28xx/em28xx-core.c | 24 +---
> drivers/media/usb/em28xx/em28xx-i2c.c | 10 --
> drivers/media/usb/em28xx/em28xx-reg.h | 10 ++
> drivers/media/usb/em28xx/em28xx.h |3 +--
> 4 Dateien geändert, 28 Zeilen hinzugefügt(+), 19 Zeilen entfernt(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-core.c
> b/drivers/media/usb/em28xx/em28xx-core.c
> index f6076a5..192b657 100644
> --- a/drivers/media/usb/em28xx/em28xx-core.c
> +++ b/drivers/media/usb/em28xx/em28xx-core.c
> @@ -525,17 +525,19 @@ int em28xx_audio_setup(struct em28xx *dev)
> dev->has_alsa_audio = false;
> dev->audio_mode.has_audio = false;
> return 0;
> - } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
> -EM28XX_CHIPCFG_I2S_3_SAMPRATES) {
> - em28xx_info("I2S Audio (3 sample rates)\n");
> - dev->audio_mode.i2s_3rates = 1;
> - } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
> -EM28XX_CHIPCFG_I2S_5_SAMPRATES) {
> - em28xx_info("I2S Audio (5 sample rates)\n");
> - dev->audio_mode.i2s_5rates = 1;
> - }
> -
> - if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
> + } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
> + if (dev->chip_id < CHIP_ID_EM2860 &&
> + (cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
> + EM2820_CHIPCFG_I2S_1_SAMPRATE)
> + dev->audio_mode.i2s_samplerates = 1;
No need to store it at all, as, at least currently, this is not used
anywhere.
This patch could be useful if we could use this to improve em28xx-audio.c.
Otherwise, I would just drop the code that checks it, eventually
just keeping the registers at em28xx-reg.h
> + else if (dev->chip_id >= CHIP_ID_EM2860 &&
> + (cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
> + EM2860_CHIPCFG_I2S_5_SAMPRATES)
> + dev->audio_mode.i2s_samplerates = 5;
> + else
> + dev->audio_mode.i2s_samplerates = 3;
> + em28xx_info("I2S Audio (%d sample rate(s))\n",
> +dev->audio_mode.i2s_samplerates);
> /* Skip the code that does AC97 vendor detection */
> dev->audio_mode.ac97 = EM28XX_NO_AC97;
> goto init_audio;
> diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
> b/drivers/media/usb/em28xx/em28xx-i2c.c
> index c4ff973..f2d5f8a 100644
> --- a/drivers/media/usb/em28xx/em28xx-i2c.c
> +++ b/drivers/media/usb/em28xx/em28xx-i2c.c
> @@ -736,10 +736,16 @@ static int em28xx_i2c_eeprom(struct em28xx *dev,
> unsigned bus,
> em28xx_info("\tAC97 audio (5 sample rates)\n");
> break;
> case 2:
> - em28xx_info("\tI2S audio, sample rate=32k\n");
> + if (dev->chip_id < CHIP_ID_EM2860)
> + em28xx_info("\tI2S audio, sample rate=32k\n");
> + else
> + em28xx_info("\tI2S audio, 3 sample rates\n");
> break;
> case 3:
> - em28xx_info("\tI2S audio, 3 sample rates\n");
> + if (dev->chip_id < CHIP_ID_EM2860)
> + em28xx_info("\tI2S audio, 3 sample rates\n");
> + else
> + em28xx_info("\tI2S audio, 5 sample rates\n");
> break;
> }
>
> diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
> b/drivers/media/usb/em28xx/em28xx-reg.h
> index b769ceb..311fb34 100644
> --- a/drivers/media/usb/em28xx/em28xx-reg.h
> +++ b/drivers/media/usb/em28xx/em28xx-reg.h
> @@ -25,10 +25,12 @@
> #define EM28XX_R00_CHIPCFG 0x00
>
> /* em28xx Chip Configuration 0x00 */
> -#define EM28XX_CHIPCFG_VENDOR_AUDIO 0x80
> -#define EM28XX_CHIPCFG_I2S_VOLUME_CAPABLE0x40
> -#define EM28XX_CHIPCFG_I2S_5_SAMPRATES 0x30
> -#define EM28XX_CHIPCFG_I2S_3_SAMPRATES 0x20
> +#define EM2860_CHIPCFG_VENDOR_AUDIO 0x80
> +#define EM2860_CHIPCFG_I2S_VOLUME_CAPABLE0x40
> +#define EM2820_CHIPCFG_I2S_3_SAMPRATES 0x30
> +#define EM2860_CHIPCFG_I2S_5_SA
Re: em28xx list_add corruption reported by list debug
Em Sun, 22 Dec 2013 13:06:00 -0200 Mauro Carvalho Chehab escreveu: > Em Sun, 22 Dec 2013 00:27:21 +0200 > Antti Palosaari escreveu: > > > I ran also this kind of bug. Device was PCTV 290e, which has that video > > unused. I have no any analog em28xx webcam to test if that happens here too. > > > > Fortunately I found one video device which does not crash nor dump debug > > bug warnings. It is some old gspca webcam. Have to look example how > > those videobuf callbacks are implemented there.. > > > > regards > > Antti > > > > > > [crope@localhost linux]$ cat /dev/video0 > > cat: /dev/video0: Invalid argument > > [crope@localhost linux]$ cat /dev/video0 > > cat: /dev/video0: Device or resource busy > > [crope@localhost linux]$ > > > > > > joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint > > for analog mode and transfer type 0 > > It seems that there's something bad on em28174 registration: it should not > be creating a v4l2 device, if the device is DVB only. > > The thing is that, when this driver was created, all devices were either > analog only or hybrid. Only very recently, pure DVB devices got added. > > It shouldn't be that hard to split em28xx_init_dev() into a few routines > that would only register v4l2 if the device has analog support. > > Again, this changeset: > https://patchwork.linuxtv.org/patch/17967/ > > Seems to be part of such solution, as it already splits the v4l2 > register logic into a separate function. Ok, if I didn't make any mistake, this changeset should do the trick: https://patchwork.linuxtv.org/patch/21282/ Please notice that this is compile-tested only. Regards, Mauro -- Cheers, Mauro -- 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
[RFC PATCHv2] em28xx: split analog part into a separate module
Now that dvb-only devices start to happen, it makes sense
to split the analog part on a separate module.
Signed-off-by: Mauro Carvalho Chehab
-
This is a respin of https://patchwork.linuxtv.org/patch/17967/
v2: add a dev->has_video to signalize if the device has a video interface, and
fix some locks
Compile-tested only.
---
drivers/media/usb/em28xx/Kconfig| 6 +-
drivers/media/usb/em28xx/Makefile | 5 +-
drivers/media/usb/em28xx/em28xx-cards.c | 94 ++
drivers/media/usb/em28xx/em28xx-core.c | 12 +++
drivers/media/usb/em28xx/em28xx-video.c | 133
drivers/media/usb/em28xx/em28xx.h | 17 ++--
6 files changed, 150 insertions(+), 117 deletions(-)
diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig
index d6ba514d31eb..838fc9dbb747 100644
--- a/drivers/media/usb/em28xx/Kconfig
+++ b/drivers/media/usb/em28xx/Kconfig
@@ -1,8 +1,12 @@
config VIDEO_EM28XX
- tristate "Empia EM28xx USB video capture support"
+ tristate "Empia EM28xx USB devices support"
depends on VIDEO_DEV && I2C
select VIDEO_TUNER
select VIDEO_TVEEPROM
+
+config VIDEO_EM28XX_V4L2
+ tristate "Empia EM28xx analog TV, video capture and/or webcam support"
+ depends on VIDEO_EM28XX && I2C
select VIDEOBUF2_VMALLOC
select VIDEO_SAA711X if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_TVP5150 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/em28xx/Makefile
b/drivers/media/usb/em28xx/Makefile
index ad6d48557940..3e2b6b54817d 100644
--- a/drivers/media/usb/em28xx/Makefile
+++ b/drivers/media/usb/em28xx/Makefile
@@ -1,10 +1,11 @@
-em28xx-y +=em28xx-video.o em28xx-i2c.o em28xx-cards.o
-em28xx-y +=em28xx-core.o em28xx-vbi.o em28xx-camera.o
+em28xx-y +=em28xx-core.o em28xx-i2c.o em28xx-cards.o
+em28xx-v4l-objs := em28xx-video.o em28xx-vbi.o em28xx-camera.o
em28xx-alsa-objs := em28xx-audio.o
em28xx-rc-objs := em28xx-input.o
obj-$(CONFIG_VIDEO_EM28XX) += em28xx.o
+obj-$(CONFIG_VIDEO_EM28XX_V4L2) += em28xx-v4l.o
obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 36853f16bf97..e1ffd9c6e79d 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2106,7 +2106,7 @@ struct em28xx_board em28xx_boards[] = {
},
/* 1b80:e1cc Delock 61959
* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2
- * mostly the same as MaxMedia UB-425-TC but different remote */
+* mostly the same as MaxMedia UB-425-TC but different remote */
[EM2874_BOARD_DELOCK_61959] = {
.name = "Delock 61959",
.tuner_type= TUNER_ABSENT,
@@ -2955,11 +2955,12 @@ static void request_module_async(struct work_struct
*work)
em28xx_init_extension(dev);
#if defined(CONFIG_MODULES) && defined(MODULE)
+ if (!dev->has_video)
+ request_module("em28xx-v4l2");
if (dev->has_audio_class)
request_module("snd-usb-audio");
else if (dev->has_alsa_audio)
request_module("em28xx-alsa");
-
if (dev->board.has_dvb)
request_module("em28xx-dvb");
if (dev->board.buttons ||
@@ -2988,8 +2989,6 @@ void em28xx_release_resources(struct em28xx *dev)
{
/*FIXME: I2C IR should be disconnected */
- em28xx_release_analog_resources(dev);
-
if (dev->def_i2c_bus)
em28xx_i2c_unregister(dev, 1);
em28xx_i2c_unregister(dev, 0);
@@ -3014,7 +3013,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
struct usb_interface *interface,
int minor)
{
- struct v4l2_ctrl_handler *hdl = &dev->ctrl_handler;
int retval;
static const char *default_chip_name = "em28xx";
const char *chip_name = default_chip_name;
@@ -3141,15 +3139,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
}
}
- retval = v4l2_device_register(&interface->dev, &dev->v4l2_dev);
- if (retval < 0) {
- em28xx_errdev("Call to v4l2_device_register() failed!\n");
- return retval;
- }
-
- v4l2_ctrl_handler_init(hdl, 8);
- dev->v4l2_dev.ctrl_handler = hdl;
-
rt_mutex_init(&dev->i2c_bus_lock);
/* register i2c bus 0 */
@@ -3178,75 +3167,11 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
}
}
- /*
-* Default format, used for tvp5150 or saa711x output formats
-*/
- dev->vinmode = 0x10;
- dev->vinctl = EM28XX_VINCTRL_INTERLACED |
- EM28XX_VINCTRL_CCIR656_ENABLE;
-
Re: em28xx list_add corruption reported by list debug
Em Sun, 22 Dec 2013 00:27:21 +0200 Antti Palosaari escreveu: > I ran also this kind of bug. Device was PCTV 290e, which has that video > unused. I have no any analog em28xx webcam to test if that happens here too. > > Fortunately I found one video device which does not crash nor dump debug > bug warnings. It is some old gspca webcam. Have to look example how > those videobuf callbacks are implemented there.. > > regards > Antti > > > [crope@localhost linux]$ cat /dev/video0 > cat: /dev/video0: Invalid argument > [crope@localhost linux]$ cat /dev/video0 > cat: /dev/video0: Device or resource busy > [crope@localhost linux]$ > > > joulu 22 00:08:24 localhost.localdomain kernel: em28174 #0: no endpoint > for analog mode and transfer type 0 It seems that there's something bad on em28174 registration: it should not be creating a v4l2 device, if the device is DVB only. The thing is that, when this driver was created, all devices were either analog only or hybrid. Only very recently, pure DVB devices got added. It shouldn't be that hard to split em28xx_init_dev() into a few routines that would only register v4l2 if the device has analog support. Again, this changeset: https://patchwork.linuxtv.org/patch/17967/ Seems to be part of such solution, as it already splits the v4l2 register logic into a separate function. > joulu 22 00:08:31 localhost.localdomain kernel: [ cut here > ] > joulu 22 00:08:31 localhost.localdomain kernel: WARNING: CPU: 3 PID: > 6892 at lib/list_debug.c:33 __list_add+0xac/0xc0() > joulu 22 00:08:31 localhost.localdomain kernel: list_add corruption. > prev->next should be next (88030b686498), but was (null). > (prev=88030c6c1748). > joulu 22 00:08:31 localhost.localdomain kernel: Modules linked in: > rc_pinnacle_pctv_hd(O) em28xx_rc(O) tda18271(O) cxd2820r(O) > em28xx_dvb(O) r820t(O) mn88472(O) rtl2832_sd...b_usb_af901 > joulu 22 00:08:31 localhost.localdomain kernel: CPU: 3 PID: 6892 Comm: > cat Tainted: G C O 3.13.0-rc1+ #77 > joulu 22 00:08:31 localhost.localdomain kernel: Hardware name: System > manufacturer System Product Name/M5A78L-M/USB3, BIOS 150311/14/2012 > joulu 22 00:08:31 localhost.localdomain kernel: 0009 > 8803052afcb8 816b8da9 8803052afd00 > joulu 22 00:08:31 localhost.localdomain kernel: 8803052afcf0 > 8106bcfd 88030c6c5348 88030b686498 > joulu 22 00:08:31 localhost.localdomain kernel: 88030c6c1748 > 0292 0001 8803052afd50 > joulu 22 00:08:31 localhost.localdomain kernel: Call Trace: > joulu 22 00:08:31 localhost.localdomain kernel: [] > dump_stack+0x4d/0x66 > joulu 22 00:08:31 localhost.localdomain kernel: [] > warn_slowpath_common+0x7d/0xa0 > joulu 22 00:08:31 localhost.localdomain kernel: [] > warn_slowpath_fmt+0x4c/0x50 > joulu 22 00:08:31 localhost.localdomain kernel: [] > __list_add+0xac/0xc0 > joulu 22 00:08:31 localhost.localdomain kernel: [] > buffer_queue+0x7b/0xb0 [em28xx] > joulu 22 00:08:31 localhost.localdomain kernel: [] > __enqueue_in_driver+0x74/0x80 [videobuf2_core] > joulu 22 00:08:31 localhost.localdomain kernel: [] > vb2_streamon+0xa8/0x190 [videobuf2_core] > joulu 22 00:08:31 localhost.localdomain kernel: [] > __vb2_init_fileio+0x332/0x3a0 [videobuf2_core] > joulu 22 00:08:31 localhost.localdomain kernel: [] > __vb2_perform_fileio+0x483/0x620 [videobuf2_core] > joulu 22 00:08:31 localhost.localdomain kernel: [] > vb2_fop_read+0xc4/0x5e0 [videobuf2_core] > joulu 22 00:08:31 localhost.localdomain kernel: [] > v4l2_read+0x65/0xb0 [videodev] > joulu 22 00:08:31 localhost.localdomain kernel: [] > vfs_read+0x98/0x170 > joulu 22 00:08:31 localhost.localdomain kernel: [] > SyS_read+0x4c/0xa0 > joulu 22 00:08:31 localhost.localdomain kernel: [] ? > __audit_syscall_entry+0x9c/0xf0 > joulu 22 00:08:31 localhost.localdomain kernel: [] > system_call_fastpath+0x16/0x1b > joulu 22 00:08:31 localhost.localdomain kernel: ---[ end trace > dcb247cebbcc2a82 ]--- > > > -- Cheers, Mauro -- 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: em28xx DEADLOCK reported by lock debug
Em Sun, 22 Dec 2013 14:51:53 +0100
Frank Schäfer escreveu:
> Am 21.12.2013 20:55, schrieb Antti Palosaari:
> > On 21.12.2013 18:51, Frank Schäfer wrote:
> >> Hi Antti,
> >>
> >> thank you for reporting this issue.
> >>
> >> Am 18.12.2013 17:04, schrieb Antti Palosaari:
> >>> That same lock debug deadlock is still there (maybe ~4 times I report
> >>> it during 2 years). Is that possible to fix easily at all?
> >>
> >> Patches are always welcome. ;)
> >
> > haha, I cannot simply learn every driver I meet some problems...
> Hint:
>
> If you report a bug ~4 times in 2 years but never get a reply, it
> usually means
> a) nobody cares
> b) nobody has the resources (time, knowledge) to fix it.
>
> So you either have to live with this issue or to fix it yourself.
It is the latter case: fixing it require lots of efforts.
One way to fix would be to change em28xx_close_extension() to
something like:
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index f6076a512e8f..d938e2bbd62f 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -1350,13 +1350,19 @@ void em28xx_init_extension(struct em28xx *dev)
void em28xx_close_extension(struct em28xx *dev)
{
+ int (*fini)(struct em28xx *) = NULL;
const struct em28xx_ops *ops = NULL;
mutex_lock(&em28xx_devlist_mutex);
list_for_each_entry(ops, &em28xx_extension_devlist, next) {
- if (ops->fini)
- ops->fini(dev);
+ fini = ops->fini;
}
list_del(&dev->devlist);
mutex_unlock(&em28xx_devlist_mutex);
+
+ if (fini) {
+ mutex_lock(&dev->lock);
+ fini(dev);
+ mutex_unlock(&dev->lock);
+ }
}
Please note that the above is not 100% correct, as one device may have
more than one extension.
Then, it should be sure that on every place that em28xx_close_extension()
is called, dev->lock is not taken.
As an alternative, eventually the extension list could be moved to the
struct em28xx, but a device list is still needed, in order to handle
extension module removal.
Another way that would probably be better is to convert the em28xx
code that handles extension (extension here is dvb, rc, alsa) to use
krefs, And add a kref free code that would call ops->fini. Note that,
in this case, dev itself would also need to be a kref.
I suspect that using kref would would be cleaner, but a change like that
would require to rewrite the extensions code.
Btw, there's a related RFC patchset that splits the V4L2 interface from
em28xx, transforming it also into an extension. With such patch, a DVB
only device should not call any v4l2 init code, nor require V4L2 to be
enabled:
https://patchwork.linuxtv.org/patch/17967/
The above RFC requires testing.
I may be able to find some time to do work on it this end of the year,
starting with the V4L2 split patchset, depending if I finish some other
things already on my todo list.
Regards,
Mauro
--
Cheers,
Mauro
--
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: em28xx DEADLOCK reported by lock debug
On 22.12.2013 15:51, Frank Schäfer wrote: Am 21.12.2013 20:55, schrieb Antti Palosaari: On 21.12.2013 18:51, Frank Schäfer wrote: Hi Antti, thank you for reporting this issue. Am 18.12.2013 17:04, schrieb Antti Palosaari: That same lock debug deadlock is still there (maybe ~4 times I report it during 2 years). Is that possible to fix easily at all? Patches are always welcome. ;) haha, I cannot simply learn every driver I meet some problems... Hint: If you report a bug ~4 times in 2 years but never get a reply, it usually means a) nobody cares b) nobody has the resources (time, knowledge) to fix it. So you either have to live with this issue or to fix it yourself. OK, as you request me to fix it, I will fix that by making DVB USB v2 driver for these em28xx devices I have added. It should not be very much work as em28xx protocol is still relatively easy. 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
[PATCH] em28xx: fix I2S audio sample rate definitions and info output
The audio configuration in chip config register 0x00 and eeprom are always
consistent. But currently the audio configuration #defines for the chip config
register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the eeprom
info output says 0x20 means 1 sample rate and 0x30 3 sample rates.
I've checked the datasheet excerpts I have and it seems that the meaning of
these bits is different for em2820/40 (1 and 3 sample rates) and em2860+
(3 and 5 smaple rates).
I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom
audio config 0x20 matches the sample rates reproted by the USB device
descriptor (32k only).
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-core.c | 24 +---
drivers/media/usb/em28xx/em28xx-i2c.c | 10 --
drivers/media/usb/em28xx/em28xx-reg.h | 10 ++
drivers/media/usb/em28xx/em28xx.h |3 +--
4 Dateien geändert, 28 Zeilen hinzugefügt(+), 19 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index f6076a5..192b657 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -525,17 +525,19 @@ int em28xx_audio_setup(struct em28xx *dev)
dev->has_alsa_audio = false;
dev->audio_mode.has_audio = false;
return 0;
- } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
- EM28XX_CHIPCFG_I2S_3_SAMPRATES) {
- em28xx_info("I2S Audio (3 sample rates)\n");
- dev->audio_mode.i2s_3rates = 1;
- } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
- EM28XX_CHIPCFG_I2S_5_SAMPRATES) {
- em28xx_info("I2S Audio (5 sample rates)\n");
- dev->audio_mode.i2s_5rates = 1;
- }
-
- if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
+ } else if ((cfg & EM28XX_CHIPCFG_AUDIOMASK) != EM28XX_CHIPCFG_AC97) {
+ if (dev->chip_id < CHIP_ID_EM2860 &&
+ (cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
+ EM2820_CHIPCFG_I2S_1_SAMPRATE)
+ dev->audio_mode.i2s_samplerates = 1;
+ else if (dev->chip_id >= CHIP_ID_EM2860 &&
+(cfg & EM28XX_CHIPCFG_AUDIOMASK) ==
+EM2860_CHIPCFG_I2S_5_SAMPRATES)
+ dev->audio_mode.i2s_samplerates = 5;
+ else
+ dev->audio_mode.i2s_samplerates = 3;
+ em28xx_info("I2S Audio (%d sample rate(s))\n",
+ dev->audio_mode.i2s_samplerates);
/* Skip the code that does AC97 vendor detection */
dev->audio_mode.ac97 = EM28XX_NO_AC97;
goto init_audio;
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index c4ff973..f2d5f8a 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -736,10 +736,16 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
bus,
em28xx_info("\tAC97 audio (5 sample rates)\n");
break;
case 2:
- em28xx_info("\tI2S audio, sample rate=32k\n");
+ if (dev->chip_id < CHIP_ID_EM2860)
+ em28xx_info("\tI2S audio, sample rate=32k\n");
+ else
+ em28xx_info("\tI2S audio, 3 sample rates\n");
break;
case 3:
- em28xx_info("\tI2S audio, 3 sample rates\n");
+ if (dev->chip_id < CHIP_ID_EM2860)
+ em28xx_info("\tI2S audio, 3 sample rates\n");
+ else
+ em28xx_info("\tI2S audio, 5 sample rates\n");
break;
}
diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
b/drivers/media/usb/em28xx/em28xx-reg.h
index b769ceb..311fb34 100644
--- a/drivers/media/usb/em28xx/em28xx-reg.h
+++ b/drivers/media/usb/em28xx/em28xx-reg.h
@@ -25,10 +25,12 @@
#define EM28XX_R00_CHIPCFG 0x00
/* em28xx Chip Configuration 0x00 */
-#define EM28XX_CHIPCFG_VENDOR_AUDIO0x80
-#define EM28XX_CHIPCFG_I2S_VOLUME_CAPABLE 0x40
-#define EM28XX_CHIPCFG_I2S_5_SAMPRATES 0x30
-#define EM28XX_CHIPCFG_I2S_3_SAMPRATES 0x20
+#define EM2860_CHIPCFG_VENDOR_AUDIO0x80
+#define EM2860_CHIPCFG_I2S_VOLUME_CAPABLE 0x40
+#define EM2820_CHIPCFG_I2S_3_SAMPRATES 0x30
+#define EM2860_CHIPCFG_I2S_5_SAMPRATES 0x30
+#define EM2820_CHIPCFG_I2S_1_SAMPRATE 0x20
+#define EM2860_CHIPCFG_I2S_3_SAMPRATES 0x20
#define EM28XX_CHIPCFG_AC970x10
#define EM28XX_CHIPCFG_AUDIOMASK 0x30
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 191ef35..4d8c7d2 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -292,8 +29
Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL
Em Sat, 21 Dec 2013 07:42:17 -0500
Rob Clark escreveu:
> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote:
> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
> > ERR_PTR on a error. This encourages a common buggy pattern in
> > callers:
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> > if (IS_ERR_OR_NULL(sgt))
> > return PTR_ERR(sgt);
> >
> > This causes the caller to return 0 on an error. IS_ERR_OR_NULL
> > is almost always a sign of poorly-defined error handling.
> >
> > This patch converts dma_buf_map_attachment to always return
> > ERR_PTR, and fixes the callers that incorrectly handled NULL.
> > There are a few more callers that were not checking for NULL
> > at all, which would have dereferenced a NULL pointer later.
> > There are also a few more callers that correctly handled NULL
> > and ERR_PTR differently, I left those alone but they could also
> > be modified to delete the NULL check.
> >
> > This patch also converts dma_buf_vmap to always return NULL.
> > All the callers to dma_buf_vmap only check for NULL, and would
> > have dereferenced an ERR_PTR and panic'd if one was ever
> > returned. This is not consistent with the rest of the dma buf
> > APIs, but matches the expectations of all of the callers.
> >
> > Signed-off-by: Colin Cross
> > ---
> > drivers/base/dma-buf.c | 18 +++---
> > drivers/gpu/drm/drm_prime.c| 2 +-
> > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
> > drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
> > 4 files changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> > index 1e16cbd61da2..cfe1d8bc7bb8 100644
> > --- a/drivers/base/dma-buf.c
> > +++ b/drivers/base/dma-buf.c
> > @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> > * @dmabuf:[in]buffer to attach device to.
> > * @dev: [in]device to be attached.
> > *
> > - * Returns struct dma_buf_attachment * for this attachment; may return
> > negative
> > - * error codes.
> > - *
> > + * Returns struct dma_buf_attachment * for this attachment; returns
> > ERR_PTR on
> > + * error.
> > */
> > struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > struct device *dev)
> > @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
> > * @attach:[in]attachment whose scatterlist is to be returned
> > * @direction: [in]direction of DMA transfer
> > *
> > - * Returns sg_table containing the scatterlist to be returned; may return
> > NULL
> > - * or ERR_PTR.
> > - *
> > + * Returns sg_table containing the scatterlist to be returned; returns
> > ERR_PTR
> > + * on error.
> > */
> > struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> > enum dma_data_direction direction)
> > @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct
> > dma_buf_attachment *attach,
> > return ERR_PTR(-EINVAL);
> >
> > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> > + if (!sg_table)
> > + sg_table = ERR_PTR(-ENOMEM);
> >
> > return sg_table;
> > }
> > @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
> > * These calls are optional in drivers. The intended use for them
> > * is for mapping objects linear in kernel space for high use objects.
> > * Please attempt to use kmap/kunmap before thinking about these
> > interfaces.
> > + *
> > + * Returns NULL on error.
> > */
> > void *dma_buf_vmap(struct dma_buf *dmabuf)
> > {
> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > BUG_ON(dmabuf->vmap_ptr);
> >
> > ptr = dmabuf->ops->vmap(dmabuf);
> > - if (IS_ERR_OR_NULL(ptr))
> > + if (WARN_ON_ONCE(IS_ERR(ptr)))
>
> since vmap is optional, the WARN_ON might be a bit strong.. although
> it would be a bit strange for an exporter to supply a vmap fxn which
> always returned NULL, not sure about that. Just thought I'd mention
> it in case anyone else had an opinion about that.
>
> But either way:
>
> Reviewed-by: Rob Clark
IMHO, a WARN_ON_ONCE() here (or some other error report printk) seems ok,
as, if this function is called, the caller would be expecting it to not
fail.
Either way:
Reviewed-by: Mauro Carvalho Chehab
>
>
> > + ptr = NULL;
> > + if (!ptr)
> > goto out_unlock;
> >
> > dmabuf->vmap_ptr = ptr;
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index 56805c39c906..bb516fdd195d 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct
> > drm_device *dev,
> > get_dma_buf(dma_buf);
> >
> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> >
Re: [PATCH 10/11] media: rc: img-ir: add Sharp decoder module
Em Fri, 13 Dec 2013 15:12:58 +
James Hogan escreveu:
> Add an img-ir module for decoding the Sharp infrared protocol.
Patches 5 and 7-11 look OK to me.
While not required for patchset acceptance, it would be great if you could
also add an IR raw decoder for this protocol, specially if you can also
test it.
>
> Signed-off-by: James Hogan
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> ---
> drivers/media/rc/img-ir/Kconfig| 7 ++
> drivers/media/rc/img-ir/Makefile | 1 +
> drivers/media/rc/img-ir/img-ir-sharp.c | 115
> +
> 3 files changed, 123 insertions(+)
> create mode 100644 drivers/media/rc/img-ir/img-ir-sharp.c
>
> diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig
> index 38505188df0e..24e0966a3220 100644
> --- a/drivers/media/rc/img-ir/Kconfig
> +++ b/drivers/media/rc/img-ir/Kconfig
> @@ -45,3 +45,10 @@ config IR_IMG_SONY
> help
> Say Y or M here to enable support for the Sony protocol in the ImgTec
> infrared decoder block.
> +
> +config IR_IMG_SHARP
> + tristate "Sharp protocol support"
> + depends on IR_IMG && IR_IMG_HW
> + help
> +Say Y or M here to enable support for the Sharp protocol in the
> +ImgTec infrared decoder block.
> diff --git a/drivers/media/rc/img-ir/Makefile
> b/drivers/media/rc/img-ir/Makefile
> index f3e7cc4f32e4..3c3ab4f1a9f1 100644
> --- a/drivers/media/rc/img-ir/Makefile
> +++ b/drivers/media/rc/img-ir/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_IR_IMG) += img-ir.o
> obj-$(CONFIG_IR_IMG_NEC) += img-ir-nec.o
> obj-$(CONFIG_IR_IMG_JVC) += img-ir-jvc.o
> obj-$(CONFIG_IR_IMG_SONY)+= img-ir-sony.o
> +obj-$(CONFIG_IR_IMG_SHARP) += img-ir-sharp.o
> diff --git a/drivers/media/rc/img-ir/img-ir-sharp.c
> b/drivers/media/rc/img-ir/img-ir-sharp.c
> new file mode 100644
> index ..4d70abc088b4
> --- /dev/null
> +++ b/drivers/media/rc/img-ir/img-ir-sharp.c
> @@ -0,0 +1,115 @@
> +/*
> + * ImgTec IR Decoder setup for Sharp protocol.
> + *
> + * Copyright 2012-2013 Imagination Technologies Ltd.
> + */
> +
> +#include
> +
> +#include "img-ir-hw.h"
> +
> +/* Convert Sharp data to a scancode */
> +static int img_ir_sharp_scancode(int len, u64 raw, u64 protocols)
> +{
> + unsigned int addr, cmd, exp, chk;
> +
> + if (len != 15)
> + return IMG_IR_ERR_INVALID;
> +
> + addr = (raw >> 0) & 0x1f;
> + cmd = (raw >> 5) & 0xff;
> + exp = (raw >> 13) & 0x1;
> + chk = (raw >> 14) & 0x1;
> +
> + /* validate data */
> + if (!exp)
> + return IMG_IR_ERR_INVALID;
> + if (chk)
> + /* probably the second half of the message */
> + return IMG_IR_ERR_INVALID;
> +
> + return addr << 8 | cmd;
> +}
> +
> +/* Convert Sharp scancode to Sharp data filter */
> +static int img_ir_sharp_filter(const struct img_ir_sc_filter *in,
> +struct img_ir_filter *out, u64 protocols)
> +{
> + unsigned int addr, cmd, exp = 0, chk = 0;
> + unsigned int addr_m, cmd_m, exp_m = 0, chk_m = 0;
> +
> + addr = (in->data >> 8) & 0x1f;
> + addr_m = (in->mask >> 8) & 0x1f;
> + cmd= (in->data >> 0) & 0xff;
> + cmd_m = (in->mask >> 0) & 0xff;
> + if (cmd_m) {
> + /* if filtering commands, we can only match the first part */
> + exp = 1;
> + exp_m = 1;
> + chk = 0;
> + chk_m = 1;
> + }
> +
> + out->data = addr|
> + cmd << 5 |
> + exp << 13 |
> + chk << 14;
> + out->mask = addr_m |
> + cmd_m << 5 |
> + exp_m << 13 |
> + chk_m << 14;
> +
> + return 0;
> +}
> +
> +/*
> + * Sharp decoder
> + * See also http://www.sbprojects.com/knowledge/ir/sharp.php
> + */
> +static struct img_ir_decoder img_ir_sharp = {
> + .type = RC_BIT_SHARP,
> + .control = {
> + .decoden = 0,
> + .decodend2 = 1,
> + .code_type = IMG_IR_CODETYPE_PULSEDIST,
> + .d1validsel = 1,
> + },
> + /* main timings */
> + .timings = {
> + /* 0 symbol */
> + .s10 = {
> + .pulse = { 320 /* 320 us */ },
> + .space = { 680 /* 1 ms period */ },
> + },
> + /* 1 symbol */
> + .s11 = {
> + .pulse = { 320 /* 230 us */ },
> + .space = { 1680 /* 2 ms period */ },
> + },
> + /* free time */
> + .ft = {
> + .minlen = 15,
> + .maxlen = 15,
> + .ft_min = 5000, /* 5 ms */
> + },
> + },
> + /* scancode logic */
> + .scancode = img_ir_sharp_scancode,
> + .filter = img_ir_sharp_filter,
> +};
> +
> +static int __init img_ir_sharp_init(void
Re: em28xx DEADLOCK reported by lock debug
Am 21.12.2013 20:55, schrieb Antti Palosaari:
> On 21.12.2013 18:51, Frank Schäfer wrote:
>> Hi Antti,
>>
>> thank you for reporting this issue.
>>
>> Am 18.12.2013 17:04, schrieb Antti Palosaari:
>>> That same lock debug deadlock is still there (maybe ~4 times I report
>>> it during 2 years). Is that possible to fix easily at all?
>>
>> Patches are always welcome. ;)
>
> haha, I cannot simply learn every driver I meet some problems...
Hint:
If you report a bug ~4 times in 2 years but never get a reply, it
usually means
a) nobody cares
b) nobody has the resources (time, knowledge) to fix it.
So you either have to live with this issue or to fix it yourself.
>
> But now, when V4L2 SDR module was added RTL28xxU DVB module I see
> quite similar looking bug warning here too :
>
> I wonder if that is same...
>
>
> joulu 21 21:49:19 localhost.localdomain kernel: usb 2-2:
> rtl2832_sdr_queue_setup: nbuffers=32 sizes[0]=131072
> joulu 21 21:49:19 localhost.localdomain kernel: joulu 21 21:49:19
> localhost.localdomain kernel:
> ==
> joulu 21 21:49:19 localhost.localdomain kernel: [ INFO: possible
> circular locking dependency detected ]
> joulu 21 21:49:19 localhost.localdomain kernel: 3.13.0-rc1+ #77
> Tainted: G C O
> joulu 21 21:49:19 localhost.localdomain kernel:
> ---
> joulu 21 21:49:19 localhost.localdomain kernel: python/15284 is trying
> to acquire lock:
> joulu 21 21:49:19 localhost.localdomain kernel:
> (&s->vb_queue_lock){+.+.+.}, at: []
> vb2_fop_mmap+0x33/0x90 [videobuf2_core]
> joulu 21 21:49:19 localhost.localdomain kernel:
> but task is already
> holding lock:
> joulu 21 21:49:19 localhost.localdomain kernel:
> (&mm->mmap_sem){++}, at: [] vm_mmap_pgoff+0x6f/0xc0
> joulu 21 21:49:19 localhost.localdomain kernel:
> which lock already
> depends on the new lock.
> joulu 21 21:49:19 localhost.localdomain kernel:
> the existing
> dependency chain (in reverse order) is:
> joulu 21 21:49:19 localhost.localdomain kernel:
> -> #1
> (&mm->mmap_sem){++}:
> joulu 21 21:49:19 localhost.localdomain kernel: []
> __lock_acquire+0x3d6/0xc40
> joulu 21 21:49:19 localhost.localdomain kernel: []
> lock_acquire+0xb0/0x150
> joulu 21 21:49:19 localhost.localdomain kernel: []
> might_fault+0x8c/0xb0
> joulu 21 21:49:19 localhost.localdomain kernel: []
> video_usercopy+0xba/0x4e0 [videodev]
> joulu 21 21:49:19 localhost.localdomain kernel: []
> video_ioctl2+0x15/0x20 [videodev]
> joulu 21 21:49:19 localhost.localdomain kernel: []
> v4l2_ioctl+0x153/0x240 [videodev]
> joulu 21 21:49:19 localhost.localdomain kernel: []
> do_vfs_ioctl+0x300/0x520
> joulu 21 21:49:19 localhost.localdomain kernel: []
> SyS_ioctl+0x81/0xa0
> joulu 21 21:49:19 localhost.localdomain kernel: []
> system_call_fastpath+0x16/0x1b
> joulu 21 21:49:19 localhost.localdomain kernel:
> -> #0
> (&s->vb_queue_lock){+.+.+.}:
> joulu 21 21:49:19 localhost.localdomain kernel: []
> validate_chain.isra.36+0x10d7/0x1130
> joulu 21 21:49:19 localhost.localdomain kernel: []
> __lock_acquire+0x3d6/0xc40
> joulu 21 21:49:19 localhost.localdomain kernel: []
> lock_acquire+0xb0/0x150
> joulu 21 21:49:19 localhost.localdomain kernel: []
> mutex_lock_interruptible_nested+0x77/0x460
> joulu 21 21:49:19 localhost.localdomain kernel: []
> vb2_fop_mmap+0x33/0x90 [videobuf2_core]
> joulu 21 21:49:19 localhost.localdomain kernel: []
> v4l2_mmap+0x5a/0xa0 [videodev]
> joulu 21 21:49:19 localhost.localdomain kernel: []
> mmap_region+0x3cd/0x5a0
> joulu 21 21:49:19 localhost.localdomain kernel: []
> do_mmap_pgoff+0x357/0x3e0
> joulu 21 21:49:19 localhost.localdomain kernel: []
> vm_mmap_pgoff+0x90/0xc0
> joulu 21 21:49:19 localhost.localdomain kernel: []
> SyS_mmap_pgoff+0x1d3/0x270
> joulu 21 21:49:19 localhost.localdomain kernel: []
> SyS_mmap+0x22/0x30
> joulu 21 21:49:19 localhost.localdomain kernel: []
> system_call_fastpath+0x16/0x1b
> joulu 21 21:49:19 localhost.localdomain kernel:
> other info that might
> help us debug this:
> joulu 21 21:49:19 localhost.localdomain kernel: Possible unsafe
> locking scenario:
> joulu 21 21:49:19 localhost.localdomain kernel:CPU0CPU1
> joulu 21 21:49:19 localhost.localdomain kernel:
> joulu 21 21:49:19 localhost.localdomain kernel: lock(&mm->mmap_sem);
> joulu 21 21:49:19 localhost.localdomain kernel:
> lock(&s->vb_queue_lock);
> joulu 21 21:49:19 localhost.localdomain kernel:
> lock(&mm->mmap_sem);
> joulu 21 21:49:19 localhost.localdomain kernel:
> lock(&s->vb_queue_lock);
> joulu 21 21:49:19 localhost.localdomain kernel:
> *** D
Re: [PATCH 06/11] media: rc: img-ir: add NEC decoder module
Em Fri, 13 Dec 2013 15:12:54 +
James Hogan escreveu:
> Add an img-ir module for decoding the NEC and extended NEC infrared
> protocols.
>
> Signed-off-by: James Hogan
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> ---
> drivers/media/rc/img-ir/Kconfig | 7 ++
> drivers/media/rc/img-ir/Makefile | 1 +
> drivers/media/rc/img-ir/img-ir-nec.c | 149
> +++
> 3 files changed, 157 insertions(+)
> create mode 100644 drivers/media/rc/img-ir/img-ir-nec.c
>
> diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig
> index 60eaba6a0843..44d00227c6c4 100644
> --- a/drivers/media/rc/img-ir/Kconfig
> +++ b/drivers/media/rc/img-ir/Kconfig
> @@ -24,3 +24,10 @@ config IR_IMG_HW
> signals in hardware. This is more reliable, consumes less processing
> power since only a single interrupt is received for each scancode,
> and allows an IR scancode to be used as a wake event.
> +
> +config IR_IMG_NEC
> + tristate "NEC protocol support"
> + depends on IR_IMG && IR_IMG_HW
> + help
> +Say Y or M here to enable support for the NEC and extended NEC
> +protocols in the ImgTec infrared decoder block.
> diff --git a/drivers/media/rc/img-ir/Makefile
> b/drivers/media/rc/img-ir/Makefile
> index 4ef86edec873..f3052878f092 100644
> --- a/drivers/media/rc/img-ir/Makefile
> +++ b/drivers/media/rc/img-ir/Makefile
> @@ -4,3 +4,4 @@ img-ir-$(CONFIG_IR_IMG_HW)+= img-ir-hw.o
> img-ir-objs := $(img-ir-y)
>
> obj-$(CONFIG_IR_IMG) += img-ir.o
> +obj-$(CONFIG_IR_IMG_NEC) += img-ir-nec.o
> diff --git a/drivers/media/rc/img-ir/img-ir-nec.c
> b/drivers/media/rc/img-ir/img-ir-nec.c
> new file mode 100644
> index ..ba376caafaf2
> --- /dev/null
> +++ b/drivers/media/rc/img-ir/img-ir-nec.c
> @@ -0,0 +1,149 @@
> +/*
> + * ImgTec IR Decoder setup for NEC protocol.
> + *
> + * Copyright 2010-2013 Imagination Technologies Ltd.
> + */
> +
> +#include
> +
> +#include "img-ir-hw.h"
> +
> +/* Convert NEC data to a scancode */
> +static int img_ir_nec_scancode(int len, u64 raw, u64 protocols)
> +{
> + unsigned int addr, addr_inv, data, data_inv;
> + int scancode;
> + /* a repeat code has no data */
> + if (!len)
> + return IMG_IR_REPEATCODE;
> + if (len != 32)
> + return IMG_IR_ERR_INVALID;
> + addr = (raw >> 0) & 0xff;
> + addr_inv = (raw >> 8) & 0xff;
> + data = (raw >> 16) & 0xff;
> + data_inv = (raw >> 24) & 0xff;
> + /* Validate data */
> + if ((data_inv ^ data) != 0xff)
> + return IMG_IR_ERR_INVALID;
> +
> + if ((addr_inv ^ addr) != 0xff) {
> + /* Extended NEC */
> + scancode = addr << 16 |
> +addr_inv << 8 |
> +data;
> + } else {
> + /* Normal NEC */
> + scancode = addr << 8 |
> +data;
> + }
There are some types of NEC extended that uses the full 32 bits as
scancodes. Those are used at least on Apple and TiVo remote controllers.
> + return scancode;
> +}
> +
> +/* Convert NEC scancode to NEC data filter */
> +static int img_ir_nec_filter(const struct img_ir_sc_filter *in,
> + struct img_ir_filter *out, u64 protocols)
> +{
> + unsigned int addr, addr_inv, data, data_inv;
> + unsigned int addr_m, addr_inv_m, data_m;
> +
> + data = in->data & 0xff;
> + data_m = in->mask & 0xff;
> + data_inv = data ^ 0xff;
> +
> + if (in->data & 0xff00)
> + return -EINVAL;
> +
> + if (in->data & 0x00ff) {
> + /* Extended NEC */
> + addr = (in->data >> 16) & 0xff;
> + addr_m = (in->mask >> 16) & 0xff;
> + addr_inv = (in->data >> 8) & 0xff;
> + addr_inv_m = (in->mask >> 8) & 0xff;
> + } else {
> + /* Normal NEC */
> + addr = (in->data >> 8) & 0xff;
> + addr_m = (in->mask >> 8) & 0xff;
> + addr_inv = addr ^ 0xff;
> + addr_inv_m = addr_m;
> + }
> +
> + out->data = data_inv << 24 |
> + data << 16 |
> + addr_inv << 8 |
> + addr;
> + out->mask = data_m << 24 |
> + data_m << 16 |
> + addr_inv_m << 8 |
> + addr_m;
> + return 0;
> +}
> +
> +/*
> + * NEC decoder
> + * See also http://www.sbprojects.com/knowledge/ir/nec.php
> + *
> http://wiki.altium.com/display/ADOH/NEC+Infrared+Transmission+Protocol
> + */
> +static struct img_ir_decoder img_ir_nec = {
> + .type = RC_BIT_NEC,
> + .control = {
> + .decoden = 1,
> + .code_type = IMG_IR_CODETYPE_PULSEDIST,
> + },
> + /* main timings */
> + .unit = 562500, /* 562.5 us */
> + .timings = {
> + /* lead
Re: [PATCH 04/11] media: rc: img-ir: add hardware decoder driver
Hi James,
Em Fri, 13 Dec 2013 15:12:52 +
James Hogan escreveu:
> Add remote control input driver for the ImgTec Infrared block hardware
> decoder, which is set up with timings for a specific protocol and
> supports mask/value filtering and wake events.
>
> The hardware decoder timing values, raw data to scan code conversion
> function and scan code filter to raw data filter conversion function are
> provided as separate modules for each protocol which this part of the
> driver can use. The scan code filter value and mask (and the same again
> for wake from sleep) are specified via sysfs files in
> /sys/class/rc/rcX/.
We should discuss a little more about those new sysfs controls.
There are two separate questions here:
1) are those new sysfs controls really device specific? If not, then it
makes sense to add support for it at rc-core.
I suspect that a wakeup scancode is something that should be part of the
RC core, as other devices may have it too.
Also, the RC core currently supports a scancode mask. Not sure if it is
the same concept as the one used on your hardware. Could you please
explain it better?
2) Where those new sysfs nodes will be documented.
With regards to (2), we currently lack a chapter at the Linux Media
Documentation/DocBook or at Documentation/ABI/ for the existing sysfs
interface, but let's not increase the gap, please.
I'll see if I can find some time to write such documentation, probably
at Documentation/ABI/testing.
So, if we come to the conclusion that those interfaces should be part
of the rc core, we'll need them to be documented at
Documentation/ABI/testing too.
Otherwise, if we decide to add some of those as private API, please
add a README for this device, under Documentation/remote-controllers.
The patch itself (and patches 1-3) look OK to me. I'll be reviewing
the other patches on separate emails.
>
> Signed-off-by: James Hogan
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> ---
> drivers/media/rc/img-ir/img-ir-hw.c | 1277
> +++
> drivers/media/rc/img-ir/img-ir-hw.h | 284
> 2 files changed, 1561 insertions(+)
> create mode 100644 drivers/media/rc/img-ir/img-ir-hw.c
> create mode 100644 drivers/media/rc/img-ir/img-ir-hw.h
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> new file mode 100644
> index ..917d9a076a8c
> --- /dev/null
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -0,0 +1,1277 @@
> +/*
> + * ImgTec IR Hardware Decoder found in PowerDown Controller.
> + *
> + * Copyright 2010-2013 Imagination Technologies Ltd.
> + *
> + * This ties into the input subsystem using the RC-core. Protocol support is
> + * provided in separate modules which provide the parameters and scancode
> + * translation functions to set up the hardware decoder and interpret the
> + * resulting input.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "img-ir.h"
> +
> +/* Decoder list */
> +static DEFINE_SPINLOCK(img_ir_decoders_lock);
> +static struct img_ir_decoder *img_ir_decoders;
> +static struct img_ir_priv *img_ir_privs;
> +
> +#define IMG_IR_F_FILTER 0x0001 /* enable filtering */
> +#define IMG_IR_F_WAKE0x0002 /* enable waking */
> +
> +/* code type quirks */
> +
> +#define IMG_IR_QUIRK_CODE_BROKEN 0x1 /* Decode is broken */
> +#define IMG_IR_QUIRK_CODE_LEN_INCR 0x2 /* Bit length needs increment */
> +
> +/* functions for preprocessing timings, ensuring max is set */
> +
> +static void img_ir_timing_preprocess(struct img_ir_timing_range *range,
> + unsigned int unit)
> +{
> + if (range->max < range->min)
> + range->max = range->min;
> + if (unit) {
> + /* multiply by unit and convert to microseconds */
> + range->min = (range->min*unit)/1000;
> + range->max = (range->max*unit + 999)/1000; /* round up */
> + }
> +}
> +
> +static void img_ir_symbol_timing_preprocess(struct img_ir_symbol_timing
> *timing,
> + unsigned int unit)
> +{
> + img_ir_timing_preprocess(&timing->pulse, unit);
> + img_ir_timing_preprocess(&timing->space, unit);
> +}
> +
> +static void img_ir_timings_preprocess(struct img_ir_timings *timings,
> + unsigned int unit)
> +{
> + img_ir_symbol_timing_preprocess(&timings->ldr, unit);
> + img_ir_symbol_timing_preprocess(&timings->s00, unit);
> + img_ir_symbol_timing_preprocess(&timings->s01, unit);
> + img_ir_symbol_timing_preprocess(&timings->s10, unit);
> + img_ir_symbol_timing_preprocess(&timings->s11, unit);
> + /* default s10 and s11 to s00 and s01 if no leader */
> + if (unit)
> + /* multiply by unit and convert to microseconds (round up) */
> + timings->ft.ft_min = (timings->ft.ft_min*unit + 999)/1000;
> +}
>
Re: [PATCH 01/11] dt: binding: add binding for ImgTec IR block
Hi James, On Friday 13 of December 2013 15:12:49 James Hogan wrote: > Add device tree binding for ImgTec Consumer Infrared block. > > Signed-off-by: James Hogan > Cc: Mauro Carvalho Chehab > Cc: linux-media@vger.kernel.org > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Stephen Warren > Cc: Ian Campbell > Cc: devicet...@vger.kernel.org > Cc: Rob Landley > Cc: linux-...@vger.kernel.org > --- > Documentation/devicetree/bindings/media/img-ir.txt | 20 > 1 file changed, 20 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/img-ir.txt > > diff --git a/Documentation/devicetree/bindings/media/img-ir.txt > b/Documentation/devicetree/bindings/media/img-ir.txt > new file mode 100644 > index ..6f623b094ea6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/img-ir.txt > @@ -0,0 +1,20 @@ > +* ImgTec Infrared (IR) decoder > + > +Required properties: > +- compatible:Should be "img,ir" This compatible string isn't really very specific. Is there some IP revision string that could be added, to account for possible design changes that may require binding change? > +- reg: Physical base address of the controller and > length of > + memory mapped region. > +- interrupts:The interrupt specifier to the cpu. > + > +Optional properties: > +- clocks:Clock specifier for base clock. > + Defaults to 32.768KHz if not specified. To make the binding less fragile and allow interoperability with non-DT platforms it may be better to provide also clock-names property (so you can use clk_get(); that's a Linux implementation detail, though, but to make our lives easier IMHO they should be sometimes considered too). Best regards, Tomasz -- 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 01/11] dt: binding: add binding for ImgTec IR block
Em Fri, 13 Dec 2013 15:12:49 +
James Hogan escreveu:
> Add device tree binding for ImgTec Consumer Infrared block.
>
> Signed-off-by: James Hogan
> Cc: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Stephen Warren
> Cc: Ian Campbell
> Cc: devicet...@vger.kernel.org
> Cc: Rob Landley
> Cc: linux-...@vger.kernel.org
It looks ok for me, but we should wait for a DT maintainer ack for
this one.
Regards,
Mauro
> ---
> Documentation/devicetree/bindings/media/img-ir.txt | 20
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/img-ir.txt
>
> diff --git a/Documentation/devicetree/bindings/media/img-ir.txt
> b/Documentation/devicetree/bindings/media/img-ir.txt
> new file mode 100644
> index ..6f623b094ea6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/img-ir.txt
> @@ -0,0 +1,20 @@
> +* ImgTec Infrared (IR) decoder
> +
> +Required properties:
> +- compatible:Should be "img,ir"
> +- reg: Physical base address of the controller and
> length of
> + memory mapped region.
> +- interrupts:The interrupt specifier to the cpu.
> +
> +Optional properties:
> +- clocks:Clock specifier for base clock.
> + Defaults to 32.768KHz if not specified.
> +
> +Example:
> +
> + ir@02006200 {
> + compatible = "img,ir";
> + reg = <0x02006200 0x100>;
> + interrupts = <29 4>;
> + clocks = <&clk_32khz>;
> + };
--
Cheers,
Mauro
--
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
omap4 pandaboard - Technisat USB HD problem
subscribe linux-media Hello there, theres some trouble with technisat DVBS/S2 USB HD on pandaboard. My system: ubuntu 3.2.0-1441-omap4 media_build is installed and firmware dvb-usb-SkyStar_USB_HD_FW_v17_63.HEX.fw is at /lib/firmware. With all debugging options enabled dmesg sais the following if I remove the stick and reconnect it: [ 7934.843811] dvb_usb_technisat_usb2 1-1.2.5:1.0: usb_probe_interface [ 7934.843841] dvb_usb_technisat_usb2 1-1.2.5:1.0: usb_probe_interface - got id [ 7934.843872] check for cold 14f7 500 [ 7934.844696] technisat-usb2: set alternate setting [ 7934.844970] technisat-usb2: firmware version: 17.63 [ 7934.844970] dvb-usb: found a 'Technisat SkyStar USB HD (DVB-S/S2)' in warm state. [ 7934.845001] power control: 1 [ 7934.852355] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 7934.861267] state before exiting everything: 1 [ 1592.359924] all in all I will use 524288 bytes for streaming [ 1592.359954] allocating buffer 0 [ 1592.360321] buffer 0: ffc3 (dma: 2813526016) [ 1592.360382] allocating buffer 1 [ 1592.360717] buffer 1: ffc2 (dma: 2806579200) [ 1592.360778] allocating buffer 2 [ 1592.361206] buffer 2: ffc1 (dma: 2813394944) [ 1592.361267] allocating buffer 3 [ 1592.361755] buffer 3: ffc0 (dma: 2815033344) [ 1592.361846] allocating buffer 4 [ 1592.362792] not enough memory for urb-buffer allocation. [ 1592.362792] freeing buffer 3 [ 1592.362823] freeing buffer 2 [ 1592.362854] freeing buffer 1 [ 1592.362884] freeing buffer 0 [ 1592.362915] state before exiting everything: 1 [ 1592.363128] state should be zero now: 0 [ 1592.363128] dvb-usb: Technisat SkyStar USB HD (DVB-S/S2) error while loading driver (-12) [ 7934.861846] usbcore: registered new interface driver dvb_usb_technisat_usb2 [ 7947.469573] hub 1-1.2:1.0: state 7 ports 5 chg evt 0020 [ 7947.470428] hub 1-1.2:1.0: port 5, status 0100, change 0001, 12 Mb/s [ 7947.470916] usb 1-1.2.5: USB disconnect, device number 10 [ 7947.470947] usb 1-1.2.5: unregistering device [ 7947.470947] usb 1-1.2.5: unregistering interface 1-1.2.5:1.0 [ 7947.471405] usb 1-1.2.5: usb_disable_device nuking all URBs [ 7947.631744] hub 1-1.2:1.0: debounce: port 5: total 100ms stable 100ms status 0x100 [ 7949.005615] hub 1-1.2:1.0: state 7 ports 5 chg evt 0020 [ 7949.006683] hub 1-1.2:1.0: port 5, status 0101, change 0001, 12 Mb/s [ 7949.162841] hub 1-1.2:1.0: debounce: port 5: total 100ms stable 100ms status 0x101 [ 7949.248687] usb 1-1.2.5: new high-speed USB device number 11 using ehci-omap [ 7949.366424] usb 1-1.2.5: default language 0x0409 [ 7949.367156] usb 1-1.2.5: udev 11, busnum 1, minor = 10 [ 7949.367187] usb 1-1.2.5: New USB device found, idVendor=14f7, idProduct=0500 [ 7949.367187] usb 1-1.2.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [...] same as above The device has to be handled as USB 2.0 to work correctly.. =>[ 7949.248687] usb 1-1.2.5: new high-speed USB device number 11 using ehci-omap looks good, but => [ 7947.470428] hub 1-1.2:1.0: port 5, status 0100, change 0001, 12 Mb/s is too slow or ? But /usr/bin/usb-devices tells me that the device is on 480Mb/s speed.. The hub: T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 5 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=2101 ProdID=8500 Rev=01.06 S: Manufacturer=Action Star S: Product=USB2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub The stick: T: Bus=01 Lev=03 Prnt=04 Port=04 Cnt=05 Dev#= 11 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=14f7 ProdID=0500 Rev=00.01 S: Manufacturer=TechniSat Digital S: Product=TechniSat USB device S: SerialNumber=0008C9F0B853 C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=300mA I: If#= 0 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) What I could do to get this working ? I dont know where to search anymore.. Regards - Christian Löpke - -- 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
