Re: Failed build on randconfig for DVB_DIB modules
On Fri, 2010-11-12 at 22:54 -0500, Steven Rostedt wrote: > Or we just don't test for define(MODULE). If either CONFIG_DVB_DIB3000MC > or CONFIG_DVB_DIB3000MC_MODULE are defined, the code must be there, > because, if this code is built as both a module and builtin, only the > builtin will be created. Ah, I just tried it, and I see that the code in that #if statement calls back into the dib3000mc module, so now the core kernel has missing functions. This is a bit of a nasty web. I guess it would require one of your proposed solutions, or I just simply add the dvb configs to my broken-config file and prevent randconfig from testing it. -- Steve -- 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: Failed build on randconfig for DVB_DIB modules
Sorry for the late reply, but KS and LPC got in the way. Also added kbuild to the Cc. On Tue, 2010-10-26 at 09:37 -0200, Mauro Carvalho Chehab wrote: > Hi Steven, > > Em 26-10-2010 02:15, Steven Rostedt escreveu: > > I'm currently finishing up an automated test program (that I will be > > publishing shortly). This program does various randconfig builds, boots > > and tests (as well as bisecting and patch set testing). But enough about > > it. > > > > I hit this little build bug that is more annoying than anything else. If > > I have the following configuration: > > > > > > CONFIG_DVB_USB_DIBUSB_MB=y > > CONFIG_DVB_USB_DIBUSB_MC=m > > CONFIG_DVB_USB_NOVA_T_USB2=m > > > > It fails to build with this error: > > > > ERROR: "dibusb_dib3000mc_frontend_attach" > > [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! > > ERROR: "dibusb_dib3000mc_tuner_attach" > > [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! > > ERROR: "dibusb_dib3000mc_frontend_attach" > > [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined! > > ERROR: "dibusb_dib3000mc_tuner_attach" > > [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined! > > > > Those undefined functions are defined in > > drivers/media/dvb/dvb-usb/dibusb-common.c, but are surrounded by: > > > > #if defined(CONFIG_DVB_DIB3000MC) || > > \ > > (defined(CONFIG_DVB_DIB3000MC_MODULE) && defined(MODULE)) > > > > Which Mauro updated in Dec 2007 with this commit: > > 4a56087f3b7660c9824e9ec69b96ccf8d9b25d1c > > due to just having CONFIG_DVB_DIB3000MC not enough. > > > > Well, this is not enough either. Why? > > > > On build the object dibusb-common.o is built first because of the > > DVB_USB_DIBUSB_MB being builtin kernel core. Thus, it gets built with > > the preprocessor condition false. > > > > Then when the compile gets to the modules, the object dibusb-common.o > > has already been built, and gets linked in as is. > > > > We end up with the functions not defined and we get the above error. > > > > My question: Why does that preprocessor condition exist? Can't we just > > build those functions in regardless? > > Not sure if I understood your question. Short answer is: No. What about just changing it to: #if defined(CONFIG_DVB_DIB3000MC) || defined(CONFIG_DVB_DIB3000MC_MODULE) Looking at the kbuild system scripts/Makefile.lib we have: # When an object is listed to be built compiled-in and modular, # only build the compiled-in version obj-m := $(filter-out $(obj-y),$(obj-m)) So if this is defined as both a module and builtin, the module version will never be built. Then we need that code in that #if block regardless. No need for testing the define(MODULE). > > > > A detailed explanation follows: > > > > On DVB drivers, there are a few separate > components: > - Tuner - receives the signal from antenna, converting them into an > intermediate frequency, tune to a station; > - Demod - decodes the intermediate frame into a MPEG-TS; > - Bridge - talks with the PCI/USB/.. bus and send/receive commands to > Demod/Frontend. > > The tuner + frontend + satellite controller are called frontend. > > On a typical design, tuners are a separate chip, interconnected via an I2C > bus, and > the demod may be separate or integrated with the bridge (or with the tuner). > > Since the design is modular, the same frontend may be used by different > bridges, and a > given bridge may work with more than one frontend, depending on the specific > device you may have. > > So, we basically have one Kconfig option for each component, to allow > building kernels with > the minimum footprint. > > For example, picking a random DVB bridge: > > config DVB_DM1105 > tristate "SDMC DM1105 based PCI cards" > depends on DVB_CORE && PCI && I2C > depends on INPUT > select DVB_PLL if !DVB_FE_CUSTOMISE > select DVB_STV0299 if !DVB_FE_CUSTOMISE > select DVB_STV0288 if !DVB_FE_CUSTOMISE > select DVB_STB6000 if !DVB_FE_CUSTOMISE > select DVB_CX24116 if !DVB_FE_CUSTOMISE > select DVB_SI21XX if !DVB_FE_CUSTOMISE > select DVB_DS3000 if !DVB_FE_CUSTOMISE > > The components at the select are the frontend. > > In this specific case, there's just one demod supported (stv0299), > but it allows using 6 different types of tuners. > > If you want to build a kernel with a minimal footprint, and if you have just > one device type, > you'll need only one tuner driver. > > > > In the specific case you're mentioning, we have the following bridge drivers: > > config DVB_USB_NOVA_T_USB2 > tristate "Hauppauge WinTV-NOVA-T usb2 DVB-T USB2.0 support" > depends on DVB_USB > select DVB_DIB3000MC > select DVB_PLL if !DVB_FE_CUSTOMISE > select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE > > config DVB_USB_DIBUSB_MB > tristate "DiBcom USB DVB-T devices (based on the DiB3000M-B) (see h
[PATCH v2] mceusb: fix keybouce issue after parser simplification
Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.
As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a timeout value.
The hardware has a timeout value we're now reading and storing, which
properly enables the transition to idle in the raw event storage
process, and makes IR decode behave correctly w/o keybounce.
Also remove no-longer-used ir_raw_event struct from mceusb_dev struct
and add as-yet-unused enable flags for carrier reports and learning
mode, which I'll hopefully start wiring up sooner than later. While
looking into that, found evidence that 0x9f 0x15 responses are only
non-zero when the short-range learning sensor is used, so correct the
debug spew message, and then suppress it when using the standard
long-range sensor.
Signed-off-by: Jarod Wilson
---
v2: fix flub w/duplicate case select values and really test the
final product this time...
drivers/media/rc/mceusb.c | 56 +
1 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index bb89992..968cf1f 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -47,6 +47,7 @@
#define USB_BUFLEN 32 /* USB reception buffer length */
#define USB_CTRL_MSG_SZ2 /* Size of usb ctrl msg on gen1 hw */
#define MCE_G1_INIT_MSGS 40 /* Init messages on gen1 hw to throw out */
+#define MS_TO_NS(msec) ((msec) * 1000)
/* MCE constants */
#define MCE_CMDBUF_SIZE384 /* MCE Command buffer length */
@@ -90,6 +91,7 @@
#define MCE_CMD_G_TXMASK 0x13/* Set TX port bitmask */
#define MCE_CMD_S_RXSENSOR 0x14/* Set RX sensor (std/learning) */
#define MCE_CMD_G_RXSENSOR 0x15/* Get RX sensor (std/learning) */
+#define MCE_RSP_PULSE_COUNT0x15/* RX pulse count (only if learning) */
#define MCE_CMD_TX_PORTS 0x16/* Get number of TX ports */
#define MCE_CMD_G_WAKESRC 0x17/* Get wake source */
#define MCE_CMD_UNKNOWN7 0x18/* Unknown */
@@ -312,7 +314,10 @@ static struct usb_device_id mceusb_dev_table[] = {
struct mceusb_dev {
/* ir-core bits */
struct rc_dev *rc;
- struct ir_raw_event rawir;
+
+ /* optional features we can enable */
+ bool carrier_report_enabled;
+ bool learning_enabled;
/* core device bits */
struct device *dev;
@@ -326,6 +331,8 @@ struct mceusb_dev {
/* buffers and dma */
unsigned char *buf_in;
unsigned int len_in;
+ dma_addr_t dma_in;
+ dma_addr_t dma_out;
enum {
CMD_HEADER = 0,
@@ -333,10 +340,8 @@ struct mceusb_dev {
CMD_DATA,
PARSE_IRDATA,
} parser_state;
- u8 cmd, rem;/* Remaining IR data bytes in packet */
- dma_addr_t dma_in;
- dma_addr_t dma_out;
+ u8 cmd, rem;/* Remaining IR data bytes in packet */
struct {
u32 connected:1;
@@ -417,7 +422,7 @@ static int mceusb_cmdsize(u8 cmd, u8 subcmd)
case MCE_CMD_UNKNOWN:
case MCE_CMD_S_CARRIER:
case MCE_CMD_S_TIMEOUT:
- case MCE_CMD_G_RXSENSOR:
+ case MCE_RSP_PULSE_COUNT:
datasize = 2;
break;
case MCE_CMD_SIG_END:
@@ -538,10 +543,11 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
inout, data1 == 0x02 ? "short" : "long");
break;
case MCE_CMD_G_RXSENSOR:
- if (len == 2)
+ /* aka MCE_RSP_PULSE_COUNT */
+ if (out)
dev_info(dev, "Get receive sensor\n");
- else
- dev_info(dev, "Remaining pulse count is %d\n",
+ else if (ir->learning_enabled)
+ dev_info(dev, "RX pulse count: %d\n",
((data1 << 8) | data2));
break;
case MCE_RSP_CMD_INVALID:
@@ -795,6 +801,34 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32
carrier)
return carrier;
}
+/*
+ * We don't do anything but print debug spew for many of the command bits
+ * we receive from the hardware, but some of them are useful information
+ * we want to store so that we can use them.
+ */
+static void mceusb_handle_command(struct mceusb_dev *ir, int index)
+{
+ u8 hi = ir->buf_in[index + 1] & 0xff;
+ u8 lo = ir->buf_in[index + 2] & 0xff;
+
+ switch (ir->buf_in[index]) {
+ /* 2-byte return value commands */
+ case MCE_CMD_S_TIMEOUT:
+
[PATCH] mceusb: fix keybouce issue after parser simplification
Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.
As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a timeout value.
The hardware has a timeout value we're now reading and storing, which
properly enables the transition to idle in the raw event storage
process, and makes IR decode behave correctly w/o keybounce.
Also remove no-longer-used ir_raw_event struct from mceusb_dev struct
and add as-yet-unused enable flags for carrier reports and learning
mode, which I'll hopefully start wiring up sooner than later. While
looking into that, found evidence that 0x9f 0x15 responses are only
non-zero when the short-range learning sensor is used, so correct the
debug spew message, and then suppress it when using the standard
long-range sensor.
Signed-off-by: Jarod Wilson
---
drivers/media/rc/mceusb.c | 57 +
1 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index bb89992..b62f368 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -47,6 +47,7 @@
#define USB_BUFLEN 32 /* USB reception buffer length */
#define USB_CTRL_MSG_SZ2 /* Size of usb ctrl msg on gen1 hw */
#define MCE_G1_INIT_MSGS 40 /* Init messages on gen1 hw to throw out */
+#define MS_TO_NS(msec) ((msec) * 1000)
/* MCE constants */
#define MCE_CMDBUF_SIZE384 /* MCE Command buffer length */
@@ -90,6 +91,7 @@
#define MCE_CMD_G_TXMASK 0x13/* Set TX port bitmask */
#define MCE_CMD_S_RXSENSOR 0x14/* Set RX sensor (std/learning) */
#define MCE_CMD_G_RXSENSOR 0x15/* Get RX sensor (std/learning) */
+#define MCE_RSP_PULSE_COUNT0x15/* RX pulse count (only if learning) */
#define MCE_CMD_TX_PORTS 0x16/* Get number of TX ports */
#define MCE_CMD_G_WAKESRC 0x17/* Get wake source */
#define MCE_CMD_UNKNOWN7 0x18/* Unknown */
@@ -312,7 +314,10 @@ static struct usb_device_id mceusb_dev_table[] = {
struct mceusb_dev {
/* ir-core bits */
struct rc_dev *rc;
- struct ir_raw_event rawir;
+
+ /* optional features we can enable */
+ bool carrier_report_enabled;
+ bool learning_enabled;
/* core device bits */
struct device *dev;
@@ -326,6 +331,8 @@ struct mceusb_dev {
/* buffers and dma */
unsigned char *buf_in;
unsigned int len_in;
+ dma_addr_t dma_in;
+ dma_addr_t dma_out;
enum {
CMD_HEADER = 0,
@@ -333,10 +340,8 @@ struct mceusb_dev {
CMD_DATA,
PARSE_IRDATA,
} parser_state;
- u8 cmd, rem;/* Remaining IR data bytes in packet */
- dma_addr_t dma_in;
- dma_addr_t dma_out;
+ u8 cmd, rem;/* Remaining IR data bytes in packet */
struct {
u32 connected:1;
@@ -417,7 +422,7 @@ static int mceusb_cmdsize(u8 cmd, u8 subcmd)
case MCE_CMD_UNKNOWN:
case MCE_CMD_S_CARRIER:
case MCE_CMD_S_TIMEOUT:
- case MCE_CMD_G_RXSENSOR:
+ case MCE_RSP_PULSE_COUNT:
datasize = 2;
break;
case MCE_CMD_SIG_END:
@@ -538,10 +543,12 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
inout, data1 == 0x02 ? "short" : "long");
break;
case MCE_CMD_G_RXSENSOR:
- if (len == 2)
+ if (out)
dev_info(dev, "Get receive sensor\n");
- else
- dev_info(dev, "Remaining pulse count is %d\n",
+ break;
+ case MCE_RSP_PULSE_COUNT:
+ if (!out && ir->learning_enabled)
+ dev_info(dev, "RX pulse count: %d\n",
((data1 << 8) | data2));
break;
case MCE_RSP_CMD_INVALID:
@@ -795,6 +802,34 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32
carrier)
return carrier;
}
+/*
+ * We don't do anything but print debug spew for many of the command bits
+ * we receive from the hardware, but some of them are useful information
+ * we want to store so that we can use them.
+ */
+static void mceusb_handle_command(struct mceusb_dev *ir, int index)
+{
+ u8 hi = ir->buf_in[index + 1] & 0xff;
+ u8 lo = ir->buf_in[index + 2] & 0xff;
+
+ switch (ir->buf_in[index]) {
+ /* 2-byte return value commands */
+ case MCE_CMD_S_TIMEOUT:
+ ir->rc->timeout = MS_TO_NS((hi << 8 | lo) / 2);
+
[PATCH] IR: allow disabling NEC checksum check, enable apple remote
In strict NEC extended IR protocol, a 32-bit signal consists of address,
not address, command and not command, and checksums are performed
between these two pairs of components. Currently, our NEC protocol
decoder strictly enforces these checks, and only uses 24 bits (address,
not address and command) to do scancode to keycode lookups. However,
there are remotes out there using a variant of the NEC protocol, which
assigns different meaning to some of these bits, without using any
checksums.
The test case here is Apple's remotes, which send a two-byte vendor
code instead of address/not address, a pairing ID byte, and a command
byte instead of command/not command.
For further details on the Apple remotes, see:
http://en.wikipedia.org/wiki/Apple_Remote
If we make it possible to bypass the checksum checks and use the full
32 bits for scancode lookups, the current NEC decoder can successfully
successfully decode and match keys from these remotes, as well as any
others that might employ similar alternate bit meanings.
In the Apple case, we can simply match the vendor code and auto-skip the
checksum checks. For other remotes, we can bypass the checksum by
handing a modparam to the NEC decoder, unless of course we figure out
some other means by which to determine if its a signal for which we
should skip checksumming, and/or develop something cleaner, and/or
decide to only warn (in debug mode) when checksum checks fail.
An Apple keytable using the full 32 bits is included. Existing NEC
extended remotes should continue to fuction with their current 24-bit
tables, but we *could* decide in the future to simplify things and just
use the full 32 bits for all NEC extended (ish) remotes.
Signed-off-by: Jarod Wilson
---
drivers/media/rc/ir-nec-decoder.c | 40
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-nec-apple.c | 51 +++
include/media/rc-map.h |1 +
4 files changed, 86 insertions(+), 7 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-nec-apple.c
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 8ff157a..abe9b4d 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -28,6 +28,16 @@
#defineNEC_TRAILER_SPACE (10 * NEC_UNIT) /* even longer in
reality */
#define NECX_REPEAT_BITS 1
+static bool csum = true;
+module_param(csum, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(csum, "Whether or not to perform NEC chucksum checks "
+"(default: true)");
+
+static bool pair;
+module_param(pair, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(pair, "Whether or not the Apple Pairing ID byte should "
+"be evaluated for scancode lookups (default: false)");
+
enum nec_state {
STATE_INACTIVE,
STATE_HEADER_SPACE,
@@ -49,6 +59,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct nec_dec *data = &dev->raw->nec;
u32 scancode;
u8 address, not_address, command, not_command;
+ bool checksum = csum;
if (!(dev->raw->enabled_protocols & IR_TYPE_NEC))
return 0;
@@ -157,22 +168,37 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
command = bitrev8((data->bits >> 8) & 0xff);
not_command = bitrev8((data->bits >> 0) & 0xff);
- if ((command ^ not_command) != 0xff) {
+ if ((address == 0xee) && (not_address == 0x87)) {
+ IR_dprintk(1, "Apple remote detected, pair ID 0x%02x\n",
+ not_command);
+ checksum = false;
+ /* We have a default non-paired keymap using 0x00 */
+ if (!pair)
+ not_command = 0x00;
+ }
+
+ if (checksum && ((command ^ not_command) != 0xff)) {
IR_dprintk(1, "NEC checksum error: received 0x%08x\n",
data->bits);
break;
}
- if ((address ^ not_address) != 0xff) {
- /* Extended NEC */
+ if (checksum && ((address ^ not_address) == 0xff)) {
+ /* Normal NEC */
+ scancode = address << 8 | command;
+ IR_dprintk(1, "NEC scancode 0x%04x\n", scancode);
+ } else if (!checksum) {
+ /* Extended NEC, no checksum */
+ scancode = address << 24 | not_address << 16 |
+ command << 8 | not_command;
+ IR_dprintk(1, "NEC (Ext, no csum) scancode 0x%08x\n",
+ scancode);
+ } else {
+ /* Extended NEC, standard */
scancode = ad
[PULL] git://kernellabs.com/stoth/saa7164-dev.git
Mauro, Please pull the following changes. The following changes since commit 5ed5d45da807a6d0d1d06bfe45b3623f97ce2797: Steven Toth (1): [media] saa7164: Checkpatch compliance cleanup are available in the git repository at: git://kernellabs.com/stoth/saa7164-dev.git master gitweb access here: http://www.kernellabs.com/gitweb/?p=stoth/saa7164-dev.git Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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
[omap3isp RFC][PATCH 03/10] omap3: Fix camera resources for multiomap
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c | 27 ---
1 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c2275d3..c9fc732 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -38,7 +38,7 @@
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
-static struct resource cam_resources[] = {
+static struct resource omap2cam_resources[] = {
{
.start = OMAP24XX_CAMERA_BASE,
.end= OMAP24XX_CAMERA_BASE + 0xfff,
@@ -50,19 +50,15 @@ static struct resource cam_resources[] = {
}
};
-static struct platform_device omap_cam_device = {
+static struct platform_device omap2cam_device = {
.name = "omap24xxcam",
.id = -1,
- .num_resources = ARRAY_SIZE(cam_resources),
- .resource = cam_resources,
+ .num_resources = ARRAY_SIZE(omap2cam_resources),
+ .resource = omap2cam_resources,
};
+#endif
-static inline void omap_init_camera(void)
-{
- platform_device_register(&omap_cam_device);
-}
-
-#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
+#if defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
static struct resource omap3isp_resources[] = {
{
@@ -165,15 +161,16 @@ struct platform_device omap3isp_device = {
},
};
EXPORT_SYMBOL_GPL(omap3isp_device);
+#endif
static inline void omap_init_camera(void)
{
-}
-#else
-static inline void omap_init_camera(void)
-{
-}
+#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
+ if (cpu_is_omap24xx())
+ platform_device_register(&omap2cam_device);
#endif
+}
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 07/10] omap3isp: Remove CSIA/B register abstraction
Signed-off-by: Sergio Aguirre --- drivers/media/video/isp/isp.c |8 drivers/media/video/isp/ispccp2.c |2 +- drivers/media/video/isp/ispreg.h |3 --- 3 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c index f266e7c..de9352b 100644 --- a/drivers/media/video/isp/isp.c +++ b/drivers/media/video/isp/isp.c @@ -264,12 +264,12 @@ static void isp_power_settings(struct isp_device *isp, int idle) (ISPCSI1_MIDLEMODE_SMARTSTANDBY << ISPCSI1_MIDLEMODE_SHIFT), OMAP3_ISP_IOMEM_CSI2A_REGS1, - ISP_CSIA_SYSCONFIG); + ISPCSI2_SYSCONFIG); isp_reg_writel(isp, ISPCSI1_AUTOIDLE | (ISPCSI1_MIDLEMODE_SMARTSTANDBY << ISPCSI1_MIDLEMODE_SHIFT), OMAP3_ISP_IOMEM_CCP2, - ISP_CSIB_SYSCONFIG); + ISPCCP2_SYSCONFIG); } isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL); @@ -284,13 +284,13 @@ static void isp_power_settings(struct isp_device *isp, int idle) (ISPCSI1_MIDLEMODE_FORCESTANDBY << ISPCSI1_MIDLEMODE_SHIFT), OMAP3_ISP_IOMEM_CSI2A_REGS1, - ISP_CSIA_SYSCONFIG); + ISPCSI2_SYSCONFIG); isp_reg_writel(isp, ISPCSI1_AUTOIDLE | (ISPCSI1_MIDLEMODE_FORCESTANDBY << ISPCSI1_MIDLEMODE_SHIFT), OMAP3_ISP_IOMEM_CCP2, - ISP_CSIB_SYSCONFIG); + ISPCCP2_SYSCONFIG); } isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN, diff --git a/drivers/media/video/isp/ispccp2.c b/drivers/media/video/isp/ispccp2.c index 45506a7..fa23394 100644 --- a/drivers/media/video/isp/ispccp2.c +++ b/drivers/media/video/isp/ispccp2.c @@ -421,7 +421,7 @@ static void ispccp2_mem_configure(struct isp_ccp2_device *ccp2, isp_reg_writel(isp, (ISPCSI1_MIDLEMODE_SMARTSTANDBY << ISPCSI1_MIDLEMODE_SHIFT), - OMAP3_ISP_IOMEM_CCP2, ISP_CSIB_SYSCONFIG); + OMAP3_ISP_IOMEM_CCP2, ISPCCP2_SYSCONFIG); /* Hsize, Skip */ isp_reg_writel(isp, ISPCCP2_LCM_HSIZE_SKIP_MIN | diff --git a/drivers/media/video/isp/ispreg.h b/drivers/media/video/isp/ispreg.h index c080980..d885541 100644 --- a/drivers/media/video/isp/ispreg.h +++ b/drivers/media/video/isp/ispreg.h @@ -236,9 +236,6 @@ #define ISPCCP2_LCM_DST_ADDR (0x1E8) #define ISPCCP2_LCM_DST_OFST (0x1EC) -#define ISP_CSIB_SYSCONFIG ISPCCP2_SYSCONFIG -#define ISP_CSIA_SYSCONFIG ISPCSI2_SYSCONFIG - /* CCDC module register offset */ #define ISPCCDC_PID(0x000) -- 1.7.0.4 -- 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
[omap3isp RFC][PATCH 06/10] omap3isp: Remove unused CBUFF register access
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/isp.c|2 --
drivers/media/video/isp/isp.h|1 -
drivers/media/video/isp/ispreg.h | 25 -
3 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c
index a5c02ba..f266e7c 100644
--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -86,7 +86,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
{
.isp_rev = ISP_REVISION_2_0,
.map = 1 << OMAP3_ISP_IOMEM_MAIN |
- 1 << OMAP3_ISP_IOMEM_CBUFF |
1 << OMAP3_ISP_IOMEM_CCP2 |
1 << OMAP3_ISP_IOMEM_CCDC |
1 << OMAP3_ISP_IOMEM_HIST |
@@ -100,7 +99,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
{
.isp_rev = ISP_REVISION_15_0,
.map = 1 << OMAP3_ISP_IOMEM_MAIN |
- 1 << OMAP3_ISP_IOMEM_CBUFF |
1 << OMAP3_ISP_IOMEM_CCP2 |
1 << OMAP3_ISP_IOMEM_CCDC |
1 << OMAP3_ISP_IOMEM_HIST |
diff --git a/drivers/media/video/isp/isp.h b/drivers/media/video/isp/isp.h
index edc029c..b8f63e2 100644
--- a/drivers/media/video/isp/isp.h
+++ b/drivers/media/video/isp/isp.h
@@ -56,7 +56,6 @@
enum isp_mem_resources {
OMAP3_ISP_IOMEM_MAIN,
- OMAP3_ISP_IOMEM_CBUFF,
OMAP3_ISP_IOMEM_CCP2,
OMAP3_ISP_IOMEM_CCDC,
OMAP3_ISP_IOMEM_HIST,
diff --git a/drivers/media/video/isp/ispreg.h b/drivers/media/video/isp/ispreg.h
index 8e4324f..c080980 100644
--- a/drivers/media/video/isp/ispreg.h
+++ b/drivers/media/video/isp/ispreg.h
@@ -37,11 +37,6 @@
#define OMAP3ISP_REG_BASE OMAP3430_ISP_BASE
#define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset))
-#define OMAP3ISP_CBUFF_REG_OFFSET 0x0100
-#define OMAP3ISP_CBUFF_REG_BASE(OMAP3ISP_REG_BASE +
\
-OMAP3ISP_CBUFF_REG_OFFSET)
-#define OMAP3ISP_CBUFF_REG(offset) (OMAP3ISP_CBUFF_REG_BASE + (offset))
-
#define OMAP3ISP_CCP2_REG_OFFSET 0x0400
#define OMAP3ISP_CCP2_REG_BASE (OMAP3ISP_REG_BASE +\
OMAP3ISP_CCP2_REG_OFFSET)
@@ -244,26 +239,6 @@
#define ISP_CSIB_SYSCONFIG ISPCCP2_SYSCONFIG
#define ISP_CSIA_SYSCONFIG ISPCSI2_SYSCONFIG
-/* ISP_CBUFF Registers */
-
-#define ISP_CBUFF_SYSCONFIG(0x010)
-#define ISP_CBUFF_IRQENABLE(0x01C)
-
-#define ISP_CBUFF0_CTRL(0x020)
-#define ISP_CBUFF1_CTRL(0x024)
-
-#define ISP_CBUFF0_START (0x040)
-#define ISP_CBUFF1_START (0x044)
-
-#define ISP_CBUFF0_END (0x050)
-#define ISP_CBUFF1_END (0x054)
-
-#define ISP_CBUFF0_WINDOWSIZE (0x060)
-#define ISP_CBUFF1_WINDOWSIZE (0x064)
-
-#define ISP_CBUFF0_THRESHOLD (0x070)
-#define ISP_CBUFF1_THRESHOLD (0x074)
-
/* CCDC module register offset */
#define ISPCCDC_PID(0x000)
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 02/10] omap3isp: ccdc: Write SYN_MODE.INPMOD based on fmt
This takes into account the input format to select the
adequate configuration for SYNC mode.
Also, change bitmask ISPCCDC_SYN_MODE_INPMOD_MASK to be
more consistent with other bitmasks.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispccdc.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index bee2bbe..c3d1d7a 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -1071,6 +1071,9 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
isp_configure_bridge(isp, ccdc->input, pdata);
ispccdc_config_sync_if(ccdc, &ccdc->syncif);
+ /* CCDC_PAD_SINK */
+ format = &ccdc->formats[CCDC_PAD_SINK];
+
syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Use the raw, unprocessed data when writing to memory. The H3A and
@@ -1088,10 +1091,13 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
else
syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
- isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
+ if ((format->code == V4L2_MBUS_FMT_YUYV8_1X16) ||
+ (format->code == V4L2_MBUS_FMT_UYVY8_1X16))
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+ else
+ syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK;
- /* CCDC_PAD_SINK */
- format = &ccdc->formats[CCDC_PAD_SINK];
+ isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
/* Mosaic filter */
switch (format->code) {
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 04/10] omap3isp: Export isp_user.h to userspace as omap3isp.h
Signed-off-by: Sergio Aguirre
---
arch/arm/plat-omap/include/mach/isp_user.h | 636
drivers/media/video/isp/ispccdc.h |2 +-
drivers/media/video/isp/isph3a.h |2 +-
drivers/media/video/isp/isphist.h |2 +-
drivers/media/video/isp/isppreview.h |2 +-
drivers/media/video/isp/ispstat.h |2 +-
include/linux/Kbuild |1 +
include/linux/omap3isp.h | 636
8 files changed, 642 insertions(+), 641 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/mach/isp_user.h
create mode 100644 include/linux/omap3isp.h
diff --git a/arch/arm/plat-omap/include/mach/isp_user.h
b/arch/arm/plat-omap/include/mach/isp_user.h
deleted file mode 100644
index dd9ccf6..000
--- a/arch/arm/plat-omap/include/mach/isp_user.h
+++ /dev/null
@@ -1,636 +0,0 @@
-/*
- * isp_user.h
- *
- * TI OMAP3 ISP - User-space API
- *
- * Copyright (C) 2010 Nokia Corporation
- * Copyright (C) 2009 Texas Instruments, Inc.
- *
- * Contacts: Laurent Pinchart
- * Sakari Ailus
- *
- * 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.
- *
- * 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, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- */
-
-#ifndef OMAP3_ISP_USER_H
-#define OMAP3_ISP_USER_H
-
-#include
-
-/* ISP Private IOCTLs */
-#define VIDIOC_PRIVATE_ISP_CCDC_CFG\
- _IOWR('V', BASE_VIDIOC_PRIVATE + 1, struct ispccdc_update_config)
-#define VIDIOC_PRIVATE_ISP_PRV_CFG \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 2, struct ispprv_update_config)
-#define VIDIOC_PRIVATE_ISP_AEWB_CFG \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 3, struct isph3a_aewb_config)
-#define VIDIOC_PRIVATE_ISP_HIST_CFG \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 4, struct isphist_config)
-#define VIDIOC_PRIVATE_ISP_AF_CFG \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct isph3a_af_config)
-#define VIDIOC_PRIVATE_ISP_STAT_REQ \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct ispstat_data)
-#define VIDIOC_PRIVATE_ISP_STAT_EN \
- _IOWR('V', BASE_VIDIOC_PRIVATE + 7, unsigned long)
-
-/* Events */
-
-#define V4L2_EVENT_OMAP3ISP_CLASS (V4L2_EVENT_PRIVATE_START | 0x100)
-#define V4L2_EVENT_OMAP3ISP_AEWB (V4L2_EVENT_OMAP3ISP_CLASS | 0x1)
-#define V4L2_EVENT_OMAP3ISP_AF (V4L2_EVENT_OMAP3ISP_CLASS | 0x2)
-#define V4L2_EVENT_OMAP3ISP_HIST (V4L2_EVENT_OMAP3ISP_CLASS | 0x3)
-#define V4L2_EVENT_OMAP3ISP_HS_VS (V4L2_EVENT_OMAP3ISP_CLASS | 0x4)
-
-struct ispstat_event_status {
- __u32 frame_number;
- __u16 config_counter;
- __u8 buf_err;
-};
-
-/* AE/AWB related structures and flags*/
-
-/* Flags for update field */
-#define REQUEST_STATISTICS (1 << 0)
-#define SET_COLOR_GAINS(1 << 1)
-#define SET_DIGITAL_GAIN (1 << 2)
-#define SET_EXPOSURE (1 << 3)
-#define SET_ANALOG_GAIN(1 << 4)
-
-/* H3A Range Constants */
-#define AEWB_MAX_SATURATION_LIM1023
-#define AEWB_MIN_WIN_H 2
-#define AEWB_MAX_WIN_H 256
-#define AEWB_MIN_WIN_W 6
-#define AEWB_MAX_WIN_W 256
-#define AEWB_MIN_WINVC 1
-#define AEWB_MIN_WINHC 1
-#define AEWB_MAX_WINVC 128
-#define AEWB_MAX_WINHC 36
-#define AEWB_MAX_WINSTART 4095
-#define AEWB_MIN_SUB_INC 2
-#define AEWB_MAX_SUB_INC 32
-#define AEWB_MAX_BUF_SIZE 83600
-
-#define AF_IIRSH_MIN 0
-#define AF_IIRSH_MAX 4095
-#define AF_PAXEL_HORIZONTAL_COUNT_MIN 1
-#define AF_PAXEL_HORIZONTAL_COUNT_MAX 36
-#define AF_PAXEL_VERTICAL_COUNT_MIN1
-#define AF_PAXEL_VERTICAL_COUNT_MAX128
-#define AF_PAXEL_INCREMENT_MIN 2
-#define AF_PAXEL_INCREMENT_MAX 32
-#define AF_PAXEL_HEIGHT_MIN2
-#define AF_PAXEL_HEIGHT_MAX256
-#define AF_PAXEL_WIDTH_MIN 16
-#define AF_PAXEL_WIDTH_MAX 256
-#define AF_PAXEL_HZSTART_MIN 1
-#define AF_PAXEL_HZSTART_MAX 4095
-#define AF_PAXEL_VTSTART_MIN 0
-#define AF_PAXEL_VTSTART_MAX 4095
-#define AF_THRESHOLD_MAX 255
-#define AF_COEF_MAX4095
-#define AF_PAXEL_SIZE 48
-#define AF_MAX_BUF_SIZE221184
-
-/**
- * struct isph3a_aewb_config - AE AWB configuration reset values.
- * saturation_limit: Saturation limit.
- * @win_height: Window Height. Range 2 - 256, even values only.
[omap3isp RFC][PATCH 08/10] omap3isp: Cleanup isp_power_settings
1. Get rid of CSI2 / CCP2 power settings, as they are controlled
in the receivers code anyways.
2. Avoid code duplication.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/isp.c | 49 ++---
1 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c
index de9352b..30bdc48 100644
--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -254,48 +254,13 @@ EXPORT_SYMBOL(isp_set_xclk);
*/
static void isp_power_settings(struct isp_device *isp, int idle)
{
- if (idle) {
- isp_reg_writel(isp,
- (ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY <<
- ISP_SYSCONFIG_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
- if (omap_rev() == OMAP3430_REV_ES1_0) {
- isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
- (ISPCSI1_MIDLEMODE_SMARTSTANDBY <<
- ISPCSI1_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_CSI2A_REGS1,
- ISPCSI2_SYSCONFIG);
- isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
- (ISPCSI1_MIDLEMODE_SMARTSTANDBY <<
- ISPCSI1_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_CCP2,
- ISPCCP2_SYSCONFIG);
- }
- isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
- ISP_CTRL);
-
- } else {
- isp_reg_writel(isp,
- (ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY <<
- ISP_SYSCONFIG_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
- if (omap_rev() == OMAP3430_REV_ES1_0) {
- isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
- (ISPCSI1_MIDLEMODE_FORCESTANDBY <<
- ISPCSI1_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_CSI2A_REGS1,
- ISPCSI2_SYSCONFIG);
-
- isp_reg_writel(isp, ISPCSI1_AUTOIDLE |
- (ISPCSI1_MIDLEMODE_FORCESTANDBY <<
- ISPCSI1_MIDLEMODE_SHIFT),
- OMAP3_ISP_IOMEM_CCP2,
- ISPCCP2_SYSCONFIG);
- }
-
- isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
- ISP_CTRL);
- }
+ isp_reg_writel(isp,
+ ((idle ? ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY :
+ ISP_SYSCONFIG_MIDLEMODE_FORCESTANDBY) <<
+ ISP_SYSCONFIG_MIDLEMODE_SHIFT),
+ OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
+ isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
+ ISP_CTRL);
}
/*
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 01/10] omap3isp: ccdc: Add support for YUV format
We were just supporting RAW10 formats, and we really support more
options.
Strictly speaking, CCDC needs at least to distinguish between RAW
and YUV formats for proper configuration.
Signed-off-by: Sergio Aguirre
---
drivers/media/video/isp/ispccdc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index be4581e..bee2bbe 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -45,6 +45,8 @@ static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
V4L2_MBUS_FMT_SGBRG10_1X10,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_UYVY8_1X16,
};
/*
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 05/10] omap3: Remove unusued CBUFF resource
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c9fc732..897ce82 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -67,11 +67,6 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP3430_ISP_CBUFF_BASE,
- .end= OMAP3430_ISP_CBUFF_END,
- .flags = IORESOURCE_MEM,
- },
- {
.start = OMAP3430_ISP_CCP2_BASE,
.end= OMAP3430_ISP_CCP2_END,
.flags = IORESOURCE_MEM,
--
1.7.0.4
--
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
[omap3isp RFC][PATCH 09/10] omap3isp: ccp2: Make SYSCONFIG fields consistent
Signed-off-by: Sergio Aguirre --- drivers/media/video/isp/ispccp2.c |3 +-- drivers/media/video/isp/ispreg.h | 14 -- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/isp/ispccp2.c b/drivers/media/video/isp/ispccp2.c index fa23394..3127a74 100644 --- a/drivers/media/video/isp/ispccp2.c +++ b/drivers/media/video/isp/ispccp2.c @@ -419,8 +419,7 @@ static void ispccp2_mem_configure(struct isp_ccp2_device *ccp2, config->src_ofst = 0; } - isp_reg_writel(isp, (ISPCSI1_MIDLEMODE_SMARTSTANDBY << - ISPCSI1_MIDLEMODE_SHIFT), + isp_reg_writel(isp, ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_SYSCONFIG); /* Hsize, Skip */ diff --git a/drivers/media/video/isp/ispreg.h b/drivers/media/video/isp/ispreg.h index d885541..9b0d3ad 100644 --- a/drivers/media/video/isp/ispreg.h +++ b/drivers/media/video/isp/ispreg.h @@ -141,6 +141,14 @@ #define ISPCCP2_REVISION (0x000) #define ISPCCP2_SYSCONFIG (0x004) #define ISPCCP2_SYSCONFIG_SOFT_RESET (1 << 1) +#define ISPCCP2_SYSCONFIG_AUTO_IDLE0x1 +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT 12 +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_FORCE \ + (0x0 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT) +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_NO \ + (0x1 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT) +#define ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SMART \ + (0x2 << ISPCCP2_SYSCONFIG_MSTANDBY_MODE_SHIFT) #define ISPCCP2_SYSSTATUS (0x008) #define ISPCCP2_SYSSTATUS_RESET_DONE (1 << 0) #define ISPCCP2_LC01_IRQENABLE (0x00C) @@ -1309,12 +1317,6 @@ #define ISPMMU_SIDLEMODE_SMARTIDLE 2 #define ISPMMU_SIDLEMODE_SHIFT 3 -#define ISPCSI1_AUTOIDLE 0x1 -#define ISPCSI1_MIDLEMODE_SHIFT12 -#define ISPCSI1_MIDLEMODE_FORCESTANDBY 0x0 -#define ISPCSI1_MIDLEMODE_NOSTANDBY0x1 -#define ISPCSI1_MIDLEMODE_SMARTSTANDBY 0x2 - /* - * CSI2 receiver registers (ES2.0) */ -- 1.7.0.4 -- 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
[omap3isp RFC][PATCH 10/10] omap3isp: Remove legacy MMU access regs/fields
Signed-off-by: Sergio Aguirre --- drivers/media/video/isp/ispreg.h | 43 -- 1 files changed, 0 insertions(+), 43 deletions(-) diff --git a/drivers/media/video/isp/ispreg.h b/drivers/media/video/isp/ispreg.h index 9b0d3ad..af4ddaa 100644 --- a/drivers/media/video/isp/ispreg.h +++ b/drivers/media/video/isp/ispreg.h @@ -72,11 +72,6 @@ OMAP3ISP_SBL_REG_OFFSET) #define OMAP3ISP_SBL_REG(offset) (OMAP3ISP_SBL_REG_BASE + (offset)) -#define OMAP3ISP_MMU_REG_OFFSET0x1400 -#define OMAP3ISP_MMU_REG_BASE (OMAP3ISP_REG_BASE +\ -OMAP3ISP_MMU_REG_OFFSET) -#define OMAP3ISP_MMU_REG(offset) (OMAP3ISP_MMU_REG_BASE + (offset)) - #define OMAP3ISP_CSI2A_REGS1_REG_OFFSET0x1800 #define OMAP3ISP_CSI2A_REGS1_REG_BASE (OMAP3ISP_REG_BASE +\ OMAP3ISP_CSI2A_REGS1_REG_OFFSET) @@ -458,26 +453,6 @@ #define ISPRSZ_VFILT3130 (0x0A4) #define ISPRSZ_YENH(0x0A8) -/* MMU module registers */ -#define ISPMMU_REVISION(0x000) -#define ISPMMU_SYSCONFIG (0x010) -#define ISPMMU_SYSSTATUS (0x014) -#define ISPMMU_IRQSTATUS (0x018) -#define ISPMMU_IRQENABLE (0x01C) -#define ISPMMU_WALKING_ST (0x040) -#define ISPMMU_CNTL(0x044) -#define ISPMMU_FAULT_AD(0x048) -#define ISPMMU_TTB (0x04C) -#define ISPMMU_LOCK(0x050) -#define ISPMMU_LD_TLB (0x054) -#define ISPMMU_CAM (0x058) -#define ISPMMU_RAM (0x05C) -#define ISPMMU_GFLUSH (0x060) -#define ISPMMU_FLUSH_ENTRY (0x064) -#define ISPMMU_READ_CAM(0x068) -#define ISPMMU_READ_RAM(0x06c) -#define ISPMMU_EMU_FAULT_AD(0x070) - #define ISP_INT_CLR0xFF113F11 #define ISPPRV_PCR_EN 1 #define ISPPRV_PCR_BUSY(1 << 1) @@ -1299,24 +1274,6 @@ #define ISPCCDC_LSC_INITIAL_Y_MASK 0x3F #define ISPCCDC_LSC_INITIAL_Y_SHIFT16 -#define ISPMMU_REVISION_REV_MINOR_MASK 0xF -#define ISPMMU_REVISION_REV_MAJOR_SHIFT0x4 - -#define IRQENABLE_MULTIHITFAULT(1<<4) -#define IRQENABLE_TWFAULT (1<<3) -#define IRQENABLE_EMUMISS (1<<2) -#define IRQENABLE_TRANSLNFAULT (1<<1) -#define IRQENABLE_TLBMISS (1) - -#define ISPMMU_MMUCNTL_MMU_EN (1<<1) -#define ISPMMU_MMUCNTL_TWL_EN (1<<2) -#define ISPMMU_MMUCNTL_EMUTLBUPDATE(1<<3) -#define ISPMMU_AUTOIDLE0x1 -#define ISPMMU_SIDLEMODE_FORCEIDLE 0 -#define ISPMMU_SIDLEMODE_NOIDLE1 -#define ISPMMU_SIDLEMODE_SMARTIDLE 2 -#define ISPMMU_SIDLEMODE_SHIFT 3 - /* - * CSI2 receiver registers (ES2.0) */ -- 1.7.0.4 -- 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
[omap3isp RFC][PATCH 00/10] YUV support for CCDC + cleanups
Hi, First of all, these patches are based on Laurent's tree: URL: git://linuxtv.org/pinchartl/media.git Branch: media-0004-omap3isp (Commit d0c5b0e4: OMAP3 ISP driver) I had these patches in my queue for some time, which: - Add YUV support to CCDC - Cleans up platform device MEM resources - Removes some unused/legacy defines - IMPORTANT: Moves/Renames isp_user.h to include/linux/omap3isp.h I'm working on some more changes to keep register access per component a bit cleaner. But that will be sent separately in another RFC patchlist. Please share your review comments. Regards, Sergio Sergio Aguirre (10): omap3isp: ccdc: Add support for YUV format omap3isp: ccdc: Write SYN_MODE.INPMOD based on fmt omap3: Fix camera resources for multiomap omap3isp: Export isp_user.h to userspace as omap3isp.h omap3: Remove unusued CBUFF resource omap3isp: Remove unused CBUFF register access omap3isp: Remove CSIA/B register abstraction omap3isp: Cleanup isp_power_settings omap3isp: ccp2: Make SYSCONFIG fields consistent omap3isp: Remove legacy MMU access regs/fields arch/arm/mach-omap2/devices.c | 32 +- arch/arm/plat-omap/include/mach/isp_user.h | 636 drivers/media/video/isp/isp.c | 51 +-- drivers/media/video/isp/isp.h |1 - drivers/media/video/isp/ispccdc.c | 14 +- drivers/media/video/isp/ispccdc.h |2 +- drivers/media/video/isp/ispccp2.c |5 +- drivers/media/video/isp/isph3a.h |2 +- drivers/media/video/isp/isphist.h |2 +- drivers/media/video/isp/isppreview.h |2 +- drivers/media/video/isp/ispreg.h | 85 + drivers/media/video/isp/ispstat.h |2 +- include/linux/Kbuild |1 + include/linux/omap3isp.h | 636 14 files changed, 682 insertions(+), 789 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/isp_user.h create mode 100644 include/linux/omap3isp.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: Raw mode for SAA7134_BOARD_ENCORE_ENLTV_FM53?
On Fri, Nov 12, 2010 at 12:23:56PM -0200, Mauro Carvalho Chehab wrote: >Em 12-11-2010 12:14, David Härdeman escreveu: >> Mauro, >> >> as far as I could tell, you wrote the initial support for >> SAA7134_BOARD_ENCORE_ENLTV_FM53 in >> drivers/media/video/saa7134/saa7134-input.c, right? >> >> It appears to be the only user of ir-functions.c left in that driver and >> I'm wondering if it could be converted to use raw_decode with a patch >> similar to what you committed for SAA7134_BOARD_ASUSTeK_P7131_ANALOG? >> >I need to check if I still have this board, or if it were a board that >someone borrowed me. > >I'll put it on my todo list. Since that list is probably quite long, anyone else who reads this and who has an Encore ENLTV-FM v5.3, feel free to get in touch with me in the meantime. -- David Härdeman -- 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/2] [media] ir-kbd-i2c: add rc_dev as a parameter to the driver
On Fri, Nov 12, 2010 at 11:28:38AM -0200, Mauro Carvalho Chehab wrote: >There are several fields on rc_dev that drivers can benefit. Allow drivers >to pass it as a parameter to the driver. > >For now, the rc_dev parameter is optional. If drivers don't pass it, create >them internally. However, the best is to create rc_dev inside the drivers, >in order to fill other fields, like open(), close(), driver_name, etc. >So, a latter patch making it mandatory and changing the caller drivers is >welcome. Looks good, no objections. Sorry for misinterpreting your suggested change. -- David Härdeman -- 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
issues with af9015
Hi, I have same issue with two different af9015 cards made by 2 different manufacturers with 2 different frontends. When card is used with tvheadend software which constantly does idle scanning, after 1-2 days it starts showing following dmesgs: [342924.332308] tda18218: i2c wr failed ret:-1 reg:1a len:3 [342925.152277] af9015: command failed:1 [342925.152293] tda18218: i2c wr failed ret:-1 reg:1a len:3 [342925.973596] af9015: command failed:1 [342925.973610] tda18218: i2c wr failed ret:-1 reg:1a len:3 Only way to recover it from this state is unplugging. Rebooting doesn't help as card stays powered during reboot. Any idea what can cause this? Can I do any further debugging steps? Thanks, damjan -- 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: 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:Fri Nov 12 19:00:11 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] MCDE: Add frame buffer device driver
On Fri, Nov 12, 2010 at 11:46 AM, Marcus LORENTZON wrote: > Hi Alex, > Do you have any idea of how we should use KMS without being a "real" drm 3D > device? Do you mean that we should use the KMS ioctls on for display driver? > Or do you mean that we should expose a /dev/drmX device only capable of KMS > and no GEM? > In this case I was only speaking of using the kms icotls and fbdev emulation for modesetting as your device seems to have a fairly complex display engine. As for 2D/3D/video accel, that's up to you. Each drm driver does it differently depending on how they handle command buffers. Intel and AMD have different sets of ioctls for submitting 2D/3D/video commands from userspace acceleration drivers and a different set of ioctls for memory management. > What if we were to add a drm driver for 3D later on. Is it possible to have a > separate drm device for display and one for 3D, but still share "GEM" like > buffers between these devices? It look like GEM handles are device relative. > This is a vital use case for us. And we really don't like to entangle our > MCDE display driver, memory manager and 3D driver without a good reason. > Today they are maintained as independent drivers without code dependencies. > Would this still be possible using drm? Or does drm require memory manager, > 3D and display to be one driver? I can see the drm=graphics card on desktop > machines. But embedded UMA systems doesn't really have this dependency. You > can switch memory mamanger, 3D driver, display manager in menuconfig > independently of the other drivers. Not that it's used like that on one > particular HW, but for different HW you can use different parts. In drm it > looks like all these pieces belong together. > No one has done anything like that, but I don't think it would be an issue, you'd just need some sort of way to get buffers in your display driver or your 3D driver, so I'd assume they would depend on your memory manager. Right now the userspace 2D/3D accel drivers all talk to the drm independently depending on what they need to do. Whatever your userspace stack looks like could do something similar, call into one set of ioctls for memory, another set for modesetting, and another for accel. As long as the kernel memory manager is common, you should be able to pass buffer handles between all of them. If you wanted separate memory managers for each, things get a bit trickier, but that's up to you. > Do you think the driver should live in the "gpu/drm" folder, even though it's > not a gpu driver? > gpu is kind of a broad term. It encompasses, 3D, display, video, etc. I don't think it really matters. > Do you know of any other driver that use DRM/KMS API but not being a PC-style > graphics card that we could look at for inspiration? Jordan Crouse submitted some patches for Qualcomm snapdragon a while back although it was mostly a shim for a userspace accel driver. He did implement platform support in the drm however: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=dcdb167402cbdca1d021bdfa5f63995ee0a79317 > > And GEM, is that the only way of exposing graphics buffers to user space in > drm? Or is it possible (is it ok) to expose another similar API? You > mentioned that there are TTM and GEM, do both expose user space APIs for > things like sharing buffers between processes, security, cache management, > defragmentation? Or are these type of features defined by DRM and not TTM/GEM? > GEM is not a requirement, it just happens that all the current drm drivers use variants of it for their external memory management interface. However, they are free to implement the memory manager however they like. Alex > /BR > /Marcus > >> -Original Message- >> From: Alex Deucher [mailto:alexdeuc...@gmail.com] >> Sent: den 12 november 2010 16:53 >> To: Jimmy RUBIN >> Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >> linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON; Marcus >> LORENTZON >> Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver >> >> On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN >> wrote: >> > Hi Alex, >> > >> > Good point, we are looking at this for possible future improvements >> but for the moment we feel like >> > the structure of drm does not add any simplifications for our driver. >> We have the display manager (MCDE DSS = KMS) and the memory manager >> (HWMEM = GEM) that could be migrated to drm framework. But we do not >> have drm drivers for 3D hw and this also makes drm a less obvious >> choice at the moment. >> > >> >> You don't have to use the drm strictly for 3D hardware. historically >> that's why it was written, but with kms, it also provides an interface >> for complex display systems. fbdev doesn't really deal properly with >> multiple display controllers or connectors that are dynamically >> re-routeable at runtime. I've seen a lot of gross hacks to fbdev to >> support this
Re: Leadtek WinFast PxPVR2200
I think I found the firmware. http://rapidshare.com/files/430422366/fw64.zip -- 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: mediabus enums
Hi Manjunath, On Friday 12 November 2010 17:00:36 Hadli, Manjunath wrote: > On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote: > > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote: > > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote: > > > > Hello Guennadi, > > > > > > > >Your media-bus enumerations capture the formats quite well. I > > > > > > > > needed > > > > > > > > the following for support on Davinci SOCs and liked to check with > > > > you if these are covered in some format in the list. > > > > 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 > > > > lines) (16 data lines + 4 or 5 sync lines) > > > > > > According to the subdev-formats.xml > > > > > > http://git.linuxtv.org/pinchartl/media.git?a=blob;f=Documentation/DocB > > > ook/v > > > 4l/subdev-formats.xml;h=3688f27185f72ab109e3094c268e04f67cb8643e;hb=re > > > fs/he > > > ads/media-0003-subdev-pad > > > > > > they should be called V4L2_MBUS_FMT_RGB666_1X18 (or BGR666...) > > > > Agreed. > > > > > and V4L2_MBUS_FMT_YUYV16_1X16. > > > > Depending on what Manjunath meant, this should be either YUYV16_2X16 or > > > > YUYV8_1X16. 16 bits per sample seems quite high to me, I suppose it > > should > then be YUYV8_1X16. > > Actually, the interface transfers 16 bits per sample (Y=8bits and C=8bits) > For the YC16 and 18 data lines (parallel) for RGB666. probably > V4L2_MBUS_FMT_RGB666_1X18 and V4L2_MBUS_FMT_YUYV16_1X16 fit the bill. V4L2_MBUS_FMT_RGB666_1X18 is correct, but for YUYV I think it should be V4L2_MBUS_FMT_YUYV8_1X16. You can find a detailed description of the format at http://www.ideasonboard.org/media/media/subdev.html#V4L2-MBUS-FMT-YUYV8-1X16 -- Regards, Laurent Pinchart -- 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 00/10] MCDE: Add frame buffer device driver
Hi Alex, Do you have any idea of how we should use KMS without being a "real" drm 3D device? Do you mean that we should use the KMS ioctls on for display driver? Or do you mean that we should expose a /dev/drmX device only capable of KMS and no GEM? What if we were to add a drm driver for 3D later on. Is it possible to have a separate drm device for display and one for 3D, but still share "GEM" like buffers between these devices? It look like GEM handles are device relative. This is a vital use case for us. And we really don't like to entangle our MCDE display driver, memory manager and 3D driver without a good reason. Today they are maintained as independent drivers without code dependencies. Would this still be possible using drm? Or does drm require memory manager, 3D and display to be one driver? I can see the drm=graphics card on desktop machines. But embedded UMA systems doesn't really have this dependency. You can switch memory mamanger, 3D driver, display manager in menuconfig independently of the other drivers. Not that it's used like that on one particular HW, but for different HW you can use different parts. In drm it looks like all these pieces belong together. Do you think the driver should live in the "gpu/drm" folder, even though it's not a gpu driver? Do you know of any other driver that use DRM/KMS API but not being a PC-style graphics card that we could look at for inspiration? And GEM, is that the only way of exposing graphics buffers to user space in drm? Or is it possible (is it ok) to expose another similar API? You mentioned that there are TTM and GEM, do both expose user space APIs for things like sharing buffers between processes, security, cache management, defragmentation? Or are these type of features defined by DRM and not TTM/GEM? /BR /Marcus > -Original Message- > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > Sent: den 12 november 2010 16:53 > To: Jimmy RUBIN > Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON; Marcus > LORENTZON > Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver > > On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN > wrote: > > Hi Alex, > > > > Good point, we are looking at this for possible future improvements > but for the moment we feel like > > the structure of drm does not add any simplifications for our driver. > We have the display manager (MCDE DSS = KMS) and the memory manager > (HWMEM = GEM) that could be migrated to drm framework. But we do not > have drm drivers for 3D hw and this also makes drm a less obvious > choice at the moment. > > > > You don't have to use the drm strictly for 3D hardware. historically > that's why it was written, but with kms, it also provides an interface > for complex display systems. fbdev doesn't really deal properly with > multiple display controllers or connectors that are dynamically > re-routeable at runtime. I've seen a lot of gross hacks to fbdev to > support this kind of stuff in the past, so it'd be nice to use the > interface we now have for it if you need that functionality. > Additionally, you can use the shared memory manager to both the > display side and v4l side. While the current drm drivers use GEM > externally, there's no requirement that a kms driver has to use GEM. > radeon and nouveau use ttm internally for example. Something to > consider. I just want to make sure people are aware of the interface > and what it's capable of. > > Alex > > > Jimmy > > > > -Original Message- > > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > > Sent: den 10 november 2010 15:43 > > To: Jimmy RUBIN > > Cc: linux-fb...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-media@vger.kernel.org; Linus WALLEIJ; > Dan JOHANSSON > > Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver > > > > On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin > wrote: > >> These set of patches contains a display sub system framework (DSS) > which is used to > >> implement the frame buffer device interface and a display device > >> framework that is used to add support for different type of displays > >> such as LCD, HDMI and so on. > > > > For complex display hardware, you may want to consider using the drm > > kms infrastructure rather than the kernel fb interface. It provides > > an API for complex display hardware (multiple encoders, display > > controllers, etc.) and also provides a legacy kernel fb interface for > > compatibility. See: > > Documentation/DocBook/drm.tmpl > > drivers/gpu/drm/ > > in the kernel tree. > > > > Alex > > > >> > >> The current implementation supports DSI command mode displays. > >> > >> Below is a short summary of the files in this patchset: > >> > >> mcde_fb.c > >> Implements the frame buffer device driver. > >> > >> mcde_dss.c > >> Contains the implementation of the display sub system framework > (DSS). > >> This API is used by the frame
Re: [PATCH 07/10] MCDE: Add display subsystem framework
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for the MCDE, Memory-to-display controller,
> found in the ST-Ericsson ux500 products.
>
> This patch adds a display subsystem framework that can be used
> by a frame buffer device driver to control a display and MCDE.
Like "hardware abstraction layer", "framework" is another term that
we do not like to hear. We write drivers that drive specific hardware,
so better name it after the exact part of the chip that it is driving.
Other terms to avoid include "middleware", "generic subsystem" and
"wrapper".
> +struct kobj_type ovly_type = {
> + .release = overlay_release,
> +};
You certainly should not define a new kobj_type for use in a device driver.
This is an internal data structure of the linux core code. It might make
sense if you were trying to become the new frame buffer layer maintainer
and rewrite all the existing drivers to be based on the concept of
overlays, but even then there is probably a better way.
Maybe you were thinking of using kref instead of kobj?
> +int __init mcde_dss_init(void)
> +{
> + return 0;
> +}
> +
> +void mcde_dss_exit(void)
> +{
> +}
If they don't do anything, don't define them.
Arnd
--
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 08/10] MCDE: Add frame buffer device
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> +
> +static struct platform_device mcde_fb_device = {
> + .name = "mcde_fb",
> + .id = -1,
> +};
Do not introduce new static devices. We are trying to remove them and
they will stop working. Why do you even need a device here if there is
only one of them?
> +struct fb_info *mcde_fb_create(struct mcde_display_device *ddev,
> + u16 w, u16 h, u16 vw, u16 vh, enum mcde_ovly_pix_fmt pix_fmt,
> + u32 rotate)
> +{
Here you have another device, which you could just use!
> +/* Overlay fbs' platform device */
> +static int mcde_fb_probe(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static int mcde_fb_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +
> +static struct platform_driver mcde_fb_driver = {
> + .probe = mcde_fb_probe,
> + .remove = mcde_fb_remove,
> + .driver = {
> + .name = "mcde_fb",
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +/* MCDE fb init */
> +
> +int __init mcde_fb_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&mcde_fb_driver);
> + if (ret)
> + goto fb_driver_failed;
> + ret = platform_device_register(&mcde_fb_device);
> + if (ret)
> + goto fb_device_failed;
> +
> + goto out;
> +fb_device_failed:
> + platform_driver_unregister(&mcde_fb_driver);
> +fb_driver_failed:
> +out:
> + return ret;
> +}
> +
> +void mcde_fb_exit(void)
> +{
> + platform_device_unregister(&mcde_fb_device);
> + platform_driver_unregister(&mcde_fb_driver);
> +}
This appears to be an entirely useless registration for something that
does not exist and that you are not using anywhere ...
> +
> +#include
> +#include
> +#if !defined(__KERNEL__) && !defined(_KERNEL)
> +#include
> +#else
> +#include
> +#endif
> +
> +#ifdef __KERNEL__
> +#include "mcde_dss.h"
> +#endif
> +
> +#ifdef __KERNEL__
> +#define to_mcde_fb(x) ((struct mcde_fb *)(x)->par)
Everything in this file is enclosed in #ifdef __KERNEL__, and the file
is not even exported. You can remove the #ifdef and the #else path
everywhere AFAICT.
Arnd
--
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 09/10] MCDE: Add build files and bus
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for the MCDE, Memory-to-display controller,
> found in the ST-Ericsson ux500 products.
>
> This patch adds the necessary build files for MCDE and the bus that
> all displays are connected to.
>
Can you explain why you need a bus for this?
With the code you currently have, there is only a single driver associated
with this bus type, and also just a single device that gets registered here!
>+static int __init mcde_subsystem_init(void)
>+{
>+ int ret;
>+ pr_info("MCDE subsystem init begin\n");
>+
>+ /* MCDE module init sequence */
>+ ret = mcde_init();
>+ if (ret)
>+ return ret;
>+ ret = mcde_display_init();
>+ if (ret)
>+ goto mcde_display_failed;
>+ ret = mcde_dss_init();
>+ if (ret)
>+ goto mcde_dss_failed;
>+ ret = mcde_fb_init();
>+ if (ret)
>+ goto mcde_fb_failed;
>+ pr_info("MCDE subsystem init done\n");
>+
>+ return 0;
>+mcde_fb_failed:
>+ mcde_dss_exit();
>+mcde_dss_failed:
>+ mcde_display_exit();
>+mcde_display_failed:
>+ mcde_exit();
>+ return ret;
>+}
Splitting up the module into four sub-modules and then initializing
everything from one place indicates that something is done wrong
on a global scale.
If you indeed need a bus, that should be a separate module that gets
loaded first and then has the other modules build on top of.
I'm not sure how the other parts layer on top of one another, can you
provide some more insight?
>From what I understood so far, you have a single multi-channel display
controller (mcde_hw.c) that drives the hardware.
Each controller can have multiple frame buffers attached to it, which
in turn can have multiple displays attached to each of them, but your
current configuration only has one of each, right?
Right now you have a single top-level bus device for the displays,
maybe that can be integrated into the controller so the displays are
properly rooted below the hardware that drives them.
The frame buffer device also looks weird. Right now you only seem
to have a single frame buffer registered to a driver in the same
module. Is that frame buffer not dependent on a controller?
>+#ifdef MODULE
>+module_init(mcde_subsystem_init);
>+#else
>+fs_initcall(mcde_subsystem_init);
>+#endif
This is not a file system ;-)
Arnd
--
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: mediabus enums
On Fri, 12 Nov 2010, Hadli, Manjunath wrote: > On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote: > > Hi Guennadi, > > > > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote: > > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote: > > > > Hello Guennadi, > > > > > > > >Your media-bus enumerations capture the formats quite well. I > > > > needed > > > > > > > > the following for support on Davinci SOCs and liked to check with > > > > you if these are covered in some format in the list. > > > > 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 > > > > lines) (16 data lines + 4 or 5 sync lines) > > > > > > According to the subdev-formats.xml > > > > > > http://git.linuxtv.org/pinchartl/media.git?a=blob;f=Documentation/DocB > > > ook/v > > > 4l/subdev-formats.xml;h=3688f27185f72ab109e3094c268e04f67cb8643e;hb=re > > > fs/he > > > ads/media-0003-subdev-pad > > > > > > they should be called V4L2_MBUS_FMT_RGB666_1X18 (or BGR666...) > > > > Agreed. > > > > > and V4L2_MBUS_FMT_YUYV16_1X16. > > > > Depending on what Manjunath meant, this should be either YUYV16_2X16 or > > YUYV8_1X16. 16 bits per sample seems quite high to me, I suppose it should > > then be YUYV8_1X16. > > Actually, the interface transfers 16 bits per sample (Y=8bits and C=8bits) > For the YC16 and 18 data lines (parallel) for RGB666. probably > V4L2_MBUS_FMT_RGB666_1X18 and V4L2_MBUS_FMT_YUYV16_1X16 fit the bill. No, I think, Laurent was right. If that your 1 16-bit sample also corresponds to one pixel, then it's a normal 16-bit YUYV, i.e., V4L2_MBUS_FMT_YUYV8_1X16. In the aforementioned document the number after "YUYV" is "The number of bits per pixel component," where the "component" is either the luminance, or the chrominance, both of which are 8 bit wide. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 10/10] ux500: MCDE: Add platform specific data
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> +
> + if (ddev->id == PRIMARY_DISPLAY_ID && rotate_main) {
> + swap(width, height);
> +#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_ROTATE_180_DEGREES
> + rotate = FB_ROTATE_CCW;
> +#else
> + rotate = FB_ROTATE_CW;
> +#endif
> + }
> +
> + virtual_width = width;
> + virtual_height = height * 2;
> +#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC
> + if (ddev->id == PRIMARY_DISPLAY_ID)
> + virtual_height = height;
> +#endif
> +
The contents of the hardware description should really not
be configuration dependent, because that breaks booting the same
kernel on machines that have different requirements.
This is something that should be passed down from the boot loader.
> +static void mcde_epod_enable(void)
> +{
> + /* Power on DSS mem */
> + writel(PRCMU_ENABLE_DSS_MEM, PRCM_EPOD_C_SET);
> + mdelay(PRCMU_MCDE_DELAY);
> + /* Power on DSS logic */
> + writel(PRCMU_ENABLE_DSS_LOGIC, PRCM_EPOD_C_SET);
> + mdelay(PRCMU_MCDE_DELAY);
> +}
In general, try to avoid using mdelay. Keeping the CPU busy for miliseconds
or even microseconds for no reason is just wrong.
Reasonable hardware will not require this and do the right thing anyway.
multiple writel calls are by design strictly ordered on the bus. If that is
not the case on your hardware, you should find a proper way to ensure
ordering and create a small wrapper for it with a comment that explains
the breakage. Better get the hardware designers to fix their crap before
releasing a product ;-)
If there is not even a way to reorder I/O by accessing other registers,
use msleep() to let the CPU do something useful in the meantime and complain
even more to the HW people.
Arnd
--
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: mediabus enums
On Thu, Nov 11, 2010 at 22:17:23, Laurent Pinchart wrote: > Hi Guennadi, > > On Thursday 11 November 2010 16:32:02 Guennadi Liakhovetski wrote: > > On Wed, 10 Nov 2010, Hadli, Manjunath wrote: > > > Hello Guennadi, > > > > > >Your media-bus enumerations capture the formats quite well. I > > > needed > > > > > > the following for support on Davinci SOCs and liked to check with > > > you if these are covered in some format in the list. > > > 1. Parallel RGB 666 (18 data lines+ 5 sync lines) 2. YUYV16 (16 > > > lines) (16 data lines + 4 or 5 sync lines) > > > > According to the subdev-formats.xml > > > > http://git.linuxtv.org/pinchartl/media.git?a=blob;f=Documentation/DocB > > ook/v > > 4l/subdev-formats.xml;h=3688f27185f72ab109e3094c268e04f67cb8643e;hb=re > > fs/he > > ads/media-0003-subdev-pad > > > > they should be called V4L2_MBUS_FMT_RGB666_1X18 (or BGR666...) > > Agreed. > > > and V4L2_MBUS_FMT_YUYV16_1X16. > > Depending on what Manjunath meant, this should be either YUYV16_2X16 or > > > YUYV8_1X16. 16 bits per sample seems quite high to me, I suppose it should > > then be YUYV8_1X16. Actually, the interface transfers 16 bits per sample (Y=8bits and C=8bits) For the YC16 and 18 data lines (parallel) for RGB666. probably V4L2_MBUS_FMT_RGB666_1X18 and V4L2_MBUS_FMT_YUYV16_1X16 fit the bill. > > > Notice, that these codes do not define the complete bus topology, > > e.g., they say nothing about sync signals. This is a separate topic. > > -- > Regards, > > Laurent Pinchart > -- 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 00/10] MCDE: Add frame buffer device driver
On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN wrote: > Hi Alex, > > Good point, we are looking at this for possible future improvements but for > the moment we feel like > the structure of drm does not add any simplifications for our driver. We have > the display manager (MCDE DSS = KMS) and the memory manager (HWMEM = GEM) > that could be migrated to drm framework. But we do not have drm drivers for > 3D hw and this also makes drm a less obvious choice at the moment. > You don't have to use the drm strictly for 3D hardware. historically that's why it was written, but with kms, it also provides an interface for complex display systems. fbdev doesn't really deal properly with multiple display controllers or connectors that are dynamically re-routeable at runtime. I've seen a lot of gross hacks to fbdev to support this kind of stuff in the past, so it'd be nice to use the interface we now have for it if you need that functionality. Additionally, you can use the shared memory manager to both the display side and v4l side. While the current drm drivers use GEM externally, there's no requirement that a kms driver has to use GEM. radeon and nouveau use ttm internally for example. Something to consider. I just want to make sure people are aware of the interface and what it's capable of. Alex > Jimmy > > -Original Message- > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > Sent: den 10 november 2010 15:43 > To: Jimmy RUBIN > Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON > Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver > > On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin > wrote: >> These set of patches contains a display sub system framework (DSS) which is >> used to >> implement the frame buffer device interface and a display device >> framework that is used to add support for different type of displays >> such as LCD, HDMI and so on. > > For complex display hardware, you may want to consider using the drm > kms infrastructure rather than the kernel fb interface. It provides > an API for complex display hardware (multiple encoders, display > controllers, etc.) and also provides a legacy kernel fb interface for > compatibility. See: > Documentation/DocBook/drm.tmpl > drivers/gpu/drm/ > in the kernel tree. > > Alex > >> >> The current implementation supports DSI command mode displays. >> >> Below is a short summary of the files in this patchset: >> >> mcde_fb.c >> Implements the frame buffer device driver. >> >> mcde_dss.c >> Contains the implementation of the display sub system framework (DSS). >> This API is used by the frame buffer device driver. >> >> mcde_display.c >> Contains default implementations of the functions in the display driver >> API. A display driver may override the necessary functions to function >> properly. A simple display driver is implemented in display-generic_dsi.c. >> >> display-generic_dsi.c >> Sample driver for a DSI command mode display. >> >> mcde_bus.c >> Implementation of the display bus. A display device is probed when both >> the display driver and display configuration have been registered with >> the display bus. >> >> mcde_hw.c >> Hardware abstraction layer of MCDE. All code that communicates directly >> with the hardware resides in this file. >> >> board-mop500-mcde.c >> The configuration of the display and the frame buffer device is handled >> in this file >> >> NOTE: These set of patches replaces the patches already sent out for review. >> >> RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver >> RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver >> >> The old patchset was to large to be handled by the mailing lists. >> >> Jimmy Rubin (10): >> MCDE: Add hardware abstraction layer >> MCDE: Add configuration registers >> MCDE: Add pixel processing registers >> MCDE: Add formatter registers >> MCDE: Add dsi link registers >> MCDE: Add generic display >> MCDE: Add display subsystem framework >> MCDE: Add frame buffer device driver >> MCDE: Add build files and bus >> ux500: MCDE: Add platform specific data >> >> arch/arm/mach-ux500/Kconfig | 8 + >> arch/arm/mach-ux500/Makefile | 1 + >> arch/arm/mach-ux500/board-mop500-mcde.c | 209 ++ >> arch/arm/mach-ux500/board-mop500-regulators.c | 28 + >> arch/arm/mach-ux500/board-mop500.c | 3 + >> arch/arm/mach-ux500/devices-db8500.c | 68 + >> arch/arm/mach-ux500/include/mach/db8500-regs.h | 7 + >> arch/arm/mach-ux500/include/mach/devices.h | 1 + >> arch/arm/mach-ux500/include/mach/prcmu-regs.h | 1 + >> arch/arm/mach-ux500/include/mach/prcmu.h | 3 + >> arch/arm/mach-ux500/prcmu.c | 129 ++ >> drivers/video/Kconfig | 2 + >> drivers/video/Makefile | 1 + >> drivers/video/mcde/Kconfig
Re: [PATCH 03/10] MCDE: Add pixel processing registers
On Wednesday 10 November 2010, Jimmy Rubin wrote: > This patch adds support for MCDE, Memory-to-display controller > found in the ST-Ericsson ux500 products. > > This patch adds pixel processing registers found in MCDE. > > Signed-off-by: Jimmy Rubin > Acked-by: Linus Walleij The same comments I gave for the configuration registers apply to this one and the other headers as well. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
is useful to you.
> This patch adds the hardware abstraction layer.
> All calls to the hardware is handled in mcde_hw.c
A "hardware abstraction layer" is generally considered a bad thing,
you're usually better off not advertising your code as being one.
As a rule, the device driver *is* the hardware abstraction, so you
should not add another one ;-)
> +static void disable_channel(struct mcde_chnl_state *chnl);
> +static void enable_channel(struct mcde_chnl_state *chnl);
> +static void watchdog_auto_sync_timer_function(unsigned long arg);
I generally recomment avoiding forward declarations of static functions.
Just reorder the code so you don't need them.
> +u8 *mcdeio;
> +u8 **dsiio;
> +DEFINE_SPINLOCK(mcde_lock); /* REVIEW: Remove or use */
> +struct platform_device *mcde_dev;
> +u8 num_dsilinks;
You should try hard to avoid global variables in a well-designed driver.
There are many ways around them, like accessor functions or splitting the
driver into files in a more logical way where each file only accesses
its own data. If you really cannot think of a way to avoid these,
put them in a proper name space in the way that you have done for the
global functions, by prefixing each identifier with "mcde_".
> +static u8 hardware_version;
> +
> +static struct regulator *regulator;
> +static struct clk *clock_dsi;
> +static struct clk *clock_mcde;
> +static struct clk *clock_dsi_lp;
> +static u8 mcde_is_enabled;
Even static variables like these can cause problems. Ideally all of these
are referenced through a driver private data structure that is passed around
with the device. This way you can trivially support multiple devices if
that ever becomes necessary.
> +static inline u32 dsi_rreg(int i, u32 reg)
> +{
> + return readl(dsiio[i] + reg);
> +}
> +static inline void dsi_wreg(int i, u32 reg, u32 val)
> +{
> + writel(val, dsiio[i] + reg);
> +}
dsiio is not marked __iomem, so there is something wrong here.
Moreover, why do you need two indexes? If you have multiple identical
"dsiio" structures, maybe each of them should just be a device by itself?
> +struct mcde_ovly_state {
> + bool inuse;
> + u8 idx; /* MCDE overlay index */
> + struct mcde_chnl_state *chnl; /* Owner channel */
> + u32 transactionid; /* Apply time stamp */
> + u32 transactionid_regs; /* Register update time stamp */
> + u32 transactionid_hw; /* HW completed time stamp */
> + wait_queue_head_t waitq_hw; /* Waitq for transactionid_hw */
> +
> + /* Staged settings */
> + u32 paddr;
> + u16 stride;
> + enum mcde_ovly_pix_fmt pix_fmt;
> +
> + u16 src_x;
> + u16 src_y;
> + u16 dst_x;
> + u16 dst_y;
> + u16 dst_z;
> + u16 w;
> + u16 h;
> +
> + /* Applied settings */
> + struct ovly_regs regs;
> +};
There should probably be a "struct device" pointer in this, so you can pass
it around as a real object.
> + /* Handle channel irqs */
> + irq_status = mcde_rreg(MCDE_RISPP);
> + if (irq_status & MCDE_RISPP_VCMPARIS_MASK) {
> + chnl = &channels[MCDE_CHNL_A];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPBRIS_MASK) {
> + chnl = &channels[MCDE_CHNL_B];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPC0RIS_MASK) {
> + chnl = &channels[MCDE_CHNL_C0];
> ...
> + }
This looks a bit like you actually have multiple interrupt lines multiplexed
through a private interrupt controller. Have you considered making this
controller
a separate device to multiplex the interrupt numbers?
> +void wait_for_overlay(struct mcde_ovly_state *ovly)
Not an appropriate name for a global function. Either make this static or
call it mcde_wait_for_overlay. Same for some other functions.
> +#ifdef CONFIG_AV8100_SDTV
> + /* TODO: check if these watermark levels work for HDMI as well. */
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_SMALL_WTRMRKLVL;
> +#else
> + if ((fifo == MCDE_FIFO_A || fifo == MCDE_FIFO_B) &&
> + regs->ppl >= fifo_size * 2)
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_LARGE_WTRMRKLVL;
> + else
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_MEDIUM_WTRMRKLVL;
> +#endif /* CONFIG_AV8100_SDTV */
Be careful with config options like this. If you want to build a kernel
to run on all machines, the first part probably needs to check where it
is running and consider the other pixelfetchwtrmrklevel values as well.
> +/* Channel path */
> +#define MCDE_CHNLPATH(__chnl, __fifo, __type, __ifc, __link) \
> + (((__chnl) << 16) | ((__fifo) << 12) | \
> + ((__type) << 8) | ((__ifc) << 4) | ((__link) << 0))
> +enum mcde_chnl_path {
> + /* Chann
Re: [PATCH 02/10] MCDE: Add configuration registers
On Fri, Nov 12, 2010 at 04:14:51PM +0100, Arnd Bergmann wrote:
> Some people prefer to express all this in C instead of macros:
>
> struct mcde_registers {
> enum {
> mcde_cr_dsicmd2_en = 0x0001,
> mcde_cr_dsicmd1_en = 0x0002,
> ...
> } cr;
> enum {
> mcde_conf0_syncmux0 = 0x0001,
> ...
> } conf0;
> ...
> };
>
> This gives you better type safety, but which one you choose is your decision.
It is a bad idea to describe device registers using C structures, and
especially enums.
The only thing C guarantees about structure layout is that the elements
are arranged in the same order which you specify them in your definition.
It doesn't make any guarantees about placement of those elements within
the structure.
As far as enums go, which type they correspond with is not really
predictable in portable code:
6.7.2.2 Enumeration specifiers
Constraints
4Each enumerated type shall be compatible with char, a signed integer
type, or an unsigned integer type. The choice of type is implementation-
defined,108) but shall be capable of representing the values of all
the members of the enumeration. The enumerated type is incomplete
until after the } that terminates the list of enumerator declarations.
108) An implementation may delay the choice of which integer type
until all enumeration constants have been seen.
So, given your example above, an implementation (or architecture) may
decide that 'cr' is a 'char' represented by 8 bits, while another
implementation may decide that it is an 'int' of 32 bits.
--
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 02/10] MCDE: Add configuration registers
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
>
> This patch adds the configuration registers found in MCDE.
> +
> +#define MCDE_VAL2REG(__reg, __fld, __val) \
> + (((__val) << __reg##_##__fld##_SHIFT) & __reg##_##__fld##_MASK)
> +#define MCDE_REG2VAL(__reg, __fld, __val) \
> + (((__val) & __reg##_##__fld##_MASK) >> __reg##_##__fld##_SHIFT)
> +
> +#define MCDE_CR 0x
> +#define MCDE_CR_DSICMD2_EN_V1_SHIFT 0
> +#define MCDE_CR_DSICMD2_EN_V1_MASK 0x0001
> +#define MCDE_CR_DSICMD2_EN_V1(__x) \
> + MCDE_VAL2REG(MCDE_CR, DSICMD2_EN_V1, __x)
> +#define MCDE_CR_DSICMD1_EN_V1_SHIFT 1
> +#define MCDE_CR_DSICMD1_EN_V1_MASK 0x0002
> +#define MCDE_CR_DSICMD1_EN_V1(__x) \
> + MCDE_VAL2REG(MCDE_CR, DSICMD1_EN_V1, __x)
> +#define MCDE_CR_DSI0_EN_V3_SHIFT 0
> +#define MCDE_CR_DSI0_EN_V3_MASK 0x0001
> +#define MCDE_CR_DSI0_EN_V3(__x) \
> + MCDE_VAL2REG(MCDE_CR, DSI0_EN_V3, __x)
This looks all rather unreadable. The easiest way is usually to just
define the bit mask, i.e. the second line of each register definition,
which you can use to mask the bits. It's also useful to indent the lines
so you can easily tell the register offsets apart from the contents:
#define MCDE_CR 0x
#define MCDE_CR_DSICMD2_EN_V1 0x0001
#define MCDE_CR_DSICMD1_EN_V1 0x0002
Some people prefer to express all this in C instead of macros:
struct mcde_registers {
enum {
mcde_cr_dsicmd2_en = 0x0001,
mcde_cr_dsicmd1_en = 0x0002,
...
} cr;
enum {
mcde_conf0_syncmux0 = 0x0001,
...
} conf0;
...
};
This gives you better type safety, but which one you choose is your decision.
Arnd
--
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: Leadtek WinFast PxPVR2200
03:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02) Subsystem: LeadTek Research Inc. Device [107d:6f21] Physical Slot: 0-1 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at fe80 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 2 Capabilities: [90] Vital Product Data Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Advanced Error Reporting Capabilities: [200] Virtual Channel Kernel driver in use: cx23885 Kernel modules: cx23885 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.38] mantis for_2.6.38
Hello, I've been waiting for this list of patchwork patches to be included for quite a while, and have now taken the liberty to clean them up as necessary and add them to a git tree, based on the current media_tree for_v2.6.38 branch, with exceptions as noted below: > == mantis patches - Waiting for Manu Abraham > == > > Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c > http://patchwork.kernel.org/patch/92961 David Härdeman > already applied as commit f0bdee26a2dc904c463bae1c2ae9ad06f97f100d > Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/107036 Marko Ristola > duplicate of http://patchwork.kernel.org/patch/118173 > Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files > http://patchwork.kernel.org/patch/107062 Bjørn Mork > Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module > removal http://patchwork.kernel.org/patch/107063 Bjørn Mork > Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make > modules http://patchwork.kernel.org/patch/107147 Manu Abraham > > Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits > http://patchwork.kernel.org/patch/109972 Ben Hutchings > > Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, > improve http://patchwork.kernel.org/patch/110909 Marko Ristola > another duplicate of http://patchwork.kernel.org/patch/118173 > Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery > http://patchwork.kernel.org/patch/111090 Marko Ristola > > Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of > busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola > > Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) > http://patchwork.kernel.org/patch/112708 Niklas Claesson > Missing Signed-off-by, and I'm also a bit confused wrt what the patch actually is. Needs further cleanup. > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola > > Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 > demod http://patchwork.kernel.org/patch/244201 Tuxoholic > The following changes since commit af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3[media] IR: add tv power scancode to rc6 mce keymap are available in the git repository at: git://git.mork.no/mantis.git for_2.6.38 Ben Hutchings (1): V4L/DVB: mantis: Rename gpio_set_bits to mantis_gpio_set_bits Bjørn Mork (2): V4L/DVB: mantis: use dvb_attach to avoid double dereferencing on module removal V4L/DVB/V4L: mantis: remove unused files Manu Abraham (1): Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make modules auto-loadable Marko Ristola (3): V4L/DVB: mantis: append tasklet maintenance for DVB stream delivery Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt media: mantis: use interrupt for I2C traffic instead of busy registry polling tuxoho...@hotmail.de (1): V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod drivers/media/dvb/frontends/stb0899_algo.c | 33 +++-- drivers/media/dvb/mantis/hopper_cards.c|4 +- drivers/media/dvb/mantis/hopper_vp3028.c |6 +- drivers/media/dvb/mantis/mantis_cards.c| 18 ++- drivers/media/dvb/mantis/mantis_common.h |9 +- drivers/media/dvb/mantis/mantis_core.c | 235 drivers/media/dvb/mantis/mantis_core.h | 57 --- drivers/media/dvb/mantis/mantis_dma.c | 92 --- drivers/media/dvb/mantis/mantis_dvb.c | 17 ++- drivers/media/dvb/mantis/mantis_i2c.c | 128 drivers/media/dvb/mantis/mantis_ioc.c |4 +- drivers/media/dvb/mantis/mantis_ioc.h |2 +- drivers/media/dvb/mantis/mantis_vp1033.c |2 +- drivers/media/dvb/mantis/mantis_vp1034.c | 10 +- drivers/media/dvb/mantis/mantis_vp1041.c |6 +- drivers/media/dvb/mantis/mantis_vp2033.c |5 +- drivers/media/dvb/mantis/mantis_vp2040.c |4 +- drivers/media/dvb/mantis/mantis_vp3030.c |8 +- 18 files changed, 208 insertions(+), 432 deletions(-) Note that some of these patches will trigger checkpatch long line warnings due to deliberate choices. I have no strong feelings about reformatting them, but I believe the review is easier the less I have changed the original patchworks patch... I sincerely hope this will make your job easier. Thanks for reviewing, Bjørn -- 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: Raw mode for SAA7134_BOARD_ENCORE_ENLTV_FM53?
Em 12-11-2010 12:14, David Härdeman escreveu: > Mauro, > > as far as I could tell, you wrote the initial support for > SAA7134_BOARD_ENCORE_ENLTV_FM53 in > drivers/media/video/saa7134/saa7134-input.c, right? > > It appears to be the only user of ir-functions.c left in that driver and > I'm wondering if it could be converted to use raw_decode with a patch > similar to what you committed for SAA7134_BOARD_ASUSTeK_P7131_ANALOG? > I need to check if I still have this board, or if it were a board that someone borrowed me. I'll put it on my todo list. 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 0/6] rc-core: ir-core to rc-core conversion
Em 12-11-2010 12:08, David Härdeman escreveu: > On Fri, Nov 12, 2010 at 10:56:34AM -0200, Mauro Carvalho Chehab wrote: >> Em 12-11-2010 10:12, David Härdeman escreveu: >>> Shouldn't platform_data be const? And you'll break the refcounting >>> done in rc_allocate_device() and rc_free_device() / >>> rc_unregister_device(). Not to mention the silent bugs that may be >>> introduced if anyone modifies rc_allocate_device() without noticing >>> that one driver isn't using it. >> >> It will still be const. platform_data will pass a pointer to some struct. >> The value of the pointer won't change. I don't see why this would break >> refcounting, as what will happen is that the caller driver will call >> rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c. > > I think I've misunderstood what you've been proposing for ir_kbd_i2c. > That sounds like a good solution. > >> I'm working on a patch for it right now. > > Good, I'll just wait until the patches are available to comment :) They are there already ;) http://www.spinics.net/lists/linux-media/msg24987.html http://www.spinics.net/lists/linux-media/msg24986.html Tested with a i2c-based cx231xx device (Pixelview Hybrid). 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
Raw mode for SAA7134_BOARD_ENCORE_ENLTV_FM53?
Mauro, as far as I could tell, you wrote the initial support for SAA7134_BOARD_ENCORE_ENLTV_FM53 in drivers/media/video/saa7134/saa7134-input.c, right? It appears to be the only user of ir-functions.c left in that driver and I'm wondering if it could be converted to use raw_decode with a patch similar to what you committed for SAA7134_BOARD_ASUSTeK_P7131_ANALOG? -- David Härdeman -- 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] rc-core: ir-core to rc-core conversion
On Fri, Nov 12, 2010 at 10:56:34AM -0200, Mauro Carvalho Chehab wrote: >Em 12-11-2010 10:12, David Härdeman escreveu: >> Shouldn't platform_data be const? And you'll break the refcounting >> done in rc_allocate_device() and rc_free_device() / >> rc_unregister_device(). Not to mention the silent bugs that may be >> introduced if anyone modifies rc_allocate_device() without noticing >> that one driver isn't using it. > >It will still be const. platform_data will pass a pointer to some struct. >The value of the pointer won't change. I don't see why this would break >refcounting, as what will happen is that the caller driver will call >rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c. I think I've misunderstood what you've been proposing for ir_kbd_i2c. That sounds like a good solution. >I'm working on a patch for it right now. Good, I'll just wait until the patches are available to comment :) -- David Härdeman -- 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: DVB-S/S2 Card for a linux-based dish pointer
Thank you Jason, I had stumbled on the TBS website while looking for receiver cards, but had not considered them because I was looking for something supported by the mainstream kernel. We expect a low volume for the positioner controllers (at least in the beginning), so we want to use as much off-the-shelf (COTS) parts as possible to reduce sw&hw development to a minimum. Also, I believe that if we use only what is supported by the mainstream kernel, we would not be tied to a single dvb card model/supplier/version/special driver. Can the linux dvb support be used in the situation I mentioned? (- no X running - send tuning/cps/etc configuration/commands via command line - get signal strength (dBm?) and quality (BER?), signal lock, and other sat info via command line or api or somewhere in /proc/ for example) Best regards, Joao S Veiga -- Original Message --- From: jason duhamell > You guys will want to contact http://tbsdtv.com/ for help. I my self make > embedded electronics. right now out of arm and mips based soc's if you want to cut out intel. tbs is an oem that makes the cards that other companies buy. they also make their own linux drivers. > > On Fri, Nov 12, 2010 at 2:34 AM, Joao S Veiga wrote: > Hello guys, > > We're developing an automatic satellite dish pointer controller (for > Satellite News Gathering vehicles and other > applications), and it will be based on a mini-itx Atom motherboard running > debian. > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix i2c support for IR's on cx231xx
Those two patches fix cx231xx-input, for I2C-based IR devices. They basically allow caller drivers to pass a rc_dev pointer via platform_data, making it possible to set other fields that are needed to be set by caller drivers. Mauro Carvalho Chehab (2): [media] ir-kbd-i2c: add rc_dev as a parameter to the driver [media] cx231xx: Fix i2c support at cx231xx-input drivers/media/video/cx231xx/Kconfig |2 +- drivers/media/video/cx231xx/cx231xx-input.c | 55 -- drivers/media/video/cx231xx/cx231xx.h | 21 +-- drivers/media/video/ir-kbd-i2c.c| 45 -- include/media/ir-kbd-i2c.h |2 + 5 files changed, 54 insertions(+), 71 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] ir-kbd-i2c: add rc_dev as a parameter to the driver
There are several fields on rc_dev that drivers can benefit. Allow drivers
to pass it as a parameter to the driver.
For now, the rc_dev parameter is optional. If drivers don't pass it, create
them internally. However, the best is to create rc_dev inside the drivers,
in order to fill other fields, like open(), close(), driver_name, etc.
So, a latter patch making it mandatory and changing the caller drivers is
welcome.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 55a22e7..50bb627 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -272,20 +272,16 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
const char *name = NULL;
u64 ir_type = IR_TYPE_UNKNOWN;
struct IR_i2c *ir;
- struct rc_dev *rc;
+ struct rc_dev *rc = NULL;
struct i2c_adapter *adap = client->adapter;
unsigned short addr = client->addr;
int err;
- ir = kzalloc(sizeof(struct IR_i2c),GFP_KERNEL);
- rc = rc_allocate_device();
- if (!ir || !rc) {
- err = -ENOMEM;
- goto err_out_free;
- }
+ ir = kzalloc(sizeof(struct IR_i2c), GFP_KERNEL);
+ if (!ir)
+ return -ENOMEM;
ir->c = client;
- ir->rc = rc;
ir->polling_interval = DEFAULT_POLLING_INTERVAL;
i2c_set_clientdata(client, ir);
@@ -334,6 +330,8 @@ static int ir_probe(struct i2c_client *client, const struct
i2c_device_id *id)
client->dev.platform_data;
ir_codes = init_data->ir_codes;
+ rc = init_data->rc_dev;
+
name = init_data->name;
if (init_data->type)
ir_type = init_data->type;
@@ -367,6 +365,19 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
}
}
+ if (!rc) {
+ /*
+* If platform_data doesn't specify rc_dev, initilize it
+* internally
+*/
+ rc = rc_allocate_device();
+ if (!rc) {
+ err = -ENOMEM;
+ goto err_out_free;
+ }
+ }
+ ir->rc = rc;
+
/* Make sure we are all setup before going on */
if (!name || !ir->get_key || !ir_type || !ir_codes) {
dprintk(1, ": Unsupported device at address 0x%02x\n",
@@ -383,12 +394,21 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
dev_name(&adap->dev),
dev_name(&client->dev));
- /* init + register input device */
+ /*
+* Initialize input_dev fields
+* It doesn't make sense to allow overriding them via platform_data
+*/
rc->input_id.bustype = BUS_I2C;
- rc->input_name = ir->name;
rc->input_phys = ir->phys;
- rc->map_name = ir->ir_codes;
- rc->driver_name = MODULE_NAME;
+ rc->input_name = ir->name;
+
+ /*
+* Initialize the other fields of rc_dev
+*/
+ rc->map_name = ir->ir_codes;
+ rc->allowed_protos = ir_type;
+ if (!rc->driver_name)
+ rc->driver_name = MODULE_NAME;
err = rc_register_device(rc);
if (err)
@@ -404,6 +424,7 @@ static int ir_probe(struct i2c_client *client, const struct
i2c_device_id *id)
return 0;
err_out_free:
+ /* Only frees rc if it were allocated internally */
rc_free_device(rc);
kfree(ir);
return err;
diff --git a/include/media/ir-kbd-i2c.h b/include/media/ir-kbd-i2c.h
index 4ee9b42..aca015e 100644
--- a/include/media/ir-kbd-i2c.h
+++ b/include/media/ir-kbd-i2c.h
@@ -46,5 +46,7 @@ struct IR_i2c_init_data {
*/
int(*get_key)(struct IR_i2c*, u32*, u32*);
enum ir_kbd_get_key_fn internal_get_key_func;
+
+ struct rc_dev *rc_dev;
};
#endif
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] cx231xx: Fix i2c support at cx231xx-input
There was a bug at cx231xx-input, where it were registering the remote
controls twice, one via ir-kbd-i2c and another directly.
Also, the patch that added rc_register_device() broke compilation for it.
This patch fixes cx231xx-input by fixing the depends on, to point to the
new symbol, and initializing the scanmask via platform_data.
While here, also fix Kconfig symbol change for IR core dependencies.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/Kconfig
b/drivers/media/video/cx231xx/Kconfig
index ab7d5df..d6a2350 100644
--- a/drivers/media/video/cx231xx/Kconfig
+++ b/drivers/media/video/cx231xx/Kconfig
@@ -16,7 +16,7 @@ config VIDEO_CX231XX
config VIDEO_CX231XX_RC
bool "Conexant cx231xx Remote Controller additional support"
- depends on VIDEO_IR
+ depends on IR_CORE
depends on VIDEO_CX231XX
default y
---help---
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c
b/drivers/media/video/cx231xx/cx231xx-input.c
index 6725244..65d951e 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -29,6 +29,8 @@ static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
{
u8 cmd;
+ dev_dbg(&ir->rc->input_dev->dev, "%s\n", __func__);
+
/* poll IR chip */
if (1 != i2c_master_recv(ir->c, &cmd, 1))
return -EIO;
@@ -40,7 +42,7 @@ static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
if (cmd == 0xff)
return 0;
- dev_dbg(&ir->input->dev, "scancode = %02x\n", cmd);
+ dev_dbg(&ir->rc->input_dev->dev, "scancode = %02x\n", cmd);
*ir_key = cmd;
*ir_raw = cmd;
@@ -49,9 +51,7 @@ static int get_key_isdbt(struct IR_i2c *ir, u32 *ir_key,
int cx231xx_ir_init(struct cx231xx *dev)
{
- struct input_dev *input_dev;
struct i2c_board_info info;
- int rc;
u8 ir_i2c_bus;
dev_dbg(&dev->udev->dev, "%s\n", __func__);
@@ -60,34 +60,18 @@ int cx231xx_ir_init(struct cx231xx *dev)
if (!cx231xx_boards[dev->model].rc_map)
return -ENODEV;
- input_dev = input_allocate_device();
- if (!input_dev)
- return -ENOMEM;
-
request_module("ir-kbd-i2c");
memset(&info, 0, sizeof(struct i2c_board_info));
- memset(&dev->ir.init_data, 0, sizeof(dev->ir.init_data));
+ memset(&dev->init_data, 0, sizeof(dev->init_data));
+ dev->init_data.rc_dev = rc_allocate_device();
+ if (!dev->init_data.rc_dev)
+ return -ENOMEM;
- dev->ir.input_dev = input_dev;
- dev->ir.init_data.name = cx231xx_boards[dev->model].name;
- dev->ir.props.priv = dev;
- dev->ir.props.allowed_protos = IR_TYPE_NEC;
- snprintf(dev->ir.name, sizeof(dev->ir.name),
-"cx231xx IR (%s)", cx231xx_boards[dev->model].name);
- usb_make_path(dev->udev, dev->ir.phys, sizeof(dev->ir.phys));
- strlcat(dev->ir.phys, "/input0", sizeof(dev->ir.phys));
+ dev->init_data.name = cx231xx_boards[dev->model].name;
strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
- info.platform_data = &dev->ir.init_data;
-
- input_dev->name = dev->ir.name;
- input_dev->phys = dev->ir.phys;
- input_dev->dev.parent = &dev->udev->dev;
- input_dev->id.bustype = BUS_USB;
- input_dev->id.version = 1;
- input_dev->id.vendor = le16_to_cpu(dev->udev->descriptor.idVendor);
- input_dev->id.product = le16_to_cpu(dev->udev->descriptor.idProduct);
+ info.platform_data = &dev->init_data;
/*
* Board-dependent values
@@ -95,28 +79,23 @@ int cx231xx_ir_init(struct cx231xx *dev)
* For now, there's just one type of hardware design using
* an i2c device.
*/
- dev->ir.init_data.get_key = get_key_isdbt;
- dev->ir.init_data.ir_codes = cx231xx_boards[dev->model].rc_map;
+ dev->init_data.get_key = get_key_isdbt;
+ dev->init_data.ir_codes = cx231xx_boards[dev->model].rc_map;
/* The i2c micro-controller only outputs the cmd part of NEC protocol */
- dev->ir.props.scanmask = 0xff;
+ dev->init_data.rc_dev->scanmask = 0xff;
+ dev->init_data.rc_dev->driver_name = "cx231xx";
+ dev->init_data.type = IR_TYPE_NEC;
info.addr = 0x30;
- rc = ir_input_register(input_dev, cx231xx_boards[dev->model].rc_map,
- &dev->ir.props, MODULE_NAME);
- if (rc < 0)
- return rc;
-
/* Load and bind ir-kbd-i2c */
ir_i2c_bus = cx231xx_boards[dev->model].ir_i2c_master;
+ dev_dbg(&dev->udev->dev, "Trying to bind ir at bus %d, addr 0x%02x\n",
+ ir_i2c_bus, info.addr);
i2c_new_device(&dev->i2c_bus[ir_i2c_bus].i2c_adap, &info);
- return rc;
+ return 0;
}
void cx231xx_ir_exit(struct cx231xx *dev)
{
- if (dev->ir.input_dev) {
- ir_input
RE: [PATCH 00/10] MCDE: Add frame buffer device driver
Hi Alex, Good point, we are looking at this for possible future improvements but for the moment we feel like the structure of drm does not add any simplifications for our driver. We have the display manager (MCDE DSS = KMS) and the memory manager (HWMEM = GEM) that could be migrated to drm framework. But we do not have drm drivers for 3D hw and this also makes drm a less obvious choice at the moment. Jimmy -Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: den 10 november 2010 15:43 To: Jimmy RUBIN Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin wrote: > These set of patches contains a display sub system framework (DSS) which is > used to > implement the frame buffer device interface and a display device > framework that is used to add support for different type of displays > such as LCD, HDMI and so on. For complex display hardware, you may want to consider using the drm kms infrastructure rather than the kernel fb interface. It provides an API for complex display hardware (multiple encoders, display controllers, etc.) and also provides a legacy kernel fb interface for compatibility. See: Documentation/DocBook/drm.tmpl drivers/gpu/drm/ in the kernel tree. Alex > > The current implementation supports DSI command mode displays. > > Below is a short summary of the files in this patchset: > > mcde_fb.c > Implements the frame buffer device driver. > > mcde_dss.c > Contains the implementation of the display sub system framework (DSS). > This API is used by the frame buffer device driver. > > mcde_display.c > Contains default implementations of the functions in the display driver > API. A display driver may override the necessary functions to function > properly. A simple display driver is implemented in display-generic_dsi.c. > > display-generic_dsi.c > Sample driver for a DSI command mode display. > > mcde_bus.c > Implementation of the display bus. A display device is probed when both > the display driver and display configuration have been registered with > the display bus. > > mcde_hw.c > Hardware abstraction layer of MCDE. All code that communicates directly > with the hardware resides in this file. > > board-mop500-mcde.c > The configuration of the display and the frame buffer device is handled > in this file > > NOTE: These set of patches replaces the patches already sent out for review. > > RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver > RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver > > The old patchset was to large to be handled by the mailing lists. > > Jimmy Rubin (10): > MCDE: Add hardware abstraction layer > MCDE: Add configuration registers > MCDE: Add pixel processing registers > MCDE: Add formatter registers > MCDE: Add dsi link registers > MCDE: Add generic display > MCDE: Add display subsystem framework > MCDE: Add frame buffer device driver > MCDE: Add build files and bus > ux500: MCDE: Add platform specific data > > arch/arm/mach-ux500/Kconfig | 8 + > arch/arm/mach-ux500/Makefile | 1 + > arch/arm/mach-ux500/board-mop500-mcde.c | 209 ++ > arch/arm/mach-ux500/board-mop500-regulators.c | 28 + > arch/arm/mach-ux500/board-mop500.c | 3 + > arch/arm/mach-ux500/devices-db8500.c | 68 + > arch/arm/mach-ux500/include/mach/db8500-regs.h | 7 + > arch/arm/mach-ux500/include/mach/devices.h | 1 + > arch/arm/mach-ux500/include/mach/prcmu-regs.h | 1 + > arch/arm/mach-ux500/include/mach/prcmu.h | 3 + > arch/arm/mach-ux500/prcmu.c | 129 ++ > drivers/video/Kconfig | 2 + > drivers/video/Makefile | 1 + > drivers/video/mcde/Kconfig | 39 + > drivers/video/mcde/Makefile | 12 + > drivers/video/mcde/display-generic_dsi.c | 152 ++ > drivers/video/mcde/dsi_link_config.h | 1486 ++ > drivers/video/mcde/mcde_bus.c | 259 +++ > drivers/video/mcde/mcde_config.h | 2156 > drivers/video/mcde/mcde_display.c | 427 > drivers/video/mcde/mcde_dss.c | 353 > drivers/video/mcde/mcde_fb.c | 697 +++ > drivers/video/mcde/mcde_formatter.h | 782 > drivers/video/mcde/mcde_hw.c | 2528 > > drivers/video/mcde/mcde_mod.c | 67 + > drivers/video/mcde/mcde_pixelprocess.h | 1137 +++ > include/video/mcde/mcde.h | 387 > include/video/mcde/mcde_display-generic_dsi.h | 34 + > include/video/mcde/mcde_display.h | 139 ++ > include/video/mcde/mcd
Re: [PATCH 0/6] rc-core: ir-core to rc-core conversion
Em 12-11-2010 10:12, David Härdeman escreveu: > On Fri, Nov 12, 2010 at 02:00:55AM -0200, Mauro Carvalho Chehab wrote: >> Em 11-11-2010 21:40, Jarod Wilson escreveu: >>> On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote: On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote: > A good exercise would be to port lirc-zilog and see what happens. I had a quick look at lirc-zilog and I doubt it would be a good candidate to integrate with ir-kbd-i2c.c (I assume that's what you were implying?). Which code from ir-kbd-i2c would it actually be using? >>> >>> On the receive side, lirc_zilog was pretty similar to lirc_i2c, which >>> we dropped entirely, as ir-kbd-i2c handles receive just fine for all >>> the relevant rx-only devices lirc_i2c worked with. So in theory, >>> ir-kbd-i2c might want to just grow tx support, but I think I'm more >>> inclined to make it a new stand-alone rx and tx capable driver. >> >> It doesn't matter much if we'll grow ir-kbd-i2c or convert lirc_zilog. >> The point is that rc_register_device() should be called inside the i2c >> driver, but several parameters should be passed to it via platform_data, >> in a way that is similar to ir-kbd-i2c. > > Yes, but if lirc_zilog doesn't use ir-kbd-i2c, there might not be a need > for the large number of rc-specific members in platform_data? This device is more complex than the current I2C devices, so, this will basically depend on the diversity of devices that are/will be supported. Yet, things like open/close callbacks are interesting, as they allow to turn off RC support when a table is empty, turning it on when the table is filled and some userspace app opens the input device. >> Maybe one solution would be to pass rc_dev via platform_data. > > Shouldn't platform_data be const? And you'll break the refcounting done > in rc_allocate_device() and rc_free_device() / rc_unregister_device(). > Not to mention the silent bugs that may be introduced if anyone modifies > rc_allocate_device() without noticing that one driver isn't using it. It will still be const. platform_data will pass a pointer to some struct. The value of the pointer won't change. I don't see why this would break refcounting, as what will happen is that the caller driver will call rc_allocate_device() and fill some fields there, instead of ir_kbd_i2c. I'm working on a patch for it right now. Basically, drivers that need to use other fields will do: dev->init_data->rc = rc_allocate_device(); if (!dev->init_data.rc) return -ENOMEM; dev->init_data.rc->driver_name = "foo_driver"; ... i2c_new_device(&i2c_adap, &info) > I like the idea of having an inlined function (like > usb_fill_control_urb), to be sure that all mandatory fields are > initialized by the drivers. I like the idea of having a function, let's call it rc_register_device(), which makes sure that all mandatory fields are initialized by the drivers :) >>> >>> rc_register_device(rc, name, phys, id); to further prevent duplicate >>> struct members? :) >> >> Seems a good idea to me. It is easier and more direct to pass those info >> as parameter, than to have some code inside rc_register_device to check >> for the mandatory data. > > See my reply to Jarod. > > And also, rc_register_device() is anyway going to check other mandatory > fields so having it check all of them in one go is just good consistency > IMHO. > >>> I still really like this interface change, even if its going to cause >>> short-term issues for i2c devices. I think we just extend this as >>> needed to handle the i2c bits. That said, I haven't really looked all >>> that closely at how much that entails... >>> >> >> I think I'll apply the cx231xx fixes and then rebase the rc_register_device >> patch on the top of it, doing a minimal change at IR_i2c. Currently, we >> just need to pass one extra parameter. After this, we can work to improve >> it. > > Meaning that you'll my patch with the rc_dev API the way it is basically > and then we can revisit the IR_i2c debate later if necessary? If that's > what you mean I'm all for it. > Ok. I'll do some tests here with the changes, and see if the i2c remotes will keep working after your and my patch. If they're ok, I'll post the patches to the ML and commit on my main tree. 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 0/6] rc-core: ir-core to rc-core conversion
On Fri, Nov 12, 2010 at 02:00:55AM -0200, Mauro Carvalho Chehab wrote: >Em 11-11-2010 21:40, Jarod Wilson escreveu: >> On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote: >>> On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote: A good exercise would be to port lirc-zilog and see what happens. >>> >>> I had a quick look at lirc-zilog and I doubt it would be a good >>> candidate to integrate with ir-kbd-i2c.c (I assume that's what you were >>> implying?). Which code from ir-kbd-i2c would it actually be using? >> >> On the receive side, lirc_zilog was pretty similar to lirc_i2c, which >> we dropped entirely, as ir-kbd-i2c handles receive just fine for all >> the relevant rx-only devices lirc_i2c worked with. So in theory, >> ir-kbd-i2c might want to just grow tx support, but I think I'm more >> inclined to make it a new stand-alone rx and tx capable driver. > >It doesn't matter much if we'll grow ir-kbd-i2c or convert lirc_zilog. >The point is that rc_register_device() should be called inside the i2c >driver, but several parameters should be passed to it via platform_data, >in a way that is similar to ir-kbd-i2c. Yes, but if lirc_zilog doesn't use ir-kbd-i2c, there might not be a need for the large number of rc-specific members in platform_data? >Maybe one solution would be to pass rc_dev via platform_data. Shouldn't platform_data be const? And you'll break the refcounting done in rc_allocate_device() and rc_free_device() / rc_unregister_device(). Not to mention the silent bugs that may be introduced if anyone modifies rc_allocate_device() without noticing that one driver isn't using it. I like the idea of having an inlined function (like usb_fill_control_urb), to be sure that all mandatory fields are initialized by the drivers. >>> >>> I like the idea of having a function, let's call it >>> rc_register_device(), which makes sure that all mandatory fields are >>> initialized by the drivers :) >> >> rc_register_device(rc, name, phys, id); to further prevent duplicate >> struct members? :) > >Seems a good idea to me. It is easier and more direct to pass those info >as parameter, than to have some code inside rc_register_device to check >for the mandatory data. See my reply to Jarod. And also, rc_register_device() is anyway going to check other mandatory fields so having it check all of them in one go is just good consistency IMHO. >> I still really like this interface change, even if its going to cause >> short-term issues for i2c devices. I think we just extend this as >> needed to handle the i2c bits. That said, I haven't really looked all >> that closely at how much that entails... >> > >I think I'll apply the cx231xx fixes and then rebase the rc_register_device >patch on the top of it, doing a minimal change at IR_i2c. Currently, we >just need to pass one extra parameter. After this, we can work to improve >it. Meaning that you'll my patch with the rc_dev API the way it is basically and then we can revisit the IR_i2c debate later if necessary? If that's what you mean I'm all for it. -- David Härdeman -- 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] rc-core: ir-core to rc-core conversion
On Thu, Nov 11, 2010 at 06:40:42PM -0500, Jarod Wilson wrote:
>On Thu, Nov 11, 2010 at 3:35 PM, David Härdeman wrote:
>> On Thu, Nov 11, 2010 at 02:00:38PM -0200, Mauro Carvalho Chehab wrote:
>>>I like the idea of having an inlined function (like
>>>usb_fill_control_urb), to be sure that all mandatory fields are
>>>initialized by the drivers.
>>
>> I like the idea of having a function, let's call it
>> rc_register_device(), which makes sure that all mandatory fields are
>> initialized by the drivers :)
>
>rc_register_device(rc, name, phys, id); to further prevent duplicate
>struct members? :)
As I said before, that won't work with multiple input devices per rc
dev. And it's a poorly designed API (IMHO) which expects you to set a
few properties in a struct and then add a few more via a function call.
Notes wrt. a future multi-input support:
First, realize that the name/phys/id of an input device is primarily
used to distinguish them from each other in user-space. Which means
having a shared name/phys/id triplet for all input devices belonging to
one rc device only makes them pointless.
So, I think we'll want something similar to name/phys/id, but for the rc
device (can be exported via sysfs). Input name/phys/id can then be
derived from the rc device for each input subdev (or name could perhaps
be set to some user-friendly description of the actual remote control by
whichever user-space tool loads the corresponding keymap).
Example:
rc_dev->name = "FooBar IR-Masta 2000"
rc_dev->phys = "PNP0BAR/rc0"
(would be available from /sys/class/rc/rc0/{name|phys})
/* Not set by the driver, available with lsinput */
rc_dev->input_devs[0]->name = "FooBar IR-Masta 2000 Remote 1"
rc_dev->input_devs[0]->phys = "PNP0BAR/rc0/input0"
rc_dev->input_devs[0]->id.bustype = BUS_RC;
rc_dev->input_devs[1]->name = "FooBar IR-Masta 2000 Remote 2"
rc_dev->input_devs[1]->phys = "PNP0BAR/rc0/input1"
rc_dev->input_devs[1]->id.bustype = BUS_RC;
(Just an example, don't overanalyse the details)
As you see, the rc_dev->input_name/phys/id is just a stopgap measure for
now, and I certainly don't think future development will be helped by
moving any input related fields up to the rc_register_device() level
when they should instead go further "down".
>I still really like this interface change, even if its going to cause
>short-term issues for i2c devices. I think we just extend this as
>needed to handle the i2c bits.
Agreed.
--
David Härdeman
--
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
Fixing tbs-nec table after converting to cx88 driver ir-core
Hello I am using Prof 7301 PCI card. After converting cx88 driver to ir-core (thank you very much for your work, David) the table rc-tbs-nec (for bundled remote) has incorrect values. I was comparing the results and there is a regularity (constant offset): If i add 0x80 (128 decimal) value to every code in rc-tbs-nec.c then original remote gives correct EV_KEY events (just like before cx88 conversion) :) Despite the fact that my IR receiver is now able to work with many remotes it is still using standard remote which is in mentioned table, so I think that we should correct the table to have it correct, what do you think? I also need to mention that the table is incomplete. Please have a look at remote: http://www.prof-tuners.com/eng/images/review/review_prof_7301/prof_7301_6.jpg As you can see there are two buttons (10+ and 10-), which the table doesn't take into account. Correct me if i'm wrong, but i believe it means: 10 channels up, and 10 channels down. So my proposition is to add new definitions for this buttons. Maybe: KEY_10CHANNELSUP and KEY_10CHANNELSDOWN, what do you think? Unfortunately I can't test the button meaning, because i don't have windows at home computer with original software for the card. I can provide full and fixed rc-tbs-nec table patch then. regards, -- Mariusz Bialonczyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- 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
Diseqc dish motor with budget-ci and TechniSat SkyStar HD 1131:7146 does not work.
Dish motor does not work with this card under linux budget-ci driver, even compiled from newest source from project page. What should I post here to help solve that problem? Under MS Windows everything work's fine, with bt8xx card also, this is drivers fault only. Please help me:( -- 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
