[PATCH] [0904_1] Siano: core header - update license and include files
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1238689930 -10800 # Node ID c3f0f50d46058f07fb355d8e5531f35cfd0ca37e # Parent 7311d23c3355629b617013cd51223895a2423770 [PATCH] [0904_1] Siano: core header - update license and included files From: Uri Shkolnik u...@siano-ms.com This patch does not include any implementation changes. It update the smscoreapi.h license to be identical to other Siano's headers and the #include files list. Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 7311d23c3355 -r c3f0f50d4605 linux/drivers/media/dvb/siano/smscoreapi.h --- a/linux/drivers/media/dvb/siano/smscoreapi.hSun Mar 15 12:05:57 2009 +0200 +++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:32:10 2009 +0300 @@ -1,26 +1,26 @@ -/* - * Driver for the Siano SMS1xxx USB dongle - * - * author: Anatoly Greenblat - * - * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation; - * - * Software distributed under the License is distributed on an AS IS - * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. - * - * See the GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ +/ -#ifndef __smscoreapi_h__ -#define __smscoreapi_h__ +Siano Mobile Silicon, Inc. +MDTV receiver kernel modules. +Copyright (C) 2006-2008, Uri Shkolnik, Anatoly Greenblat + +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. + +You should have received a copy of the GNU General Public License +along with this program. If not, see http://www.gnu.org/licenses/. + +/ + +#ifndef __SMS_CORE_API_H__ +#define __SMS_CORE_API_H__ #include linux/version.h #include linux/device.h @@ -28,15 +28,23 @@ #include linux/mm.h #include linux/scatterlist.h #include linux/types.h +#include linux/mutex.h +#include linux/compat.h +#include linux/wait.h +#include linux/timer.h + #include asm/page.h -#include linux/mutex.h -#include compat.h +/* #include smsir.h */ + +#define SMS_DVB3_SUBSYS +#ifdef SMS_DVB3_SUBSYS #include dmxdev.h #include dvbdev.h #include dvb_demux.h #include dvb_frontend.h +#endif #define kmutex_init(_p_) mutex_init(_p_) #define kmutex_lock(_p_) mutex_lock(_p_) @@ -598,4 +606,4 @@ int smscore_led_state(struct smscore_dev dprintk(KERN_DEBUG, DBG_ADV, fmt, ##arg) -#endif /* __smscoreapi_h__ */ +#endif /* __SMS_CORE_API_H__ */ -- 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] [0904_2] Siano: core header - add definitions and structures
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238690859 -10800
# Node ID 05cf6606192642241ff25a152e249118cb8a129b
# Parent c3f0f50d46058f07fb355d8e5531f35cfd0ca37e
[PATCH] [0904_2] Siano: core header - add definitions and structures
From: Uri Shkolnik u...@siano-ms.com
Add new definitions (of Siano's protocol messages),
and protocol structures (for future commits usage)
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r c3f0f50d4605 -r 05cf66061926 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:32:10
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:47:39
2009 +0300
@@ -55,6 +55,7 @@ along with this program. If not, see h
#define min(a, b) (((a) (b)) ? (a) : (b))
#endif
+#define SMS_PROTOCOL_MAX_RAOUNDTRIP_MS (1)
#define SMS_ALLOC_ALIGNMENT128
#define SMS_DMA_ALIGNMENT 16
#define SMS_ALIGN_ADDRESS(addr) \
@@ -170,6 +171,7 @@ struct smsclient_params_t {
#define MSG_SMS_GET_PID_FILTER_LIST_RES609
#define MSG_SMS_GET_STATISTICS_REQ 615
#define MSG_SMS_GET_STATISTICS_RES 616
+#define MSG_SMS_HO_PER_SLICES_IND 630
#define MSG_SMS_SET_ANTENNA_CONFIG_REQ 651
#define MSG_SMS_SET_ANTENNA_CONFIG_RES 652
#define MSG_SMS_GET_STATISTICS_EX_REQ 653
@@ -199,6 +201,13 @@ struct smsclient_params_t {
#define MSG_SMS_GPIO_CONFIG_EX_RES 713
#define MSG_SMS_ISDBT_TUNE_REQ 776
#define MSG_SMS_ISDBT_TUNE_RES 777
+#define MSG_SMS_TRANSMISSION_IND 782
+#define MSG_SMS_START_IR_REQ 800
+#define MSG_SMS_START_IR_RES 801
+#define MSG_SMS_IR_SAMPLES_IND 802
+#define MSG_SMS_SIGNAL_DETECTED_IND827
+#define MSG_SMS_NO_SIGNAL_IND 828
+
#define SMS_INIT_MSG_EX(ptr, type, src, dst, len) do { \
(ptr)-msgType = type; (ptr)-msgSrcId = src; (ptr)-msgDstId = dst; \
@@ -206,6 +215,15 @@ struct smsclient_params_t {
} while (0)
#define SMS_INIT_MSG(ptr, type, len) \
SMS_INIT_MSG_EX(ptr, type, 0, HIF_TASK, len)
+enum SMS_DVB3_EVENTS {
+ DVB3_EVENT_INIT = 0,
+ DVB3_EVENT_SLEEP,
+ DVB3_EVENT_HOTPLUG,
+ DVB3_EVENT_FE_LOCK,
+ DVB3_EVENT_FE_UNLOCK,
+ DVB3_EVENT_UNC_OK,
+ DVB3_EVENT_UNC_ERR
+};
enum SMS_DEVICE_MODE {
DEVICE_MODE_NONE = -1,
@@ -230,8 +248,13 @@ struct SmsMsgHdr_ST {
};
struct SmsMsgData_ST {
- struct SmsMsgHdr_ST xMsgHeader;
- u32 msgData[1];
+ struct SmsMsgHdr_ST xMsgHeader;
+ u32 msgData[1];
+};
+
+struct SmsMsgData_ST2 {
+ struct SmsMsgHdr_ST xMsgHeader;
+ u32 msgData[2];
};
struct SmsDataDownload_ST {
--
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] [0904_3] Siano: core - move and update the main core structure declaration
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238691361 -10800
# Node ID 19925582e5dded86fccce7d8c9965285c1240836
# Parent 05cf6606192642241ff25a152e249118cb8a129b
[PATCH] [0904_3] Siano: core - move and update the main core structure
declaration
From: Uri Shkolnik u...@siano-ms.com
smscoreapi - move the main core structure declaration
to the header, in order to enable other components
(such as IR) to use it.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 05cf66061926 -r 19925582e5dd linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cThu Apr 02 19:47:39
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cThu Apr 02 19:56:01
2009 +0300
@@ -56,42 +56,6 @@ struct smscore_client_t {
struct list_headidlist;
onresponse_tonresponse_handler;
onremove_t onremove_handler;
-};
-
-struct smscore_device_t {
- struct list_head entry;
-
- struct list_head clients;
- struct list_head subclients;
- spinlock_t clientslock;
-
- struct list_head buffers;
- spinlock_t bufferslock;
- int num_buffers;
-
- void*common_buffer;
- int common_buffer_size;
- dma_addr_t common_buffer_phys;
-
- void*context;
- struct device *device;
-
- chardevpath[32];
- unsigned long device_flags;
-
- setmode_t setmode_handler;
- detectmode_tdetectmode_handler;
- sendrequest_t sendrequest_handler;
- preload_t preload_handler;
- postload_t postload_handler;
-
- int mode, modes_supported;
-
- struct completion version_ex_done, data_download_done, trigger_done;
- struct completion init_device_done, reload_start_done, resume_done;
-
- int board_id;
- int led_state;
};
void smscore_set_board_id(struct smscore_device_t *core, int id)
diff -r 05cf66061926 -r 19925582e5dd linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:47:39
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:56:01
2009 +0300
@@ -128,6 +128,60 @@ struct smsclient_params_t {
onremove_t onremove_handler;
void*context;
+};
+
+struct smscore_device_t {
+ struct list_head entry;
+
+ struct list_head clients;
+ struct list_head subclients;
+ spinlock_t clientslock;
+
+ struct list_head buffers;
+ spinlock_t bufferslock;
+ int num_buffers;
+
+ void *common_buffer;
+ int common_buffer_size;
+ dma_addr_t common_buffer_phys;
+
+ void *context;
+ struct device *device;
+
+ char devpath[32];
+ unsigned long device_flags;
+
+ setmode_t setmode_handler;
+ detectmode_t detectmode_handler;
+ sendrequest_t sendrequest_handler;
+ preload_t preload_handler;
+ postload_t postload_handler;
+
+ int mode, modes_supported;
+
+ /* host -- device messages */
+ struct completion version_ex_done, data_download_done, trigger_done;
+ struct completion init_device_done, reload_start_done, resume_done;
+ struct completion gpio_configuration_done, gpio_set_level_done;
+ struct completion gpio_get_level_done, ir_init_done;
+
+ /* Buffer management */
+ wait_queue_head_t buffer_mng_waitq;
+
+ /* GPIO */
+ int gpio_get_res;
+
+ /* Target hardware board */
+ int board_id;
+
+ /* Firmware */
+ u8 *fw_buf;
+ u32 fw_buf_size;
+
+ /* Infrared (IR) */
+ /* struct ir_t ir; */
+
+ int led_state;
};
/* GPIO definitions for antenna frequency domain control (SMS8021) */
--
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] [0904_5] Siano: core header - indentation
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238692457 -10800
# Node ID eb9fed366b2bb2b8a99760f52b9c0e40d72a71e0
# Parent 83b19eba46dd4f8253d02c26db4f42728d60e28f
[PATCH] [0904_5] Siano: core header - indentation
From: Uri Shkolnik u...@siano-ms.com
Some more indentation for the smscoreapi.h
There are no implementation changes in this patch.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 83b19eba46dd -r eb9fed366b2b linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:07:49
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:14:17
2009 +0300
@@ -55,14 +55,14 @@ along with this program. If not, see h
#define min(a, b) (((a) (b)) ? (a) : (b))
#endif
-#define SMS_PROTOCOL_MAX_RAOUNDTRIP_MS (1)
-#define SMS_ALLOC_ALIGNMENT128
-#define SMS_DMA_ALIGNMENT 16
+#define SMS_PROTOCOL_MAX_RAOUNDTRIP_MS (1)
+#define SMS_ALLOC_ALIGNMENT128
+#define SMS_DMA_ALIGNMENT 16
#define SMS_ALIGN_ADDRESS(addr) \
uintptr_t)(addr)) + (SMS_DMA_ALIGNMENT-1)) ~(SMS_DMA_ALIGNMENT-1))
-#define SMS_DEVICE_FAMILY2 1
-#define SMS_ROM_NO_RESPONSE2
+#define SMS_DEVICE_FAMILY2 1
+#define SMS_ROM_NO_RESPONSE2
#define SMS_DEVICE_NOT_READY 0x800
enum sms_device_type_st {
@@ -93,13 +93,13 @@ struct smscore_buffer_t {
struct smscore_buffer_t {
/* public members, once passed to clients can be changed freely */
struct list_head entry;
- int size;
- int offset;
+ int size;
+ int offset;
/* private members, read-only for clients */
- void*p;
- dma_addr_t phys;
- unsigned long offset_in_common;
+ void *p;
+ dma_addr_t phys;
+ unsigned long offset_in_common;
};
struct smsdevice_params_t {
@@ -126,7 +126,6 @@ struct smsclient_params_t {
int data_type;
onresponse_t onresponse_handler;
onremove_t onremove_handler;
-
void *context;
};
@@ -262,13 +261,14 @@ struct smscore_device_t {
#define MSG_SMS_SIGNAL_DETECTED_IND827
#define MSG_SMS_NO_SIGNAL_IND 828
-
#define SMS_INIT_MSG_EX(ptr, type, src, dst, len) do { \
(ptr)-msgType = type; (ptr)-msgSrcId = src; (ptr)-msgDstId = dst; \
(ptr)-msgLength = len; (ptr)-msgFlags = 0; \
} while (0)
+
#define SMS_INIT_MSG(ptr, type, len) \
SMS_INIT_MSG_EX(ptr, type, 0, HIF_TASK, len)
+
enum SMS_DVB3_EVENTS {
DVB3_EVENT_INIT = 0,
DVB3_EVENT_SLEEP,
@@ -324,11 +324,12 @@ struct SmsVersionRes_ST {
u8 Step; /* 0 - Step A */
u8 MetalFix; /* 0 - Metal 0 */
- u8 FirmwareId; /* 0xFF � ROM, otherwise the
-* value indicated by
-* SMSHOSTLIB_DEVICE_MODES_E */
- u8 SupportedProtocols; /* Bitwise OR combination of
+ /* FirmwareId 0xFF if ROM, otherwise the
+* value indicated by SMSHOSTLIB_DEVICE_MODES_E */
+ u8 FirmwareId;
+ /* SupportedProtocols Bitwise OR combination of
* supported protocols */
+ u8 SupportedProtocols;
u8 VersionMajor;
u8 VersionMinor;
@@ -362,10 +363,12 @@ struct SMSHOSTLIB_STATISTICS_ST {
s32 SNR; /* dB */
u32 BER; /* Post Viterbi BER [1E-5] */
u32 FIB_CRC; /* CRC errors percentage, valid only for DAB */
- u32 TS_PER; /* Transport stream PER, 0x indicate N/A,
+ /* Transport stream PER, 0x indicate N/A,
* valid only for DVB-T/H */
- u32 MFER; /* DVB-H frame error rate in percentage,
+ u32 TS_PER;
+ /* DVB-H frame error rate in percentage,
* 0x indicate N/A, valid only for DVB-H */
+ u32 MFER;
s32 RSSI; /* dBm */
s32 InBandPwr; /* In band power in dBM */
s32 CarrierOffset; /* Carrier Offset in bin/1024 */
@@ -373,8 +376,9 @@ struct SMSHOSTLIB_STATISTICS_ST {
/* Transmission parameters, valid only for DVB-T/H */
u32 Frequency; /* Frequency in Hz */
u32 Bandwidth; /* Bandwidth in MHz */
- u32 TransmissionMode; /* Transmission Mode, for DAB modes 1-4,
+ /* Transmission Mode, for DAB modes 1-4,
* for DVB-T/H FFT mode carriers in Kilos */
+ u32 TransmissionMode;
u32 ModemState; /* from SMS_DvbModemState_ET */
u32 GuardInterval; /* Guard Interval, 1 divided by value */
u32 CodeRate; /* Code Rate from SMS_DvbModemState_ET */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
[PATCH] [0904_7] Siano: smsdvb - modify license header and included file list.
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238695774 -10800
# Node ID 7b5d5a3a7b8e80359e770041ca4c8cf407d893d6
# Parent 4a0b207a424af7f05d8eb417a698a82a61dd086f
[PATCH] [0904_7] Siano: smsdvb - modify license header
and included file list.
From: Uri Shkolnik u...@siano-ms.com
smsdvb.c (client for DVB-API v3) - modify license header
and included file list. Removing white spaces.
There are no implementation changes.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 4a0b207a424a -r 7b5d5a3a7b8e linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 20:50:24 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 21:09:34 2009 +0300
@@ -1,29 +1,40 @@
-/*
- * Driver for the Siano SMS1xxx USB dongle
- *
- * Author: Uri Shkolni
- *
- * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation;
- *
- * Software distributed under the License is distributed on an AS IS
- * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.
- *
- * See the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2008, Uri Shkolnik
+
+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.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/.
+
+/
#include linux/module.h
#include linux/init.h
+#include asm/byteorder.h
#include smscoreapi.h
+/*#include smsendian.h*/
#include sms-cards.h
+
+#ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
+#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
+ static short adapter_nr[] = \
+ {[0 ... (8 - 1)] = -1 }; \
+ module_param_array(adapter_nr, short, NULL, 0444); \
+ MODULE_PARM_DESC(adapter_nr, DVB adapter numbers)
+#define SMS_DVB_OLD_DVB_REGISTER_ADAPTER
+#endif
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -33,15 +44,15 @@ struct smsdvb_client_t {
struct smscore_device_t *coredev;
struct smscore_client_t *smsclient;
- struct dvb_adapter adapter;
- struct dvb_demuxdemux;
- struct dmxdev dmxdev;
- struct dvb_frontend frontend;
+ struct dvb_adapter adapter;
+ struct dvb_demux demux;
+ struct dmxdev dmxdev;
+ struct dvb_frontend frontend;
- fe_status_t fe_status;
- int fe_ber, fe_snr, fe_unc, fe_signal_strength;
+ fe_status_t fe_status;
+ int fe_ber, fe_snr, fe_unc, fe_signal_strength;
- struct completion tune_done, stat_done;
+ struct completion tune_done, stat_done;
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
@@ -61,7 +72,7 @@ static int smsdvb_onresponse(void *conte
struct smsdvb_client_t *client = (struct smsdvb_client_t *) context;
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) (((u8 *) cb-p)
+ cb-offset);
- u32 *pMsgData = (u32 *)phdr+1;
+ u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr-msgLength - sizeof(struct SmsMsgHdr_ST);*/
/*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
@@ -163,22 +174,22 @@ static int smsdvb_onresponse(void *conte
client-fe_status = 0;
}
-/*
- if (client-fe_status FE_HAS_LOCK)
- sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_LOCK);
- else
- sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_UNLOCK);
+ /*
+if (client-fe_status FE_HAS_LOCK)
+sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_LOCK);
+else
+sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_UNLOCK);
- if (client-sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
- sms_board_dvb3_event(client-coredev, DVB3_EVENT_UNC_OK);
- else
-
[PATCH] [0904_8] Siano: add messages handling for big-endian target
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238696826 -10800
# Node ID e8d224d81e2adde182162ab156aa98725e43f5c0
# Parent 7b5d5a3a7b8e80359e770041ca4c8cf407d893d6
[PATCH] [0904_8] Siano: add messages handling for big-endian target
From: Uri Shkolnik u...@siano-ms.com
Add code that modify the content of Siano's protocol
messages when running with big-endian target.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 7b5d5a3a7b8e -r e8d224d81e2a linux/drivers/media/dvb/siano/smsendian.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsendian.c Thu Apr 02 21:27:06 2009 +0300
@@ -0,0 +1,100 @@
+/
+
+ Siano Mobile Silicon, Inc.
+ MDTV receiver kernel modules.
+ Copyright (C) 2006-2009, Uri Shkolnik
+
+ 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.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/.
+
+ /
+
+#include asm/byteorder.h
+
+#include smsendian.h
+#include smscoreapi.h
+
+void smsendian_handle_tx_message(void *buffer)
+{
+#ifdef __BIG_ENDIAN
+ struct SmsMsgData_ST *msg = (struct SmsMsgData_ST *)buffer;
+ int i;
+ int msgWords;
+
+ switch (msg-xMsgHeader.msgType) {
+ case MSG_SMS_DATA_DOWNLOAD_REQ:
+ {
+ msg-msgData[0] = le32_to_cpu(msg-msgData[0]);
+ break;
+ }
+
+ default:
+ msgWords = (msg-xMsgHeader.msgLength -
+ sizeof(struct SmsMsgHdr_ST))/4;
+
+ for (i = 0; i msgWords; i++)
+ msg-msgData[i] = le32_to_cpu(msg-msgData[i]);
+
+ break;
+ }
+#endif /* __BIG_ENDIAN */
+}
+
+void smsendian_handle_rx_message(void *buffer)
+{
+#ifdef __BIG_ENDIAN
+ struct SmsMsgData_ST *msg = (struct SmsMsgData_ST *)buffer;
+ int i;
+ int msgWords;
+
+ switch (msg-xMsgHeader.msgType) {
+ case MSG_SMS_GET_VERSION_EX_RES:
+ {
+ struct SmsVersionRes_ST *ver =
+ (struct SmsVersionRes_ST *) msg;
+ ver-ChipModel = le16_to_cpu(ver-ChipModel);
+ break;
+ }
+
+ case MSG_SMS_DVBT_BDA_DATA:
+ case MSG_SMS_DAB_CHANNEL:
+ case MSG_SMS_DATA_MSG:
+ {
+ break;
+ }
+
+ default:
+ {
+ msgWords = (msg-xMsgHeader.msgLength -
+ sizeof(struct SmsMsgHdr_ST))/4;
+
+ for (i = 0; i msgWords; i++)
+ msg-msgData[i] = le32_to_cpu(msg-msgData[i]);
+
+ break;
+ }
+ }
+#endif /* __BIG_ENDIAN */
+}
+
+void smsendian_handle_message_header(void *msg)
+{
+#ifdef __BIG_ENDIAN
+ struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)msg;
+
+ phdr-msgType = le16_to_cpu(phdr-msgType);
+ phdr-msgLength = le16_to_cpu(phdr-msgLength);
+ phdr-msgFlags = le16_to_cpu(phdr-msgFlags);
+#endif /* __BIG_ENDIAN */
+}
+
diff -r 7b5d5a3a7b8e -r e8d224d81e2a linux/drivers/media/dvb/siano/smsendian.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsendian.h Thu Apr 02 21:27:06 2009 +0300
@@ -0,0 +1,32 @@
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2009, Uri Shkolnik
+
+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.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/.
+
+/
+
+#ifndef __SMS_ENDIAN_H__
+#define __SMS_ENDIAN_H__
+
+#include asm/byteorder.h
+
+void smsendian_handle_tx_message(void *buffer);
+void smsendian_handle_rx_message(void *buffer);
+void smsendian_handle_message_header(void *msg);
+
+#endif /* __SMS_ENDIAN_H__ */
+
--
To unsubscribe from this
[PATCH] [0904_9] Siano: add support for infra-red (IR) controllers
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238697194 -10800
# Node ID 020ba7b31c963bd36d607848198e9e4258a6f80e
# Parent e8d224d81e2adde182162ab156aa98725e43f5c0
[PATCH] [0904_9] Siano: add support for infra-red (IR) controllers
From: Uri Shkolnik u...@siano-ms.com
This patch add support for IR (infra-red)
remote controllers.
Further commits are needed in order to enable the
activation of the IR components.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r e8d224d81e2a -r 020ba7b31c96 linux/drivers/media/dvb/siano/smsir.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsir.c Thu Apr 02 21:33:14 2009 +0300
@@ -0,0 +1,301 @@
+/
+
+ Siano Mobile Silicon, Inc.
+ MDTV receiver kernel modules.
+ Copyright (C) 2006-2009, Uri Shkolnik
+
+ 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.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/.
+
+ /
+
+
+#include linux/types.h
+#include linux/input.h
+
+#include smscoreapi.h
+#include smsir.h
+#include sms-cards.h
+
+/* In order to add new IR remote control -
+ * 1) Add it to the enum ir_kb_type @ smsir,h,
+ * 2) Add its map to keyboard_layout_maps below
+ * 3) Set your board (sms-cards sub-module) to use it
+ */
+
+static struct keyboard_layout_map_t keyboard_layout_maps[] = {
+ [SMS_IR_KB_DEFAULT_TV] = {
+ .ir_protocol = IR_RC5,
+ .rc5_kbd_address = KEYBOARD_ADDRESS_TV1,
+ .keyboard_layout_map = {
+ KEY_0, KEY_1, KEY_2,
+ KEY_3, KEY_4, KEY_5,
+ KEY_6, KEY_7, KEY_8,
+ KEY_9, 0, 0, KEY_POWER,
+ KEY_MUTE, 0, 0,
+ KEY_VOLUMEUP, KEY_VOLUMEDOWN,
+ KEY_BRIGHTNESSUP,
+ KEY_BRIGHTNESSDOWN, KEY_CHANNELUP,
+ KEY_CHANNELDOWN,
+ 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+ }
+ },
+ [SMS_IR_KB_HCW_SILVER] = {
+ .ir_protocol = IR_RC5,
+ .rc5_kbd_address = KEYBOARD_ADDRESS_LIGHTING1,
+ .keyboard_layout_map = {
+ KEY_0, KEY_1, KEY_2,
+ KEY_3, KEY_4, KEY_5,
+ KEY_6, KEY_7, KEY_8,
+ KEY_9, KEY_TEXT, KEY_RED,
+ KEY_RADIO, KEY_MENU,
+ KEY_SUBTITLE,
+ KEY_MUTE, KEY_VOLUMEUP,
+ KEY_VOLUMEDOWN, KEY_PREVIOUS, 0,
+ KEY_UP, KEY_DOWN, KEY_LEFT,
+ KEY_RIGHT, KEY_VIDEO, KEY_AUDIO,
+ KEY_MHP, KEY_EPG, KEY_TV,
+ 0, KEY_NEXTSONG, KEY_EXIT,
+ KEY_CHANNELUP, KEY_CHANNELDOWN,
+ KEY_CHANNEL, 0,
+ KEY_PREVIOUSSONG, KEY_ENTER,
+ KEY_SLEEP, 0, 0, KEY_BLUE,
+ 0, 0, 0, 0, KEY_GREEN, 0,
+ KEY_PAUSE, 0, KEY_REWIND,
+ 0, KEY_FASTFORWARD, KEY_PLAY,
+ KEY_STOP, KEY_RECORD,
+ KEY_YELLOW, 0, 0, KEY_SELECT,
+ KEY_ZOOM, KEY_POWER, 0, 0
+ }
+ },
+ { } /* Terminating entry */
+};
+
+u32 ir_pos;
+u32ir_word;
+u32 ir_toggle;
+
+#define RC5_PUSH_BIT(dst, bit, pos)\
+ { dst = 1; dst |= bit; pos++; }
+
+
Re: libv4l: Possibility of changing the current pixelformat on the fly
On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). Regards, Hans p.s. One problem with this approach is that if an apps ask for a native cam format which is not one which we can also convert to, the flipping won't work. I think this is best solved by simply not listing the native formats in the enum-fmt output when the cam needs flipping. -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009 07:46:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote: On Sunday 05 April 2009 01:05:39 Jean Delvare wrote: Hi Mike, On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote: Nacked-by: Mike Isely is...@pobox.com This will interfere with the alternative use of LIRC drivers (which work in more cases that ir-kbd). Why then is ir-kbd in the kernel tree and not LIRC drivers? It will thus break some peoples' use of the driver. Do you think it will, or did you test and it actually does? If it indeed breaks, please explain why, so that a solution can be found. Also we have better information on what i2c addresses needed to be probed based on the model of the device This is excellent news. As I said in the header comment of the patch, avoiding probing when we know what the IR receiver is and at which address it sits is the way to go. Please send me all the information you have and I'll be happy to add a patch to the series, that skips probing whenever possible. Or write that patch yourself if you prefer. - and some devices supported by this device are not from Hauppauge so you are making a too-strong assumption that IR should be probed this way in all cases. I didn't make any assumption, sorry. I simply copied the code from ir-kbd-i2c. If my code does the wrong thing for some devices, that was already the case before. And this will certainly be easier to fix after my changes than before. On top of that, the Hauppauge trick is really only the order in which the addresses are probed. Just because a specific order is better for Hauppauge boards, doesn't mean it won't work for non-Hauppauge boards. Also, unless ir-kbd has suddenly improved, this will not work at all for HVR-1950 class devices nor MCE type PVR-24xxx devices (different incompatible IR receiver). I'm sorry but you can't blame me for ir-kbd-i2c not supporting some devices. I updated the driver to make use of the new binding model, but that's about all I did. This is why the pvrusb2 driver has never directly attempted to load ir-kbd. The pvrusb2 driver however abuses the bttv driver's I2C adapter ID (I2C_HW_B_BT848) and was thus affected when ir-kbd-i2c is loaded. This is the only reason why my patch touches the pvrusb2 driver. If you tell me you want the ir-kbd-i2c driver to leave pvrusb2 alone, I can drop all the related changes from my patch, that's very easy. Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. IMO, doing all those tricks to support an out-of-tree driver is the wrong approach. This is just postponing a more serious discussion about what should be done in kernel, in order to better support IR's. In the case of lirc, the userspace part has already an event interface. If the drivers are doing the right thing with their IR part, lirc can just use the event interface for all drivers. This seems to be the proper approach. From what I got from Andy and Mike's comments is that the real issue is that the IR kernel code is incomplete, broken or bad designed. So, several users and userspace apps don't rely on the kernel code but, instead, use lirc as an alternative. That's said, I propose a different approach: 1) Add some entry at feature-removal-schedule.txt posting a date to end support for out-of-tree I2C IR modules; 2) Start discussing with lirc people (and input/event maintainers if needed) about what is needed to properly support the required functionalities for a better lirc usage; 3) Propose a few API additions in order to support those functionalities; 4) apply IR patches on kernel to support the
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
On Sat, 4 Apr 2009 14:24:27 +0200 Jean Delvare kh...@linux-fr.org wrote: Hi all, Here finally comes my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 6 pieces for easier review. Firstly there are 2 preliminary patches: media-video-01-cx18-fix-i2c-error-handling.patch media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch Then 2 patches doing the actual conversion: media-video-03-ir-kbd-i2c-convert-to-new-style.patch media-video-04-configure-ir-receiver.patch And lastly 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: media-video-05-saa7134-input-cleanup-msi-ir.patch media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27 and 2.6.29. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. I'll post all 6 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, From the discussions we already have, I noticed some points to take care of: 1) about the lirc support, I don't think we should change a kernel driver due to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we need to better address this with lirc developers; 2) the way Mike is proposing to solve the issue with pvrusb2 will break userspace usage for people that have those devices whose IR work with the in-kernel IR i2c driver. This means that we'll cause a kernel regression due to an out-of-tree driver; 3) So far, nobody gave us any positive return that the new IR model is working with any of the touched drivers. So, more tests are needed. I'm expecting to have a positive reply for each of the touched drivers. People, please test! Since the merge window is almost finished, IMO, we should postpone those changes to 2.6.31, to better address the lirc issue and to give people more time for testing, applying the changesets after the end of the merge window at the v4l/dvb development tree. This will help people to test, review and propose changes if needed. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] soc-camera: one new host-driver, one driver extension and one fix
On Fri, 3 Apr 2009 21:34:59 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Mauro, 04/04: Add camera (CSI) driver for MX1 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64 There are two checkpatch.pl warnings on the last one. Please add later a patch to fix. WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17: +EXPORT_SYMBOL(mx1_camera_sof_fiq_start); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18: +EXPORT_SYMBOL(mx1_camera_sof_fiq_end); Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [0904_10] Siano: smsdvb - add events mechanism
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238742622 -10800
# Node ID ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
# Parent 020ba7b31c963bd36d607848198e9e4258a6f80e
[PATCH] [0904_10] Siano: smsdvb - add events mechanism
From: Uri Shkolnik u...@siano-ms.com
Add events mechanism that will notify the cards component
(which represent the specific hardware target) for DVB related
events.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 020ba7b31c96 -r ec7ee486fb86 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 21:33:14 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:10:22 2009 +0300
@@ -66,6 +66,45 @@ static int sms_dbg;
static int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
+
+/* Events that may come from DVB v3 adapter */
+static void sms_board_dvb3_event(struct smscore_device_t *coredev,
+ enum SMS_DVB3_EVENTS event) {
+ switch (event) {
+ case DVB3_EVENT_INIT:
+ sms_debug(DVB3_EVENT_INIT);
+ /* sms_board_event(coredev, BOARD_EVENT_BIND); */
+ break;
+ case DVB3_EVENT_SLEEP:
+ sms_debug(DVB3_EVENT_SLEEP);
+ /* sms_board_event(coredev, BOARD_EVENT_POWER_SUSPEND); */
+ break;
+ case DVB3_EVENT_HOTPLUG:
+ sms_debug(DVB3_EVENT_HOTPLUG);
+ /* sms_board_event(coredev, BOARD_EVENT_POWER_INIT); */
+ break;
+ case DVB3_EVENT_FE_LOCK:
+ sms_debug(DVB3_EVENT_FE_LOCK);
+ /* sms_board_event(coredev, BOARD_EVENT_FE_LOCK); */
+ break;
+ case DVB3_EVENT_FE_UNLOCK:
+ sms_debug(DVB3_EVENT_FE_UNLOCK);
+ /* sms_board_event(coredev, BOARD_EVENT_FE_UNLOCK); */
+ break;
+ case DVB3_EVENT_UNC_OK:
+ sms_debug(DVB3_EVENT_UNC_OK);
+ /* sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_OK); */
+ break;
+ case DVB3_EVENT_UNC_ERR:
+ sms_debug(DVB3_EVENT_UNC_ERR);
+ /* sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_ERRORS); */
+ break;
+
+ default:
+ sms_err(Unknown dvb3 api event);
+ break;
+ }
+}
static int smsdvb_onresponse(void *context, struct smscore_buffer_t *cb)
{
@@ -174,17 +213,15 @@ static int smsdvb_onresponse(void *conte
client-fe_status = 0;
}
- /*
-if (client-fe_status FE_HAS_LOCK)
-sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_LOCK);
-else
-sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_UNLOCK);
+ if (client-fe_status FE_HAS_LOCK)
+ sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_LOCK);
+ else
+ sms_board_dvb3_event(client-coredev, DVB3_EVENT_FE_UNLOCK);
-if (client-sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
-sms_board_dvb3_event(client-coredev, DVB3_EVENT_UNC_OK);
-else
-sms_board_dvb3_event(client-coredev, DVB3_EVENT_UNC_ERR);
-*/
+ if (client-sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
+ sms_board_dvb3_event(client-coredev, DVB3_EVENT_UNC_OK);
+ else
+ sms_board_dvb3_event(client-coredev, DVB3_EVENT_UNC_ERR);
if (client-fe_status FE_HAS_LOCK)
sms_board_led_feedback(client-coredev,
@@ -346,13 +383,12 @@ static int smsdvb_set_frontend(struct dv
struct dvb_frontend_parameters *fep)
{
struct smsdvb_client_t *client =
- container_of(fe, struct smsdvb_client_t, frontend);
+ container_of(fe, struct smsdvb_client_t, frontend);
struct {
struct SmsMsgHdr_ST Msg;
u32 Data[3];
} Msg;
- int ret;
Msg.Msg.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
Msg.Msg.msgDstId = HIF_TASK;
@@ -387,7 +423,8 @@ static int smsdvb_set_frontend(struct dv
}
/* Disable LNA, if any. An error is returned if no LNA is present */
- ret = sms_board_lna_control(client-coredev, 0);
+ {
+ int ret = sms_board_lna_control(client-coredev, 0);
if (ret == 0) {
fe_status_t status;
@@ -403,7 +440,7 @@ static int smsdvb_set_frontend(struct dv
/* previous tune didnt lock - enable LNA and tune again */
sms_board_lna_control(client-coredev, 1);
}
-
+ }
return smsdvb_sendrequest_and_wait(client, Msg, sizeof(Msg),
client-tune_done);
}
@@ -428,6 +465,7 @@ static int smsdvb_init(struct dvb_fronte
struct smsdvb_client_t *client =
container_of(fe, struct smsdvb_client_t, frontend);
+ sms_board_dvb3_event(client-coredev, DVB3_EVENT_INIT);
[PATCH] [0904_11] Siano: smsendian smsdvb - binding the smsendian to smsdvb
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238743608 -10800
# Node ID 01979ae55ffec22d74b77681613f38bd606be227
# Parent ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
[PATCH] [0904_11] Siano: smsendian smsdvb - binding the smsendian to smsdvb
From: Uri Shkolnik u...@siano-ms.com
Bind the smsendian, which manipulates some Siano's messages content
when using Siano chip-set with big-endian target,
with the DVB-API v3 client adapter.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r ec7ee486fb86 -r 01979ae55ffe linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileFri Apr 03 10:10:22 2009 +0300
+++ b/linux/drivers/media/dvb/siano/MakefileFri Apr 03 10:26:48 2009 +0300
@@ -1,4 +1,4 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
diff -r ec7ee486fb86 -r 01979ae55ffe linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:10:22 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:26:48 2009 +0300
@@ -24,7 +24,7 @@ along with this program. If not, see h
#include asm/byteorder.h
#include smscoreapi.h
-/*#include smsendian.h*/
+#include smsendian.h
#include sms-cards.h
#ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
@@ -52,7 +52,7 @@ struct smsdvb_client_t {
fe_status_t fe_status;
int fe_ber, fe_snr, fe_unc, fe_signal_strength;
- struct completion tune_done, stat_done;
+ struct completion tune_done;
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
@@ -114,7 +114,7 @@ static int smsdvb_onresponse(void *conte
u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr-msgLength - sizeof(struct SmsMsgHdr_ST);*/
- /*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
+ smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);
switch (phdr-msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -271,7 +271,7 @@ static int smsdvb_start_feed(struct dvb_
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg); */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg);
return smsclient_sendrequest(client-smsclient, PidMsg,
sizeof(PidMsg));
}
@@ -291,7 +291,7 @@ static int smsdvb_stop_feed(struct dvb_d
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg); */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg);
return smsclient_sendrequest(client-smsclient, PidMsg,
sizeof(PidMsg));
}
@@ -302,7 +302,7 @@ static int smsdvb_sendrequest_and_wait(s
{
int rc;
- /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer); */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer);
rc = smsclient_sendrequest(client-smsclient, buffer, size);
if (rc 0)
return rc;
--
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] [0904_12] Siano: unified the debug filter module parameter (dvb and core)
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238744721 -10800
# Node ID 5b86da897fbaf03ea4f5bca50abeaad15634f1d9
# Parent 01979ae55ffec22d74b77681613f38bd606be227
[PATCH] [0904_12] Siano: unified the debug filter module parameter (dvb and
core)
From: Uri Shkolnik u...@siano-ms.com
The sms_debug module parameter sets the debug filter
for the smsmdtv module. It has been moved to the core
component, and replace the smsdvb's.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 10:26:48
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 10:45:21
2009 +0300
@@ -34,8 +34,8 @@
#include smscoreapi.h
#include sms-cards.h
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
+int sms_debug;
+module_param_named(debug, sms_debug, int, 0644);
MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
struct smscore_device_notifyee_t {
diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 10:26:48
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 10:45:21
2009 +0300
@@ -627,6 +627,7 @@ int smscore_led_state(struct smscore_dev
int smscore_led_state(struct smscore_device_t *core, int led);
/* */
+extern int sms_debug;
#define DBG_INFO 1
#define DBG_ADV 2
@@ -635,7 +636,7 @@ int smscore_led_state(struct smscore_dev
printk(kern %s: fmt \n, __func__, ##arg)
#define dprintk(kern, lvl, fmt, arg...) do {\
- if (sms_dbg lvl) \
+ if (sms_debug lvl) \
sms_printk(kern, fmt, ##arg); } while (0)
#define sms_log(fmt, arg...) sms_printk(KERN_INFO, fmt, ##arg)
diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:26:48 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:45:21 2009 +0300
@@ -63,9 +63,6 @@ static struct list_head g_smsdvb_clients
static struct list_head g_smsdvb_clients;
static struct mutex g_smsdvb_clientslock;
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
-MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
/* Events that may come from DVB v3 adapter */
static void sms_board_dvb3_event(struct smscore_device_t *coredev,
--
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: [PULL] soc-camera: one new host-driver, one driver extension and one fix
Hi Mauro, On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote: On Fri, 3 Apr 2009 21:34:59 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Mauro, 04/04: Add camera (CSI) driver for MX1 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64 There are two checkpatch.pl warnings on the last one. Please add later a patch to fix. WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17: +EXPORT_SYMBOL(mx1_camera_sof_fiq_start); WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18: +EXPORT_SYMBOL(mx1_camera_sof_fiq_end); They are irrelevant. These two symbols are defined in assembly, so, you cannot put EXPORT_SYMBOL() there. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
On Fri, 03 Apr 2009 20:29:08 +0200 Erik Andrén erik.and...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jean-Francois, Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for more m5602-gspca changeset that are 2.6.30 material. Jean, I'm preparing the last 2.6.30 material for sending upstream. Could you please merge this quickly today? Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [0904_13] Siano: move DVB_API and remove redundant code
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238755204 -10800
# Node ID f65a29f0f9a66f82a91525ae0085a15f00ac91c2
# Parent 897669fdeb3be75a2bde978557b5398a4a7d8914
[PATCH] [0904_13] Siano: move DVB_API and remove redundant code
From: Uri Shkolnik u...@siano-ms.com
The DVB-API related information has been moved from the core header
to the smsdvb, and the redundant code has been removed from the
core header.
This code has been moved since it is used only by
the smsdvb client component.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 897669fdeb3b -r f65a29f0f9a6 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:31:13
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:40:04
2009 +0300
@@ -36,15 +36,6 @@ along with this program. If not, see h
#include asm/page.h
/* #include smsir.h */
-
-#define SMS_DVB3_SUBSYS
-#ifdef SMS_DVB3_SUBSYS
-#include dmxdev.h
-#include dvbdev.h
-#include dvb_demux.h
-#include dvb_frontend.h
-
-#endif
#define kmutex_init(_p_) mutex_init(_p_)
#define kmutex_lock(_p_) mutex_lock(_p_)
diff -r 897669fdeb3b -r f65a29f0f9a6 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:31:13 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:40:04 2009 +0300
@@ -22,6 +22,11 @@ along with this program. If not, see h
#include linux/module.h
#include linux/init.h
#include asm/byteorder.h
+
+#include dmxdev.h
+#include dvbdev.h
+#include dvb_demux.h
+#include dvb_frontend.h
#include smscoreapi.h
/*#include smsendian.h*/
@@ -52,7 +57,7 @@ struct smsdvb_client_t {
fe_status_t fe_status;
int fe_ber, fe_snr, fe_unc, fe_signal_strength;
- struct completion tune_done, stat_done;
+ struct completion tune_done;
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
--
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: libv4l: Possibility of changing the current pixelformat on the fly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Best regards, Erik Regards, Hans p.s. One problem with this approach is that if an apps ask for a native cam format which is not one which we can also convert to, the flipping won't work. I think this is best solved by simply not listing the native formats in the enum-fmt output when the cam needs flipping. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknYlVoACgkQN7qBt+4UG0FwqACfQtawSmcm8rtFUCGZtV9pzVd+ jmkAoKHkibnapkZkDfl4pXd8pjaJ9M0E =odkv -END PGP SIGNATURE- -- 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] [0904_14] Siano: assemble all components to one kernel module
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238756860 -10800
# Node ID 616e696ce6f0c0d76a1aaea8b36e0345112c5ab6
# Parent f65a29f0f9a66f82a91525ae0085a15f00ac91c2
[PATCH] [0904_14] Siano: assemble all components to one kernel module
From: Uri Shkolnik u...@siano-ms.com
Previously, the support for Siano-based devices
has been combined from several kernel modules.
This patch assembles all into single kernel module.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/MakefileFri Apr 03 14:07:40 2009 +0300
@@ -1,8 +1,6 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsusb.o smsdvb.o smsendian.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsdvb.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 13:40:04
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 14:07:40
2009 +0300
@@ -1321,8 +1321,8 @@ static int __init smscore_module_init(vo
}
#endif
-#if 0 /* def SMS_DVB_CLIENT */
- /* DVB Register */
+#ifdef SMS_DVB3_SUBSYS
+ /* DVB v.3 Register */
rc = smsdvb_register();
if (rc) {
sms_err(Error registering DVB client.\n);
@@ -1339,7 +1339,7 @@ static int __init smscore_module_init(vo
}
#endif
-#if 0 /* def SMS_USB_BUS_DRV */
+#ifdef SMS_USB_DRV
/* USB Register */
rc = smsusb_register();
if (rc) {
@@ -1385,8 +1385,7 @@ static void __exit smscore_module_exit(v
smschar_unregister();
#endif
-#if 0 /* def SMS_DVB_CLIENT */
- /* DVB UnRegister */
+#ifdef SMS_DVB3_SUBSYS
smsdvb_unregister();
#endif
@@ -1395,8 +1394,9 @@ static void __exit smscore_module_exit(v
smsnet_unregister();
#endif
-#if 0 /* def SMS_USB_BUS_DRV */
- /* Unregister USB */
+ /* Unegister interfaces objects */
+#ifdef SMS_USB_DRV
+ /* USB unregister */
smsusb_unregister();
#endif
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:40:04
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 14:07:40
2009 +0300
@@ -617,6 +617,17 @@ int smscore_get_board_id(struct smscore_
int smscore_led_state(struct smscore_device_t *core, int led);
+
+#ifdef SMS_DVB3_SUBSYS
+extern int smsdvb_register(void);
+extern void smsdvb_unregister(void);
+#endif
+
+#ifdef SMS_USB_DRV
+extern int smsusb_register(void);
+extern void smsusb_unregister(void);
+#endif
+
/* */
#define DBG_INFO 1
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:07:40 2009 +0300
@@ -638,7 +638,7 @@ adapter_error:
return rc;
}
-int smsdvb_module_init(void)
+int smsdvb_register(void)
{
int rc;
@@ -652,7 +652,7 @@ int smsdvb_module_init(void)
return rc;
}
-void smsdvb_module_exit(void)
+void smsdvb_unregister(void)
{
smscore_unregister_hotplug(smsdvb_hotplug);
@@ -665,9 +665,6 @@ void smsdvb_module_exit(void)
kmutex_unlock(g_smsdvb_clientslock);
}
-module_init(smsdvb_module_init);
-module_exit(smsdvb_module_exit);
-
MODULE_DESCRIPTION(SMS DVB subsystem adaptation module);
MODULE_AUTHOR(Siano Mobile Silicon, INC. (u...@siano-ms.com));
MODULE_LICENSE(GPL);
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:07:40 2009 +0300
@@ -539,7 +539,7 @@ static struct usb_driver smsusb_driver =
.resume = smsusb_resume,
};
-int smsusb_module_init(void)
+int smsusb_register(void)
{
int rc = usb_register(smsusb_driver);
if (rc)
@@ -550,16 +550,13 @@ int smsusb_module_init(void)
return rc;
}
-void smsusb_module_exit(void)
+void smsusb_unregister(void)
{
- sms_debug();
/* Regular USB Cleanup */
usb_deregister(smsusb_driver);
+ sms_info(end);
}
-module_init(smsusb_module_init);
-module_exit(smsusb_module_exit);
-
-MODULE_DESCRIPTION(Driver for the Siano SMS1XXX USB dongle);
+MODULE_DESCRIPTION(Driver for the Siano SMS1xxx USB dongle);
MODULE_AUTHOR(Siano Mobile Silicon, INC. (u...@siano-ms.com));
MODULE_LICENSE(GPL);
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thu, 2 Apr 2009 18:16:42 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop using the i2c command interface. I didn't checked, but I suspect that this is the last case of using the i2c command on v4l drivers. The removal of i2c command will probably make Jean happy as well, since this will also remove some legacy code from i2c core. This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these patches above remove code that's no longer needed. There are also some v4l2-subdev.h API improvements that I postponed until all the drivers were converted. These changes are trivial, but touch on a lot of files. Please let's avoid changing the internal API again on 2.6.31. We should focus on fixing the bugs during this cycle, since the changes were far above the usual, and affected all drivers. The other major change is that the old i2c autoprobing API is now used for kernels 2.6.26. This was 2.6.22, but a bug in i2c_new_probed_subdev prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually it would be possible with 2.6.25, but since there were some other i2c API changes in 2.6.26 anyway I decided that it made life easier if we put the switchover point at 2.6.26. Ok. There are some other cleanups I could do, but all the important ones are now taken care of. I would like to take the opportunity to thank Jean Delvare for his support and his help in testing various drivers and working on ir-kbd-i2c, and Mauro for processing and merging all my patches. I feel a little guilty for burying Mauro in this big pile of patches :-) I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx conversion, Trent Piepho for his reviews, Steve Toth for testing the cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri Deevi for converting the cx231xx driver at short notice. I've no doubt forgotten people, for which I apologize. Thank you and all the others for the efforts. I expect you all to take extra care to fix all regressions that may eventually rise with those changes. In particular, please track the bugzillas at kernel.org. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [0904_15] Siano: core header - bind SMS messages endian handling
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238758250 -10800
# Node ID 856813745905e07d9fc6be5e136fdf7060c6fc37
# Parent 0ddd2fd20badbf2bb33566a05ff2ea2a6dff8600
[PATCH] [0904_15] Siano: core header - bind SMS messages endian handling
From: Uri Shkolnik u...@siano-ms.com
This patch bind the smsedian (which manipulate the content
of Siano's protocol messages) to the smsdvb component.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 0ddd2fd20bad -r 856813745905 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:18:10 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:30:50 2009 +0300
@@ -29,7 +29,7 @@ along with this program. If not, see h
#include dvb_frontend.h
#include smscoreapi.h
-/*#include smsendian.h*/
+#include smsendian.h
#include sms-cards.h
#ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
@@ -116,7 +116,7 @@ static int smsdvb_onresponse(void *conte
u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr-msgLength - sizeof(struct SmsMsgHdr_ST);*/
- /*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
+ smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);
switch (phdr-msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -293,7 +293,7 @@ static int smsdvb_stop_feed(struct dvb_d
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg); */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg);
return smsclient_sendrequest(client-smsclient, PidMsg,
sizeof(PidMsg));
}
@@ -304,7 +304,7 @@ static int smsdvb_sendrequest_and_wait(s
{
int rc;
- /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer); */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer);
rc = smsclient_sendrequest(client-smsclient, buffer, size);
if (rc 0)
return rc;
--
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: tm6010 development repository
On Sun, 05 Apr 2009 12:45:56 +1200 Kevin Wells wells_ke...@yahoo.co.nz wrote: Steven Toth wrote: Kevin Wells wrote: I've started trying to understand the code in the following repository: http://www.linuxtv.org/hg/~mchehab/tm6010/ I have a few patches I would like to apply. How should I do this? Submit the patches to the list and I'll try to get some time to create and maintain a ~stoth/tm6010 tree. I think I can get the nova-s-usb2 running with just a little effort. Thanks Steve. Sorry for the slow reply. I'm doing this in my limited spare time. Patches to follow. Nothing exciting. Just trying to make the code more robust. Patches are very granular. Let me know if that doesn't work for you. Knowing the driver works on the nova-s-usb2 would be encouraging. I'm trying to get it to work on an hvr-900h. I'll merge those with some patches I have here. hvr-900h analog part is working with a some troubles on the experimental tree I have here. A good thing to do, after I merge yours and my patches, is to convert it to the new v4l2 dev/subdev interface. I suspect that this will solve several bugs we currently have with the i2c interface of this driver. I intend to do this later this week, after the end of the merge window. For now, I still have lots of patches to review, in order to submit for 2.6.30. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.
On Sun, 5 Apr 2009, Uri Shkolnik wrote: PidMsg.xMsgHeader.msgLength = sizeof(PidMsg); PidMsg.msgData[0] = feed-pid; - /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg); */ + smsendian_handle_tx_message((struct SmsMsgHdr_ST *)PidMsg); return smsclient_sendrequest(client-smsclient, PidMsg, sizeof(PidMsg)); I don't get it, you wrote the code commented out in one patch, and now you're going to sumbit patches to uncomment it one line at a time? -- 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] [0904_17] Siano: smsusb - update header and indentation
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238759458 -10800
# Node ID 73c6299ef5f518beb07b6eb371402fe1be4e26ea
# Parent c582116cfbb96671629143fced33e3f88c28b3c7
[PATCH] [0904_17] Siano: smsusb - update header and indentation
From: Uri Shkolnik u...@siano-ms.com
This patch does not introduce any implementation change.
It include modified license and included files list and
align indentation.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r c582116cfbb9 -r 73c6299ef5f5 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:38:46 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:50:58 2009 +0300
@@ -1,35 +1,34 @@
-/*
- * Driver for the Siano SMS1xxx USB dongle
- *
- * author: Anatoly Greenblat
- *
- * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation;
- *
- * Software distributed under the License is distributed on an AS IS
- * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.
- *
- * See the GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2008, Uri Shkolnik, Anatoly Greenblat
+
+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.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/.
+
+/
#include linux/kernel.h
#include linux/init.h
#include linux/usb.h
#include linux/firmware.h
+#include asm/byteorder.h
#include smscoreapi.h
#include sms-cards.h
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
-MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
+#include smsendian.h
#define USB1_BUFFER_SIZE 0x1000
#define USB2_BUFFER_SIZE 0x4000
@@ -41,7 +40,7 @@ struct smsusb_device_t;
struct smsusb_urb_t {
struct smscore_buffer_t *cb;
- struct smsusb_device_t *dev;
+ struct smsusb_device_t *dev;
struct urb urb;
};
@@ -50,10 +49,10 @@ struct smsusb_device_t {
struct usb_device *udev;
struct smscore_device_t *coredev;
- struct smsusb_urb_t surbs[MAX_URBS];
+ struct smsusb_urb_t surbs[MAX_URBS];
- int response_alignment;
- int buffer_size;
+ int response_alignment;
+ int buffer_size;
};
static int smsusb_submit_urb(struct smsusb_device_t *dev,
@@ -75,7 +74,7 @@ static void smsusb_onresponse(struct urb
}
if (urb-actual_length 0) {
- struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) surb-cb-p;
+ struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)surb-cb-p;
if (urb-actual_length = phdr-msgLength) {
surb-cb-size = phdr-msgLength;
@@ -84,11 +83,11 @@ static void smsusb_onresponse(struct urb
(phdr-msgFlags MSG_HDR_FLAG_SPLIT_MSG)) {
surb-cb-offset =
- dev-response_alignment +
- ((phdr-msgFlags 8) 3);
+ dev-response_alignment +
+ ((phdr-msgFlags 8) 3);
/* sanity check */
- if (((int) phdr-msgLength +
+ if (((int)phdr-msgLength +
surb-cb-offset) urb-actual_length) {
sms_err(invalid response
msglen %d offset %d
@@ -101,7 +100,7 @@ static void smsusb_onresponse(struct urb
/* move buffer pointer and
* copy header to its new location */
- memcpy((char *) phdr + surb-cb-offset,
+ memcpy((char *)phdr + surb-cb-offset,
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Sun, 5 Apr 2009 08:43:35 -0300, Mauro Carvalho Chehab wrote: On Thu, 2 Apr 2009 18:16:42 +0200 Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop using the i2c command interface. I didn't checked, but I suspect that this is the last case of using the i2c command on v4l drivers. The removal of i2c command will probably make Jean happy as well, since this will also remove some legacy code from i2c core. Oh yeah \o/ This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these patches above remove code that's no longer needed. There are also some v4l2-subdev.h API improvements that I postponed until all the drivers were converted. These changes are trivial, but touch on a lot of files. Please let's avoid changing the internal API again on 2.6.31. We should focus on fixing the bugs during this cycle, since the changes were far above the usual, and affected all drivers. The other major change is that the old i2c autoprobing API is now used for kernels 2.6.26. This was 2.6.22, but a bug in i2c_new_probed_subdev prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually it would be possible with 2.6.25, but since there were some other i2c API changes in 2.6.26 anyway I decided that it made life easier if we put the switchover point at 2.6.26. Ok. There are some other cleanups I could do, but all the important ones are now taken care of. I would like to take the opportunity to thank Jean Delvare for his support and his help in testing various drivers and working on ir-kbd-i2c, and Mauro for processing and merging all my patches. I feel a little guilty for burying Mauro in this big pile of patches :-) I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx conversion, Trent Piepho for his reviews, Steve Toth for testing the cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri Deevi for converting the cx231xx driver at short notice. I've no doubt forgotten people, for which I apologize. Thank you and all the others for the efforts. I expect you all to take extra care to fix all regressions that may eventually rise with those changes. In particular, please track the bugzillas at kernel.org. Yes, I am totally committed to help fix any i2c issue that may arise as a consequence of the recent driver conversions. -- Jean Delvare -- 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] [0904_18] Siano: smsusb - byte ordering and big endian support
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238760032 -10800
# Node ID ab731e3cec5cb076b8f87f827c3c97a4dd84e0ca
# Parent 73c6299ef5f518beb07b6eb371402fe1be4e26ea
[PATCH] [0904_18] Siano: smsusb - byte ordering and big endian support
From: Uri Shkolnik u...@siano-ms.com
This patch add support for Siano's messaging in big endian systems.
Few indentations (without implementation impact) have been added.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 73c6299ef5f5 -r ab731e3cec5c linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:50:58 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 15:00:32 2009 +0300
@@ -27,7 +27,6 @@ along with this program. If not, see h
#include smscoreapi.h
#include sms-cards.h
-
#include smsendian.h
#define USB1_BUFFER_SIZE 0x1000
@@ -64,7 +63,7 @@ static void smsusb_onresponse(struct urb
static void smsusb_onresponse(struct urb *urb, struct pt_regs *regs)
#endif
{
- struct smsusb_urb_t *surb = (struct smsusb_urb_t *) urb-context;
+ struct smsusb_urb_t *surb = (struct smsusb_urb_t *)urb-context;
struct smsusb_device_t *dev = surb-dev;
if (urb-status 0) {
@@ -76,6 +75,7 @@ static void smsusb_onresponse(struct urb
if (urb-actual_length 0) {
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)surb-cb-p;
+ smsendian_handle_message_header(phdr);
if (urb-actual_length = phdr-msgLength) {
surb-cb-size = phdr-msgLength;
@@ -179,6 +179,7 @@ static int smsusb_sendrequest(void *cont
struct smsusb_device_t *dev = (struct smsusb_device_t *)context;
int dummy;
+ smsendian_handle_message_header((struct SmsMsgHdr_ST *)buffer);
return usb_bulk_msg(dev-udev, usb_sndbulkpipe(dev-udev, 2),
buffer, size, dummy, 1000);
}
@@ -336,8 +337,8 @@ static int smsusb_init_device(struct usb
case SMS_VEGA:
dev-buffer_size = USB2_BUFFER_SIZE;
dev-response_alignment =
- dev-udev-ep_in[1]-desc.wMaxPacketSize -
- sizeof(struct SmsMsgHdr_ST);
+ le16_to_cpu(dev-udev-ep_in[1]-desc.wMaxPacketSize) -
+ sizeof(struct SmsMsgHdr_ST);
params.flags |= SMS_DEVICE_FAMILY2;
break;
@@ -532,13 +533,12 @@ MODULE_DEVICE_TABLE(usb, smsusb_id_table
MODULE_DEVICE_TABLE(usb, smsusb_id_table);
static struct usb_driver smsusb_driver = {
- .name = smsusb,
- .probe = smsusb_probe,
- .disconnect = smsusb_disconnect,
- .id_table = smsusb_id_table,
-
- .suspend= smsusb_suspend,
- .resume = smsusb_resume,
+ .name = smsusb,
+ .probe = smsusb_probe,
+ .disconnect = smsusb_disconnect,
+ .suspend = smsusb_suspend,
+ .resume = smsusb_resume,
+ .id_table = smsusb_id_table,
};
int smsusb_register(void)
--
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] [0904_19] Siano: sms-cards - update cards (targets) component header
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238760946 -10800
# Node ID 8377a5e61286b90e293e287cefc9638d2ddd938e
# Parent ab731e3cec5cb076b8f87f827c3c97a4dd84e0ca
[PATCH] [0904_19] Siano: sms-cards - update cards (targets) component header
From: Uri Shkolnik u...@siano-ms.com
sms-cards component holds all target-specific information.
The component' header has been added with:
1) Include the infra-red header
2) More target types (definitions)
3) Structure for various GPIO usage
4) Extend sms_board struct to include
a) GPIO structure
b) IR structure
5) Some 'extern' declartion (for future commits usage)
6) Board Events structure
7) board event function prototype.
All modifications are in the declaration level only.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r ab731e3cec5c -r 8377a5e61286 linux/drivers/media/dvb/siano/sms-cards.h
--- a/linux/drivers/media/dvb/siano/sms-cards.h Fri Apr 03 15:00:32 2009 +0300
+++ b/linux/drivers/media/dvb/siano/sms-cards.h Fri Apr 03 15:15:46 2009 +0300
@@ -22,6 +22,7 @@
#include linux/usb.h
#include smscoreapi.h
+#include smsir.h
#define SMS_BOARD_UNKNOWN 0
#define SMS1XXX_BOARD_SIANO_STELLAR 1
@@ -34,6 +35,41 @@
#define SMS1XXX_BOARD_HAUPPAUGE_WINDHAM 8
#define SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD 9
#define SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2 10
+#define SMS1XXX_BOARD_SIANO_NICE 11
+#define SMS1XXX_BOARD_SIANO_VENICE 12
+
+struct sms_board_gpio_cfg {
+ int lna_vhf_exist;
+ int lna_vhf_ctrl;
+ int lna_uhf_exist;
+ int lna_uhf_ctrl;
+ int lna_uhf_d_ctrl;
+ int lna_sband_exist;
+ int lna_sband_ctrl;
+ int lna_sband_d_ctrl;
+ int foreign_lna0_ctrl;
+ int foreign_lna1_ctrl;
+ int foreign_lna2_ctrl;
+ int rf_switch_vhf;
+ int rf_switch_uhf;
+ int rf_switch_sband;
+ int leds_power;
+ int led0;
+ int led1;
+ int led2;
+ int led3;
+ int led4;
+ int ir;
+ int eeprom_wp;
+ int mrc_sense;
+ int mrc_pdn_resetn;
+ int mrc_gp0; /* mrcs spi int */
+ int mrc_gp1;
+ int mrc_gp2;
+ int mrc_gp3;
+ int mrc_gp4;
+ int host_spi_gsp_ts_int;
+};
struct sms_board {
enum sms_device_type_st type;
@@ -41,9 +77,14 @@ struct sms_board {
/* gpios */
int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
+ struct sms_board_gpio_cfg board_cfg;
+ enum ir_kb_type ir_kb_type;
};
struct sms_board *sms_get_board(int id);
+
+extern struct usb_device_id smsusb_id_table[];
+extern struct smscore_device_t *coredev;
int sms_board_setup(struct smscore_device_t *coredev);
@@ -56,4 +97,28 @@ int sms_board_lna_control(struct smscore
extern int sms_board_load_modules(int id);
+enum SMS_BOARD_EVENTS {
+ BOARD_EVENT_POWER_INIT,
+ BOARD_EVENT_POWER_SUSPEND,
+ BOARD_EVENT_POWER_RESUME,
+ BOARD_EVENT_BIND,
+ BOARD_EVENT_SCAN_PROG,
+ BOARD_EVENT_SCAN_COMP,
+ BOARD_EVENT_EMERGENCY_WARNING_SIGNAL,
+ BOARD_EVENT_FE_LOCK,
+ BOARD_EVENT_FE_UNLOCK,
+ BOARD_EVENT_DEMOD_LOCK,
+ BOARD_EVENT_DEMOD_UNLOCK,
+ BOARD_EVENT_RECEPTION_MAX_4,
+ BOARD_EVENT_RECEPTION_3,
+ BOARD_EVENT_RECEPTION_2,
+ BOARD_EVENT_RECEPTION_1,
+ BOARD_EVENT_RECEPTION_LOST_0,
+ BOARD_EVENT_MULTIPLEX_OK,
+ BOARD_EVENT_MULTIPLEX_ERRORS
+};
+
+int sms_board_event(struct smscore_device_t *coredev,
+ enum SMS_BOARD_EVENTS gevent);
+
#endif /* __SMS_CARDS_H__ */
--
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/4] Add support to libv4l to use orientation from VIDIOC_ENUMINPUT
On Mon, 30 Mar 2009 10:30:22 +0200 Hans de Goede j.w.r.dego...@hhs.nl wrote: On 03/30/2009 12:28 AM, Adam Baker wrote: Add check to libv4l of the sensor orientation as reported by VIDIOC_ENUMINPUT Signed-off-by: Adam Bakerli...@baker-net.org.uk Looks good, thanks. I'll apply this to my libv4l tree, as soon as its certain that the matching kernel changes will go in to the kernel without any API changes. kernel patches merged. As per your request, I'm letting the libv4l one for you to take care. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l: Possibility of changing the current pixelformat on the fly
On 04/05/2009 01:26 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Erm, yes that is what I was saying, but that is because I was confusing things with the sq905 driver some other people are working on. Now I understand what you were trying to ask. So the problem is that the vv6410 sensor can do flipping in hardware, and then the order in which it sends out the pixels changes from gbgbgb (for example) to bgbgbg, for the lines which have blue, effectively changing the pixelformat, right? In that case I think the only solution is to simply return -EBUSY when the vflip / hflip controls are changed while a stream is active. As for the race window with one application querying the format (or even setting it) and then another app changing the flip before the application which just set the format starts the stream, we already have that wrt 2 applications doing this: app a: setformat x app b: setformat y app a: start stream (thinking format is x) Which is something which normally (luckily) never happens. Does that sound like a plan ? Note that this is a solution at the driver level, which IMHO is the only way as we cannot assume libv4l is always being used. Regards, Hans -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 06:14 -0300, Mauro Carvalho Chehab wrote: IMO, doing all those tricks to support an out-of-tree driver is the wrong approach. This is just postponing a more serious discussion about what should be done in kernel, in order to better support IR's. The tricks were to not break the current user experience by saddling them with a kernel module that they may not want. (If the tricks are needed at all - I'm will test later today.) I agree that better in kernel infrastructure needs to be in place for IR. LIRC's kernel space infrastructure module, lirc_dev, probably isn't a bad model for support of IR devices. The individual LIRC modules for supporting specific sets of devices are the ones that have problems to varying degrees. In the case of lirc, the userspace part has already an event interface. If the drivers are doing the right thing with their IR part, lirc can just use the event interface for all drivers. This seems to be the proper approach. Input event interfaces alone neglect IR blasters. From what I got from Andy and Mike's comments is that the real issue is that the IR kernel code is incomplete, broken or bad designed. So, several users and userspace apps don't rely on the kernel code but, instead, use lirc as an alternative. There is at least one other motivation: LIRC also handles a number of other hardware interfaces that are not I2C: serial ports (/dev/ttySX), parallel port, USB, etc. I happen to use the lirc_mceusb2 module for my Phillips Home IR receiver/blaster (I'm not sure if the blaster works under linux.) That's said, I propose a different approach: 1) Add some entry at feature-removal-schedule.txt posting a date to end support for out-of-tree I2C IR modules; 2) Start discussing with lirc people (and input/event maintainers if needed) about what is needed to properly support the required functionalities for a better lirc usage; 3) Propose a few API additions in order to support those functionalities; 4) apply IR patches on kernel to support the missing functionalities; The scope of a complete kernel IR infrastructure goes a bit beyond I2C bus devices that are only input devices. What's the scope of what you want to tackle here? I certainly don't want to reinvent something that's going to look just like the LIRC driver model: http://www.lirc.org/html/technical.html Which already has an infrastructure for IR driver module writers: http://www.lirc.org/html/technical.html#lirc_dev Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up set of in kernel modules? lirc_i2c can certainly be broken up into several modules: 1 per supported device. Should these create an input device as well to maintain compatability with apps expecting an ir-kbd-i2c like function? Or do we split up ir-kbd-i2c into per device modules and in addition to the input event interface, have it register with the lirc_dev module? Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it would be a waste of time not to do so.) Regards, Andy 5) remove the support for out-of-tree i2c IR modules. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l: Possibility of changing the current pixelformat on the fly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/05/2009 01:26 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Erm, yes that is what I was saying, but that is because I was confusing things with the sq905 driver some other people are working on. Glad that you were confused as I couldn't really make out the meaning of your answer. :) Now I understand what you were trying to ask. So the problem is that the vv6410 sensor can do flipping in hardware, and then the order in which it sends out the pixels changes from gbgbgb (for example) to bgbgbg, for the lines which have blue, effectively changing the pixelformat, right? Correct. In that case I think the only solution is to simply return -EBUSY when the vflip / hflip controls are changed while a stream is active. So this effectively forces a reprobe of the hardware? As for the race window with one application querying the format (or even setting it) and then another app changing the flip before the application which just set the format starts the stream, we already have that wrt 2 applications doing this: app a: setformat x app b: setformat y app a: start stream (thinking format is x) Which is something which normally (luckily) never happens. If this ever becomes a real issue, shouldn't some kind of user-space master program aquire the device and then handle format requests for all client programs? Does that sound like a plan ? Yes, I'll try this ASAP. Note that this is a solution at the driver level, which IMHO is the only way as we cannot assume libv4l is always being used. If it works this sounds like the most clean and elegant solution. The weak point being that the application must try to renegotiate the format upon the -EBUSY signal. Thanks for the help! Regards, Erik Regards, Hans -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknYqtwACgkQN7qBt+4UG0FBgACggwgmVfMKj2bQAj/UVSL/vHSH Ss0Anj/8xoRpXiIzBg3HdtDa0SXK6WK2 =yIxz -END PGP SIGNATURE- -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy, On Sat, 04 Apr 2009 21:50:08 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote: On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote: I think this is way out of date for cx18 based boards. The only IR chip I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses 0x70-0x74. I guess 0x71 is the proper address for Rx. I'll let you know when I test. This address list comes from the ir-kbd-i2c driver. The cx18 driver happens to use the same I2C adapter ID as the ivtv driver (I2C_HW_B_CX2341X) and this is what the ir-kbd-i2c driver used to decide which addresses to probe. As I don't know anything about the hardware, I had to keep the new code compatible with the old one and keep probing the same addresses. This is the i2cdetect output from my HVR-1600 - the only cx18 based card known or reported to have an IR chip: [r...@morgan ~]# i2cdetect -l i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c ivtv i2c driver #0 I2C adapter i2c-2 i2c cx18 i2c driver #0-0I2C adapter i2c-3 i2c cx18 i2c driver #0-1I2C adapter [r...@morgan ~]# i2cdetect 2 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-2. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- 70: 70 71 72 73 -- -- -- -- [r...@morgan ~]# i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- The Zilog is at 0x70-0x73. The standard IR Tx and RX addresses are 0x70 and 0x71 Now, if you tell me that this list doesn't make sense for cx18 boards, we can change it. I owe you the right address to probe. I think it is 0x71, but I want to double check. Well, it doesn't really matter to me at this point. All I care about is that ir-kbd-i2c didn't support cx18 adapters before, so my patch can just ignore them. Support can be added later. More interestingly, if only one board needs to be supported for now and you have all the information about the IR receiver, then we simply don't need auto-detection of IR devices on cx18 at all. We can directly take the clean route of device declaration. As far as I know the cx18 does that very well for all other chips (tuner, decoder etc.) much like the ivtv driver does, so adding support for IR should be easy. As addresses 0x70-0x74 were not probed so far on cx18 boards, I guess that IR support never worked for cx18 (at least not with ir-kbd-i2c)? No, the lirc_i2c, lirc_pvr150, and lirc_zilog come in via the i2c subsystem. Does ir-kbd-i2c support the Zilog Z8F0811 at all? If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I can simplify my patch set and omit the cx18 entirely. Which I just did... The HVR-1600 could have been supported by ir-kbd-i2c. It's submission was redirected slightly here: http://lkml.org/lkml/2009/2/3/118 And deferred here: http://www.spinics.net/lists/linux-media/msg03883.html until your changes were done. OK. Then let's indeed get my changes merged first, and then we can see the best way to add support for the HVR-1600 IR. I have an I2C related question. If the cx18 or ivtv driver autoloads ir-kbd-i2c and registers an I2C client on the bus, does that preclude lirc_i2c, lirc_pvr150 or lirc_zilog from using the device? LIRC users may notice, if it does. I don't know anything about lirc_i2c, lirc_pvr150 or lirc_zilog. I tend to ignore all the code that is neither in the Linux kernel tree nor in the v4l-dvb tree. lirc_pvr150 has always been out of kernel and likely always will be. Any valid reason? Out-of-free drivers are a pain for users :( lirc_i2c and lirc_zilog, the stripped down version of lirc_pvr150, was submitted by Janne and Jarrod: http://lkml.org/lkml/2008/9/9/19 I do not
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Hans, On Sun, 5 Apr 2009 07:46:47 +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). I'd rather name the parameter disable_ir, to make it consistent with what other bridge drivers already use, and also because what the parameter really does is preventing I2C devices from being instantiated, _not_ preventing the ir-kbd-i2c module from loading. I have a patch doing that already, it's pretty simple, I'll post it in a minute. It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. lirc_i2c will break, it still uses the legacy binding model. That's what you get for living outside the kernel tree... Upgrading it shouldn't be too hard, given that the difficult part is to update the bridge drivers and I've already taken care of this part (although lirc_i2c might need to probe more addresses than ir-kbd-i2c does). The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. I wholeheartedly agree. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. Totally correct. The current mess^Wmodel vaguely works when a single TV card is present, but mixing different TV cards in the same system would certainly break. Admittedly this is probably not a very common case, I guess the vast majority of users have a single TV card. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. Please note that my conversion _already_ no longer makes any use of adapter IDs. What it still does is probing, except for a few selected cards (AVerMedia Cardbus and MSI t...@nywhere Plus). The idea is clearly to turn probing into a fallback and use per-card data for IR device instantiation the first choice for as many cards as possible in the future. Updated patch set is available at: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Changes since previous version: * Dropped cx18 changes on request by Andy Walls. * Added disable_ir module parameter to all bridge drivers which didn't have it. -- Jean Delvare -- 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] [0904_4] Siano: core header indentation
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238692069 -10800
# Node ID 83b19eba46dd4f8253d02c26db4f42728d60e28f
# Parent 19925582e5dded86fccce7d8c9965285c1240836
siano: core header identation
[PATCH] [0904_4] Siano: core header indentation
From: Uri Shkolnik u...@siano-ms.com
smscoreapi.h - indentation and removing lots of white spaces
There are no implementation changes in this patch.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 19925582e5dd -r 83b19eba46dd linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:56:01
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:07:49
2009 +0300
@@ -103,31 +103,31 @@ struct smscore_buffer_t {
};
struct smsdevice_params_t {
- struct device *device;
+ struct device *device;
- int buffer_size;
- int num_buffers;
+ int buffer_size;
+ int num_buffers;
- chardevpath[32];
- unsigned long flags;
+ char devpath[32];
+ unsigned long flags;
- setmode_t setmode_handler;
- detectmode_tdetectmode_handler;
- sendrequest_t sendrequest_handler;
- preload_t preload_handler;
- postload_t postload_handler;
+ setmode_t setmode_handler;
+ detectmode_t detectmode_handler;
+ sendrequest_t sendrequest_handler;
+ preload_t preload_handler;
+ postload_t postload_handler;
- void*context;
+ void *context;
enum sms_device_type_st device_type;
};
struct smsclient_params_t {
- int initial_id;
- int data_type;
- onresponse_tonresponse_handler;
- onremove_t onremove_handler;
+ int initial_id;
+ int data_type;
+ onresponse_t onresponse_handler;
+ onremove_t onremove_handler;
- void*context;
+ void *context;
};
struct smscore_device_t {
@@ -185,26 +185,26 @@ struct smscore_device_t {
};
/* GPIO definitions for antenna frequency domain control (SMS8021) */
-#define SMS_ANTENNA_GPIO_0 1
-#define SMS_ANTENNA_GPIO_1 0
+#define SMS_ANTENNA_GPIO_0 1
+#define SMS_ANTENNA_GPIO_1 0
-#define BW_8_MHZ 0
-#define BW_7_MHZ 1
-#define BW_6_MHZ 2
-#define BW_5_MHZ 3
-#define BW_ISDBT_1SEG 4
-#define BW_ISDBT_3SEG 5
+#define BW_8_MHZ 0
+#define BW_7_MHZ 1
+#define BW_6_MHZ 2
+#define BW_5_MHZ 3
+#define BW_ISDBT_1SEG 4
+#define BW_ISDBT_3SEG 5
#define MSG_HDR_FLAG_SPLIT_MSG 4
-#define MAX_GPIO_PIN_NUMBER31
+#define MAX_GPIO_PIN_NUMBER31
-#define HIF_TASK 11
-#define SMS_HOST_LIB 150
+#define HIF_TASK 11
+#define SMS_HOST_LIB 150
#define DVBT_BDA_CONTROL_MSG_ID201
#define SMS_MAX_PAYLOAD_SIZE 240
-#define SMS_TUNE_TIMEOUT 500
+#define SMS_TUNE_TIMEOUT 500
#define MSG_SMS_GPIO_CONFIG_REQ507
#define MSG_SMS_GPIO_CONFIG_RES508
@@ -212,45 +212,45 @@ struct smscore_device_t {
#define MSG_SMS_GPIO_SET_LEVEL_RES 510
#define MSG_SMS_GPIO_GET_LEVEL_REQ 511
#define MSG_SMS_GPIO_GET_LEVEL_RES 512
-#define MSG_SMS_RF_TUNE_REQ561
-#define MSG_SMS_RF_TUNE_RES562
+#define MSG_SMS_RF_TUNE_REQ561
+#define MSG_SMS_RF_TUNE_RES562
#define MSG_SMS_INIT_DEVICE_REQ578
#define MSG_SMS_INIT_DEVICE_RES579
#define MSG_SMS_ADD_PID_FILTER_REQ 601
#define MSG_SMS_ADD_PID_FILTER_RES 602
-#define MSG_SMS_REMOVE_PID_FILTER_REQ 603
-#define
Re: libv4l: Possibility of changing the current pixelformat on the fly
On 04/05/2009 02:58 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/05/2009 01:26 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Erm, yes that is what I was saying, but that is because I was confusing things with the sq905 driver some other people are working on. Glad that you were confused as I couldn't really make out the meaning of your answer. :) Now I understand what you were trying to ask. So the problem is that the vv6410 sensor can do flipping in hardware, and then the order in which it sends out the pixels changes from gbgbgb (for example) to bgbgbg, for the lines which have blue, effectively changing the pixelformat, right? Correct. In that case I think the only solution is to simply return -EBUSY when the vflip / hflip controls are changed while a stream is active. So this effectively forces a reprobe of the hardware? No, it just disallows changing the flipping (and thus the format) while an app is actively streaming. so one can use something like v4l2ucp, and change the flipping while the cam is not being used otherwise, but if for example skype or cheese or whatever is streaming data from the cam then the flip will be disallowed (and a device busy error will be returned). This may not seem very user friendly but normally one does not want to mess with the flip controls anyways unless the cam is mounted upside down or something like that. As for the race window with one application querying the format (or even setting it) and then another app changing the flip before the application which just set the format starts the stream, we already have that wrt 2 applications doing this: app a: setformat x app b: setformat y app a: start stream (thinking format is x) Which is something which normally (luckily) never happens. If this ever becomes a real issue, shouldn't some kind of user-space master program aquire the device and then handle format requests for all client programs? Yes, one of these days we need to think (very hard) about a much better way for sharing v4l devices. Does that sound like a plan ? Yes, I'll try this ASAP. Note that this is a solution at the driver level, which IMHO is the only way as we cannot assume libv4l is always being used. If it works this sounds like the most clean and elegant solution. The weak point being that the application must try to renegotiate the format upon the -EBUSY signal. No, the idea is that the flipping will simply not change (hence the error, signaling the setting of the flip control failed). Regards, Hans -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Mike, Selected answers, as most points have already been discussed elsewhere meanwhile... On Sat, 4 Apr 2009 18:29:35 -0500 (CDT), Mike Isely wrote: On Sun, 5 Apr 2009, Jean Delvare wrote: This is excellent news. As I said in the header comment of the patch, avoiding probing when we know what the IR receiver is and at which address it sits is the way to go. Please send me all the information you have and I'll be happy to add a patch to the series, that skips probing whenever possible. Or write that patch yourself if you prefer. I have samples of most of the devices in question and can code proper I2C addresses for each of those for each resident I2C client. The pvrusb2 driver's device attribute structure already has allowance for specification of the correct I2C addresses to use for chips specific to each device (part of the v4l2-subdev rework I recently did). Right now the driver has built in defaults, and if a particular model needs something else, it can be overridden as part of the device's profile in pvrusb2-devattr.c. Good. Declaring the right IR receiver device based on board information is clearly the way to go. I didn't make any assumption, sorry. I simply copied the code from ir-kbd-i2c. If my code does the wrong thing for some devices, that was already the case before. And this will certainly be easier to fix after my changes than before. No, I think the point you are missing is that by moving that logic from ir-kbd-i2c into each driver (e.g. pvrusb2) you are moving logic that *might* be executed into a spot where it *will* be executed. Yes, you are right. Remember that the pvrusb2 driver did not autoload ir-kbd-i2c before this patch. Before this change, a user could elect not to use ir-i2c-kbd simply by not loading it. Which was pretty fragile because another bridge driver could still have loaded it. The pvrusb2 driver didn't request it, because the intent all along there is that the user makes the choice by loading the desired driver. Which simply underlines how weird the current situation is... Forcing the choice on the user is pretty bad from a usability perspective. Now with this change, the pvrusb2 driver is going to attempt to load ir-kbd-i2c where asked for or not. Not exactly, only the device will be the instantiated, the drivers won't be loaded, but the result is indeed the same: it's getting in lirc_i2c's way if that's what the user wants to use. And if not, the resulting binding will prevent lirc_i2c from later on loading. If the user had been loading lirc_i2c previously, this will cause his/her usage of IR to break. No, it's not perfect, but it worked. I'm all for improving things, but not by removing an ability that people are using. I have just added a disable_ir module parameter to work around this issue. Set it to 1 and no ir-kbd device will be instantiated, letting lirc_i2c do whatever it wants with the IR receiver device. You might argue that this is still a regression because the user now has to pass an extra parameter to get the same result as before, but OTOH lirc_i2c will need changes pretty soon anyway, its behavior will have to be changed and the users will notice. There's no way we can go from the current weird situation to a sane situation without changing the (unfortunate) user habits. (...) I really don't want to throw rocks here; it's always better to work out the solution than simply block any changes at all. I realize that something has to be done here in order to keep ir-kbd-i2c viable as a choice for users of the pvrusb2 driver. To that end, how about this strategy: 1. Just drop the part of the patch for the pvrusb2 driver and get the rest merged. Yes, I realize that this will break use of ir-kbd-i2c in cooperation with the pvrusb2 driver. As Mauro already said: not acceptable. Breaking an in-tree driver (ir-kbd-i2c) is worse than breaking an out-of-tree driver (lirc_i2c) regardless of the respective number of users or usefulness of these drivers. 2. Once ir-kbd-i2c has been updated, I will push another set of changes into the pvrusb2 driver that will make it usable there. Basically what I have in mind is similar to what you tried but I'm going to integrate it with the device profiles so that it can be appropriately loaded based on device model, with the correct I2C address in each case. And most importantly, I will add a module option to enable/disable loading or ir-kbd-i2c. This will fix my main objection, since then it will still allow lirc to be usable, for now... This sounds like a good idea. 3. I'd like to fix the abuse you mention regarding I2C_HW_B_BT848. I'm unclear on what the cleanest solution is there, but if you like to (a) point at some documentation, (b) describe what I should do, or (c) suggest a patch, I will work to deal with the problem. Ideally these adapter IDs will no longer be needed within a
Siano's patches
Hi Mauro, Please note patches (1..19) series @ http://patchwork.kernel.org/project/linux-media/list/?submitter=uri I'll wait for reviews and commit for this series before submitting additional patches. Pierre - the SDIO binding (registering) is still to be submitted, it isn't included within patches 1..19. Regards, Uri -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. Janne -- 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/6] ir-kbd-i2c conversion to the new i2c binding model
Hi Mauro, On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: From the discussions we already have, I noticed some points to take care of: 1) about the lirc support, I don't think we should change a kernel driver due to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we need to better address this with lirc developers; Well, the new binding model makes it harder for rogue drivers such as lirc_i2c. They will need _some_ form of cooperation from us, which will most likely come when they get merged into the kernel tree. 2) the way Mike is proposing to solve the issue with pvrusb2 will break userspace usage for people that have those devices whose IR work with the in-kernel IR i2c driver. This means that we'll cause a kernel regression due to an out-of-tree driver; 3) So far, nobody gave us any positive return that the new IR model is working with any of the touched drivers. So, more tests are needed. I'm expecting to have a positive reply for each of the touched drivers. People, please test! Yes, please! :) Since the merge window is almost finished, IMO, we should postpone those changes to 2.6.31, (...) The legacy i2c model will be gone in 2.6.30. Really. Hans and myself have put enough energy into this to not let it slip for just a miserable infrared support module which I understand is hardly used by anyone. So it's really up to you, either you accept my ir-kbd-i2c conversion now (that is, when it has received the minimum testing and reviewing it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build failures. to better address the lirc issue and to give people more time for testing, applying the changesets after the end of the merge window at the v4l/dvb development tree. This will help people to test, review and propose changes if needed. These changes are on-going for over a year now. If the lirc people didn't hear about it so far, I doubt they will pay more attention just because we delay the deadline by 2 months. The only thing that will get their attention is when lirc_i2c break. So let's just do that ;) Don't get me wrong. I don't want to be (too) rude to lirc developers. If they need help to port their code to the new i2c binding model, I'll help them. If they need help to merge lirc_i2c into the kernel, I'll help as well. But I don't see any point in delaying important, long awaited kernel changes just for them. As long as they are out-of-tree, they can fix things after the fact easily. They aren't affected by the merge window. They'll have several weeks before kernel 2.6.30 is actually released, which they can use to fix anything that broke. Thanks, -- Jean Delvare -- 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] Remove support for Genpix-CW3K (damages hardware)
Hi Alan, On Wed, 01 Apr 2009 13:01:25 -0700 Alan Nisota alannis...@gmail.com wrote: Patrick Boettcher wrote: Hi Alan, Don't you think it is enough to put a Kconfig option to activate the USB-IDs (by default: off) rather than throwing everything away? We could, but honestly, there are likely few people using this device who don't have to patch their kernel anyway, and it is a trivial patch to apply. There have been 4 incarnations of the CW3K as the manufacturer has tried to actively make it not work in Linux (and users have found ways around that for each subsequent revision). When I created the patch, I was not aware that the developer would take this stance. Only the 1st batch of devices works with the existing code, and I'm not aware of any way to detect the device version. Given the manufacturer's stance and the potential to unknowingly damage the device (I've been informed that the manufacturer has stated that use of the Linux drivers with the CW3K will void any manufacturer's warranty), I would rather remove support for this piece of hardware outright. I believe the manufacturer still supports the 8PSK-USB and Skywalker1 versions of the hardware on Linux (plus a new Skywalker2 which requires a kernel patch to enable). We shouldn't drop support for a device just because the manufacturer doesn't want it to be supported. If it really damages the hardware or violates the warranty, then we can print a warning message clearly stating that the vendor refuses to collaborate, briefly explaining the issues and recommending the user to replace the device to some other from a vendor-friendly at dmesg, but keep allowing they to use it, with some force option for people that wants to take the risk. This is just my 2 cents. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, This is a new request pull to rewrite_eeprom tool. I have added validations, warning messages and a backup feature. Since I don't have any em2874/em2884 device I am not able to implement any addicional validation but it seems already safe enough. for these devices too. - v4l2-apps/util: Add rewrite_eeprom tool Thanks, Douglas -- 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] Remove support for Genpix-CW3K (damages hardware)
Mauro Carvalho Chehab wrote: We shouldn't drop support for a device just because the manufacturer doesn't want it to be supported. If it really damages the hardware or violates the warranty, then we can print a warning message clearly stating that the vendor refuses to collaborate, briefly explaining the issues and recommending the user to replace the device to some other from a vendor-friendly at dmesg, but keep allowing they to use it, with some force option for people that wants to take the risk. I'm not going to go through the entire soap-opera as I know it, but basically the manufacturer has 2 tiers of devices, those that were designed to work only with a specific piece of hardware, and those that are supported in Windows and Linux, but come with a significant price premium. The latter devices are supported by the kernel and should be continued to be. The former is what we're talking about and what my patch removes support for. The patch was in response to real users with real problems. I am in no way associated with the manufacturer other than that he provided me with initial help writing the Linux drivers several years ago. I no longer have a use for the drivers myself, and any support I do is just to help the community out. I have provided a patch which makes the driver safe to use. If you prefer an alternate method of achieving the same goal, or wish to just ignore it altogether, that is ok, but I don't have the time to develop and test a patch that is more complicated then what I've already posted. If you are going to take any action, I would prefer it get pushed into the current kernel development tree to minimize the potential harm to users. -- 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
Problem with the Hauppauge Nexus CA
Hi, i am trying to get the Hauppauge Nexus CA's analogue tuner to work with 2.6.26. No matter what i do all i get is the DVB as tuner. I got some help on #linuxtv that indicated that the saa7146 driver lacks support for the analogue tuner, and has lacked it for some time. Is this by design? Should i get a new card, or is this fixable in any way? /Carl -- 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: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
On Sun, 5 Apr 2009 07:29:00 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Fri, 03 Apr 2009 20:29:08 +0200 Erik Andrén erik.and...@gmail.com wrote: Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/ for more m5602-gspca changeset that are 2.6.30 material. I'm preparing the last 2.6.30 material for sending upstream. Could you please merge this quickly today? Hello Mauro, It seems there is a problem with my messages: on March 27, I sent to you and to the list a pull request for the first set of Erik's changesets. The message came back normally to me as if it was sent to all people. But I cannot see it in the list archives! I am resending it now. Then, for 2.6.30, there are still the second set of Erik and 2 or three changesfrom me. Do I add these changesets to the current unpulled ones in my stable repository? Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Here is my previous pull request. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11224:2258bd92f522 gspca - vc032x: Remove the JPEG tables of mi1320_soc. changeset: 11225:ea6d8f0cd083 gspca - m5602-s5k4aa: No more default mode changeset: 11226:630fa8f75f42 gspca - m5602-s5k4aa: Add start function and VGA resolution init. changeset: 11227:7b14d00aa61c gspca - m5602: Simplify error handling changeset: 11228:89647a4acf75 gspca - m5602-ov9650: Add QCIF resolution support changeset: 11229:7578294f06cd gspca - m5602-ov9650: Clean up ov9650_start() function. changeset: 11230:8863f4fdf25e gspca - m5602-s5k83a: Add led support to the s5k83a sensor. changeset: 11231:817e36da4fd9 gspca - m5602-ov9650: Set the ov9650 sensor in soft sleep when inactive. changeset: 11232:9d0a113a28a4 gspca - m5602-ov9650: Always init the ov9650 before starting a stream changeset: 11233:871b2546315d gspca - m5602: Rework v4l ctrl handling in all sensors changeset: 11234:04c1227d412f gspca - m5602-ov9650: Checkpatch fixes changeset: 11235:089b896afa94 gspca - m5602-mt9m111: Separate mode vectors per sensor. changeset: 11236:531f8383ff70 gspca - m5602-mt9m111: Move v4l2 controls to main sensor file. changeset: 11237:ea5335dfb00e gspca - m5602: Remove an unused member in the sd struct. changeset: 11238:f915d64a686e gspca - m5602: Constify all sensor structs changeset: 11239:be006d6783fb gspca - m5602-ov9650: Autogain is on by default changeset: 11240:ad9622150aea gspca - m5602-ov9650: Auto white balancing is on by default changeset: 11241:82263c1cbdee gspca - m5602-ov9650: Don't read exposure data from COM1. changeset: 11242:a640fe97ac35 gspca - m5602: Improve error handling in the ov9650 driver changeset: 11243:9d70484bfca5 gspca - m5602-ov9650: Synthesize modesetting. changeset: 11244:dc66997ccf36 gspca - m5602-ov9650: Replace a magic constant with a define changeset: 11245:ecbaf91c8745 gspca - m5602-ov9650: Add a disconnect hook, setup a ctrl cache ctrl. changeset: 11246:0310786ebedc gspca - m5602-ov9650: Use the local ctrl cache. Adjust image on vflip. changeset: 11247:1bebd29cecc3 gspca - m5602: Move the vflip quirk to probe stage. changeset: 11248:6b4f4f173a66 gspca - m5602: Don't touch hflip/vflip register on Read/Modify/Write changeset: 11249:7c1aa8d0507f gspca - m5602: Minor cleanups Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Janne, On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git I tried to clone this but it failed: git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I will happily help you with the i2c side of things. Without an access to your git tree however, I don't know the latest state of your code. And I can't see any lirc_zilog module in the CVS repository of lirc either. But if you show me the i2c code you're worried about, I'll let you know what I think about it. -- Jean Delvare -- 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: libv4l: Possibility of changing the current pixelformat on the fly
On Sun, 5 Apr 2009, Hans de Goede wrote: On 04/05/2009 01:26 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: On 04/04/2009 10:22 PM, Erik Andrén wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, While trying to get hflip and vflip working for the stv06xx webcam bridge coupled to the vv6410 sensor I've come across the following problem. When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. The changing of the pixelformat only happens when you flip the data before conversion. If you look at the current upside down handling code you will see it does the rotate 180 degrees after conversion. This is how the vflip / hflip should be handled too. We only have 4 (2 really since we don't care about r versus b / u versus v while flippiing) destination formats for which we then need to write flipping code. Otherwise we need to write flipping code for *all* supported input formats, not to mention flipping some input formats is close to impossible (JPEG for example). So you mean we should do the vflip/hflip in software, just exposing one native format? Erm, yes that is what I was saying, but that is because I was confusing things with the sq905 driver some other people are working on. Now I understand what you were trying to ask. So the problem is that the vv6410 sensor can do flipping in hardware, and then the order in which it sends out the pixels changes from gbgbgb (for example) to bgbgbg, for the lines which have blue, effectively changing the pixelformat, right? You mention the sq905 cameras, and the general problem of image flipping. You comment that the order of the data changes if any kind of flipping is done, with the result that the image format (Bayer tiling) changes. One difference I do see here is that the vv6410 sensor can do flipping in hardware which the sq905 cameras obviously can not. However, the fact that the Bayer tiling of the image must change in accordance with the flipping is equally present. And I do not see how that problem could be avoided, on any occasion when flipping is needed. This brings up an interesting question of what would be the most efficient way actually to do the required image flipping: If the flipping is done before the finished image is produced, then the Bayer tiling of the image has changed. Therefore a different treatment is needed. If the flipping is done after the finished image is produced, then there is three times as much data, and the flipping might take longer (or might not if it were done exactly right?). Therefore, how best to do this? As I said, I am thinking about the sq905 driver. One of its peculiarities, as far as I can tell, is that the cameras all use the same Bayer tiling before the flipping. But after the flipping it is obviously a different story. The approach that was taken in the libgphoto2 driver for the sq905 cameras was to do the flipping first, and then to apply the right Bayer tiling afterward for the particular camera. Clearly, that could also be done here. However, is that the best way to go about it? Perhaps in fact it is simpler to do the flipping of an entire finished image, instead. Then one would of course have to move triples instead of single bytes, in order to leave the color mapping unmolested. It is interesting that this problem comes up with some other cameras, too. Theodore Kilgore
Re: Driver for GL861+AF9003+MT2060]
El Fri, 03 Apr 2009 01:03:23 +0300 Antti Palosaari cr...@iki.fi escribió: You don't need to implement all those in most cases. read_ber, read_signal_strength, read_snr, read_ucblocks and get_frontend are not obligatory *required* in any? case. Besides, IIRC, not all signal information functions were implemented in the af9005 (I didn't know all the details of the chipset and the expected scale in the dvb driver). They're nice to have but not indispensable. Bye -- Luca -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 06:37:43PM +0200, Jean Delvare wrote: Hi Janne, On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote: Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git I tried to clone this but it failed: git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) hmm, getting that here too. I'll send Jarod a mail. You can use my clone instead: git://git.jannau.net/linux-2.6-lirc.git I will happily help you with the i2c side of things. Without an access to your git tree however, I don't know the latest state of your code. And I can't see any lirc_zilog module in the CVS repository of lirc either. But if you show me the i2c code you're worried about, I'll let you know what I think about it. lirc_zilog or lirc_pvr is not in lirc's cvs since it requires a 'firmware' for mapping keys to sequences for the ir blaster. Janne -- 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] [0904_11] Siano: smsendian smsdvb - binding the smsendian to smsdvb
--- On Sun, 4/5/09, Uri Shkolnik uri...@yahoo.com wrote:
From: Uri Shkolnik uri...@yahoo.com
Subject: [PATCH] [0904_11] Siano: smsendian smsdvb - binding the smsendian
to smsdvb
To: LinuxML linux-media@vger.kernel.org
Date: Sunday, April 5, 2009, 1:20 PM
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1238743608 -10800
# Node ID 01979ae55ffec22d74b77681613f38bd606be227
# Parent ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
[PATCH] [0904_11] Siano: smsendian smsdvb - binding
the smsendian to smsdvb
From: Uri Shkolnik u...@siano-ms.com
Bind the smsendian, which manipulates some Siano's messages
content
when using Siano chip-set with big-endian target,
with the DVB-API v3 client adapter.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r ec7ee486fb86 -r 01979ae55ffe
linux/drivers/media/dvb/siano/Makefile
---
a/linux/drivers/media/dvb/siano/Makefile
Fri Apr 03 10:10:22 2009 +0300
+++
b/linux/drivers/media/dvb/siano/Makefile
Fri Apr 03 10:26:48 2009 +0300
@@ -1,4 +1,4 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
diff -r ec7ee486fb86 -r 01979ae55ffe
linux/drivers/media/dvb/siano/smsdvb.c
---
a/linux/drivers/media/dvb/siano/smsdvb.c
Fri Apr 03 10:10:22 2009 +0300
+++
b/linux/drivers/media/dvb/siano/smsdvb.c
Fri Apr 03 10:26:48 2009 +0300
@@ -24,7 +24,7 @@ along with this program. If not,
see h
#include asm/byteorder.h
#include smscoreapi.h
-/*#include smsendian.h*/
+#include smsendian.h
#include sms-cards.h
#ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
@@ -52,7 +52,7 @@ struct smsdvb_client_t {
fe_status_t fe_status;
int fe_ber, fe_snr, fe_unc,
fe_signal_strength;
- struct completion tune_done,
stat_done;
+ struct completion tune_done;
/* todo: save freq/band instead whole
struct */
struct dvb_frontend_parameters
fe_params;
@@ -114,7 +114,7 @@ static int smsdvb_onresponse(void
*conte
u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr-msgLength -
sizeof(struct SmsMsgHdr_ST);*/
- /*smsendian_handle_rx_message((struct
SmsMsgData_ST *) phdr);*/
+ smsendian_handle_rx_message((struct
SmsMsgData_ST *) phdr);
switch (phdr-msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -271,7 +271,7 @@ static int smsdvb_start_feed(struct
dvb_
PidMsg.xMsgHeader.msgLength =
sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- /* smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)PidMsg); */
+ smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)PidMsg);
return
smsclient_sendrequest(client-smsclient, PidMsg,
sizeof(PidMsg));
}
@@ -291,7 +291,7 @@ static int smsdvb_stop_feed(struct
dvb_d
PidMsg.xMsgHeader.msgLength =
sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- /* smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)PidMsg); */
+ smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)PidMsg);
return
smsclient_sendrequest(client-smsclient, PidMsg,
sizeof(PidMsg));
}
@@ -302,7 +302,7 @@ static int
smsdvb_sendrequest_and_wait(s
{
int rc;
- /* smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)buffer); */
+ smsendian_handle_tx_message((struct
SmsMsgHdr_ST *)buffer);
rc =
smsclient_sendrequest(client-smsclient, buffer, size);
if (rc 0)
return rc;
--
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
This patch is voided and been replaced by another (newer) patch.
--
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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 15:08 +0200, Jean Delvare wrote: Hi Andy, If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I can simplify my patch set and omit the cx18 entirely. Which I just did... The HVR-1600 could have been supported by ir-kbd-i2c. It's submission was redirected slightly here: http://lkml.org/lkml/2009/2/3/118 And deferred here: http://www.spinics.net/lists/linux-media/msg03883.html until your changes were done. OK. Then let's indeed get my changes merged first, and then we can see the best way to add support for the HVR-1600 IR. OK. I'll test your change anyway if I can. lirc_pvr150 has always been out of kernel and likely always will be. Any valid reason? Out-of-free drivers are a pain for users :( Well, like many of the lirc modules, it's a little kludged. The main problem is this: 1. lirc_pvr150, in the past, needed to make a direct call into the ivtv module to reset the IR chip, if it detected that the chip was hung up. That's why it tries to load the ivtv module, to make sure that symbol is in the kernel. This could cause problems, if it was a Z8 chip that was supported by some other bridge driver. I wrote a patch for lirc_pvr150 for cx18 devices for users who needed it. lirc_zilog is the cut down version of lirc_pvr150 module that was submitted in the patchset to the LKML, and no longer has the reset logic. The reset logic is not needed anymore as far as I can tell, and thus the cx18 specific patch is probably irrelevant for lirc_zilog. Other weird things include: 2. In lirc_pvr150 and lirc_zilog, both the IR Rx and IR Tx support are in one module, which is a break from the normal LIRC driver modules that keep those functions separate. This was done for the sake of detecting if the chip had hung up and to call the reset logic, AFAICT. 3. lirc_pvr150 and lirc_zilog have an IR blaster firmware image that is really an encoding of a bunch of captured sequences between the Windows driver and the Z8F0811 chip. It allows the lirc_zilog or lirc_pvr150 driver to do IR blasting by essentially performing a replay attack on the Z8F0811. Since the Zilog EULA that comes with the Hauppauge Windows IR driver for the Z8F0811 is pretty draconian, replaying captured snoops is probably the best that can be done legally to stimulate the microcontroller IR Tx code in the Z8 as delivered. Regards, Andy -- 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] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Apr 5 19:00:09 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11392:151524ab300a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote: On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote: I would guess that it won't work. There is an effort to merge lirc. It's currently stalled though. Perhaps you and Jarrod and Christopher have already discussed this, but... Instead of trying to push all of the LIRC kernel components through in one big patch set, perhaps it would be easier to just get the lirc_dev and any other needed infrastructure components in first. If one focuses on satisfying the LKML comments to lirc_dev and the Makefile to get that kernel module in the kernel, then, at least for video card hosted IR devices, there is an infrastructure to which to hook new or rewritten i2c IR driver modules. I guess lkml would NAK patches adding infrastructure only bits but we will probably for the next patchset concentrate on a few lirc drivers. Christopher doesn't participate in the merge attempt. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I can help with this. I'm mainly concerned with lirc_dev, lirc_i2c (for Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2. That's because, of course, I have devices that use those modules. :) I have devices for lirc_zilog (which should probably be merged with lirc_i2c) and lirc serial. Jarod has at least mce usb and imon devices. That are probably the devices we'll concentrate on the next submission. lirc_dev and the API header would be my first priority, if you need help. Did anyone consolidate all the comments from the LKML on Jarrod's patch submission? no and I lost track which comments were already handled. Janne -- 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/6] ir-kbd-i2c conversion to the new i2c binding model
On Sun, 5 Apr 2009, Jean Delvare wrote: Hi Mauro, On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: From the discussions we already have, I noticed some points to take care of: 1) about the lirc support, I don't think we should change a kernel driver due to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we need to better address this with lirc developers; Well, the new binding model makes it harder for rogue drivers such as lirc_i2c. They will need _some_ form of cooperation from us, which will most likely come when they get merged into the kernel tree. 2) the way Mike is proposing to solve the issue with pvrusb2 will break userspace usage for people that have those devices whose IR work with the in-kernel IR i2c driver. This means that we'll cause a kernel regression due to an out-of-tree driver; It's an either/or. If nothing is done, the ir-kbd-i2c become unusable for pvrusb2 but lirc (for now) continues to work. If Jean's change is accepted as-is, then ir-kbd-i2c will be ok but now lirc is toast. If I implement what I am suggesting, then it becomes possible at least for both cases to still work, but with a module option. Not perfect, but it is the only way I see to allow this situation to retain some sanity. In the longer term, the lirc folks are going to have to change what they are doing. Fine, that's a problem they have to solve. It's nothing I can do anyting about. But I am not going to be the instigator that breaks lirc as used by the pvrusb2 driver. In the short term, implementing the module option breaks the deadlock here. Jean can continue getting rid of the old i2c model and I won't be a pain about it. 3) So far, nobody gave us any positive return that the new IR model is working with any of the touched drivers. So, more tests are needed. I'm expecting to have a positive reply for each of the touched drivers. People, please test! Yes, please! :) Since the merge window is almost finished, IMO, we should postpone those changes to 2.6.31, (...) The legacy i2c model will be gone in 2.6.30. Really. Hans and myself have put enough energy into this to not let it slip for just a miserable infrared support module which I understand is hardly used by anyone. So it's really up to you, either you accept my ir-kbd-i2c conversion now (that is, when it has received the minimum testing and reviewing it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build failures. Accept his ir-kbd-i2c conversion now, minus the pvrusb2 changes. I will deal with the pvrusb2 driver appropriately (and immediately). That should resolve the issue for the short term. to better address the lirc issue and to give people more time for testing, applying the changesets after the end of the merge window at the v4l/dvb development tree. This will help people to test, review and propose changes if needed. These changes are on-going for over a year now. If the lirc people didn't hear about it so far, I doubt they will pay more attention just because we delay the deadline by 2 months. The only thing that will get their attention is when lirc_i2c break. So let's just do that ;) Don't get me wrong. I don't want to be (too) rude to lirc developers. If they need help to port their code to the new i2c binding model, I'll help them. If they need help to merge lirc_i2c into the kernel, I'll help as well. But I don't see any point in delaying important, long awaited kernel changes just for them. As long as they are out-of-tree, they can fix things after the fact easily. They aren't affected by the merge window. They'll have several weeks before kernel 2.6.30 is actually released, which they can use to fix anything that broke. I agree. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Hans Verkuil wrote: [...] Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those drivers that did not autoload this module. The driver author can refine things later (I'll definitely will do that for ivtv). Yes, and I will do the same for pvrusb2. Simple is good. It will be interesting if someone can find out whether lirc will work at all once autoprobing is removed from i2c. If it isn't, then perhaps that will wake them up to the realization that they really need to move to the kernel. It's probably going to break, and that will wake them up. There's no choice otherwise. The new mechanism is the right way to do it: the adapter driver has all the information if, where and what IR is used and so should be the one to tell the kernel what to do. Attempting to autodetect and magically figure out what IR might be there is awkward and probably impossible to get right 100%. Hell, it's wrong already: if you have another board that already loads ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c whether you like it or not, because ir-kbd-i2c will connect to your i2c adapter like a leech. So with the addition of a module option you at least give back control of this to the user. Yes, I know this is a possibility. It sucks and long term the new mechanism is the solution. I don't want anyone to think I am against the new mechanism. I'm for it. But I'd like to minimize the damage potential on the way there. When this initial conversion is done I'm pretty sure we can improve ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. So we don't need those horrible adapter ID tests and other magic that's going on in that driver. But that's phase two. My impression (at least for pvrusb2-driven devices) is that the later IR receivers require a completely different driver to work properly; one can't just bolt additional features into ir-kbd-i2c for this. In lirc's case, a different driver is in fact used. But you know this already. I haven't looked at ir-kbd-i2c in a while, but one other thing I seriously did not like about it was that the mapping of IR codes to key events was effectively hardcoded in the driver. That makes it difficult to make the same driver work with different kinds of remotes. Even if the bridge driver (e.g. pvrusb2) were to supply such a map, that's still wrong because it's within the realm of possibility that the user might actually want to use a different remote transmitter (provided it is compatible enough to work with the receiver hardware). The lirc architecture solves this easily via a conf file in userspace. In fact, lirc can map multiple mappings to a single receiver, permitting it to work concurrently with more than one remote. But is such a thing even possible with ir-kbd-i2c? I know this is one reason people tend to choose lirc. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: libv4l: Possibility of changing the current pixelformat on the fly
On Sun, 5 Apr 2009, Jean-Francois Moine wrote: On Sat, 04 Apr 2009 22:22:19 +0200 Erik Andrén erik.and...@gmail.com wrote: [snip] When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. Hi Erik, I saw such a problem in some other webcams. When doing a flip, the sensor scans the pixels in the reverse order. So, R G R G G B G B becomes B G B G G R G R The solution is to start the scan one line lower or higher for VFLIP and one pixel on the left or on the right for HFLIP. May you do this with all the sensors of the stv06xx? That is a very clever solution -- if the hardware will do such a thing. I can not speak for the stv06xx cameras, of course. But I am pretty sure it is impossible for the sq905 cameras. Therefore it is not a universal solution. If it can be done, great. But it seems to me that the general way to do this would be just to adjust the Bayer tiling to be in accord with the flipping after it is done (one of the possibilities already mentioned above). The problem which I would address is that the need for image flipping ought to be handled in a standard way, if possible. The sq905 cameras (with which I have been directly concerned) do give rise to similar problems. The big difference is that there is no way with an sq905 to tell the camera to do any flipping in hardware, nor to shift the pixel reading one space over or down. Hence my obvious interest in seeing this problem analysed completely, and in seeing the best solution adopted. One possible way to do that would be to have the choice for the pixel format to reflect what it ought to be, after any flipping has taken place. From this point of view, it would not matter if the flipping is done in V4L or in hardware, before the data has left the camera. It would only be necessary to agree that any required flipping takes place first, and then the Bayer interpolation afterwards. Theodore Kilgore
Re: libv4l: Possibility of changing the current pixelformat on the fly
2009/4/5 Jean-Francois Moine moin...@free.fr: On Sat, 04 Apr 2009 22:22:19 +0200 Erik Andrén erik.and...@gmail.com wrote: [snip] When flipping the image horizontally, vertically or both, the sensor pixel ordering changes. In the m5602 driver I was able to compensate for this in the bridge code. In the stv06xx I don't have this option. One way of solving this problem is by changing the pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal format. When a vertical flip is required, change the format to V4L2_SBGGR8. My current understanding of libv4l is that it probes the pixelformat upon device open. In order for this to work we would need either poll the current pixelformat regularly or implement some kind of notification mechanism upon a flipping request. What do you think is this the right way to go or is there another alternative. Hi Erik, I saw such a problem in some other webcams. When doing a flip, the sensor scans the pixels in the reverse order. So, R G R G G B G B becomes B G B G G R G R The solution is to start the scan one line lower or higher for VFLIP and one pixel on the left or on the right for HFLIP. As I wrote in my original email I haven't found out a way to adjust this when using the vv6410 sensor. May you do this with all the sensors of the stv06xx? This issue is vv6410 specific. Best regards, Erik Andrén Cheers. -- Ken ar c'hentan | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote: If one focuses on satisfying the LKML comments to lirc_dev and the Makefile to get that kernel module in the kernel, then, at least for video card hosted IR devices, there is an infrastructure to which to hook new or rewritten i2c IR driver modules. I guess lkml would NAK patches adding infrastructure only bits but we will probably for the next patchset concentrate on a few lirc drivers. Christopher doesn't participate in the merge attempt. Oh, OK. A git tree is available at git://git.wilsonet.com/linux-2.6-lirc.git Jared Wilson and I were working on it (mainly last september). Since the IR on the HD PVR is also driven by the same zilog chip as on other hauppauge devices I'll take of lirc_zilog. Help converting the i2c drivers to the new i2c model is welcome. General cleanup of lirc to make it ready for mainline is of course wellcome too. I can help with this. I'm mainly concerned with lirc_dev, lirc_i2c (for Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2. That's because, of course, I have devices that use those modules. :) I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. I'd personally leave lirc_zilog separate since it handles Tx and RX for one specific chip, and lirc_i2c is Rx only for a number of chips. Perhaps dropping Rx support for the Zilog Z8 in lirc_i2c and then modifying lirc_zilog to still do Rx, even if the firmware wasn't available for Tx, is a better way to go. and lirc serial. Jarod has at least mce usb and imon devices. That are probably the devices we'll concentrate on the next submission. OK. lirc_dev and the API header would be my first priority, if you need help. Did anyone consolidate all the comments from the LKML on Jarrod's patch submission? no and I lost track which comments were already handled. Hmm. Well good luck. Let me know if I can help. I have 2 cards with the Zilog and a USB unit that is supported by lirc_mceusb2. Regards, Andy Janne -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 16:05 +0200, Jean Delvare wrote:
Hi Hans,
Hi Jean,
Updated patch set is available at:
http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-04-04
10:58:36.0 +0200
[snip]
-
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
[snip]
I just noticed you're missing address 0x71 for ivtv. At least some
PVR-150 boards have a Zilog chip at that address.
Regards,
Andy
--
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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 13:33 -0500, Mike Isely wrote: Also, lirc makes it possible to userspace map the underlying IR codes to keybindings and associate multiple different remotes - all of that is apparently hardcoded in ir-kbd-i2c. Yes. My first remote for my PC was an HP OEM'ed and customized unit. LIRC's text configuration files made support for the remote's non-standard keys a task for 'vi' and not 'make'. Key mappings belong in configuration files - not hard coded in the kernel. Wierd or not, your change makes it hard(er) on those who legitimately wish to use lirc. Here's an interesting summary: If fact, the only pvrusb2-driven hardware from Hauppauge that is known to work with ir-kbd-i2c are the old 29xxx and 24xxx model series (not the MCE series). Those devices are out of production, AFAIK. The current devices being sold by Hauppauge don't work at all with ir-kbd-i2c and probably never will. Perhaps one can conclude that there hasn't been a lot of pressure (that I know about) to deal with updating / enhancing / replacing ir-kbd-i2c because lirc happens to be filling the niche better in many cases. Here is where LIRC may be its own worst enemy. LIRC has filled some shortcomings in the kernel for support of IR device functions for so long (LWN says LIRC is 10 years old), that large numbers of users have come to depend on its operation, while at the same time apparently removing impetus for doing much to update the in kernel IR device support. Some of the discussion on the LKML about why an input layer device is sufficient for handling most, but not all cases is interesting: http://lkml.org/lkml/2008/9/11/63 Gerd also enlightens us on why we have ir-kdb-i2c in kernel in that post. It appears that ir-kbd-i2c was written to avoid using LIRC for TV card I2C IR devices for the most common use cases. As such, it's a 90% (80%, 70% ?) solution: no blasting, no raw IR parsing for unknown protocols, only the most common remotes supported, and, of course, no support for non-I2C devices. My needs don't fit that unfortunately. I need IR blasting, an uncommon remote supported, and both USB and I2C IR device support. Regards, Andy -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. This really doesn't matter. With the new binding model, probing is under control. You can do probing on some cards and not others, and you can probe some addresses and not others. And one i2c drivers can cleanly support more than one device type. What should be considered to decide whether two devices should be supported by the same driver or not, is how much their supporting code has in common. -- Jean Delvare -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare: On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote: I have devices for lirc_zilog (which should probably be merged with lirc_i2c) Hmmm. Following Jean's reasoning, that may be the wrong way to go, if you want to avoid probing. A module to handle each specific type of I2C IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be better in the long run. This really doesn't matter. With the new binding model, probing is under control. You can do probing on some cards and not others, and you can probe some addresses and not others. And one i2c drivers can cleanly support more than one device type. Hmm, I'm still happy with the broken DVB-T for saa7134 on 2.6.29, tasting some Chianti vine now and need to sleep soon, but I'm also not that confident that your saa7134 MSI t...@nywhere Plus i2c remote does work addressing it directly, since previous reports always said it becomes only visible at all after other devices are probed previously. Unfortunately I can't test it, but will try to reach some with such hardware and ask for testing, likely not on the list currently. What should be considered to decide whether two devices should be supported by the same driver or not, is how much their supporting code has in common. What can not be translated to the input system I would like to know. Andy seems to have closer looked into that. To have it was a need after 2.5.x turned into 2.6.x. It was not even in sight if and when lirc would be ever usable on it again. You have it from Gerd. I also think we currently have lots of users with all sorts of TV cards. Triple cards are still quite expensive and can have only one DVB and one analog stream at once, Quad cards depend on special PCI slots and PCIe multi capable cards are not yet supported. Because of that, there are lots of mythtv and similar machines stuffed with all sort of cards in every free PCI slot I think. Cheers, Hermann -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote: Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare: On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: What can not be translated to the input system I would like to know. Andy seems to have closer looked into that. 1. IR blasting: sending IR codes to transmit out to a cable convertor box, DTV to analog convertor box, or similar devices to change channels before recording starts. An input interface doesn't work well for output. 2. Sending raw IR samples to user space: user space applications can then decode or match an unknown or non-standard IR remote protocol in user space software. Timing information to go along with the sample data probably needs to be preserved. I'm assuming the input interface currently doesn't support that. That's all the Gerd mentioned. One more nice feature to have, that I'm not sure how easily the input system could support: 3. specifying remote control code to key/button translations with a configuration file instead of recompiling a module. In effect there are actually two devices the ir-kbd-i2c input driver is supporting in various combinations: an IR receiver and an IR remote. Regards, Andy -- 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 1 of 3] cx88: Add support for stereo and sap detection for A2
On Mon, 6 Apr 2009 02:36:01 +0200 (CEST) Marton Balint c...@fazekas.hu wrote: On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote: Hi Marton, I suspect that you will need to use div64 math or some othe way to calculate the freq: /home/v4l/master/v4l/cx88-dsp.c: In function 'detect_a2_a2m_eiaj': /home/v4l/master/v4l/cx88-dsp.c:147: error: SSE register return with SSE disabled make[3]: *** [/home/v4l/master/v4l/cx88-dsp.o] Error 1 make[3]: *** Waiting for unfinished jobs Gcc should have optimised away the floating point operations and the __builtin_remainder function. Hmm, it seems that older gcc's don't do this. Would you try the attached patch? It uses integer modulo instead of __builtin_remainder, so only basic floating point operations needs optimising, hopefully every common gcc version will be able to do it. Worked. I've folded this patch with the previous one, to avoid bisect breakage upstream. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net wrote:
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
What can not be translated to the input system I would like to know.
Andy seems to have closer looked into that.
1. IR blasting: sending IR codes to transmit out to a cable convertor
box, DTV to analog convertor box, or similar devices to change channels
before recording starts. An input interface doesn't work well for
output.
On my understanding, IR output is a separate issue. AFAIK, only a very few ivtv
devices support IR output. I'm not sure how this is currently implemented.
2. Sending raw IR samples to user space: user space applications can
then decode or match an unknown or non-standard IR remote protocol in
user space software. Timing information to go along with the sample
data probably needs to be preserved. I'm assuming the input interface
currently doesn't support that.
If the driver processes correctly the IR samples, I don't see why you would
need to pass the raw protocols to userspace. Maybe we need to add some ioctls
at the API to allow certain controls, like, for example, ask kernel to decode
IR using RC4 instead or RC5, on devices that supports more than one IR protocol.
That's all the Gerd mentioned.
One more nice feature to have, that I'm not sure how easily the input
system could support:
3. specifying remote control code to key/button translations with a
configuration file instead of recompiling a module.
The input and the current drivers that use input already supports this feature.
You just need to load a new code table to replace the existing one.
See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
contains a complete code to fully replace a key code table. Also, the Makefile
there will extract the current keytables for the in-kernel drivers.
Btw, with only 12 lines, you can create a keycode replace hello world!:
#include fcntl.h /* due to O_RDONLY */
#include stdio.h /* open() */
#include linux/input.h/* input ioctls and keycode macros */
#include sys/ioctl.h /* ioctl() */
void main(void)
{
int codes[2];
int fd = open(/dev/video0, O_RDONLY); /* Hmm.. in real apps, we
should check for errors */
codes[0] = 10; /* Scan code */
codes[1] = KEY_UP; /* Key code */
ioctl(fd, EVIOCSKEYCODE, codes);/* hello world! */
}
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Andy, Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls: On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote: Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare: On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote: What can not be translated to the input system I would like to know. Andy seems to have closer looked into that. 1. IR blasting: sending IR codes to transmit out to a cable convertor box, DTV to analog convertor box, or similar devices to change channels before recording starts. An input interface doesn't work well for output. 2. Sending raw IR samples to user space: user space applications can then decode or match an unknown or non-standard IR remote protocol in user space software. Timing information to go along with the sample data probably needs to be preserved. I'm assuming the input interface currently doesn't support that. That's all the Gerd mentioned. One more nice feature to have, that I'm not sure how easily the input system could support: 3. specifying remote control code to key/button translations with a configuration file instead of recompiling a module. In effect there are actually two devices the ir-kbd-i2c input driver is supporting in various combinations: an IR receiver and an IR remote. Regards, Andy you always end up with something transmitting series of 0s and 1s. It does not matter if the medium is infrared, infradead ;), wireless or whats or ever. If it spares a chip for the remote and you have to get it from IRQs triggered, you have to do that. It could also be some voltage change, a ultrasound beeper or what ever. The first place for such is the input layer and nothing out of the kernel. Cheers, Hermann -- 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
how to watch Pay TV under linux
Dear all: I know if I want to see pay tv, it seems I have to got a tv card which supports ci module. Would anyone tell me which card that linux driver already support so far? appreciate your help, miloody -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls awa...@radix.net wrote:
On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
What can not be translated to the input system I would like to know.
Andy seems to have closer looked into that.
1. IR blasting: sending IR codes to transmit out to a cable convertor
box, DTV to analog convertor box, or similar devices to change channels
before recording starts. An input interface doesn't work well for
output.
On my understanding, IR output is a separate issue. AFAIK, only a very few
ivtv
devices support IR output. I'm not sure how this is currently implemented.
For the pvrusb2 driver, MCE style 24xxx devices (2nd generation 24xxx)
and HVR-1950 devices have IR blasting capabilities. At the moment,
people have gotten this to work on the 24xxx model with the appropriate
lirc driver. In theory it should be doable for HVR-1950 as well (and
the pvrusb2 does what is needed to make it possible) but I don't think
anyone has succeeded there yet.
Sure IR output as a concept and interface is a separate issue. But it
can be implemented in the same chip (which is the case in the two
examples I list above). So the issue is not separate; it must be dealt
with as a whole. Two drivers implementing different features but trying
to share one chip is just not fun.
2. Sending raw IR samples to user space: user space applications can
then decode or match an unknown or non-standard IR remote protocol in
user space software. Timing information to go along with the sample
data probably needs to be preserved. I'm assuming the input interface
currently doesn't support that.
If the driver processes correctly the IR samples, I don't see why you would
need to pass the raw protocols to userspace. Maybe we need to add some ioctls
at the API to allow certain controls, like, for example, ask kernel to decode
IR using RC4 instead or RC5, on devices that supports more than one IR
protocol.
Ugh. Why should v4l-dvb get into this business when it's already solved
somewhere else? In userspace even.
I see in so many other places people arguing for V4L functionality that
needs to be kicked out of the kernel and put into userspace. For
example, there's all that silliness over pixel formats that I'm soon
going to have to deal with...
Yet in this case with IR, there already exists a subsystem that does
*more* than ir-kbd-i2c.c, AND it does all the crazy configuration /
control in userspace - and yet you argue that ir-kbd-i2c.c should be
preferred? Purely because lirc is not in-tree? Well heck, lirc should
be in-tree. Let's help them get there and forget ever having to deal
with IR again ourselves. Let them do it.
That's all the Gerd mentioned.
One more nice feature to have, that I'm not sure how easily the input
system could support:
3. specifying remote control code to key/button translations with a
configuration file instead of recompiling a module.
The input and the current drivers that use input already supports this
feature.
You just need to load a new code table to replace the existing one.
See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
contains a complete code to fully replace a key code table. Also, the Makefile
there will extract the current keytables for the in-kernel drivers.
Btw, with only 12 lines, you can create a keycode replace hello world!:
#include fcntl.h/* due to O_RDONLY */
#include stdio.h/* open() */
#include linux/input.h /* input ioctls and keycode macros */
#include sys/ioctl.h/* ioctl() */
void main(void)
{
int codes[2];
int fd = open(/dev/video0, O_RDONLY); /* Hmm.. in real apps, we
should check for errors */
codes[0] = 10; /* Scan code */
codes[1] = KEY_UP; /* Key code */
ioctl(fd, EVIOCSKEYCODE, codes);/* hello world! */
}
I just looked at this. I freely admit I haven't noticed this before,
but having looked at it now, and having examined ir-kbd-i2c.c, I still
don't see the whole picture here:
1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently
implicitly trying to assume a particular type of remote based on the I2C
address of the IR receiver it's talking to. Yuck. That's really not
right at all. The IR receiver used does not automatically mean which
remote is used. What if the vendor switches remotes? That's happened
with the PVR-USB2 hardware in the past (based on photos I've seen).
Who's to say the next remote to be supplied is compatible?
2. Your example above is opening the video device endpoint and issuing
ioctl()s that are not part of V4L. That is supposed to work?!?
Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Andy Walls wrote: Here is where LIRC may be its own worst enemy. LIRC has filled some shortcomings in the kernel for support of IR device functions for so long (LWN says LIRC is 10 years old), that large numbers of users have come to depend on its operation, while at the same time apparently removing impetus for doing much to update the in kernel IR device support. More than that. In 1997 I bought a serial port remote off ebay and tried to get it to work with linux. I found an abandoned project from the Metzler brothers called LIRC, though it didn't work. I wrote a new protocol for the serial port driver, which was the only one at the time, rewrote the remote pulse decoding code and came up a new socket based the client/server protocol and wrote the x-event client. At that point remotes were defined in header files so make was still needed to add a new one. -- 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
pvrusb2 IR changes coming [was: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model]
Jean: Here's a description of what I've got on the front burner right now: 1. The pvrusb2 driver now can unambiguously know if it is dealing with a device that is known to have ir-kbd-i2c compatible IR capabilities. 2. There is a new module option, disable_autoload_ir_kbd, which if present and set to 1 will indicate that ir-kbd should not be loaded. 2. Based upon (1) and (2), the driver will optionally attempt to load ir-kbd using the code from your patch. 3. In the pvrusb2 case, the only i2c address that currently matters is 0x18 (though I have some suspicions about another case but that can be dealt with later), so I trimmed the probe list in the register function you had added. Since calling i2c_new_probed_device() for a non-existent target driver doesn't cause any harm, then merging the above now should not result in any kind of regression. So it can go in even before the rest of your changes. That I believe also removes the objection Mauro had - this way there's no issues / dependencies. I've tested this enough to know that it at least doesn't do any further harm. I will put this up in a changeset shortly. With all that said, we should not ignore lirc and instead do whatever is reasonable to help ensure it continues to work. Though admittedly there's been plenty of opportunity to update and this whole transition has been going on for a long time. The stuff I describe above should at least keep the pvrusb2 driver out of the fray for now. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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/6] ir-kbd-i2c: Switch to the new-style device binding model
On Sun, 5 Apr 2009, Mike Isely wrote: 1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently implicitly trying to assume a particular type of remote based on the I2C address of the IR receiver it's talking to. Yuck. That's really not right at all. The IR receiver used does not automatically mean which remote is used. What if the vendor switches remotes? That's happened with the PVR-USB2 hardware in the past (based on photos I've seen). Who's to say the next remote to be supplied is compatible? IMHO, the way the remote supported is compiled into the kernel is absurd. The system I setup 12 years ago was better than this. At least the remote was compiled into a userspace daemon and multiple remotes were supported at the same time. The keycode system I used had a remote id/key id split, so you could have volume up key on any remote control the mixer but make the power buttons on different remotes turn on different apps. 3. A given IR remote may be described by much more than what 'scan codes' it produces. I don't know a lot about IR, but looking at the typical lirc definition for a remote, there's obvious timing and protocol parameters as well. Just being able to swap scan codes around is not always going to be enough. A remote typically sends a header sequence of a long pulse and space before the code. The length of the pulse on the space varies greatly by remote and makes a good way to identify the remote when multiple ones are supported. Then a pulse coded remote sends a sequence bits, usually 8 to 32. The length of the pulse identifies 1s or 0s. Different remotes have different pulse lengths and different spaces between them. RC5 remotes use Manchester encoding for this part. When you hold a key down some remotes just repeat the same sequence over and over again. Some repeat the scan code but omit the header part. Some send out a special pulse sequence to indicate the last key is being held down. With the latter two methods you can tell the difference between a key being held down and a key being pressed repeatedly. With the first you have guess based on how fast the repeats are coming in. This is very different than a keyboard, which sends a code when you press a key and another when you release it. The rate at which remotes repeat varies greatly. You might find that one remote makes your volume change annoying slowly while another is much too fast to be usable. Remote keys usually start repeating without delay, so if you let a toggle like 'mute' repeat it becomes almost impossible to hit it just once. Entering numbers becomes impossible as well. -- 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
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 changesets. One sets up the ability to track what kind of IR receiver is expected, the other optionally autoloads ir-kbd-i2c based on that result and a module option that can be used to disable that autoloading. This is the result of what I had posted about an hour ago. It looks like a lot of lines, but it was all basically trivial stuff. Note that these changes are safe; nothing is regressed here and this does not depend on anyone else's changes. Even though that second changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, the fact is that it won't cause any harm either. Since the pvrusb2 driver wasn't previously autoloading ir-kbd-i2c anyway, this change therefore breaks nothing. But it does have the desirable effect in that it should take me out of the IR debate for now and I can stop being a pain to Jean :-) Jean: I hope I didn't break any etiquette here. Though that second change is from me, the majority of the changeset really is from your patch to the pvrusb2 driver. I made changes to it so I didn't feel right in still trying to blame you for it ;-) Plus, if I were to hand it back to you for inclusion in your patch series then you would be dependant upon the pvrusb2 change I made to drive the decision about loading based on the device hardware. Since this change as a whole is mergeable without the rest of your changeset I felt it most expedient just to push this up now. -Mike - pvrusb2: Select, track, and report IR scheme in use with the device - pvrusb2: autoload ir-kbd when appropriate pvrusb2-devattr.c |1 + pvrusb2-devattr.h | 22 +++--- pvrusb2-hdw-internal.h |3 +++ pvrusb2-hdw.c | 18 +- pvrusb2-i2c-core.c | 40 ++-- 5 files changed, 66 insertions(+), 18 deletions(-) -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
