Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
On Sat, May 6, 2017 at 3:50 AM, Thomas Hollstegge wrote: > Hi Markus, > > Markus Rechberger schrieb am Sat, 06. May 00:33: >> We had different HW designs based on Empia until 2012 using this USB >> ID it will not work with many units out there, also with different >> standby behaviours, chipsets etc. > > Well, after this patch there's one more device that works with an > open-source driver, which I consider a good thing. What about > open-sourcing support for the other devices you're talking about? > As mentioned you can use the sysfs approach for you. Don't buy a device which you intend to use with unintended software afterwards. Your device is from 2010 as far as I see, you can ship the unit back for changing the USB ID for it so you can mess around with it and break it completely. The USB ID in question is used for all kind of devices, even analog or radio only units which are very far from being supported by this crappy opensource driver which is able to crash the entire kernel. Our work is pretty much isolated. You might match your unit also based on your serialnumber if you want to apply such a patch to the crappy opensource driver. >> If you want to get a device with kernel support I recommend buying a >> different one and let that one go back to our community (since our >> tuners and support are still quite popular). > > Thanks, but I'd rather stick with the device I have than spending more > money to have a device that only works with a closed-source driver. > then sell it get a good price and buy another unit or ship it back for getting another USB ID (the EEPROM needs to be removed for rewriting it). > Anyway, I just saw that the patch doesn't apply cleanly against > linux-media master. I'll submit a new version of the patch in a > minute. > > Cheers > Thomas
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat May 6 05:00:23 CEST 2017 media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa media_build git hash: 1af19680bde3e227d64d99ff5fdc43eb343a3b28 v4l-utils git hash: eb9dcc3e1d4805c382e244397df2290051179601 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-blackfin-bf561: OK linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: WARNINGS linux-4.9.26-i686: WARNINGS linux-4.10.14-i686: WARNINGS linux-4.11-i686: WARNINGS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding
Subject is too long.
On Sat, May 06, 2017 at 04:04:50AM +0300, Gideon Sheril wrote:
> /* The atomisp uses type==0 for the end-of-list marker, so leave space. */
> @@ -152,13 +152,13 @@ const struct camera_af_platform_data
> *camera_get_af_platform_data(void)
> EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
>
> int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
> -struct camera_sensor_platform_data
> *plat_data,
> -enum intel_v4l2_subdev_type type)
> + struct
> camera_sensor_platform_data *plat_data,
> + enum
> intel_v4l2_subdev_type type)
Huh???
> {
> int i;
> struct i2c_board_info *bi;
> struct gmin_subdev *gs;
> -struct i2c_client *client = v4l2_get_subdevdata(subdev);
> + struct i2c_client *client = v4l2_get_subdevdata(subdev);
Wut? How would this be correct?
regards,
dan carpenter
[PATCH] staging/media/atomisp/platform/intel-mid change spaces to tabs and comma/assignment space padding
atomisp_gmin_platform.c:
Fix ERROR: spaces instead of tabs and comma/assignment padding error.
Signed-off-by: Gideon Sheril
---
.../platform/intel-mid/atomisp_gmin_platform.c | 166 ++---
1 file changed, 83 insertions(+), 83 deletions(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..6953dca 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
/* The atomisp uses type==0 for the end-of-list marker, so leave space. */
@@ -152,13 +152,13 @@ const struct camera_af_platform_data
*camera_get_af_platform_data(void)
EXPORT_SYMBOL_GPL(camera_get_af_platform_data);
int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
-struct camera_sensor_platform_data *plat_data,
-enum intel_v4l2_subdev_type type)
+ struct
camera_sensor_platform_data *plat_data,
+ enum
intel_v4l2_subdev_type type)
{
int i;
struct i2c_board_info *bi;
struct gmin_subdev *gs;
-struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
dev_info(&client->dev, "register atomisp i2c module type %d\n", type);
@@ -172,7 +172,7 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
if (adev)
adev->power.flags.power_resources = 0;
- for (i=0; i < MAX_SUBDEVS; i++)
+ for (i = 0; i < MAX_SUBDEVS; i++)
if (!pdata.subdevs[i].type)
break;
@@ -203,13 +203,13 @@ int atomisp_register_i2c_module(struct v4l2_subdev
*subdev,
EXPORT_SYMBOL_GPL(atomisp_register_i2c_module);
struct v4l2_subdev *atomisp_gmin_find_subdev(struct i2c_adapter *adapter,
-struct i2c_board_info *board_info)
+struct i2c_board_info
*board_info)
{
int i;
- for (i=0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
+ for (i = 0; i < MAX_SUBDEVS && pdata.subdevs[i].type; i++) {
struct intel_v4l2_subdev_table *sd = &pdata.subdevs[i];
if (sd->v4l2_subdev.i2c_adapter_id == adapter->nr &&
- sd->v4l2_subdev.board_info.addr == board_info->addr)
+ sd->v4l2_subdev.board_info.addr == board_info->addr)
return sd->subdev;
}
return NULL;
@@ -270,45 +270,45 @@ static const struct gmin_cfg_var t100_vars[] = {
};
static const struct gmin_cfg_var mrd7_vars[] = {
-{"INT33F8:00_CamType", "1"},
-{"INT33F8:00_CsiPort", "1"},
-{"INT33F8:00_CsiLanes","2"},
-{"INT33F8:00_CsiFmt","13"},
-{"INT33F8:00_CsiBayer", "0"},
-{"INT33F8:00_CamClk", "0"},
-{"INT33F9:00_CamType", "1"},
-{"INT33F9:00_CsiPort", "0"},
-{"INT33F9:00_CsiLanes","1"},
-{"INT33F9:00_CsiFmt","13"},
-{"INT33F9:00_CsiBayer", "0"},
-{"INT33F9:00_CamClk", "1"},
-{},
+ {"INT33F8:00_CamType", "1"},
+ {"INT33F8:00_CsiPort", "1"},
+ {"INT33F8:00_CsiLanes", "2"},
+ {"INT33F8:00_CsiFmt", "13"},
+ {"INT33F8:00_CsiBayer", "0"},
+ {"INT33F8:00_CamClk", "0"},
+ {"INT33F9:00_CamType", "1"},
+ {"INT33F9:00_CsiPort", "0"},
+ {"INT33F9:00_CsiLanes", "1"},
+ {"INT33F9:00_CsiFmt", "13"},
+ {"INT33F9:00_CsiBayer", "0"},
+ {"INT33F9:00_CamClk", "1"},
+ {},
};
static const struct gmin_cfg_var ecs7_vars[] = {
-{"INT33BE:00_CsiPort", "1"},
-{"INT33BE:00_CsiLanes","2"},
-{"INT33BE:00_CsiFmt","13"},
-{"INT33BE:00_CsiBayer", "2"},
-{"INT33BE:00_CamClk", "0"},
-{"INT33F0:00_CsiPort", "0"},
-{"INT33F0:00_CsiLanes","1"},
-{"INT33F0:00_CsiFmt","13"},
-{"INT33F0:00_CsiBayer", "0"},
-{"INT33F0:00_CamClk", "1"},
-{"gmin_V2P8GPIO","402"},
-{},
+ {"INT33BE:00_CsiPort", "1"},
+ {"INT33BE:00_CsiLanes", "2"},
+ {"INT33BE:00_CsiFmt", "13"},
+ {"INT33BE:00_CsiBayer", "2"},
+ {"INT33BE:00_CamClk", "0"},
+ {"INT33F0:00_CsiPort", "0"},
+ {"INT33
Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls
Hi Kieran / Mauro, On Fri, May 05, 2017 at 06:33:22PM +0100, Kieran Bingham wrote: > Hi Sakari, > > On 04/01/17 08:57, Sakari Ailus wrote: > > Hi Kieran, > > > > Thanks for the patch! > > > > On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote: > >> On 03/01/17 13:36, Laurent Pinchart wrote: > >>> Hi Kieran, > >>> > >>> Thank you for the patch. > >>> > >>> On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote: > Drivers must not perform unbalanced calls to stop the entity pipeline, > however if they do they will fault in the core media code, as the > entity->pipe will be set as NULL. We handle this gracefully in the core > with a WARN for the developer. > > Replace the erroneous check on zero streaming counts, with a check on > NULL pipe elements instead, as this is the symptom of unbalanced > media_pipeline_stop calls. > > Signed-off-by: Kieran Bingham > >>> > >>> This looks good to me, > >>> > >>> Acked-by: Laurent Pinchart > >>> > >>> I'll let Sakari review and merge the patch. > >> > >> Ahh, yes - I forgot to mention, although perhaps it will be obvious for > >> Sakari - but this patch is based on top of Sakari's pending media > >> pipeline and graph walk cleanup series :D > > > > I've applied this on top of the other patches. > > > > It's always good to mention dependencies to other patches, that's very > > relevant for reviewers. > > I've just been going through my old branches doing some clean up - and I can't > see that this patch [0] made it to integration anywhere. > > Did it get lost? > It looks like the cleanup series it was based on made it through... What I think happened was that I had applied it to the correct branch BUT I already had sent a pull request on it. My apologies. > > Mauro, perhaps you could pick this one up now ? The patchwork link is here: https://patchwork.linuxtv.org/patch/38883/> -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[PATCH] media: fix one code style problem
From: Remco Verhoef
this patch will fix one code style problem (ctx:WxE), space
prohibited before that
Signed-off-by: Remco Verhoef
---
.../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..b0f9188 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -51,7 +51,7 @@ struct gmin_subdev {
static struct gmin_subdev gmin_subdevs[MAX_SUBDEVS];
-static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI ,
+static enum { PMIC_UNSET = 0, PMIC_REGULATOR, PMIC_AXP, PMIC_TI,
PMIC_CRYSTALCOVE } pmic_id;
/* The atomisp uses type==0 for the end-of-list marker, so leave space. */
--
1.9.1
[PATCH v2] [media] em28xx: support for Sundtek MediaTV Digital Home
Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the
following components:
USB bridge: Empia EM2874B
Demodulator: Micronas DRX 3913KA2
Tuner: NXP TDA18271HDC2
Signed-off-by: Thomas Hollstegge
---
Changes in v2:
- Make the patch apply against linux-media master
drivers/media/usb/em28xx/em28xx-cards.c | 15 +++
drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
drivers/media/usb/em28xx/em28xx.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index a12b599..adb5db2 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -415,6 +415,7 @@ static struct em28xx_reg_seq hauppauge_930c_digital[] = {
/* 1b80:e425 MaxMedia UB425-TC
* 1b80:e1cc Delock 61959
+ * eb1a:51b2 Sundtek MediaTV Digital Home
* GPIO_6 - demod reset, 0=active
* GPIO_7 - LED, 0=active
*/
@@ -2405,6 +2406,18 @@ struct em28xx_board em28xx_boards[] = {
.ir_codes = RC_MAP_HAUPPAUGE,
.leds = hauppauge_dualhd_leds,
},
+ /* eb1a:51b2 Sundtek MediaTV Digital Home
+* Empia EM2874B + Micronas DRX 3913KA2 + NXP TDA18271HDC2 */
+ [EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME] = {
+ .name = "Sundtek MediaTV Digital Home",
+ .tuner_type= TUNER_ABSENT,
+ .tuner_gpio= maxmedia_ub425_tc,
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_REDDO,
+ .def_i2c_bus = 1,
+ .i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
};
EXPORT_SYMBOL_GPL(em28xx_boards);
@@ -2602,6 +2615,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM28178_BOARD_PLEX_PX_BCUD },
{ USB_DEVICE(0xeb1a, 0x5051), /* Ion Video 2 PC MKII / Startech
svid2usb23 / Raygo R12-41373 */
.driver_info = EM2860_BOARD_TVP5150_REFERENCE_DESIGN },
+ { USB_DEVICE(0xeb1a, 0x51b2),
+ .driver_info =
EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 82edd37..e7fa25d 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1482,6 +1482,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
break;
}
case EM2874_BOARD_DELOCK_61959:
+ case EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME:
case EM2874_BOARD_MAXMEDIA_UB425_TC:
/* attach demodulator */
dvb->fe[0] = dvb_attach(drxk_attach, &maxmedia_ub425_tc_drxk,
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index e8d97d5..226c2b6 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -148,6 +148,7 @@
#define EM28178_BOARD_PLEX_PX_BCUD98
#define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB 99
#define EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 100
+#define EM2874_BOARD_SUNDTEK_MEDIATV_DIGITAL_HOME 101
/* Limits minimum and default number of buffers */
#define EM28XX_MIN_BUF 4
--
2.7.4
Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
Hi Markus, Markus Rechberger schrieb am Sat, 06. May 00:33: > We had different HW designs based on Empia until 2012 using this USB > ID it will not work with many units out there, also with different > standby behaviours, chipsets etc. Well, after this patch there's one more device that works with an open-source driver, which I consider a good thing. What about open-sourcing support for the other devices you're talking about? > If you want to get a device with kernel support I recommend buying a > different one and let that one go back to our community (since our > tuners and support are still quite popular). Thanks, but I'd rather stick with the device I have than spending more money to have a device that only works with a closed-source driver. Anyway, I just saw that the patch doesn't apply cleanly against linux-media master. I'll submit a new version of the patch in a minute. Cheers Thomas
Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls
Hi Sakari, On 04/01/17 08:57, Sakari Ailus wrote: > Hi Kieran, > > Thanks for the patch! > > On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote: >> On 03/01/17 13:36, Laurent Pinchart wrote: >>> Hi Kieran, >>> >>> Thank you for the patch. >>> >>> On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote: Drivers must not perform unbalanced calls to stop the entity pipeline, however if they do they will fault in the core media code, as the entity->pipe will be set as NULL. We handle this gracefully in the core with a WARN for the developer. Replace the erroneous check on zero streaming counts, with a check on NULL pipe elements instead, as this is the symptom of unbalanced media_pipeline_stop calls. Signed-off-by: Kieran Bingham >>> >>> This looks good to me, >>> >>> Acked-by: Laurent Pinchart >>> >>> I'll let Sakari review and merge the patch. >> >> Ahh, yes - I forgot to mention, although perhaps it will be obvious for >> Sakari - but this patch is based on top of Sakari's pending media >> pipeline and graph walk cleanup series :D > > I've applied this on top of the other patches. > > It's always good to mention dependencies to other patches, that's very > relevant for reviewers. I've just been going through my old branches doing some clean up - and I can't see that this patch [0] made it to integration anywhere. Did it get lost? It looks like the cleanup series it was based on made it through... Mauro, perhaps you could pick this one up now ? Regards Kieran [0] https://www.spinics.net/lists/linux-media/msg109715.html
[PATCH] staging: media: atomisp: fixed sparse warnings
Added "static" storage class to 4 not-declared functions
Signed-off-by: Avraham Shukron
---
.../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a..15409e9 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -436,7 +436,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int
on)
return -EINVAL;
}
-int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
{
struct gmin_subdev *gs = find_gmin_subdev(subdev);
@@ -455,7 +455,8 @@ int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
}
-int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
+
+static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
{
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -491,7 +492,7 @@ int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
}
-int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
{
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -527,7 +528,7 @@ int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
}
-int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
{
int ret = 0;
struct gmin_subdev *gs = find_gmin_subdev(subdev);
--
2.7.4
Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
On Fri, May 5, 2017 at 11:44 PM, Thomas Hollstegge wrote: > Hi Markus, > > Markus Rechberger schrieb am Fri, 05. May 08:06: >> On Fri, May 5, 2017 at 6:21 AM, Thomas Hollstegge >> wrote: >> > Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the >> > following components: >> > >> > USB bridge: Empia EM2874B >> > Demodulator: Micronas DRX 3913KA2 >> > Tuner: NXP TDA18271HDC2 >> > >> >> Not that it matters a lot anymore for those units however the USB ID >> is allocated for multiple different units, this patch will break some >> of them. > > I searched the kernel sources for USB IDs but didn't find any mention. > So what exactly will break with this commit? Is there a better way to > detect different devices besides USB IDs? > We had different HW designs based on Empia until 2012 using this USB ID it will not work with many units out there, also with different standby behaviours, chipsets etc. If you want to get a device with kernel support I recommend buying a different one and let that one go back to our community (since our tuners and support are still quite popular). >> If you want to use that use the unit with this driver you're on your >> own and have to assign it via sysfs and usb/bind. > > I did, and it works fine. However, it would be nice if the driver > supported the devices directly. > >> It was a joint project many years ago before we also started to design >> and manufacture our own units. > > Interesting, thanks for sharing this insight! > > Cheers > Thomas
Re: [PATCH] [media] em28xx: support for Sundtek MediaTV Digital Home
Hi Markus, Markus Rechberger schrieb am Fri, 05. May 08:06: > On Fri, May 5, 2017 at 6:21 AM, Thomas Hollstegge > wrote: > > Sundtek MediaTV Digital Home is a rebranded MaxMedia UB425-TC with the > > following components: > > > > USB bridge: Empia EM2874B > > Demodulator: Micronas DRX 3913KA2 > > Tuner: NXP TDA18271HDC2 > > > > Not that it matters a lot anymore for those units however the USB ID > is allocated for multiple different units, this patch will break some > of them. I searched the kernel sources for USB IDs but didn't find any mention. So what exactly will break with this commit? Is there a better way to detect different devices besides USB IDs? > If you want to use that use the unit with this driver you're on your > own and have to assign it via sysfs and usb/bind. I did, and it works fine. However, it would be nice if the driver supported the devices directly. > It was a joint project many years ago before we also started to design > and manufacture our own units. Interesting, thanks for sharing this insight! Cheers Thomas
[PATCH v5 4/8] ARM: dts: stm32: Enable DCMI camera interface on STM32F429-EVAL board
Enable DCMI camera interface on STM32F429-EVAL board.
Signed-off-by: Hugues Fruchet
---
arch/arm/boot/dts/stm32429i-eval.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 3c99466..617f2f7 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,6 +141,15 @@
clock-frequency = <2500>;
};
+&dcmi {
+ status = "okay";
+
+ port {
+ dcmi_0: endpoint {
+ };
+ };
+};
+
&i2c1 {
pinctrl-0 = <&i2c1_pins>;
pinctrl-names = "default";
--
1.9.1
[PATCH v5 0/8] Add support for DCMI camera interface of STMicroelectronics STM32 SoC series
This patchset introduces a basic support for Digital Camera Memory Interface (DCMI) of STMicroelectronics STM32 SoC series. This first basic support implements RGB565 & YUV frame grabbing. Cropping and JPEG support will be added later on. This has been tested on STM324x9I-EVAL evaluation board embedding an OV2640 camera sensor. This driver depends on: - [PATCHv6 00/14] atmel-isi/ov7670/ov2640: convert to standalone drivers http://www.spinics.net/lists/linux-media/msg113480.html === = history = === version 5: - Fix remarks from Hans Verkuil on v4: http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html - clk_enable before subdev streamon in start_streaming - rework cleanup on error in start_streaming - typos/blank fixing - remove extra checks done by core in try_fmt - use clamp macro to check supported min/max resolution - revisit cap->card string to fit cap->card length - removed some unneeded ret variables - use of devm_reset_control_get to save reset cleanup version 4: - "v4l2-compliance -s -f" report - fix behaviour in case of start_streaming failure (DMA memory shortage for ex.) - dt-bindings: Fix remarks from Rob Herring: http://www.mail-archive.com/linux-media@vger.kernel.org/msg111340.html Add "Acked-by: Rob Herring " version 3: - stm32-dcmi: Add "Reviewed-by: Hans Verkuil " - dt-bindings: Fix remarks from Rob Herring: http://www.mail-archive.com/linux-media@vger.kernel.org/msg110956.html version 2: - Fix a Kbuild warning in probe: http://www.mail-archive.com/linux-media@vger.kernel.org/msg110678.html - Fix a warning in dcmi_queue_setup() - dt-bindings: warn on sensor signals level inversion in board example - Typos fixing version 1: - Initial submission === = v4l2-compliance = === Below is the v4l2-compliance report for this current version of the DCMI camera interface. v4l2-compliance has been built from v4l-utils-1.12.3. ~ # v4l2-compliance -s -f -d /dev/video0 v4l2-compliance SHA : f5f45e17ee98a0ebad7836ade2b34ceec909d751 Driver Info: Driver name : stm32-dcmi Card type : STM32 Digital Camera Memory Int Bus info : platform:dcmi Driver version: 4.11.0 Capabilities : 0x8521 Video Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x0521 Video Capture Read/Write Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Test input 0: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 3 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supp
[PATCH v5 8/8] ARM: configs: stm32: DCMI + OV2640 camera support
Enable DCMI camera interface and OV2640 camera sensor drivers. Signed-off-by: Hugues Fruchet --- arch/arm/configs/stm32_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index 84adc88..3f2e4ce 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -53,6 +53,13 @@ CONFIG_GPIO_STMPE=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_USB_SUPPORT is not set +CONFIG_VIDEO_V4L2=y +CONFIG_MEDIA_SUBDRV_AUTOSELECT=n +CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_VIDEO_STM32_DCMI=y +CONFIG_VIDEO_OV2640=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y -- 1.9.1
[PATCH v5 7/8] ARM: configs: stm32: STMPE1600 GPIO expander
Enable STMPE1600 GPIO expander. Signed-off-by: Hugues Fruchet --- arch/arm/configs/stm32_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index a9d8e3c..84adc88 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -49,6 +49,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set CONFIG_REGULATOR=y +CONFIG_GPIO_STMPE=y +CONFIG_MFD_STMPE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_USB_SUPPORT is not set CONFIG_NEW_LEDS=y -- 1.9.1
[PATCH v5 1/8] dt-bindings: Document STM32 DCMI bindings
This adds documentation of device tree bindings for the STM32 DCMI
(Digital Camera Memory Interface).
Acked-by: Rob Herring
Signed-off-by: Hugues Fruchet
---
.../devicetree/bindings/media/st,stm32-dcmi.txt| 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
new file mode 100644
index 000..f8baf65
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STM32 Digital Camera Memory Interface (DCMI)
+
+Required properties:
+- compatible: "st,stm32-dcmi"
+- reg: physical base address and length of the registers set for the device
+- interrupts: should contain IRQ line for the DCMI
+- resets: reference to a reset controller,
+ see Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
+- clocks: list of clock specifiers, corresponding to entries in
+ the clock-names property
+- clock-names: must contain "mclk", which is the DCMI peripherial clock
+- pinctrl: the pincontrol settings to configure muxing properly
+ for pins that connect to DCMI device.
+ See Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt.
+- dmas: phandle to DMA controller node,
+see Documentation/devicetree/bindings/dma/stm32-dma.txt
+- dma-names: must contain "tx", which is the transmit channel from DCMI to DMA
+
+DCMI supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ dcmi: dcmi@5005 {
+ compatible = "st,stm32-dcmi";
+ reg = <0x5005 0x400>;
+ interrupts = <78>;
+ resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
+ clock-names = "mclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcmi_pins>;
+ dmas = <&dma2 1 1 0x414 0x3>;
+ dma-names = "tx";
+ port {
+ dcmi_0: endpoint {
+ remote-endpoint = <...>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
--
1.9.1
[PATCH v5 3/8] ARM: dts: stm32: Enable DCMI support on STM32F429 MCU
Enable DCMI camera interface on STM32F429 MCU.
Signed-off-by: Hugues Fruchet
---
arch/arm/boot/dts/stm32f429.dtsi | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index ee0da97..e1ff978 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -736,6 +736,29 @@
slew-rate = <3>;
};
};
+
+ dcmi_pins: dcmi_pins@0 {
+ pins {
+ pinmux =
,
+
,
+
,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <3>;
+ };
+ };
};
rcc: rcc@40023810 {
@@ -805,6 +828,20 @@
status = "disabled";
};
+ dcmi: dcmi@5005 {
+ compatible = "st,stm32-dcmi";
+ reg = <0x5005 0x400>;
+ interrupts = <78>;
+ resets = <&rcc STM32F4_AHB2_RESET(DCMI)>;
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(DCMI)>;
+ clock-names = "mclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dcmi_pins>;
+ dmas = <&dma2 1 1 0x414 0x3>;
+ dma-names = "tx";
+ status = "disabled";
+ };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
--
1.9.1
[PATCH v5 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver
This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
of STMicroelectronics STM32 SoC series.
Reviewed-by: Hans Verkuil
Signed-off-by: Yannick Fertre
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/Kconfig| 12 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/stm32/Makefile |1 +
drivers/media/platform/stm32/stm32-dcmi.c | 1403 +
4 files changed, 1418 insertions(+)
create mode 100644 drivers/media/platform/stm32/Makefile
create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ac026ee..de6e18b 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -114,6 +114,18 @@ config VIDEO_S3C_CAMIF
To compile this driver as a module, choose M here: the module
will be called s3c-camif.
+config VIDEO_STM32_DCMI
+ tristate "Digital Camera Memory Interface (DCMI) support"
+ depends on VIDEO_V4L2 && OF && HAS_DMA
+ depends on ARCH_STM32 || COMPILE_TEST
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This module makes the STM32 Digital Camera Memory Interface (DCMI)
+ available as a v4l2 device.
+
+ To compile this driver as a module, choose M here: the module
+ will be called stm32-dcmi.
+
source "drivers/media/platform/soc_camera/Kconfig"
source "drivers/media/platform/exynos4-is/Kconfig"
source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 63303d6..231f3c2 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,6 +68,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin/
obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel/
obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel/
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
+
ccflags-y += -I$(srctree)/drivers/media/i2c
obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
diff --git a/drivers/media/platform/stm32/Makefile
b/drivers/media/platform/stm32/Makefile
new file mode 100644
index 000..9b606a7
--- /dev/null
+++ b/drivers/media/platform/stm32/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32-dcmi.o
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c
b/drivers/media/platform/stm32/stm32-dcmi.c
new file mode 100644
index 000..348f025
--- /dev/null
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -0,0 +1,1403 @@
+/*
+ * Driver for STM32 Digital Camera Memory Interface
+ *
+ * Copyright (C) STMicroelectronics SA 2017
+ * Authors: Yannick Fertre
+ * Hugues Fruchet
+ * for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * This driver is based on atmel_isi.c
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "stm32-dcmi"
+
+/* Registers offset for DCMI */
+#define DCMI_CR0x00 /* Control Register */
+#define DCMI_SR0x04 /* Status Register */
+#define DCMI_RIS 0x08 /* Raw Interrupt Status register */
+#define DCMI_IER 0x0C /* Interrupt Enable Register */
+#define DCMI_MIS 0x10 /* Masked Interrupt Status register */
+#define DCMI_ICR 0x14 /* Interrupt Clear Register */
+#define DCMI_ESCR 0x18 /* Embedded Synchronization Code Register */
+#define DCMI_ESUR 0x1C /* Embedded Synchronization Unmask Register */
+#define DCMI_CWSTRT0x20 /* Crop Window STaRT */
+#define DCMI_CWSIZE0x24 /* Crop Window SIZE */
+#define DCMI_DR0x28 /* Data Register */
+#define DCMI_IDR 0x2C /* IDentifier Register */
+
+/* Bits definition for control register (DCMI_CR) */
+#define CR_CAPTURE BIT(0)
+#define CR_CM BIT(1)
+#define CR_CROPBIT(2)
+#define CR_JPEGBIT(3)
+#define CR_ESS BIT(4)
+#define CR_PCKPOL BIT(5)
+#define CR_HSPOL BIT(6)
+#define CR_VSPOL BIT(7)
+#define CR_FCRC_0 BIT(8)
+#define CR_FCRC_1 BIT(9)
+#define CR_EDM_0 BIT(10)
+#define CR_EDM_1 BIT(11)
+#define CR_ENABLE BIT(14)
+
+/* Bits definition for status register (DCMI_SR) */
+#define SR_HSYNC BIT(0)
+#define SR_VSYNC BIT(1)
+#define SR_FNE BIT(2)
+
+/*
+ * Bits definition for interrupt registers
+ * (DCMI_RIS, DCMI_IER, DCMI_MIS, DCMI_ICR)
+ */
+#define IT_FRAME BIT(0)
+#define IT_OVR BIT(1)
+#define IT_ERR BIT(2)
+#define IT_VSYNC BIT(3)
+#define IT_LINEBIT(4)
+
+enum state {
+ STOPPED = 0,
+ RUNNING,
+ STOPPING,
+};
+
+#define MIN_WIDTH 16U
+#define MAX_WIDTH 2048U
+#define MIN_HEIGHT 16U
+#define MAX_HEIGHT 2048U
+
+#define TIM
[PATCH v5 6/8] ARM: dts: stm32: Enable OV2640 camera support of STM32F429-EVAL board
Enable OV2640 camera support of STM32F429-EVAL board.
Signed-off-by: Hugues Fruchet
---
arch/arm/boot/dts/stm32429i-eval.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 2bb8a0f..95c33b1 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -48,6 +48,7 @@
/dts-v1/;
#include "stm32f429.dtsi"
#include
+#include
/ {
model = "STMicroelectronics STM32429i-EVAL board";
@@ -66,6 +67,14 @@
serial0 = &usart1;
};
+ clocks {
+ clk_ext_camera: clk-ext-camera {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ };
+ };
+
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
@@ -146,6 +155,11 @@
port {
dcmi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
};
};
};
@@ -155,6 +169,22 @@
pinctrl-names = "default";
status = "okay";
+ ov2640: camera@30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ resetb-gpios = <&stmpegpio 2 GPIO_ACTIVE_HIGH>;
+ pwdn-gpios = <&stmpegpio 0 GPIO_ACTIVE_LOW>;
+ clocks = <&clk_ext_camera>;
+ clock-names = "xvclk";
+ status = "okay";
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&dcmi_0>;
+ };
+ };
+ };
+
stmpe1600: stmpe1600@42 {
compatible = "st,stmpe1600";
reg = <0x42>;
--
1.9.1
[PATCH v5 5/8] ARM: dts: stm32: Enable STMPE1600 gpio expander of STM32F429-EVAL board
Enable STMPE1600 gpio expander of STM32F429-EVAL board.
Signed-off-by: Hugues Fruchet
---
arch/arm/boot/dts/stm32429i-eval.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 617f2f7..2bb8a0f 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -154,6 +154,23 @@
pinctrl-0 = <&i2c1_pins>;
pinctrl-names = "default";
status = "okay";
+
+ stmpe1600: stmpe1600@42 {
+ compatible = "st,stmpe1600";
+ reg = <0x42>;
+ irq-gpio = <&gpioi 8 0>;
+ irq-trigger = <3>;
+ interrupts = <8 3>;
+ interrupt-parent = <&exti>;
+ interrupt-controller;
+ wakeup-source;
+
+ stmpegpio: stmpe_gpio {
+ compatible = "st,stmpe-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
};
&mac {
--
1.9.1
[PATCH v4 3/4] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks
To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.
We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 17 +
drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
include/media/vsp1.h | 7 +++
3 files changed, 35 insertions(+)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9d235e830f5a..84d0418660bf 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -36,6 +36,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
}
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+ struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+ if (drm->du_complete)
+ drm->du_complete(drm->du_private);
+}
+
/*
-
* DU Driver API
*/
@@ -95,6 +103,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct
vsp1_du_lif_config *cfg)
}
pipe->num_inputs = 0;
+ vsp1->drm->du_complete = NULL;
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -199,6 +208,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct
vsp1_du_lif_config *cfg)
if (ret < 0)
return ret;
+ /*
+* Register a callback to allow us to notify the DRM driver of frame
+* completion events.
+*/
+ vsp1->drm->du_complete = cfg->callback;
+ vsp1->drm->du_private = cfg->callback_data;
+
ret = media_pipeline_start(&pipe->output->entity.subdev.entity,
&pipe->pipe);
if (ret < 0) {
@@ -603,6 +619,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->lif = &vsp1->lif->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
+ pipe->frame_end = vsp1_du_pipeline_frame_end;
return 0;
}
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
b/drivers/media/platform/vsp1/vsp1_drm.h
index c8d2f88fc483..e9f80727ff92 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -23,6 +23,8 @@
* @num_inputs: number of active pipeline inputs at the beginning of an update
* @inputs: source crop rectangle, destination compose rectangle and z-order
* position for every input
+ * @du_complete: frame completion callback for the DU driver (optional)
+ * @du_private: data to be passed to the du_complete callback
*/
struct vsp1_drm {
struct vsp1_pipeline pipe;
@@ -33,8 +35,17 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+ /* Frame synchronisation */
+ void (*du_complete)(void *);
+ void *du_private;
};
+static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+ return container_of(pipe, struct vsp1_drm, pipe);
+}
+
int vsp1_drm_init(struct vsp1_device *vsp1);
void vsp1_drm_cleanup(struct vsp1_device *vsp1);
int vsp1_drm_create_links(struct vsp1_device *vsp1);
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 38aac554dbba..c135c47b4641 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -24,10 +24,17 @@ int vsp1_du_init(struct device *dev);
* struct vsp1_du_lif_config - VSP LIF configuration
* @width: output frame width
* @height: output frame height
+ * @callback: frame completion callback function (optional). When a callback
+ * is provided, the VSP driver guarantees that it will be called once
+ * and only once for each vsp1_du_atomic_flush() call.
+ * @callback_data: data to be passed to the frame completion callback
*/
struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
+
+ void (*callback)(void *);
+ void *callback_data;
};
int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config
*cfg);
--
git-series 0.9.1
[PATCH v4 4/4] drm: rcar-du: Register a completion callback with VSP1
Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.
Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 ++--
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 +
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5f0664bcd12d..345eff72f581 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -378,7 +378,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc
*rcrtc)
* Page Flip
*/
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
{
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -650,6 +650,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
{
struct rcar_du_crtc *rcrtc = arg;
+ struct rcar_du_device *rcdu = rcrtc->group->dev;
irqreturn_t ret = IRQ_NONE;
u32 status;
@@ -658,7 +659,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(&rcrtc->crtc);
- rcar_du_crtc_finish_page_flip(rcrtc);
+
+ if (rcdu->info->gen < 3)
+ rcar_du_crtc_finish_page_flip(rcrtc);
+
ret = IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 15871fae7445..b199ed5adf36 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -73,5 +73,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
void rcar_du_crtc_route_output(struct drm_crtc *crtc,
enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
#endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..c7bb96fbfab1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
#include "rcar_du_kms.h"
#include "rcar_du_vsp.h"
+static void rcar_du_vsp_complete(void *private)
+{
+ struct rcar_du_crtc *crtc = private;
+
+ rcar_du_crtc_finish_page_flip(crtc);
+}
+
void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
{
const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;
@@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+ .callback = rcar_du_vsp_complete,
+ .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
--
git-series 0.9.1
[PATCH v4 0/4] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines
The RCAR-DU utilises a running VSPD pipeline to perform processing for the display pipeline. This presents the opportunity for some race conditions to affect the quality of the display output. To prevent reporting page flips early, we must track this timing through the VSP1, and only allow the rcar-du object to report the page-flip completion event after the VSP1 has processed. This series ensures that tearing and flicker is prevented, without introducing any (substantial) performance impact. These patches have been tested by introducing artificial delays in the commit code paths and verifying that no visual tearing or flickering occurs. Extensive testing around the race window has been performed by dynamically adapting the artificial delay between 15, and 17 seconds in 100uS increments for periods of 5 seconds on each delay test. These tests have successfully run for 3 hours. Manual start/stop testing has also been performed. Mauro: As this patchset covers two subsystems, and the DRM/DU side is dependant upon the media/VSP side, If you are happy with these patches, Would it be possible to get acks from you for integration through the DRM tree please? Regards Kieran Kieran Bingham (3): v4l: vsp1: Postpone frame end handling in event of display list race v4l: vsp1: Extend VSP1 module API to allow DRM callbacks drm: rcar-du: Register a completion callback with VSP1 Laurent Pinchart (1): drm: rcar-du: Arm the page flip event after queuing the page flip drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 30 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 1 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 9 - drivers/media/platform/vsp1/vsp1_dl.c | 19 ++-- drivers/media/platform/vsp1/vsp1_dl.h | 2 +- drivers/media/platform/vsp1/vsp1_drm.c | 17 +++- drivers/media/platform/vsp1/vsp1_drm.h | 11 ++- drivers/media/platform/vsp1/vsp1_pipe.c | 13 ++- include/media/vsp1.h| 7 ++- 9 files changed, 92 insertions(+), 17 deletions(-) base-commit: 4df0f635a142c7498d20de9356851fb989c7f653 -- git-series 0.9.1
[PATCH v4 1/4] drm: rcar-du: Arm the page flip event after queuing the page flip
From: Laurent Pinchart
The page flip event is armed in the atomic begin handler, creating a
race condition with the frame end interrupt that could send the event
before the atomic operation actually completes. To avoid that, arm the
event in the atomic flush handler after queuing the page flip.
This change doesn't fully close the race window, as the frame end
interrupt could be generated before the page flip is committed to
hardware but only handled after the event is armed. However, the race
window is now much smaller.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 4ed6f2340af0..5f0664bcd12d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -581,17 +581,6 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc
*crtc,
struct drm_crtc_state *old_crtc_state)
{
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
- struct drm_device *dev = rcrtc->crtc.dev;
- unsigned long flags;
-
- if (crtc->state->event) {
- WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-
- spin_lock_irqsave(&dev->event_lock, flags);
- rcrtc->event = crtc->state->event;
- crtc->state->event = NULL;
- spin_unlock_irqrestore(&dev->event_lock, flags);
- }
if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
@@ -601,9 +590,20 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc
*crtc,
struct drm_crtc_state *old_crtc_state)
{
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+ struct drm_device *dev = rcrtc->crtc.dev;
+ unsigned long flags;
rcar_du_crtc_update_planes(rcrtc);
+ if (crtc->state->event) {
+ WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+ rcrtc->event = crtc->state->event;
+ crtc->state->event = NULL;
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+ }
+
if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_flush(rcrtc);
}
--
git-series 0.9.1
[PATCH v4 2/4] v4l: vsp1: Postpone frame end handling in event of display list race
If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.
In this event, we skip the pipeline completion callback handler so that
the pipeline will not mistakenly report frame completion to the user.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_dl.c | 19 +--
drivers/media/platform/vsp1/vsp1_dl.h | 2 +-
drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 7d8f37772b56..85fe2b4ae310 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -561,9 +561,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager
*dlm)
spin_unlock(&dlm->lock);
}
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+/**
+ * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
+ * @dlm: the display list manager
+ *
+ * Return true if the previous display list has completed at frame end, or
false
+ * if it has been delayed by one frame because the display list commit raced
+ * with the frame end interrupt. The function always returns true in header
mode
+ * as display list processing is then not continuous and races never occur.
+ */
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
struct vsp1_device *vsp1 = dlm->vsp1;
+ bool completed = false;
spin_lock(&dlm->lock);
@@ -575,8 +585,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
* perform any operation as there can't be any new display list queued
* in that case.
*/
- if (dlm->mode == VSP1_DL_MODE_HEADER)
+ if (dlm->mode == VSP1_DL_MODE_HEADER) {
+ completed = true;
goto done;
+ }
/*
* The UPD bit set indicates that the commit operation raced with the
@@ -594,6 +606,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
if (dlm->queued) {
dlm->active = dlm->queued;
dlm->queued = NULL;
+ completed = true;
}
/*
@@ -614,6 +627,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
done:
spin_unlock(&dlm->lock);
+
+ return completed;
}
/* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..6ec1380a10af 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
*vsp1,
void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
b/drivers/media/platform/vsp1/vsp1_pipe.c
index edebf3fa926f..e817623b84e0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -330,10 +330,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
{
+ bool completed;
+
if (pipe == NULL)
return;
- vsp1_dlm_irq_frame_end(pipe->output->dlm);
+ completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+ if (!completed) {
+ /*
+* If the DL commit raced with the frame end interrupt, the
+* commit ends up being postponed by one frame. Return
+* immediately without calling the pipeline's frame end handler
+* or incrementing the sequence number.
+*/
+ return;
+ }
if (pipe->hgo)
vsp1_hgo_frame_end(pipe->hgo);
--
git-series 0.9.1
Re: [PATCH v8 01/10] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing
On 05/05/2017 03:23 PM, Stanimir Varbanov wrote:
> Hi Hans,
>
> On 05/05/2017 02:34 PM, Hans Verkuil wrote:
>> On 04/28/17 11:13, Stanimir Varbanov wrote:
>>> Unfortunatly previous attempt to allow consumer drivers to
>>> use COMPILE_TEST option in Kconfig is not enough, because in the
>>> past the consumer drivers used 'depends on' Kconfig option but
>>> now they are using 'select' Kconfig option which means on non ARM
>>> arch'es compilation is triggered. Thus we need to move the ifdefery
>>> one level below by touching the private qcom_scm.h header.
>>>
>>> To: Andy Gross
>>> Cc: Stephen Boyd
>>> Cc: Bjorn Andersson
>>> Signed-off-by: Stanimir Varbanov
>>> ---
>>> drivers/firmware/Kconfig| 2 +-
>>> drivers/firmware/qcom_scm.h | 72
>>> ++---
>>> include/linux/qcom_scm.h| 32
>>> 3 files changed, 62 insertions(+), 44 deletions(-)
>>>
>>> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
>>> index 6e4ed5a9c6fd..480578c3691a 100644
>>> --- a/drivers/firmware/Kconfig
>>> +++ b/drivers/firmware/Kconfig
>>> @@ -204,7 +204,7 @@ config FW_CFG_SYSFS_CMDLINE
>>>
>>> config QCOM_SCM
>>> bool
>>> - depends on ARM || ARM64
>>> + depends on ARM || ARM64 || COMPILE_TEST
>>> select RESET_CONTROLLER
>>>
>>> config QCOM_SCM_32
>>> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
>>> index 9bea691f30fb..d2b5723afb3f 100644
>>> --- a/drivers/firmware/qcom_scm.h
>>> +++ b/drivers/firmware/qcom_scm.h
>>> @@ -12,6 +12,7 @@
>>> #ifndef __QCOM_SCM_INT_H
>>> #define __QCOM_SCM_INT_H
>>>
>>> +#if IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64)
>>
>> This is weird. Shouldn't this be:
>>
>> #if IS_ENABLED(CONFIG_QCOM_SCM)
>
> I think no, because if you take a look in the above hunk which adding
> COMPILE_TEST in the QCOM_SCM config the CONFIG_QCOM_SCM will be enabled
> if compile testing is selected for example on x86 build target.
My apologies, just ignore my comment. I missed that QCOM_SCM is automatically
configured and not manually.
This patch is fine.
Regards,
Hans
>
>>
>> If the code in the actual source only works for ARM, then that should be
>> handled in that source code, and not in this header IMHO.
>
> Do you mean adding #ifdef in the source file? IMO this will become a
> bigger mess.
>
>>
>> Regards,
>>
>> Hans
>>
>>> #define QCOM_SCM_SVC_BOOT 0x1
>>> #define QCOM_SCM_BOOT_ADDR 0x1
>>> #define QCOM_SCM_BOOT_ADDR_MC 0x11
>>> @@ -58,6 +59,66 @@ extern int __qcom_scm_pas_auth_and_reset(struct device
>>> *dev, u32 peripheral);
>>> extern int __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
>>> extern int __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
>>>
>>> +#define QCOM_SCM_SVC_MP0xc
>>> +#define QCOM_SCM_RESTORE_SEC_CFG 2
>>> +extern int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
>>> + u32 spare);
>>> +#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE3
>>> +#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT4
>>> +extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
>>> +size_t *size);
>>> +extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
>>> +u32 size, u32 spare);
>>> +#else
>>> +static inline int __qcom_scm_set_remote_state(struct device *dev, u32
>>> state,
>>> + u32 id)
>>> +{ return -ENODEV; }
>>> +static inline int __qcom_scm_set_warm_boot_addr(struct device *dev, void
>>> *entry,
>>> + const cpumask_t *cpus)
>>> +{ return -ENODEV; }
>>> +static inline int __qcom_scm_set_cold_boot_addr(void *entry,
>>> + const cpumask_t *cpus)
>>> +{ return -ENODEV; }
>>> +static inline void __qcom_scm_cpu_power_down(u32 flags) {}
>>> +static inline int __qcom_scm_is_call_available(struct device *dev, u32
>>> svc_id,
>>> + u32 cmd_id)
>>> +{ return -ENODEV; }
>>> +#define QCOM_SCM_SVC_HDCP 0x11
>>> +#define QCOM_SCM_CMD_HDCP 0x01
>>> +static inline int __qcom_scm_hdcp_req(struct device *dev,
>>> + struct qcom_scm_hdcp_req *req,
>>> + u32 req_cnt, u32 *resp)
>>> +{ return -ENODEV; }
>>> +static inline void __qcom_scm_init(void) {}
>>> +#define QCOM_SCM_SVC_PIL 0x2
>>> +#define QCOM_SCM_PAS_IS_SUPPORTED_CMD 0x7
>>> +static inline bool __qcom_scm_pas_supported(struct device *dev, u32
>>> peripheral)
>>> +{ return false; }
>>> +static inline int __qcom_scm_pas_init_image(struct device *dev, u32
>>> peripheral,
>>> +dma_addr_t metadata_phys)
>>> +{ return -ENODEV; }
>>> +static inline int __qcom_scm_pas_mem_setup(struct device
[PATCH] Staging: media: s5p-cec: Fixed spelling mistake
Fixed spelling mistake of "successfully" Signed-off-by: Rene Hickersberger --- drivers/staging/media/s5p-cec/s5p_cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c b/drivers/staging/media/s5p-cec/s5p_cec.c index 2a07968..7e9ace8 100644 --- a/drivers/staging/media/s5p-cec/s5p_cec.c +++ b/drivers/staging/media/s5p-cec/s5p_cec.c @@ -216,7 +216,7 @@ static int s5p_cec_probe(struct platform_device *pdev) platform_set_drvdata(pdev, cec); pm_runtime_enable(dev); - dev_dbg(dev, "successfuly probed\n"); + dev_dbg(dev, "successfully probed\n"); return 0; } -- 2.9.3
Re: [PATCH v8 00/10] Qualcomm video decoder/encoder driver
Hi Hans, On 05/05/2017 03:44 PM, Hans Verkuil wrote: > Hi Stanimir, > > It looks good to me. I do think that patch 01/10 shouldn't go through > media. This might mean that we have to drop the COMPILE_TEST dependency > on the media driver until this firmware driver patch gets merged, which > is fine with me as long as this is clearly stated in the commit log for > the media Kconfig. Let me know what you want to do with this. OK, the best I can do is to drop COMPILE_TEST for Venus driver in this patch set and work separately on qcom_scm firmware driver patching. Thus I will repost v9 version next week. > > I also saw some comments for patch 05/10, but I'm not sure if that would > block merging this driver or can be fixed afterwards. I will prefix the exported symbols from venus-core driver as pointed by Sakari in next v9 version plus fixes for few signed-unsigned compare warnings. -- regards, Stan
Re: [PATCH v8 05/10] media: venus: adding core part and helper functions
Hi Bjorn
On 05/02/2017 09:52 PM, Bjorn Andersson wrote:
> On Tue 02 May 01:52 PDT 2017, Stanimir Varbanov wrote:
>
>> Hei Sakari,
>>
>> On 04/30/2017 01:21 AM, Sakari Ailus wrote:
>>> Hi, Stan!!
>>>
>>> On Fri, Apr 28, 2017 at 12:13:52PM +0300, Stanimir Varbanov wrote:
>>> ...
+int helper_get_bufreq(struct venus_inst *inst, u32 type,
+struct hfi_buffer_requirements *req)
+{
+ u32 ptype = HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS;
+ union hfi_get_property hprop;
+ int ret, i;
>>>
>>> unsigned int i ? It's an array index...
>>
>> Thanks for pointing that out, I have to revisit all similar places as
>> well ...
>>
>
> It's perfectly fine to index an array with an int and you are comparing
> the index with a integer constant in the loop - so don't clutter the
> code unnecessarily.
I personally prefer unsigned for iterator variable type (because
unsigned type has defined behavior on overflow), but having the fact
that I'm comparing with int I will keep it int.
Also it seems that -Wsign-compare is not enabled by default in kernel,
no? So I have modified my Makefile and catch few occurrences of warnings
about signed with unsigned compare and fixed them.
--
regards,
Stan
Re: [PATCH v8 01/10] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing
Hi Hans,
On 05/05/2017 02:34 PM, Hans Verkuil wrote:
> On 04/28/17 11:13, Stanimir Varbanov wrote:
>> Unfortunatly previous attempt to allow consumer drivers to
>> use COMPILE_TEST option in Kconfig is not enough, because in the
>> past the consumer drivers used 'depends on' Kconfig option but
>> now they are using 'select' Kconfig option which means on non ARM
>> arch'es compilation is triggered. Thus we need to move the ifdefery
>> one level below by touching the private qcom_scm.h header.
>>
>> To: Andy Gross
>> Cc: Stephen Boyd
>> Cc: Bjorn Andersson
>> Signed-off-by: Stanimir Varbanov
>> ---
>> drivers/firmware/Kconfig| 2 +-
>> drivers/firmware/qcom_scm.h | 72
>> ++---
>> include/linux/qcom_scm.h| 32
>> 3 files changed, 62 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
>> index 6e4ed5a9c6fd..480578c3691a 100644
>> --- a/drivers/firmware/Kconfig
>> +++ b/drivers/firmware/Kconfig
>> @@ -204,7 +204,7 @@ config FW_CFG_SYSFS_CMDLINE
>>
>> config QCOM_SCM
>> bool
>> -depends on ARM || ARM64
>> +depends on ARM || ARM64 || COMPILE_TEST
>> select RESET_CONTROLLER
>>
>> config QCOM_SCM_32
>> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
>> index 9bea691f30fb..d2b5723afb3f 100644
>> --- a/drivers/firmware/qcom_scm.h
>> +++ b/drivers/firmware/qcom_scm.h
>> @@ -12,6 +12,7 @@
>> #ifndef __QCOM_SCM_INT_H
>> #define __QCOM_SCM_INT_H
>>
>> +#if IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64)
>
> This is weird. Shouldn't this be:
>
> #if IS_ENABLED(CONFIG_QCOM_SCM)
I think no, because if you take a look in the above hunk which adding
COMPILE_TEST in the QCOM_SCM config the CONFIG_QCOM_SCM will be enabled
if compile testing is selected for example on x86 build target.
>
> If the code in the actual source only works for ARM, then that should be
> handled in that source code, and not in this header IMHO.
Do you mean adding #ifdef in the source file? IMO this will become a
bigger mess.
>
> Regards,
>
> Hans
>
>> #define QCOM_SCM_SVC_BOOT 0x1
>> #define QCOM_SCM_BOOT_ADDR 0x1
>> #define QCOM_SCM_BOOT_ADDR_MC 0x11
>> @@ -58,6 +59,66 @@ extern int __qcom_scm_pas_auth_and_reset(struct device
>> *dev, u32 peripheral);
>> extern int __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
>> extern int __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
>>
>> +#define QCOM_SCM_SVC_MP 0xc
>> +#define QCOM_SCM_RESTORE_SEC_CFG2
>> +extern int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
>> + u32 spare);
>> +#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE 3
>> +#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT 4
>> +extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
>> + size_t *size);
>> +extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
>> + u32 size, u32 spare);
>> +#else
>> +static inline int __qcom_scm_set_remote_state(struct device *dev, u32 state,
>> + u32 id)
>> +{ return -ENODEV; }
>> +static inline int __qcom_scm_set_warm_boot_addr(struct device *dev, void
>> *entry,
>> +const cpumask_t *cpus)
>> +{ return -ENODEV; }
>> +static inline int __qcom_scm_set_cold_boot_addr(void *entry,
>> +const cpumask_t *cpus)
>> +{ return -ENODEV; }
>> +static inline void __qcom_scm_cpu_power_down(u32 flags) {}
>> +static inline int __qcom_scm_is_call_available(struct device *dev, u32
>> svc_id,
>> + u32 cmd_id)
>> +{ return -ENODEV; }
>> +#define QCOM_SCM_SVC_HDCP 0x11
>> +#define QCOM_SCM_CMD_HDCP 0x01
>> +static inline int __qcom_scm_hdcp_req(struct device *dev,
>> + struct qcom_scm_hdcp_req *req,
>> + u32 req_cnt, u32 *resp)
>> +{ return -ENODEV; }
>> +static inline void __qcom_scm_init(void) {}
>> +#define QCOM_SCM_SVC_PIL0x2
>> +#define QCOM_SCM_PAS_IS_SUPPORTED_CMD 0x7
>> +static inline bool __qcom_scm_pas_supported(struct device *dev, u32
>> peripheral)
>> +{ return false; }
>> +static inline int __qcom_scm_pas_init_image(struct device *dev, u32
>> peripheral,
>> + dma_addr_t metadata_phys)
>> +{ return -ENODEV; }
>> +static inline int __qcom_scm_pas_mem_setup(struct device *dev, u32
>> peripheral,
>> +phys_addr_t addr, phys_addr_t size)
>> +{ return -ENODEV; }
>> +static inline int __qcom_scm_pas_auth_and_reset(struct device *dev,
>> + u32 peripheral)
>> +{ return -ENODEV; }
>> +static i
Re: [PATCH 6/8] omapdrm: hdmi4: refcount hdmi_power_on/off_core
On 04/28/17 13:30, Tomi Valkeinen wrote:
> On 14/04/17 13:25, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> The hdmi_power_on/off_core functions can be called multiple times:
>> when the HPD changes and when the HDMI CEC support needs to power
>> the HDMI core.
>>
>> So use a counter to know when to really power on or off the HDMI core.
>>
>> Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to
>> power up the HDMI core (needed for CEC).
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> index 4a164dc01f15..e371b47ff6ff 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
>> @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device
>> *dssdev)
>> {
>> int r;
>>
>> +if (hdmi.core.core_pwr_cnt++)
>> +return 0;
>> +
>
> How's the locking between the CEC side and the DRM side? Normally these
> functions are protected with the DRM modesetting locks, but CEC doesn't
> come from there. We have the hdmi.lock, did you check that it's held
> when CEC side calls shared functions?
Yes, the hdmi_power_on/off_core functions are all called from other functions
with the hdmi.lock taken. The CEC code calls those higher level functions
(hdmi4_core_enable/disable).
>
>> r = regulator_enable(hdmi.vdda_reg);
>> if (r)
>> -return r;
>> +goto err_reg_enable;
>>
>> r = hdmi_runtime_get();
>> if (r)
>> goto err_runtime_get;
>>
>> +hdmi4_core_powerdown_disable(&hdmi.core);
>
> I'd like to have the powerdown_disable as a separate patch.
Will do.
> Also, now
> that you call it here, I believe it can be dropped from hdmi4_configure().
I was a bit scared of messing with that function. But if you say it can
be removed, then who am I to argue? :-)
>
> Hmm, but in hdmi4_configure we call hdmi_core_swreset_assert() before
> hdmi4_core_powerdown_disable(). I wonder what exactly that does, and
> whether we end up resetting also the CEC parts when we change the videomode.
Good one. I'll attempt to check this.
Regards,
Hans
>
> Tomi
>
Re: [V1] staging : media : fixed macro expansion error
> #define DEFINE_SYSFS_PROPERTY(prop, signal, size, mask, check) > \ > -property_write(prop, signal size, mask, check) > \ > -property_read(prop, size, mask) > +(property_write(prop, signal size, mask, check) > \ > +property_read(prop, size, mask)) breaks the build. regards, dan carpenter
[GIT PULL for v4.12-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.12-1 For: - New driver to support mediatek jpeg in hardware codec; - rc-lirc, s5p-cec and st-cec staging drivers got promoted; - Hardware histogram support for vsp1 driver; - added Virtual Media Controller driver, to make easier to test the media controller; - added a new CEC driver (rainshadow-cec); - Removed two staging LIRC drivers for obscure hardware that are too obsolete; - Added support for Intel SR300 Depth camera; - Some improvements at CEC and RC core; - Lots of driver cleanups, improvements all over the tree. With this series, we're finally getting rid of the LIRC staging driver. There's just one left (lirc_zilog), with require more care, as part of its functionality (IR RX) is already provided by another driver. Work in progress to convert it on the proper way. Thanks! Mauro - The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf: Linux 4.11-rc5 (2017-04-02 17:23:54 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.12-1 for you to fetch changes up to 3622d3e77ecef090b5111e3c5423313f11711dfa: [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 -0300) media updates for v4.12-rc1 Alexandre-Xavier Labonté-Lamoureux (1): [media] em28xx: Add new USB ID eb1a:5051 Alexey Khoroshilov (1): [media] m2m-deinterlace: don't return zero on failure paths in deinterlace_probe() Alyssa Milburn (4): [media] digitv: limit messages to buffer size [media] zr364xx: enforce minimum size when reading header [media] ttusb2: limit messages to buffer size [media] dw2102: limit messages to buffer size Anton Leontiev (1): [media] vb2: Fix queue_setup() callback description Anton Sviridenko (1): [media] solo6x10: release vb2 buffers in solo_stop_streaming() Antti Palosaari (4): [media] mn88472: implement signal strength statistics [media] mn88472: implement cnr statistics [media] mn88472: implement PER statistics [media] si2157: revert si2157: Si2141/2151 tuner support Arnd Bergmann (7): [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze() [media] cx231xx-i2c: reduce stack size in bus scan [media] mxl111sf: reduce stack usage in init function [media] tc358743: fix register i2c_rd/wr functions [media] coda/imx-vdoa: platform_driver should not be const [media] tw5864: use dev_warn instead of WARN to shut up warning [media] vcodec: mediatek: mark pm functions as __maybe_unused Arushi Singhal (1): [media] staging: media: omap4iss: Replace a bit shift by a use of BIT Avraham Shukron (2): [media] staging: omap4iss: fix multiline comment style [media] staging: omap4iss: fix coding style issue Bartosz Golaszewski (3): [media] media: vpif: use a configurable i2c_adapter_id for vpif display [media] media: dt-bindings: vpif: fix whitespace errors [media] media: dt-bindings: vpif: extend the example with an output port Baruch Siach (1): [media] doc: kapi: fix typo Ben Hutchings (1): [media] dvb-usb-dibusb-mc-common: Add MODULE_LICENSE Benjamin Gaignard (4): [media] sti: hdmi: add CEC notifier support [media] stih-cec.txt: document new hdmi phandle [media] stih-cec: add CEC notifier support [media] ARM: dts: STiH410: update sti-cec for CEC notifier support Benoit Parrot (2): [media] media: ti-vpe: vpdma: add support for user specified stride [media] media: ti-vpe: vpe: allow use of user specified stride Bhumika Goyal (6): [media] media: i2c: soc_camera: constify v4l2_subdev_* structures [media] b2c2: constify nxt200x_config structure [media] saa7134: constify nxt200x_config structures [media] cx88: constify mb86a16_config structure [media] pci: mantis: constify mb86a16_config structure [media] media: pci: constify stv0299_config structures Christophe JAILLET (2): [media] s5p-g2d: Fix error handling [media] tm6000: Fix resource freeing in 'tm6000_prepare_isoc()' Colin Ian King (5): [media] atmel-isc: fix off-by-one comparison and out of bounds read issue [media] usb: au0828: remove redundant code [media] coda: remove redundant call to v4l2_m2m_get_vq [media] Staging: media/lirc: don't call put_ir_rx on rx twice [media] xc5000: fix spelling mistake: "calibration" Daniel Patrick Johnson (1): [media] uvcvideo: Add support for Intel SR300 depth camera Daniel Scheller (2): [media] dvb-frontends/drxk: don't log errors on unsupported operation mode [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops Derek
[V1] staging : media : fixed macro expansion error
enclosing complex macro expansion with parentheses is meaningfull according kernel coding style Signed-off-by: Surender Polsani --- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c b/drivers/staging/media/bcm2048/radio-bcm2048.c index 375c617..b9cafbb 100644 --- a/drivers/staging/media/bcm2048/radio-bcm2048.c +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c @@ -2001,8 +2001,8 @@ static irqreturn_t bcm2048_handler(int irq, void *dev) } #define DEFINE_SYSFS_PROPERTY(prop, signal, size, mask, check) \ -property_write(prop, signal size, mask, check) \ -property_read(prop, size, mask) +(property_write(prop, signal size, mask, check) \ +property_read(prop, size, mask)) #define property_str_read(prop, size) \ static ssize_t bcm2048_##prop##_read(struct device *dev, \ -- 1.9.1
Re: [PATCH 1/6] drm: Add writeback connector type
On Fri, May 05, 2017 at 10:22:19AM +0200, Boris Brezillon wrote: > On Fri, 25 Nov 2016 16:48:59 + > Brian Starkey wrote: > > > +/** > > + * drm_writeback_connector_init - Initialize a writeback connector and its > > properties > > + * @dev: DRM device > > + * @wb_connector: Writeback connector to initialize > > + * @funcs: Connector funcs vtable > > + * @formats: Array of supported pixel formats for the writeback engine > > + * @n_formats: Length of the formats array > > + * > > + * This function creates the writeback-connector-specific properties if > > they > > + * have not been already created, initializes the connector as > > + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the > > property > > + * values. > > + * > > + * Drivers should always use this function instead of drm_connector_init() > > to > > + * set up writeback connectors. > > + * > > + * Returns: 0 on success, or a negative error code > > + */ > > +int drm_writeback_connector_init(struct drm_device *dev, > > +struct drm_writeback_connector *wb_connector, > > +const struct drm_connector_funcs *funcs, > > +u32 *formats, int n_formats) > > This should probably be 'const u32 *formats', since developers are > likely to define a this array with a 'static const' specifier in their > driver. Fixed in the v4. Thanks, Liviu -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v8 00/10] Qualcomm video decoder/encoder driver
Hi Stanimir, It looks good to me. I do think that patch 01/10 shouldn't go through media. This might mean that we have to drop the COMPILE_TEST dependency on the media driver until this firmware driver patch gets merged, which is fine with me as long as this is clearly stated in the commit log for the media Kconfig. Let me know what you want to do with this. I also saw some comments for patch 05/10, but I'm not sure if that would block merging this driver or can be fixed afterwards. Regards, Hans On 04/28/17 11:13, Stanimir Varbanov wrote: > Hi everyone, > > The changes since v7 are: > * fixed error path in recovery handler. > * fixed the logic in helper_vb2_buf_prepare. > * added comments over venus_format arrays why MPLANE formats are used. > * added sequence for output queue as well. > * added COMPILE_TEST Kconfig option for the venus driver. To make > compile testing of the venus driver possible I had to create a patch > 01/10 which fixing the qcom SCM driver. > > I have made various fixes and improvements of the decoder and encoder > to make them work on Venus hw versions 1xx & 3xx (Venus hw v.1xx is found > on SoC apq8016 / db410c SBC board, and Venus hw v.3xx on apq8096). > A brief of the changes: > * implemented buffer reference handling. This is adding delayed process > of the newly queued buffers until the firmware release them completely. > With this in place now vidioc_create_bufs op works properly. > * implemented vidioc_try_decoder_cmd and vidioc_decoder_cmd v4l2 ioctl > ops. > * cleanups and run checkpatch --strict > > The patchset is based on next-20170426 and applies cleanly on media_tree > as well. > > The report of v4l2-compliance is below patchset diff status. > > regards, > Stan > > Stanimir Varbanov (10): > firmware: qcom_scm: Fix to allow COMPILE_TEST-ing > media: v4l2-mem2mem: extend m2m APIs for more accurate buffer > management > doc: DT: venus: binding document for Qualcomm video driver > MAINTAINERS: Add Qualcomm Venus video accelerator driver > media: venus: adding core part and helper functions > media: venus: vdec: add video decoder files > media: venus: venc: add video encoder files > media: venus: hfi: add Host Firmware Interface (HFI) > media: venus: hfi: add Venus HFI files > media: venus: enable building of Venus video driver > > .../devicetree/bindings/media/qcom,venus.txt | 107 ++ > MAINTAINERS|8 + > drivers/firmware/Kconfig |2 +- > drivers/firmware/qcom_scm.h| 72 +- > drivers/media/platform/Kconfig | 13 + > drivers/media/platform/Makefile|2 + > drivers/media/platform/qcom/venus/Makefile | 11 + > drivers/media/platform/qcom/venus/core.c | 388 + > drivers/media/platform/qcom/venus/core.h | 323 > drivers/media/platform/qcom/venus/firmware.c | 107 ++ > drivers/media/platform/qcom/venus/firmware.h | 22 + > drivers/media/platform/qcom/venus/helpers.c| 725 + > drivers/media/platform/qcom/venus/helpers.h| 44 + > drivers/media/platform/qcom/venus/hfi.c| 522 +++ > drivers/media/platform/qcom/venus/hfi.h| 175 +++ > drivers/media/platform/qcom/venus/hfi_cmds.c | 1255 > drivers/media/platform/qcom/venus/hfi_cmds.h | 304 > drivers/media/platform/qcom/venus/hfi_helper.h | 1050 + > drivers/media/platform/qcom/venus/hfi_msgs.c | 1056 + > drivers/media/platform/qcom/venus/hfi_msgs.h | 283 > drivers/media/platform/qcom/venus/hfi_venus.c | 1571 > > drivers/media/platform/qcom/venus/hfi_venus.h | 23 + > drivers/media/platform/qcom/venus/hfi_venus_io.h | 113 ++ > drivers/media/platform/qcom/venus/vdec.c | 1152 ++ > drivers/media/platform/qcom/venus/vdec.h | 23 + > drivers/media/platform/qcom/venus/vdec_ctrls.c | 149 ++ > drivers/media/platform/qcom/venus/venc.c | 1281 > drivers/media/platform/qcom/venus/venc.h | 23 + > drivers/media/platform/qcom/venus/venc_ctrls.c | 269 > drivers/media/v4l2-core/v4l2-mem2mem.c | 37 + > include/linux/qcom_scm.h | 32 - > include/media/v4l2-mem2mem.h | 92 ++ > 32 files changed, 11190 insertions(+), 44 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt > create mode 100644 drivers/media/platform/qcom/venus/Makefile > create mode 100644 drivers/media/platform/qcom/venus/core.c > create mode 100644 drivers/media/platform/qcom/venus/core.h > create mode 100644 drivers/media/platform/qcom/venus/firmware.c > create mode 100644 drivers/media/platform/qcom/venus/firmware.h > create mode 1006
Re: [PATCH v4 0/7] Add V4L2 SDR (DRIF & MAX2175) driver
Hi Ramesh, Looks good. I replied to patch 3/7 requesting a small change, but otherwise I'm OK. The only thing missing is an Ack from Rob for patch 6/7 (R-car DRIF bindings). Once I have that + an updated patch 3/7 I can make a pull request for this. Regards, Hans On 05/02/17 15:26, Ramesh Shanmugasundaram wrote: > Hi Media, DT maintainers, All, > > This patch set contains two drivers > - Renesas R-Car Digital Radio Interface (DRIF) driver > - Maxim's MAX2175 RF to Bits tuner driver > > These patches were based on top of media-next repo > commit:6d95b3f24881c0fd0f345eca959a2a803a040930 > > These two drivers combined together expose a V4L2 SDR device that is > compliant with the V4L2 framework [1]. Agreed review comments are > incorporated in this series. > > The rcar_drif device is modelled using "renesas,bonding" property. The > discussion on this property is available here [2]. > > Change history: > > v3 -> v4: > - Added ACKs > rcar_drif: > - Incorporated a number of review comments from Laurent on DRIF driver. > - Addressed comments from Rob and Laurent on bindings. > max2175: > - Minor changes addressing Hans and Laurent's comments > > v2 -> v3: > rcar_drif: > - Reduced DRIF DT properties to expose tested I2S mode only (Hans - > discussion on #v4l) > - Fixed error path clean up of ctrl_hdl on rcar_drif > > v1 -> v2: > - SDR formats renamed as "planar" instead of sliced (Hans) > - Documentation formatting correction (Laurent) > > rcar_drif: > - DT model using "bonding" property > - Addressed Laurent's coments on bindings - DT optional parameters rename & > rework > - Addressed Han's comments on driver > - Addressed Geert's comments on DT > > max2175: > - Avoided scaling using method proposed by Antti. Thanks > - Bindings is a separate patch (Rob) > - Addressed Rob's comment on bindings > - Added Custom controls documentation (Laurent) > > [1] v4l2-compliance report: > root@salvator-x:~# v4l2-compliance -S /dev/swradio0 > v4l2-compliance SHA : b514d615166bdc0901a4c71261b87db31e89f464 > > Driver Info: > Driver name : rcar_drif > Card type : R-Car DRIF > Bus info : platform:R-Car DRIF > Driver version: 4.11.0 > Capabilities : 0x8531 > SDR Capture > Tuner > Read/Write > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0531 > SDR Capture > Tuner > Read/Write > Streaming > Extended Pix Format > > Compliance test for device /dev/swradio0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second sdr open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK > test VIDIOC_G/S_FREQUENCY: OK > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 0 Audio Inputs: 0 Tuners: 1 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 5 Private Controls: 3 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > test Scaling: OK (Not Suppo
Re: [PATCH v4 3/7] media: i2c: max2175: Add MAX2175 support
On 05/02/17 15:26, Ramesh Shanmugasundaram wrote: > This patch adds driver support for the MAX2175 chip. This is Maxim > Integrated's RF to Bits tuner front end chip designed for software-defined > radio solutions. This driver exposes the tuner as a sub-device instance > with standard and custom controls to configure the device. > > Signed-off-by: Ramesh Shanmugasundaram > > --- > v4: > - Addressed v4l2_ctrl name string convention (Hans) > - "HSLS above/below" to "HSLS Above/Below" > - "RX MODE" to "RX Mode" > --- > Documentation/media/v4l-drivers/index.rst |1 + > Documentation/media/v4l-drivers/max2175.rst | 60 ++ > drivers/media/i2c/Kconfig |4 + > drivers/media/i2c/Makefile |2 + > drivers/media/i2c/max2175/Kconfig |8 + > drivers/media/i2c/max2175/Makefile |4 + > drivers/media/i2c/max2175/max2175.c | 1437 > +++ > drivers/media/i2c/max2175/max2175.h | 108 ++ > 8 files changed, 1624 insertions(+) > create mode 100644 Documentation/media/v4l-drivers/max2175.rst > create mode 100644 drivers/media/i2c/max2175/Kconfig > create mode 100644 drivers/media/i2c/max2175/Makefile > create mode 100644 drivers/media/i2c/max2175/max2175.c > create mode 100644 drivers/media/i2c/max2175/max2175.h > > diff --git a/Documentation/media/v4l-drivers/index.rst > b/Documentation/media/v4l-drivers/index.rst > index a606d1cdac13..d8cade53d496 100644 > --- a/Documentation/media/v4l-drivers/index.rst > +++ b/Documentation/media/v4l-drivers/index.rst > @@ -42,6 +42,7 @@ For more details see the file COPYING in the source > distribution of Linux. > davinci-vpbe > fimc > ivtv > +max2175 > meye > omap3isp > omap4_camera > diff --git a/Documentation/media/v4l-drivers/max2175.rst > b/Documentation/media/v4l-drivers/max2175.rst > new file mode 100644 > index ..201af8f217e9 > --- /dev/null > +++ b/Documentation/media/v4l-drivers/max2175.rst > @@ -0,0 +1,60 @@ > +Maxim Integrated MAX2175 RF to bits tuner driver > + > + > +The MAX2175 driver implements the following driver-specific controls: > + > +``V4L2_CID_MAX2175_I2S_ENABLE`` > +--- > +Enable/Disable I2S output of the tuner. > + > +.. flat-table:: > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 4 > + > +* - ``(0)`` > + - I2S output is disabled. > +* - ``(1)`` > + - I2S output is enabled. > + > +``V4L2_CID_MAX2175_HSLS`` > +- > +The high-side/low-side (HSLS) control of the tuner for a given band. > + > +.. flat-table:: > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 4 > + > +* - ``(0)`` > + - The LO frequency position is below the desired frequency. > +* - ``(1)`` > + - The LO frequency position is above the desired frequency. > + > +``V4L2_CID_MAX2175_RX_MODE (menu)`` > +--- > +The Rx mode controls a number of preset parameters of the tuner like sck 'sck' is short of 'sample clock' or something like that? I recommend that you write this in full at least once in this documentation. > +rate, sampling rate etc. These multiple settings are provided under one > +single label called Rx mode in the datasheet. The list below shows the > +supported modes with a brief description. > + > +.. flat-table:: > +:header-rows: 0 > +:stub-columns: 0 > +:widths: 1 4 > + > +* - ``"Europe modes"`` > +* - ``"FM 1.2" (0)`` > + - This configures FM band with a sample rate of 0.512 million > +samples/sec with a 10.24 MHz sck. > +* - ``"DAB 1.2" (1)`` > + - This configures VHF band with a sample rate of 2.048 million > +samples/sec with a 32.768 MHz sck. > + > +* - ``"North America modes"`` > +* - ``"FM 1.0" (0)`` > + - This configures FM band with a sample rate of 0.7441875 million > +samples/sec with a 14.88375 MHz sck. > +* - ``"DAB 1.2" (1)`` > + - This configures FM band with a sample rate of 0.372 million > +samples/sec with a 7.441875 MHz sck. Regards, Hans
Re: [PATCH v8 02/10] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management
On 04/28/17 11:13, Stanimir Varbanov wrote:
> this add functions for:
> - remove buffers from src/dst queue by index
> - remove exact buffer from src/dst queue
>
> also extends m2m API to iterate over a list of src/dst buffers
> in safely and non-safely manner.
>
> Signed-off-by: Stanimir Varbanov
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/media/v4l2-core/v4l2-mem2mem.c | 37 ++
> include/media/v4l2-mem2mem.h | 92
> ++
> 2 files changed, 129 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> b/drivers/media/v4l2-core/v4l2-mem2mem.c
> index 6bc27e7b2a33..f62e68aa04c4 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> @@ -126,6 +126,43 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx
> *q_ctx)
> }
> EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove);
>
> +void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
> + struct vb2_v4l2_buffer *vbuf)
> +{
> + struct v4l2_m2m_buffer *b;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&q_ctx->rdy_spinlock, flags);
> + b = container_of(vbuf, struct v4l2_m2m_buffer, vb);
> + list_del(&b->list);
> + q_ctx->num_rdy--;
> + spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_buf);
> +
> +struct vb2_v4l2_buffer *
> +v4l2_m2m_buf_remove_by_idx(struct v4l2_m2m_queue_ctx *q_ctx, unsigned int
> idx)
> +
> +{
> + struct v4l2_m2m_buffer *b, *tmp;
> + struct vb2_v4l2_buffer *ret = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&q_ctx->rdy_spinlock, flags);
> + list_for_each_entry_safe(b, tmp, &q_ctx->rdy_queue, list) {
> + if (b->vb.vb2_buf.index == idx) {
> + list_del(&b->list);
> + q_ctx->num_rdy--;
> + ret = &b->vb;
> + break;
> + }
> + }
> + spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_idx);
> +
> /*
> * Scheduling handlers
> */
> diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
> index 3ccd01bd245e..e157d5c9b224 100644
> --- a/include/media/v4l2-mem2mem.h
> +++ b/include/media/v4l2-mem2mem.h
> @@ -437,6 +437,47 @@ static inline void *v4l2_m2m_next_dst_buf(struct
> v4l2_m2m_ctx *m2m_ctx)
> }
>
> /**
> + * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready
> + * buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + * @b: current buffer of type struct v4l2_m2m_buffer
> + */
> +#define v4l2_m2m_for_each_dst_buf(m2m_ctx, b)\
> + list_for_each_entry(b, &m2m_ctx->cap_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_src_buf() - iterate over a list of source ready buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + * @b: current buffer of type struct v4l2_m2m_buffer
> + */
> +#define v4l2_m2m_for_each_src_buf(m2m_ctx, b)\
> + list_for_each_entry(b, &m2m_ctx->out_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_dst_buf_safe() - iterate over a list of destination
> ready
> + * buffers safely
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + * @b: current buffer of type struct v4l2_m2m_buffer
> + * @n: used as temporary storage
> + */
> +#define v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, b, n)\
> + list_for_each_entry_safe(b, n, &m2m_ctx->cap_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_src_buf_safe() - iterate over a list of source ready
> + * buffers safely
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + * @b: current buffer of type struct v4l2_m2m_buffer
> + * @n: used as temporary storage
> + */
> +#define v4l2_m2m_for_each_src_buf_safe(m2m_ctx, b, n)\
> + list_for_each_entry_safe(b, n, &m2m_ctx->out_q_ctx.rdy_queue, list)
> +
> +/**
> * v4l2_m2m_get_src_vq() - return vb2_queue for source buffers
> *
> * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> @@ -488,6 +529,57 @@ static inline void *v4l2_m2m_dst_buf_remove(struct
> v4l2_m2m_ctx *m2m_ctx)
> return v4l2_m2m_buf_remove(&m2m_ctx->cap_q_ctx);
> }
>
> +/**
> + * v4l2_m2m_buf_remove_by_buf() - take off exact buffer from the list of
> ready
> + * buffers
> + *
> + * @q_ctx: pointer to struct @v4l2_m2m_queue_ctx
> + * @vbuf: the buffer to be removed
> + */
> +void v4l2_m2m_buf_remove_by_buf(struct v4l2_m2m_queue_ctx *q_ctx,
> + struct vb2_v4l2_buffer *vbuf);
> +
> +/**
> + * v4l2_m2m_src_buf_remove_by_buf() - take off exact source buffer from the
> list
> + * of ready buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance give
Re: [PATCH v8 01/10] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing
On 04/28/17 11:13, Stanimir Varbanov wrote:
> Unfortunatly previous attempt to allow consumer drivers to
> use COMPILE_TEST option in Kconfig is not enough, because in the
> past the consumer drivers used 'depends on' Kconfig option but
> now they are using 'select' Kconfig option which means on non ARM
> arch'es compilation is triggered. Thus we need to move the ifdefery
> one level below by touching the private qcom_scm.h header.
>
> To: Andy Gross
> Cc: Stephen Boyd
> Cc: Bjorn Andersson
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/firmware/Kconfig| 2 +-
> drivers/firmware/qcom_scm.h | 72
> ++---
> include/linux/qcom_scm.h| 32
> 3 files changed, 62 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 6e4ed5a9c6fd..480578c3691a 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -204,7 +204,7 @@ config FW_CFG_SYSFS_CMDLINE
>
> config QCOM_SCM
> bool
> - depends on ARM || ARM64
> + depends on ARM || ARM64 || COMPILE_TEST
> select RESET_CONTROLLER
>
> config QCOM_SCM_32
> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
> index 9bea691f30fb..d2b5723afb3f 100644
> --- a/drivers/firmware/qcom_scm.h
> +++ b/drivers/firmware/qcom_scm.h
> @@ -12,6 +12,7 @@
> #ifndef __QCOM_SCM_INT_H
> #define __QCOM_SCM_INT_H
>
> +#if IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64)
This is weird. Shouldn't this be:
#if IS_ENABLED(CONFIG_QCOM_SCM)
If the code in the actual source only works for ARM, then that should be
handled in that source code, and not in this header IMHO.
Regards,
Hans
> #define QCOM_SCM_SVC_BOOT0x1
> #define QCOM_SCM_BOOT_ADDR 0x1
> #define QCOM_SCM_BOOT_ADDR_MC0x11
> @@ -58,6 +59,66 @@ extern int __qcom_scm_pas_auth_and_reset(struct device
> *dev, u32 peripheral);
> extern int __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
> extern int __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
>
> +#define QCOM_SCM_SVC_MP 0xc
> +#define QCOM_SCM_RESTORE_SEC_CFG 2
> +extern int __qcom_scm_restore_sec_cfg(struct device *dev, u32 device_id,
> + u32 spare);
> +#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE 3
> +#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT 4
> +extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
> + size_t *size);
> +extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
> + u32 size, u32 spare);
> +#else
> +static inline int __qcom_scm_set_remote_state(struct device *dev, u32 state,
> + u32 id)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_set_warm_boot_addr(struct device *dev, void
> *entry,
> + const cpumask_t *cpus)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_set_cold_boot_addr(void *entry,
> + const cpumask_t *cpus)
> +{ return -ENODEV; }
> +static inline void __qcom_scm_cpu_power_down(u32 flags) {}
> +static inline int __qcom_scm_is_call_available(struct device *dev, u32
> svc_id,
> +u32 cmd_id)
> +{ return -ENODEV; }
> +#define QCOM_SCM_SVC_HDCP0x11
> +#define QCOM_SCM_CMD_HDCP0x01
> +static inline int __qcom_scm_hdcp_req(struct device *dev,
> + struct qcom_scm_hdcp_req *req,
> + u32 req_cnt, u32 *resp)
> +{ return -ENODEV; }
> +static inline void __qcom_scm_init(void) {}
> +#define QCOM_SCM_SVC_PIL 0x2
> +#define QCOM_SCM_PAS_IS_SUPPORTED_CMD0x7
> +static inline bool __qcom_scm_pas_supported(struct device *dev, u32
> peripheral)
> +{ return false; }
> +static inline int __qcom_scm_pas_init_image(struct device *dev, u32
> peripheral,
> + dma_addr_t metadata_phys)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_pas_mem_setup(struct device *dev, u32
> peripheral,
> + phys_addr_t addr, phys_addr_t size)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_pas_auth_and_reset(struct device *dev,
> + u32 peripheral)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_pas_shutdown(struct device *dev, u32
> peripheral)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
> +{ return -ENODEV; }
> +static inline int __qcom_scm_restore_sec_cfg(struct device *dev, u32
> device_id,
> + u32 spare)
> +{ return -ENODEV; }
> +extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spa
Re: [PATCH v4 2/8] [media] stm32-dcmi: STM32 DCMI camera interface driver
Hi Hugues,
I found a few small things that should be fixed first. It should all be
easy and quick to fix.
On 04/20/17 18:07, Hugues Fruchet wrote:
> This V4L2 subdev driver enables Digital Camera Memory Interface (DCMI)
> of STMicroelectronics STM32 SoC series.
>
> Reviewed-by: Hans Verkuil
> Signed-off-by: Yannick Fertre
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/platform/Kconfig| 12 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/stm32/Makefile |1 +
> drivers/media/platform/stm32/stm32-dcmi.c | 1419
> +
> 4 files changed, 1434 insertions(+)
> create mode 100644 drivers/media/platform/stm32/Makefile
> create mode 100644 drivers/media/platform/stm32/stm32-dcmi.c
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c
> b/drivers/media/platform/stm32/stm32-dcmi.c
> new file mode 100644
> index 000..0ed3bd9
> --- /dev/null
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -0,0 +1,1419 @@
...
> +static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> +{
> + struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
> + struct dcmi_buf *buf, *node;
> + u32 val;
> + int ret;
> +
> + /* Enable stream on the sub device */
> + ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
> + if (ret && ret != -ENOIOCTLCMD) {
> + dev_err(dcmi->dev, "%s: Failed to start streaming, subdev
> streamon error",
> + __func__);
> + goto err_release_buffers;
> + }
> +
> + if (clk_enable(dcmi->mclk)) {
> + dev_err(dcmi->dev, "%s: Failed to start streaming, cannot
> enable clock",
> + __func__);
> + goto err_subdev_streamoff;
> + }
It feels more natural to me to first enable the clock, then call s_stream.
It seems what stop_streaming expects as well, since that disables the clock
last,
so here you would expect to see the opposite: the clock is enabled first.
> +
> + spin_lock_irq(&dcmi->irqlock);
> +
> + val = reg_read(dcmi->regs, DCMI_CR);
> +
> + val &= ~(CR_PCKPOL | CR_HSPOL | CR_VSPOL |
> + CR_EDM_0 | CR_EDM_1 | CR_FCRC_0 |
> + CR_FCRC_1 | CR_JPEG | CR_ESS);
> +
> + /* Set bus width */
> + switch (dcmi->bus.bus_width) {
> + case 14:
> + val &= CR_EDM_0 + CR_EDM_1;
> + break;
> + case 12:
> + val &= CR_EDM_1;
> + break;
> + case 10:
> + val &= CR_EDM_0;
> + break;
> + default:
> + /* Set bus width to 8 bits by default */
> + break;
> + }
> +
> + /* Set vertical synchronization polarity */
> + if (dcmi->bus.flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> + val |= CR_VSPOL;
> +
> + /* Set horizontal synchronization polarity */
> + if (dcmi->bus.flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> + val |= CR_HSPOL;
> +
> + /* Set pixel clock polarity */
> + if (dcmi->bus.flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> + val |= CR_PCKPOL;
> +
> + reg_write(dcmi->regs, DCMI_CR, val);
> +
> + /* Enable dcmi */
> + reg_set(dcmi->regs, DCMI_CR, CR_ENABLE);
> +
> + dcmi->state = RUNNING;
> +
> + dcmi->sequence = 0;
> + dcmi->errors_count = 0;
> + dcmi->buffers_count = 0;
> + dcmi->active = NULL;
> +
> + /*
> + * Start transfer if at least one buffer has been queued,
> + * otherwise transfer is defered at buffer queueing
typo: defered -> deferred
> + */
> + if (list_empty(&dcmi->buffers)) {
> + dev_dbg(dcmi->dev, "Start streaming is defered to next buffer
> queueing\n");
ditto (do a search & replace)
> + spin_unlock_irq(&dcmi->irqlock);
> + return 0;
> + }
> +
> + dcmi->active = list_entry(dcmi->buffers.next, struct dcmi_buf, list);
> + list_del_init(&dcmi->active->list);
> +
> + dev_dbg(dcmi->dev, "Start streaming, starting capture\n");
> +
> + ret = dcmi_start_capture(dcmi);
> + if (ret) {
> + dev_err(dcmi->dev, "%s: Start streaming failed, cannot start
> capture",
> + __func__);
> +
> + spin_unlock_irq(&dcmi->irqlock);
The clock isn't disabled in this error path.
> + goto err_subdev_streamoff;
> + }
> +
> + /* Enable interruptions */
> + reg_set(dcmi->regs, DCMI_IER, IT_FRAME | IT_OVR | IT_ERR);
> +
> + spin_unlock_irq(&dcmi->irqlock);
> +
> + return 0;
> +
> +err_subdev_streamoff:
> + v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
> +
> +err_release_buffers:
> + spin_lock_irq(&dcmi->irqlock);
> + /*
> + * Return all buffers to vb2 in QUEUED state.
> + * This will give ownership back to userspace
> + */
> + if (dcmi->active) {
> + buf = dcmi->active;
> + vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
> +
[GIT PULL FOR v4.12] Fix for nasty tc358743 regression
The following changes since commit 3622d3e77ecef090b5111e3c5423313f11711dfa: [media] ov2640: print error if devm_*_optional*() fails (2017-04-25 07:08:21 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.12i for you to fetch changes up to ad21c3167e4a67d5aa2a46a134ca07c4fa8c6719: tc358743: fix register i2c_rd/wr function fix (2017-05-05 12:19:17 +0200) Philipp Zabel (1): tc358743: fix register i2c_rd/wr function fix drivers/media/i2c/tc358743.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [RFC v2 3/3] dt: bindings: Add a binding for referencing EEPROM from camera sensors
Hi, On Fri, May 05, 2017 at 11:48:30AM +0300, Sakari Ailus wrote: > Many camera sensor devices contain EEPROM chips that describe the > properties of a given unit --- the data is specific to a given unit can > thus is not stored e.g. in user space or the driver. > > Some sensors embed the EEPROM chip and it can be accessed through the > sensor's I2C interface. This property is to be used for devices where the > EEPROM chip is accessed through a different I2C address than the sensor. > > The intent is to later provide this information to the user space. > > Signed-off-by: Sakari Ailus > Acked-by: Pavel Machek Reviewed-by: Sebastian Reichel > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt > index 0a33240..38e3916 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -79,6 +79,9 @@ Optional properties > > - lens-focus: A phandle to the node of the focus lens controller. > > +- eeprom: A phandle to the node of the EEPROM describing the camera sensor > + (i.e. device specific calibration data), in case it differs from the > + sensor node. > > Optional endpoint properties > -- Sebastian signature.asc Description: PGP signature
Re: [RFC v2 2/3] dt: bindings: Add lens-focus binding for image sensors
Hi, On Fri, May 05, 2017 at 11:48:29AM +0300, Sakari Ailus wrote: > The lens-focus property contains a phandle to the lens voice coil driver > that is associated to the sensor; typically both are contained in the same > camera module. > > Signed-off-by: Sakari Ailus > Acked-by: Pavel Machek Reviewed-by: Sebastian Reichel > --- > Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt > index dac764b..0a33240 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -77,6 +77,8 @@ Optional properties >single LED, then the phandles here refer to the child nodes of the LED >driver describing individual LEDs. > > +- lens-focus: A phandle to the node of the focus lens controller. > + > > Optional endpoint properties > -- Sebastian signature.asc Description: PGP signature
[RFC v2 0/3] Document bindings for camera modules and associated flash devices
This RFC patchset documents properties commonly required by camera modules and associated camera flash devices. The camera module is essentially a package consisting of an image sensor, a lens, possibly a voice coil to move the lens and a number of other things that at least the drivers need not to know of. All the devices in a camera module are declared separately in the system and as such the fact that they come in a single package isn't generally very useful to driver software. I'm sending the set as RFC as there's no driver implementation, and a dependency to the V4L2 async changes: http://www.spinics.net/lists/linux-media/msg114915.html> since RFC v1: - Remove sentences elaborating applicability of the bindings. - Say a LED driver is a piece of hardware. - Otherwise reformulate the descriptions according to the comments. Sakari Ailus (3): dt: bindings: Add a binding for flash devices associated to a sensor dt: bindings: Add lens-focus binding for image sensors dt: bindings: Add a binding for referencing EEPROM from camera sensors .../devicetree/bindings/media/video-interfaces.txt | 16 1 file changed, 16 insertions(+) -- 2.7.4
[RFC v2 2/3] dt: bindings: Add lens-focus binding for image sensors
The lens-focus property contains a phandle to the lens voice coil driver that is associated to the sensor; typically both are contained in the same camera module. Signed-off-by: Sakari Ailus Acked-by: Pavel Machek --- Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index dac764b..0a33240 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -77,6 +77,8 @@ Optional properties single LED, then the phandles here refer to the child nodes of the LED driver describing individual LEDs. +- lens-focus: A phandle to the node of the focus lens controller. + Optional endpoint properties -- 2.7.4
Re: [RFC 3/3] dt: bindings: Add a binding for referencing EEPROM from camera sensors
On Thu, May 04, 2017 at 04:38:04PM +0200, Sebastian Reichel wrote: > Hi, > > On Tue, May 02, 2017 at 01:25:49PM +0300, Sakari Ailus wrote: > > Many camera sensor devices contain EEPROM chips that describe the > > properties of a given unit --- the data is specific to a given unit can > > thus is not stored e.g. in user space or the driver. > > > > Some sensors embed the EEPROM chip and it can be accessed through the > > sensor's I²C interface. This property is to be used for devices where the > > EEPROM chip is accessed through a different I²C address than the sensor. > > > > The intent is to later provide this information to the user space. > > > > Signed-off-by: Sakari Ailus > > --- > > Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > > b/Documentation/devicetree/bindings/media/video-interfaces.txt > > index e52aefc..9bd2005 100644 > > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > > @@ -80,6 +80,9 @@ Optional properties > > - lens-focus: A phandle to the node of the lens. Only valid for device > >nodes that are related to an image sensor. > > > > +- eeprom: A phandle to the node of the related EEPROM. Only valid for > > + device nodes that are related to an image sensor. > > Here it's even more obvious, that the second sentence is redundant. > The requirement is already in the first sentence :) Instead it > should be mentioned, that this is to be used by devices not having > their own embedded eeprom. How about: > > eeprom: A phandle to the node of the EEPROM describing the camera > sensor (i.e. device specific calibration data), in case it differs > from the sensor node. Ack. I addressed the rest of the feedback, too, and posted RFC v2. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[RFC v2 1/3] dt: bindings: Add a binding for flash devices associated to a sensor
Camera flash drivers (and LEDs) are separate from the sensor devices in DT. In order to make an association between the two, provide the association information to the software. Signed-off-by: Sakari Ailus Acked-by: Pavel Machek Reviewed-by: Sebastian Reichel --- Documentation/devicetree/bindings/media/video-interfaces.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 9cd2a36..dac764b 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -67,6 +67,17 @@ are required in a relevant parent node: identifier, should be 1. - #size-cells: should be zero. + +Optional properties +--- + +- flash: An array of phandles that refer to the flash light sources + related to an image sensor. These could be e.g. LEDs. In case the LED + driver (current sink or source chip for the LED(s)) drives more than a + single LED, then the phandles here refer to the child nodes of the LED + driver describing individual LEDs. + + Optional endpoint properties -- 2.7.4
[RFC v2 3/3] dt: bindings: Add a binding for referencing EEPROM from camera sensors
Many camera sensor devices contain EEPROM chips that describe the properties of a given unit --- the data is specific to a given unit can thus is not stored e.g. in user space or the driver. Some sensors embed the EEPROM chip and it can be accessed through the sensor's I2C interface. This property is to be used for devices where the EEPROM chip is accessed through a different I2C address than the sensor. The intent is to later provide this information to the user space. Signed-off-by: Sakari Ailus Acked-by: Pavel Machek --- Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 0a33240..38e3916 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -79,6 +79,9 @@ Optional properties - lens-focus: A phandle to the node of the focus lens controller. +- eeprom: A phandle to the node of the EEPROM describing the camera sensor + (i.e. device specific calibration data), in case it differs from the + sensor node. Optional endpoint properties -- 2.7.4
Re: [RFC 1/3] dt: bindings: Add a binding for flash devices associated to a sensor
Hi, On Fri, May 05, 2017 at 11:28:34AM +0300, Sakari Ailus wrote: > Sebastian Reichel wrote: > > On Tue, May 02, 2017 at 01:25:47PM +0300, Sakari Ailus wrote: > > > +- flash: An array of phandles that refer to the flash light sources > > > + related to an image sensor. These could be e.g. LEDs. In case the LED > > > + driver drives more than a single LED, then the phandles here refer to > > > + the child nodes of the LED driver describing individual LEDs. Only > > > + valid for device nodes that are related to an image sensor. > > > > s/driver/controller/g - DT describes HW. Otherwise > > Driver is hardware in this case. :-) The chip that acts as a current sink or > source for the LED is the driver. E.g. the adp1653 documentation describes > the chip as "Compact, High Efficiency, High Power, Flash/Torch LED Driver > with Dual Interface". > > It might be still possible to improve the wording. Software oriented folks > are more likely to misunderstand the meaning of driver here, but controller > might seem ambiguous for hardware oriented people. > > How about: > > - flash: An array of phandles that refer to the flash light sources > related to an image sensor. These could be e.g. LEDs. In case the LED > driver (current sink or source chip for the LED(s)) drives more than a > single LED, then the phandles here refer to the child nodes of the LED > driver describing individual LEDs. Only valid for device nodes that are > related to an image sensor. Maybe drop the last sentence? The requirement is already in the first one. Otherwise: Reviewed-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature
Re: [RFC 1/3] dt: bindings: Add a binding for flash devices associated to a sensor
Hi Sebastian, Sebastian Reichel wrote: Hi Sakari, On Tue, May 02, 2017 at 01:25:47PM +0300, Sakari Ailus wrote: Camera flash drivers (and LEDs) are separate from the sensor devices in DT. In order to make an association between the two, provide the association information to the software. Signed-off-by: Sakari Ailus --- Documentation/devicetree/bindings/media/video-interfaces.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 9cd2a36..d6c62bc 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -67,6 +67,17 @@ are required in a relevant parent node: identifier, should be 1. - #size-cells: should be zero. + +Optional properties +--- + +- flash: An array of phandles that refer to the flash light sources + related to an image sensor. These could be e.g. LEDs. In case the LED + driver drives more than a single LED, then the phandles here refer to + the child nodes of the LED driver describing individual LEDs. Only + valid for device nodes that are related to an image sensor. s/driver/controller/g - DT describes HW. Otherwise Driver is hardware in this case. :-) The chip that acts as a current sink or source for the LED is the driver. E.g. the adp1653 documentation describes the chip as "Compact, High Efficiency, High Power, Flash/Torch LED Driver with Dual Interface". It might be still possible to improve the wording. Software oriented folks are more likely to misunderstand the meaning of driver here, but controller might seem ambiguous for hardware oriented people. How about: - flash: An array of phandles that refer to the flash light sources related to an image sensor. These could be e.g. LEDs. In case the LED driver (current sink or source chip for the LED(s)) drives more than a single LED, then the phandles here refer to the child nodes of the LED driver describing individual LEDs. Only valid for device nodes that are related to an image sensor. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH 1/6] drm: Add writeback connector type
On Fri, 25 Nov 2016 16:48:59 + Brian Starkey wrote: > +/** > + * drm_writeback_connector_init - Initialize a writeback connector and its > properties > + * @dev: DRM device > + * @wb_connector: Writeback connector to initialize > + * @funcs: Connector funcs vtable > + * @formats: Array of supported pixel formats for the writeback engine > + * @n_formats: Length of the formats array > + * > + * This function creates the writeback-connector-specific properties if they > + * have not been already created, initializes the connector as > + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property > + * values. > + * > + * Drivers should always use this function instead of drm_connector_init() to > + * set up writeback connectors. > + * > + * Returns: 0 on success, or a negative error code > + */ > +int drm_writeback_connector_init(struct drm_device *dev, > + struct drm_writeback_connector *wb_connector, > + const struct drm_connector_funcs *funcs, > + u32 *formats, int n_formats) This should probably be 'const u32 *formats', since developers are likely to define a this array with a 'static const' specifier in their driver.
