Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

2010-11-03 Thread Pavel Machek
Hi! @@ -79,6 +79,10 @@ static struct drm_driver driver = { static int __init i810_init(void) { + if (num_present_cpus() 1) { + pr_err(drm/i810 does not support SMP\n); + return -EINVAL; + } driver.num_ioctls = i810_max_ioctl; return

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Pavel Machek
On Sun 2009-12-06 12:59:00, Christoph Bartelmus wrote: Hi Dmitry, on 05 Dec 09 at 22:55, Dmitry Torokhov wrote: [...] I do not believe you are being realistic. Sometimes we just need to say that the device is a POS and is just not worth it. Remember, there is still lirc hole for the

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Pavel Machek
Hi! (11) if none is against renaming IR as RC, I'll do it on a next patch; Call it irc -- infrared remote control. Bluetooth remote controls will have very different characteristics. Pavel -- (english)

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Pavel Machek
On Tue 2009-12-15 15:14:02, Jon Smirl wrote: On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote: Hi!       (11) if none is against renaming IR as RC, I'll do it on a next patch; Call it irc -- infrared remote control. Bluetooth remote controls will have very different

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Pavel Machek
On Tue 2009-12-15 15:29:51, Jon Smirl wrote: On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote: On Tue 2009-12-15 15:14:02, Jon Smirl wrote: On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote: Hi!       (11) if none is against renaming IR as RC, I'll do

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-15 Thread Pavel Machek
On Tue 2009-12-15 15:45:14, Jon Smirl wrote: On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote: On Tue 2009-12-15 15:29:51, Jon Smirl wrote: On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote: On Tue 2009-12-15 15:14:02, Jon Smirl wrote: On Tue, Dec 15, 2009

Re: webcam problem after suspend/hibernate

2010-04-01 Thread Pavel Machek
Hi! Do you mean the dmesg output ? A full dmesg is included in this address : http://pastebin.com/8XU619Uk Not in all suspend/hibernate the problem comes, only in some of them and this included dmesg output is just after a non working case of webcam fault. I also have found this in

Re: webcam problem after suspend/hibernate

2010-04-04 Thread Pavel Machek
Hi! Do you mean the dmesg output ? A full dmesg is included in this address : http://pastebin.com/8XU619Uk Not in all suspend/hibernate the problem comes, only in some of them and this included dmesg output is just after a non working case of webcam fault. I also have

Re: webcam problem after suspend/hibernate

2010-04-04 Thread Pavel Machek
Hi! If unload/reload of uvcvideo helps, it is most likely problem in that. If unload/reload of ehci_hcd is needed, it is most likely ehci problem. My testing shows that: 1. If I remove uvcvideo BEFORE suspend and reinsert it after resume, it works. However, I cannot always

Re: webcam problem after suspend/hibernate

2010-04-06 Thread Pavel Machek
On Tue 2010-04-06 11:32:46, Mohamed Ikbel Boulabiar wrote: Hi ! Ok, that puts the problem firmly into uvcvideo area. Try changing its _resume routine to whatever is done on device unplug... it should be rather easy, and is quite close to correct solution. I am waiting to try that.

Re: webcam problem after suspend/hibernate

2010-04-11 Thread Pavel Machek
Hi! My testing shows that: 1. If I remove uvcvideo BEFORE suspend and reinsert it after resume, it works. However, I cannot always rmmod uvcvideo before suspend as it may be in use. ... I think uvcvideo is failing to reinitialize the camera on resume, and forcing

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2010-03-25 Thread Pavel Machek
Hi! This were the original plan we've discussed, back in December: Seems sane. struct keycode_table_entry { unsigned keycode; char scancode[32]; /* 32 is just an arbitrary long array - maybe shorter */ int len; } What about struct keycode_table_entry {

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2010-03-26 Thread Pavel Machek
Hi! Anyway, one simple way to avoid resetting the hardware for every new parameter change would be to use a timer for reset. This way, an userspace application or script that is touching on several parameters would just send the complete RX init sequence and after some dozens of

arm tree in broken state (was Re: What's inside the pxa tree for this merge window)

2009-09-30 Thread Pavel Machek
I discarded them _because_ Eric handled them, which is what I said in the comments when I discarded them. Ok, I did do my best to get patches in the right order in the mainline, but it all failed. AFAICS, v4l and sh are already in the mainline with a _wrongly_ resolved mefge

Video capture in FPGA -- simple hardware to emulate?

2014-02-13 Thread Pavel Machek
Hi! I'm working on project that will need doing video capture from FPGA. That means I can define interface between kernel and hardware. Is there suitable, simple hardware we should emulate in the FPGA? I took a look, and pxa_camera seems to be one of the simple ones... Thanks,

Re: Video capture in FPGA -- simple hardware to emulate?

2014-02-13 Thread Pavel Machek
Hi! I'm working on project that will need doing video capture from FPGA. That means I can define interface between kernel and hardware. Is there suitable, simple hardware we should emulate in the FPGA? I took a look, and pxa_camera seems to be one of the simple ones... Too bad

Re: [PATCH] radio-bcm2048.c: fix wrong overflow check

2014-04-22 Thread Pavel Machek
On Tue 2014-04-22 12:16:56, Dan Carpenter wrote: On Tue, Apr 22, 2014 at 10:55:53AM +0200, Pali Rohár wrote: On Tuesday 22 April 2014 10:39:17 Dan Carpenter wrote: On Sun, Apr 20, 2014 at 04:56:22PM +0200, Pavel Machek wrote: Fix wrong overflow check in radio-bcm2048. Signed-off

[PATCH v2] radio-bcm2048.c: fix wrong overflow check

2014-04-22 Thread Pavel Machek
From: Pali Rohár pali.ro...@gmail.com This patch fixes an off by one check in bcm2048_set_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Pavel Machek pa...@ucw.cz Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

[PATCHv2] radio-bcm2048.c: fix wrong overflow check

2014-04-22 Thread Pavel Machek
From: Pali Rohár pali.ro...@gmail.com Fix wrong overflow check in radio-bcm2048. Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Pavel Machek pa...@ucw.cz Reported-by: Dan Carpenter dan.carpen...@oracle.com --- Nothing in patch changed, just added CCs, and From/Reported-by headers

Re: [PATCH 2/2] staging: nokia_h4p: nokia_core.c - removed IRQF_DISABLED macro

2014-07-09 Thread Pavel Machek
On Wed 2014-07-09 11:36:38, Anil Belur wrote: From: Anil Belur ask...@gmail.com - this patch removes the IRQF_DISABLED macro, as this is deprecated/noop. Signed-off-by: Anil Belur ask...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz I wonder if it would maek sense to do ./include

Re: [PATCH 1/2] staging: media: bcm2048: radio-bcm2048.c - removed IRQF_DISABLED macro

2014-07-09 Thread Pavel Machek
On Wed 2014-07-09 11:36:37, Anil Belur wrote: From: Anil Belur ask...@gmail.com - this patch removes IRQF_DISABLED macro, as this is deprecated/noop. Signed-off-by: Anil Belur ask...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek

Re: [PATCH] staging: media: bcm2048: fix coding style error

2014-11-15 Thread Pavel Machek
On Sat 2014-11-15 21:12:18, Konrad Zapalowicz wrote: On 11/15, Christian Resell wrote: Simple style fix (checkpatch.pl: space prohibited before that ','). For the eudyptula challenge (http://eudyptula-challenge.org/). Nice, however we do not need the information about the 'eudyptula

[RFC] adp1653: Add device tree bindings for LED controller

2014-11-16 Thread Pavel Machek
For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks. Anything else obviously wrong? Signed-off-by: Pavel Machek pa...@ucw.cz Thanks

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 09:11:04, Lars-Peter Clausen wrote: On 11/16/2014 08:59 AM, Pavel Machek wrote: [...] +adp1653: adp1653@30 { +compatible = ad,adp1653; The Analog Devices vendor prefix is adi. Thanks, will be fixed in next version. -- (english) http://www.livejournal.com

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 11:09:51, Andreas Färber wrote: Hi Pavel, Am 16.11.2014 um 08:59 schrieb Pavel Machek: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? [...] diff --git a/arch/arm/boot/dts/omap3-n900.dts b

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-17 Thread Pavel Machek
Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding below look acceptable? I'll clean up driver code a bit more, remove the printks

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-17 Thread Pavel Machek
On Mon 2014-11-17 11:09:45, Pali Rohár wrote: On Monday 17 November 2014 11:05:19 Pavel Machek wrote: Hi! On Mon 2014-11-17 09:43:19, Pali Rohár wrote: On Sunday 16 November 2014 08:59:28 Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
On Tue 2014-11-18 09:09:09, Jacek Anaszewski wrote: Hi Pavel, Sakari, On 11/17/2014 03:58 PM, Sakari Ailus wrote: Hi Pavel, On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
On Tue 2014-11-18 09:09:09, Jacek Anaszewski wrote: Hi Pavel, Sakari, On 11/17/2014 03:58 PM, Sakari Ailus wrote: Hi Pavel, On Sun, Nov 16, 2014 at 08:59:28AM +0100, Pavel Machek wrote: For device tree people: Yes, I know I'll have to create file in documentation, but does the binding

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
I've already submitted a patch [1] that updates leds common bindings. I hasn't been merged yet, as the related LED Flash class patch [2] still needs some indicator leds related discussion [3]. I think this is a good moment to discuss the flash related led common bindings. Part of

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
Hi! @@ -19,5 +30,10 @@ Examples: system-status { label = Status; linux,default-trigger = heartbeat; + iout-torch = 500 500; + iout-flash = 1000 1000; + iout-indicator = 100 100; + flash-timeout = 1000; + ... }; I don't get

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
Hi! If the hardware LED changes with one that needs different current, the block for the adp1653 stays the same, but white LED block should be updated with different value. I think that you are talking about sub nodes. Indeed I am leaning towards this type of design. I think I am :-). I

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-18 Thread Pavel Machek
On Mon 2014-11-17 07:06:17, Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [141117 07:03]: On Monday 17 November 2014 15:55:46 Tony Lindgren wrote: There's nothing stopping us from initializing the camera code from pdata-quirks.c for now to keep it working. Certainly the

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-20 Thread Pavel Machek
Hi! I would also swap the segments of a property name to follow the convention as in case of regulator-max-microamp. Updated version: == Optional properties for child nodes: - max-microamp : maximum intensity in microamperes of

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-20 Thread Pavel Machek
Hi! But regulators already have regulator-max-microamp property. So what about: max-microamp : maximum intensity in microamperes of the LED (torch LED for flash devices) max-flash-microamp : initial intensity in microamperes of the flash LED; it

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-11-29 Thread Pavel Machek
Hi! +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. The modes are +supported by the LED class (see Documentation/leds/leds-class.txt) +and LED Flash class respectively. + +In order to enable support for flash LEDs

Re: [PATCH/RFC v8 04/14] v4l2-async: change custom.match callback argument type

2014-11-29 Thread Pavel Machek
property. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Hans Verkuil hans.verk...@cisco.com Acked-by: Pavel Machek pa

Re: [PATCH/RFC v8 07/14] exynos4-is: Add support for v4l2-flash subdevs

2014-11-29 Thread Pavel Machek
kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line

Re: [PATCH/RFC v8 12/14] leds: Add driver for AAT1290 current regulator

2014-11-29 Thread Pavel Machek
}, spaces after { and before } ? Otherwise looks ok, Signed-off-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

2014-11-29 Thread Pavel Machek
Hi! diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..50a8dad 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,6 +41,62 @@

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

2014-12-01 Thread Pavel Machek
Hi! Is this one needed? Just ommit child note if it is not there. It is needed because you can have one led connected two both outputs. This allows to describe such a design. Ok. +- maxim,trigger-type : Array of trigger types in order: flash, torch + Possible trigger types: +

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-12-01 Thread Pavel Machek
Hi! How are faults cleared? Should it be list of strings, instead of bitmask? We may want to add new fault modes in future... Faults are cleared by reading the attribute. I will add this note. There can be more than one fault at a time. I think that the bitmask is a flexible solution. I

[PATCH] media: i2c/adp1653: devicetree support for adp1653

2014-12-03 Thread Pavel Machek
We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt @@ -0,0 +1,38 @@ +* Analog

Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693

2014-12-04 Thread Pavel Machek
Hi! +- maxim,boost-mode : + In boost mode the device can produce up to 1.2A of total current + on both outputs. The maximum current on each output is reduced + to 625mA then. If there are two child led nodes defined then boost + is enabled by default. + Possible values: +

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-12-06 Thread Pavel Machek
The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-12-08 Thread Pavel Machek
On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-12-09 Thread Pavel Machek
On Tue 2014-12-09 09:54:06, Jacek Anaszewski wrote: Hi Pavel, On 12/08/2014 09:18 PM, Pavel Machek wrote: On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2014-12-10 Thread Pavel Machek
Hi! both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at runtime? Why? We can emulate sane and consistent behaviour for all the

Re: [PATCH] media: i2c/adp1653: devicetree support for adp1653

2014-12-23 Thread Pavel Machek
On Tue 2014-12-23 15:23:25, Mauro Carvalho Chehab wrote: Em Wed, 3 Dec 2014 22:46:41 +0100 Pavel Machek pa...@ucw.cz escreveu: We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation

[PATCHv2] media: i2c/adp1653: devicetree support for adp1653

2014-12-24 Thread Pavel Machek
We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz --- Changed -microsec to -us, as requested by devicetree people. Fixed checkpatch issues. diff --git

Re: [PATCH] media: i2c/adp1653: devicetree support for adp1653

2014-12-24 Thread Pavel Machek
On Tue 2014-12-23 21:49:04, Pavel Machek wrote: On Tue 2014-12-23 15:23:25, Mauro Carvalho Chehab wrote: Em Wed, 3 Dec 2014 22:46:41 +0100 Pavel Machek pa...@ucw.cz escreveu: We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

2014-12-26 Thread Pavel Machek
Hi! We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz --- Changed -microsec to -us, as requested by devicetree people. Fixed checkpatch

Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property

2015-01-15 Thread Pavel Machek
Hi! Perhaps we could use the 'reg' property to describe actual connections, I'm not sure if it's better than a LED specific property, e.g. max77387@52 { compatible = nxp,max77387; #address-cells = 2; #size-cells = 0; reg = 0x52; flash_led {

Re: [PATCH/RFC v10 07/19] mfd: max77693: Adjust FLASH_EN_SHIFT and TORCH_EN_SHIFT macros

2015-01-20 Thread Pavel Machek
On Tue 2015-01-20 15:40:29, Lee Jones wrote: On Tue, 20 Jan 2015, Jacek Anaszewski wrote: On 01/20/2015 02:01 PM, Jacek Anaszewski wrote: On 01/20/2015 12:17 PM, Lee Jones wrote: On Fri, 09 Jan 2015, Jacek Anaszewski wrote: Modify FLASH_EN_SHIFT and TORCH_EN_SHIFT macros to work

Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property

2015-01-20 Thread Pavel Machek
On Tue 2015-01-20 11:29:16, Rob Herring wrote: On Tue, Jan 20, 2015 at 10:09 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: On 01/16/2015 04:52 PM, Jacek Anaszewski wrote: On 01/16/2015 02:48 PM, Rob Herring wrote: [...] You may want to add something like led-output-cnt or

Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653

2015-01-18 Thread Pavel Machek
On Sun 2015-01-04 10:43:52, Pavel Machek wrote: We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz Sakari? You are listed as adp1653 maintainer. Did

Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface

2015-02-20 Thread Pavel Machek
Hi! +What:/sys/class/leds/led/available_sync_leds +Date:February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization,

0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface

2015-02-18 Thread Pavel Machek
...@rpsys.net NAK-ed-by: Pavel Machek +What:/sys/class/leds/led/available_sync_leds +Date:February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available

Re: [PATCH/RFC v10 15/19] media: Add registration helpers for V4L2 flash sub-devices

2015-01-12 Thread Pavel Machek
Hi! +* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only. +* Therefore it must be possible to set it to 0 level which in +* the LED subsystem reflects LED_OFF state. +*/ + if (cdata_id != INDICATOR_INTENSITY) + ++__intensity; And normally we'd do

Re: [PATCH/RFC v10 08/19] leds: Add support for max77693 mfd flash cell

2015-01-12 Thread Pavel Machek
Hi! +struct max77693_sub_led { + /* related FLED output identifier */ -flash LED, about 4x. +/* split composite current @i into two @iout according to @imax weights */ +static void __max77693_calc_iout(u32 iout[2], u32 i, u32 imax[2]) +{ + u64 t = i; + + t *= imax[1]; +

Re: [PATCH/RFC v10 10/19] leds: Add driver for AAT1290 current regulator

2015-01-09 Thread Pavel Machek
-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH/RFC v10 04/19] dt-binding: mfd: max77693: Add DT binding related macros

2015-01-09 Thread Pavel Machek
-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More

Re: [PATCH/RFC v10 09/19] DT: Add documentation for the mfd Maxim max77693

2015-01-09 Thread Pavel Machek
Park kyungmin.p...@samsung.com Acked-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..ef184f0 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation

Re: [PATCH/RFC v10 05/19] mfd: max77693: Modify flash cell name identifiers

2015-01-09 Thread Pavel Machek
...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-media

Re: [PATCH/RFC v10 06/19] mfd: max77693: modifications around max77693_led_platform_data

2015-01-09 Thread Pavel Machek
...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Chanwoo Choi cw00.c...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Seems that max77693_led_platform_data is unused at the moment, so it should not break bisect. Acked-by: Pavel Machek pa...@ucw.cz index f0b6585..c1ccb13 100644

Re: [PATCH/RFC v10 11/19] of: Add Skyworks Solutions, Inc. vendor prefix

2015-01-09 Thread Pavel Machek
...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses

Re: [PATCH/RFC v10 14/19] v4l2-ctrls: Add V4L2_CID_FLASH_SYNC_STROBE control

2015-01-09 Thread Pavel Machek
Park kyungmin.p...@samsung.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe

Re: [PATCH/RFC v10 13/19] exynos4-is: Add support for v4l2-flash subdevs

2015-01-09 Thread Pavel Machek
kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line

Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property

2015-01-09 Thread Pavel Machek
...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Acked-by: Pavel Machek pa...@ucw.cz -- (english) http

Re: [PATCH/RFC v10 07/19] mfd: max77693: Adjust FLASH_EN_SHIFT and TORCH_EN_SHIFT macros

2015-01-09 Thread Pavel Machek
Park kyungmin.p...@samsung.com Cc: Chanwoo Choi cw00.c...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe

Re: [PATCH/RFC v10 02/19] Documentation: leds: Add description of LED Flash class extension

2015-01-09 Thread Pavel Machek
Hi! The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie

Re: [PATCH/RFC v10 01/19] leds: Add LED Flash class extension to the LED subsystem

2015-01-09 Thread Pavel Machek
Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz

Re: [PATCH/RFC v10 08/19] leds: Add support for max77693 mfd flash cell

2015-01-09 Thread Pavel Machek
On Fri 2015-01-09 16:22:58, Jacek Anaszewski wrote: This patch adds led-flash support to Maxim max77693 chipset. A device can be exposed to user space through LED subsystem sysfs interface. Device supports up to two leds which can work in flash and torch mode. The leds can be triggered

Re: [PATCH/RFC v10 12/19] DT: Add documentation for the Skyworks AAT1290

2015-01-09 Thread Pavel Machek
On Fri 2015-01-09 16:23:02, Jacek Anaszewski wrote: This patch adds device tree binding documentation for 1.5A Step-Up Current Regulator for Flash LEDs. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Pavel Machek pa

Re: [PATCH/RFC v10 17/19] DT: Add documentation for exynos4-is 'flashes' property

2015-01-09 Thread Pavel Machek
Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures

Re: [PATCH/RFC v10 19/19] leds: aat1290: add support for V4L2 Flash sub-device

2015-01-09 Thread Pavel Machek
-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Sakari Ailus sakari.ai...@linux.intel.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http

Re: [PATCH/RFC v10 16/19] Documentation: leds: Add description of v4l2-flash sub-device

2015-01-09 Thread Pavel Machek
sakari.ai...@linux.intel.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from

Re: [PATCH/RFC v10 15/19] media: Add registration helpers for V4L2 flash sub-devices

2015-01-09 Thread Pavel Machek
in the kernel config the functions' empty versions will be used. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com Acked-by: Pavel Machek pa...@ucw.cz

Re: [PATCH/RFC v10 18/19] leds: max77693: add support for V4L2 Flash sub-device

2015-01-09 Thread Pavel Machek
-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

2015-01-04 Thread Pavel Machek
Hi! Thanks for the patch! A few comments below. On Wed, Dec 24, 2014 at 11:34:34PM +0100, Pavel Machek wrote: We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel

[PATCHv3] media: i2c/adp1653: devicetree support for adp1653

2015-01-04 Thread Pavel Machek
We are moving to device tree support on OMAP3, but that currently breaks ADP1653 driver. This adds device tree support, plus required documentation. Signed-off-by: Pavel Machek pa...@ucw.cz --- Please apply, Pavel diff --git

Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface

2015-02-20 Thread Pavel Machek
On Fri 2015-02-20 07:36:16, Greg KH wrote: On Fri, Feb 20, 2015 at 08:56:11AM +0100, Jacek Anaszewski wrote: On 02/19/2015 10:40 PM, Greg KH wrote: On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02

[PATCH] Add device tree support to adp1653 flash driver

2015-03-13 Thread Pavel Machek
Nokia N900 is switching to device tree, make sure we can use flash there, too. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index 873fe19..0341009 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -8,6

Re: [PATCH] Add device tree support to adp1653 flash driver

2015-03-23 Thread Pavel Machek
Hi! Nokia N900 is switching to device tree, make sure we can use flash there, too. Signed-off-by: Pavel Machek pa...@ucw.cz Sakari, you are marked as a matinainer for this driver. Can you take the patch so that it makes it into 4.1? Thanks

Re: [PATCH/RFC v13 04/13] DT: Add documentation for the mfd Maxim max77693

2015-03-23 Thread Pavel Machek
rpur...@rpsys.net Acked-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 38e6440..15c546e 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation

Re: [PATCH/RFC v13 04/13] DT: Add documentation for the mfd Maxim max77693

2015-03-23 Thread Pavel Machek
On Mon 2015-03-23 15:02:13, Lee Jones wrote: On Mon, 23 Mar 2015, Pavel Machek wrote: On Mon 2015-03-23 12:07:43, Lee Jones wrote: This patch requires a DT Ack. No, it requires DT people to be notified -- and they were, few times by now. They clearly don't care. Well

Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface

2015-03-02 Thread Pavel Machek
Hi! Of course the relevant sysfs group could be initialized only with the needed number of sync leds attributes, but still this is less than optimal design. It looks like this interface indeed doesn't fit for sysfs. I am leaning towards removing the support for synchronized flash

Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension

2015-01-29 Thread Pavel Machek
Hi! This approach would require implementing additional mechanisms on both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at

Re: [PATCH] radio-bcm2048: remove unused var

2015-04-28 Thread Pavel Machek
, skip_release = 0; ^ Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Acked-by: Pavel Machek pa...@ucw.cz diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c b/drivers/staging/media/bcm2048/radio-bcm2048.c index e9d0691b21d3..5e11a78ceef3 100644 --- a/drivers

Re: [PATCH v6 05/10] leds: Add driver for AAT1290 flash LED controller

2015-04-30 Thread Pavel Machek
+struct aat1290_led_config_data { + /* maximum LED current in movie mode */ + u32 max_mm_current; + /* maximum LED current in flash mode */ + u32 max_flash_current; + /* maximum flash timeout */ + u32 max_flash_tm; Ok, the comments tell us what should be already

Re: [PATCH] radio-bcm2048: Enable access to automute and ctrl registers

2015-05-18 Thread Pavel Machek
On Fri 2015-05-15 23:31:51, Pali Rohár wrote: From: maxx m...@spaceboyz.net This enables access to automute function of the chip via sysfs and gives direct access to FM_AUDIO_CTRL0/1 registers, also via sysfs. I don't think this is so important but helps in developing radio scanner apps.

Re: [PATCH] radio-bcm2048: Fix region selection

2015-05-18 Thread Pavel Machek
On Sat 2015-05-16 17:20:50, Jan Roemisch wrote: Removed Japan wide band region since this is impossible to do just like that. Additionally it's now possible to go back to non-Japanese regions without having to reload the module. Acked-by: Pavel Machek pa...@ucw.cz But note that you'll

Re: [PATCH v8 1/1] media: i2c/adp1653: Devicetree support for adp1653

2015-04-15 Thread Pavel Machek
On Thu 2015-04-16 07:24:42, Sebastian Reichel wrote: Hi Sakari, Since this driver won't make it into 4.1 anyways, I have one more comment: Like this driver did not receive enough bikesheding. + } else { + gpiod_set_value(flash-platform_data-enable_gpio, on); + if

Re: [PATCH v8 1/1] media: i2c/adp1653: Devicetree support for adp1653

2015-04-16 Thread Pavel Machek
Hi! This will reduce complexity in the driver and should be fairly easy to implement, since there is no adp1653 platform code user in the mainline kernel anyways. I'd hate to break out of tree users for very little gain. ... So let's have a look at the advantages of removing the

Re: [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653

2015-04-13 Thread Pavel Machek
Hi! #define to_adp1653_flash(sd) container_of(sd, struct adp1653_flash, subdev) Let me know if you're going to send v8 or if I can make the changes. I think we're pretty much done then. You are free to make the changes. Thanks,

Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties

2015-04-03 Thread Pavel Machek
see? Date: Thu, 2 Apr 2015 22:30:44 +0200 From: Pavel Machek pa...@ucw.cz To: Sakari Ailus sakari.ai...@iki.fi Subject: Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653 Besides, I can't understand your point. Could you express it in other words, please? Typo in device tree would

Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties

2015-04-08 Thread Pavel Machek
-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16

Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties

2015-04-08 Thread Pavel Machek
Hi! I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Hello? It is 2015. Yes, that was nice rule... in 1995 or so :-). As I mentioned in the previous message in this subject, the max-microamp property

Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties

2015-04-08 Thread Pavel Machek
On Tue 2015-04-07 18:20:08, Bryan Wu wrote: On Fri, Apr 3, 2015 at 1:37 PM, Pavel Machek pa...@ucw.cz wrote: Hi! +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum

Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties

2015-04-02 Thread Pavel Machek
...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Acked-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b

  1   2   3   4   5   6   >