Re: [PATCH 2/6] em28xx: add ts mode setting for PCTV 461e
Indeed, the patch is correct, but the description should say: em28xx: add ts mode setting for PCTV 292e TS mode must be set in the existing PCTV 292e driver. Thanks for your reviews! On 13 August 2014 02:23, Antti Palosaari wrote: > Acked-by: Antti Palosaari > Reviewed-by: Antti Palosaari > > PCTV 461e is satellite receiver whilst that one should be PCTV 292e. I will > fix the type, no new patch needed. > > Antti > > > On 08/11/2014 10:58 PM, Olli Salonen wrote: >> >> TS mode must be set in the existing PCTV 461e driver. >> >> Signed-off-by: Olli Salonen >> --- >> drivers/media/usb/em28xx/em28xx-dvb.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c >> b/drivers/media/usb/em28xx/em28xx-dvb.c >> index d8e9760..0645793 100644 >> --- a/drivers/media/usb/em28xx/em28xx-dvb.c >> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c >> @@ -1535,6 +1535,7 @@ static int em28xx_dvb_init(struct em28xx *dev) >> /* attach demod */ >> si2168_config.i2c_adapter = &adapter; >> si2168_config.fe = &dvb->fe[0]; >> + si2168_config.ts_mode = SI2168_TS_PARALLEL; >> memset(&info, 0, sizeof(struct i2c_board_info)); >> strlcpy(info.type, "si2168", I2C_NAME_SIZE); >> info.addr = 0x64; >> > > -- > http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 00/21] LED / flash API integration
Hi Jacek, On Thu, Aug 07, 2014 at 10:21:14AM +0200, Jacek Anaszewski wrote: > On 08/06/2014 08:53 AM, Sakari Ailus wrote: > >Hi Jacek, > > > >On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote: > >... > >>1) Who should register V4L2 Flash sub-device? > >> > >>LED Flash Class devices, after introduction of the Flash Manager, > >>are not tightly coupled with any media controller. They are maintained > >>by the Flash Manager and made available for dynamic assignment to > >>any media system they are connected to through multiplexing devices. > >> > >>In the proposed rough solution, when support for V4L2 Flash sub-devices > >>is enabled, there is a v4l2_device created for them to register in. > >>This however implies that V4L2 Flash device will not be available > >>in any media controller, which calls its existence into question. > >> > >>Therefore I'd like to consult possible ways of solving this issue. > >>The option I see is implementing a mechanism for moving V4L2 Flash > >>sub-devices between media controllers. A V4L2 Flash sub-device > >>would initially be assigned to one media system in the relevant > >>device tree binding, but it could be dynamically reassigned to > >>the other one. However I'm not sure if media controller design > >>is prepared for dynamic modifications of its graph and how many > >>modifications in the existing drivers this solution would require. > > > >Do you have a use case where you would need to strobe a flash from multiple > >media devices at different times, or is this entirely theoretical? Typically > >flash controllers are connected to a single source of hardware strobe (if > >there's one) since the flash LEDs are in fact mounted next to a specific > >camera sensor. > > I took into account such arrangements in response to your message > [1], where you were considering configurations like "one flash but > two > cameras", "one camera and two flashes". And you also called for > proposing generic solution. > > One flash and two (or more) cameras case is easily conceivable - > You even mentioned stereo cameras. One camera and many flashes > arrangement might be useful in case of some professional devices which > might be designed so that they would be able to apply different scene > lighting. I haven't heard about such devices, but as you said > such a configuration isn't unthinkable. > > >If this is a real issue the way to solve it would be to have a single media > >device instead of many. > > I was considering adding media device, that would be a representation > of a flash manager, gathering all the registered flashes. Nonetheless, > finally I came to conclusion that a v4l2-device alone should suffice, > just to provide a Flash Manager representation allowing for > v4l2-flash sub-devices to register in. > All the features provided by the media device are useless in case > of a set of V4L2 Flash sub-devices. They couldn't have any linkage > in such a device. The only benefit from having media device gathering > V4L2 Flash devices would be possibility of listing them. Not quite so. The flash is associated to the sensor (and lens) using the group ID in the Media controller. The user space doesn't need to "know" this association. More complex use cases such as the above may need extensions to the Media controller API. > >>2) Consequences of locking the Flash Manager during flash strobe > >> > >>In case a LED Flash Class device depends on muxes involved in > >>routing the other LED Flash Class device's strobe signals, > >>the Flash Manager must be locked for the time of strobing > >>to prevent reconfiguration of the strobe signal routing > >>by the other device. > > > >I wouldn't be concerned of this in particular. It's more important we do > >actully have V4L2 flash API supported by LED flash drivers and that they do > >implement the API correctly. > > > >It's at least debatable whether you should try to prevent user space from > >doing silly things or not. With complex devices it may relatively easily > >lead to wrecking havoc with actual use cases which we certainly do not want. > > > >In this case, if you just prevent changing the routing (do you have a use > >case for it?) while strobing, someone else could still change the routing > >just before you strobe. > > Originally I started to implementing this so that strobe signal routing > was altered upon setting strobe source. With such an implementation > the use case would be as follows: > > 1. Process 1 sets strobe source to external > 2. Process 2 sets strobe source to software > 3. Process 1 strobes the flash, unaware that strobe source setting has >been changed > > To avoid such problems I changed the implementation so that the > routing is set in the led_flash_manager_setup_strobe function called > from led_set_flash_strobe and led_set_external_strobe functions. > led_flash_manager_setup_strobe sets strobe signal routing > and strobes the flash under lock and holds it for the flash timeout > per
Re: [PATCH/RFC v4 06/21] leds: add API for setting torch brightness
Bryan and Richard,
Your opinion would be much appreciated to a question myself and Jacek were
pondering. Please see below.
On Thu, Aug 07, 2014 at 03:12:09PM +0200, Jacek Anaszewski wrote:
> Hi Sakari,
>
> On 08/04/2014 02:50 PM, Sakari Ailus wrote:
> >Hi Jacek,
> >
> >Thank you for your continued efforts on this!
> >
> >On Mon, Aug 04, 2014 at 02:35:26PM +0200, Jacek Anaszewski wrote:
> >>On 07/16/2014 11:54 PM, Sakari Ailus wrote:
> >>>Hi Jacek,
> >>>
> >>>Jacek Anaszewski wrote:
> >>>...
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 1a130cc..9bea9e6 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -44,11 +44,21 @@ struct led_classdev {
> #define LED_BLINK_ONESHOT_STOP(1 << 18)
> #define LED_BLINK_INVERT(1 << 19)
> #define LED_SYSFS_LOCK(1 << 20)
> +#define LED_DEV_CAP_TORCH(1 << 21)
>
> /* Set LED brightness level */
> /* Must not sleep, use a workqueue if needed */
> void(*brightness_set)(struct led_classdev *led_cdev,
> enum led_brightness brightness);
> +/*
> + * Set LED brightness immediately - it is required for flash led
> + * devices as they require setting torch brightness to have
> immediate
> + * effect. brightness_set op cannot be used for this purpose because
> + * the led drivers schedule a work queue task in it to allow for
> + * being called from led-triggers, i.e. from the timer irq context.
> + */
> >>>
> >>>Do we need to classify actual devices based on this? I think it's rather
> >>>a different API behaviour between the LED and the V4L2 APIs.
> >>>
> >>>On devices that are slow to control, the behaviour should be asynchronous
> >>>over the LED API and synchronous when accessed through the V4L2 API. How
> >>>about implementing the work queue, as I have suggested, in the
> >>>framework, so
> >>>that individual drivers don't need to care about this and just implement
> >>>the
> >>>synchronous variant of this op? A flag could be added to distinguish
> >>>devices
> >>>that are fast so that the work queue isn't needed.
> >>>
> >>>It'd be nice to avoid individual drivers having to implement multiple
> >>>ops to
> >>>do the same thing, just for differing user space interfacs.
> >>>
> >>
> >>It is not only the matter of a device controller speed. If a flash
> >>device is to be made accessible from the LED subsystem, then it
> >>should be also compatible with led-triggers. Some of led-triggers
> >>call brightness_set op from the timer irq context and thus no
> >>locking in the callback can occur. This requirement cannot be
> >>met i.e. if i2c bus is to be used. This is probably the primary
> >>reason for scheduling work queue tasks in brightness_set op.
> >>
> >>Having the above in mind, setting a brightness in a work queue
> >>task must be possible for all LED Class Flash drivers, regardless
> >>whether related devices have fast or slow controller.
> >>
> >>Let's recap the cost of possible solutions then:
> >>
> >>1) Moving the work queues to the LED framework
> >>
> >> - it would probably require extending led_set_brightness and
> >> __led_set_brightness functions by a parameter indicating whether it
> >> should call brightness_set op in the work queue task or directly;
> >> - all existing triggers would have to be updated accordingly;
> >> - work queues would have to be removed from all the LED drivers;
> >>
> >>2) adding led_set_torch_brightness API
> >>
> >> - no modifications in existing drivers and triggers would be required
> >> - instead, only the modifications from the discussed patch would
> >> be required
> >>
> >>Solution 1 looks cleaner but requires much more modifications.
> >
> >How about a combination of the two, i.e. option 1 with the old op remaining
> >there for compatibility with the old drivers (with a comment telling it's
> >deprecated)?
> >
> >This way new drivers will benefit from having to implement this just once,
> >and modifications to the existing drivers could be left for later.
>
> It's OK for me, but the opinion from the LED side guys is needed here
> as well.
Ping.
> >The downside is that any old drivers wouldn't get V4L2 flash API but that's
> >entirely acceptable in my opinion since these would hardly be needed in use
> >cases that would benefit from V4L2 flash API.
>
> In the version 4 of the patch set I changed the implementation, so that
> a flash led driver must call led_classdev_flash_register to get
> registered as a LED Flash Class device and v4l2_flash_init to get
> V4L2 Flash API. In effect old drivers will have no chance to get V4L2
> Flash API either way.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Re: [PATCH/RFC v4 15/21] media: Add registration helpers for V4L2 flash
Hi Jacek,
On Mon, Aug 11, 2014 at 03:27:22PM +0200, Jacek Anaszewski wrote:
...
> diff --git a/include/media/v4l2-flash.h b/include/media/v4l2-flash.h
> new file mode 100644
> index 000..effa46b
> --- /dev/null
> +++ b/include/media/v4l2-flash.h
> @@ -0,0 +1,137 @@
> +/*
> + * V4L2 Flash LED sub-device registration helpers.
> + *
> + * Copyright (C) 2014 Samsung Electronics Co., Ltd
> + * Author: Jacek Anaszewski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation."
> + */
> +
> +#ifndef _V4L2_FLASH_H
> +#define _V4L2_FLASH_H
> +
> +#include
> +#include
> +#include le
> +#include
> +#include
> +
> +struct led_classdev_flash;
> +struct led_classdev;
> +enum led_brightness;
> +
> +struct v4l2_flash_ops {
> + int (*torch_brightness_set)(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
> + int (*torch_brightness_update)(struct led_classdev *led_cdev);
> + int (*flash_brightness_set)(struct led_classdev_flash *flash,
> + u32 brightness);
> + int (*flash_brightness_update)(struct led_classdev_flash *flash);
> + int (*strobe_set)(struct led_classdev_flash *flash, bool state);
> + int (*strobe_get)(struct led_classdev_flash *flash, bool *state);
> + int (*timeout_set)(struct led_classdev_flash *flash, u32 timeout);
> + int (*indicator_brightness_set)(struct led_classdev_flash *flash,
> + u32 brightness);
> + int (*indicator_brightness_update)(struct led_classdev_flash *flash);
> + int (*external_strobe_set)(struct led_classdev_flash *flash,
> + bool enable);
> + int (*fault_get)(struct led_classdev_flash *flash, u32 *fault);
> + void (*sysfs_lock)(struct led_classdev *led_cdev);
> + void (*sysfs_unlock)(struct led_classdev *led_cdev);
> >>>
> >>>These functions are not driver specific and there's going to be just one
> >>>implementation (I suppose). Could you refresh my memory regarding why
> >>>the LED framework functions aren't called directly?
> >>
> >>These ops are required to make possible building led-class-flash as
> >>a kernel module.
> >
> >Assuming you'd use the actual implementation directly, what would be the
> >dependencies? I don't think the LED flash framework has any callbacks
> >towards the V4L2 (LED) flash framework, does it? Please correct my
> >understanding if I'm missing something. In Makefile format, assume all
> >targets are .PHONY:
> >
> >led-flash-api: led-api
> >
> >v4l2-flash: led-flash-api
> >
> >driver: led-flash-api v4l2-flash
>
> LED Class Flash driver gains V4L2 Flash API when
> CONFIG_V4L2_FLASH_LED_CLASS is defined. This is accomplished in
> the probe function by either calling v4l2_flash_init function
> or the macro of this name, when the CONFIG_V4L2_FLASH_LED_CLASS
> macro isn't defined.
>
> If the v4l2-flash.c was to call the LED API directly, then the
> led-class-flash module symbols would have to be available at
> v4l2-flash.o linking time.
Is this an issue? EXPORT_SYMBOL_GPL() for the relevant symbols should be
enough.
> This requirement cannot be met if the led-class-flash is built
> as a module.
>
> Use of function pointers in the v4l2-flash.c allows to compile it
> into the kernel and enables the possibility of adding the V4L2 Flash
> support conditionally, during driver probing.
I'd simply decide this during kernel compilation time. If you want
something, just enable it. v4l2_flash_init() is called directly by the
driver in any case, so unless that is also called through a wrapper the
driver is still directly dependent on it.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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: Thu Aug 14 04:00:18 CEST 2014 git branch: test git hash: 0f3bf3dc1ca394a8385079a5653088672b65c5c4 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.16-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p-mfc: correct improper logs
This patch corrects improper logs within the code initializing hardware.
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 6c3f8f7..4976292 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -282,9 +282,9 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
s5p_mfc_clock_off();
return ret;
}
- mfc_debug(2, "Ok, now will write a command to init the system\n");
+ mfc_debug(2, "Ok, now will wait for completion of hardware init\n");
if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_SYS_INIT_RET)) {
- mfc_err("Failed to load firmware\n");
+ mfc_err("Failed to init hardware\n");
s5p_mfc_reset(dev);
s5p_mfc_clock_off();
return -EIO;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] media: tuner xc5000 firmware load fixes and improvements
This patch fixes firmware load issues seen during suspend and resume and speeds up firmware force load path. Releasing firmware from xc5000_release() instead of right after load helps avoid requesting firmware when it needs to be force loaded and fixes slowpath warnings during resume after suspend is done before firmware is loaded. Shuah Khan (2): media: tuner xc5000 - release firmwware from xc5000_release() media: tuner xc5000 - try to avoid firmware load in resume path drivers/media/tuners/xc5000.c | 50 - 1 file changed, 35 insertions(+), 15 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: tuner xc5000 - try to avoid firmware load in resume path
xc5000 doesn't load firmware at attach time instead loads it
when it needs to set and change configuration from its init,
frequency, digital and analog mode set interffaces. As a result,
when system is suspended before firmware is loaded, firmware
load can be avoided during resume. Loading formware in this
scenario results in slowpath warnings during resume as it won't
be in the suspend firmware cache.
Signed-off-by: Shuah Khan
---
drivers/media/tuners/xc5000.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index 31b1dec..d853cb3 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -1293,6 +1293,20 @@ static int xc5000_suspend(struct dvb_frontend *fe)
return 0;
}
+static int xc5000_resume(struct dvb_frontend *fe)
+{
+ struct xc5000_priv *priv = fe->tuner_priv;
+
+ dprintk(1, "%s()\n", __func__);
+
+ /* suspended before firmware is loaded.
+ Avoid firmware load in resume path. */
+ if (!priv->firmware)
+ return 0;
+
+ return xc5000_set_params(fe);
+}
+
static int xc5000_init(struct dvb_frontend *fe)
{
struct xc5000_priv *priv = fe->tuner_priv;
@@ -1360,7 +1374,7 @@ static const struct dvb_tuner_ops xc5000_tuner_ops = {
.init = xc5000_init,
.sleep = xc5000_sleep,
.suspend = xc5000_suspend,
- .resume= xc5000_set_params,
+ .resume= xc5000_resume,
.set_config= xc5000_set_config,
.set_params= xc5000_set_digital_params,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: tuner xc5000 - release firmwware from xc5000_release()
xc5000 releases firmware right after loading it. Change it to
save the firmware and release it from xc5000_release(). This
helps avoid fecthing firmware when forced firmware load requests
come in to change analog tv frequence and when firmware needs to
be reloaded after suspend and resume.
Signed-off-by: Shuah Khan
---
drivers/media/tuners/xc5000.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index 512fe50..31b1dec 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -70,6 +70,8 @@ struct xc5000_priv {
struct dvb_frontend *fe;
struct delayed_work timer_sleep;
+
+ const struct firmware *firmware;
};
/* Misc Defines */
@@ -1136,20 +1138,23 @@ static int xc_load_fw_and_init_tuner(struct
dvb_frontend *fe, int force)
if (!force && xc5000_is_firmware_loaded(fe) == 0)
return 0;
- ret = request_firmware(&fw, desired_fw->name,
- priv->i2c_props.adap->dev.parent);
- if (ret) {
- printk(KERN_ERR "xc5000: Upload failed. (file not found?)\n");
- return ret;
- }
-
- dprintk(1, "firmware read %Zu bytes.\n", fw->size);
+ if (!priv->firmware) {
+ ret = request_firmware(&fw, desired_fw->name,
+ priv->i2c_props.adap->dev.parent);
+ if (ret) {
+ pr_err("xc5000: Upload failed. rc %d\n", ret);
+ return ret;
+ }
+ dprintk(1, "firmware read %Zu bytes.\n", fw->size);
- if (fw->size != desired_fw->size) {
- printk(KERN_ERR "xc5000: Firmware file with incorrect size\n");
- ret = -EINVAL;
- goto err;
- }
+ if (fw->size != desired_fw->size) {
+ pr_err("xc5000: Firmware file with incorrect size\n");
+ ret = -EINVAL;
+ goto err;
+ }
+ priv->firmware = fw;
+ } else
+ fw = priv->firmware;
/* Try up to 5 times to load firmware */
for (i = 0; i < 5; i++) {
@@ -1232,7 +1237,6 @@ err:
else
printk(KERN_CONT " - too many retries. Giving up\n");
- release_firmware(fw);
return ret;
}
@@ -1316,6 +1320,8 @@ static int xc5000_release(struct dvb_frontend *fe)
if (priv) {
cancel_delayed_work(&priv->timer_sleep);
hybrid_tuner_release_state(priv);
+ if (priv->firmware)
+ release_firmware(priv->firmware);
}
mutex_unlock(&xc5000_list_mutex);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: fix au0828 dvb suspend/resume to call dvb_frontend_suspend/resume
au0828 doesn't resume correctly and TV tuning fails with
xc_set_signal_source(0) failed message. Change au0828 dvb
suspend and resume interfaces to suspend and resume frontend
during suspend and resume respectively. dvb_frontend_suspend()
suspends tuner and fe using tuner and fe ops. dvb_frontend_resume()
resumes fe and tuner using fe and tuner ops ini before waking up
the frontend. With this change HVR950Q suspend and resume work
when system gets suspended when digital function is tuned to a
channel and with active TV stream, and after resume it went right
back to active TV stream.
Signed-off-by: Shuah Khan
---
drivers/media/usb/au0828/au0828-dvb.c | 47 ++---
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-dvb.c
b/drivers/media/usb/au0828/au0828-dvb.c
index 821f86e..4bd9d68 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -620,34 +620,39 @@ int au0828_dvb_register(struct au0828_dev *dev)
void au0828_dvb_suspend(struct au0828_dev *dev)
{
struct au0828_dvb *dvb = &dev->dvb;
+ int rc;
- if (dvb->frontend && dev->urb_streaming) {
- pr_info("stopping DVB\n");
-
- cancel_work_sync(&dev->restart_streaming);
-
- /* Stop transport */
- mutex_lock(&dvb->lock);
- stop_urb_transfer(dev);
- au0828_stop_transport(dev, 1);
- mutex_unlock(&dvb->lock);
- dev->need_urb_start = 1;
+ if (dvb->frontend) {
+ if (dev->urb_streaming) {
+ cancel_work_sync(&dev->restart_streaming);
+ /* Stop transport */
+ mutex_lock(&dvb->lock);
+ stop_urb_transfer(dev);
+ au0828_stop_transport(dev, 1);
+ mutex_unlock(&dvb->lock);
+ dev->need_urb_start = 1;
+ }
+ /* suspend frontend - does tuner and fe to sleep */
+ rc = dvb_frontend_suspend(dvb->frontend);
+ pr_info("au0828_dvb_suspend(): Suspending DVB fe %d\n", rc);
}
}
void au0828_dvb_resume(struct au0828_dev *dev)
{
struct au0828_dvb *dvb = &dev->dvb;
+ int rc;
- if (dvb->frontend && dev->need_urb_start) {
- pr_info("resuming DVB\n");
-
- au0828_set_frontend(dvb->frontend);
-
- /* Start transport */
- mutex_lock(&dvb->lock);
- au0828_start_transport(dev);
- start_urb_transfer(dev);
- mutex_unlock(&dvb->lock);
+ if (dvb->frontend) {
+ /* resume frontend - does fe and tuner init */
+ rc = dvb_frontend_resume(dvb->frontend);
+ pr_info("au0828_dvb_resume(): Resuming DVB fe %d\n", rc);
+ if (dev->need_urb_start) {
+ /* Start transport */
+ mutex_lock(&dvb->lock);
+ au0828_start_transport(dev);
+ start_urb_transfer(dev);
+ mutex_unlock(&dvb->lock);
+ }
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: ttpci: build av7110_ir.c only when allowed by CONFIG_INPUT_EVDEV
From: Randy Dunlap Fix build when CONFIG_INPUT_EVDEV=m and DVB_AV7110=y. Only build av7110_ir.c when CONFIG_INPUT_EVDEV is compatible with CONFIG_DVB_AV7110. Fixes these build errors: drivers/built-in.o: In function `input_sync': av7110_ir.c:(.text+0x1223ac): undefined reference to `input_event' drivers/built-in.o: In function `av7110_emit_key': av7110_ir.c:(.text+0x12247c): undefined reference to `input_event' av7110_ir.c:(.text+0x122495): undefined reference to `input_event' av7110_ir.c:(.text+0x122569): undefined reference to `input_event' av7110_ir.c:(.text+0x1225a7): undefined reference to `input_event' drivers/built-in.o:av7110_ir.c:(.text+0x122629): more undefined references to `input_event' follow drivers/built-in.o: In function `av7110_ir_init': (.text+0x1227e4): undefined reference to `input_allocate_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12298f): undefined reference to `input_register_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12299e): undefined reference to `input_free_device' drivers/built-in.o: In function `av7110_ir_exit': (.text+0x122a94): undefined reference to `input_unregister_device' Signed-off-by: Randy Dunlap Reported-by: Randy Dunlap Reported-by: Jim Davis Cc: Holger Waechtler Cc: Oliver Endriss --- drivers/media/pci/ttpci/Kconfig |4 drivers/media/pci/ttpci/Makefile |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) Index: linux-next-20140813/drivers/media/pci/ttpci/Kconfig ======= --- linux-next-20140813.orig/drivers/media/pci/ttpci/Kconfig +++ linux-next-20140813/drivers/media/pci/ttpci/Kconfig @@ -1,8 +1,12 @@ +config DVB_AV7110_IR + bool + config DVB_AV7110 tristate "AV7110 cards" depends on DVB_CORE && PCI && I2C select TTPCI_EEPROM select VIDEO_SAA7146_VV + select DVB_AV7110_IR if INPUT_EVDEV=y || INPUT_EVDEV=DVB_AV7110 depends on VIDEO_DEV# dependencies of VIDEO_SAA7146_VV select DVB_VES1820 if MEDIA_SUBDRV_AUTOSELECT select DVB_VES1X93 if MEDIA_SUBDRV_AUTOSELECT Index: linux-next-20140813/drivers/media/pci/ttpci/Makefile === --- linux-next-20140813.orig/drivers/media/pci/ttpci/Makefile +++ linux-next-20140813/drivers/media/pci/ttpci/Makefile @@ -5,7 +5,7 @@ dvb-ttpci-objs := av7110_hw.o av7110_v4l.o av7110_av.o av7110_ca.o av7110.o av7110_ipack.o -ifdef CONFIG_INPUT_EVDEV +ifdef CONFIG_DVB_AV7110_IR dvb-ttpci-objs += av7110_ir.o endif -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
Hello. On 08/13/2014 09:30 PM, Ian Molton wrote: Fixed kernel WARNINGs for me! \o/ Ian, perhaps it makes sense for me to take these patches into my hands? I'm planning to respin these tomorrow - is that OK? Yes. I have test hardware with two different frontends here. I'm sorry, what do you mean by frontends? -Ian WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
> Fixed kernel WARNINGs for me! \o/ > Ian, perhaps it makes sense for me to take these patches into my hands? I'm planning to respin these tomorrow - is that OK? I have test hardware with two different frontends here. -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20140813, in drivers/media/pci/ttpci/av7110_ir.c
On 08/13/14 09:23, Jim Davis wrote: > Building with the attached random configuration file, > > LD init/built-in.o > drivers/built-in.o: In function `input_sync': > av7110_ir.c:(.text+0x1223ac): undefined reference to `input_event' > drivers/built-in.o: In function `av7110_emit_key': > av7110_ir.c:(.text+0x12247c): undefined reference to `input_event' > av7110_ir.c:(.text+0x122495): undefined reference to `input_event' > av7110_ir.c:(.text+0x122569): undefined reference to `input_event' > av7110_ir.c:(.text+0x1225a7): undefined reference to `input_event' > drivers/built-in.o:av7110_ir.c:(.text+0x122629): more undefined > references to `input_event' follow > drivers/built-in.o: In function `av7110_ir_init': > (.text+0x1227e4): undefined reference to `input_allocate_device' > drivers/built-in.o: In function `av7110_ir_init': > (.text+0x12298f): undefined reference to `input_register_device' > drivers/built-in.o: In function `av7110_ir_init': > (.text+0x12299e): undefined reference to `input_free_device' > drivers/built-in.o: In function `av7110_ir_exit': > (.text+0x122a94): undefined reference to `input_unregister_device' > make: *** [vmlinux] Error 1 > I reported this on Feb. 14 and July 11 of 2014. :( -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: adv7604: Add ability to read default input port from DT
On Wed, Aug 13, 2014 at 01:14:35PM +0100, Ian Molton wrote:
> On Mon, 11 Aug 2014 13:19:02 +0100
> Mark Rutland wrote:
>
> > > - - pclk-sample: Pixel clock polarity. Defaults to output on the falling
> > > edge.
> > > + - pclk-sample: Pixel clock polarity. Defaults to output on the
> > > falling edge.
> >
> > Unrelated whitespace change?
>
> Is there a sensible way to get miniscule whitespace changes in?
Just mention it in the commit message.
> > >If none of hsync-active, vsync-active and pclk-sample is specified the
> > >endpoint will use embedded BT.656 synchronization.
> > >
> > > + - default-input: Select which input is selected after reset.
> >
> > Valid values are?
>
> Chip dependent. 0 for 7611, 0-1 for 7612, I expect there are other chips in
> the family with differing numbers of inputs.
Ok. Can this be mentioned in the documentation?
Cheers,
Mark.
> > > + if (!of_property_read_u32(endpoint, "default_input", &v))
> >
> > This doesn't match the binding ('_' vs '-').
>
> Good catch!
>
> --
> Ian Molton
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
randconfig build error with next-20140813, in drivers/media/pci/ttpci/av7110_ir.c
Building with the attached random configuration file, LD init/built-in.o drivers/built-in.o: In function `input_sync': av7110_ir.c:(.text+0x1223ac): undefined reference to `input_event' drivers/built-in.o: In function `av7110_emit_key': av7110_ir.c:(.text+0x12247c): undefined reference to `input_event' av7110_ir.c:(.text+0x122495): undefined reference to `input_event' av7110_ir.c:(.text+0x122569): undefined reference to `input_event' av7110_ir.c:(.text+0x1225a7): undefined reference to `input_event' drivers/built-in.o:av7110_ir.c:(.text+0x122629): more undefined references to `input_event' follow drivers/built-in.o: In function `av7110_ir_init': (.text+0x1227e4): undefined reference to `input_allocate_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12298f): undefined reference to `input_register_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12299e): undefined reference to `input_free_device' drivers/built-in.o: In function `av7110_ir_exit': (.text+0x122a94): undefined reference to `input_unregister_device' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.16.0 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_A
Firmware files for 3 media device drivers
Hi, Please pull from: ssh://linuxtv.org/git/mchehab/linux-firmware.git master It has firmware files for media devices based on xc4000, xc5000c and as102. Thanks! Mauro - The following changes since commit 83b97f580e002ae94f060c5bd5a536b275e81afb: Move metadata for intel/fw_sst_0f28.bin-48kHz_i2s_master into WHENCE (2014-08-09 22:05:03 +0100) are available in the git repository at: ssh://linuxtv.org/git/mchehab/linux-firmware.git master for you to fetch changes up to 330e6abed89f16ab6fdca9dcfbc16105745a13fd: xc4000: add firmware for Xceive xc4000 tuner driver (2014-08-13 12:04:15 -0300) Mauro Carvalho Chehab (3): as102: add firmware for Abilis Systems Single DVB-T Receiver xc5000: Add firmware for xc5000c variant xc4000: add firmware for Xceive xc4000 tuner driver LICENCE.Abilis | 22 +++ LICENCE.xc4000 | 23 +++ LICENCE.xc5000c| 23 +++ WHENCE | 20 ++- as102_data1_st.hex | 1259 + as102_data2_st.hex | 1087 dvb-fe-xc4000-1.4.1.fw | Bin 0 -> 18643 bytes dvb-fe-xc5000c-4.1.30.7.fw | Bin 0 -> 16497 bytes 8 files changed, 2433 insertions(+), 1 deletion(-) create mode 100644 LICENCE.Abilis create mode 100644 LICENCE.xc4000 create mode 100644 LICENCE.xc5000c create mode 100644 as102_data1_st.hex create mode 100644 as102_data2_st.hex create mode 100644 dvb-fe-xc4000-1.4.1.fw create mode 100644 dvb-fe-xc5000c-4.1.30.7.fw -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Linux Kernel Media mini-summit on Oct, 16-17 in Düsseldorf, Germany
Hi, As there are still too things to be discussed in order to improve media stuff, and most of the developers nowadays are located in Europe and usually go to ELCE, we're scheduling a two day mini-summit in Düsseldorf, Germany, on Thrusday/Friday. There is a perfect opportunity to discuss the media Kernel-Userspace API improvements that are required for newer devices to work. So, we hope to have there the major Kernel contributors to the media subsystem, and some people working on userspace, in order to be sure that we'll match the needs required on userspace. In order to properly organize the event, I need the name of the developers interested on joining us, plus the themes proposed for discussions. As usual, we'll be using the media-works...@linuxtv.org ML for specific discussions about that, so the ones interested on participate are requested to subscribe it. Thanks! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: adv7604: Add ability to read default input port from DT
On Mon, 11 Aug 2014 13:19:02 +0100
Mark Rutland wrote:
> > - - pclk-sample: Pixel clock polarity. Defaults to output on the falling
> > edge.
> > + - pclk-sample: Pixel clock polarity. Defaults to output on the falling
> > edge.
>
> Unrelated whitespace change?
Is there a sensible way to get miniscule whitespace changes in?
> >If none of hsync-active, vsync-active and pclk-sample is specified the
> >endpoint will use embedded BT.656 synchronization.
> >
> > + - default-input: Select which input is selected after reset.
>
> Valid values are?
Chip dependent. 0 for 7611, 0-1 for 7612, I expect there are other chips in the
family with differing numbers of inputs.
> > +if (!of_property_read_u32(endpoint, "default_input", &v))
>
> This doesn't match the binding ('_' vs '-').
Good catch!
--
Ian Molton
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] rc: Add DT bindings for hix5hd2
From: Guoxiong Yan
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/media/hix5hd2-ir.txt | 21
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
new file mode 100644
index ..324048435b64
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -0,0 +1,21 @@
+Device-Tree bindings for hix5hd2 ir IP
+
+Required properties:
+- compatible: Should contain "hisilicon,hix5hd2-ir".
+- reg: Base physical address of the controller and length of memory
+ mapped region.
+- interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+- clocks: clock phandle and specifier pair.
+- hisilicon,power-syscon: phandle of syscon used to control power.
+
+Example node:
+
+ ir: ir@f8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0xf8001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock HIX5HD2_FIXED_24M>;
+ hisilicon,power-syscon = <&sctrl>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] rc: Introduce hix5hd2 IR transmitter driver
From: Guoxiong Yan
IR transmitter driver for Hisilicon hix5hd2 soc
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-hix5hd2.c | 347 +
3 files changed, 359 insertions(+)
create mode 100644 drivers/media/rc/ir-hix5hd2.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8fbd377e6311..b1c0c9c7ed74 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -166,6 +166,17 @@ config IR_ENE
To compile this driver as a module, choose M here: the
module will be called ene_ir.
+config IR_HIX5HD2
+ tristate "Hisilicon hix5hd2 IR remote control"
+ depends on RC_CORE
+ help
+Say Y here if you want to use hisilicon remote control.
+The driver passes raw pulse and space information to the LIRC decoder.
+To compile this driver as a module, choose M here: the module will be
+called hisi_ir.
+
+If you're not sure, select N here
+
config IR_IMON
tristate "SoundGraph iMON Receiver and Display"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f8b54ff46601..e86cda376639 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
+obj-$(CONFIG_IR_HIX5HD2) += ir-hix5hd2.o
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
new file mode 100644
index ..16a9d73dad4f
--- /dev/null
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -0,0 +1,347 @@
+/*
+ * Copyright (c) 2014 Linaro Ltd.
+ * Copyright (c) 2014 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IR_ENABLE 0x00
+#define IR_CONFIG 0x04
+#define CNT_LEADS 0x08
+#define CNT_LEADE 0x0c
+#define CNT_SLEADE 0x10
+#define CNT0_B 0x14
+#define CNT1_B 0x18
+#define IR_BUSY0x1c
+#define IR_DATAH 0x20
+#define IR_DATAL 0x24
+#define IR_INTM0x28
+#define IR_INTS0x2c
+#define IR_INTC0x30
+#define IR_START 0x34
+
+/* interrupt mask */
+#define INTMS_SYMBRCV (BIT(24) | BIT(8))
+#define INTMS_TIMEOUT (BIT(25) | BIT(9))
+#define INTMS_OVERFLOW (BIT(26) | BIT(10))
+#define INT_CLR_OVERFLOW BIT(18)
+#define INT_CLR_TIMEOUTBIT(17)
+#define INT_CLR_RCVBIT(16)
+#define INT_CLR_RCVTIMEOUT (BIT(16) | BIT(17))
+
+#define IR_CLK 0x48
+#define IR_CLK_ENABLE BIT(4)
+#define IR_CLK_RESET BIT(5)
+
+#define IR_CFG_WIDTH_MASK 0x
+#define IR_CFG_WIDTH_SHIFT 16
+#define IR_CFG_FORMAT_MASK 0x3
+#define IR_CFG_FORMAT_SHIFT14
+#define IR_CFG_INT_LEVEL_MASK 0x3f
+#define IR_CFG_INT_LEVEL_SHIFT 8
+/* only support raw mode */
+#define IR_CFG_MODE_RAWBIT(7)
+#define IR_CFG_FREQ_MASK 0x7f
+#define IR_CFG_FREQ_SHIFT 0
+#define IR_CFG_INT_THRESHOLD 1
+/* symbol start from low to high, symbol stream end at high*/
+#define IR_CFG_SYMBOL_FMT 0
+#define IR_CFG_SYMBOL_MAXWIDTH 0x3e80
+
+#define IR_HIX5HD2_NAME"hix5hd2-ir"
+
+struct hix5hd2_ir_priv {
+ int irq;
+ void*base;
+ struct device *dev;
+ struct rc_dev *rdev;
+ struct regmap *regmap;
+ struct clk *clock;
+ unsigned long rate;
+};
+
+static void hix5hd2_ir_send_lirc_timeout(struct rc_dev *rdev)
+{
+ DEFINE_IR_RAW_EVENT(ev);
+
+ ev.timeout = true;
+ ir_raw_event_store(rdev, &ev);
+}
+
+static irqreturn_t hix5hd2_ir_rx_interrupt(int irq, void *data)
+{
+ u32 symb_num, symb_val, symb_time;
+ u32 data_l, data_h;
+ u32 irq_sr, i;
+ struct hix5hd2_ir_priv *priv = data;
+
+ irq_sr = readl_relaxed(priv->base + IR_INTS);
+ if (irq_sr & INTMS_OVERFLOW) {
+ /*
+* we must read IR_DATAL first, then we can clean up
+* IR_INTS availably since logic would not clear
+* fifo when overflow, drv do the job
+*/
+ ir_raw_event_reset(priv->rdev);
+ symb_num = readl_relaxed(priv->base + IR_DA
[PATCH 0/2] Introduce hix5hd2 IR transmitter driver
Guoxiong Yan (2): [media] rc: Add DT bindings for hix5hd2 [media] rc: Introduce hix5hd2 IR transmitter driver .../devicetree/bindings/media/hix5hd2-ir.txt | 19 ++ drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/ir-hix5hd2.c | 347 4 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt create mode 100644 drivers/media/rc/ir-hix5hd2.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
