nvmem part,
Acked-by: Srinivas Kandagatla
drivers/tty/serial/amba-pl011.c | 2 +-
drivers/tty/serial/sprd_serial.c | 2 +-
drivers/video/fbdev/da8xx-fb.c | 4 ++--
fs/afs/write.c | 4
fs
Hi Pete,
On 23/09/14 19:02, Peter Griffin wrote:
Hi Srini,
On Mon, 22 Sep 2014, Srinivas Kandagatla wrote:
This patch fixes a compilation error while building with the
random kernel configuration.
drivers/media/rc/st_rc.c: In function 'st_rc_probe':
drivers/media/rc/st_rc.c:28
r_register anyway."
Signed-off-by: Srinivas Kandagatla
---
drivers/media/rc/st_rc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 03bbb09..e309441 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@
This patch moves setting of pm_ops out of the CONFIG_PM_SLEEP condition.
Setting pm ops under CONFIG_PM_SLEEP does not make any sense.
This patch also remove unnecessary also remove CONFIG_PM condition for pm
member in st_rc_driver structure.
Signed-off-by: Srinivas Kandagatla
---
drivers/media
tion]
rc_dev->rstc = reset_control_get(dev, NULL);
drivers/media/rc/st_rc.c:281:15: warning: assignment makes pointer
from integer without a cast [enabled by default]
rc_dev->rstc = reset_control_get(dev, NULL);
Reported-by: Jim Davis
Signed-off-by: Srinivas Kandagatla
---
drivers/media
Hi Mauro,
Thankyou for the "[media] enable COMPILE_TEST for media drivers" patch
which picked up few things in st-rc driver in linux-next testing.
Here is a few minor fixes to the driver, could you consider them for
the next merge window.
Thanks,
srini
Srinivas Kandagatla (3):
me
Thanks Mark,
The blocking issue for st-rc driver is now closed.
On 18/10/13 12:37, Mark Rutland wrote:
>>
>> Mauro C. had an option that this is not a real use-case and let's not
>> overdesign the API, thinking on a possible scenario that may never happen.
>>
>> Do you still think that this use c
.../devicetree/bindings/media/remote-control.txt | 31
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/remote-control.txt
diff --git a/Documentation/devicetree/bindings/media
On 01/10/13 15:49, Mauro Carvalho Chehab wrote:
>>> > >
>>> > > Btw, we're even thinking on mapping HDMI-CEC remote controller RX/TX via
>>> > > the RC subsystem. So, another L1 protocol would be "hdmi-cec".
>>> > >
>> > Ok.
>>> > > Yet, it seems unlikely that the very same remote controller IP w
On 27/09/13 14:57, Mauro Carvalho Chehab wrote:
> Em Fri, 27 Sep 2013 14:26:12 +0100
> Srinivas KANDAGATLA escreveu:
>
>> On 27/09/13 12:34, Mark Rutland wrote:
>>
>>>>> + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present i
On 27/09/13 12:34, Mark Rutland wrote:
>> > + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff
>> > +the rx pins are wired up.
> I'm unsure on this. What if the device has multiple receivers that can
> be independently configured? What if it supports something other than
>
Thanks Prabhakar,
>> +config RC_ST
>> + tristate "ST remote control receiver"
>> + depends on ARCH_STI && RC_CORE
>> + help
>> +Say Y here if you want support for ST remote control driver
>> +which allows both IR and UHF RX.
>> +The driver passes raw pluse
From: Srinivas Kandagatla
This patch attempts to collate generic bindings which can be used by
the remote control hardwares. Currently the list is not long as there
are only 2 drivers which are device tree'd.
Mainly this patch tries to document few bindings used by ST IRB driver
which c
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
This driver adds
Hi Stephen,
On 24/09/13 20:49, Stephen Warren wrote:
>>> >> Should those property names be prefixed with "st,"; I assume they're
>>> >> specific to this binding rather than something generic that applies to
>>> >> all IR controller bindings? If you expect them to be generic, it's fine.
>> >
>> >
Thanks Stephen,
On 23/09/13 21:40, Stephen Warren wrote:
> On 09/19/2013 02:59 AM, Srinivas KANDAGATLA wrote:
>> This patch adds support to ST RC driver, which is basically a IR/UHF
>> receiver and transmitter. This IP (IRB) is common across all the ST
>> parts for settop
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
In this driver
Thanks Mark,
On 16/09/13 15:10, Mark Rutland wrote:
>> +
>> > +Required properties:
>> > + - compatible: should be "st,comms-irb".
> This should probably say "should contain" rather than "should be". There
> may be future vairants of this device, which will also have a more
> specific compat
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
In this driver
On 29/08/13 13:01, Sean Young wrote:
> On Thu, Aug 29, 2013 at 12:29:00PM +0100, Srinivas KANDAGATLA wrote:
>> On 29/08/13 10:11, Sean Young wrote:
>>> On Wed, Aug 28, 2013 at 04:33:50PM +0100, Srinivas KANDAGATLA wrote:
>>>> From: Srinivas Kandagatla
>>&
On 29/08/13 11:49, Mauro Carvalho Chehab wrote:
>>> +MODULE_AUTHOR("STMicroelectronics (R&D) Ltd");
>>> > > +MODULE_LICENSE("GPL");
>>> > > --
>>> > > 1.7.6.5
> Except for the few points that Sean commented, the patch seems ok on my eyes.
Thankyou for reviewing. I will send v3 with the fixes.
th
On 29/08/13 10:11, Sean Young wrote:
> On Wed, Aug 28, 2013 at 04:33:50PM +0100, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>>
>> This patch adds support to ST RC driver, which is basically a IR/UHF
>> receiver and transmitter. This IP (IRB) is common acr
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
In this driver
On 16/08/13 12:40, Sean Young wrote:
> On Fri, Aug 16, 2013 at 11:53:48AM +0100, Srinivas KANDAGATLA wrote:
>> Thanks Sean for the comments.
>> On 16/08/13 09:38, Sean Young wrote:
>>> On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
>> [...]
>
Thanks Sean for the comments.
On 16/08/13 09:38, Sean Young wrote:
> On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
[...]
>>
>> Documentation/devicetree/bindings/media/st-rc.txt | 18 +
>> drivers/media/rc/Kconfig | 10 +
On 15/08/13 14:29, Mark Rutland wrote:
> On Thu, Aug 15, 2013 at 01:57:13PM +0100, Srinivas KANDAGATLA wrote:
>> Thanks Mark for your comments.
>>
>> On 15/08/13 09:49, Mark Rutland wrote:
>>> On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
On 15/08/13 14:30, Pawel Moll wrote:
> On Wed, 2013-08-14 at 18:27 +0100, Srinivas KANDAGATLA wrote:
>> +Device-Tree bindings for ST IR and UHF receiver
>> +
>> +Required properties:
>> + - compatible: should be "st,rc".
>> + - st,uhfmode: b
Thanks Mark for your comments.
On 15/08/13 09:49, Mark Rutland wrote:
> On Wed, Aug 14, 2013 at 06:27:01PM +0100, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>>
>> This patch adds support to ST RC driver, which is basically a IR/UHF
>> receiver and tra
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP is common across all the ST parts for
settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
In this driver adds onl
From: Srinivas Kandagatla
Thankyou for providing comments on v1 patch.
This patchset adds new members to rc_device structure to open rc device from
code other than rc-main. In the current code rc-device is only opened via input
driver. In cases where rc device is using lirc protocol, it will
From: Srinivas Kandagatla
This patch adds user count to rc_dev structure, the reason to add this
new member is to allow other code like lirc to open rc device directly.
In the existing code, rc device is only opened by input subsystem which
works ok if we have any input drivers to match. But in
From: Srinivas Kandagatla
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process
On 19/07/13 12:01, Sean Young wrote:
>> +int rval = 0;
>>
>> -return rdev->open(rdev);
>> +if (!rdev->users++)
>> +rval = rdev->open(rdev);
>> +
>> +if (rval)
>> +rdev->users--;
>> +
>> +return rval;
>
> This looks racey. Some locking is needed, I thi
From: Srinivas Kandagatla
Thankyou for providing comments on RFC patch.
This patchset adds new members to rc_device structure to open rc device from
code other than rc-main. In the current code rc-device is only opened via input
driver. In cases where rc device is using lirc protocol, it will
From: Srinivas Kandagatla
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process
From: Srinivas Kandagatla
This patch adds user count to rc_dev structure, the reason to add this
new member is to allow other code like lirc to open rc device directly.
In the existing code, rc device is only opened by input subsystem which
works ok if we have any input drivers to match. But in
Thanks Sean for the comments,
On 12/07/13 13:46, Sean Young wrote:
> On Fri, Jul 12, 2013 at 09:55:28AM +0100, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>>
>> The use case is simple, if any rc device has allowed protocols =
>> RC_TYPE_LIRC and map_name =
From: Srinivas Kandagatla
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/media/rc/ir-rx51.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/media/platform/soc_camera/soc_camera.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/media/platform/mx2_emmaprp.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform
From: Srinivas Kandagatla
Running below Coccinelle lookup pattern like below on the
latest kernel showed about 52 hits. This patch series is a subset
of those 52 patches, so that it will be easy for maintainers to review.
Hopefully these patches will get rid of some code duplication in kernel
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/media/platform/m2m-deinterlace.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/m2m
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/media/platform/blackfin/bfin_capture.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media
From: Srinivas Kandagatla
This patch removes BUG_ON in ir_raw_event_thread which IMO is a
over-kill, and this kills the ir_raw_event_thread too. With a bit of
additional logic in this patch, we nomore need to kill this thread.
Other disadvantage of having a BUG-ON is,
wake_up_process(dev->
From: Srinivas Kandagatla
This patch adds an additional availability check in ir_raw_event_store
before adding an ir_raw_event into kfifo. The reason to do this is,
Kfifo_alloc allocates fifo of size rounded down to 2. Which in this
case makes sizeof ir_raw_event*MAX_IR_EVENT_SIZE = 6144 to 4096
46 matches
Mail list logo
