Re: [PATCH v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
Moi!
Yes, using the I2C binding way provides a better decoupling than using the
legacy way. The current dvb_attach() macros are hacks that were created
by the time where the I2C standard bind didn't work with DVB.
I understand. I converted my code to use i2c binding model,
but I'm uncertain about a few things.
1. How to load the modules of i2c driver?
Currently I use request_module()/module_put()
like an example (ddbrige-core.c) from Antti does,
but I'd prefer implicit module loading/ref-counting
like in dvb_attach() if it exists.
2. Is there a standard way to pass around dvb_frontend*, i2c_client*,
regmap* between bridge(dvb_adapter) and demod/tuner drivers?
Currently I use config structure for the purpose, which is set to
dev.platform_data (via i2c_board_info/i2c_new_device()) or
dev.driver_data (via i2c_{get,set}_clientdata()),
but using config as both IN/OUT looks a bit hacky.
3. Should I also use RegMap API for register access?
I tried using it but gave up,
because it does not fit well to one of my use-case,
where (only) reads must be done via 0xfb register, like
READ(reg, buf, len) - [addr/w, 0xfb, reg], [addr/r, buf[0]...],
WRITE(reg, buf, len) - [addr/w, reg, buf[0]...],
and regmap looked to me overkill for 8bit-reg, 8bit-val cases
and did not simplify the code.
so I'd like to go without RegMap if possible,
since I'm already puzzled enough by I2C binding, regmap, clock source,
as well as dvb-core, PCI ;)
regards,
Akihiro
--
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 v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
Moikka!, thanks for the comments and advices. I had been updating my code and during that, I also found that updating property cache in tuner_ops.get_signal_strength() was simple and (seemed to me) better than using a kthread, so the current implementation (under testing) is just like what Mauro proposed, but, In time: not implementing its own thread has one drawback: the driver needs to check if the minimal time needed to get a new stats were already archived. since I don't know the minimal time and whether there's a limit in the first place, I'd like to let users take the responsibility. ... I simply don't understand why you want hook that RF strength call via demod? The frontend cache is shared between demod and tuner. We use it for tuner drivr as well demod driver. Let the tuner driver make RSSI calculation independently without any unneeded relation to demod driver. I think the main reason for the hook is because the dvb-core calls ops.get_frontend() everytime before reading of any property cache, so it is already a nice place to trigger property updates, and reading any property involves demod (FE as a whole) anyway. regards, akihiro -- 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 v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
moikka!
On 09/06/2014 09:09 AM, Akihiro TSUKADA wrote:
Moi!
Yes, using the I2C binding way provides a better decoupling than using the
legacy way. The current dvb_attach() macros are hacks that were created
by the time where the I2C standard bind didn't work with DVB.
I understand. I converted my code to use i2c binding model,
but I'm uncertain about a few things.
1. How to load the modules of i2c driver?
Currently I use request_module()/module_put()
like an example (ddbrige-core.c) from Antti does,
but I'd prefer implicit module loading/ref-counting
like in dvb_attach() if it exists.
Maybe I haven't found the best way yet, but that was implementation I
made for AF9035 driver:
https://patchwork.linuxtv.org/patch/25764/
Basically it is 2 functions, af9035_add_i2c_dev() and af9035_del_i2c_dev()
2. Is there a standard way to pass around dvb_frontend*, i2c_client*,
regmap* between bridge(dvb_adapter) and demod/tuner drivers?
Currently I use config structure for the purpose, which is set to
dev.platform_data (via i2c_board_info/i2c_new_device()) or
dev.driver_data (via i2c_{get,set}_clientdata()),
but using config as both IN/OUT looks a bit hacky.
In my understanding, platform_data is place to pass environment specific
config to driver. get/set client_data() is aimed to carry pointer for
device specific instance state inside a driver. Is it possible to set
I2C client data before calling i2c_new_device() and pass pointer to driver?
There is also IOCTL style command for I2C, but it is legacy and should
not be used.
Documentation/i2c/busses/i2c-ocores
Yet, using config to OUT seems to be bit hacky for my eyes too. I though
replacing all OUT with ops when converted af9033 driver. Currently
caller fills struct af9033_ops and then af9033 I2C probe populates ops.
See that patch:
https://patchwork.linuxtv.org/patch/25746/
Does this kind of ops sounds any better?
EXPORT_SYMBOL() is easiest way to offer outputs, like
EXPORT_SYMBOL(get_frontend), EXPORT_SYMBOL(get_i2c_adapter). But we want
avoid those exported symbols.
3. Should I also use RegMap API for register access?
I tried using it but gave up,
because it does not fit well to one of my use-case,
where (only) reads must be done via 0xfb register, like
READ(reg, buf, len) - [addr/w, 0xfb, reg], [addr/r, buf[0]...],
WRITE(reg, buf, len) - [addr/w, reg, buf[0]...],
and regmap looked to me overkill for 8bit-reg, 8bit-val cases
and did not simplify the code.
so I'd like to go without RegMap if possible,
since I'm already puzzled enough by I2C binding, regmap, clock source,
as well as dvb-core, PCI ;)
I prefer RegMap API, but I am only one who has started using it yet. And
I haven't converted any demod driver having I2C bus/gate/repeater for
tuner to that API. It is because of I2C locking with I2C mux adapter,
you need use unlocked version of i2c_transfer() for I2C mux as I2C bus
lock is already taken. RegMap API does not support that, but I think it
should be possible if you implement own xfer callback for regmap. For RF
tuners RegMap API should be trivial and it will reduce ~100 LOC from driver.
But if you decide avoid RegMap API, I ask you add least implementing
those I2C read / write function parameters similarly than RegMap API
does. Defining all kind of weird register write / read functions makes
life harder. I converted recently IT913x driver to RegMap API and
biggest pain was there very different register read / write routines. So
I need to do a lot of work in order convert functions first some common
style and then it was trivial to change RegMap API.
https://patchwork.linuxtv.org/patch/25766/
https://patchwork.linuxtv.org/patch/25757/
I quickly overlooked that demod driver and one which looked crazy was
LNA stuff. You implement set_lna callback in demod, but it is then
passed back to PCI driver using frontend callback. Is there some reason
you hooked it via demod? You could implement set_lna in PCI driver too.
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 v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
On 09/06/2014 09:09 AM, Akihiro TSUKADA wrote: 3. Should I also use RegMap API for register access? I tried using it but gave up, because it does not fit well to one of my use-case, where (only) reads must be done via 0xfb register, like READ(reg, buf, len) - [addr/w, 0xfb, reg], [addr/r, buf[0]...], WRITE(reg, buf, len) - [addr/w, reg, buf[0]...], and regmap looked to me overkill for 8bit-reg, 8bit-val cases and did not simplify the code. so I'd like to go without RegMap if possible, since I'm already puzzled enough by I2C binding, regmap, clock source, as well as dvb-core, PCI ;) That is MaxLinear MxL301RF tuner I2C. Problem is there that it uses write + STOP + write, so you should not even do that as a one I2C i2c_transfer. All I2C messages send using i2c_transfer are send so called REPEATED START condition. I ran that same problem ears ago in a case of, surprise, MxL5007 tuner. https://patchwork.linuxtv.org/patch/17847/ I think you could just write wanted register to command register 0xfb. And after that all the reads are coming from that active register until you change it. RegMap API cannot handle I2C command format like that, it relies repeated start for reads. Si2157 / Si2168 are using I2C access with STOP condition - but it is otherwise bad example as there is firmware API, not register API. Look still as a example. 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
Framerate is consistently divided by 2.5
Hi, After patching the kernel, the rate that images are captured from the camera reduce by a factor of 2.5. Here are a list of frame rates I have tried followed by the resulted frame-rate: 10 fps -- 4 fps 15 fps -- 6 fps 25 fps -- 10 fps 30 fps -- 12 fps Note that all of the rates are consistently divided by 2.5. This seems to be a clocking issue to me. Is there any multipliers in V4L2 (or UVC?) code in framerate calculation which depends on the hardware and be cause of this? Bests, Isaac -- 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 v2] hackrf: HackRF SDR driver
V4L2 driver for HackRF SDR. Very basic version, with reduced
feature set. Driver implements receiver only, hardware supports
also transmitter.
USB ID 1d50:6089. Model HackRF One
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Changes in v2:
* renamed state 's' = 'dev'
* do not init spin_lock_irqsave() flags as it has no meaning
* remove unneeded error check from buf_queue
* comment fix remove mention of capt_file
* some minor issues reported by checkpatch.pl
---
drivers/media/usb/Kconfig |3 +-
drivers/media/usb/Makefile|3 +-
drivers/media/usb/hackrf/Kconfig | 10 +
drivers/media/usb/hackrf/Makefile |1 +
drivers/media/usb/hackrf/hackrf.c | 1142 +
5 files changed, 1157 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/usb/hackrf/Kconfig
create mode 100644 drivers/media/usb/hackrf/Makefile
create mode 100644 drivers/media/usb/hackrf/hackrf.c
diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig
index d6e8edc..056181f 100644
--- a/drivers/media/usb/Kconfig
+++ b/drivers/media/usb/Kconfig
@@ -56,8 +56,9 @@ endif
if MEDIA_SDR_SUPPORT
comment Software defined radio USB devices
-source drivers/media/usb/msi2500/Kconfig
source drivers/media/usb/airspy/Kconfig
+source drivers/media/usb/hackrf/Kconfig
+source drivers/media/usb/msi2500/Kconfig
endif
endif #MEDIA_USB_SUPPORT
diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile
index b5b645b..6f2eb7c 100644
--- a/drivers/media/usb/Makefile
+++ b/drivers/media/usb/Makefile
@@ -9,8 +9,9 @@ obj-y += zr364xx/ stkwebcam/ s2255/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_USB_GSPCA) += gspca/
obj-$(CONFIG_USB_PWC) += pwc/
-obj-$(CONFIG_USB_MSI2500) += msi2500/
obj-$(CONFIG_USB_AIRSPY)+= airspy/
+obj-$(CONFIG_USB_HACKRF)+= hackrf/
+obj-$(CONFIG_USB_MSI2500) += msi2500/
obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_VIDEO_HDPVR) += hdpvr/
diff --git a/drivers/media/usb/hackrf/Kconfig b/drivers/media/usb/hackrf/Kconfig
new file mode 100644
index 000..937e6f5
--- /dev/null
+++ b/drivers/media/usb/hackrf/Kconfig
@@ -0,0 +1,10 @@
+config USB_HACKRF
+ tristate HackRF
+ depends on VIDEO_V4L2
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ This is a video4linux2 driver for HackRF SDR device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hackrf
+
diff --git a/drivers/media/usb/hackrf/Makefile
b/drivers/media/usb/hackrf/Makefile
new file mode 100644
index 000..73064a2
--- /dev/null
+++ b/drivers/media/usb/hackrf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_HACKRF) += hackrf.o
diff --git a/drivers/media/usb/hackrf/hackrf.c
b/drivers/media/usb/hackrf/hackrf.c
new file mode 100644
index 000..9427652
--- /dev/null
+++ b/drivers/media/usb/hackrf/hackrf.c
@@ -0,0 +1,1142 @@
+/*
+ * HackRF driver
+ *
+ * Copyright (C) 2014 Antti Palosaari cr...@iki.fi
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/usb.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
+#include media/videobuf2-vmalloc.h
+
+/* HackRF USB API commands (from HackRF Library) */
+enum {
+ CMD_SET_TRANSCEIVER_MODE = 0x01,
+ CMD_SAMPLE_RATE_SET= 0x06,
+ CMD_BASEBAND_FILTER_BANDWIDTH_SET = 0x07,
+ CMD_BOARD_ID_READ = 0x0e,
+ CMD_VERSION_STRING_READ= 0x0f,
+ CMD_SET_FREQ = 0x10,
+ CMD_SET_LNA_GAIN = 0x13,
+ CMD_SET_VGA_GAIN = 0x14,
+};
+
+/*
+ * bEndpointAddress 0x81 EP 1 IN
+ * Transfer TypeBulk
+ * wMaxPacketSize 0x0200 1x 512 bytes
+ */
+#define MAX_BULK_BUFS(6)
+#define BULK_BUFFER_SIZE (128 * 512)
+
+static const struct v4l2_frequency_band bands_adc[] = {
+ {
+ .tuner = 0,
+ .type = V4L2_TUNER_ADC,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 20,
+ .rangehigh = 2400,
+ },
+};
+
+static const struct v4l2_frequency_band bands_rf[] = {
+ {
+ .tuner = 1,
+ .type =
Re: [PATCH v2] hackrf: HackRF SDR driver
On 09/06/2014 12:39 PM, Antti Palosaari wrote:
V4L2 driver for HackRF SDR. Very basic version, with reduced
feature set. Driver implements receiver only, hardware supports
also transmitter.
USB ID 1d50:6089. Model HackRF One
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Changes in v2:
* renamed state 's' = 'dev'
* do not init spin_lock_irqsave() flags as it has no meaning
* remove unneeded error check from buf_queue
* comment fix remove mention of capt_file
* some minor issues reported by checkpatch.pl
+ start_streaming() error handling...
---
drivers/media/usb/Kconfig |3 +-
drivers/media/usb/Makefile|3 +-
drivers/media/usb/hackrf/Kconfig | 10 +
drivers/media/usb/hackrf/Makefile |1 +
drivers/media/usb/hackrf/hackrf.c | 1142 +
5 files changed, 1157 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/usb/hackrf/Kconfig
create mode 100644 drivers/media/usb/hackrf/Makefile
create mode 100644 drivers/media/usb/hackrf/hackrf.c
diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig
index d6e8edc..056181f 100644
--- a/drivers/media/usb/Kconfig
+++ b/drivers/media/usb/Kconfig
@@ -56,8 +56,9 @@ endif
if MEDIA_SDR_SUPPORT
comment Software defined radio USB devices
-source drivers/media/usb/msi2500/Kconfig
source drivers/media/usb/airspy/Kconfig
+source drivers/media/usb/hackrf/Kconfig
+source drivers/media/usb/msi2500/Kconfig
endif
endif #MEDIA_USB_SUPPORT
diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile
index b5b645b..6f2eb7c 100644
--- a/drivers/media/usb/Makefile
+++ b/drivers/media/usb/Makefile
@@ -9,8 +9,9 @@ obj-y += zr364xx/ stkwebcam/ s2255/
obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/
obj-$(CONFIG_USB_GSPCA) += gspca/
obj-$(CONFIG_USB_PWC) += pwc/
-obj-$(CONFIG_USB_MSI2500) += msi2500/
obj-$(CONFIG_USB_AIRSPY)+= airspy/
+obj-$(CONFIG_USB_HACKRF)+= hackrf/
+obj-$(CONFIG_USB_MSI2500) += msi2500/
obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_AU0828) += au0828/
obj-$(CONFIG_VIDEO_HDPVR) += hdpvr/
diff --git a/drivers/media/usb/hackrf/Kconfig b/drivers/media/usb/hackrf/Kconfig
new file mode 100644
index 000..937e6f5
--- /dev/null
+++ b/drivers/media/usb/hackrf/Kconfig
@@ -0,0 +1,10 @@
+config USB_HACKRF
+ tristate HackRF
+ depends on VIDEO_V4L2
+ select VIDEOBUF2_VMALLOC
+ ---help---
+ This is a video4linux2 driver for HackRF SDR device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hackrf
+
diff --git a/drivers/media/usb/hackrf/Makefile
b/drivers/media/usb/hackrf/Makefile
new file mode 100644
index 000..73064a2
--- /dev/null
+++ b/drivers/media/usb/hackrf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_HACKRF) += hackrf.o
diff --git a/drivers/media/usb/hackrf/hackrf.c
b/drivers/media/usb/hackrf/hackrf.c
new file mode 100644
index 000..9427652
--- /dev/null
+++ b/drivers/media/usb/hackrf/hackrf.c
@@ -0,0 +1,1142 @@
+/*
+ * HackRF driver
+ *
+ * Copyright (C) 2014 Antti Palosaari cr...@iki.fi
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/usb.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
+#include media/videobuf2-vmalloc.h
+
+/* HackRF USB API commands (from HackRF Library) */
+enum {
+ CMD_SET_TRANSCEIVER_MODE = 0x01,
+ CMD_SAMPLE_RATE_SET= 0x06,
+ CMD_BASEBAND_FILTER_BANDWIDTH_SET = 0x07,
+ CMD_BOARD_ID_READ = 0x0e,
+ CMD_VERSION_STRING_READ= 0x0f,
+ CMD_SET_FREQ = 0x10,
+ CMD_SET_LNA_GAIN = 0x13,
+ CMD_SET_VGA_GAIN = 0x14,
+};
+
+/*
+ * bEndpointAddress 0x81 EP 1 IN
+ * Transfer TypeBulk
+ * wMaxPacketSize 0x0200 1x 512 bytes
+ */
+#define MAX_BULK_BUFS(6)
+#define BULK_BUFFER_SIZE (128 * 512)
+
+static const struct v4l2_frequency_band bands_adc[] = {
+ {
+ .tuner = 0,
+ .type = V4L2_TUNER_ADC,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 20,
+ .rangehigh = 2400,
+ },
+};
+
+static const
Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
On 09/06/2014 07:08 AM, Akihiro TSUKADA wrote: Moikka!, thanks for the comments and advices. I had been updating my code and during that, I also found that updating property cache in tuner_ops.get_signal_strength() was simple and (seemed to me) better than using a kthread, so the current implementation (under testing) is just like what Mauro proposed, but, In time: not implementing its own thread has one drawback: the driver needs to check if the minimal time needed to get a new stats were already archived. since I don't know the minimal time and whether there's a limit in the first place, I'd like to let users take the responsibility. You could add some simple jiffie (some kind of kernel global time) which limits calls to some reasonable level. if (jiffies jiffies_previous + 1 sec) return 0; else jiffies_previous = jiffies; ... continue ... I simply don't understand why you want hook that RF strength call via demod? The frontend cache is shared between demod and tuner. We use it for tuner drivr as well demod driver. Let the tuner driver make RSSI calculation independently without any unneeded relation to demod driver. I think the main reason for the hook is because the dvb-core calls ops.get_frontend() everytime before reading of any property cache, so it is already a nice place to trigger property updates, and reading any property involves demod (FE as a whole) anyway. That must be changed 'resently'. IIRC originally get_frontend() was called by dvb-core only once, just after demod lock was gained. Also userspace could call it using some IOCTL (GET_FRONTEND?). But if it is not called periodically by dvb-core, you could not use it for bit error measurements, as you will usually need to start measurement, then wait complete, read values and return. Signal strength and SNR are typically provided by chip without any waiting. 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] drivers: media: radio: radio-miropcm20.c: include missing header file
On Fri, Aug 29, 2014 at 01:38:01PM +0530, Sudip Mukherjee wrote: with -Werror=implicit-function-declaration build failed with error : error: implicit declaration of function 'inb' error: implicit declaration of function 'outb' Reported-by: Jim Davis jim.ep...@gmail.com Signed-off-by: Sudip Mukherjee su...@vectorindi.org --- Jim reported for next-20140828 , but the error still persists in next-20140829 also. drivers/media/radio/radio-miropcm20.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/radio/radio-miropcm20.c b/drivers/media/radio/radio-miropcm20.c index 998919e..3309f7c 100644 --- a/drivers/media/radio/radio-miropcm20.c +++ b/drivers/media/radio/radio-miropcm20.c @@ -36,6 +36,7 @@ #include media/v4l2-fh.h #include media/v4l2-event.h #include sound/aci.h +#includelinux/io.h #define RDS_DATASHIFT 2 /* Bit 2 */ #define RDS_DATAMASK(1 RDS_DATASHIFT) -- 1.8.1.2 gentle ping. build fails on next-20140905 also with the attached config (-Werror=implicit-function-declaration) thanks sudip # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0-rc2 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SYSVIPC is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_TASKS_RCU=y # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_LTO_MENU is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y
Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
Em Sat, 06 Sep 2014 06:34:33 +0300 Antti Palosaari cr...@iki.fi escreveu: On 09/06/2014 06:17 AM, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 06:10:01 +0300 Antti Palosaari cr...@iki.fi escreveu: ... I simply don't understand why you want hook that RF strength call via demod? The frontend cache is shared between demod and tuner. We use it for tuner driver as well demod driver. Let the tuner driver make RSSI calculation independently without any unneeded relation to demod driver. Well, adding kthreads has a cost, with is a way higher than just calling a callback function. Also, it makes a way more complicated to implement several tasks. For example, devices with kthreads need to stop them during suspend, and restart them at resume time, or otherwise suspend and/or resume may not work. Also, the power consumption increases with kthread, as the CPU need to be periodically waken. I'm not saying we shouldn't use kthreads at driver level, but the best is to avoid when there are some other simpler ways of doing it. And small reality check, how much you think one kthreads, that polls once per 2 second or so causes, in a case when you are *already streaming* 20-80 Mbit/sec data stream :) I think CPU does not need wake up to execute one thread as there is a lot of other interrupts happening in that use case anyway. You can't assume that all streams received by a tuner uses 20-80Mbps. It could be a sound broadcasting stream, for example, with uses a much lower bandwidth. We have a remote controller which is polled often as 100ms and it happens even when device is sleeping. And lots of drivers have a modprobe parameter to disable it, because it causes too much power consumption. 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: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
Em Sat, 06 Sep 2014 13:36:14 +0300 Antti Palosaari cr...@iki.fi escreveu: On 09/06/2014 07:08 AM, Akihiro TSUKADA wrote: Moikka!, thanks for the comments and advices. I had been updating my code and during that, I also found that updating property cache in tuner_ops.get_signal_strength() was simple and (seemed to me) better than using a kthread, so the current implementation (under testing) is just like what Mauro proposed, but, In time: not implementing its own thread has one drawback: the driver needs to check if the minimal time needed to get a new stats were already archived. since I don't know the minimal time and whether there's a limit in the first place, I'd like to let users take the responsibility. For RSSI measurements, in general there's no minimal time, but for measures like BER, PER, UCB, you'll need to wait for a while before the stats to be updated. So, you'll need to at least track those. You could add some simple jiffie (some kind of kernel global time) which limits calls to some reasonable level. if (jiffies jiffies_previous + 1 sec) return 0; else jiffies_previous = jiffies; Don't use jiffies like that. jiffies can be overflowed and the update will never occur. The right way is to use the macros time_after() and time_before(), or, alternatively, time_is_after_jiffies() and time_is_before_jiffies(). ... continue ... I simply don't understand why you want hook that RF strength call via demod? The frontend cache is shared between demod and tuner. We use it for tuner drivr as well demod driver. Let the tuner driver make RSSI calculation independently without any unneeded relation to demod driver. I think the main reason for the hook is because the dvb-core calls ops.get_frontend() everytime before reading of any property cache, so it is already a nice place to trigger property updates, and reading any property involves demod (FE as a whole) anyway. That must be changed 'resently'. IIRC originally get_frontend() was called by dvb-core only once, just after demod lock was gained. Also userspace could call it using some IOCTL (GET_FRONTEND?). No, get_frontend() is not automatically called by the dvb kthread after lock has gained. Just double-checked. But if it is not called periodically by dvb-core, you could not use it for bit error measurements, as you will usually need to start measurement, then wait complete, read values and return. Probably, the application you're using for tests are calling it periodically. What the core calls periodically for sure is read_status(). That's why most drivers that provide DVBv5 stats hook the cache update there. Signal strength and SNR are typically provided by chip without any waiting. 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
sale cisco switches
HI We sale cisco new and original switches and routers, following is the product and price list. If you are interested, please contact me! WS-C3750X-24S-S WS-C3750X-48P-S WS-C2960S-24TS-L WS-C2960S-48TS-L WS-C2960S-48LPS-L WS-C2960S-48FPS-L WS-C2960S-48LPD-L WS-C2960S-48FPD-L MY SKYPE ID:AMY122388 REGARD. AMY
[PATCH] af9033: init DVBv5 statistics
We need to init supported stats here in order signal app which
stats are supported.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/af9033.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index be5002a..63a89c1 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -238,6 +238,7 @@ static u32 af9033_div(struct af9033_dev *dev, u32 a, u32 b,
u32 x)
static int af9033_init(struct dvb_frontend *fe)
{
struct af9033_dev *dev = fe-demodulator_priv;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
int ret, i, len;
const struct reg_val *init;
u8 buf[4];
@@ -448,6 +449,19 @@ static int af9033_init(struct dvb_frontend *fe)
}
dev-bandwidth_hz = 0; /* force to program all parameters */
+ /* init stats here in order signal app which stats are supported */
+ c-strength.len = 1;
+ c-strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-cnr.len = 1;
+ c-cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-block_count.len = 1;
+ c-block_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-block_error.len = 1;
+ c-block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-post_bit_count.len = 1;
+ c-post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c-post_bit_error.len = 1;
+ c-post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
/* start statistics polling */
schedule_delayed_work(dev-stat_work, msecs_to_jiffies(2000));
--
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 4/5] media: davinci: vpif_display: fix the check on suspend/resume callbacks
It is possible to call STREAMON without having any buffers queued. So vb2_is_streaming() can return true without start_streaming() having been called. Only after at least one buffer has been queued will start_streaming be called. The check vb2_is_streaming() is incorrect as this would start the DMA without having proper DMA pointers set up. this patch uses vb2_start_streaming_called() instead to check is streaming was called. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/davinci/vpif_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c index 76f829d..8d6ced5 100644 --- a/drivers/media/platform/davinci/vpif_display.c +++ b/drivers/media/platform/davinci/vpif_display.c @@ -1400,7 +1400,7 @@ static int vpif_suspend(struct device *dev) ch = vpif_obj.dev[i]; common = ch-common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(common-buffer_queue)) + if (!vb2_start_streaming_called(common-buffer_queue)) continue; mutex_lock(common-lock); @@ -1432,7 +1432,7 @@ static int vpif_resume(struct device *dev) ch = vpif_obj.dev[i]; common = ch-common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(common-buffer_queue)) + if (!vb2_start_streaming_called(common-buffer_queue)) continue; mutex_lock(common-lock); -- 1.9.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 0/5] media: davinci: vpif fixes
this patch series fixes several small issues in VPIF driver. Lad, Prabhakar (5): media: davinci: vpif_display: drop setting of vb2 buffer state to ACTIVE media: davinci: vpif_capture: drop setting of vb2 buffer state to ACTIVE media: videobuf2-core.h: add a helper to get status of start_streaming() media: davinci: vpif_display: fix the check on suspend/resume callbacks media: davinci: vpif_capture: fix the check on suspend/resume callbacks drivers/media/platform/davinci/vpif_capture.c | 7 ++- drivers/media/platform/davinci/vpif_display.c | 8 ++-- include/media/videobuf2-core.h| 9 + 3 files changed, 13 insertions(+), 11 deletions(-) -- 1.9.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 5/5] media: davinci: vpif_capture: fix the check on suspend/resume callbacks
It is possible to call STREAMON without having any buffers queued. So vb2_is_streaming() can return true without start_streaming() having been called. Only after at least one buffer has been queued will start_streaming be called. The check vb2_is_streaming() is incorrect as this would start the DMA without having proper DMA pointers set up. this patch uses vb2_start_streaming_called() instead to check is streaming was called. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/davinci/vpif_capture.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index 881efcd..3ccb26f 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -1596,7 +1596,7 @@ static int vpif_suspend(struct device *dev) ch = vpif_obj.dev[i]; common = ch-common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(common-buffer_queue)) + if (!vb2_start_streaming_called(common-buffer_queue)) continue; mutex_lock(common-lock); @@ -1630,7 +1630,7 @@ static int vpif_resume(struct device *dev) ch = vpif_obj.dev[i]; common = ch-common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(common-buffer_queue)) + if (!vb2_start_streaming_called(common-buffer_queue)) continue; mutex_lock(common-lock); -- 1.9.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 2/5] media: davinci: vpif_capture: drop setting of vb2 buffer state to ACTIVE
this patch drops setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE, as any buffer queued to the driver is marked ACTIVE by the vb2 core. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/davinci/vpif_capture.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index cf15bb1..881efcd 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -213,8 +213,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count) /* Remove buffer from the buffer queue */ list_del(common-cur_frm-list); spin_unlock_irqrestore(common-irqlock, flags); - /* Mark state of the current frame to active */ - common-cur_frm-vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(common-cur_frm-vb, 0); @@ -350,7 +348,6 @@ static void vpif_schedule_next_buffer(struct common_obj *common) /* Remove that buffer from the buffer queue */ list_del(common-next_frm-list); spin_unlock(common-irqlock); - common-next_frm-vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(common-next_frm-vb, 0); /* Set top and bottom field addresses in VPIF registers */ -- 1.9.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 3/5] media: videobuf2-core.h: add a helper to get status of start_streaming()
this patch adds a helper to get the status if start_streaming()
was called successfully.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Pawel Osciak pa...@osciak.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
include/media/videobuf2-core.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5a10d8d..b3c9973 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -590,6 +590,15 @@ vb2_plane_size(struct vb2_buffer *vb, unsigned int
plane_no)
return 0;
}
+/**
+ * vb2_start_streaming_called() - return streaming status of driver
+ * @q: videobuf queue
+ */
+static inline bool vb2_start_streaming_called(struct vb2_queue *q)
+{
+ return q-start_streaming_called;
+}
+
/*
* The following functions are not part of the vb2 core API, but are simple
* helper functions that you can use in your struct v4l2_file_operations,
--
1.9.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 1/5] media: davinci: vpif_display: drop setting of vb2 buffer state to ACTIVE
this patch drops setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE, as any buffer queued to the driver is marked ACTIVE by the vb2 core. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/davinci/vpif_display.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c index 2ce3ddf..76f829d 100644 --- a/drivers/media/platform/davinci/vpif_display.c +++ b/drivers/media/platform/davinci/vpif_display.c @@ -196,8 +196,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count) list_del(common-cur_frm-list); spin_unlock_irqrestore(common-irqlock, flags); - /* Mark state of the current frame to active */ - common-cur_frm-vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(common-cur_frm-vb, 0); common-set_addr((addr + common-ytop_off), @@ -306,8 +304,6 @@ static void process_progressive_mode(struct common_obj *common) /* Remove that buffer from the buffer queue */ list_del(common-next_frm-list); spin_unlock(common-irqlock); - /* Mark status of the buffer as active */ - common-next_frm-vb.state = VB2_BUF_STATE_ACTIVE; /* Set top and bottom field addrs in VPIF registers */ addr = vb2_dma_contig_plane_dma_addr(common-next_frm-vb, 0); -- 1.9.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
Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
On 06/09/14 03:51, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 05:09:55 +0300 Antti Palosaari cr...@iki.fi escreveu: Moro! On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote: moikka, Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. I understand that RSSI property should be set directly in the tuner driver, but I'm afraid that creating a kthread just for updating RSSI would be overkill and complicate matters. Would you give me an advice? Mauro Now I know that as I implement it. I added kthread and it works correctly, just I though it is aimed to work. In my case signal strength is reported by demod, not tuner, because there is some logic in firmware to calculate it. Here is patches you would like to look as a example: af9033: implement DVBv5 statistic for signal strength https://patchwork.linuxtv.org/patch/25748/ Actually, you don't need to add a separate kthread to collect the stats. The DVB frontend core already has a thread that calls the frontend status on every 3 seconds (the time can actually be different, depending on the value for fepriv-delay. So, if the device doesn't have any issues on getting stats on this period, it could just hook the DVBv5 stats logic at ops.read_status(). Hmm, fepriv-delay missed that one, 3 seconds is far too long for lmedm04. It would be good to hook stats on to this thread. Regards Malcolm -- 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 v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
On 06/09/14 17:24, Malcolm Priestley wrote: On 06/09/14 03:51, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 05:09:55 +0300 Antti Palosaari cr...@iki.fi escreveu: Moro! On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote: moikka, Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. I understand that RSSI property should be set directly in the tuner driver, but I'm afraid that creating a kthread just for updating RSSI would be overkill and complicate matters. Would you give me an advice? Mauro Now I know that as I implement it. I added kthread and it works correctly, just I though it is aimed to work. In my case signal strength is reported by demod, not tuner, because there is some logic in firmware to calculate it. Here is patches you would like to look as a example: af9033: implement DVBv5 statistic for signal strength https://patchwork.linuxtv.org/patch/25748/ Actually, you don't need to add a separate kthread to collect the stats. The DVB frontend core already has a thread that calls the frontend status on every 3 seconds (the time can actually be different, depending on the value for fepriv-delay. So, if the device doesn't have any issues on getting stats on this period, it could just hook the DVBv5 stats logic at ops.read_status(). Hmm, fepriv-delay missed that one, 3 seconds is far too long for lmedm04. It would be good to hook stats on to this thread. optional that is. -- 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 3/3] si2168: avoid firmware loading if it has been loaded previously
Moro Antti,
Tried removing the command 85 after resume, but the result is that the
demod doesn't lock after sleep. Curiously this only impacts HD or
DVB-T2 channels. DVB-T SD channels are fine even after resume.
Log of the testing here:
http://paste.ubuntu.com/8271949/
Same thing happens after applying the si2157: sleep hack patch: my
TT CT2-4400 does not lock on the second tune, ie. after sleep.
Log of the testing of that patch is here:
http://paste.ubuntu.com/8271869/
Cheers,
-olli
On 5 September 2014 21:54, Olli Salonen olli.salo...@iki.fi wrote:
Moro,
I'll test it once more when testing the si2157 sleep hack you
posted. Though I remember that the command 85 seemed to be the magic
trick that finally made it work - I agree it sounds a bit strange
considering it's run later on anyway. The proprietary driver seems to
do a command 85 after wake up, but of course that's not a guarantee of
anything.
My sniff using the proprietary driver is here:
http://trsqr.net/olli/ct2-4400/ct2-4400-wakeup-tune-sleep.txt
Cheers,
-olli
On 5 September 2014 11:36, Antti Palosaari cr...@iki.fi wrote:
Moikka
Did you really need command 85 here? It will be given later in any case. For
my Si2168 B40 there was no need for it.
regards
Antti
On 08/25/2014 09:07 PM, Olli Salonen wrote:
Add a variable to keep track if firmware is loaded or not and skip parts
of the
initialization if fw is already loaded. Resume from sleep with a different
command compared to initial power up and run command 85 after resume
command.
This behaviour is observed when using manufacturer provided binary-only
si2168
driver for TechnoTrend CT2-4400.
Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
drivers/media/dvb-frontends/si2168.c | 31
---
drivers/media/dvb-frontends/si2168_priv.h | 1 +
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 55a4212..a0797fd 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -363,6 +363,7 @@ static int si2168_init(struct dvb_frontend *fe)
dev_dbg(s-client-dev, \n);
+ /* initialize */
memcpy(cmd.args,
\xc0\x12\x00\x0c\x00\x0d\x16\x00\x00\x00\x00\x00\x00, 13);
cmd.wlen = 13;
cmd.rlen = 0;
@@ -370,6 +371,26 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
+ if (s-fw_loaded) {
+ /* resume */
+ memcpy(cmd.args, \xc0\x06\x08\x0f\x00\x20\x21\x01, 8);
+ cmd.wlen = 8;
+ cmd.rlen = 1;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
+ memcpy(cmd.args, \x85, 1);
+ cmd.wlen = 1;
+ cmd.rlen = 1;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
+ goto warm;
+ }
+
+ /* power up */
memcpy(cmd.args, \xc0\x06\x01\x0f\x00\x20\x20\x01, 8);
cmd.wlen = 8;
cmd.rlen = 1;
@@ -466,9 +487,6 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
- dev_info(s-client-dev, found a '%s' in warm state\n,
- si2168_ops.info.name);
-
/* set ts mode */
memcpy(cmd.args, \x14\x00\x01\x10\x10\x00, 6);
cmd.args[4] |= s-ts_mode;
@@ -478,6 +496,12 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
+ s-fw_loaded = true;
+
+warm:
+ dev_info(s-client-dev, found a '%s' in warm state\n,
+ si2168_ops.info.name);
+
s-active = true;
return 0;
@@ -645,6 +669,7 @@ static int si2168_probe(struct i2c_client *client,
*config-i2c_adapter = s-adapter;
*config-fe = s-fe;
s-ts_mode = config-ts_mode;
+ s-fw_loaded = false;
i2c_set_clientdata(client, s);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h
b/drivers/media/dvb-frontends/si2168_priv.h
index 0f83284..e13983e 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -36,6 +36,7 @@ struct si2168 {
fe_delivery_system_t delivery_system;
fe_status_t fe_status;
bool active;
+ bool fw_loaded;
u8 ts_mode;
};
--
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] PT3 (tc90522, mxl301rf, qm1d1c0042) ISDB-S/T driver package
From: guest knightri...@are.ma DVB driver for Earthsoft PT3 (PCIE ISDB-S/T receiver) = Status: STABLE (there was a bug in previous release, sorry) Behavior: same as PT1 DVB, plus some tuning enhancements 1. in addition to the real frequency: ISDB-S : freq. channel ID ISDB-T : freq# (I/O# +128), ch#, ch# +64 for CATV 2. in addition to TSID: ISDB-S : slot# Main components: 1. SharpVA4M6JC2103 : contains 2 ISDB-S + 2 ISDB-T tuners ISDB-S : Sharp QM1D1C0042 RF-IC ISDB-T : MaxLinear CMOS Hybrid TV MxL301RF 2. Toshiba TC90522XBG : quad demodulator (2ch OFDM + 2ch 8PSK) 3. Altera EP4CGX15BF14C8N : customized FPGA PCI bridge 4. ESMT M12L16161A-7TG : on-board memory Full package: - URL: https://github.com/knight-rider/ptx/tree/master/pt3_dvb - buildable as standalone, DKMS or tree embedded module - installation: $ chmod +x dkms.install dkms.uninstall $ ./dkms.install Features: - dropped verbosity (debug levels), use single level -DDEBUG instead - translated to standard (?) I2C protocol - dropped FE's LNB control other unused features - raw CNR for DVBv3 (.read_snr) - decibel scaled CNR for DVBv5 (@ .0001 dB) - converted pr_ to dev_ Recent correspondence: Q Antti: For the next round you must split that patchset as one patch per driver. A DECLINED: This package contains PCI bridge (including I2C DMA handlers), demod tuner drivers. Splitting will break the integrity only makes harder to review. It is up to the maintainers to review only drivers of interest... Q Antti: IMHO, the most correct implementation solution is use of I2C mux. https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing See implementation example from rtl2832 and si2168 drivers. I encourage you to use RegMap API Implementation example could be found from e4000 driver at least. A DECLINED: Good recommendation taken into consideration. However, this driver is already in stable status, tested running well. Changing communication protocol is very risky will cause tons of bugs. Unless it is a must, this method is not likely to be taken. FYI, the only document available is SDK from PT3 card maker, Earthsoft. No guarantee this driver works in other cards. Q Antti: Masking return statuses does not look good nor clear A DECLINED: We only want to know stop if an error occured. It is enough. Q Antti: Global static variable looks very bad A DONE: removed, pt3_pci now decides when to ignit demod chip Q Antti: Overall tc90522 driver looks very complex. One reason is that HW algo used. I cannot see any reason why it is used, just change default SW algo and implement things more likely others are doing. Basically it is callback which dvb core uses to tune device. However, thee is complex state machine implemented. State machine state is updated by read_status() callback, which is *not* ran by DVB core when that HW aldo is used. How that can work? You need to call FE status from userspace in order to update state machine? If your app does not call status, that does not work at all? A DECLINED: You are WRONG. dvb-core runs the iteration. Q Mauro: If the device doesn't have a hardware zig-zag, and you don't use the SW algo, then it may fail to tune to some transponders. On the devices with SW algo, the status updates happen at the read_status() call. On your implementation, you're doing it at ops.tune() callback, with seems OK on my eyes. As I said, that depends if the HW (or firmware) already does frequency zig-zag or not. If it does, this implementation is better. However, if it doesn't, you should convert to use SW algo. A DONE: That's it! The chip seems to be smart enough user only needs to check the lock. Q Antti: Driver should not need index at all. It could be found from the frontend pointer after registration, but still not needed. A DONE: removed, but If you read the source thoroughly, you will find idx is used only for debugging Q Antti: There is some issues as T and S mode driver instances registered to same chip. What happens if you are wathing T and try tune S at same time? (probably T breaks). A Nothing wrong. The chip can handle all 2ch T + 2ch S simultaneously. Q Antti: You must use dev_ functions for logging. A DONE: with notes.. Some maintainers (I forgot their names, maybe you also?) asked to use pr_*. And I agreed with them. dev_* is used only in pt3_pci, the PCI bridge driver. IMHO pr_* is more suitable. We can change to dev_* if it is a must. Q Mauro: There's actually a order of preference for those printk macros. pr_* is better than using printk, but dev_* is a little better, as it would save you from adding the demod-idx to the printk calls, as it will use the device name instead. A This is NOT fully correct. Only one I2C device is registered. Since all 4 demods share the same I2C, dev_ will print May
Re: [PATCH v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
moikka!, Basically it is 2 functions, af9035_add_i2c_dev() and af9035_del_i2c_dev() I used request_module()/try_module_get()/module_put() just like the above example (and bridge-core.c). It works, but when I unload bridge driver(earth_pt3), its demod and tuner modules stay loaded, with the refcount of 0. Is it ok that the auto loaded modules remain with 0 ref count? Yet, using config to OUT seems to be bit hacky for my eyes too. I though replacing all OUT with ops when converted af9033 driver. Currently caller fills struct af9033_ops and then af9033 I2C probe populates ops. See that patch: https://patchwork.linuxtv.org/patch/25746/ Does this kind of ops sounds any better? Do you mean using ops in struct config? if so, I don't find much difference with the current situation where demod/tuner probe() sets dvb_frontend* to config-fe. I quickly overlooked that demod driver and one which looked crazy was LNA stuff. You implement set_lna callback in demod, but it is then passed back to PCI driver using frontend callback. Is there some reason you hooked it via demod? You could implement set_lna in PCI driver too. Stupidly I forgot that FE's ops can be set from the PCI driver. I will remove those callbacks and set the corresponding ops instead. regards, akihiro -- 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 v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
On 06/09/14 17:24, Malcolm Priestley wrote: On 06/09/14 03:51, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 05:09:55 +0300 Antti Palosaari cr...@iki.fi escreveu: Moro! On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote: moikka, Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. I understand that RSSI property should be set directly in the tuner driver, but I'm afraid that creating a kthread just for updating RSSI would be overkill and complicate matters. Would you give me an advice? Mauro Now I know that as I implement it. I added kthread and it works correctly, just I though it is aimed to work. In my case signal strength is reported by demod, not tuner, because there is some logic in firmware to calculate it. Here is patches you would like to look as a example: af9033: implement DVBv5 statistic for signal strength https://patchwork.linuxtv.org/patch/25748/ Actually, you don't need to add a separate kthread to collect the stats. The DVB frontend core already has a thread that calls the frontend status on every 3 seconds (the time can actually be different, depending on the value for fepriv-delay. So, if the device doesn't have any issues on getting stats on this period, it could just hook the DVBv5 stats logic at ops.read_status(). Hmm, fepriv-delay missed that one, 3 seconds is far too long for lmedm04. The only way change this is by using algo DVBFE_ALGO_HW using the frontend ops tune. As most frontends are using dvb_frontend_swzigzag it could be implemented by patching the frontend ops tune code at the lock return in this function or in dvb_frontend_swzigzag_update_delay. Regards Malcolm -- 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 v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
Em Sat, 06 Sep 2014 22:37:21 +0100 Malcolm Priestley tvbox...@gmail.com escreveu: On 06/09/14 17:24, Malcolm Priestley wrote: On 06/09/14 03:51, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 05:09:55 +0300 Antti Palosaari cr...@iki.fi escreveu: Moro! On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote: moikka, Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. I understand that RSSI property should be set directly in the tuner driver, but I'm afraid that creating a kthread just for updating RSSI would be overkill and complicate matters. Would you give me an advice? Mauro Now I know that as I implement it. I added kthread and it works correctly, just I though it is aimed to work. In my case signal strength is reported by demod, not tuner, because there is some logic in firmware to calculate it. Here is patches you would like to look as a example: af9033: implement DVBv5 statistic for signal strength https://patchwork.linuxtv.org/patch/25748/ Actually, you don't need to add a separate kthread to collect the stats. The DVB frontend core already has a thread that calls the frontend status on every 3 seconds (the time can actually be different, depending on the value for fepriv-delay. So, if the device doesn't have any issues on getting stats on this period, it could just hook the DVBv5 stats logic at ops.read_status(). Hmm, fepriv-delay missed that one, 3 seconds is far too long for lmedm04. The only way change this is by using algo DVBFE_ALGO_HW using the frontend ops tune. As most frontends are using dvb_frontend_swzigzag it could be implemented by patching the frontend ops tune code at the lock return in this function or in dvb_frontend_swzigzag_update_delay. Well, if a different value is needed, it shouldn't be hard to add a way to customize it, letting the demod to specify it, in the same way as fe-ops.info.frequency_stepsize (and other similar demot properties) are passed through the core. 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: [PATCH 3/3] si2168: avoid firmware loading if it has been loaded previously
Moro!
Removing 85 causes lose of DVB-T2 lock, but DVB-T works for me too
(Si2168 B40). So you were correct. I will apply that patch as it is.
That tuner sleep/firmware download patch is another thing. Maybe I will
apply it too as it prevents unnecessary firmware downloading for Si2158
(my Si2157 does not need fw upgrade at all). It harms me a little bit to
lose 18mA @5V idle power consumption, but 18mA is still not too much.
Reality is that most of these Linux DVB drivers are so broken that USB
device consumes more than 100mA on sleep. I am only person who has done
these measurements and tried to fix all leakages, and many times done it
even better than Windows drivers :) If Linux DVB power management is
almost always broken, it is still not very successful on windows I have
noticed.
It is annoying though maintain these drivers without a hardware...
regards
Antti
On 09/06/2014 08:36 PM, Olli Salonen wrote:
Moro Antti,
Tried removing the command 85 after resume, but the result is that the
demod doesn't lock after sleep. Curiously this only impacts HD or
DVB-T2 channels. DVB-T SD channels are fine even after resume.
Log of the testing here:
http://paste.ubuntu.com/8271949/
Same thing happens after applying the si2157: sleep hack patch: my
TT CT2-4400 does not lock on the second tune, ie. after sleep.
Log of the testing of that patch is here:
http://paste.ubuntu.com/8271869/
Cheers,
-olli
On 5 September 2014 21:54, Olli Salonen olli.salo...@iki.fi wrote:
Moro,
I'll test it once more when testing the si2157 sleep hack you
posted. Though I remember that the command 85 seemed to be the magic
trick that finally made it work - I agree it sounds a bit strange
considering it's run later on anyway. The proprietary driver seems to
do a command 85 after wake up, but of course that's not a guarantee of
anything.
My sniff using the proprietary driver is here:
http://trsqr.net/olli/ct2-4400/ct2-4400-wakeup-tune-sleep.txt
Cheers,
-olli
On 5 September 2014 11:36, Antti Palosaari cr...@iki.fi wrote:
Moikka
Did you really need command 85 here? It will be given later in any case. For
my Si2168 B40 there was no need for it.
regards
Antti
On 08/25/2014 09:07 PM, Olli Salonen wrote:
Add a variable to keep track if firmware is loaded or not and skip parts
of the
initialization if fw is already loaded. Resume from sleep with a different
command compared to initial power up and run command 85 after resume
command.
This behaviour is observed when using manufacturer provided binary-only
si2168
driver for TechnoTrend CT2-4400.
Signed-off-by: Olli Salonen olli.salo...@iki.fi
---
drivers/media/dvb-frontends/si2168.c | 31
---
drivers/media/dvb-frontends/si2168_priv.h | 1 +
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 55a4212..a0797fd 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -363,6 +363,7 @@ static int si2168_init(struct dvb_frontend *fe)
dev_dbg(s-client-dev, \n);
+ /* initialize */
memcpy(cmd.args,
\xc0\x12\x00\x0c\x00\x0d\x16\x00\x00\x00\x00\x00\x00, 13);
cmd.wlen = 13;
cmd.rlen = 0;
@@ -370,6 +371,26 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
+ if (s-fw_loaded) {
+ /* resume */
+ memcpy(cmd.args, \xc0\x06\x08\x0f\x00\x20\x21\x01, 8);
+ cmd.wlen = 8;
+ cmd.rlen = 1;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
+ memcpy(cmd.args, \x85, 1);
+ cmd.wlen = 1;
+ cmd.rlen = 1;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
+ goto warm;
+ }
+
+ /* power up */
memcpy(cmd.args, \xc0\x06\x01\x0f\x00\x20\x20\x01, 8);
cmd.wlen = 8;
cmd.rlen = 1;
@@ -466,9 +487,6 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
- dev_info(s-client-dev, found a '%s' in warm state\n,
- si2168_ops.info.name);
-
/* set ts mode */
memcpy(cmd.args, \x14\x00\x01\x10\x10\x00, 6);
cmd.args[4] |= s-ts_mode;
@@ -478,6 +496,12 @@ static int si2168_init(struct dvb_frontend *fe)
if (ret)
goto err;
+ s-fw_loaded = true;
+
+warm:
+ dev_info(s-client-dev, found a '%s' in warm state\n,
+ si2168_ops.info.name);
+
s-active = true;
return 0;
@@ -645,6 +669,7 @@ static int si2168_probe(struct i2c_client *client,
*config-i2c_adapter = s-adapter;
*config-fe = s-fe;
s-ts_mode = config-ts_mode;
+ s-fw_loaded = false;
i2c_set_clientdata(client, s);
diff --git
[GIT PULL] si2168 and si2157 firmware download improvements
The following changes since commit 89fffac802c18caebdf4e91c0785b522c9f6399a: [media] drxk_hard: fix bad alignments (2014-09-03 19:19:18 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git silabs_prevent_fw_dl for you to fetch changes up to 5d8440f3f7ac82942df1afaa28e46174dd310e69: si2168: avoid firmware loading if it has been loaded previously (2014-09-07 02:28:43 +0300) Olli Salonen (3): si2157: change command for sleep si2157: avoid firmware loading if it has been loaded previously si2168: avoid firmware loading if it has been loaded previously drivers/media/dvb-frontends/si2168.c | 31 --- drivers/media/dvb-frontends/si2168_priv.h | 1 + drivers/media/tuners/si2157.c | 18 +- drivers/media/tuners/si2157_priv.h| 1 + 4 files changed, 43 insertions(+), 8 deletions(-) -- 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 v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
On 09/07/2014 01:37 AM, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 22:37:21 +0100 Malcolm Priestley tvbox...@gmail.com escreveu: On 06/09/14 17:24, Malcolm Priestley wrote: On 06/09/14 03:51, Mauro Carvalho Chehab wrote: Em Sat, 06 Sep 2014 05:09:55 +0300 Antti Palosaari cr...@iki.fi escreveu: Moro! On 08/29/2014 01:45 PM, Akihiro TSUKADA wrote: moikka, Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. I understand that RSSI property should be set directly in the tuner driver, but I'm afraid that creating a kthread just for updating RSSI would be overkill and complicate matters. Would you give me an advice? Mauro Now I know that as I implement it. I added kthread and it works correctly, just I though it is aimed to work. In my case signal strength is reported by demod, not tuner, because there is some logic in firmware to calculate it. Here is patches you would like to look as a example: af9033: implement DVBv5 statistic for signal strength https://patchwork.linuxtv.org/patch/25748/ Actually, you don't need to add a separate kthread to collect the stats. The DVB frontend core already has a thread that calls the frontend status on every 3 seconds (the time can actually be different, depending on the value for fepriv-delay. So, if the device doesn't have any issues on getting stats on this period, it could just hook the DVBv5 stats logic at ops.read_status(). Hmm, fepriv-delay missed that one, 3 seconds is far too long for lmedm04. The only way change this is by using algo DVBFE_ALGO_HW using the frontend ops tune. As most frontends are using dvb_frontend_swzigzag it could be implemented by patching the frontend ops tune code at the lock return in this function or in dvb_frontend_swzigzag_update_delay. Well, if a different value is needed, it shouldn't be hard to add a way to customize it, letting the demod to specify it, in the same way as fe-ops.info.frequency_stepsize (and other similar demot properties) are passed through the core. DVBFE_ALGO_SW, which is used normally, polls read_status rather rapidly. For statics problem is that it is too rapid, not that it is too slow. If you want re-use that as a timer for statistics, you could simply make own ratelimit very easily using kernel jiffies. Not going to implement details, but here is skeleton, which is almost as many lines of code as actual implementation: if (jiffies jiffies_prev + 2 sec) return 0; // limit on else jiffies_prev = jiffies; ... statistics polling code here. 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 v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
On 09/06/2014 10:35 PM, Akihiro TSUKADA wrote: moikka!, Basically it is 2 functions, af9035_add_i2c_dev() and af9035_del_i2c_dev() I used request_module()/try_module_get()/module_put() just like the above example (and bridge-core.c). It works, but when I unload bridge driver(earth_pt3), its demod and tuner modules stay loaded, with the refcount of 0. Is it ok that the auto loaded modules remain with 0 ref count? So there is no other problem than those modules were left loaded? If you could unload those using rmmod it is OK then. Ref counting is here to prevent unloading demod and tuner driver while those are used by some other module. So when bridge is loaded, you should not be able to unload demod or tuner. But when bridge is unloaded, you should be able to unload demod and tuner. And your question, I think there is no way to unload modules automatically or at least no need. Yet, using config to OUT seems to be bit hacky for my eyes too. I though replacing all OUT with ops when converted af9033 driver. Currently caller fills struct af9033_ops and then af9033 I2C probe populates ops. See that patch: https://patchwork.linuxtv.org/patch/25746/ Does this kind of ops sounds any better? Do you mean using ops in struct config? if so, I don't find much difference with the current situation where demod/tuner probe() sets dvb_frontend* to config-fe. Alloc driver specific ops in bridge driver, then put pointer to that ops to config struct. Driver fills ops during probe. Maybe that patch clears the idea: af9033: Don't export functions for the hardware filter https://patchwork.linuxtv.org/patch/23087/ Functionality is not much different than passing pointer to frontend pointer from bridge to I2C demod driver via platform_data... Somehow you will need to transfer data during driver loading and there is not many alternatives: * platform data pointer * driver data pointer * export function * i2c_clients_command (legacy) * device ID string (not very suitable) * + the rest from i2c client, not related at all 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 v2 8/8] tda18212: convert to RegMap API
Use RegMap API to handle all the boring I2C register access
boilerplate stuff.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/Kconfig| 1 +
drivers/media/tuners/tda18212.c | 131 ++--
2 files changed, 18 insertions(+), 114 deletions(-)
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index d79fd1c..483963d 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -204,6 +204,7 @@ config MEDIA_TUNER_FC0013
config MEDIA_TUNER_TDA18212
tristate NXP TDA18212 silicon tuner
depends on MEDIA_SUPPORT I2C
+ select REGMAP_I2C
default m if !MEDIA_SUBDRV_AUTOSELECT
help
NXP TDA18212 silicon tuner driver.
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 24948c7..d93e066 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -19,122 +19,16 @@
*/
#include tda18212.h
-
-/* Max transfer size done by I2C transfer functions */
-#define MAX_XFER_SIZE 64
+#include linux/regmap.h
struct tda18212_dev {
struct tda18212_config cfg;
struct i2c_client *client;
+ struct regmap *regmap;
u32 if_frequency;
};
-/* write multiple registers */
-static int tda18212_wr_regs(struct tda18212_dev *dev, u8 reg, u8 *val, int len)
-{
- int ret;
- u8 buf[MAX_XFER_SIZE];
- struct i2c_msg msg[1] = {
- {
- .addr = dev-client-addr,
- .flags = 0,
- .len = 1 + len,
- .buf = buf,
- }
- };
-
- if (1 + len sizeof(buf)) {
- dev_warn(dev-client-dev,
- i2c wr reg=%04x: len=%d is too big!\n,
- reg, len);
- return -EINVAL;
- }
-
- buf[0] = reg;
- memcpy(buf[1], val, len);
-
- ret = i2c_transfer(dev-client-adapter, msg, 1);
- if (ret == 1) {
- ret = 0;
- } else {
- dev_warn(dev-client-dev,
- i2c wr failed=%d reg=%02x len=%d\n,
- ret, reg, len);
- ret = -EREMOTEIO;
- }
- return ret;
-}
-
-/* read multiple registers */
-static int tda18212_rd_regs(struct tda18212_dev *dev, u8 reg, u8 *val, int len)
-{
- int ret;
- u8 buf[MAX_XFER_SIZE];
- struct i2c_msg msg[2] = {
- {
- .addr = dev-client-addr,
- .flags = 0,
- .len = 1,
- .buf = reg,
- }, {
- .addr = dev-client-addr,
- .flags = I2C_M_RD,
- .len = len,
- .buf = buf,
- }
- };
-
- if (len sizeof(buf)) {
- dev_warn(dev-client-dev,
- i2c rd reg=%04x: len=%d is too big!\n,
- reg, len);
- return -EINVAL;
- }
-
- ret = i2c_transfer(dev-client-adapter, msg, 2);
- if (ret == 2) {
- memcpy(val, buf, len);
- ret = 0;
- } else {
- dev_warn(dev-client-dev,
- i2c rd failed=%d reg=%02x len=%d\n,
- ret, reg, len);
- ret = -EREMOTEIO;
- }
-
- return ret;
-}
-
-/* write single register */
-static int tda18212_wr_reg(struct tda18212_dev *dev, u8 reg, u8 val)
-{
- return tda18212_wr_regs(dev, reg, val, 1);
-}
-
-/* read single register */
-static int tda18212_rd_reg(struct tda18212_dev *dev, u8 reg, u8 *val)
-{
- return tda18212_rd_regs(dev, reg, val, 1);
-}
-
-#if 0 /* keep, useful when developing driver */
-static void tda18212_dump_regs(struct tda18212_dev *dev)
-{
- int i;
- u8 buf[256];
-
- #define TDA18212_RD_LEN 32
- for (i = 0; i sizeof(buf); i += TDA18212_RD_LEN)
- tda18212_rd_regs(dev, i, buf[i], TDA18212_RD_LEN);
-
- print_hex_dump(KERN_INFO, , DUMP_PREFIX_OFFSET, 32, 1, buf,
- sizeof(buf), true);
-
- return;
-}
-#endif
-
static int tda18212_set_params(struct dvb_frontend *fe)
{
struct tda18212_dev *dev = fe-tuner_priv;
@@ -231,15 +125,15 @@ static int tda18212_set_params(struct dvb_frontend *fe)
goto error;
}
- ret = tda18212_wr_reg(dev, 0x23, bw_params[i][2]);
+ ret = regmap_write(dev-regmap, 0x23, bw_params[i][2]);
if (ret)
goto error;
- ret = tda18212_wr_reg(dev, 0x06, 0x00);
+ ret = regmap_write(dev-regmap, 0x06, 0x00);
if (ret)
goto error;
- ret = tda18212_wr_reg(dev, 0x0f, bw_params[i][0]);
+ ret = regmap_write(dev-regmap, 0x0f, bw_params[i][0]);
if (ret)
goto error;
[PATCH v2 7/8] tda18212: rename state from 'priv' to 'dev'
foo_dev seems to be most correct term for the structure holding data
of each device instance. It is most used term in Kernel codebase and also
examples from book Linux Device Drivers, Third Edition, uses it.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.c | 104
1 file changed, 51 insertions(+), 53 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 5d1d785..24948c7 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -23,7 +23,7 @@
/* Max transfer size done by I2C transfer functions */
#define MAX_XFER_SIZE 64
-struct tda18212_priv {
+struct tda18212_dev {
struct tda18212_config cfg;
struct i2c_client *client;
@@ -31,14 +31,13 @@ struct tda18212_priv {
};
/* write multiple registers */
-static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
- int len)
+static int tda18212_wr_regs(struct tda18212_dev *dev, u8 reg, u8 *val, int len)
{
int ret;
u8 buf[MAX_XFER_SIZE];
struct i2c_msg msg[1] = {
{
- .addr = priv-client-addr,
+ .addr = dev-client-addr,
.flags = 0,
.len = 1 + len,
.buf = buf,
@@ -46,7 +45,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
};
if (1 + len sizeof(buf)) {
- dev_warn(priv-client-dev,
+ dev_warn(dev-client-dev,
i2c wr reg=%04x: len=%d is too big!\n,
reg, len);
return -EINVAL;
@@ -55,11 +54,11 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
buf[0] = reg;
memcpy(buf[1], val, len);
- ret = i2c_transfer(priv-client-adapter, msg, 1);
+ ret = i2c_transfer(dev-client-adapter, msg, 1);
if (ret == 1) {
ret = 0;
} else {
- dev_warn(priv-client-dev,
+ dev_warn(dev-client-dev,
i2c wr failed=%d reg=%02x len=%d\n,
ret, reg, len);
ret = -EREMOTEIO;
@@ -68,19 +67,18 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
}
/* read multiple registers */
-static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
- int len)
+static int tda18212_rd_regs(struct tda18212_dev *dev, u8 reg, u8 *val, int len)
{
int ret;
u8 buf[MAX_XFER_SIZE];
struct i2c_msg msg[2] = {
{
- .addr = priv-client-addr,
+ .addr = dev-client-addr,
.flags = 0,
.len = 1,
.buf = reg,
}, {
- .addr = priv-client-addr,
+ .addr = dev-client-addr,
.flags = I2C_M_RD,
.len = len,
.buf = buf,
@@ -88,18 +86,18 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
};
if (len sizeof(buf)) {
- dev_warn(priv-client-dev,
+ dev_warn(dev-client-dev,
i2c rd reg=%04x: len=%d is too big!\n,
reg, len);
return -EINVAL;
}
- ret = i2c_transfer(priv-client-adapter, msg, 2);
+ ret = i2c_transfer(dev-client-adapter, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
ret = 0;
} else {
- dev_warn(priv-client-dev,
+ dev_warn(dev-client-dev,
i2c rd failed=%d reg=%02x len=%d\n,
ret, reg, len);
ret = -EREMOTEIO;
@@ -109,26 +107,26 @@ static int tda18212_rd_regs(struct tda18212_priv *priv,
u8 reg, u8 *val,
}
/* write single register */
-static int tda18212_wr_reg(struct tda18212_priv *priv, u8 reg, u8 val)
+static int tda18212_wr_reg(struct tda18212_dev *dev, u8 reg, u8 val)
{
- return tda18212_wr_regs(priv, reg, val, 1);
+ return tda18212_wr_regs(dev, reg, val, 1);
}
/* read single register */
-static int tda18212_rd_reg(struct tda18212_priv *priv, u8 reg, u8 *val)
+static int tda18212_rd_reg(struct tda18212_dev *dev, u8 reg, u8 *val)
{
- return tda18212_rd_regs(priv, reg, val, 1);
+ return tda18212_rd_regs(dev, reg, val, 1);
}
#if 0 /* keep, useful when developing driver */
-static void tda18212_dump_regs(struct tda18212_priv *priv)
+static void tda18212_dump_regs(struct tda18212_dev *dev)
{
int i;
u8 buf[256];
#define TDA18212_RD_LEN 32
for (i = 0; i sizeof(buf); i += TDA18212_RD_LEN)
- tda18212_rd_regs(priv, i, buf[i],
[PATCH v2 5/8] tda18212: convert driver to I2C binding
Convert driver from DVB proprietary model to common I2C model.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.c | 129
drivers/media/tuners/tda18212.h | 14 -
2 files changed, 79 insertions(+), 64 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 15b09f8..659787b 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -24,8 +24,8 @@
#define MAX_XFER_SIZE 64
struct tda18212_priv {
- struct tda18212_config *cfg;
- struct i2c_adapter *i2c;
+ struct tda18212_config cfg;
+ struct i2c_client *client;
u32 if_frequency;
};
@@ -38,7 +38,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
u8 buf[MAX_XFER_SIZE];
struct i2c_msg msg[1] = {
{
- .addr = priv-cfg-i2c_address,
+ .addr = priv-client-addr,
.flags = 0,
.len = 1 + len,
.buf = buf,
@@ -46,7 +46,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
};
if (1 + len sizeof(buf)) {
- dev_warn(priv-i2c-dev,
+ dev_warn(priv-client-dev,
%s: i2c wr reg=%04x: len=%d is too big!\n,
KBUILD_MODNAME, reg, len);
return -EINVAL;
@@ -55,12 +55,12 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
buf[0] = reg;
memcpy(buf[1], val, len);
- ret = i2c_transfer(priv-i2c, msg, 1);
+ ret = i2c_transfer(priv-client-adapter, msg, 1);
if (ret == 1) {
ret = 0;
} else {
- dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x \
- len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ dev_warn(priv-client-dev, %s: i2c wr failed=%d reg=%02x
len=%d\n,
+ KBUILD_MODNAME, ret, reg, len);
ret = -EREMOTEIO;
}
return ret;
@@ -74,12 +74,12 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
u8 buf[MAX_XFER_SIZE];
struct i2c_msg msg[2] = {
{
- .addr = priv-cfg-i2c_address,
+ .addr = priv-client-addr,
.flags = 0,
.len = 1,
.buf = reg,
}, {
- .addr = priv-cfg-i2c_address,
+ .addr = priv-client-addr,
.flags = I2C_M_RD,
.len = len,
.buf = buf,
@@ -87,19 +87,19 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
};
if (len sizeof(buf)) {
- dev_warn(priv-i2c-dev,
+ dev_warn(priv-client-dev,
%s: i2c rd reg=%04x: len=%d is too big!\n,
KBUILD_MODNAME, reg, len);
return -EINVAL;
}
- ret = i2c_transfer(priv-i2c, msg, 2);
+ ret = i2c_transfer(priv-client-adapter, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
ret = 0;
} else {
- dev_warn(priv-i2c-dev, %s: i2c rd failed=%d reg=%02x \
- len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ dev_warn(priv-client-dev, %s: i2c rd failed=%d reg=%02x
len=%d\n,
+ KBUILD_MODNAME, ret, reg, len);
ret = -EREMOTEIO;
}
@@ -166,7 +166,7 @@ static int tda18212_set_params(struct dvb_frontend *fe)
[ATSC_QAM] = { 0x7d, 0x20, 0x63 },
};
- dev_dbg(priv-i2c-dev,
+ dev_dbg(priv-client-dev,
%s: delivery_system=%d frequency=%d bandwidth_hz=%d\n,
__func__, c-delivery_system, c-frequency,
c-bandwidth_hz);
@@ -176,25 +176,25 @@ static int tda18212_set_params(struct dvb_frontend *fe)
switch (c-delivery_system) {
case SYS_ATSC:
- if_khz = priv-cfg-if_atsc_vsb;
+ if_khz = priv-cfg.if_atsc_vsb;
i = ATSC_VSB;
break;
case SYS_DVBC_ANNEX_B:
- if_khz = priv-cfg-if_atsc_qam;
+ if_khz = priv-cfg.if_atsc_qam;
i = ATSC_QAM;
break;
case SYS_DVBT:
switch (c-bandwidth_hz) {
case 600:
- if_khz = priv-cfg-if_dvbt_6;
+ if_khz = priv-cfg.if_dvbt_6;
i = DVBT_6;
break;
case 700:
- if_khz = priv-cfg-if_dvbt_7;
+ if_khz = priv-cfg.if_dvbt_7;
[PATCH v2 2/8] tda18212: prepare for I2C client conversion
We need carry pointer to frontend via config struct
(I2C platform_data ptr) when I2C model is used. Add that pointer
first in order to keep build unbreakable during conversion.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/tuners/tda18212.h b/drivers/media/tuners/tda18212.h
index c36b49e..265559a 100644
--- a/drivers/media/tuners/tda18212.h
+++ b/drivers/media/tuners/tda18212.h
@@ -37,6 +37,11 @@ struct tda18212_config {
u16 if_dvbc;
u16 if_atsc_vsb;
u16 if_atsc_qam;
+
+ /*
+* pointer to DVB frontend
+*/
+ struct dvb_frontend *fe;
};
#if IS_ENABLED(CONFIG_MEDIA_TUNER_TDA18212)
--
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 v2 4/8] em28xx: convert tda18212 tuner to I2C client
Used tda18212 tuner is implemented as a I2C driver. Use em28xx
tuner I2C client for tda18212 driver.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/em28xx/em28xx-dvb.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 0645793..9682c52 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -373,7 +373,6 @@ static struct tda18271_config kworld_ub435q_v2_config = {
};
static struct tda18212_config kworld_ub435q_v3_config = {
- .i2c_address= 0x60,
.if_atsc_vsb= 3600,
.if_atsc_qam= 3600,
};
@@ -1437,6 +1436,15 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
break;
case EM2874_BOARD_KWORLD_UB435Q_V3:
+ {
+ struct i2c_client *client;
+ struct i2c_adapter *adapter = dev-i2c_adap[dev-def_i2c_bus];
+ struct i2c_board_info board_info = {
+ .type = tda18212,
+ .addr = 0x60,
+ .platform_data = kworld_ub435q_v3_config,
+ };
+
dvb-fe[0] = dvb_attach(lgdt3305_attach,
em2874_lgdt3305_nogate_dev,
dev-i2c_adap[dev-def_i2c_bus]);
@@ -1445,14 +1453,26 @@ static int em28xx_dvb_init(struct em28xx *dev)
goto out_free;
}
- /* Attach the demodulator. */
- if (!dvb_attach(tda18212_attach, dvb-fe[0],
- dev-i2c_adap[dev-def_i2c_bus],
- kworld_ub435q_v3_config)) {
- result = -EINVAL;
+ /* attach tuner */
+ kworld_ub435q_v3_config.fe = dvb-fe[0];
+ request_module(tda18212);
+ client = i2c_new_device(adapter, board_info);
+ if (client == NULL || client-dev.driver == NULL) {
+ dvb_frontend_detach(dvb-fe[0]);
+ result = -ENODEV;
goto out_free;
}
+
+ if (!try_module_get(client-dev.driver-owner)) {
+ i2c_unregister_device(client);
+ dvb_frontend_detach(dvb-fe[0]);
+ result = -ENODEV;
+ goto out_free;
+ }
+
+ dvb-i2c_client_tuner = client;
break;
+ }
case EM2874_BOARD_PCTV_HD_MINI_80E:
dvb-fe[0] = dvb_attach(drx39xxj_attach,
dev-i2c_adap[dev-def_i2c_bus]);
if (dvb-fe[0] != NULL) {
--
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 v2 1/8] tda18212: add support for slave chip version
There is 2 different versions of that chip available, master and
slave. Slave is used only on dual tuner devices with master tuner.
Laser printing top of chip is 18212/M or 18212/S according to chip
version.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 05a4ac9..15b09f8 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -306,7 +306,8 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
{
struct tda18212_priv *priv = NULL;
int ret;
- u8 val;
+ u8 chip_id = chip_id;
+ char *version;
priv = kzalloc(sizeof(struct tda18212_priv), GFP_KERNEL);
if (priv == NULL)
@@ -320,26 +321,38 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
fe-ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
/* check if the tuner is there */
- ret = tda18212_rd_reg(priv, 0x00, val);
+ ret = tda18212_rd_reg(priv, 0x00, chip_id);
+ dev_dbg(priv-i2c-dev, %s: chip_id=%02x\n, __func__, chip_id);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0); /* close I2C-gate */
- if (!ret)
- dev_dbg(priv-i2c-dev, %s: chip id=%02x\n, __func__, val);
- if (ret || val != 0xc7) {
- kfree(priv);
- return NULL;
+ if (ret)
+ goto err;
+
+ switch (chip_id) {
+ case 0xc7:
+ version = M; /* master */
+ break;
+ case 0x47:
+ version = S; /* slave */
+ break;
+ default:
+ goto err;
}
dev_info(priv-i2c-dev,
- %s: NXP TDA18212HN successfully identified\n,
- KBUILD_MODNAME);
+ %s: NXP TDA18212HN/%s successfully identified\n,
+ KBUILD_MODNAME, version);
memcpy(fe-ops.tuner_ops, tda18212_tuner_ops,
sizeof(struct dvb_tuner_ops));
return fe;
+err:
+ dev_dbg(i2c-dev, %s: failed=%d\n, __func__, ret);
+ kfree(priv);
+ return NULL;
}
EXPORT_SYMBOL(tda18212_attach);
--
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 v2 6/8] tda18212: clean logging
There is no need to print module name nor function name as those
are done by kernel logging system when dev_xxx logging is used and
driver is proper I2C driver.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/tda18212.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
index 659787b..5d1d785 100644
--- a/drivers/media/tuners/tda18212.c
+++ b/drivers/media/tuners/tda18212.c
@@ -47,8 +47,8 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
if (1 + len sizeof(buf)) {
dev_warn(priv-client-dev,
-%s: i2c wr reg=%04x: len=%d is too big!\n,
-KBUILD_MODNAME, reg, len);
+ i2c wr reg=%04x: len=%d is too big!\n,
+ reg, len);
return -EINVAL;
}
@@ -59,8 +59,9 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
if (ret == 1) {
ret = 0;
} else {
- dev_warn(priv-client-dev, %s: i2c wr failed=%d reg=%02x
len=%d\n,
- KBUILD_MODNAME, ret, reg, len);
+ dev_warn(priv-client-dev,
+ i2c wr failed=%d reg=%02x len=%d\n,
+ ret, reg, len);
ret = -EREMOTEIO;
}
return ret;
@@ -88,8 +89,8 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
if (len sizeof(buf)) {
dev_warn(priv-client-dev,
-%s: i2c rd reg=%04x: len=%d is too big!\n,
-KBUILD_MODNAME, reg, len);
+ i2c rd reg=%04x: len=%d is too big!\n,
+ reg, len);
return -EINVAL;
}
@@ -98,8 +99,9 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
memcpy(val, buf, len);
ret = 0;
} else {
- dev_warn(priv-client-dev, %s: i2c rd failed=%d reg=%02x
len=%d\n,
- KBUILD_MODNAME, ret, reg, len);
+ dev_warn(priv-client-dev,
+ i2c rd failed=%d reg=%02x len=%d\n,
+ ret, reg, len);
ret = -EREMOTEIO;
}
@@ -167,8 +169,8 @@ static int tda18212_set_params(struct dvb_frontend *fe)
};
dev_dbg(priv-client-dev,
- %s: delivery_system=%d frequency=%d bandwidth_hz=%d\n,
- __func__, c-delivery_system, c-frequency,
+ delivery_system=%d frequency=%d bandwidth_hz=%d\n,
+ c-delivery_system, c-frequency,
c-bandwidth_hz);
if (fe-ops.i2c_gate_ctrl)
@@ -266,7 +268,7 @@ exit:
return ret;
error:
- dev_dbg(priv-client-dev, %s: failed=%d\n, __func__, ret);
+ dev_dbg(priv-client-dev, failed=%d\n, ret);
goto exit;
}
@@ -305,7 +307,7 @@ static int tda18212_probe(struct i2c_client *client,
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
- dev_err(client-dev, %s: kzalloc() failed\n, KBUILD_MODNAME);
+ dev_err(client-dev, kzalloc() failed\n);
goto err;
}
@@ -317,7 +319,7 @@ static int tda18212_probe(struct i2c_client *client,
fe-ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
ret = tda18212_rd_reg(priv, 0x00, chip_id);
- dev_dbg(priv-client-dev, %s: chip_id=%02x\n, __func__, chip_id);
+ dev_dbg(priv-client-dev, chip_id=%02x\n, chip_id);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0); /* close I2C-gate */
@@ -338,8 +340,7 @@ static int tda18212_probe(struct i2c_client *client,
}
dev_info(priv-client-dev,
- %s: NXP TDA18212HN/%s successfully identified\n,
- KBUILD_MODNAME, version);
+ NXP TDA18212HN/%s successfully identified\n, version);
fe-tuner_priv = priv;
memcpy(fe-ops.tuner_ops, tda18212_tuner_ops,
@@ -348,7 +349,7 @@ static int tda18212_probe(struct i2c_client *client,
return 0;
err:
- dev_dbg(client-dev, %s: failed=%d\n, __func__, ret);
+ dev_dbg(client-dev, failed=%d\n, ret);
kfree(priv);
return ret;
}
@@ -358,7 +359,7 @@ static int tda18212_remove(struct i2c_client *client)
struct tda18212_priv *priv = i2c_get_clientdata(client);
struct dvb_frontend *fe = priv-cfg.fe;
- dev_dbg(client-dev, %s:\n, __func__);
+ dev_dbg(client-dev, \n);
memset(fe-ops.tuner_ops, 0, sizeof(struct dvb_tuner_ops));
fe-tuner_priv = NULL;
--
http://palosaari.fi/
--
To unsubscribe from this list:
[PATCH v2 3/8] anysee: convert tda18212 tuner to I2C client
Used tda18212 tuner is implemented as I2C driver. Implement I2C
client to anysee and use it for tda18212.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/anysee.c | 185 +++---
drivers/media/usb/dvb-usb-v2/anysee.h | 3 +
2 files changed, 152 insertions(+), 36 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c
b/drivers/media/usb/dvb-usb-v2/anysee.c
index e4a2382..d3c5f23 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -332,7 +332,6 @@ static struct tda10023_config
anysee_tda10023_tda18212_config = {
};
static struct tda18212_config anysee_tda18212_config = {
- .i2c_address = (0xc0 1),
.if_dvbt_6 = 4150,
.if_dvbt_7 = 4150,
.if_dvbt_8 = 4150,
@@ -340,7 +339,6 @@ static struct tda18212_config anysee_tda18212_config = {
};
static struct tda18212_config anysee_tda18212_config2 = {
- .i2c_address = 0x60 /* (0xc0 1) */,
.if_dvbt_6 = 3550,
.if_dvbt_7 = 3700,
.if_dvbt_8 = 4150,
@@ -632,6 +630,92 @@ error:
return ret;
}
+static int anysee_add_i2c_dev(struct dvb_usb_device *d, char *type, u8 addr,
+ void *platform_data)
+{
+ int ret, num;
+ struct anysee_state *state = d_to_priv(d);
+ struct i2c_client *client;
+ struct i2c_adapter *adapter = d-i2c_adap;
+ struct i2c_board_info board_info = {
+ .addr = addr,
+ .platform_data = platform_data,
+ };
+
+ strlcpy(board_info.type, type, I2C_NAME_SIZE);
+
+ /* find first free client */
+ for (num = 0; num ANYSEE_I2C_CLIENT_MAX; num++) {
+ if (state-i2c_client[num] == NULL)
+ break;
+ }
+
+ dev_dbg(d-udev-dev, %s: num=%d\n, __func__, num);
+
+ if (num == ANYSEE_I2C_CLIENT_MAX) {
+ dev_err(d-udev-dev, %s: I2C client out of index\n,
+ KBUILD_MODNAME);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ request_module(board_info.type);
+
+ /* register I2C device */
+ client = i2c_new_device(adapter, board_info);
+ if (client == NULL || client-dev.driver == NULL) {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ /* increase I2C driver usage count */
+ if (!try_module_get(client-dev.driver-owner)) {
+ i2c_unregister_device(client);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ state-i2c_client[num] = client;
+ return 0;
+err:
+ dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
+ return ret;
+}
+
+static void anysee_del_i2c_dev(struct dvb_usb_device *d)
+{
+ int num;
+ struct anysee_state *state = d_to_priv(d);
+ struct i2c_client *client;
+
+ /* find last used client */
+ num = ANYSEE_I2C_CLIENT_MAX;
+ while (num--) {
+ if (state-i2c_client[num] != NULL)
+ break;
+ }
+
+ dev_dbg(d-udev-dev, %s: num=%d\n, __func__, num);
+
+ if (num == -1) {
+ dev_err(d-udev-dev, %s: I2C client out of index\n,
+ KBUILD_MODNAME);
+ goto err;
+ }
+
+ client = state-i2c_client[num];
+
+ /* decrease I2C driver usage count */
+ module_put(client-dev.driver-owner);
+
+ /* unregister I2C device */
+ i2c_unregister_device(client);
+
+ state-i2c_client[num] = NULL;
+err:
+ dev_dbg(d-udev-dev, %s: failed\n, __func__);
+}
+
static int anysee_frontend_attach(struct dvb_usb_adapter *adap)
{
struct anysee_state *state = adap_to_priv(adap);
@@ -640,12 +724,12 @@ static int anysee_frontend_attach(struct dvb_usb_adapter
*adap)
u8 tmp;
struct i2c_msg msg[2] = {
{
- .addr = anysee_tda18212_config.i2c_address,
+ .addr = 0x60,
.flags = 0,
.len = 1,
.buf = \x00,
}, {
- .addr = anysee_tda18212_config.i2c_address,
+ .addr = 0x60,
.flags = I2C_M_RD,
.len = 1,
.buf = tmp,
@@ -723,9 +807,11 @@ static int anysee_frontend_attach(struct dvb_usb_adapter
*adap)
/* probe TDA18212 */
tmp = 0;
ret = i2c_transfer(d-i2c_adap, msg, 2);
- if (ret == 2 tmp == 0xc7)
+ if (ret == 2 tmp == 0xc7) {
dev_dbg(d-udev-dev, %s: TDA18212 found\n,
__func__);
+ state-has_tda18212 = true;
+ }
else
tmp = 0;
@@ -939,46 +1025,63 @@ static int anysee_tuner_attach(struct dvb_usb_adapter
*adap)
* fails
[GIT PULL] tda18212 improvements
The following changes since commit 89fffac802c18caebdf4e91c0785b522c9f6399a: [media] drxk_hard: fix bad alignments (2014-09-03 19:19:18 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git tda18212 for you to fetch changes up to 69afce975bd1978941b5174eb20f14bad58db667: tda18212: convert to RegMap API (2014-09-07 04:56:45 +0300) Antti Palosaari (8): tda18212: add support for slave chip version tda18212: prepare for I2C client conversion anysee: convert tda18212 tuner to I2C client em28xx: convert tda18212 tuner to I2C client tda18212: convert driver to I2C binding tda18212: clean logging tda18212: rename state from 'priv' to 'dev' tda18212: convert to RegMap API drivers/media/tuners/Kconfig | 1 + drivers/media/tuners/tda18212.c | 272 +++ drivers/media/tuners/tda18212.h | 19 +++--- drivers/media/usb/dvb-usb-v2/anysee.c | 185 +++--- drivers/media/usb/dvb-usb-v2/anysee.h | 3 ++ drivers/media/usb/em28xx/em28xx-dvb.c | 32 + 6 files changed, 292 insertions(+), 220 deletions(-) -- 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
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: Sun Sep 7 04:00:16 CEST 2014 git branch: test git hash: 89fffac802c18caebdf4e91c0785b522c9f6399a gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK 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: WARNINGS linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16-i686: WARNINGS linux-3.17-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16-x86_64: WARNINGS linux-3.17-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
[ANNOUNCE] libdvbv5 API initial documentation
Hi, We're about to release a new version for the v4l-utils, with the libdvbv5 API improvements. To help developers to understand and use the library, I did an effort to document the major functionalities available at the library. Not everything is there yet, but it should cover already the functionality that most applications would use on it. It is still a draft, as we might change some things before the launch of version 1.4.0 of v4l-utils. So, feel free to take a look and review. The document is available at: http://linuxtv.org/docs/libdvbv5/dvb-demux_8h.html 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: [ANNOUNCE] libdvbv5 API initial documentation
Em Sun, 7 Sep 2014 02:35:32 -0300 Mauro Carvalho Chehab m.che...@samsung.com escreveu: Hi, We're about to release a new version for the v4l-utils, with the libdvbv5 API improvements. To help developers to understand and use the library, I did an effort to document the major functionalities available at the library. Not everything is there yet, but it should cover already the functionality that most applications would use on it. It is still a draft, as we might change some things before the launch of version 1.4.0 of v4l-utils. So, feel free to take a look and review. The document is available at: http://linuxtv.org/docs/libdvbv5/dvb-demux_8h.html Hmm... Actually, the main page is at: http://linuxtv.org/docs/libdvbv5/index.html Ah, provided that doxygen is installed, the documentation can be generated from the v4l-utils on several formats, including man pages. In order to do that, you need to run (from the latest v4l-utils git tree main branch): $ autoreconf -vfi $ ./configure --enable-doxygen-man (to enable manpage format, if desired) To generate the doxygen docs, run: $ make doxygen-run Have fun! 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
az6027.c:undefined reference to `stb0899_attach'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2b12164b55e76e421c069de2cdf6b04c077983f1 commit: 7b34be71db533f3e0cf93d53cf62d036cdb5418a [media] use IS_ENABLED() macro date: 1 year, 7 months ago config: i386-randconfig-ib0-09071244 (attached as .config) All error/warnings: drivers/built-in.o: In function `az6027_frontend_attach': az6027.c:(.text+0x1e203a): undefined reference to `stb0899_attach' --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.8.0-rc3 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_NOCB_CPU=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_MM_OWNER=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set CONFIG_HAVE_UID16=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y
