Hi,
Can you capture raw bayer images correctly? I assume green
means YUV buffers that are all zero.
Do you know more specifically which patch breaks it?
CCing freemangordon (Ivaylo Dimitrov). He tried to debug it
months ago but without success. Should know more info about this
problem.
I
Hi Pavel, Sakari,
On 11/19/2014 06:53 PM, Sakari Ailus wrote:
Hi Jacek and Pavel,
Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
Hi!
If the hardware LED changes with one that needs different current, the
block for the adp1653 stays the same, but
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
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
On 11/19/2014 10:45 AM, Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
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
Hi Pavel,
On 11/20/2014 01:12 PM, Pavel Machek wrote:
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:
-
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
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
Hi Jacek and Pavel,
Jacek Anaszewski wrote:
Hi Pavel, Sakari,
On 11/18/2014 05:51 PM, Pavel Machek wrote:
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
Hi Pavel,
Pavel Machek wrote:
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
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 below look acceptable?
I'll clean up driver code a bit
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
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
On 11/18/2014 09:46 AM, Pavel Machek wrote:
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
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
On 11/18/2014 12:32 PM, Pavel Machek wrote:
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
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
Hi Pavel,
On 11/18/2014 02:21 PM, Pavel Machek wrote:
Hi!
@@ -19,5 +30,10 @@ Examples:
system-status {
label = Status;
linux,default-trigger = heartbeat;
+ iout-torch = 500 500;
+ iout-flash = 1000 1000;
+ iout-indicator =
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
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
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.
Anything else obviously wrong?
Signed-off-by: Pavel
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.
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 in documentation, but does the binding below look
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 in
* Pavel Machek pa...@ucw.cz [141117 02:17]:
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:
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 below look acceptable?
I'll clean up driver code a bit more, remove the printks. Anything
else obviously wrong?
Jacek
On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
* Pavel Machek pa...@ucw.cz [141117 02:17]:
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
Hi Pali,
On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
* Pavel Machek pa...@ucw.cz [141117 02:17]:
On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
On Monday 17 November 2014 11:05:19 Pavel Machek wrote:
Hi!
* 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
binding should be added to the driver, but that removes a
On Monday 17 November 2014 16:04:07 Sakari Ailus wrote:
Hi Pali,
On Mon, Nov 17, 2014 at 04:01:31PM +0100, Pali Rohár wrote:
On Monday 17 November 2014 15:55:46 Tony Lindgren wrote:
* Pavel Machek pa...@ucw.cz [141117 02:17]:
On Mon 2014-11-17 11:09:45, Pali Rohár wrote:
On
On Monday 17 November 2014 16: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
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,
On 11/16/2014 08:59 AM, Pavel Machek wrote:
[...]
+ adp1653: adp1653@30 {
+ compatible = ad,adp1653;
The Analog Devices vendor prefix is adi.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
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)
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/arch/arm/boot/dts/omap3-n900.dts
index 739fcf2..ed0bfc1
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
35 matches
Mail list logo
