RE: [PATCH 2/2] v4l: s5p-mfc: Limit enum_fmt to output formats of current version
Hi Pawel,
From: Pawel Osciak [mailto:posc...@chromium.org]
Sent: Tuesday, May 20, 2014 3:47 AM
Hi Kamil,
I like the solution as well. Two suggestions to consider below.
On Fri, May 16, 2014 at 9:03 PM, Kamil Debski k.deb...@samsung.com
wrote:
MFC versions support a different set of formats, this specially
applies to the raw YUV formats. This patch changes enum_fmt, so that
it only reports formats that are supported by the used MFC version.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 9370c34..d5efb10 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -223,6 +223,7 @@ struct s5p_mfc_buf_align { struct
s5p_mfc_variant
{
unsigned int version;
unsigned int port_num;
+ u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
struct s5p_mfc_buf_align *buf_align;
char*fw_name;
@@ -666,6 +667,7 @@ struct s5p_mfc_fmt {
u32 codec_mode;
enum s5p_mfc_fmt_type type;
u32 num_planes;
+ u32 versions;
};
/**
@@ -705,4 +707,9 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx
*ctx);
#define IS_MFCV6_PLUS(dev) (dev-variant-version = 0x60 ? 1 :
0)
#define IS_MFCV7_PLUS(dev) (dev-variant-version = 0x70 ? 1 :
0)
+#define MFC_V5 BIT(0)
+#define MFC_V6 BIT(1)
+#define MFC_V7 BIT(2)
These may be confusing. I'd suggest at least suffixing those macros
with _BIT.
Or better yet, please make this into an enum and also make
variant-versions of size BITS_TO_LONGS() with max enum value.
I think I'll stick with adding the _BIT suffix.
/* Get format */
@@ -384,11 +402,9 @@ static int vidioc_try_fmt(struct file *file,
void *priv, struct v4l2_format *f)
mfc_err(Unknown codec\n);
return -EINVAL;
}
- if (!IS_MFCV6_PLUS(dev)) {
- if (fmt-fourcc == V4L2_PIX_FMT_VP8) {
- mfc_err(Not supported format.\n);
- return -EINVAL;
- }
+ if ((dev-variant-version_bit fmt-versions) == 0)
{
+ mfc_err(Unsupported format by this MFC
version.\n);
+ return -EINVAL;
What do you think of moving this check to find_format()? You wouldn't
have to duplicate it across enum_fmt and try_fmt then...
Find_format is used as a helper for try_fmt and is not used by enum_fmt.
Enum_fmt does also some other checks and operates iterates the formats
array directly, so I think the change included in this patch is ok.
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
--
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: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
Also adding dri-devel and linux-media. Please don't forget these lists for
the next round.
-Daniel
On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
Adding Greg just as an fyi since we've chatted briefly about the avsink
bus. Comments below.
-Daniel
On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
This RFC is based on previous discussion to set up a generic communication
channel between display and audio driver and
an internal design of Intel MCG/VPG HDMI audio driver. It's still an
initial draft and your advice would be appreciated
to improve the design.
The basic idea is to create a new avsink module and let both drm and alsa
depend on it.
This new module provides a framework and APIs for synchronization between
the display and audio driver.
1. Display/Audio Client
The avsink core provides APIs to create, register and lookup a
display/audio client.
A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver)
can create a client, add some resources
objects (shared power wells, display outputs, and audio inputs, register
ops) to the client, and then register this
client to avisink core. The peer driver can look up a registered client by
a name or type, or both. If a client gives
a valid peer client name on registration, avsink core will bind the two
clients as peer for each other. And we
expect a display client and an audio client to be peers for each other in a
system.
int avsink_new_client ( const char *name,
int type, /* client type, display or audio */
struct module *module,
void *context,
const char *peer_name,
struct avsink_client **client_ret);
int avsink_free_client (struct avsink_client *client);
Hm, my idea was to create a new avsink bus and let vga drivers register
devices on that thing and audio drivers register as drivers. There's a bit
more work involved in creating a full-blown bus, but it has a lot of
upsides:
- Established infrastructure for matching drivers (i.e. audio drivers)
against devices (i.e. avsinks exported by gfx drivers).
- Module refcounting.
- power domain handling and well-integrated into runtime pm.
- Allows integration into componentized device framework since we're
dealing with a real struct device.
- Better decoupling between gfx and audio side since registration is done
at runtime.
- We can attach drv private date which the audio driver needs.
int avsink_register_client(struct avsink_client *client);
int avisink_unregister_client(int client_handle);
struct avsink_client *avsink_lookup_client(const char *name, int type);
struct avsink_client {
const char *name; /* client name */
int type; /* client type*/
void *context;
struct module *module; /* top-level module for locking */
struct avsink_client *peer; /* peer client */
/* shared power wells */
struct avsink_power_well *power_well;
We need to have an struct power_domain here so that we can do proper
runtime pm. But like I've said above I think we actually want a full blown
struct device.
int num_power_wells;
/* endpoints, display outputs or audio inputs */
struct avsink_endpoint * endpoint;
int num_endpints;
struct avsink_registers_ops *reg_ops; /* ops to access registers
of a client */
void *private_data;
...
};
I think you're indeed implementing a full blown bus here ;-)
avsink-client = bus devices/childern
avsink-peer = driver for all this stuff
avsink-power_well = runtime pm support for the avsink bus
avsink-reg_ops = driver bind/unbind support
On system boots, the avsink module is loaded before the display and audio
driver module. And the display and audio
driver may be loaded on parallel.
* If a specific display driver (eg. i915) supports avsink, it can create a
display client, add power wells and display
outputs to the client, and then register the display client to the avsink
core. Then it may look up if there is any
audio client registered, by name or type, and may find an audio client
registered by some audio driver.
* If an audio driver supports avsink, it usually should look up a
registered display client by name or type at first,
because it may need the shared power well in GPU and check the display
outputs' name to bind the audio inputs. If
the display client is not registered yet, the audio driver can choose to
wait (maybe in a work queue) or return
-EAGAIN for a deferred probe. After the display client is found, the
audio driver can register an audio client with
the display client's name as the peer name, the avsink core will bind the
display
[PATCH 2/3] [media] s5p-mfc: Support multiple firmware sub-versions
For MFC firmwares, improved versions with bug fixes and
feature additions are released keeping the firmware version
including major and minor number same. The issue came with
the release of a new MFCv6 firmware with an interface change.
This patch adds the support of accepting multiple firmware
binaries for every version with the driver trying to load
firmwares starting from latest. This ensures full backward
compatibility regardless of which firmware version and kernel
version is used.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|9 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 ++-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 15 ---
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8da4c23..514e7ec 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1343,7 +1343,7 @@ static struct s5p_mfc_variant mfc_drvdata_v5 = {
.port_num = MFC_NUM_PORTS,
.buf_size = buf_size_v5,
.buf_align = mfc_buf_align_v5,
- .fw_name= s5p-mfc.fw,
+ .fw_name[0] = s5p-mfc.fw,
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
@@ -1370,7 +1370,8 @@ static struct s5p_mfc_variant mfc_drvdata_v6 = {
.port_num = MFC_NUM_PORTS_V6,
.buf_size = buf_size_v6,
.buf_align = mfc_buf_align_v6,
- .fw_name= s5p-mfc-v6.fw,
+ .fw_name[0] = s5p-mfc-v6.fw,
+ .fw_name[1] = s5p-mfc-v6-v2.fw,
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
@@ -1397,7 +1398,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7 = {
.port_num = MFC_NUM_PORTS_V7,
.buf_size = buf_size_v7,
.buf_align = mfc_buf_align_v7,
- .fw_name= s5p-mfc-v7.fw,
+ .fw_name[0] = s5p-mfc-v7.fw,
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
@@ -1424,7 +1425,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8 = {
.port_num = MFC_NUM_PORTS_V8,
.buf_size = buf_size_v8,
.buf_align = mfc_buf_align_v8,
- .fw_name= s5p-mfc-v8.fw,
+ .fw_name[0] = s5p-mfc-v8.fw,
};
static struct platform_device_id mfc_driver_ids[] = {
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 89681c3..de60185 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -38,6 +38,8 @@
#define MFC_BANK2_ALIGN_ORDER 13
#define MFC_BASE_ALIGN_ORDER 17
+#define MFC_FW_MAX_VERSIONS2
+
#include media/videobuf2-dma-contig.h
static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
@@ -163,6 +165,11 @@ enum s5p_mfc_decode_arg {
MFC_DEC_RES_CHANGE,
};
+enum s5p_mfc_fw_ver {
+ MFC_FW_V1,
+ MFC_FW_V2,
+};
+
#define MFC_BUF_FLAG_USED (1 0)
#define MFC_BUF_FLAG_EOS (1 1)
@@ -225,7 +232,7 @@ struct s5p_mfc_variant {
u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
struct s5p_mfc_buf_align *buf_align;
- char*fw_name;
+ char*fw_name[MFC_FW_MAX_VERSIONS];
};
/**
@@ -287,6 +294,7 @@ struct s5p_mfc_priv_buf {
* @warn_start:hardware error code from which warnings start
* @mfc_ops: ops structure holding HW operation function pointers
* @mfc_cmds: cmd structure holding HW commands function pointers
+ * @fw_ver:loaded firmware sub-version
*
*/
struct s5p_mfc_dev {
@@ -331,6 +339,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
+ enum s5p_mfc_fw_ver fw_ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index c97c7c8..7aabcdb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -78,14 +78,23 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
{
struct firmware *fw_blob;
- int err;
+ int err = -EINVAL, i;
/* Firmare has to be present as a separate file or compiled
* into kernel. */
mfc_debug_enter();
- err = request_firmware((const struct firmware **)fw_blob,
-dev-variant-fw_name, dev-v4l2_dev.dev);
+ for (i = MFC_FW_MAX_VERSIONS - 1; i = 0; i--) {
+ if (!dev-variant-fw_name[i])
+ continue;
+ err = request_firmware((const struct firmware **)fw_blob,
+ dev-variant-fw_name[i], dev-v4l2_dev.dev);
+ if (!err) {
+ dev-fw_ver =
[PATCH 0/3] Support for multiple MFC FW sub-versions
This patchset is for supporting multple firmware sub-versions for MFC. Newer firmwares come with changed interfaces and fixes without any change in the fw version number. So this implementation is as per Tomasz Figa's suggestion [1]. [1] http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/31735 Arun Kumar K (3): [media] s5p-mfc: Remove duplicate function s5p_mfc_reload_firmware [media] s5p-mfc: Support multiple firmware sub-versions [media] s5p-mfc: Add init buffer cmd to MFCV6 drivers/media/platform/s5p-mfc/s5p_mfc.c| 11 +++--- drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 44 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++-- 4 files changed, 30 insertions(+), 42 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] s5p-mfc: Add init buffer cmd to MFCV6
Latest MFC v6 firmware requires tile mode and loop filter
setting to be done as part of Init buffer command, in sync
with v7. This patch adds this support for new v6 firmware.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 4f5e0ea..c1c12f8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -48,6 +48,8 @@
#define WRITEL(data, reg) \
(WARN_ON_ONCE(!(reg)) ? 0 : writel((data), (reg)))
+#define IS_MFCV6_V2(dev) (!IS_MFCV7_PLUS(dev) dev-fw_ver == MFC_FW_V2)
+
/* Allocate temporary buffers for decoding */
static int s5p_mfc_alloc_dec_temp_buffers_v6(struct s5p_mfc_ctx *ctx)
{
@@ -1352,7 +1354,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
WRITEL(ctx-display_delay, mfc_regs-d_display_delay);
}
- if (IS_MFCV7_PLUS(dev)) {
+ if (IS_MFCV7_PLUS(dev) || IS_MFCV6_V2(dev)) {
WRITEL(reg, mfc_regs-d_dec_options);
reg = 0;
}
@@ -1367,7 +1369,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
if (ctx-dst_fmt-fourcc == V4L2_PIX_FMT_NV12MT_16X16)
reg |= (0x1 S5P_FIMV_D_OPT_TILE_MODE_SHIFT_V6);
- if (IS_MFCV7_PLUS(dev))
+ if (IS_MFCV7_PLUS(dev) || IS_MFCV6_V2(dev))
WRITEL(reg, mfc_regs-d_init_buffer_options);
else
WRITEL(reg, mfc_regs-d_dec_options);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] s5p-mfc: Remove duplicate function s5p_mfc_reload_firmware
The function s5p_mfc_reload_firmware is exactly same as
s5p_mfc_load_firmware. So removing the duplicate function.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 33 -
2 files changed, 1 insertion(+), 34 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 9ed0985..8da4c23 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -162,7 +162,7 @@ static void s5p_mfc_watchdog_worker(struct work_struct
*work)
/* Double check if there is at least one instance running.
* If no instance is in memory than no firmware should be present */
if (dev-num_inst 0) {
- ret = s5p_mfc_reload_firmware(dev);
+ ret = s5p_mfc_load_firmware(dev);
if (ret) {
mfc_err(Failed to reload FW\n);
goto unlock;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 6c3f8f7..c97c7c8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -107,39 +107,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
return 0;
}
-/* Reload firmware to MFC */
-int s5p_mfc_reload_firmware(struct s5p_mfc_dev *dev)
-{
- struct firmware *fw_blob;
- int err;
-
- /* Firmare has to be present as a separate file or compiled
-* into kernel. */
- mfc_debug_enter();
-
- err = request_firmware((const struct firmware **)fw_blob,
-dev-variant-fw_name, dev-v4l2_dev.dev);
- if (err != 0) {
- mfc_err(Firmware is not present in the /lib/firmware directory
nor compiled in kernel\n);
- return -EINVAL;
- }
- if (fw_blob-size dev-fw_size) {
- mfc_err(MFC firmware is too big to be loaded\n);
- release_firmware(fw_blob);
- return -ENOMEM;
- }
- if (!dev-fw_virt_addr) {
- mfc_err(MFC firmware is not allocated\n);
- release_firmware(fw_blob);
- return -EINVAL;
- }
- memcpy(dev-fw_virt_addr, fw_blob-data, fw_blob-size);
- wmb();
- release_firmware(fw_blob);
- mfc_debug_leave();
- return 0;
-}
-
/* Release firmware memory */
int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] USB: as102_usb_drv.c: Remove useless return variables
This patch remove variables that are initialized with a constant,
are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.
Verified by compilation only.
The coccinelle script that find and fixes this issue is:
// smpl
@@
type T;
constant C;
identifier ret;
@@
- T ret = C;
... when != ret
- return ret;
+ return C;
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
drivers/staging/media/as102/as102_usb_drv.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/as102/as102_usb_drv.c
b/drivers/staging/media/as102/as102_usb_drv.c
index e4a6945..e6f6278 100644
--- a/drivers/staging/media/as102/as102_usb_drv.c
+++ b/drivers/staging/media/as102/as102_usb_drv.c
@@ -249,7 +249,7 @@ static void as102_free_usb_stream_buffer(struct as102_dev_t
*dev)
static int as102_alloc_usb_stream_buffer(struct as102_dev_t *dev)
{
- int i, ret = 0;
+ int i;
dev-stream = usb_alloc_coherent(dev-bus_adap.usb_dev,
MAX_STREAM_URB * AS102_USB_BUF_SIZE,
@@ -280,7 +280,7 @@ static int as102_alloc_usb_stream_buffer(struct as102_dev_t
*dev)
dev-stream_urb[i] = urb;
}
- return ret;
+ return 0;
}
static void as102_usb_stop_stream(struct as102_dev_t *dev)
@@ -458,7 +458,6 @@ exit:
static int as102_release(struct inode *inode, struct file *file)
{
- int ret = 0;
struct as102_dev_t *dev = NULL;
dev = file-private_data;
@@ -467,7 +466,7 @@ static int as102_release(struct inode *inode, struct file
*file)
kref_put(dev-kref, as102_usb_release);
}
- return ret;
+ return 0;
}
MODULE_DEVICE_TABLE(usb, as102_usb_id_table);
--
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] v4l: s5p-mfc: Limit enum_fmt to output formats of current version
MFC versions support a different set of formats, this specially applies
to the raw YUV formats. This patch changes enum_fmt, so that it only
reports formats that are supported by the used MFC version.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|3 ++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |7
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 49 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 50 ---
4 files changed, 67 insertions(+), 42 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 2ab90dd..2ae7168 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1339,6 +1339,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v5 = {
static struct s5p_mfc_variant mfc_drvdata_v5 = {
.version= MFC_VERSION,
+ .version_bit= MFC_V5_BIT,
.port_num = MFC_NUM_PORTS,
.buf_size = buf_size_v5,
.buf_align = mfc_buf_align_v5,
@@ -1365,6 +1366,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v6 = {
static struct s5p_mfc_variant mfc_drvdata_v6 = {
.version= MFC_VERSION_V6,
+ .version_bit= MFC_V6_BIT,
.port_num = MFC_NUM_PORTS_V6,
.buf_size = buf_size_v6,
.buf_align = mfc_buf_align_v6,
@@ -1391,6 +1393,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v7 = {
static struct s5p_mfc_variant mfc_drvdata_v7 = {
.version= MFC_VERSION_V7,
+ .version_bit= MFC_V7_BIT,
.port_num = MFC_NUM_PORTS_V7,
.buf_size = buf_size_v7,
.buf_align = mfc_buf_align_v7,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 993c993..4f3d38e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -223,6 +223,7 @@ struct s5p_mfc_buf_align {
struct s5p_mfc_variant {
unsigned int version;
unsigned int port_num;
+ u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
struct s5p_mfc_buf_align *buf_align;
char*fw_name;
@@ -664,6 +665,7 @@ struct s5p_mfc_fmt {
u32 codec_mode;
enum s5p_mfc_fmt_type type;
u32 num_planes;
+ u32 versions;
};
/**
@@ -703,4 +705,9 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
#define IS_MFCV6_PLUS(dev) (dev-variant-version = 0x60 ? 1 : 0)
#define IS_MFCV7_PLUS(dev) (dev-variant-version = 0x70 ? 1 : 0)
+#define MFC_V5_BIT BIT(0)
+#define MFC_V6_BIT BIT(1)
+#define MFC_V7_BIT BIT(2)
+
+
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index ac43a4a..641ff07 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -39,6 +39,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = 4:2:0 2 Planes 64x32 Tiles,
@@ -46,6 +47,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V5_BIT,
},
{
.name = 4:2:0 2 Planes Y/CbCr,
@@ -53,6 +55,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = 4:2:0 2 Planes Y/CrCb,
@@ -60,6 +63,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = H264 Encoded Stream,
@@ -67,6 +71,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
+ .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = H264/MVC Encoded Stream,
@@ -74,6 +79,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_MVC_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
+
Re: [PATCH 2/3] [media] s5p-mfc: Support multiple firmware sub-versions
Hi Arun,
On 20 May 2014 15:47, Arun Kumar K arun...@samsung.com wrote:
For MFC firmwares, improved versions with bug fixes and
feature additions are released keeping the firmware version
including major and minor number same. The issue came with
the release of a new MFCv6 firmware with an interface change.
This patch adds the support of accepting multiple firmware
binaries for every version with the driver trying to load
firmwares starting from latest. This ensures full backward
compatibility regardless of which firmware version and kernel
version is used.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|9 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 ++-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 15 ---
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8da4c23..514e7ec 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1343,7 +1343,7 @@ static struct s5p_mfc_variant mfc_drvdata_v5 = {
.port_num = MFC_NUM_PORTS,
.buf_size = buf_size_v5,
.buf_align = mfc_buf_align_v5,
- .fw_name= s5p-mfc.fw,
+ .fw_name[0] = s5p-mfc.fw,
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v6 = {
@@ -1370,7 +1370,8 @@ static struct s5p_mfc_variant mfc_drvdata_v6 = {
.port_num = MFC_NUM_PORTS_V6,
.buf_size = buf_size_v6,
.buf_align = mfc_buf_align_v6,
- .fw_name= s5p-mfc-v6.fw,
+ .fw_name[0] = s5p-mfc-v6.fw,
+ .fw_name[1] = s5p-mfc-v6-v2.fw,
Probably a simple 1 line comment about the difference between the
versions would help.
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
@@ -1397,7 +1398,7 @@ static struct s5p_mfc_variant mfc_drvdata_v7 = {
.port_num = MFC_NUM_PORTS_V7,
.buf_size = buf_size_v7,
.buf_align = mfc_buf_align_v7,
- .fw_name= s5p-mfc-v7.fw,
+ .fw_name[0] = s5p-mfc-v7.fw,
};
struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
@@ -1424,7 +1425,7 @@ static struct s5p_mfc_variant mfc_drvdata_v8 = {
.port_num = MFC_NUM_PORTS_V8,
.buf_size = buf_size_v8,
.buf_align = mfc_buf_align_v8,
- .fw_name= s5p-mfc-v8.fw,
+ .fw_name[0] = s5p-mfc-v8.fw,
};
static struct platform_device_id mfc_driver_ids[] = {
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 89681c3..de60185 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -38,6 +38,8 @@
#define MFC_BANK2_ALIGN_ORDER 13
#define MFC_BASE_ALIGN_ORDER 17
+#define MFC_FW_MAX_VERSIONS2
+
#include media/videobuf2-dma-contig.h
static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
@@ -163,6 +165,11 @@ enum s5p_mfc_decode_arg {
MFC_DEC_RES_CHANGE,
};
+enum s5p_mfc_fw_ver {
+ MFC_FW_V1,
+ MFC_FW_V2,
+};
+
#define MFC_BUF_FLAG_USED (1 0)
#define MFC_BUF_FLAG_EOS (1 1)
@@ -225,7 +232,7 @@ struct s5p_mfc_variant {
u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
struct s5p_mfc_buf_align *buf_align;
- char*fw_name;
+ char*fw_name[MFC_FW_MAX_VERSIONS];
};
/**
@@ -287,6 +294,7 @@ struct s5p_mfc_priv_buf {
* @warn_start:hardware error code from which warnings start
* @mfc_ops: ops structure holding HW operation function pointers
* @mfc_cmds: cmd structure holding HW commands function pointers
+ * @fw_ver:loaded firmware sub-version
*
*/
struct s5p_mfc_dev {
@@ -331,6 +339,7 @@ struct s5p_mfc_dev {
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
const struct s5p_mfc_regs *mfc_regs;
+ enum s5p_mfc_fw_ver fw_ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index c97c7c8..7aabcdb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -78,14 +78,23 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
{
struct firmware *fw_blob;
- int err;
+ int err = -EINVAL, i;
nit: Please use either
int i, err = -EINVAL;
or
int i;
int err = -EINVAL;
/* Firmare has to be present as a separate file or compiled
* into kernel. */
mfc_debug_enter();
- err = request_firmware((const struct firmware **)fw_blob,
-
Re: [linuxtv-samsung:for-v3.16 45/81] drivers/media/dvb-frontends/si2168.c:47 si2168_cmd_execute() warn: add some parenthesis here?
On Mon, May 05, 2014 at 11:52:46PM +0300, Antti Palosaari wrote:
845f3505 Antti Palosaari 2014-04-10 46
845f3505 Antti Palosaari 2014-04-10 @47 if (!(cmd-args[0]
7) 0x01) {
This should be: if
(!((md-args[0] 7) 0x01)) {
Otherwise it is a precedence error where it does the negate before the
bitwise AND.
That was already on my TODO list as daily media build test sparse
warned it already http://hverkuil.home.xs4all.nl/logs/Monday.log
I am waiting for media/master kernel upgrades from 3.15-rc1 as that
kernel will hang whole machine when em28xx driver used (em28xx
driver is USB bridge for those si2168 and si2157).
Wait, what? This is a one liner. I haven't understood the connection
with 3.15-rc1?
regards,
dan carpenter
--
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: [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
Also adding dri-devel and linux-media. Please don't forget these lists for
the next round.
-Daniel
On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
Adding Greg just as an fyi since we've chatted briefly about the avsink
bus. Comments below.
-Daniel
On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
This RFC is based on previous discussion to set up a generic
communication channel between display and audio driver and
an internal design of Intel MCG/VPG HDMI audio driver. It's still an
initial draft and your advice would be appreciated
to improve the design.
The basic idea is to create a new avsink module and let both drm and alsa
depend on it.
This new module provides a framework and APIs for synchronization between
the display and audio driver.
1. Display/Audio Client
The avsink core provides APIs to create, register and lookup a
display/audio client.
A specific display driver (eg. i915) or audio driver (eg. HD-Audio
driver) can create a client, add some resources
objects (shared power wells, display outputs, and audio inputs, register
ops) to the client, and then register this
client to avisink core. The peer driver can look up a registered client
by a name or type, or both. If a client gives
a valid peer client name on registration, avsink core will bind the two
clients as peer for each other. And we
expect a display client and an audio client to be peers for each other in
a system.
int avsink_new_client ( const char *name,
int type, /* client type, display or audio
*/
struct module *module,
void *context,
const char *peer_name,
struct avsink_client **client_ret);
int avsink_free_client (struct avsink_client *client);
Hm, my idea was to create a new avsink bus and let vga drivers register
devices on that thing and audio drivers register as drivers. There's a bit
more work involved in creating a full-blown bus, but it has a lot of
upsides:
- Established infrastructure for matching drivers (i.e. audio drivers)
against devices (i.e. avsinks exported by gfx drivers).
- Module refcounting.
- power domain handling and well-integrated into runtime pm.
- Allows integration into componentized device framework since we're
dealing with a real struct device.
- Better decoupling between gfx and audio side since registration is done
at runtime.
- We can attach drv private date which the audio driver needs.
I think this would be another case where the interface framework[0]
could potentially be used. It doesn't give you all of the above, but
there's no reason it couldn't be extended. Then again, adding too much
would end up duplicating more of the driver core, so if something really
heavy-weight is required here, then the interface framework is not the
best option.
[0]: https://lkml.org/lkml/2014/5/13/525
On system boots, the avsink module is loaded before the display and audio
driver module. And the display and audio
driver may be loaded on parallel.
* If a specific display driver (eg. i915) supports avsink, it can create
a display client, add power wells and display
outputs to the client, and then register the display client to the
avsink core. Then it may look up if there is any
audio client registered, by name or type, and may find an audio client
registered by some audio driver.
* If an audio driver supports avsink, it usually should look up a
registered display client by name or type at first,
because it may need the shared power well in GPU and check the display
outputs' name to bind the audio inputs. If
the display client is not registered yet, the audio driver can choose
to wait (maybe in a work queue) or return
-EAGAIN for a deferred probe. After the display client is found, the
audio driver can register an audio client with
-EPROBE_DEFER is the correct error code for deferred probing.
6. Display register operation (optional)
Some audio driver needs to access GPU audio registers. The register ops
are provided by the peer display client.
struct avsink_registers_ops {
int (*read_register) (uint32_t reg_addr, uint32_t *data, void
*context);
int (*write_register) (uint32_t reg_addr, uint32_t data, void
*context);
int (*read_modify_register) (uint32_t reg_addr, uint32_t data,
uint32_t mask, void *context);
int avsink_define_reg_ops (struct avsink_client *client, struct
avsink_registers_ops *ops);
And avsink core provides API for the audio driver to access the display
registers:
int avsink_read_display_register(struct avsink_client *client ,
[PATCH v3] v4l: s5p-mfc: Limit enum_fmt to output formats of current version
MFC versions support a different set of formats, this specially applies
to the raw YUV formats. This patch changes enum_fmt, so that it only
reports formats that are supported by the used MFC version.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
v2 included suggestions made by Pawel Osciak.
v3 includes a fix in the codecs supported by the MFC encoder.
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|3 ++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |7
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 49 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 50 ---
4 files changed, 67 insertions(+), 42 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 2ab90dd..2ae7168 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1339,6 +1339,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v5 = {
static struct s5p_mfc_variant mfc_drvdata_v5 = {
.version= MFC_VERSION,
+ .version_bit= MFC_V5_BIT,
.port_num = MFC_NUM_PORTS,
.buf_size = buf_size_v5,
.buf_align = mfc_buf_align_v5,
@@ -1365,6 +1366,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v6 = {
static struct s5p_mfc_variant mfc_drvdata_v6 = {
.version= MFC_VERSION_V6,
+ .version_bit= MFC_V6_BIT,
.port_num = MFC_NUM_PORTS_V6,
.buf_size = buf_size_v6,
.buf_align = mfc_buf_align_v6,
@@ -1391,6 +1393,7 @@ struct s5p_mfc_buf_align mfc_buf_align_v7 = {
static struct s5p_mfc_variant mfc_drvdata_v7 = {
.version= MFC_VERSION_V7,
+ .version_bit= MFC_V7_BIT,
.port_num = MFC_NUM_PORTS_V7,
.buf_size = buf_size_v7,
.buf_align = mfc_buf_align_v7,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 993c993..4f3d38e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -223,6 +223,7 @@ struct s5p_mfc_buf_align {
struct s5p_mfc_variant {
unsigned int version;
unsigned int port_num;
+ u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
struct s5p_mfc_buf_align *buf_align;
char*fw_name;
@@ -664,6 +665,7 @@ struct s5p_mfc_fmt {
u32 codec_mode;
enum s5p_mfc_fmt_type type;
u32 num_planes;
+ u32 versions;
};
/**
@@ -703,4 +705,9 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
#define IS_MFCV6_PLUS(dev) (dev-variant-version = 0x60 ? 1 : 0)
#define IS_MFCV7_PLUS(dev) (dev-variant-version = 0x70 ? 1 : 0)
+#define MFC_V5_BIT BIT(0)
+#define MFC_V6_BIT BIT(1)
+#define MFC_V7_BIT BIT(2)
+
+
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index ac43a4a..641ff07 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -39,6 +39,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = 4:2:0 2 Planes 64x32 Tiles,
@@ -46,6 +47,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V5_BIT,
},
{
.name = 4:2:0 2 Planes Y/CbCr,
@@ -53,6 +55,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = 4:2:0 2 Planes Y/CrCb,
@@ -60,6 +63,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
+ .versions = MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = H264 Encoded Stream,
@@ -67,6 +71,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
+ .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT,
},
{
.name = H264/MVC Encoded Stream,
@@ -74,6 +79,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode =
Re: [alsa-devel] [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
Date 20.5.2014 14:43, Thierry Reding wrote: On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote: Also adding dri-devel and linux-media. Please don't forget these lists for the next round. -Daniel On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote: Adding Greg just as an fyi since we've chatted briefly about the avsink bus. Comments below. -Daniel On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote: This RFC is based on previous discussion to set up a generic communication channel between display and audio driver and an internal design of Intel MCG/VPG HDMI audio driver. It's still an initial draft and your advice would be appreciated to improve the design. The basic idea is to create a new avsink module and let both drm and alsa depend on it. This new module provides a framework and APIs for synchronization between the display and audio driver. 1. Display/Audio Client The avsink core provides APIs to create, register and lookup a display/audio client. A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) can create a client, add some resources objects (shared power wells, display outputs, and audio inputs, register ops) to the client, and then register this client to avisink core. The peer driver can look up a registered client by a name or type, or both. If a client gives a valid peer client name on registration, avsink core will bind the two clients as peer for each other. And we expect a display client and an audio client to be peers for each other in a system. int avsink_new_client ( const char *name, int type, /* client type, display or audio */ struct module *module, void *context, const char *peer_name, struct avsink_client **client_ret); int avsink_free_client (struct avsink_client *client); Hm, my idea was to create a new avsink bus and let vga drivers register devices on that thing and audio drivers register as drivers. There's a bit more work involved in creating a full-blown bus, but it has a lot of upsides: - Established infrastructure for matching drivers (i.e. audio drivers) against devices (i.e. avsinks exported by gfx drivers). - Module refcounting. - power domain handling and well-integrated into runtime pm. - Allows integration into componentized device framework since we're dealing with a real struct device. - Better decoupling between gfx and audio side since registration is done at runtime. - We can attach drv private date which the audio driver needs. I think this would be another case where the interface framework[0] could potentially be used. It doesn't give you all of the above, but there's no reason it couldn't be extended. Then again, adding too much would end up duplicating more of the driver core, so if something really heavy-weight is required here, then the interface framework is not the best option. [0]: https://lkml.org/lkml/2014/5/13/525 This looks like the right direction. I would go in this way rather than create specific A/V grouping mechanisms. This seems to be applicable to more use cases. Jaroslav -- Jaroslav Kysela pe...@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc. -- 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: [linuxtv-samsung:for-v3.16 45/81] drivers/media/dvb-frontends/si2168.c:47 si2168_cmd_execute() warn: add some parenthesis here?
On 05/20/2014 03:01 PM, Dan Carpenter wrote:
On Mon, May 05, 2014 at 11:52:46PM +0300, Antti Palosaari wrote:
845f3505 Antti Palosaari 2014-04-10 46
845f3505 Antti Palosaari 2014-04-10 @47 if (!(cmd-args[0] 7)
0x01) {
This should be: if (!((md-args[0] 7)
0x01)) {
Otherwise it is a precedence error where it does the negate before the
bitwise AND.
That was already on my TODO list as daily media build test sparse
warned it already http://hverkuil.home.xs4all.nl/logs/Monday.log
I am waiting for media/master kernel upgrades from 3.15-rc1 as that
kernel will hang whole machine when em28xx driver used (em28xx
driver is USB bridge for those si2168 and si2157).
Wait, what? This is a one liner. I haven't understood the connection
with 3.15-rc1?
Current media master, which contains that brand new si2168 driver, is
3.15-rc1. That device is implemented as a)
em28xx driver - USB interface + remote controller
si2168 driver - DVB-T/T2/C digital TV demodulator
si2157 driver - RF tuner
For some reason em28xx freezes whole machine when that 3.15-rc1 kernel
is used. It is not only that device, but all the other em28xx devices
too what I have.
Even it is simple one liner, I tend to test all my patches before pull
requesting to media master tree. Sure, I can do it using linus latest
tree and then rebase to media master pull request, but it is all extra
work.
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: [RFC PATCH 2/2 with seqcount v3] reservation: add suppport for read-only access using rcu
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
op 19-05-14 15:42, Thomas Hellstrom schreef:
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
@@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
reservation_object *obj)
kfree(obj-staged);
obj-staged = NULL;
return 0;
-}
-max = old-shared_max * 2;
+} else
+max = old-shared_max * 2;
Perhaps as a separate reformatting patch?
I'll fold it in to the patch that added
reservation_object_reserve_shared.
+
+int reservation_object_get_fences_rcu(struct reservation_object *obj,
+ struct fence **pfence_excl,
+ unsigned *pshared_count,
+ struct fence ***pshared)
+{
+unsigned shared_count = 0;
+unsigned retry = 1;
+struct fence **shared = NULL, *fence_excl = NULL;
+int ret = 0;
+
+while (retry) {
+struct reservation_object_list *fobj;
+unsigned seq;
+
+seq = read_seqcount_begin(obj-seq);
+
+rcu_read_lock();
+
+fobj = rcu_dereference(obj-fence);
+if (fobj) {
+struct fence **nshared;
+
+shared_count = ACCESS_ONCE(fobj-shared_count);
ACCESS_ONCE() shouldn't be needed inside the seqlock?
Yes it is, shared_count may be increased, leading to potential
different sizes for krealloc and memcpy
if the ACCESS_ONCE is removed. I could use shared_max here instead,
which stays the same,
but it would waste more memory.
Maarten, Another perhaps ignorant question WRT this,
Does ACCESS_ONCE() guarantee that the value accessed is read atomically?
/Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2 with seqcount v3] reservation: add suppport for read-only access using rcu
op 20-05-14 17:13, Thomas Hellstrom schreef:
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
op 19-05-14 15:42, Thomas Hellstrom schreef:
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
@@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
reservation_object *obj)
kfree(obj-staged);
obj-staged = NULL;
return 0;
-}
-max = old-shared_max * 2;
+} else
+max = old-shared_max * 2;
Perhaps as a separate reformatting patch?
I'll fold it in to the patch that added
reservation_object_reserve_shared.
+
+int reservation_object_get_fences_rcu(struct reservation_object *obj,
+ struct fence **pfence_excl,
+ unsigned *pshared_count,
+ struct fence ***pshared)
+{
+unsigned shared_count = 0;
+unsigned retry = 1;
+struct fence **shared = NULL, *fence_excl = NULL;
+int ret = 0;
+
+while (retry) {
+struct reservation_object_list *fobj;
+unsigned seq;
+
+seq = read_seqcount_begin(obj-seq);
+
+rcu_read_lock();
+
+fobj = rcu_dereference(obj-fence);
+if (fobj) {
+struct fence **nshared;
+
+shared_count = ACCESS_ONCE(fobj-shared_count);
ACCESS_ONCE() shouldn't be needed inside the seqlock?
Yes it is, shared_count may be increased, leading to potential
different sizes for krealloc and memcpy
if the ACCESS_ONCE is removed. I could use shared_max here instead,
which stays the same,
but it would waste more memory.
Maarten, Another perhaps ignorant question WRT this,
Does ACCESS_ONCE() guarantee that the value accessed is read atomically?
Well I've reworked the code to use shared_max, so this point is moot. :-)
On any archs I'm aware of it would work, either the old or new value would be
visible, as long as natural alignment is used.
rcu uses the same trick in the rcu_dereference macro, so if this didn't work
rcu wouldn't work either.
~Maarten
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.15-rc6] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus Most of the changes are drivers fixes (rtl28xuu, fc2580, ov7670, davinci, gspca, s5p-fimc and s5c73m3). There is also a compat32 fix and one infoleak fixup at the media controller. Thanks! Mauro. - The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to 97d9d23dda6f37d90aefeec4ed619d52df525382: [media] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode (2014-05-13 20:03:31 -0300) Antti Palosaari (3): [media] rtl28xxu: do not hard depend on staging SDR module [media] rtl28xxu: silence error log about disabled rtl2832_sdr module [media] fc2580: fix tuning failure on 32-bit arch Guennadi Liakhovetski (2): [media] V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space [media] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode Jean Delvare (1): [media] Prefer gspca_sonixb over sn9c102 for all devices Lad, Prabhakar (5): [media] media: davinci: vpif_capture: fix releasing of active buffers [media] media: davinci: vpif_display: fix releasing of active buffers [media] media: davinci: vpbe_display: fix releasing of active buffers [media] staging: media: davinci: vpfe: make sure all the buffers are released [media] media: davinci: vpfe: make sure all the buffers unmapped and released Mauro Carvalho Chehab (1): Merge tag 'v3.15-rc1' into patchwork Nicolas Dufresne (1): [media] s5p-fimc: Fix YUV422P depth Salva Peiró (1): [media] media-device: fix infoleak in ioctl media_enum_entities() Sylwester Nawrocki (1): [media] s5c73m3: Add missing rename of v4l2_of_get_next_endpoint() function drivers/media/i2c/ov7670.c | 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/media-device.c | 1 + drivers/media/platform/davinci/vpbe_display.c| 16 +++- drivers/media/platform/davinci/vpfe_capture.c| 2 + drivers/media/platform/davinci/vpif_capture.c| 34 +++-- drivers/media/platform/davinci/vpif_display.c| 35 +++-- drivers/media/platform/exynos4-is/fimc-core.c| 2 +- drivers/media/tuners/fc2580.c| 6 +-- drivers/media/tuners/fc2580_priv.h | 1 + drivers/media/usb/dvb-usb-v2/Makefile| 1 - drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 48 +--- drivers/media/usb/gspca/sonixb.c | 2 - drivers/media/v4l2-core/v4l2-compat-ioctl32.c| 12 +++--- drivers/staging/media/davinci_vpfe/vpfe_video.c | 13 ++- drivers/staging/media/sn9c102/sn9c102_devtable.h | 2 - 16 files changed, 132 insertions(+), 47 deletions(-) -- 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 0/3] Support for multiple MFC FW sub-versions
Hi Arun, On 20.05.2014 12:17, Arun Kumar K wrote: This patchset is for supporting multple firmware sub-versions for MFC. Newer firmwares come with changed interfaces and fixes without any change in the fw version number. So this implementation is as per Tomasz Figa's suggestion [1]. [1] http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/31735 Arun Kumar K (3): [media] s5p-mfc: Remove duplicate function s5p_mfc_reload_firmware [media] s5p-mfc: Support multiple firmware sub-versions [media] s5p-mfc: Add init buffer cmd to MFCV6 drivers/media/platform/s5p-mfc/s5p_mfc.c| 11 +++--- drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 44 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |6 ++-- 4 files changed, 30 insertions(+), 42 deletions(-) The whole series looks good. Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/dma-buf-sharing.txt: update API descriptions
On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote: Update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim gioh@lge.com I applied this to my dma-api branch for v3.16, thanks! --- Documentation/dma-buf-sharing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..aadd901 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a - pointer to the same. It also associates an anonymous file with this buffer, - so it can be exported. On failure to allocate the dma_buf object, it returns - NULL. + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and + returns a pointer to the same. It also associates an anonymous file with this + buffer, so it can be exported. On failure to allocate the dma_buf object, + it returns NULL. 'exp_name' is the name of exporter - to facilitate information while debugging. @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. dma_buf-ops- indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
help needed to install and run (in Zoneminder) the DVR pci card JY 4008a
Are you able to assist with the above running Mageia4 32 bit sys but cannot seem to get a camera recognised in either xawtv or zoneminder Thanks for any help you can give me.Ernie Clarke clark...@slingshot.co.nz -- 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
[no subject]
subscribe -- 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
Fresco Logic FL2000
It was suggested to me to inquire here if anyone was working on drivers or support for the Fresco Logic FL2000 1d5c:2000 Mike KC7NOA -- 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: OK
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: Wed May 21 04:00:19 CEST 2014 git branch: test git hash: ba0d342ecc21fbbe2f6c178f4479944d1fb34f3b gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-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: OK linux-2.6.31.14-i686: OK 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: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK 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: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/dma-buf-sharing.txt: update API descriptions
Hi Bjorn, On 21 May 2014 04:50, Bjorn Helgaas bhelg...@google.com wrote: On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote: Update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim gioh@lge.com I applied this to my dma-api branch for v3.16, thanks! As always, I would queue this up for my dma-buf pull request, along with other dma-buf changes. Thanks and best regards, ~Sumit. --- Documentation/dma-buf-sharing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..aadd901 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a - pointer to the same. It also associates an anonymous file with this buffer, - so it can be exported. On failure to allocate the dma_buf object, it returns - NULL. + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and + returns a pointer to the same. It also associates an anonymous file with this + buffer, so it can be exported. On failure to allocate the dma_buf object, + it returns NULL. 'exp_name' is the name of exporter - to facilitate information while debugging. @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. dma_buf-ops- indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Thanks and regards, Sumit Semwal Graphics Engineer - Graphics working group Linaro.org │ Open source software for ARM SoCs -- 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] Documentation/dma-buf-sharing.txt: update API descriptions
On Tue, May 20, 2014 at 9:43 PM, Sumit Semwal sumit.sem...@linaro.org wrote: Hi Bjorn, On 21 May 2014 04:50, Bjorn Helgaas bhelg...@google.com wrote: On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote: Update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim gioh@lge.com I applied this to my dma-api branch for v3.16, thanks! As always, I would queue this up for my dma-buf pull request, along with other dma-buf changes. OK, I dropped this one. --- Documentation/dma-buf-sharing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..aadd901 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a - pointer to the same. It also associates an anonymous file with this buffer, - so it can be exported. On failure to allocate the dma_buf object, it returns - NULL. + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and + returns a pointer to the same. It also associates an anonymous file with this + buffer, so it can be exported. On failure to allocate the dma_buf object, + it returns NULL. 'exp_name' is the name of exporter - to facilitate information while debugging. @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. dma_buf-ops- indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Thanks and regards, Sumit Semwal Graphics Engineer - Graphics working group Linaro.org │ Open source software for ARM SoCs -- 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
