Hello Akinobu,
thank you for the patch.
On which platform have you tested the series (just curious) ?
On Sun, Apr 08, 2018 at 12:48:05AM +0900, Akinobu Mita wrote:
> The ov772x driver only works when the i2c controller have
> I2C_FUNC_PROTOCOL_MANGLING. However, many i2c controller drivers d
Nachricht des Absenders:
/Guten Morgen,
Bitte schämen Sie sich nicht, diese Nachricht zu lesen, weil Sie der
beabsichtigte Empfänger sind. Ich habe deine E-Mail-Adresse über ein
Verzeichnis gesehen und ich habe dich kontaktiert, weil ich dringend deine
Hilfe benötigt habe. Mein Name ist Frau Yorda
Hi Hugo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-
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 Apr 9 05:00:11 CEST 2018
media-tree git hash:17dec0a949153d9ac00760ba2f5b78cb583e995f
media_build gi
The user-supplied norm value gets overwritten by the generic .norm
member from the norm_params. That way, we lose the specific norm the
user may want to set.
For instance, if the user specifies V4L2_STD_PAL_60, the value actually
used will be V4L2_STD_525_60, which in the end will be as if the use
Depending on the chosen standard, configure the decoder to use the
appropriate color encoding standard (PAL-like, NTSC-like or SECAM).
Until now, the decoder was not configured for a specific color standard,
making it autodetect the color encoding.
While this may sound fine, it potentially causes
Add support for the SECAM norm, using the "AVSECAM" decoder configuration
sequence found in Windows driver's .INF file.
For reference, the "AVSECAM" sequence in the .INF file is:
0x04,0x73,0xDC,0x72,0xA2,0x90,0x35,0x01,0x30,0x04,0x08,0x2D,0x28,0x08,
0x02,0x69,0x16,0x35,0x21,0x16,0x36
Signed-off-b
Use the USBTV_TV_STD define instead of repeating ourselves.
Signed-off-by: Hugo Grostabussiat
---
drivers/media/usb/usbtv/usbtv-video.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv-video.c
b/drivers/media/usb/usbtv/usbtv-video.c
index d0bf5
Re-format the register {address, value} pairs so they follow the same
order as the decoder configuration sequences in the Windows driver's .INF
file.
For instance, for PAL, the "AVPAL" sequence in the .INF file is:
0x04,0x68,0xD3,0x72,0xA2,0xB0,0x15,0x01,0x2C,0x10,0x20,0x2e,0x08,0x02,
0x02,0x59,0x
Make use of the V4L2_STD_525_60 and V4L2_STD_625_50 defines to
determine the vertical resolution to use when capturing.
V4L2_STD_525_60 (resp. V4L2_STD_625_50) is the set of standards using
525 (resp. 625) lines per frame, independently of the color encoding.
Signed-off-by: Hugo Grostabussiat
--
This series adds SECAM support to the usbtv driver, while
also attempting to mimic the Windows driver's behavior
regarding color encoding selection.
I made USB captures of the device as it is set up by the Windows driver,
for all the supported video standards. The analog source used is the
composi
The mce keyboard repeats pressed keys every 100ms. If the IR timeout
is set to less than that, we send key up events before the repeat
arrives, so we have key up/key down for each IR repeat.
The keyboard ends any sequence with a 0 scancode, in which case all keys
are cleared so there is no need to
mceusb devices have a default timeout of 100ms, but this can be changed.
Signed-off-by: Sean Young
---
drivers/media/rc/mceusb.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 69ba57372c05..c97cb2eb1c5f 1006
Since the kernel now modifies the timeout, make it possible to retrieve
the current value.
Signed-off-by: Sean Young
---
Documentation/media/uapi/rc/lirc-func.rst| 1 +
Documentation/media/uapi/rc/lirc-set-rec-timeout.rst | 14 +-
drivers/media/rc/lirc_dev.c
If two keys are pressed, then both keys are encoded in the scancode. This
makes the mce keyboard more responsive.
Signed-off-by: Sean Young
---
drivers/media/rc/ir-mce_kbd-decoder.c | 21 -
drivers/media/rc/rc-main.c| 2 +-
2 files changed, 13 insertions(+), 10 d
The MCE Remote sends a 0 scancode when keys are released. If this is not
received or decoded, then keys can get "stuck"; the keyup event is not
sent since the input_sync() is missing from the timeout handler.
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Young
---
drivers/media/rc/ir-mce_kbd-de
The longer the IR timeout, the longer the rc device waits until delivering
the trailing space. So, by reducing this timeout, we reduce the delay for
the last scancode to be delivered.
Note that the lirc daemon disables all protocols, in which case we revert
back to the default value.
Signed-off-b
Each IR protocol has its own repeat period. We can minimise the keyup
timer to be the protocol period + IR timeout. This makes keys less
"sticky" and makes IR more reactive and nicer to use.
This feature was previously attempted in commit d57ea877af38 ("media: rc:
per-protocol repeat period"), but
The current IR decoding is much too slow. Many IR protocols rely on
a trailing space for decoding (e.g. rc-6 needs to know when the bits
end). The trailing space is generated by the IR timeout, and if this
is longer than required, buttons can feel slow to respond.
The other issue is the keyup time
I created a report of the issue in Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=199323
I'd be grateful for any tips on how to debug this further.
Cheers,
-olli
On 4 April 2018 at 14:41, Olli Salonen wrote:
> Hello Peter and Max,
>
> I noticed that when using kernel 4.10 or newer my DVB
From: Akihiro Tsukada
The tuner is used in Earthsoft PT1/PT2 DVB boards,
and the driver was extraced from (the former) va1j5jf8007s.c of PT1.
it might contain PT1 specific configs.
Signed-off-by: Akihiro Tsukada
---
Changes since v2:
- none
Changes since v1:
- none
drivers/media/tuners/Kcon
From: Akihiro Tsukada
This patch adds a PLL "description" of Philips TDA6651 for ISDB-T.
It was extracted from (the former) va1j5jf8007t.c of EarthSoft PT1,
thus the desc might include PT1 specific configs.
Signed-off-by: Akihiro Tsukada
---
Changes since v2:
- do not #define chip name constant
From: Akihiro Tsukada
earth-pt1 was a monolithic module and included demod/tuner drivers.
This patch removes those FE parts and attach demod/tuner i2c drivers.
Signed-off-by: Akihiro Tsukada
---
Changes since v2:
- specify tuner chip name literally
Changes since v1:
- use i2c_board_info.name
From: Akihiro Tsukada
Without this patch, re-loading of the module was required after resume.
Signed-off-by: Akihiro Tsukada
---
Changes since v2:
- none
Changes since v1:
- none
drivers/media/pci/pt1/pt1.c | 107 +++-
1 file changed, 105 insertions(+), 2 dele
From: Akihiro Tsukada
As described in Document/timers/timers-howto.txt,
hrtimer-based delay should be used for small sleeps.
Signed-off-by: Akihiro Tsukada
---
Changes since v2:
- none
Changes since v1:
- none
drivers/media/pci/pt1/pt1.c | 34 +++---
1 file change
From: Akihiro Tsukada
Changes since v2:
- dvb-pll,pt1: do not #define chip name constants and use string literals
Changes since v1:
- use new style of specifying pll_desc of the terrestrial tuner
Akihiro Tsukada (5):
dvb-frontends/dvb-pll: add tda6651 ISDB-T pll_desc
tuners: add new i2c dri
From: Akihiro Tsukada
As the kernel doc "timers-howto.txt" reads,
short delay with msleep() can take much longer.
In a case of raspbery-pi platform where CONFIG_HZ_100 was set,
it actually affected the init of Friio devices
since it issues lots of i2c transactions with short delay.
Signed-off-by
From: Akihiro Tsukada
registers the module as an i2c driver,
but keeps dvb_pll_attach() untouched for compatibility.
Signed-off-by: Akihiro Tsukada
---
Changes since v4:
- do not #define chip name constants
Changes since v3:
- use standard i2c_device_id instead of dvb_pll_config
drivers/medi
From: Akihiro Tsukada
i2c message buf might be on stack.
Signed-off-by: Akihiro Tsukada
---
Changes since v4:
- none
drivers/media/usb/dvb-usb-v2/gl861.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c
b/drivers/m
From: Akihiro Tsukada
This driver already contains tua6034-based device settings,
but they are not for ISDB-T and have different parameters.
Signed-off-by: Akihiro Tsukada
---
Changes since v4:
- do not #define chip name constant
Changes since v3:
- rebase on the new style of specifying pll_de
From: Akihiro Tsukada
Friio device contains "gl861" bridge and "tc90522" demod,
for which the separate drivers are already in the kernel.
But friio driver was monolithic and did not use them,
practically copying those features.
This patch decomposes friio driver into sub drivers and
re-uses exist
From: Akihiro Tsukada
This series decomposes dvb-usb-friio into sub drivers
and merge the bridge driver with dvb-usb-gl861.
As to the demod & tuner drivers, existing drivers are re-used.
Changes since v4:
- dvb-pll,gl861: do not #define chip name constants
- i2c algo of gl861 is not (yet?) chang
From: Niklas Söderlund
s/dose/does/
Fixes: d295c6a460cd2ac6 ("[media] media: entity: Add
media_entity_get_fwnode_pad() function")
Signed-off-by: Niklas Söderlund
---
include/media/media-entity.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/media/media-entity.h b
Thank you for sending this patch.
Am 24.03.2018 um 15:01 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> Structure i2c_driver does not need to set the owner field, as this will
> be populated by the driver core.
>
> Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
>
> Cc: Matt
Am 05.04.2018 um 19:54 schrieb Mauro Carvalho Chehab:
> Drivers that depend on omap-iommu.h (currently, just omap3isp)
> need a stub implementation in order to be built with COMPILE_TEST.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> include/linux/omap-iommu.h | 5 +
> 1 file changed, 5 i
35 matches
Mail list logo
