Re: [PATCH] media: s5p-jpeg: don't return a value on a void function
Hi Mauro,
Thank you for the patch.
On 04/20/2018 09:01 PM, Mauro Carvalho Chehab wrote:
> Building this driver on arm64 gives this warning:
> drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error:
> return expression in void function
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> index 0974b9a7a584..0861842b2dfc 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c
> @@ -425,9 +425,9 @@ unsigned int exynos3250_jpeg_get_int_status(void __iomem
> *regs)
> }
>
> void exynos3250_jpeg_clear_int_status(void __iomem *regs,
> - unsigned int value)
> + unsigned int value)
> {
> - return writel(value, regs + EXYNOS3250_JPGINTST);
> + writel(value, regs + EXYNOS3250_JPGINTST);
> }
>
> unsigned int exynos3250_jpeg_operating(void __iomem *regs)
>
Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
--
Best regards,
Jacek Anaszewski
Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label documentation, DT example
Hi Rob,
Any thoughts on my analysis? Do you think that LED function naming
standardization would really make sense having the abundance
of LED functions categories present in the mainline dts files?
The list of standard LED function names would have to be
continuously extended as people would be adding new boards.
Limiting users to only existing set of LED functions wouldn't
be practical IMHO.
I'd propose only to modify 'label' property description in LED common
bindings, so that it would explicitly state that it should contain only
"colour:functon" segments. It would be driver's responsibility to add
"devicename:" prefix to the label and use the whole string for a LED
class device name. Some drivers do that already. All DT bindings, dts
files and LED class drivers that don't adhere to this rule would have
to be updated accordingly.
Regarding colour - the "devicename:colour:function" LED device naming
convention defined in Documentation/leds/leds-class.txt is around for
a long time. Since LED colour can vary from board two board and is
independent of a driver, we have to have a means for defining it in
DT. Would you see providing separate 'colour' DT property as a solution?
Best regards,
Jacek Anaszewski
On 09/23/2017 11:12 PM, Jacek Anaszewski wrote:
> On 09/22/2017 11:07 PM, Jacek Anaszewski wrote:
>> On 09/20/2017 10:53 PM, Rob Herring wrote:
>>> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:
>>>> Hi Pavel,
>>>>
>>>> On 09/18/2017 10:54 PM, Pavel Machek wrote:
>>>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>>> Specify the exact label used if the label property is omitted in DT, as
>>>>>>>> well as use label in the example that conforms to LED device naming.
>>>>>>>>
>>>>>>>> @@ -69,11 +73,11 @@ Example
>>>>>>>>flash-max-microamp = <32>;
>>>>>>>>led-max-microamp = <6>;
>>>>>>>>ams,input-max-microamp = <175>;
>>>>>>>> - label = "as3645a:flash";
>>>>>>>> + label = "as3645a:white:flash";
>>>>>>>>};
>>>>>>>>indicator@1 {
>>>>>>>>reg = <0x1>;
>>>>>>>>led-max-microamp = <1>;
>>>>>>>> - label = "as3645a:indicator";
>>>>>>>> + label = "as3645a:red:indicator";
>>>>>>>>};
>>>>>>>>};
>>>>>>>
>>>>>>> Ok, but userspace still has no chance to determine if this is flash
>>>>>>> from main camera or flash for front camera; todays smartphones have
>>>>>>> flashes on both cameras.
>>>>>>>
>>>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or
>>>>>>> ?
>>>>>>
>>>>>> If there's just a single one in the device, could you use that?
>>>>>>
>>>>>> Even if we name this so for N9 (and N900), the application still would
>>>>>> only
>>>>>> work with the two devices.
>>>>>
>>>>> Well, I'd plan to name it on other devices, too.
>>>>>
>>>>>> My suggestion would be to look for a flash LED, and perhaps the maximum
>>>>>> current as well. That should generally work better than assumptions on
>>>>>> the
>>>>>> label.
>>>>>
>>>>> If you just look for flash LED, you don't know if it is front one or
>>>>> back one. Its true that if you have just one flash it is usually on
>>>>> the back camera, but you can't know if maybe driver is not available
>>>>> for the main flash.
>>>>>
>>>>> Lets get this right, please "main_camera_flash" is 12 bytes more than
>>>>> "flash", and it saves application logic.. more than 12 bytes, I'm sure.
>>>>
>>>> What you are trying to introduce is yet another level of LED class
Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label documentation, DT example
On 09/22/2017 11:07 PM, Jacek Anaszewski wrote:
> On 09/20/2017 10:53 PM, Rob Herring wrote:
>> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:
>>> Hi Pavel,
>>>
>>> On 09/18/2017 10:54 PM, Pavel Machek wrote:
>>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:
>>>>> Hi Pavel,
>>>>>
>>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>>> Specify the exact label used if the label property is omitted in DT, as
>>>>>>> well as use label in the example that conforms to LED device naming.
>>>>>>>
>>>>>>> @@ -69,11 +73,11 @@ Example
>>>>>>> flash-max-microamp = <32>;
>>>>>>> led-max-microamp = <6>;
>>>>>>> ams,input-max-microamp = <175>;
>>>>>>> - label = "as3645a:flash";
>>>>>>> + label = "as3645a:white:flash";
>>>>>>> };
>>>>>>> indicator@1 {
>>>>>>> reg = <0x1>;
>>>>>>> led-max-microamp = <1>;
>>>>>>> - label = "as3645a:indicator";
>>>>>>> + label = "as3645a:red:indicator";
>>>>>>> };
>>>>>>> };
>>>>>>
>>>>>> Ok, but userspace still has no chance to determine if this is flash
>>>>>> from main camera or flash for front camera; todays smartphones have
>>>>>> flashes on both cameras.
>>>>>>
>>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or
>>>>>> ?
>>>>>
>>>>> If there's just a single one in the device, could you use that?
>>>>>
>>>>> Even if we name this so for N9 (and N900), the application still would
>>>>> only
>>>>> work with the two devices.
>>>>
>>>> Well, I'd plan to name it on other devices, too.
>>>>
>>>>> My suggestion would be to look for a flash LED, and perhaps the maximum
>>>>> current as well. That should generally work better than assumptions on the
>>>>> label.
>>>>
>>>> If you just look for flash LED, you don't know if it is front one or
>>>> back one. Its true that if you have just one flash it is usually on
>>>> the back camera, but you can't know if maybe driver is not available
>>>> for the main flash.
>>>>
>>>> Lets get this right, please "main_camera_flash" is 12 bytes more than
>>>> "flash", and it saves application logic.. more than 12 bytes, I'm sure.
>>>
>>> What you are trying to introduce is yet another level of LED class
>>> device naming standard, one level below devicename:colour:function.
>>> It seems you want also to come up with the set of standarized LED
>>> function names. This would certainly have to be covered for consistency.
>>
>> I really dislike how this naming convention is used for label. label is
>> supposed to be the phyically identifiable name. Having the devicename
>> defeats that. Perhaps color, too. We'd be better off with a color
>> property. It seems we're overloading the naming with too many things.
>> Now we're adding device association.
>
> Regarding devicename - there is indeed inconsistency in the way how LED
> DT bindings use label, as some of them use it for defining full LED
> class device name, and the rest fill only colour and function, leaving
> addition of a devicename to the driver.
>
> The problem is also in current definition of label in LED common
> bindings documentation, which says:
>
> "It has to uniquely identify a device, i.e. no other LED class device
> can be assigned the same label."
>
> In view of your above words this is not true, and we probably should
> remove this sentence (it doesn't have DT maintainer ack btw).
>
>> I do want to see standard names though. On 96boards for example, there
>> are defined LEDs and locations. The function on some are defined (e.g.
>> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see
>> the same
Re: [PATCH v3 0/4] AS3645A fixes
Hi Sakari, On 09/22/2017 11:25 PM, Sakari Ailus wrote: > Hi Jacek, > > (Fixed DT list address.) > > Jacek Anaszewski wrote: >> Hi Sakari, >> >> On 09/22/2017 11:32 AM, Sakari Ailus wrote: >>> Hi Jacek and others, >>> >>> Here are a few fixes for the as3645a DTS as well as changes in bindings. >>> The driver is not in a release yet. >>> >>> Jacek: Could you take these to your fixes branch so we don't get >>> faulty DT >>> bindings to a release? I've dropped the patches related to LED naming >>> and >>> label property as the discusion appears to continue on that. >> >> No problem. One question - isn't patch 3/4 missing? > > Hmm. I can see it on both linux-leds and devicetree. > > I've pushed the four patches here, on v4.14-rc1: > > <URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=as3645a-fix> I turned out that gmail treated your patches as spam due to your "resend" patch set. Patch set applied to the fixes-4.14-rc3 branch of linux-leds.git. -- Best regards, Jacek Anaszewski
Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label documentation, DT example
On 09/20/2017 10:53 PM, Rob Herring wrote:
> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:
>> Hi Pavel,
>>
>> On 09/18/2017 10:54 PM, Pavel Machek wrote:
>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:
>>>> Hi Pavel,
>>>>
>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>> Specify the exact label used if the label property is omitted in DT, as
>>>>>> well as use label in the example that conforms to LED device naming.
>>>>>>
>>>>>> @@ -69,11 +73,11 @@ Example
>>>>>> flash-max-microamp = <32>;
>>>>>> led-max-microamp = <6>;
>>>>>> ams,input-max-microamp = <175>;
>>>>>> -label = "as3645a:flash";
>>>>>> +label = "as3645a:white:flash";
>>>>>> };
>>>>>> indicator@1 {
>>>>>> reg = <0x1>;
>>>>>> led-max-microamp = <1>;
>>>>>> -label = "as3645a:indicator";
>>>>>> +label = "as3645a:red:indicator";
>>>>>> };
>>>>>> };
>>>>>
>>>>> Ok, but userspace still has no chance to determine if this is flash
>>>>> from main camera or flash for front camera; todays smartphones have
>>>>> flashes on both cameras.
>>>>>
>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or
>>>>> ?
>>>>
>>>> If there's just a single one in the device, could you use that?
>>>>
>>>> Even if we name this so for N9 (and N900), the application still would only
>>>> work with the two devices.
>>>
>>> Well, I'd plan to name it on other devices, too.
>>>
>>>> My suggestion would be to look for a flash LED, and perhaps the maximum
>>>> current as well. That should generally work better than assumptions on the
>>>> label.
>>>
>>> If you just look for flash LED, you don't know if it is front one or
>>> back one. Its true that if you have just one flash it is usually on
>>> the back camera, but you can't know if maybe driver is not available
>>> for the main flash.
>>>
>>> Lets get this right, please "main_camera_flash" is 12 bytes more than
>>> "flash", and it saves application logic.. more than 12 bytes, I'm sure.
>>
>> What you are trying to introduce is yet another level of LED class
>> device naming standard, one level below devicename:colour:function.
>> It seems you want also to come up with the set of standarized LED
>> function names. This would certainly have to be covered for consistency.
>
> I really dislike how this naming convention is used for label. label is
> supposed to be the phyically identifiable name. Having the devicename
> defeats that. Perhaps color, too. We'd be better off with a color
> property. It seems we're overloading the naming with too many things.
> Now we're adding device association.
Regarding devicename - there is indeed inconsistency in the way how LED
DT bindings use label, as some of them use it for defining full LED
class device name, and the rest fill only colour and function, leaving
addition of a devicename to the driver.
The problem is also in current definition of label in LED common
bindings documentation, which says:
"It has to uniquely identify a device, i.e. no other LED class device
can be assigned the same label."
In view of your above words this is not true, and we probably should
remove this sentence (it doesn't have DT maintainer ack btw).
> I do want to see standard names though. On 96boards for example, there
> are defined LEDs and locations. The function on some are defined (e.g.
> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see
> the same label across all boards.
Currently we have following LED functions (obtained with
grep label Documentation/devicetree/bindings/leds/* | sed
s'/^.*label/label/g' | awk -F"=" '{print $2}' | sed '/^$/d' | sed
s'/.*:\(.*\)";/\1/' | sed '/^\s\{1,\}/d' | sort -u)
0
1
2
2g
3
4
5
6
7
adsl
alarm
alive
aux
broadband
chrg
dsl
flash
green
indicator
inet
keypad
phone
power
red
sata
sata0
sata1
tel
tv
upgrading
usb
usr0
usr1
usr35
wan
white
wireless
wps
yellow
By extracting numerical pattern names and replacing numbers with N
we're getting something like this:
N
Ng
colour
adsl
alarm
alive
aux
broadband
chrg
dsl
flash
indicator
inet
keypad
phone
power
sataN
tel
tv
upgrading
usb
usrN
wan
wireless
wps
Is this list something you'd like to see as a base of standard LED
functions? It seems that this list would have to be continuously
supplemented with new positions.
--
Best regards,
Jacek Anaszewski
Re: [PATCH v3 0/4] AS3645A fixes
Hi Sakari, On 09/22/2017 11:32 AM, Sakari Ailus wrote: > Hi Jacek and others, > > Here are a few fixes for the as3645a DTS as well as changes in bindings. > The driver is not in a release yet. > > Jacek: Could you take these to your fixes branch so we don't get faulty DT > bindings to a release? I've dropped the patches related to LED naming and > label property as the discusion appears to continue on that. No problem. One question - isn't patch 3/4 missing? Best regards, Jacek Anaszewski > Thanks. > > > since v2: > > - Drop patches related to LED naming. > > - No other changes. > > since v1: > > - Add LED colour to the name of the LED, this adds two patches to the set. > > - Add a patch to unregister the indicator LED in driver remove function. > > - No changes to v1 patches. > > Sakari Ailus (4): > as3645a: Use ams,input-max-microamp as documented in DT bindings > dt: bindings: as3645a: Use LED number to refer to LEDs > as3645a: Use integer numbers for parsing LEDs > as3645a: Unregister indicator LED on device unbind > > .../devicetree/bindings/leds/ams,as3645a.txt | 28 + > arch/arm/boot/dts/omap3-n950-n9.dtsi | 10 +--- > drivers/leds/leds-as3645a.c| 29 > +++--- > 3 files changed, 51 insertions(+), 16 deletions(-) >
Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label documentation, DT example
Hi Pavel,
On 09/18/2017 10:54 PM, Pavel Machek wrote:
> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:
>> Hi Pavel,
>>
>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:
>>> Hi!
>>>
>>>> Specify the exact label used if the label property is omitted in DT, as
>>>> well as use label in the example that conforms to LED device naming.
>>>>
>>>> @@ -69,11 +73,11 @@ Example
>>>>flash-max-microamp = <32>;
>>>>led-max-microamp = <6>;
>>>>ams,input-max-microamp = <175>;
>>>> - label = "as3645a:flash";
>>>> + label = "as3645a:white:flash";
>>>>};
>>>>indicator@1 {
>>>>reg = <0x1>;
>>>>led-max-microamp = <1>;
>>>> - label = "as3645a:indicator";
>>>> + label = "as3645a:red:indicator";
>>>>};
>>>>};
>>>
>>> Ok, but userspace still has no chance to determine if this is flash
>>> from main camera or flash for front camera; todays smartphones have
>>> flashes on both cameras.
>>>
>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or
>>> ?
>>
>> If there's just a single one in the device, could you use that?
>>
>> Even if we name this so for N9 (and N900), the application still would only
>> work with the two devices.
>
> Well, I'd plan to name it on other devices, too.
>
>> My suggestion would be to look for a flash LED, and perhaps the maximum
>> current as well. That should generally work better than assumptions on the
>> label.
>
> If you just look for flash LED, you don't know if it is front one or
> back one. Its true that if you have just one flash it is usually on
> the back camera, but you can't know if maybe driver is not available
> for the main flash.
>
> Lets get this right, please "main_camera_flash" is 12 bytes more than
> "flash", and it saves application logic.. more than 12 bytes, I'm sure.
What you are trying to introduce is yet another level of LED class
device naming standard, one level below devicename:colour:function.
It seems you want also to come up with the set of standarized LED
function names. This would certainly have to be covered for consistency.
--
Best regards,
Jacek Anaszewski
Re: as3645a flash userland interface
On 09/12/2017 11:55 PM, Pavel Machek wrote: > On Tue 2017-09-12 20:53:33, Jacek Anaszewski wrote: >> Hi Pavel, >> >> On 09/12/2017 12:36 PM, Pavel Machek wrote: >>> Hi! >>> >>> There were some changes to as3645a flash controller. Before we have >>> stable interface we have to keep forever I want to ask: >> >> Note that we have already two LED flash class drivers - leds-max77693 >> and leds-aat1290. They have been present in mainline for over two years >> now. > > Well.. that's ok. No change there is neccessary. > >>> What directory are the flash controls in? >>> >>> /sys/class/leds/led-controller:flash ? >>> >>> Could we arrange for something less generic, like >>> >>> /sys/class/leds/main-camera:flash ? >> >> I'd rather avoid overcomplicating this. LED class device name pattern >> is well defined to devicename:colour:function >> (see Documentation/leds/leds-class.txt, "LED Device Naming" section). >> >> In this case "flash" in place of the "function" segment makes the >> things clear enough I suppose. > > It does not. > > Phones usually have two cameras, front and back, and these days both > cameras have their flash. > > And poor userspace flashlight application can not know if as3645 > drivers front LED or back LED. Thus, I'd set devicename to > front-camera or main-camera -- because that's what it is associated > with. Userspace does not care what hardware drives the LED, but needs > to know if it is front or back camera. The name of a LED flash class device isn't fixed and is derived from DT label property. Name in the example of some DT bindings will not force people to apply similar pattern for the other drivers and even for the related one. No worry about having to keep anything forever basing on that. -- Best regards, Jacek Anaszewski
Re: as3645a flash userland interface
Hi Pavel, On 09/12/2017 12:36 PM, Pavel Machek wrote: > Hi! > > There were some changes to as3645a flash controller. Before we have > stable interface we have to keep forever I want to ask: Note that we have already two LED flash class drivers - leds-max77693 and leds-aat1290. They have been present in mainline for over two years now. > What directory are the flash controls in? > > /sys/class/leds/led-controller:flash ? > > Could we arrange for something less generic, like > > /sys/class/leds/main-camera:flash ? I'd rather avoid overcomplicating this. LED class device name pattern is well defined to devicename:colour:function (see Documentation/leds/leds-class.txt, "LED Device Naming" section). In this case "flash" in place of the "function" segment makes the things clear enough I suppose. -- Best regards, Jacek Anaszewski
Re: [PATCH v9 18/24] as3645a: Switch to fwnode property API
Hi Sakari, On 09/09/2017 11:36 PM, Sakari Ailus wrote: > Hi Jacek, > > On Sat, Sep 09, 2017 at 09:06:41PM +0200, Jacek Anaszewski wrote: >> Hi Sakari, >> >> I've come across this patch only by a chance. I believe that merging >> leds-as3645a.c patches via media tree is not going to be a persistent >> pattern. At least we haven't agreed on that, and in any case I should >> have a possibility to give my ack for this patch. > > Correct. The reason the previous patches went through linux-media was > because these patches dependend on other patches only in linux-media at the > time. This is no longer the case (the three as3645a patches I'd like to get > in as fixes are another matter but let's discuss that separately). > >> >> Would you mind also adding linux-leds list on cc when touching areas >> related to LED/flash devices? > > I added this patch to this version of the set and missed cc'ing it to > linux-leds. I think I'll send it there separately once the 17th patch (ACPI > support) has been reviewed. The two are loosely related to the rest of the > patches in the set but there's no hard dependency. Right, they are loosely related, but cross-posting anything having "LED" in its contents to linux-leds list would be understandable if not desirable :-) Just to keep LED people in sync. -- Best regards, Jacek Anaszewski
Re: [PATCH v9 18/24] as3645a: Switch to fwnode property API
Hi Sakari,
I've come across this patch only by a chance. I believe that merging
leds-as3645a.c patches via media tree is not going to be a persistent
pattern. At least we haven't agreed on that, and in any case I should
have a possibility to give my ack for this patch.
Would you mind also adding linux-leds list on cc when touching areas
related to LED/flash devices?
Thanks in advance.
Best regards,
Jacek Anaszewski
On 09/08/2017 03:18 PM, Sakari Ailus wrote:
> Switch the as3645a from OF to the fwnode property API. Also add ACPI
> support.
>
> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> ---
> drivers/leds/leds-as3645a.c | 81
> +
> 1 file changed, 46 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
> index 605e0c64e974..2e73c3f818f1 100644
> --- a/drivers/leds/leds-as3645a.c
> +++ b/drivers/leds/leds-as3645a.c
> @@ -25,7 +25,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
>
> #include
> @@ -148,8 +148,8 @@ struct as3645a {
> struct v4l2_flash *vf;
> struct v4l2_flash *vfind;
>
> - struct device_node *flash_node;
> - struct device_node *indicator_node;
> + struct fwnode_handle *flash_node;
> + struct fwnode_handle *indicator_node;
>
> struct as3645a_config cfg;
>
> @@ -492,30 +492,33 @@ static int as3645a_detect(struct as3645a *flash)
>
> static int as3645a_parse_node(struct as3645a *flash,
> struct as3645a_names *names,
> - struct device_node *node)
> + struct fwnode_handle *fwnode)
> {
> struct as3645a_config *cfg = >cfg;
> - struct device_node *child;
> + struct fwnode_handle *child;
> const char *name;
> + const char *str;
> int rval;
>
> - for_each_child_of_node(node, child) {
> + fwnode_for_each_child_node(fwnode, child) {
> u32 id = 0;
>
> - of_property_read_u32(child, "reg", );
> + fwnode_property_read_u32(
> + child, is_of_node(child) ? "reg" : "led", );
>
> switch (id) {
> case AS_LED_FLASH:
> - flash->flash_node = of_node_get(child);
> + flash->flash_node = child;
> break;
> case AS_LED_INDICATOR:
> - flash->indicator_node = of_node_get(child);
> + flash->indicator_node = child;
> break;
> default:
> dev_warn(>client->dev,
>"unknown LED %u encountered, ignoring\n", id);
> break;
> }
> + fwnode_handle_get(child);
> }
>
> if (!flash->flash_node) {
> @@ -523,14 +526,18 @@ static int as3645a_parse_node(struct as3645a *flash,
> return -ENODEV;
> }
>
> - rval = of_property_read_string(flash->flash_node, "label", );
> - if (!rval)
> + rval = fwnode_property_read_string(flash->flash_node, "label", );
> + if (!rval) {
> strlcpy(names->flash, name, sizeof(names->flash));
> - else
> + } else if (is_of_node(fwnode)) {
> snprintf(names->flash, sizeof(names->flash),
> - "%s:flash", node->name);
> + "%s:flash", to_of_node(fwnode)->name);
> + } else {
> + dev_err(>client->dev, "flash node has no label!\n");
> + return -EINVAL;
> + }
>
> - rval = of_property_read_u32(flash->flash_node, "flash-timeout-us",
> + rval = fwnode_property_read_u32(flash->flash_node, "flash-timeout-us",
> >flash_timeout_us);
> if (rval < 0) {
> dev_err(>client->dev,
> @@ -538,7 +545,7 @@ static int as3645a_parse_node(struct as3645a *flash,
> goto out_err;
> }
>
> - rval = of_property_read_u32(flash->flash_node, "flash-max-microamp",
> + rval = fwnode_property_read_u32(flash->flash_node, "flash-max-microamp",
> >flash_max_ua);
> if (rval < 0) {
> dev_err(>client->dev,
> @@ -546,7 +553,7 @@ static int as3645a_parse_node(struct as3645a *flash,
> goto out_err;
> }
>
> - rval = of_pr
Re: [PATCH 0/3] AS3645A fixes
Hi Sakari, Thanks for the patch set. On 09/08/2017 02:42 PM, Sakari Ailus wrote: > Hi folks, > > Here are a few fixes for the as3645a DTS as well as changes in bindings. > The driver is not in a release yet. I'd like to get these in as through > the media tree fixes branch. > > Sakari Ailus (3): > as3645a: Use ams,input-max-microamp as documented in DT bindings > dt: bindings: as3645a: Use LED number to refer to LEDs > as3645a: Use integer numbers for parsing LEDs > > .../devicetree/bindings/leds/ams,as3645a.txt | 28 > ++ > arch/arm/boot/dts/omap3-n950-n9.dtsi | 10 +--- > drivers/leds/leds-as3645a.c| 28 > +++--- > 3 files changed, 50 insertions(+), 16 deletions(-) > Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> -- Best regards, Jacek Anaszewski
Re: [PATCH v2 1/3] dt: bindings: Document DT bindings for Analog devices as3645a
Hi Sakari,
Thanks for the update.
On 08/19/2017 11:24 PM, Sakari Ailus wrote:
> From: Sakari Ailus <sakari.ai...@iki.fi>
>
> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> ---
> .../devicetree/bindings/leds/ams,as3645a.txt | 71
> ++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ams,as3645a.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> new file mode 100644
> index ..12c5ef26ec73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> @@ -0,0 +1,71 @@
> +Analog devices AS3645A device tree bindings
> +
> +The AS3645A flash LED controller can drive two LEDs, one high current
> +flash LED and one indicator LED. The high current flash LED can be
> +used in torch mode as well.
> +
> +Ranges below noted as [a, b] are closed ranges between a and b, i.e. a
> +and b are included in the range.
> +
> +Please also see common.txt in the same directory.
> +
> +
> +Required properties
> +===
> +
> +compatible : Must be "ams,as3645a".
> +reg : The I2C address of the device. Typically 0x30.
> +
> +
> +Required properties of the "flash" child node
> +=
> +
> +flash-timeout-us: Flash timeout in microseconds. The value must be in
> + the range [10, 85] and divisible by 5.
> +flash-max-microamp: Maximum flash current in microamperes. Has to be
> + in the range between [20, 50] and
> + divisible by 2.
> +led-max-microamp: Maximum torch (assist) current in microamperes. The
> + value must be in the range between [2, 16] and
> + divisible by 2.
> +ams,input-max-microamp: Maximum flash controller input current. The
> + value must be in the range [125, 200]
> + and divisible by 5.
> +
> +
> +Optional properties of the "flash" child node
> +=
> +
> +label: The label of the flash LED.
> +
> +
> +Required properties of the "indicator" child node
> +=
> +
> +led-max-microamp: Maximum indicator current. The allowed values are
> + 2500, 5000, 7500 and 1.
> +
> +Optional properties of the "indicator" child node
> +=
> +
> +label: The label of the indicator LED.
> +
> +
> +Example
> +===
> +
> + as3645a@30 {
> + reg = <0x30>;
> + compatible = "ams,as3645a";
> + flash {
> + flash-timeout-us = <15>;
> + flash-max-microamp = <32>;
> + led-max-microamp = <6>;
> + ams,input-max-microamp = <175>;
> + label = "as3645a:flash";
> + };
> + indicator {
> + led-max-microamp = <1>;
> + label = "as3645a:indicator";
> + };
> + };
>
For the patch going through media tree:
Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
--
Best regards,
Jacek Anaszewski
Re: [PATCH v2.1 2/3] leds: as3645a: Add LED flash class driver
Hi Sakari,
On 08/21/2017 03:53 PM, Sakari Ailus wrote:
> Hi Jacek,
>
> Jacek Anaszewski wrote:
>> Hi Sakari,
>>
>> Thanks for the update.
>> I've noticed that you added node labels to the child device nodes
>> in [0]:
>>
>> "as3645a_flash : flash" and "as3645a_indicator : indicator"
>
> The phandle references (as3645a_flash and as3645a_indicator) should
> actually be moved to the patch adding the flash property to the sensor
> device node. It doesn't do anything here, yet.
>
>>
>> I am still seeing problems with this approach:
>>
>> 1) AFAIK these labels are only used for referencing nodes inside dts
>>files and they don't affect the name property of struct device_node
>
> That's right.
>
>> 2) Even if you changed the node name from flash to as3645a_flash, you
>>would get weird LED class device name "as3645a_flash:flash" in case
>>label property is absent. Do you have any objections against the
>>approach I proposed in the previous review?:
>>
>>
>> snprintf(names->flash, sizeof(names->flash),
>> AS_NAME":%s", node->name);
>
> In the current patch, the device node of the flash controller is used,
> postfixed with colon and the name of the LED ("flash" or "indicator") if
> no label is defined. In other words, with that DT source you'll have
> "as3645a:flash" and "as3645a:indicator". So if you change the name of
> the device node of the I²C device, that will be reflected in the label.
>
> If a label exists, then the label is used as such.
>
> I don't really have objections to what you're proposing as such but my
> question is: is it useful? With that, the flash and indicator labels
> will not come from DT if label properties are undefined. They'll always
> be "as3645a:flash" and "as3645a:indicator", independently of the names
> of the device nodes.
>
Ah, indeed, the node->name is put in place of devicename segment and
the node points to the LED controller node. Neat approach, likely to
be adopted as a pattern from now on for all new LED class drivers.
For the patch going through media tree:
Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
--
Best regards,
Jacek Anaszewski
Re: [PATCH v2.1 2/3] leds: as3645a: Add LED flash class driver
Forgot to add a link to the referenced patch: [0] http://www.spinics.net/lists/devicetree/msg191273.html On 08/20/2017 12:09 PM, Jacek Anaszewski wrote: > Hi Sakari, > > Thanks for the update. > I've noticed that you added node labels to the child device nodes > in [0]: > > "as3645a_flash : flash" and "as3645a_indicator : indicator" > > I am still seeing problems with this approach: > > 1) AFAIK these labels are only used for referencing nodes inside dts >files and they don't affect the name property of struct device_node > 2) Even if you changed the node name from flash to as3645a_flash, you >would get weird LED class device name "as3645a_flash:flash" in case >label property is absent. Do you have any objections against the >approach I proposed in the previous review?: > > > snprintf(names->flash, sizeof(names->flash), >AS_NAME":%s", node->name); > > Best regards, > Jacek Anaszewski > > On 08/19/2017 11:42 PM, Sakari Ailus wrote: >> From: Sakari Ailus <sakari.ai...@iki.fi> >> >> Add a LED flash class driver for the as3654a flash controller. A V4L2 flash >> driver for it already exists (drivers/media/i2c/as3645a.c), and this driver >> is based on that. >> >> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> >> --- >> Well. The driver does not control explicit power resources nor it used >> runtime PM. Remove references to it. >> >> MAINTAINERS | 6 + >> drivers/leds/Kconfig| 8 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-as3645a.c | 763 >> >> 4 files changed, 778 insertions(+) >> create mode 100644 drivers/leds/leds-as3645a.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 931abca006b7..8f40ba2e5303 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2124,6 +2124,12 @@ F:arch/arm64/ >> F: Documentation/arm64/ >> >> AS3645A LED FLASH CONTROLLER DRIVER >> +M: Sakari Ailus <sakari.ai...@iki.fi> >> +L: linux-l...@vger.kernel.org >> +S: Maintained >> +F: drivers/leds/leds-as3645a.c >> + >> +AS3645A LED FLASH CONTROLLER DRIVER >> M: Laurent Pinchart <laurent.pinch...@ideasonboard.com> >> L: linux-media@vger.kernel.org >> T: git git://linuxtv.org/media_tree.git >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 594b24d410c3..bad3a4098104 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -58,6 +58,14 @@ config LEDS_AAT1290 >> help >> This option enables support for the LEDs on the AAT1290. >> >> +config LEDS_AS3645A >> +tristate "AS3645A LED flash controller support" >> +depends on I2C && LEDS_CLASS_FLASH >> +help >> + Enable LED flash class support for AS3645A LED flash >> + controller. V4L2 flash API is provided as well if >> + CONFIG_V4L2_FLASH_API is enabled. >> + >> config LEDS_BCM6328 >> tristate "LED Support for Broadcom BCM6328" >> depends on LEDS_CLASS >> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >> index 909dae62ba05..7d7b26552923 100644 >> --- a/drivers/leds/Makefile >> +++ b/drivers/leds/Makefile >> @@ -8,6 +8,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o >> # LED Platform Drivers >> obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o >> obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o >> +obj-$(CONFIG_LEDS_AS3645A) += leds-as3645a.o >> obj-$(CONFIG_LEDS_BCM6328) += leds-bcm6328.o >> obj-$(CONFIG_LEDS_BCM6358) += leds-bcm6358.o >> obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o >> diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c >> new file mode 100644 >> index ..e0898233 >> --- /dev/null >> +++ b/drivers/leds/leds-as3645a.c >> @@ -0,0 +1,763 @@ >> +/* >> + * drivers/leds/leds-as3645a.c - AS3645A and LM3555 flash controllers driver >> + * >> + * Copyright (C) 2008-2011 Nokia Corporation >> + * Copyright (c) 2011, 2017 Intel Corporation. >> + * >> + * Based on drivers/media/i2c/as3645a.c. >> + * >> + * Contact: Sakari Ailus <sakari.ai...@iki.fi> >> + * >> + * 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 Fou
Re: [PATCH v2.1 2/3] leds: as3645a: Add LED flash class driver
Hi Sakari, Thanks for the update. I've noticed that you added node labels to the child device nodes in [0]: "as3645a_flash : flash" and "as3645a_indicator : indicator" I am still seeing problems with this approach: 1) AFAIK these labels are only used for referencing nodes inside dts files and they don't affect the name property of struct device_node 2) Even if you changed the node name from flash to as3645a_flash, you would get weird LED class device name "as3645a_flash:flash" in case label property is absent. Do you have any objections against the approach I proposed in the previous review?: snprintf(names->flash, sizeof(names->flash), AS_NAME":%s", node->name); Best regards, Jacek Anaszewski On 08/19/2017 11:42 PM, Sakari Ailus wrote: > From: Sakari Ailus <sakari.ai...@iki.fi> > > Add a LED flash class driver for the as3654a flash controller. A V4L2 flash > driver for it already exists (drivers/media/i2c/as3645a.c), and this driver > is based on that. > > Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> > --- > Well. The driver does not control explicit power resources nor it used > runtime PM. Remove references to it. > > MAINTAINERS | 6 + > drivers/leds/Kconfig| 8 + > drivers/leds/Makefile | 1 + > drivers/leds/leds-as3645a.c | 763 > > 4 files changed, 778 insertions(+) > create mode 100644 drivers/leds/leds-as3645a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 931abca006b7..8f40ba2e5303 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2124,6 +2124,12 @@ F: arch/arm64/ > F: Documentation/arm64/ > > AS3645A LED FLASH CONTROLLER DRIVER > +M: Sakari Ailus <sakari.ai...@iki.fi> > +L: linux-l...@vger.kernel.org > +S: Maintained > +F: drivers/leds/leds-as3645a.c > + > +AS3645A LED FLASH CONTROLLER DRIVER > M: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > L: linux-media@vger.kernel.org > T: git git://linuxtv.org/media_tree.git > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 594b24d410c3..bad3a4098104 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -58,6 +58,14 @@ config LEDS_AAT1290 > help >This option enables support for the LEDs on the AAT1290. > > +config LEDS_AS3645A > + tristate "AS3645A LED flash controller support" > + depends on I2C && LEDS_CLASS_FLASH > + help > + Enable LED flash class support for AS3645A LED flash > + controller. V4L2 flash API is provided as well if > + CONFIG_V4L2_FLASH_API is enabled. > + > config LEDS_BCM6328 > tristate "LED Support for Broadcom BCM6328" > depends on LEDS_CLASS > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > index 909dae62ba05..7d7b26552923 100644 > --- a/drivers/leds/Makefile > +++ b/drivers/leds/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o > # LED Platform Drivers > obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o > obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o > +obj-$(CONFIG_LEDS_AS3645A) += leds-as3645a.o > obj-$(CONFIG_LEDS_BCM6328) += leds-bcm6328.o > obj-$(CONFIG_LEDS_BCM6358) += leds-bcm6358.o > obj-$(CONFIG_LEDS_BD2802)+= leds-bd2802.o > diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c > new file mode 100644 > index ..e0898233 > --- /dev/null > +++ b/drivers/leds/leds-as3645a.c > @@ -0,0 +1,763 @@ > +/* > + * drivers/leds/leds-as3645a.c - AS3645A and LM3555 flash controllers driver > + * > + * Copyright (C) 2008-2011 Nokia Corporation > + * Copyright (c) 2011, 2017 Intel Corporation. > + * > + * Based on drivers/media/i2c/as3645a.c. > + * > + * Contact: Sakari Ailus <sakari.ai...@iki.fi> > + * > + * 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. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define AS_TIMER_US_TO_CODE(t) (((t) / 1000 - 100) / > 50) > +#def
Re: [PATCH 2/3] leds: as3645a: Add LED flash class driver
goto out_err;
> + }
> +
> + of_property_read_u32(flash->flash_node, "voltage-reference",
> + >voltage_reference);
> +
> + of_property_read_u32(flash->flash_node, "peak-current-limit",
> + >peak);
> + cfg->peak = AS_PEAK_mA_TO_REG(cfg->peak);
> +
> + flash->indicator_node = of_get_child_by_name(node, "indicator");
> + if (!flash->indicator_node) {
> + dev_warn(>client->dev,
> + "can't find indicator node\n");
> + goto out_err;
> + }
> +
> + rval = of_property_read_string(flash->indicator_node, "label", );
> + if (!rval)
> + strlcpy(names->indicator, name, sizeof(names->indicator));
> + else
> + snprintf(names->indicator, sizeof(names->indicator),
> + "%s:indicator", node->name);
snprintf(names->indicator, sizeof(names->indicator),
AS_NAME":%s", node->name);
> +
> + rval = of_property_read_u32(flash->indicator_node, "led-max-microamp",
> + >indicator_max_ua);
> + if (rval < 0) {
> + dev_err(>client->dev,
> + "can't read led-max-microamp property for indicator\n");
> + goto out_err;
> + }
> +
> + return 0;
> +
> +out_err:
> + of_node_put(flash->flash_node);
> + of_node_put(flash->indicator_node);
> +
> + return rval;
> +}
> +
> +static int as3645a_led_class_setup(struct as3645a *flash,
> +struct as3645a_names *names)
> +{
> + struct led_classdev *fled_cdev = >fled.led_cdev;
> + struct led_classdev *iled_cdev = >iled_cdev;
> + struct led_flash_setting *cfg;
> + int rval;
> +
> + iled_cdev->name = names->indicator;
> + iled_cdev->brightness_set_blocking = as3645a_set_indicator_brightness;
> + iled_cdev->max_brightness =
> + flash->cfg.indicator_max_ua / AS_INDICATOR_INTENSITY_STEP;
> +
> + rval = led_classdev_register(>client->dev, iled_cdev);
> + if (rval < 0)
> + return rval;
> +
> + cfg = >fled.brightness;
> + cfg->min = AS_FLASH_INTENSITY_MIN;
> + cfg->max = flash->cfg.flash_max_ua;
> + cfg->step = AS_FLASH_INTENSITY_STEP;
> + cfg->val = flash->cfg.flash_max_ua;
> +
> + cfg = >fled.timeout;
> + cfg->min = AS_FLASH_TIMEOUT_MIN;
> + cfg->max = flash->cfg.flash_timeout_us;
> + cfg->step = AS_FLASH_TIMEOUT_STEP;
> + cfg->val = flash->cfg.flash_timeout_us;
> +
> + flash->fled.ops = _led_flash_ops;
> +
> + fled_cdev->name = names->flash;
> + fled_cdev->brightness_set_blocking = as3645a_set_assist_brightness;
> + /* Value 0 is off in LED class. */
> + fled_cdev->max_brightness =
> + as3645a_current_to_reg(flash, false,
> +flash->cfg.assist_max_ua) + 1;
> + fled_cdev->flags = LED_DEV_CAP_FLASH;
> +
> + rval = led_classdev_flash_register(>client->dev, >fled);
> + if (rval) {
> + led_classdev_unregister(iled_cdev);
> + dev_err(>client->dev,
> + "led_classdev_flash_register() failed, error %d\n",
> + rval);
> + }
> +
> + return rval;
> +}
> +
> +static int as3645a_v4l2_setup(struct as3645a *flash)
> +{
> + struct led_classdev_flash *fled = >fled;
> + struct led_classdev *led = >led_cdev;
> + struct v4l2_flash_config cfg = {
> + .intensity = {
> + .min = AS_TORCH_INTENSITY_MIN,
> + .max = flash->cfg.assist_max_ua,
> + .step = AS_TORCH_INTENSITY_STEP,
> + .val = flash->cfg.assist_max_ua,
> + },
> + };
> + struct v4l2_flash_config cfgind = {
> + .intensity = {
> + .min = AS_INDICATOR_INTENSITY_MIN,
> + .max = flash->cfg.indicator_max_ua,
> + .step = AS_INDICATOR_INTENSITY_STEP,
> + .val = flash->cfg.indicator_max_ua,
> + },
> + };
> +
> + strlcpy(cfg.dev_name, led->name, sizeof(cfg.dev_name));
> + strlcpy(cfgind.dev_name, flash->iled_cdev.name, sizeof(cfg.dev_name));
> +
> + flash->vf = v4l2_flash_init(
> + >client->dev, of_fwnode_handle(flash->flash_node),
> + >fled, NULL, );
> + if (IS_ERR(flash->vf))
> + return PTR_ERR(flash->vf);
> +
> + flash->vfind = v4l2_flash_indicator_init(
> + >client->dev, of_fwnode_handle(flash->indicator_node),
> + >iled_cdev, );
> + if (IS_ERR(flash->vfind)) {
> + v4l2_flash_release(flash->vf);
> + return PTR_ERR(flash->vfind);
> + }
> +
> + return 0;
> +}
> +
> +static int as3645a_probe(struct i2c_client *client)
> +{
> + struct as3645a_names names;
> + struct as3645a *flash;
> + int rval;
> +
> + if (client->dev.of_node == NULL)
> + return -ENODEV;
> +
> + flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
> + if (flash == NULL)
> + return -ENOMEM;
> +
> + flash->client = client;
> +
> + rval = as3645a_parse_node(flash, , client->dev.of_node);
> + if (rval < 0)
> + return rval;
> +
> + rval = as3645a_detect(flash);
> + if (rval < 0)
> + goto out_put_nodes;
> +
> + mutex_init(>mutex);
> + i2c_set_clientdata(client, flash);
> +
> + rval = as3645a_setup(flash);
> + if (rval)
> + goto out_mutex_destroy;
> +
> + rval = as3645a_led_class_setup(flash, );
> + if (rval)
> + goto out_mutex_destroy;
> +
> + rval = as3645a_v4l2_setup(flash);
> + if (rval)
> + goto out_led_classdev_flash_unregister;
> +
> + return 0;
> +
> +out_led_classdev_flash_unregister:
> + led_classdev_flash_unregister(>fled);
> +
> +out_mutex_destroy:
> + mutex_destroy(>mutex);
> +
> +out_put_nodes:
> + of_node_put(flash->flash_node);
> + of_node_put(flash->indicator_node);
> +
> + return rval;
> +}
> +
> +static int as3645a_remove(struct i2c_client *client)
> +{
> + struct as3645a *flash = i2c_get_clientdata(client);
> +
> + as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
> +
> + v4l2_flash_release(flash->vf);
> +
> + led_classdev_flash_unregister(>fled);
> + led_classdev_unregister(>iled_cdev);
> +
> + mutex_destroy(>mutex);
> +
> + of_node_put(flash->flash_node);
> + of_node_put(flash->indicator_node);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id as3645a_of_table[] = {
> + { .compatible = "ams,as3645a" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, as3645a_of_table);
> +
> +SIMPLE_DEV_PM_OPS(as3645a_pm_ops, as3645a_resume, as3645a_suspend);
> +
> +static struct i2c_driver as3645a_i2c_driver = {
> + .driver = {
> + .of_match_table = as3645a_of_table,
> + .name = AS_NAME,
> + .pm = _pm_ops,
LED subsystem already installs its own pm ops (see led-class.c)
and sets brightness on all LED class devices to LED_OFF on suspend
and brings it back on resume.
If you set LED_CORE_SUSPENDRESUME flag, then you could get rid
of as3645a_resume() and as3645a_suspend() and turn the device in power
down mode (if it has one) always when both flash and indicator LED are
off (if it makes sense from power comsumption POV).
> + },
> + .probe_new = as3645a_probe,
> + .remove = as3645a_remove,
> +};
> +
> +module_i2c_driver(as3645a_i2c_driver);
> +
> +MODULE_AUTHOR("Laurent Pinchart <laurent.pinch...@ideasonboard.com>");
> +MODULE_AUTHOR("Sakari Ailus <sakari.ai...@iki.fi>");
> +MODULE_DESCRIPTION("LED flash driver for AS3645A, LM3555 and their clones");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 1/3] dt: bindings: Document DT bindings for Analog devices as3645a
Hi Sakari,
Thanks for the patch. One issue below.
On 08/16/2017 02:55 PM, Sakari Ailus wrote:
> From: Sakari Ailus <sakari.ai...@iki.fi>
>
> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
> ---
> .../devicetree/bindings/leds/ams,as3645a.txt | 56
> ++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ams,as3645a.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> new file mode 100644
> index ..00066e3f9036
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> @@ -0,0 +1,56 @@
> +Analog devices AS3645A device tree bindings
> +
> +The AS3645A flash LED controller can drive two LEDs, one high current
> +flash LED and one indicator LED. The high current flash LED can be
> +used in torch mode as well.
> +
> +Ranges below noted as [a, b] are closed ranges between a and b, i.e. a
> +and b are included in the range.
> +
> +
> +Required properties
> +===
> +
> +compatible : Must be "ams,as3645a".
> +reg : The I2C address of the device. Typically 0x30.
> +
> +
> +Required properties of the "flash" child node
> +=
> +
> +flash-timeout-us: Flash timeout in microseconds. The value must be in
> + the range [10, 85] and divisible by 5.
> +flash-max-microamp: Maximum flash current in microamperes. Has to be
> + in the range between [20, 50] and
> + divisible by 2.
> +led-max-microamp: Maximum torch (assist) current in microamperes. The
> + value must be in the range between [2, 16] and
> + divisible by 2.
> +ams,input-max-microamp: Maximum flash controller input current. The
> + value must be in the range [125, 200]
> + and divisible by 5.
> +
> +
> +Required properties of the "indicator" child node
> +=
> +
> +led-max-microamp: Maximum indicator current. The allowed values are
> + 2500, 5000, 7500 and 1.
Most LED bindings mention also optional label property in the form:
- label : See Documentation/devicetree/bindings/leds/common.txt
> +
> +Example
> +===
> +
> + as3645a: flash@30 {
> + reg = <0x30>;
> + compatible = "ams,as3645a";
> + flash {
label = "as3645a:flash";
> + flash-timeout-us = <15>;
> + flash-max-microamp = <32>;
> + led-max-microamp = <60000>;
> + ams,input-max-microamp = <175>;
> + };
> + indicator {
label = "as3645a:indicator";
> + led-max-microamp = <1>;
> + };
> + };
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 0/3] AS3645A flash support
Hi Sakari,
On 08/16/2017 02:54 PM, Sakari Ailus wrote:
> Hi everyone,
>
> This set adds support for the AS3645A flash driver which can be found e.g.
> in Nokia N9.
>
> The set depeds on the flash patches here so I'd prefer to merge this
> through mediatree.
>
> <URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=flash>
>
> Jacek: would that be ok for you?
No problem.
>
> Since the RFC set:
>
> - Add back the DT binding documentation I lost long ago.
>
> - Use colon (":") in the default names instead of a space.
>
> Sakari Ailus (3):
> dt: bindings: Document DT bindings for Analog devices as3645a
> leds: as3645a: Add LED flash class driver
> arm: dts: omap3: N9/N950: Add AS3645A camera flash
>
> .../devicetree/bindings/leds/ams,as3645a.txt | 56 ++
> MAINTAINERS| 6 +
> arch/arm/boot/dts/omap3-n9.dts | 1 +
> arch/arm/boot/dts/omap3-n950-n9.dtsi | 14 +
> arch/arm/boot/dts/omap3-n950.dts | 1 +
> drivers/leds/Kconfig | 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-as3645a.c| 785
> +
> 8 files changed, 872 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ams,as3645a.txt
> create mode 100644 drivers/leds/leds-as3645a.c
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 0/2] More s5p-jpeg fixes
Hi Andrzej, Thanks for the patches. On 08/11/2017 01:49 PM, Andrzej Pietrasiewicz wrote: > Hi All, > > The first patch in the series fixes decoding path, > the second patch fixes encoding path. Please see > appropriate commit messages. > > Andrzej Pietrasiewicz (2): > media: s5p-jpeg: don't overwrite result's "size" member > media: s5p-jpeg: set w/h when encoding > > drivers/media/platform/s5p-jpeg/jpeg-core.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> -- Best regards, Jacek Anaszewski
Re: [PATCH 0/5] s5p-jpeg fixes
Hi Andrzej, Thanks for the patch set. On 08/08/2017 01:22 PM, Andrzej Pietrasiewicz wrote: > Hi All, > > This series contains a number of fixes to the s5p-jpeg driver. > > There are two patches from Tony K Nadackal, which got lost long time ago. > > @Thierry: > The patch changing the software reset routine you sent recently was > actually a resend of Tony's patch. I investigated the question why > this patch is needed. The encoder/decoder should be disabled as soon > as possible, in the interrupt service routine; please see the commit message. > I am resending Tony's patch again, with updated commit message. > Thank you for reminding about the patch in question! > > There are also three patches from me, please see appropriate commit > messages. > > Rebased onto Mauro's master. > > Andrzej Pietrasiewicz (3): > media: platform: s5p-jpeg: disable encoder/decoder in exynos4-like > hardware after use > media: platform: s5p-jpeg: fix number of components macro > media: platform: s5p-jpeg: directly use parsed subsampling on 5433 > > Tony K Nadackal (2): > media: platform: s5p-jpeg: Fix crash in jpeg isr due to multiple > interrupts. > media: platform: s5p-jpeg: Clear JPEG_CODEC_ON bits in sw reset > function > > drivers/media/platform/s5p-jpeg/jpeg-core.c | 8 +++- > drivers/media/platform/s5p-jpeg/jpeg-core.h | 1 + > drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 9 - > drivers/media/platform/s5p-jpeg/jpeg-regs.h | 2 +- > 4 files changed, 17 insertions(+), 3 deletions(-) > For the whole series: Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> -- Best regards, Jacek Anaszewski
Re: [RFC 05/19] leds: as3645a: Add LED flash class driver
Hi Sakari, Thanks for the update. My remarks from [0] related to LED class device naming apply also to this version of the patch. [0[ https://www.spinics.net/lists/linux-leds/msg08015.html Best regards, Jacek Anaszewski On 07/18/2017 09:03 PM, Sakari Ailus wrote: > From: Sakari Ailus <sakari.ai...@iki.fi> > > Add a LED flash class driver for the as3654a flash controller. A V4L2 flash > driver for it already exists (drivers/media/i2c/as3645a.c), and this driver > is based on that. > > Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> > --- > MAINTAINERS | 6 + > drivers/leds/Kconfig| 8 + > drivers/leds/Makefile | 1 + > drivers/leds/leds-as3645a.c | 742 > > 4 files changed, 757 insertions(+) > create mode 100644 drivers/leds/leds-as3645a.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 205d3977ac46..312be8939969 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2106,6 +2106,12 @@ F: arch/arm64/ > F: Documentation/arm64/ > > AS3645A LED FLASH CONTROLLER DRIVER > +M: Sakari Ailus <sakari.ai...@iki.fi> > +L: linux-l...@vger.kernel.org > +S: Maintained > +F: drivers/leds/leds-as3645a.c > + > +AS3645A LED FLASH CONTROLLER DRIVER > M: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > L: linux-media@vger.kernel.org > T: git git://linuxtv.org/media_tree.git > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > index 594b24d410c3..bad3a4098104 100644 > --- a/drivers/leds/Kconfig > +++ b/drivers/leds/Kconfig > @@ -58,6 +58,14 @@ config LEDS_AAT1290 > help >This option enables support for the LEDs on the AAT1290. > > +config LEDS_AS3645A > + tristate "AS3645A LED flash controller support" > + depends on I2C && LEDS_CLASS_FLASH > + help > + Enable LED flash class support for AS3645A LED flash > + controller. V4L2 flash API is provided as well if > + CONFIG_V4L2_FLASH_API is enabled. > + > config LEDS_BCM6328 > tristate "LED Support for Broadcom BCM6328" > depends on LEDS_CLASS > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > index 909dae62ba05..7d7b26552923 100644 > --- a/drivers/leds/Makefile > +++ b/drivers/leds/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o > # LED Platform Drivers > obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o > obj-$(CONFIG_LEDS_AAT1290) += leds-aat1290.o > +obj-$(CONFIG_LEDS_AS3645A) += leds-as3645a.o > obj-$(CONFIG_LEDS_BCM6328) += leds-bcm6328.o > obj-$(CONFIG_LEDS_BCM6358) += leds-bcm6358.o > obj-$(CONFIG_LEDS_BD2802)+= leds-bd2802.o > diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c > new file mode 100644 > index ..b1dc32a3c620 > --- /dev/null > +++ b/drivers/leds/leds-as3645a.c > @@ -0,0 +1,742 @@ > +/* > + * drivers/leds/leds-as3645a.c - AS3645A and LM3555 flash controllers driver > + * > + * Copyright (C) 2008-2011 Nokia Corporation > + * Copyright (c) 2011, 2017 Intel Corporation. > + * > + * Based on drivers/media/i2c/as3645a.c. > + * > + * Contact: Sakari Ailus <sakari.ai...@iki.fi> > + * > + * 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. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define AS_TIMER_US_TO_CODE(t) (((t) / 1000 - 100) / > 50) > +#define AS_TIMER_CODE_TO_US(c) ((50 * (c) + 100) * > 1000) > + > +/* Register definitions */ > + > +/* Read-only Design info register: Reset state: 0001 */ > +#define AS_DESIGN_INFO_REG 0x00 > +#define AS_DESIGN_INFO_FACTORY(x)(((x) >> 4)) > +#define AS_DESIGN_INFO_MODEL(x) ((x) & 0x0f) > + > +/* Read-only Version control register: Reset state: > + * for first engineering samples > + */ > +#define AS_VERSION_CONTROL_REG 0x01 > +#define AS_VERSION_CONTROL_RFU(x)(((x) >> 4)) > +#define AS_VERSIO
Re: [PATCH 2/2] v4l2-flash-led-class: Create separate sub-devices for indicators
torch_intensity);
> + _cfg.intensity);
>
> channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
> if (channel_ind) {
> __gb_lights_channel_v4l2_config(_ind->intensity_uA,
> - _cfg.indicator_intensity);
> + _cfg_ind.intensity);
> iled = _ind->fled.led_cdev;
> }
>
> @@ -558,6 +559,8 @@ static int gb_lights_light_v4l2_register(struct gb_light
> *light)
> fled = _flash->fled;
>
> snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
> + snprintf(sd_cfg_ind.dev_name, sizeof(sd_cfg_ind.dev_name),
> + "%s indicator", light->name);
>
> /* Set the possible values to faults, in our case all faults */
> sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> @@ -566,21 +569,32 @@ static int gb_lights_light_v4l2_register(struct
> gb_light *light)
> LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
> LED_FAULT_LED_OVER_TEMPERATURE;
>
> - light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> - _flash_ops, _cfg);
> + light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, _flash_ops,
> + _cfg);
> if (IS_ERR_OR_NULL(light->v4l2_flash)) {
> ret = PTR_ERR(light->v4l2_flash);
> goto out_free;
> }
>
> + if (channel_ind) {
> + light->v4l2_flash_ind =
> + v4l2_flash_indicator_init(dev, NULL, iled, _cfg_ind);
> + if (IS_ERR_OR_NULL(light->v4l2_flash_ind)) {
> + ret = PTR_ERR(light->v4l2_flash_ind);
> + goto out_free;
> + }
> + }
> +
> return ret;
>
> out_free:
> + v4l2_flash_release(light->v4l2_flash);
> return ret;
> }
>
> static void gb_lights_light_v4l2_unregister(struct gb_light *light)
> {
> + v4l2_flash_release(light->v4l2_flash_ind);
> v4l2_flash_release(light->v4l2_flash);
> }
> #else
> diff --git a/include/media/v4l2-flash-led-class.h
> b/include/media/v4l2-flash-led-class.h
> index 54e31a805a88..c3f39992f3fa 100644
> --- a/include/media/v4l2-flash-led-class.h
> +++ b/include/media/v4l2-flash-led-class.h
> @@ -56,8 +56,7 @@ struct v4l2_flash_ops {
> * struct v4l2_flash_config - V4L2 Flash sub-device initialization data
> * @dev_name:the name of the media entity,
> * unique in the system
> - * @torch_intensity: constraints for the LED in torch mode
> - * @indicator_intensity: constraints for the indicator LED
> + * @intensity: non-flash strobe constraints for the LED
> * @flash_faults:bitmask of flash faults that the LED flash class
> * device can report; corresponding LED_FAULT* bit
> * definitions are available in the header file
> @@ -66,8 +65,7 @@ struct v4l2_flash_ops {
> */
> struct v4l2_flash_config {
> char dev_name[32];
> - struct led_flash_setting torch_intensity;
> - struct led_flash_setting indicator_intensity;
> + struct led_flash_setting intensity;
> u32 flash_faults;
> unsigned int has_external_strobe:1;
> };
> @@ -110,8 +108,6 @@ static inline struct v4l2_flash
> *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
> * @dev: flash device, e.g. an I2C device
> * @fwn: fwnode_handle of the LED, may be NULL if the same as device's
> * @fled_cdev: LED flash class device to wrap
> - * @iled_cdev: LED flash class device representing indicator LED
> associated
> - * with fled_cdev, may be NULL
> * @ops: V4L2 Flash device ops
> * @config: initialization data for V4L2 Flash sub-device
> *
> @@ -124,9 +120,24 @@ static inline struct v4l2_flash
> *v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
> struct v4l2_flash *v4l2_flash_init(
> struct device *dev, struct fwnode_handle *fwn,
> struct led_classdev_flash *fled_cdev,
> - struct led_classdev *iled_cdev,
> - const struct v4l2_flash_ops *ops,
> - struct v4l2_flash_config *config);
> + const struct v4l2_flash_ops *ops, struct v4l2_flash_config *config);
> +
> +/**
> + * v4l2_flash_indicator_init - initialize V4L2 indicator sub-device
> + * @dev: flash device, e.g. an I2C device
> + * @fwn: fwnode_handle of the LED, may be NULL if the same as device's
> + * @iled_cdev: LED flash class device representing the indicator LED
> + * @config: initialization data for V4L2 Flash sub-device
> + *
> + * Create V4L2 Flash sub-device wrapping given LED subsystem device.
> + *
> + * Returns: A valid pointer, or, when an error occurs, the return
> + * value is encoded using ERR_PTR(). Use IS_ERR() to check and
> + * PTR_ERR() to obtain the numeric return value.
> + */
> +struct v4l2_flash *v4l2_flash_indicator_init(
> + struct device *dev, struct fwnode_handle *fwn,
> + struct led_classdev *iled_cdev, struct v4l2_flash_config *config);
>
> /**
> * v4l2_flash_release - release V4L2 Flash sub-device
> @@ -139,10 +150,14 @@ void v4l2_flash_release(struct v4l2_flash *v4l2_flash);
> #else
> static inline struct v4l2_flash *v4l2_flash_init(
> struct device *dev, struct fwnode_handle *fwn,
> - struct led_classdev_flash *fled_cdev,
> - struct led_classdev *iled_cdev,
> - const struct v4l2_flash_ops *ops,
> - struct v4l2_flash_config *config)
> + struct led_classdev_flash *fled_cdev, struct v4l2_flash_config *config)
> +{
> + return NULL;
> +}
> +
> +static inline struct v4l2_flash *v4l2_flash_indicator_init(
> + struct device *dev, struct fwnode_handle *fwn,
> + struct led_classdev *iled_cdev, struct v4l2_flash_config *config)
> {
> return NULL;
> }
>
Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
--
Best regards,
Jacek Anaszewski
Re: [PATCH v3 0/8] [media] s5p-jpeg: Various fixes and improvements
Hi Thierry, For the whole series: Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> Best regards, Jacek Anaszewski On 06/27/2017 06:08 PM, Thierry Escande wrote: > Hi, > > This series contains various fixes and improvements for the Samsung > s5p-jpeg driver. Most of these patches come from the Chromium v3.8 > kernel tree. > > In this v3: > - Remove codec reset patch (Not needed based on documentation and no > use case described in original patch commit message). > - Check for Exynos5420 variant in stream error handling patch. > - Add use case for resolution change event support in commit message. > - Move subsampling value decoding in a separate function. > - Check Exynos variant for 4:1:1 subsampling support. > > v2: > - Remove IOMMU support patch (mapping now created automatically for > single JPEG CODEC device). > - Remove "Change sclk_jpeg to 166MHz" patch (can be set through DT > properties). > - Remove support for multi-planar APIs (Not needed). > - Add comment regarding call to jpeg_bound_align_image() after qbuf. > - Remove unrelated code from resolution change event support patch. > > Thierry Escande (3): > [media] s5p-jpeg: Handle parsing error in s5p_jpeg_parse_hdr() > [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue > [media] s5p-jpeg: Split s5p_jpeg_parse_hdr() > > Tony K Nadackal (3): > [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf > [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling > [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format > > henryhsu (2): > [media] s5p-jpeg: Add support for resolution change event > [media] s5p-jpeg: Add stream error handling for Exynos5420 > > drivers/media/platform/s5p-jpeg/jpeg-core.c | 186 > +--- > drivers/media/platform/s5p-jpeg/jpeg-core.h | 7 ++ > 2 files changed, 148 insertions(+), 45 deletions(-) >
Re: [PATCH v3 4/8] [media] s5p-jpeg: Don't use temporary structure in s5p_jpeg_buf_queue
Hi Thierry,
On 06/27/2017 06:08 PM, Thierry Escande wrote:
> If s5p_jpeg_parse_hdr() fails to parse the JPEG header, the passed
> s5p_jpeg_q_data structure is not modify so there is no need to use a
s/modify/modified/
> temporary structure and the field-by-field copy can be avoided.
>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> ---
> drivers/media/platform/s5p-jpeg/jpeg-core.c | 23 ---
> 1 file changed, 4 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index df3e5ee..1769744 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -2500,9 +2500,9 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
>
> if (ctx->mode == S5P_JPEG_DECODE &&
> vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> - struct s5p_jpeg_q_data tmp, *q_data;
> + struct s5p_jpeg_q_data *q_data;
>
> - ctx->hdr_parsed = s5p_jpeg_parse_hdr(,
> + ctx->hdr_parsed = s5p_jpeg_parse_hdr(>out_q,
>(unsigned long)vb2_plane_vaddr(vb, 0),
>min((unsigned long)ctx->out_q.size,
>vb2_get_plane_payload(vb, 0)), ctx);
> @@ -2511,24 +2511,9 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
> return;
> }
>
> - q_data = >out_q;
> - q_data->w = tmp.w;
> - q_data->h = tmp.h;
> - q_data->sos = tmp.sos;
> - memcpy(q_data->dht.marker, tmp.dht.marker,
> -sizeof(tmp.dht.marker));
> - memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len));
> - q_data->dht.n = tmp.dht.n;
> - memcpy(q_data->dqt.marker, tmp.dqt.marker,
> -sizeof(tmp.dqt.marker));
> - memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len));
> - q_data->dqt.n = tmp.dqt.n;
> - q_data->sof = tmp.sof;
> - q_data->sof_len = tmp.sof_len;
> -
> q_data = >cap_q;
> - q_data->w = tmp.w;
> - q_data->h = tmp.h;
> + q_data->w = ctx->out_q.w;
> + q_data->h = ctx->out_q.h;
>
> /*
>* This call to jpeg_bound_align_image() takes care of width and
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 6/8] leds: as3645a: Add LED flash class driver
On 06/15/2017 03:34 PM, Sakari Ailus wrote:
> Hi Jacek,
>
> On Thu, Jun 15, 2017 at 03:01:47PM +0200, Jacek Anaszewski wrote:
>> Hi Sakari,
>>
>> On 06/15/2017 12:10 AM, Sakari Ailus wrote:
>>> Hi Jacek,
>>>
>>> Thanks for the review!
>>
>> You're welcome!
>>
>>> I have to say I found the v4l2-flash-led-class framework quite useful, now
>>> that I refactored a driver for using it. Now we have a user for the
>>> indicator, too. :-)
>>
>> Nice :-). I'm also surprised that v4l2-flash API is also used in
>> drivers/staging/greybus/light.c which popped up with kbuild test robot
>> complaints.
>
> I missed that on the first round of the submission as well. I'll fix that
> in v2.
>
>>
>>> On Wed, Jun 14, 2017 at 11:15:24PM +0200, Jacek Anaszewski wrote:
>>>>> +static __maybe_unused int as3645a_suspend(struct device *dev)
>>>>> +{
>>>>> + struct i2c_client *client = to_i2c_client(dev);
>>>>> + struct as3645a *flash = i2c_get_clientdata(client);
>>>>> + int rval;
>>>>> +
>>>>> + rval = as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
>>>>> + dev_dbg(dev, "Suspend %s\n", rval < 0 ? "failed" : "ok");
>>>>> +
>>>>> + return rval;
>>>>> +}
>>>>> +
>>>>> +static __maybe_unused int as3645a_resume(struct device *dev)
>>>>> +{
>>>>> + struct i2c_client *client = to_i2c_client(dev);
>>>>> + struct as3645a *flash = i2c_get_clientdata(client);
>>>>> + int rval;
>>>>> +
>>>>> + rval = as3645a_setup(flash);
>>>>> +
>>>>
>>>> nitpicking: inconsistent coding style - there is no empty line before
>>>> dev_dbg() in the as3645a_suspend().
>>>
>>> Added one for as3645a_suspend() --- it should have been there.
>>>
>>>>
>>>>> + dev_dbg(dev, "Resume %s\n", rval < 0 ? "fail" : "ok");
>>>>> +
>>>>> + return rval;
>>>>> +}
>>>
>>> ...
>>>
>>>>> +static int as3645a_led_class_setup(struct as3645a *flash)
>>>>> +{
>>>>> + struct led_classdev *fled_cdev = >fled.led_cdev;
>>>>> + struct led_classdev *iled_cdev = >iled_cdev;
>>>>> + struct led_flash_setting *cfg;
>>>>> + int rval;
>>>>> +
>>>>> + iled_cdev->name = "as3645a indicator";
>>>>> + iled_cdev->brightness_set_blocking = as3645a_set_indicator_brightness;
>>>>> + iled_cdev->max_brightness =
>>>>> + flash->cfg.indicator_max_ua / AS_INDICATOR_INTENSITY_STEP;
>>>>> +
>>>>> + rval = led_classdev_register(>client->dev, iled_cdev);
>>>>> + if (rval < 0)
>>>>> + return rval;
>>>>> +
>>>>> + cfg = >fled.brightness;
>>>>> + cfg->min = AS_FLASH_INTENSITY_MIN;
>>>>> + cfg->max = flash->cfg.flash_max_ua;
>>>>> + cfg->step = AS_FLASH_INTENSITY_STEP;
>>>>> + cfg->val = flash->cfg.flash_max_ua;
>>>>> +
>>>>> + cfg = >fled.timeout;
>>>>> + cfg->min = AS_FLASH_TIMEOUT_MIN;
>>>>> + cfg->max = flash->cfg.flash_timeout_us;
>>>>> + cfg->step = AS_FLASH_TIMEOUT_STEP;
>>>>> + cfg->val = flash->cfg.flash_timeout_us;
>>>>> +
>>>>> + flash->fled.ops = _led_flash_ops;
>>>>> +
>>>>> + fled_cdev->name = "as3645a flash";
>>>>
>>>> LED class device name should be taken from label DT property,
>>>> or DT node name if the former wasn't defined.
>>>>
>>>> Also LED device naming convention defines colon as a separator
>>>> between name segments.
>>>
>>> Right. I'll fix that.
>>>
>>> I just realised I'm missing DT binding documentation for this device; I'll
>>> add that, too.
>>>
>>> Is the preference to allow freely chosen node names for the LEDs? Now that
>>> there's the label, too, this appears to be somewhat duplicated information.
>>
>> It depends on whether the sub-leds are identified by reg property.
>> In this case usually common prefix is used followed by reg value,
>> e.g. led@1, led@2 etc.
>
> Is there a device that would use this already? I checked common.txt and
> I couldn't find a suggestion of this scheme there.
There is no suitable suggestion in common.txt indeed, but it is used
e.g. in:
leds-mt6323.txt, leds-bcm6328.txt, leds-pm8058.txt.
>> Otherwise prevailing scheme is e.g.:
>>
>> blue-power {
>> ...
>> label = "netxbig:blue:power";
>> }
>>
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 6/8] leds: as3645a: Add LED flash class driver
Hi Sakari,
On 06/15/2017 12:10 AM, Sakari Ailus wrote:
> Hi Jacek,
>
> Thanks for the review!
You're welcome!
> I have to say I found the v4l2-flash-led-class framework quite useful, now
> that I refactored a driver for using it. Now we have a user for the
> indicator, too. :-)
Nice :-). I'm also surprised that v4l2-flash API is also used in
drivers/staging/greybus/light.c which popped up with kbuild test robot
complaints.
> On Wed, Jun 14, 2017 at 11:15:24PM +0200, Jacek Anaszewski wrote:
>>> +static __maybe_unused int as3645a_suspend(struct device *dev)
>>> +{
>>> + struct i2c_client *client = to_i2c_client(dev);
>>> + struct as3645a *flash = i2c_get_clientdata(client);
>>> + int rval;
>>> +
>>> + rval = as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
>>> + dev_dbg(dev, "Suspend %s\n", rval < 0 ? "failed" : "ok");
>>> +
>>> + return rval;
>>> +}
>>> +
>>> +static __maybe_unused int as3645a_resume(struct device *dev)
>>> +{
>>> + struct i2c_client *client = to_i2c_client(dev);
>>> + struct as3645a *flash = i2c_get_clientdata(client);
>>> + int rval;
>>> +
>>> + rval = as3645a_setup(flash);
>>> +
>>
>> nitpicking: inconsistent coding style - there is no empty line before
>> dev_dbg() in the as3645a_suspend().
>
> Added one for as3645a_suspend() --- it should have been there.
>
>>
>>> + dev_dbg(dev, "Resume %s\n", rval < 0 ? "fail" : "ok");
>>> +
>>> + return rval;
>>> +}
>
> ...
>
>>> +static int as3645a_led_class_setup(struct as3645a *flash)
>>> +{
>>> + struct led_classdev *fled_cdev = >fled.led_cdev;
>>> + struct led_classdev *iled_cdev = >iled_cdev;
>>> + struct led_flash_setting *cfg;
>>> + int rval;
>>> +
>>> + iled_cdev->name = "as3645a indicator";
>>> + iled_cdev->brightness_set_blocking = as3645a_set_indicator_brightness;
>>> + iled_cdev->max_brightness =
>>> + flash->cfg.indicator_max_ua / AS_INDICATOR_INTENSITY_STEP;
>>> +
>>> + rval = led_classdev_register(>client->dev, iled_cdev);
>>> + if (rval < 0)
>>> + return rval;
>>> +
>>> + cfg = >fled.brightness;
>>> + cfg->min = AS_FLASH_INTENSITY_MIN;
>>> + cfg->max = flash->cfg.flash_max_ua;
>>> + cfg->step = AS_FLASH_INTENSITY_STEP;
>>> + cfg->val = flash->cfg.flash_max_ua;
>>> +
>>> + cfg = >fled.timeout;
>>> + cfg->min = AS_FLASH_TIMEOUT_MIN;
>>> + cfg->max = flash->cfg.flash_timeout_us;
>>> + cfg->step = AS_FLASH_TIMEOUT_STEP;
>>> + cfg->val = flash->cfg.flash_timeout_us;
>>> +
>>> + flash->fled.ops = _led_flash_ops;
>>> +
>>> + fled_cdev->name = "as3645a flash";
>>
>> LED class device name should be taken from label DT property,
>> or DT node name if the former wasn't defined.
>>
>> Also LED device naming convention defines colon as a separator
>> between name segments.
>
> Right. I'll fix that.
>
> I just realised I'm missing DT binding documentation for this device; I'll
> add that, too.
>
> Is the preference to allow freely chosen node names for the LEDs? Now that
> there's the label, too, this appears to be somewhat duplicated information.
It depends on whether the sub-leds are identified by reg property.
In this case usually common prefix is used followed by reg value,
e.g. led@1, led@2 etc.
Otherwise prevailing scheme is e.g.:
blue-power {
...
label = "netxbig:blue:power";
}
--
Best regards,
Jacek Anaszewski
Re: [PATCH 5/8] v4l2-flash: Flash ops aren't mandatory
Hi Sakari, On 06/14/2017 11:19 PM, Sakari Ailus wrote: > Hi Jacek, > > On Wed, Jun 14, 2017 at 11:14:13PM +0200, Jacek Anaszewski wrote: >> Hi Sakari, >> >> On 06/14/2017 11:47 AM, Sakari Ailus wrote: >>> None of the flash operations are not mandatory and therefore there should >>> be no need for the flash ops structure either. Accept NULL. >>> >>> Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> >>> --- >>> drivers/media/v4l2-core/v4l2-flash-led-class.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c >>> b/drivers/media/v4l2-core/v4l2-flash-led-class.c >>> index 6d69119..fdb79da 100644 >>> --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c >>> +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c >>> @@ -18,7 +18,7 @@ >>> #include >>> >>> #define has_flash_op(v4l2_flash, op) \ >>> - (v4l2_flash && v4l2_flash->ops->op) >>> + (v4l2_flash && v4l2_flash->ops && v4l2_flash->ops->op) >> >> This change doesn't seem to be related to the patch subject. > > Yes, it is: if there's a chance that ops is NULL, then you have to test here > you actually have the ops struct around. The test is no longer in > v4l2_flash_init(). Indeed. Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> >>> #define call_flash_op(v4l2_flash, op, arg) \ >>> (has_flash_op(v4l2_flash, op) ? \ >>> @@ -618,7 +618,7 @@ struct v4l2_flash *v4l2_flash_init( >>> struct v4l2_subdev *sd; >>> int ret; >>> >>> - if (!fled_cdev || !ops || !config) >>> + if (!fled_cdev || !config) >>> return ERR_PTR(-EINVAL); >>> >>> led_cdev = _cdev->led_cdev; >>> > -- Best regards, Jacek Anaszewski
Re: [PATCH 6/8] leds: as3645a: Add LED flash class driver
; + struct led_classdev *fled_cdev = >fled.led_cdev;
> + struct led_classdev *iled_cdev = >iled_cdev;
> + struct led_flash_setting *cfg;
> + int rval;
> +
> + iled_cdev->name = "as3645a indicator";
> + iled_cdev->brightness_set_blocking = as3645a_set_indicator_brightness;
> + iled_cdev->max_brightness =
> + flash->cfg.indicator_max_ua / AS_INDICATOR_INTENSITY_STEP;
> +
> + rval = led_classdev_register(>client->dev, iled_cdev);
> + if (rval < 0)
> + return rval;
> +
> + cfg = >fled.brightness;
> + cfg->min = AS_FLASH_INTENSITY_MIN;
> + cfg->max = flash->cfg.flash_max_ua;
> + cfg->step = AS_FLASH_INTENSITY_STEP;
> + cfg->val = flash->cfg.flash_max_ua;
> +
> + cfg = >fled.timeout;
> + cfg->min = AS_FLASH_TIMEOUT_MIN;
> + cfg->max = flash->cfg.flash_timeout_us;
> + cfg->step = AS_FLASH_TIMEOUT_STEP;
> + cfg->val = flash->cfg.flash_timeout_us;
> +
> + flash->fled.ops = _led_flash_ops;
> +
> + fled_cdev->name = "as3645a flash";
LED class device name should be taken from label DT property,
or DT node name if the former wasn't defined.
Also LED device naming convention defines colon as a separator
between name segments.
> + fled_cdev->brightness_set_blocking = as3645a_set_assist_brightness;
> + /* Value 0 is off in LED class. */
> + fled_cdev->max_brightness =
> + as3645a_current_to_reg(flash, false,
> +flash->cfg.assist_max_ua) + 1;
> + fled_cdev->flags = LED_DEV_CAP_FLASH;
> +
> + rval = led_classdev_flash_register(>client->dev, >fled);
> + if (rval) {
> + led_classdev_unregister(iled_cdev);
> + dev_err(>client->dev,
> + "led_classdev_flash_register() failed, error %d\n",
> + rval);
> + }
> +
> + return rval;
> +}
> +
> +static int as3645a_v4l2_setup(struct as3645a *flash)
> +{
> + struct led_classdev_flash *fled = >fled;
> + struct led_classdev *led = >led_cdev;
> + struct v4l2_flash_config cfg = {
> + .torch_intensity = {
> + .min = AS_TORCH_INTENSITY_MIN,
> + .max = flash->cfg.assist_max_ua,
> + .step = AS_TORCH_INTENSITY_STEP,
> + .val = flash->cfg.assist_max_ua,
> + },
> + .indicator_intensity = {
> + .min = AS_INDICATOR_INTENSITY_MIN,
> + .max = flash->cfg.indicator_max_ua,
> + .step = AS_INDICATOR_INTENSITY_STEP,
> + .val = flash->cfg.indicator_max_ua,
> + },
> + };
> +
> + strlcpy(cfg.dev_name, led->name, sizeof(cfg.dev_name));
> +
> + flash->vf = v4l2_flash_init(>client->dev, NULL, >fled,
> + >iled_cdev, NULL, );
> + if (IS_ERR(flash->vf))
> + return PTR_ERR(flash->vf);
> +
> + return 0;
> +}
> +
> +static int as3645a_probe(struct i2c_client *client)
> +{
> + struct as3645a *flash;
> + int rval;
> +
> + if (client->dev.of_node == NULL)
> + return -ENODEV;
> +
> + flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
> + if (flash == NULL)
> + return -ENOMEM;
> +
> + flash->client = client;
> +
> + rval = as3645a_parse_node(flash, client->dev.of_node);
> + if (rval < 0)
> + return rval;
> +
> + rval = as3645a_detect(flash);
> + if (rval < 0)
> + return rval;
> +
> + mutex_init(>mutex);
> + i2c_set_clientdata(client, flash);
> +
> + rval = as3645a_setup(flash);
> + if (rval)
> + goto out_mutex_destroy;
> +
> + rval = as3645a_led_class_setup(flash);
> + if (rval)
> + goto out_mutex_destroy;
> +
> + rval = as3645a_v4l2_setup(flash);
> + if (rval)
> + goto out_led_classdev_flash_unregister;
> +
> + return 0;
> +
> +out_led_classdev_flash_unregister:
> + led_classdev_flash_unregister(>fled);
> +
> +out_mutex_destroy:
> + mutex_destroy(>mutex);
> +
> + return rval;
> +}
> +
> +static int as3645a_remove(struct i2c_client *client)
> +{
> + struct as3645a *flash = i2c_get_clientdata(client);
> +
> + as3645a_set_control(flash, AS_MODE_EXT_TORCH, false);
> +
> + v4l2_flash_release(flash->vf);
> +
> + led_classdev_flash_unregister(>fled);
> + led_classdev_unregister(>iled_cdev);
> +
> + mutex_destroy(>mutex);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id as3645a_of_table[] = {
> + { .compatible = "ams,as3645a" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, as3645a_of_table);
> +
> +SIMPLE_DEV_PM_OPS(as3645a_pm_ops, as3645a_resume, as3645a_suspend);
> +
> +static struct i2c_driver as3645a_i2c_driver = {
> + .driver = {
> + .of_match_table = as3645a_of_table,
> + .name = AS_NAME,
> + .pm = _pm_ops,
> + },
> + .probe_new = as3645a_probe,
> + .remove = as3645a_remove,
> +};
> +
> +module_i2c_driver(as3645a_i2c_driver);
> +
> +MODULE_AUTHOR("Laurent Pinchart <laurent.pinch...@ideasonboard.com>");
> +MODULE_AUTHOR("Sakari Ailus <sakari.ai...@iki.fi>");
> +MODULE_DESCRIPTION("LED flash driver for AS3645A, LM3555 and their clones");
> +MODULE_LICENSE("GPL v2");
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 5/8] v4l2-flash: Flash ops aren't mandatory
Hi Sakari, On 06/14/2017 11:47 AM, Sakari Ailus wrote: > None of the flash operations are not mandatory and therefore there should > be no need for the flash ops structure either. Accept NULL. > > Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com> > --- > drivers/media/v4l2-core/v4l2-flash-led-class.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c > b/drivers/media/v4l2-core/v4l2-flash-led-class.c > index 6d69119..fdb79da 100644 > --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c > +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c > @@ -18,7 +18,7 @@ > #include > > #define has_flash_op(v4l2_flash, op) \ > - (v4l2_flash && v4l2_flash->ops->op) > + (v4l2_flash && v4l2_flash->ops && v4l2_flash->ops->op) This change doesn't seem to be related to the patch subject. > #define call_flash_op(v4l2_flash, op, arg) \ > (has_flash_op(v4l2_flash, op) ? \ > @@ -618,7 +618,7 @@ struct v4l2_flash *v4l2_flash_init( > struct v4l2_subdev *sd; > int ret; > > - if (!fled_cdev || !ops || !config) > + if (!fled_cdev || !config) > return ERR_PTR(-EINVAL); > > led_cdev = _cdev->led_cdev; > -- Best regards, Jacek Anaszewski
Re: [PATCH 4/8] v4l2-flash: Use led_classdev instead of led_classdev_flash for indicator
cdev,
> - struct led_classdev_flash *iled_cdev,
> + struct led_classdev *iled_cdev,
> const struct v4l2_flash_ops *ops,
> struct v4l2_flash_config *config);
>
> @@ -140,7 +140,7 @@ void v4l2_flash_release(struct v4l2_flash *v4l2_flash);
> static inline struct v4l2_flash *v4l2_flash_init(
> struct device *dev, struct fwnode_handle *fwn,
> struct led_classdev_flash *fled_cdev,
> - struct led_classdev_flash *iled_cdev,
> + struct led_classdev *iled_cdev,
> const struct v4l2_flash_ops *ops,
> struct v4l2_flash_config *config)
> {
>
Reviewed-by: Jacek Anaszewski <jacek.anaszew...@gmail.com>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset
Hi Thierry, On 06/07/2017 02:34 PM, Thierry Escande wrote: > Hi Jacek, > > On 02/06/2017 21:50, Jacek Anaszewski wrote: >> Hi Thierry, >> >> On 06/02/2017 06:02 PM, Thierry Escande wrote: >>> From: Abhilash Kesavan <a.kesa...@samsung.com> >>> >>> This patch resets the encoding and decoding register bits before doing a >>> soft reset. >>> >>> Signed-off-by: Tony K Nadackal <tony...@samsung.com> >>> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com> >>> --- >>> drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c >>> b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c >>> index a1d823a..9ad8f6d 100644 >>> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c >>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c >>> @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base) >>> unsigned int reg; >>> reg = readl(base + EXYNOS4_JPEG_CNTL_REG); >>> +writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE), >>> + base + EXYNOS4_JPEG_CNTL_REG); >> >> Why is it required? It would be nice if commit message explained that. > > Unfortunately the bug entry in the ChromeOS issue tracker does not > mention more information about that and the patch author is no more > reachable on that email address. > > So unless someone else knows the answer I won't be able to give more > explanation in the commit message... Unfortunately I don't have longer access to the hardware and can't test these changes. Have you tested them, or just cherry-picked from the bug tracker? -- Best regards, Jacek Anaszewski
Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs
_querybuf= v4l2_m2m_ioctl_querybuf,
> .vidioc_qbuf= v4l2_m2m_ioctl_qbuf,
> @@ -2648,7 +2771,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
> struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
>
> if (ctx->mode == S5P_JPEG_DECODE &&
> - vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + vb->vb2_queue->type == ctx->out_q.type) {
> static const struct v4l2_event ev_src_ch = {
> .type = V4L2_EVENT_SOURCE_CHANGE,
> .u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
> @@ -2657,8 +2780,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
> u32 ori_w;
> u32 ori_h;
>
> - dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
> - V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, ctx->cap_q.type);
> ori_w = ctx->out_q.w;
> ori_h = ctx->out_q.h;
>
> @@ -2708,7 +2830,7 @@ static void s5p_jpeg_stop_streaming(struct vb2_queue *q)
>* subsampling. Update capture queue when the stream is off.
>*/
> if (ctx->state == JPEGCTX_RESOLUTION_CHANGE &&
> - q->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> + !V4L2_TYPE_IS_OUTPUT(q->type)) {
> s5p_jpeg_set_capture_queue_data(ctx);
> ctx->state = JPEGCTX_RUNNING;
> }
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h
> b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> index 9aa26bd..302a297 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> @@ -196,6 +196,7 @@ struct s5p_jpeg_marker {
> * @sof_len: SOF0 marker's payload length (without length field itself)
> * @components: number of image components
> * @size:image buffer size in bytes
> + * @type:buffer type of the queue (enum v4l2_buf_type)
> */
> struct s5p_jpeg_q_data {
> struct s5p_jpeg_fmt *fmt;
> @@ -208,6 +209,7 @@ struct s5p_jpeg_q_data {
> u32 sof_len;
> u32 components;
> u32 size;
> + u32 type;
> };
>
> /**
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250
Cc Marek and Sylwester.
On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: henryhsu <henry...@chromium.org>
>
> The default clock parent of jpeg on Exynos5250 is fin_pll, which is
> 24MHz. We have to change the clock parent to CPLL, which is 333MHz,
> and set sclk_jpeg to 166MHz.
>
> Signed-off-by: Heng-Ruey Hsu <henry...@chromium.org>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> ---
> drivers/media/platform/s5p-jpeg/jpeg-core.c | 47
> +
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 7a7acbc..430e925 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -969,6 +969,44 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx
> *ctx)
> }
> }
>
> +static int exynos4_jpeg_set_sclk_rate(struct s5p_jpeg *jpeg, struct clk
> *sclk)
Why here exynos4 and in the subject Exynos5250?
> +{
> + struct clk *mout_jpeg;
> + struct clk *sclk_cpll;
> + int ret;
> +
> + mout_jpeg = clk_get(jpeg->dev, "mout_jpeg");
> + if (IS_ERR(mout_jpeg)) {
> + dev_err(jpeg->dev, "mout_jpeg clock not available: %ld\n",
> + PTR_ERR(mout_jpeg));
> + return PTR_ERR(mout_jpeg);
> + }
> +
> + sclk_cpll = clk_get(jpeg->dev, "sclk_cpll");
> + if (IS_ERR(sclk_cpll)) {
> + dev_err(jpeg->dev, "sclk_cpll clock not available: %ld\n",
> + PTR_ERR(sclk_cpll));
> + clk_put(mout_jpeg);
> + return PTR_ERR(sclk_cpll);
> + }
> +
> + ret = clk_set_parent(mout_jpeg, sclk_cpll);
> + clk_put(sclk_cpll);
> + clk_put(mout_jpeg);
> + if (ret) {
> + dev_err(jpeg->dev, "clk_set_parent failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_set_rate(sclk, 166500 * 1000);
> + if (ret) {
> + dev_err(jpeg->dev, "clk_set_rate failed: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> #if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> static int jpeg_iommu_init(struct platform_device *pdev)
> {
> @@ -2974,6 +3012,15 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
> jpeg->variant->clk_names[i]);
> return PTR_ERR(jpeg->clocks[i]);
> }
> +
> + if (jpeg->variant->version == SJPEG_EXYNOS4 &&
> + !strncmp(jpeg->variant->clk_names[i],
> + "sclk", strlen("sclk"))) {
> + ret = exynos4_jpeg_set_sclk_rate(jpeg,
> + jpeg->clocks[i]);
> + if (ret)
> + return ret;
> + }
> }
>
> /* v4l2 device */
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 6/9] [media] s5p-jpeg: Add support for resolution change event
x);
> + ctx->state = JPEGCTX_RUNNING;
> + }
> +
> pm_runtime_put(ctx->jpeg->dev);
> }
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h
> b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> index 4492a35..9aa26bd 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
> @@ -98,6 +98,11 @@ enum exynos4_jpeg_img_quality_level {
> QUALITY_LEVEL_4,/* low */
> };
>
> +enum s5p_jpeg_ctx_state {
> + JPEGCTX_RUNNING = 0,
> + JPEGCTX_RESOLUTION_CHANGE,
> +};
> +
> /**
> * struct s5p_jpeg - JPEG IP abstraction
> * @lock:the mutex protecting this structure
> @@ -220,6 +225,7 @@ struct s5p_jpeg_q_data {
> * @hdr_parsed: set if header has been parsed during
> decompression
> * @crop_altered:set if crop rectangle has been altered by the user space
> * @ctrl_handler:controls handler
> + * @state: state of the context
> */
> struct s5p_jpeg_ctx {
> struct s5p_jpeg *jpeg;
> @@ -235,6 +241,7 @@ struct s5p_jpeg_ctx {
> boolhdr_parsed;
> boolcrop_altered;
> struct v4l2_ctrl_handler ctrl_handler;
> + enum s5p_jpeg_ctx_state state;
> };
>
> /**
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support
Cc Marek Szyprowski.
Marek, could you share your opinion about this patch?
On 06/02/2017 06:02 PM, Thierry Escande wrote:
> From: Tony K Nadackal <tony...@samsung.com>
>
> This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
> and ARM DMA IOMMU configurations are supported. The address space is
> created with size limited to 256M and base address set to 0x2000.
>
> Signed-off-by: Tony K Nadackal <tony...@samsung.com>
> Signed-off-by: Thierry Escande <thierry.esca...@collabora.com>
> ---
> drivers/media/platform/s5p-jpeg/jpeg-core.c | 77
> +
> 1 file changed, 77 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 770a709..5569b99 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -28,6 +28,14 @@
> #include
> #include
> #include
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#endif
>
> #include "jpeg-core.h"
> #include "jpeg-hw-s5p.h"
> @@ -35,6 +43,10 @@
> #include "jpeg-hw-exynos3250.h"
> #include "jpeg-regs.h"
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static struct dma_iommu_mapping *mapping;
> +#endif
> +
> static struct s5p_jpeg_fmt sjpeg_formats[] = {
> {
> .name = "JPEG JFIF",
> @@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx
> *ctx)
> }
> }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static int jpeg_iommu_init(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + int err;
> +
> + mapping = arm_iommu_create_mapping(_bus_type, 0x2000,
> +SZ_512M);
> + if (IS_ERR(mapping)) {
> + dev_err(dev, "IOMMU mapping failed\n");
> + return PTR_ERR(mapping);
> + }
> +
> + dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL);
> + if (!dev->dma_parms) {
> + err = -ENOMEM;
> + goto error_alloc;
> + }
> +
> + err = dma_set_max_seg_size(dev, 0xu);
> + if (err)
> + goto error;
> +
> + err = arm_iommu_attach_device(dev, mapping);
> + if (err)
> + goto error;
> +
> + return 0;
> +
> +error:
> + devm_kfree(dev, dev->dma_parms);
> + dev->dma_parms = NULL;
> +
> +error_alloc:
> + arm_iommu_release_mapping(mapping);
> + mapping = NULL;
> +
> + return err;
> +}
> +
> +static void jpeg_iommu_deinit(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> +
> + if (mapping) {
> + arm_iommu_detach_device(dev);
> + devm_kfree(dev, dev->dma_parms);
> + dev->dma_parms = NULL;
> + arm_iommu_release_mapping(mapping);
> + mapping = NULL;
> + }
> +}
> +#endif
> +
> /*
> *
>
> * Device file operations
> @@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
> spin_lock_init(>slock);
> jpeg->dev = >dev;
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> + ret = jpeg_iommu_init(pdev);
> + if (ret) {
> + dev_err(>dev, "IOMMU Initialization failed\n");
> + return ret;
> + }
> +#endif
> /* memory-mapped registers */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> @@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device
> *pdev)
> clk_disable_unprepare(jpeg->clocks[i]);
> }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> + jpeg_iommu_deinit(pdev);
> +#endif
> +
> return 0;
> }
>
>
--
Best regards,
Jacek Anaszewski
Re: [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format
Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal <tony...@samsung.com> > > This patch adds support for decoding 4:1:1 chroma subsampling in the > jpeg header parsing function. > > Signed-off-by: Tony K Nadackal <tony...@samsung.com> > Signed-off-by: Thierry Escande <thierry.esca...@collabora.com> > --- > drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c > b/drivers/media/platform/s5p-jpeg/jpeg-core.c > index 0d83948..770a709 100644 > --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c > +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c > @@ -1236,6 +1236,9 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data > *result, > case 0x33: > ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY; > break; > + case 0x41: > + ctx->subsampling = V4L2_JPEG_CHROMA_SUBSAMPLING_411; > + break; > default: > return false; > } > Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> -- Best regards, Jacek Anaszewski
Re: [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf
Hi Thierry, Thanks for the patch. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal <tony...@samsung.com> > > When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr() > function parses the input jpeg file and takes the width and height > parameters from its header. These new width/height values will be used > for the calculation of stride. HX_JPEG Hardware needs the width and > height values aligned on a 16 bits boundary. This width/height alignment > is handled in the s5p_jpeg_s_fmt_vid_cap() function during the S_FMT > ioctl call. > > But if user space calls the QBUF of OUTPUT buffer after the S_FMT of > CAPTURE buffer, these aligned values will be replaced by the values in > jpeg header. I assume that you may want to avoid re-setting the capture buf format when decoding a stream of JPEGs and you are certain that all of them have the same subsampling. Nonetheless, please keep in mind that in case of Exynos4x12 SoCs there is a risk of permanent decoder hangup if you'd try to decode to a YUV with lower subsampling than the one of input JPEG. s5p_jpeg_try_fmt_vid_cap() does a suitable adjustment to avoid the problem. I'd add a comment over this call to jpeg_bound_align_image() that resigning from executing S_FMT on capture buf for each JPEG image can result in a hardware hangup if forbidden decoding will be enforced. > If the width/height values of jpeg are not aligned, the > decoder output will be corrupted. So in this patch we call > jpeg_bound_align_image() to align the width/height values of Capture > buffer in s5p_jpeg_buf_queue(). > > Signed-off-by: Tony K Nadackal <tony...@samsung.com> > Signed-off-by: Thierry Escande <thierry.esca...@collabora.com> > --- > drivers/media/platform/s5p-jpeg/jpeg-core.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c > b/drivers/media/platform/s5p-jpeg/jpeg-core.c > index 52dc794..6fb1ab4 100644 > --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c > +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c > @@ -2523,6 +2523,13 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb) > q_data = >cap_q; > q_data->w = tmp.w; > q_data->h = tmp.h; > + > + jpeg_bound_align_image(ctx, _data->w, S5P_JPEG_MIN_WIDTH, > +S5P_JPEG_MAX_WIDTH, q_data->fmt->h_align, > +_data->h, S5P_JPEG_MIN_HEIGHT, > +S5P_JPEG_MAX_HEIGHT, q_data->fmt->v_align > + ); > + q_data->size = q_data->w * q_data->h * q_data->fmt->depth >> 3; > } > > v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf); > -- Best regards, Jacek Anaszewski
Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset
Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Abhilash Kesavan <a.kesa...@samsung.com> > > This patch resets the encoding and decoding register bits before doing a > soft reset. > > Signed-off-by: Tony K Nadackal <tony...@samsung.com> > Signed-off-by: Thierry Escande <thierry.esca...@collabora.com> > --- > drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > index a1d823a..9ad8f6d 100644 > --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c > @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base) > unsigned int reg; > > reg = readl(base + EXYNOS4_JPEG_CNTL_REG); > + writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE), > +base + EXYNOS4_JPEG_CNTL_REG); Why is it required? It would be nice if commit message explained that. > + reg = readl(base + EXYNOS4_JPEG_CNTL_REG); > writel(reg & ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); > > udelay(100); > -- Best regards, Jacek Anaszewski
Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition
Hi Mauro, This patch seems to have lost somehow. Could you help merging it? Thanks, Jacek Anaszewski On 05/29/2017 09:29 AM, Alexandre Courbot wrote: > Hi everyone, > > On Thu, Apr 27, 2017 at 4:35 AM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> On 04/26/2017 04:54 AM, Alexandre Courbot wrote: >>> On Wed, Apr 26, 2017 at 4:15 AM, Jacek Anaszewski >>> <jacek.anaszew...@gmail.com> wrote: >>>> Hi Alexandre, >>>> >>>> Thanks for the patch. >>>> >>>> On 04/25/2017 08:19 AM, Alexandre Courbot wrote: >>>>> v4l2_m2m_job_finish(), which is called from the interrupt handler withHi s >>>>> slock acquired, can call the device_run() hook immediately if another >>>>> context was in the queue. This hook also acquires slock, resulting in >>>>> a deadlock for this scenario. >>>>> >>>>> Fix this by releasing slock right before calling v4l2_m2m_job_finish(). >>>>> This is safe to do as the state of the hardware cannot change before >>>>> v4l2_m2m_job_finish() is called anyway. >>>>> >>>>> Signed-off-by: Alexandre Courbot <acour...@chromium.org> >>>>> --- >>>>> drivers/media/platform/s5p-jpeg/jpeg-core.c | 12 +--- >>>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c >>>>> b/drivers/media/platform/s5p-jpeg/jpeg-core.c >>>>> index 52dc7941db65..223b4379929e 100644 >>>>> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c >>>>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c >>>>> @@ -2642,13 +2642,13 @@ static irqreturn_t s5p_jpeg_irq(int irq, void >>>>> *dev_id) >>>>> if (curr_ctx->mode == S5P_JPEG_ENCODE) >>>>> vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); >>>>> v4l2_m2m_buf_done(dst_buf, state); >>>>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> >>>>> curr_ctx->subsampling = s5p_jpeg_get_subsampling_mode(jpeg->regs); >>>>> spin_unlock(>slock); >>>>> >>>>> s5p_jpeg_clear_int(jpeg->regs); >>>>> >>>>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> return IRQ_HANDLED; >>>>> } >>>>> >>>>> @@ -2707,11 +2707,12 @@ static irqreturn_t exynos4_jpeg_irq(int irq, void >>>>> *priv) >>>>> v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_ERROR); >>>>> } >>>>> >>>>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> if (jpeg->variant->version == SJPEG_EXYNOS4) >>>>> curr_ctx->subsampling = >>>>> exynos4_jpeg_get_frame_fmt(jpeg->regs); >>>>> >>>>> spin_unlock(>slock); >>>>> + >>>>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> return IRQ_HANDLED; >>>>> } >>>>> >>>>> @@ -2770,10 +2771,15 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, >>>>> void *dev_id) >>>>> if (curr_ctx->mode == S5P_JPEG_ENCODE) >>>>> vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); >>>>> v4l2_m2m_buf_done(dst_buf, state); >>>>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> >>>>> curr_ctx->subsampling = >>>>> exynos3250_jpeg_get_subsampling_mode(jpeg->regs); >>>>> + >>>>> + spin_unlock(>slock); >>>>> + >>>>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>>>> + return IRQ_HANDLED; >>>>> + >>>>> exit_unlock: >>>>> spin_unlock(>slock); >>>>> return IRQ_HANDLED; >>>>> >>>> >>>> Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> >>>> >>>> Just out of curiosity - could you share how you discovered the problem - >>>> by some static checkers or trying to use the driver? >>> >>> We discovered this issue after adding a new unit test for the jpeg >>> codec in Chromium OS: >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=705971 >>> >>> >From what I understand the test spawns different processes that access >>> the codec device concurrently, creating the situation leading to the >>> bug. >> >> Thanks for the explanation. Nice fix. > > Gentle ping as I am not seeing this patch in the tree yet. Thanks. > >> >>> On a slightly related note, I was thinking whether it would make sense >>> to move the call to v4l2_m2m_job_finish() (and maybe other parts of >>> the current interrupt handler) into a worker or a threaded interrupt >>> handler so as to reduce the time we spend with interrupts disabled. >>> Can I have your input on this idea? >> >> Right, all remaining drivers call it from workers. >> Feel free to submit a patch. >> >> -- >> Best regards, >> Jacek Anaszewski >
Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition
On 04/26/2017 04:54 AM, Alexandre Courbot wrote: > On Wed, Apr 26, 2017 at 4:15 AM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> Hi Alexandre, >> >> Thanks for the patch. >> >> On 04/25/2017 08:19 AM, Alexandre Courbot wrote: >>> v4l2_m2m_job_finish(), which is called from the interrupt handler with >>> slock acquired, can call the device_run() hook immediately if another >>> context was in the queue. This hook also acquires slock, resulting in >>> a deadlock for this scenario. >>> >>> Fix this by releasing slock right before calling v4l2_m2m_job_finish(). >>> This is safe to do as the state of the hardware cannot change before >>> v4l2_m2m_job_finish() is called anyway. >>> >>> Signed-off-by: Alexandre Courbot <acour...@chromium.org> >>> --- >>> drivers/media/platform/s5p-jpeg/jpeg-core.c | 12 +--- >>> 1 file changed, 9 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c >>> b/drivers/media/platform/s5p-jpeg/jpeg-core.c >>> index 52dc7941db65..223b4379929e 100644 >>> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c >>> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c >>> @@ -2642,13 +2642,13 @@ static irqreturn_t s5p_jpeg_irq(int irq, void >>> *dev_id) >>> if (curr_ctx->mode == S5P_JPEG_ENCODE) >>> vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); >>> v4l2_m2m_buf_done(dst_buf, state); >>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> >>> curr_ctx->subsampling = s5p_jpeg_get_subsampling_mode(jpeg->regs); >>> spin_unlock(>slock); >>> >>> s5p_jpeg_clear_int(jpeg->regs); >>> >>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> return IRQ_HANDLED; >>> } >>> >>> @@ -2707,11 +2707,12 @@ static irqreturn_t exynos4_jpeg_irq(int irq, void >>> *priv) >>> v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_ERROR); >>> } >>> >>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> if (jpeg->variant->version == SJPEG_EXYNOS4) >>> curr_ctx->subsampling = >>> exynos4_jpeg_get_frame_fmt(jpeg->regs); >>> >>> spin_unlock(>slock); >>> + >>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> return IRQ_HANDLED; >>> } >>> >>> @@ -2770,10 +2771,15 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, >>> void *dev_id) >>> if (curr_ctx->mode == S5P_JPEG_ENCODE) >>> vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); >>> v4l2_m2m_buf_done(dst_buf, state); >>> - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> >>> curr_ctx->subsampling = >>> exynos3250_jpeg_get_subsampling_mode(jpeg->regs); >>> + >>> + spin_unlock(>slock); >>> + >>> + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); >>> + return IRQ_HANDLED; >>> + >>> exit_unlock: >>> spin_unlock(>slock); >>> return IRQ_HANDLED; >>> >> >> Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> >> >> Just out of curiosity - could you share how you discovered the problem - >> by some static checkers or trying to use the driver? > > We discovered this issue after adding a new unit test for the jpeg > codec in Chromium OS: > > https://bugs.chromium.org/p/chromium/issues/detail?id=705971 > >>From what I understand the test spawns different processes that access > the codec device concurrently, creating the situation leading to the > bug. Thanks for the explanation. Nice fix. > On a slightly related note, I was thinking whether it would make sense > to move the call to v4l2_m2m_job_finish() (and maybe other parts of > the current interrupt handler) into a worker or a threaded interrupt > handler so as to reduce the time we spend with interrupts disabled. > Can I have your input on this idea? Right, all remaining drivers call it from workers. Feel free to submit a patch. -- Best regards, Jacek Anaszewski
Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition
Hi Alexandre, Thanks for the patch. On 04/25/2017 08:19 AM, Alexandre Courbot wrote: > v4l2_m2m_job_finish(), which is called from the interrupt handler with > slock acquired, can call the device_run() hook immediately if another > context was in the queue. This hook also acquires slock, resulting in > a deadlock for this scenario. > > Fix this by releasing slock right before calling v4l2_m2m_job_finish(). > This is safe to do as the state of the hardware cannot change before > v4l2_m2m_job_finish() is called anyway. > > Signed-off-by: Alexandre Courbot <acour...@chromium.org> > --- > drivers/media/platform/s5p-jpeg/jpeg-core.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c > b/drivers/media/platform/s5p-jpeg/jpeg-core.c > index 52dc7941db65..223b4379929e 100644 > --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c > +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c > @@ -2642,13 +2642,13 @@ static irqreturn_t s5p_jpeg_irq(int irq, void *dev_id) > if (curr_ctx->mode == S5P_JPEG_ENCODE) > vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); > v4l2_m2m_buf_done(dst_buf, state); > - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > > curr_ctx->subsampling = s5p_jpeg_get_subsampling_mode(jpeg->regs); > spin_unlock(>slock); > > s5p_jpeg_clear_int(jpeg->regs); > > + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > return IRQ_HANDLED; > } > > @@ -2707,11 +2707,12 @@ static irqreturn_t exynos4_jpeg_irq(int irq, void > *priv) > v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_ERROR); > } > > - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > if (jpeg->variant->version == SJPEG_EXYNOS4) > curr_ctx->subsampling = exynos4_jpeg_get_frame_fmt(jpeg->regs); > > spin_unlock(>slock); > + > + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > return IRQ_HANDLED; > } > > @@ -2770,10 +2771,15 @@ static irqreturn_t exynos3250_jpeg_irq(int irq, void > *dev_id) > if (curr_ctx->mode == S5P_JPEG_ENCODE) > vb2_set_plane_payload(_buf->vb2_buf, 0, payload_size); > v4l2_m2m_buf_done(dst_buf, state); > - v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > > curr_ctx->subsampling = > exynos3250_jpeg_get_subsampling_mode(jpeg->regs); > + > + spin_unlock(>slock); > + > + v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx); > + return IRQ_HANDLED; > + > exit_unlock: > spin_unlock(>slock); > return IRQ_HANDLED; > Acked-by: Jacek Anaszewski <jacek.anaszew...@gmail.com> Just out of curiosity - could you share how you discovered the problem - by some static checkers or trying to use the driver? -- Best regards, Jacek Anaszewski
Re: [PATCH v4l-utils v7 4/7] mediactl: Add media_device creation helpers
Hhi Sakari, On 12/09/2016 12:05 AM, Sakari Ailus wrote: Hi Jacek, On Thu, Dec 08, 2016 at 11:04:20PM +0100, Jacek Anaszewski wrote: Hi Sakari, On 11/24/2016 01:17 PM, Sakari Ailus wrote: Hi Jacek, Thanks for the patchset. On Wed, Oct 12, 2016 at 04:35:19PM +0200, Jacek Anaszewski wrote: Add helper functions that allow for easy instantiation of media_device object basing on whether the media device contains v4l2 subdev with given file descriptor. Doesn't this work with video nodes as well? That's what you seem to be using it for later on. And I think that's actually more useful. The existing implementation uses udev to look up devices. Could you use libudev device enumeration API to find the media devices, and fall back to sysfs if udev doesn't work? There seems to be a reasonable-looking example here: <URL:http://stackoverflow.com/questions/25361042/how-to-list-usb-mass-storage-devices-programatically-using-libudev-in-linux> Actually I am calling media_get_devname_udev() at first and falling back to sysfs similarly as it is accomplished in media_enum_entities(). Is there any specific reason for which I should use libudev device enumeration API in media_device_new_by_subdev_fd()? Yes. You rely on the API udev provides; the sysfs implementation is just a fallback in case udev isn't available in the system. I guess it'd mostly work but, for instance, you assume sysfs is found under /sys. The sysfs itself isn't one of the most stable APIs either. Udev is a simply better option when it's there. Thanks for clarifying that. I'll check the libudev device enumeration API then. -- Best regards, Jacek Anaszewski -- 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 v4l-utils v7 4/7] mediactl: Add media_device creation helpers
Hi Sakari,
On 11/24/2016 01:17 PM, Sakari Ailus wrote:
Hi Jacek,
Thanks for the patchset.
On Wed, Oct 12, 2016 at 04:35:19PM +0200, Jacek Anaszewski wrote:
Add helper functions that allow for easy instantiation of media_device
object basing on whether the media device contains v4l2 subdev with
given file descriptor.
Doesn't this work with video nodes as well? That's what you seem to be using
it for later on. And I think that's actually more useful.
The existing implementation uses udev to look up devices. Could you use
libudev device enumeration API to find the media devices, and fall back to
sysfs if udev doesn't work? There seems to be a reasonable-looking example
here:
<URL:http://stackoverflow.com/questions/25361042/how-to-list-usb-mass-storage-devices-programatically-using-libudev-in-linux>
Actually I am calling media_get_devname_udev() at first and falling back
to sysfs similarly as it is accomplished in media_enum_entities().
Is there any specific reason for which I should use libudev device
enumeration API in media_device_new_by_subdev_fd()?
Best regards,
Jacek Anaszewski
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c | 131 +-
utils/media-ctl/mediactl.h| 27 +
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 155b65f..d347a40 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -440,8 +441,9 @@ static int media_get_devname_udev(struct udev *udev,
return -EINVAL;
devnum = makedev(entity->info.v4l.major, entity->info.v4l.minor);
- media_dbg(entity->media, "looking up device: %u:%u\n",
- major(devnum), minor(devnum));
+ if (entity->media)
+ media_dbg(entity->media, "looking up device: %u:%u\n",
+ major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
if (device) {
p = udev_device_get_devnode(device);
@@ -523,6 +525,7 @@ static int media_get_devname_sysfs(struct media_entity
*entity)
return 0;
}
+
Unrelated change.
static int media_enum_entities(struct media_device *media)
{
struct media_entity *entity;
@@ -707,6 +710,92 @@ struct media_device *media_device_new(const char *devnode)
return media;
}
+struct media_device *media_device_new_by_subdev_fd(int fd, struct media_entity
**fd_entity)
+{
+ char video_devname[32], device_dir_path[256], media_dev_path[256],
media_major_minor[10];
+ struct media_device *media = NULL;
+ struct dirent *entry;
+ struct media_entity tmp_entity;
+ DIR *device_dir;
+ struct udev *udev;
+ char *p;
+ int ret, i;
+
+ if (fd_entity == NULL)
+ return NULL;
+
+ ret = media_get_devname_by_fd(fd, video_devname);
+ if (ret < 0)
+ return NULL;
+
+ p = strrchr(video_devname, '/');
+ if (p == NULL)
+ return NULL;
+
+ ret = media_udev_open();
+ if (ret < 0)
+ return NULL;
+
+ sprintf(device_dir_path, "/sys/class/video4linux/%s/device/", p + 1);
+
+ device_dir = opendir(device_dir_path);
+ if (device_dir == NULL)
+ return NULL;
+
+ while ((entry = readdir(device_dir))) {
+ if (strncmp(entry->d_name, "media", 4))
Why 4? And isn't entry->d_name nul-terminated, so you could use strcmp()?
+ continue;
+
+ sprintf(media_dev_path, "%s%s/dev", device_dir_path,
entry->d_name);
+
+ fd = open(media_dev_path, O_RDONLY);
+ if (fd < 0)
+ continue;
+
+ ret = read(fd, media_major_minor, sizeof(media_major_minor));
+ if (ret < 0)
+ continue;
+
+ sscanf(media_major_minor, "%d:%d", _entity.info.dev.major,
_entity.info.dev.minor);
This would be better split on two lines.
+
+ /* Try to get the device name via udev */
+ if (media_get_devname_udev(udev, _entity)) {
+ /* Fall back to get the device name via sysfs */
+ if (media_get_devname_sysfs(_entity))
+ continue;
+ }
+
+ media = media_device_new(tmp_entity.devname);
+ if (media == NULL)
+ continue;
+
+ ret = media_device_enumerate(media);
+ if (ret < 0) {
+ media_dbg(media, "Failed to enumerate %s (%d)\n",
+
Re: [PATCH v4l-utils v7 1/7] mediactl: Add support for v4l2-ctrl-binding config
Hi Sakari,
On 11/24/2016 03:23 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Oct 12, 2016 at 04:35:16PM +0200, Jacek Anaszewski wrote:
Make struct v4l2_subdev capable of aggregating v4l2-ctrl-bindings -
media device configuration entries. Added are also functions for
validating support for the control on given media entity and checking
whether a v4l2-ctrl-binding has been defined for a media entity.
I still don't think this belongs here.
I think I told you about the generic pipeline configuration library I worked
on years ago; unfortunately it was left on prototype stage. Still, what I
realised was that something very similar is needed in that library ---
associating information to the representation of the media entities (or the
V4L2 sub-devices) in user space that has got nothing to do with the devices
themselves.
We could have e.g. a list of key--value pairs where the key is a pointer
provided by the user (i.e. application, another library) that could be
associated with the value. That would avoid having explicit information on
that in the struct media_entity itself.
An quicker alternative would be to manage a list of controls e.g. in the
plugin itself and store the media entity where they're implemented in that
list, with the control value.
We are not interested in media entity -> control value relation but
but media entity -> control id. The value is an arbitrary choice of
userspace. Binding's task is to route the ctrl ioctl to a desired
pipeline entity if more than one supports same control.
Effectively we'd need a list of controls as a keys and entities
as values. The list should be allocated dynamically as it would
make no sense to keep keys for all v4l2 controls if only few bindings
are defined.
Best regards,
Jacek Anaszewski
Cc Laurent as well.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libv4l2subdev.c | 32
utils/media-ctl/v4l2subdev.h| 19 +++
2 files changed, 51 insertions(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index c3439d7..4f8ee7f 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -50,7 +50,15 @@ int v4l2_subdev_create(struct media_entity *entity)
entity->sd->fd = -1;
+ entity->sd->v4l2_ctrl_bindings = malloc(sizeof(__u32));
+ if (entity->sd->v4l2_ctrl_bindings == NULL)
+ goto err_v4l2_ctrl_bindings_alloc;
+
return 0;
+
+err_v4l2_ctrl_bindings_alloc:
+ free(entity->sd);
+ return -ENOMEM;
}
int v4l2_subdev_create_opened(struct media_entity *entity, int fd)
@@ -102,6 +110,7 @@ void v4l2_subdev_close(struct media_entity *entity)
if (entity->sd->fd_owner)
close(entity->sd->fd);
+ free(entity->sd->v4l2_ctrl_bindings);
free(entity->sd);
}
@@ -884,3 +893,26 @@ const enum v4l2_mbus_pixelcode
*v4l2_subdev_pixelcode_list(unsigned int *length)
return mbus_codes;
}
+
+int v4l2_subdev_supports_v4l2_ctrl(struct media_device *media,
+ struct media_entity *entity,
+ __u32 ctrl_id)
+{
+ struct v4l2_queryctrl queryctrl = {};
+ int ret;
+
+ ret = v4l2_subdev_open(entity);
+ if (ret < 0)
+ return ret;
+
+ queryctrl.id = ctrl_id;
+
+ ret = ioctl(entity->sd->fd, VIDIOC_QUERYCTRL, );
+ if (ret < 0)
+ return ret;
+
+ media_dbg(media, "Validated control \"%s\" (0x%8.8x) on entity %s\n",
+ queryctrl.name, queryctrl.id, entity->info.name);
+
+ return 0;
+}
diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
index 011fab1..4dee6b1 100644
--- a/utils/media-ctl/v4l2subdev.h
+++ b/utils/media-ctl/v4l2subdev.h
@@ -26,10 +26,14 @@
struct media_device;
struct media_entity;
+struct media_device;
struct v4l2_subdev {
int fd;
unsigned int fd_owner:1;
+
+ __u32 *v4l2_ctrl_bindings;
+ unsigned int num_v4l2_ctrl_bindings;
};
/**
@@ -314,4 +318,19 @@ enum v4l2_field v4l2_subdev_string_to_field(const char
*string);
const enum v4l2_mbus_pixelcode *v4l2_subdev_pixelcode_list(
unsigned int *length);
+/**
+ * @brief Check if sub-device supports given v4l2 control
+ * @param media - media device.
+ * @param entity - media entity.
+ * @param ctrl_id - id of the v4l2 control to check.
+ *
+ * Verify if the sub-device associated with given media entity
+ * supports v4l2-control with given ctrl_id.
+ *
+ * @return 1 if the control is supported, 0 otherwise.
+ */
+int v4l2_subdev_supports_v4l2_ctrl(struct media_device *device,
+ struct media_entity *entity,
+ __u32 ctrl_id);
+
#endif
--
To unsubsc
Re: [PATCH v4l-utils v7 7/7] Add a libv4l plugin for Exynos4 camera
Hi Sakari,
On 11/24/2016 04:11 PM, Sakari Ailus wrote:
Hi Jacek,
Thank you for your continued work on the Exynos plugin patchset!
I think we're pretty close to being able to merge the set, if you could
still bear with me awhile. :-)
Your demanding reviewer I must admit. :-)
Of course, I appreciate all your remarks, they're highly valuable.
On Wed, Oct 12, 2016 at 04:35:22PM +0200, Jacek Anaszewski wrote:
...
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..c38b7f6
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,19 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+media-bus-format-names.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*FMT_//; /FIXED/ d; s/\t.*//; s/.*/{
\"&\", MEDIA_BUS_FMT_& },/;' \
+ < $< > $@
+
+media-bus-format-codes.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*#define //; /FIXED/ d; s/\t.*//;
s/.*/ &,/;' \
+ < $< > $@
+
+BUILT_SOURCES = media-bus-format-names.h media-bus-format-codes.h
+CLEANFILES = $(BUILT_SOURCES)
It'd be nice to be able to use the same generated headers that now are under
utils/media-ctl, instead of copying the sed script here in verbatim. If the
script is changed or fixed in some way, the other location probably will
remain unchanged...
The problem is that those headers are built after this plugin.
I wonder if there's a proper way to generate build time headers such as
these.
Another less good alternative would be to put these into a separate Makefile
and include that Makefile where the headers are needed. But I don't like
that much either, it's a hack.
In this case it seems to be the only feasible optimization.
+
+nodist_libv4l_exynos4_camera_la_SOURCES = $(BUILT_SOURCES)
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
../../utils/media-ctl/libmediactl.c ../../utils/media-ctl/libv4l2subdev.c
../../utils/media-ctl/mediatext.c
+libv4l_exynos4_camera_la_CFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
new file mode 100644
index 000..c219fe5
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
@@ -0,0 +1,1325 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski <j.anaszew...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../../utils/media-ctl/mediactl.h"
+#include "../../utils/media-ctl/mediatext.h"
+#include "../../utils/media-ctl/v4l2subdev.h"
+#include "libv4l-plugin.h"
+
+#ifdef DEBUG
+#define V4L2_EXYNOS4_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_EXYNOS4_DBG(format, ARG...)
+#endif
+
+#define V4L2_EXYNOS4_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define V4L2_EXYNOS4_LOG(format, ARG...)\
+ fprintf(stdout, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define VIDIOC_CTRL(type) \
+ ((type) == VIDIOC_S_CTRL ? "VIDIOC_S_CTRL" : \
+ "VIDIOC_G_CTRL")
+
+#if HAVE_VISIBILITY
+#define PLUGIN_PUBLIC __attribute__ ((visibility("default")))
+#else
+#define PLUGIN_PUBLIC
+#endif
+
+#define SYS_IOCTL(fd, cmd, arg) \
+ syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg))
+
+#define SIMPLE_CONVERT_IOCTL(fd, cmd, arg, __struc) ({ \
+ int __ret; \
+ struct __struc *req = arg; \
+ uint32_t type = req->type; \
+ req->type = convert_type(type); \
+ __ret = SYS_IOCTL(fd, cmd, arg);\
+ req->type = type; \
+ __ret; \
+ })
+
+#ifnd
Re: [PATCH v4l-utils v7 6/7] mediactl: libv4l2subdev: add support for comparing mbus formats
On 11/24/2016 03:36 PM, Sakari Ailus wrote: Hi Jacek, On Wed, Oct 12, 2016 at 04:35:21PM +0200, Jacek Anaszewski wrote: This patch adds a function for checking whether two mbus formats are compatible. Compatible doesn't in general case mean the same as... the same. On parallel busses a 10-bit source can be connected to an 8-bit sink-for instance. How about moving this to the plugin, and if someone else needs it, then we move it out later? This is a good idea, as I am checking not all fields of v4l2_mbus_framefmt, but only those which matter during Exynos4 media devuce pipeline format negotiation. -- Best regards, Jacek Anaszewski -- 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 v4l-utils v7 4/7] mediactl: Add media_device creation helpers
On 11/24/2016 03:32 PM, Sakari Ailus wrote:
[...]
+ sprintf(device_dir_path, "/sys/class/video4linux/%s/device/", p + 1);
+
+ device_dir = opendir(device_dir_path);
+ if (device_dir == NULL)
+ return NULL;
+
+ while ((entry = readdir(device_dir))) {
+ if (strncmp(entry->d_name, "media", 4))
Why 4? And isn't entry->d_name nul-terminated, so you could use strcmp()?
Media devices, as other devices, have numerical postfix, which is
not of our interest.
Right. But still 5 would be the right number as we should also check the
last "a".
Of course, this needs to be fixed, thanks.
--
Best regards,
Jacek Anaszewski
--
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 v4l-utils v7 2/7] mediatext: Add library
Hi Sakari,
On 11/24/2016 02:01 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Oct 12, 2016 at 04:35:17PM +0200, Jacek Anaszewski wrote:
libmediatext is a helper library for converting configurations (Media
controller links, V4L2 controls and V4L2 sub-device media bus formats and
selections) from text-based form into IOCTLs.
libmediatext depends on libv4l2subdev and libmediactl.
I'm not very happy with the plugin using the mediatext library as it was in
2013. I've heavily changed (and extended) the library since to cover
additional use cases such as the request API:
<URL:http://www.spinics.net/lists/linux-media/msg103242.html>
This version is not meaningfully extensible in forward-compatible way. In
order to resolve the matter quickly without making merging the further
developed library difficult, I propose merging the code to the plugin
itself. We could later check if it could be refactored.
How about that?
It works for me.
Thanks,
Jacek Anaszewski
Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
Signed-off-by: Teemu Tuominen <teemu.tuomi...@intel.com>
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
---
utils/media-ctl/Makefile.am| 10 +-
utils/media-ctl/libmediatext.pc.in | 10 ++
utils/media-ctl/mediatext-test.c | 64
utils/media-ctl/mediatext.c| 312 +
utils/media-ctl/mediatext.h| 52 +++
5 files changed, 446 insertions(+), 2 deletions(-)
create mode 100644 utils/media-ctl/libmediatext.pc.in
create mode 100644 utils/media-ctl/mediatext-test.c
create mode 100644 utils/media-ctl/mediatext.c
create mode 100644 utils/media-ctl/mediatext.h
diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index ee7dcc9..2f12357 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -1,4 +1,4 @@
-noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la
+noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la
libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h
libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
@@ -21,9 +21,15 @@ libv4l2subdev_la_LIBADD = libmediactl.la
libv4l2subdev_la_CFLAGS = -static
libv4l2subdev_la_LDFLAGS = -static
+libmediatext_la_SOURCES = mediatext.c
+libmediatext_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
+libmediatext_la_LDFLAGS = -static $(LIBUDEV_LIBS)
+
mediactl_includedir=$(includedir)/mediactl
noinst_HEADERS = mediactl.h v4l2subdev.h
-bin_PROGRAMS = media-ctl
+bin_PROGRAMS = media-ctl mediatext-test
media_ctl_SOURCES = media-ctl.c options.c options.h tools.h
media_ctl_LDADD = libmediactl.la libv4l2subdev.la
+mediatext_test_SOURCES = mediatext-test.c
+mediatext_test_LDADD = libmediatext.la libmediactl.la libv4l2subdev.la
diff --git a/utils/media-ctl/libmediatext.pc.in
b/utils/media-ctl/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/utils/media-ctl/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/mediatext-test.c b/utils/media-ctl/mediatext-test.c
new file mode 100644
index 000..b8b9282
--- /dev/null
+++ b/utils/media-ctl/mediatext-test.c
@@ -0,0 +1,64 @@
+/*
+ * libmediatext test program
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Contact: Sakari Ailus <sakari.ai...@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+#include
+
+#include "mediactl.h"
+#include "mediatext.h"
+
+int main(int argc, char *argv[])
+{
+ struct media_device *device;
+ int rval;
+
+ if (argc != 3) {
+ fprintf(stderr, "usage: %s \n\n",
argv[0]);
+ fprintf(stderr, "\tstring := [ v4l2-ctrl |?v4l2-mbus | link-reset |
link-conf]\n\n");
+ fprintf(stderr, "\tv4l2-ctrl := \"entity\" ctrl_type ctrl_id
ctrl_value\n");
+ fprintf(stderr, "\tctrl_type := [ int | int64 | bitmask ]\n");
+ fprintf(stderr, "\tctrl_value := [ %%d | %%PRId64 | bitmask_value
]\n&quo
Re: [PATCH v4l-utils v7 3/7] mediactl: Add media_entity_get_backlinks()
Hi Sakari,
Thanks for the review.
On 11/24/2016 01:40 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Oct 12, 2016 at 04:35:18PM +0200, Jacek Anaszewski wrote:
Add a new graph helper useful for discovering video pipeline.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c | 21 +
utils/media-ctl/mediactl.h| 15 +++
2 files changed, 36 insertions(+)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 91ed003..155b65f 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -36,6 +36,7 @@
#include
#include
+#include
Is there something that needs this one in the patch?
MAJOR and MINOR macros.
#include
#include "mediactl.h"
@@ -172,6 +173,26 @@ const struct media_entity_desc
*media_entity_get_info(struct media_entity *entit
return >info;
}
+int media_entity_get_backlinks(struct media_entity *entity,
+ struct media_link **backlinks,
+ unsigned int *num_backlinks)
+{
+ unsigned int num_bklinks = 0;
+ int i;
+
+ if (entity == NULL || backlinks == NULL || num_backlinks == NULL)
+ return -EINVAL;
+
If you have an interface that accesses a memory buffer of unknown size, you
need to verify that the user has provided a buffer large enough.
How about using the num_backlinks argument to provide the maximum size to
the function, and passing the actual number to the user, the latter of which
you already do?
Sounds reasonable.
Alternatively, an iterator style API could be nice as well. Up to you.
It would probably need an addition of some generic infrastructure.
I suppose that there is no such a feature in v4l-utils?
I wonder what Laurent thinks.
+ for (i = 0; i < entity->num_links; ++i)
+ if ((entity->links[i].flags & MEDIA_LNK_FL_ENABLED) &&
+ (entity->links[i].sink->entity == entity))
+ backlinks[num_bklinks++] = >links[i];
+
+ *num_backlinks = num_bklinks;
+
+ return 0;
+}
+
/*
-
* Open/close
*/
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index 336cbf9..b1f33cd 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -434,6 +434,20 @@ int media_parse_setup_link(struct media_device *media,
int media_parse_setup_links(struct media_device *media, const char *p);
/**
+ * @brief Get entity's enabled backlinks
+ * @param entity - media entity.
+ * @param backlinks - array of pointers to matching backlinks.
+ * @param num_backlinks - number of matching backlinks.
+ *
+ * Get links that are connected to the entity sink pads.
+ *
+ * @return 0 on success, or a negative error code on failure.
+ */
+int media_entity_get_backlinks(struct media_entity *entity,
+ struct media_link **backlinks,
+ unsigned int *num_backlinks);
+
+/**
* @brief Get v4l2_subdev for the entity
* @param entity - media entity
*
@@ -443,4 +457,5 @@ int media_parse_setup_links(struct media_device *media,
const char *p);
*/
struct v4l2_subdev *media_entity_get_v4l2_subdev(struct media_entity *entity);
+
Unrelated change.
#endif
--
Best regards,
Jacek Anaszewski
--
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 v4l-utils v7 4/7] mediactl: Add media_device creation helpers
Hi Sakari,
Thanks for the review.
On 11/24/2016 01:17 PM, Sakari Ailus wrote:
Hi Jacek,
Thanks for the patchset.
On Wed, Oct 12, 2016 at 04:35:19PM +0200, Jacek Anaszewski wrote:
Add helper functions that allow for easy instantiation of media_device
object basing on whether the media device contains v4l2 subdev with
given file descriptor.
Doesn't this work with video nodes as well? That's what you seem to be using
it for later on. And I think that's actually more useful.
Exactly, thanks for spotting this.
s/v4l2 subdev/video device opened/
The existing implementation uses udev to look up devices. Could you use
libudev device enumeration API to find the media devices, and fall back to
sysfs if udev doesn't work? There seems to be a reasonable-looking example
here:
<URL:http://stackoverflow.com/questions/25361042/how-to-list-usb-mass-storage-devices-programatically-using-libudev-in-linux>
I'll check that, thanks.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c | 131 +-
utils/media-ctl/mediactl.h| 27 +
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 155b65f..d347a40 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -440,8 +441,9 @@ static int media_get_devname_udev(struct udev *udev,
return -EINVAL;
devnum = makedev(entity->info.v4l.major, entity->info.v4l.minor);
- media_dbg(entity->media, "looking up device: %u:%u\n",
- major(devnum), minor(devnum));
+ if (entity->media)
+ media_dbg(entity->media, "looking up device: %u:%u\n",
+ major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
if (device) {
p = udev_device_get_devnode(device);
@@ -523,6 +525,7 @@ static int media_get_devname_sysfs(struct media_entity
*entity)
return 0;
}
+
Unrelated change.
static int media_enum_entities(struct media_device *media)
{
struct media_entity *entity;
@@ -707,6 +710,92 @@ struct media_device *media_device_new(const char *devnode)
return media;
}
+struct media_device *media_device_new_by_subdev_fd(int fd, struct media_entity
**fd_entity)
+{
+ char video_devname[32], device_dir_path[256], media_dev_path[256],
media_major_minor[10];
+ struct media_device *media = NULL;
+ struct dirent *entry;
+ struct media_entity tmp_entity;
+ DIR *device_dir;
+ struct udev *udev;
+ char *p;
+ int ret, i;
+
+ if (fd_entity == NULL)
+ return NULL;
+
+ ret = media_get_devname_by_fd(fd, video_devname);
+ if (ret < 0)
+ return NULL;
+
+ p = strrchr(video_devname, '/');
+ if (p == NULL)
+ return NULL;
+
+ ret = media_udev_open();
+ if (ret < 0)
+ return NULL;
+
+ sprintf(device_dir_path, "/sys/class/video4linux/%s/device/", p + 1);
+
+ device_dir = opendir(device_dir_path);
+ if (device_dir == NULL)
+ return NULL;
+
+ while ((entry = readdir(device_dir))) {
+ if (strncmp(entry->d_name, "media", 4))
Why 4? And isn't entry->d_name nul-terminated, so you could use strcmp()?
Media devices, as other devices, have numerical postfix, which is
not of our interest.
+ continue;
+
+ sprintf(media_dev_path, "%s%s/dev", device_dir_path,
entry->d_name);
+
+ fd = open(media_dev_path, O_RDONLY);
+ if (fd < 0)
+ continue;
+
+ ret = read(fd, media_major_minor, sizeof(media_major_minor));
+ if (ret < 0)
+ continue;
+
+ sscanf(media_major_minor, "%d:%d", _entity.info.dev.major,
_entity.info.dev.minor);
This would be better split on two lines.
OK.
+
+ /* Try to get the device name via udev */
+ if (media_get_devname_udev(udev, _entity)) {
+ /* Fall back to get the device name via sysfs */
+ if (media_get_devname_sysfs(_entity))
+ continue;
+ }
+
+ media = media_device_new(tmp_entity.devname);
+ if (media == NULL)
+ continue;
+
+ ret = media_device_enumerate(media);
+ if (ret < 0) {
+ media_dbg(media, "Failed to enumerate %s (%d)\n",
+ tmp_entity.devname,
Re: [PATCH v4l-utils v7 0/7] Add a plugin for Exynos4 camera
On 11/24/2016 10:10 AM, Mauro Carvalho Chehab wrote: Em Thu, 24 Nov 2016 09:10:28 +0100 Jacek Anaszewski <j.anaszew...@samsung.com> escreveu: On 11/23/2016 10:51 PM, Mauro Carvalho Chehab wrote: Em Thu, 03 Nov 2016 13:13:12 +0100 Jacek Anaszewski <j.anaszew...@samsung.com> escreveu: Hi Hans, On 11/03/2016 12:51 PM, Hans Verkuil wrote: Hi all, Is there anything that blocks me from merging this? This plugin work has been ongoing for years and unless there are serious objections I propose that this is merged. Jacek, is there anything missing that would prevent merging this? There were issues raised by Sakari during last review, related to the way how v4l2 control bindings are defined. That discussion wasn't finished, so I stayed by my approach. Are those things something that could be fixed later without breaking binary apps? If not, then perhaps it is time to merge this. They are related to the format of configuration file being introduced by this patch set, so there are no binary apps depending on it. Ok. Yet, changing the configuration file format could be a pain for the users. The best would be to add a format that would be extensible enough to be able to add support for other needs in the future. Few days ago I had a discussion with Sakari on IRC, and he pointed me to his patch set adding an extended version of his mediatext library RFC [0], the first version of which I included to my patch set, and extended a bit. A decision should be made if I should adapt my API to the mediatext RFC. RFC is not a stable ground though. [0] https://www.spinics.net/lists/linux-media/msg103242.html If I understood well, you're proposing to use this format for the configuration file: link-conf "s5p-mipi-csis.0":1 -> "FIMC.0":0 [1] ctrl-to-subdev-conf 0x0098091f -> "fimc.0.capture" ctrl-to-subdev-conf 0x00980902 -> "S5C73M3" ctrl-to-subdev-conf 0x00980922 -> "fimc.0.capture" ctrl-to-subdev-conf 0x009a0914 -> "S5C73M3" What if, instead, you use something like: [group] key = value type of configuration file? This way, if one wants to extend it, all it is needed is to add other groups or more key types. The users with an older configuration won't suffer if newer groups and newer key types were added. E. g something like: [link] source = "s5p-mipi-csis.0":1 sink = "FIMC.0":0 [1] [ctrl-to-subdev] ctrl_id = 0x0098091f subdev= "fimc.0.capture" [ctrl-to-subdev] ctrl_id = 0x00980902 subdev = "S5C73M3" ... This way, Sakari's patches could use the same format to add mediatext entries. E. g. something like (the actual content actually depends on what is here - I'm just wild guessing from the tree diagram at the RFC e-mail): [mediatext] shell_script = foo devnode = /dev/video* devnode = /dev/mediaX devnode = /dev/v4l-subdev* without needing to change the format of the file, and keeping it backward compatible. First version of this patch set used similar configuration format but Sakari asked me to switch to the format accepted by media-ctl, which the first version of mediatext adhered to. Sakari has pledged to review this patch set, so we will be able to decide on how to proceed no sooner than that. Best regards, Jacek Anaszewski Regards, Mauro Other than that - I've tested it and it works fine both with GStreamer and my test app. Best regards, Jacek Anaszewski On 12/10/16 16:35, Jacek Anaszewski wrote: This is a seventh version of the patch series adding a plugin for the Exynos4 camera. Last version [0] of the patch set was posted in January. The plugin doesn't link against libmediactl, but has its sources compiled in. Currently utils are built after the plugins, but libv4l-exynos4-camera plugin depends on the utils. In order to link the plugin against libmediactl the build system would have to be modified. Changes from v6: - close v4l2 sub-devices on media device release - moved non-generic code from libmediactl to the plugin - resigned from adding libmedia_ioctl library and moved all its code to the plugin, since it depended on pipeline representation, which was not generic for all possible media device topologies - used media_get_info()->name instead of adding media_entity_get_name - renamed media_get_backlinks_by_entity() to media_entity_get_backlinks(() - moved pipeline from struct media_device to the plugin - changed the way of associating video device file descriptor with media device - switched to using auto-generated media-bus-format-names.h header file - renamed v4l2-ctrl-redir config entry name to v4l2-ctrl-binding Changes from v5: - fixed and tested use cases with S5K6A3 sensor and FIMC-IS-ISP - added conversion "colorspace
Re: [PATCH v4l-utils v7 0/7] Add a plugin for Exynos4 camera
On 11/23/2016 10:51 PM, Mauro Carvalho Chehab wrote: Em Thu, 03 Nov 2016 13:13:12 +0100 Jacek Anaszewski <j.anaszew...@samsung.com> escreveu: Hi Hans, On 11/03/2016 12:51 PM, Hans Verkuil wrote: Hi all, Is there anything that blocks me from merging this? This plugin work has been ongoing for years and unless there are serious objections I propose that this is merged. Jacek, is there anything missing that would prevent merging this? There were issues raised by Sakari during last review, related to the way how v4l2 control bindings are defined. That discussion wasn't finished, so I stayed by my approach. Are those things something that could be fixed later without breaking binary apps? If not, then perhaps it is time to merge this. They are related to the format of configuration file being introduced by this patch set, so there are no binary apps depending on it. Few days ago I had a discussion with Sakari on IRC, and he pointed me to his patch set adding an extended version of his mediatext library RFC [0], the first version of which I included to my patch set, and extended a bit. A decision should be made if I should adapt my API to the mediatext RFC. RFC is not a stable ground though. [0] https://www.spinics.net/lists/linux-media/msg103242.html Other than that - I've tested it and it works fine both with GStreamer and my test app. Best regards, Jacek Anaszewski On 12/10/16 16:35, Jacek Anaszewski wrote: This is a seventh version of the patch series adding a plugin for the Exynos4 camera. Last version [0] of the patch set was posted in January. The plugin doesn't link against libmediactl, but has its sources compiled in. Currently utils are built after the plugins, but libv4l-exynos4-camera plugin depends on the utils. In order to link the plugin against libmediactl the build system would have to be modified. Changes from v6: - close v4l2 sub-devices on media device release - moved non-generic code from libmediactl to the plugin - resigned from adding libmedia_ioctl library and moved all its code to the plugin, since it depended on pipeline representation, which was not generic for all possible media device topologies - used media_get_info()->name instead of adding media_entity_get_name - renamed media_get_backlinks_by_entity() to media_entity_get_backlinks(() - moved pipeline from struct media_device to the plugin - changed the way of associating video device file descriptor with media device - switched to using auto-generated media-bus-format-names.h header file - renamed v4l2-ctrl-redir config entry name to v4l2-ctrl-binding Changes from v5: - fixed and tested use cases with S5K6A3 sensor and FIMC-IS-ISP - added conversion "colorspace id to string" Changes from v4: - removed some redundant functions for traversing media device graph and switched over to using existing ones - avoided accessing struct v4l2_subdev from libmediactl - applied various improvements Changes from v3: - added struct v4l2_subdev and put entity fd and information about supported controls to it - improved functions for negotiating and setting pipeline format by using available libv4lsubdev API - applied minor improvements and cleanups Changes from v2: - switched to using mediatext library for parsing the media device configuration - extended libmediactl - switched to using libmediactl Changes from v1: - removed redundant mbus code negotiation - split the parser, media device helpers and ioctl wrappers to the separate modules - added mechanism for querying extended controls - applied various fixes and modifications The plugin was tested on v4.8-rc2 (exynos4-is driver doesn't proble properly with current master branch of linux-media.git) with patches fixing several issues for Exynos4 camera: [1], [2], [3]. The plugin expects a configuration file: /var/lib/libv4l/exynos4_capture_conf Exemplary configuration file for pipeline with sensor S5C73M3 (rear camera): == link-conf "s5p-mipi-csis.0":1 -> "FIMC.0":0 [1] v4l2-ctrl-binding 0x0098091f -> "fimc.0.capture" v4l2-ctrl-binding 0x00980902 -> "S5C73M3" v4l2-ctrl-binding 0x00980922 -> "fimc.0.capture" v4l2-ctrl-binding 0x009a0914 -> "S5C73M3" == With this settings the plugin can be tested on the exynos4412-trats2 board using following gstreamer pipeline: gst-launch-1.0 v4l2src device=/dev/video1 extra-controls="c,rotate=90,color_effects=2" ! video/x-raw,width=960,height=720 ! fbdevsink Exemplary configuration file for pipeline with sensor S5K6A3 (front camera): == link-conf "s5p-mipi-csis.1":1
Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
On 11/09/2016 07:26 PM, Rob Herring wrote: On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote: On 11/03/2016 11:10 AM, Andi Shyti wrote: Hi Jacek, Only DT bindings of LED class drivers should be placed in Documentation/devicetree/bindings/leds. Please move it to the media bindings. that's where I placed it first, but Rob asked me to put it in the LED directory and Cc the LED mailining list. That's the discussion of the version 2: https://lkml.org/lkml/2016/9/12/380 Rob, Jacek, could you please agree where I can put the binding? I'm not sure if this is a good approach. I've noticed also that backlight bindings have been moved to leds, whereas they don't look similarly. We have common.txt LED bindings, that all LED class drivers' bindings have to follow. Neither backlight bindings nor these ones do that, which introduces some mess. And there are probably LED bindings that don't follow common.txt either. Eventually adding a sub-directory, e.g. remote_control could make it somehow logically justified, but still - shouldn't bindings be placed in the documentation directory related to the subsystem of the driver they are predestined to? No. While binding directories often mirror the driver directories, they are not the same. Bindings are grouped by types of h/w and IR LEDs are a type of LED. If you prefer a sub-dir, that is fine with me. Fine. So how about sub-dir "ir" ? -- Best regards, Jacek Anaszewski -- 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 v4l-utils v7 0/7] Add a plugin for Exynos4 camera
Hi Hans, On 11/03/2016 12:51 PM, Hans Verkuil wrote: Hi all, Is there anything that blocks me from merging this? This plugin work has been ongoing for years and unless there are serious objections I propose that this is merged. Jacek, is there anything missing that would prevent merging this? There were issues raised by Sakari during last review, related to the way how v4l2 control bindings are defined. That discussion wasn't finished, so I stayed by my approach. Other than that - I've tested it and it works fine both with GStreamer and my test app. Best regards, Jacek Anaszewski On 12/10/16 16:35, Jacek Anaszewski wrote: This is a seventh version of the patch series adding a plugin for the Exynos4 camera. Last version [0] of the patch set was posted in January. The plugin doesn't link against libmediactl, but has its sources compiled in. Currently utils are built after the plugins, but libv4l-exynos4-camera plugin depends on the utils. In order to link the plugin against libmediactl the build system would have to be modified. Changes from v6: - close v4l2 sub-devices on media device release - moved non-generic code from libmediactl to the plugin - resigned from adding libmedia_ioctl library and moved all its code to the plugin, since it depended on pipeline representation, which was not generic for all possible media device topologies - used media_get_info()->name instead of adding media_entity_get_name - renamed media_get_backlinks_by_entity() to media_entity_get_backlinks(() - moved pipeline from struct media_device to the plugin - changed the way of associating video device file descriptor with media device - switched to using auto-generated media-bus-format-names.h header file - renamed v4l2-ctrl-redir config entry name to v4l2-ctrl-binding Changes from v5: - fixed and tested use cases with S5K6A3 sensor and FIMC-IS-ISP - added conversion "colorspace id to string" Changes from v4: - removed some redundant functions for traversing media device graph and switched over to using existing ones - avoided accessing struct v4l2_subdev from libmediactl - applied various improvements Changes from v3: - added struct v4l2_subdev and put entity fd and information about supported controls to it - improved functions for negotiating and setting pipeline format by using available libv4lsubdev API - applied minor improvements and cleanups Changes from v2: - switched to using mediatext library for parsing the media device configuration - extended libmediactl - switched to using libmediactl Changes from v1: - removed redundant mbus code negotiation - split the parser, media device helpers and ioctl wrappers to the separate modules - added mechanism for querying extended controls - applied various fixes and modifications The plugin was tested on v4.8-rc2 (exynos4-is driver doesn't proble properly with current master branch of linux-media.git) with patches fixing several issues for Exynos4 camera: [1], [2], [3]. The plugin expects a configuration file: /var/lib/libv4l/exynos4_capture_conf Exemplary configuration file for pipeline with sensor S5C73M3 (rear camera): == link-conf "s5p-mipi-csis.0":1 -> "FIMC.0":0 [1] v4l2-ctrl-binding 0x0098091f -> "fimc.0.capture" v4l2-ctrl-binding 0x00980902 -> "S5C73M3" v4l2-ctrl-binding 0x00980922 -> "fimc.0.capture" v4l2-ctrl-binding 0x009a0914 -> "S5C73M3" == With this settings the plugin can be tested on the exynos4412-trats2 board using following gstreamer pipeline: gst-launch-1.0 v4l2src device=/dev/video1 extra-controls="c,rotate=90,color_effects=2" ! video/x-raw,width=960,height=720 ! fbdevsink Exemplary configuration file for pipeline with sensor S5K6A3 (front camera): == link-conf "s5p-mipi-csis.1":1 -> "FIMC-LITE.1":0 [1] link-conf "FIMC-LITE.1":2 -> "FIMC-IS-ISP":0 [1] link-conf "FIMC-IS-ISP":1 -> "FIMC.0":1 [1] == gst-launch-1.0 v4l2src device=/dev/video1 extra-controls="c,rotate=270,color_effects=2,horizontal_flip=1" ! video/x-raw,width=960,height=920 ! fbdevsink Best Regards, Jacek Anaszewski [0] http://www.spinics.net/lists/linux-media/msg96510.html [1] https://patchwork.kernel.org/patch/9335197/ [2] https://patchwork.kernel.org/patch/9270985/ [3] https://patchwork.kernel.org/patch/9308923/ [4] https://patchwork.kernel.org/patch/9335273/ Jacek Anaszewski (7): mediactl: Add support for v4l2-ctrl-binding config mediatext: Add library mediactl: Add media_entity_get_backlinks()
Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
On 11/03/2016 11:10 AM, Andi Shyti wrote: Hi Jacek, Only DT bindings of LED class drivers should be placed in Documentation/devicetree/bindings/leds. Please move it to the media bindings. that's where I placed it first, but Rob asked me to put it in the LED directory and Cc the LED mailining list. That's the discussion of the version 2: https://lkml.org/lkml/2016/9/12/380 Rob, Jacek, could you please agree where I can put the binding? I'm not sure if this is a good approach. I've noticed also that backlight bindings have been moved to leds, whereas they don't look similarly. We have common.txt LED bindings, that all LED class drivers' bindings have to follow. Neither backlight bindings nor these ones do that, which introduces some mess. Eventually adding a sub-directory, e.g. remote_control could make it somehow logically justified, but still - shouldn't bindings be placed in the documentation directory related to the subsystem of the driver they are predestined to? -- Best regards, Jacek Anaszewski -- 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 v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
Hi Andi,
Only DT bindings of LED class drivers should be placed in
Documentation/devicetree/bindings/leds. Please move it to the
media bindings.
Thanks,
Jacek Anaszewski
On 11/02/2016 11:40 AM, Andi Shyti wrote:
Document the ir-spi driver's binding which is a IR led driven
through the SPI line.
Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
---
.../devicetree/bindings/leds/spi-ir-led.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/spi-ir-led.txt
diff --git a/Documentation/devicetree/bindings/leds/spi-ir-led.txt
b/Documentation/devicetree/bindings/leds/spi-ir-led.txt
new file mode 100644
index 000..896b699
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/spi-ir-led.txt
@@ -0,0 +1,29 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+ - compatible: should be "ir-spi-led".
+
+Optional properties:
+ - duty-cycle: 8 bit balue that represents the percentage of one period
+ in which the signal is active. It can be 50, 60, 70, 75, 80 or 90.
+ - led-active-low: boolean value that specifies whether the output is
+ negated with a NOT gate.
+ - power-supply: specifies the power source. It can either be a regulator
+ or a gpio which enables a regulator, i.e. a regulator-fixed as
+ described in
+ Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+
+Example:
+
+ irled@0 {
+ compatible = "ir-spi-led";
+ reg = <0x0>;
+ spi-max-frequency = <500>;
+ power-supply = <_led>;
+ led-active-low;
+ duty-cycle = /bits/ 8 <60>;
+ };
--
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 v4l-utils 7/7 v7.1] Add a libv4l plugin for Exynos4 camera
Forgot to add changelog: Changes since v7: - fixed and improved ctrl ioctl handlers Best regards, Jacek Anaszewski On 10/13/2016 04:19 PM, Jacek Anaszewski wrote: The plugin provides support for the media device on Exynos4 SoC. It performs single plane <-> multi plane API conversion, video pipeline linking and takes care of automatic data format negotiation for the whole pipeline, after intercepting VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls. Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com> Acked-by: Kyungmin Park <kyungmin.p...@samsung.com> --- -- 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 v4l-utils 7/7 v7.1] Add a libv4l plugin for Exynos4 camera
The plugin provides support for the media device on Exynos4 SoC.
It performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
configure.ac |1 +
lib/Makefile.am |5 +
lib/libv4l-exynos4-camera/Makefile.am | 19 +
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 1335 +
4 files changed, 1360 insertions(+)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
diff --git a/configure.ac b/configure.ac
index 8447f05..692718a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+ lib/libv4l-exynos4-camera/Makefile
utils/Makefile
utils/libv4l2util/Makefile
diff --git a/lib/Makefile.am b/lib/Makefile.am
index a105c95..b5e52db 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -5,6 +5,11 @@ SUBDIRS = \
libv4l2rds \
libv4l-mplane
+if WITH_V4LUTILS
+SUBDIRS += \
+ libv4l-exynos4-camera
+endif
+
if WITH_LIBDVBV5
SUBDIRS += \
libdvbv5
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..c38b7f6
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,19 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+media-bus-format-names.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*FMT_//; /FIXED/ d; s/\t.*//;
s/.*/{ \"&\", MEDIA_BUS_FMT_& },/;' \
+ < $< > $@
+
+media-bus-format-codes.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*#define //; /FIXED/ d;
s/\t.*//; s/.*/ &,/;' \
+ < $< > $@
+
+BUILT_SOURCES = media-bus-format-names.h media-bus-format-codes.h
+CLEANFILES = $(BUILT_SOURCES)
+
+nodist_libv4l_exynos4_camera_la_SOURCES = $(BUILT_SOURCES)
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
../../utils/media-ctl/libmediactl.c ../../utils/media-ctl/libv4l2subdev.c
../../utils/media-ctl/mediatext.c
+libv4l_exynos4_camera_la_CFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
new file mode 100644
index 000..c2c4c6e
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
@@ -0,0 +1,1335 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski <j.anaszew...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../../utils/media-ctl/mediactl.h"
+#include "../../utils/media-ctl/mediatext.h"
+#include "../../utils/media-ctl/v4l2subdev.h"
+#include "libv4l-plugin.h"
+
+#define DEBUG
+#ifdef DEBUG
+#define V4L2_EXYNOS4_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_EXYNOS4_DBG(format, ARG...)
+#endif
+
+#define V4L2_EXYNOS4_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define V4L2_EXYNOS4_LOG(format, ARG...)\
+ fprintf(stdout, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define VIDIOC_CTRL(type) \
+ ((type) == VIDIOC_S_CTRL ? "VIDIOC_S_CTRL" :\
+ "VIDIOC_G_CTRL")
+
+#define VIDIOC_EXT_CTRL(type) \
+ ((type) == VIDIOC_S_EXT_CTRLS ? \
+ "VIDIOC_S_EXT_CTRLS": \
+ ((type) == VIDIOC_G_EXT_CTRLS ?\
+
[PATCH v4l-utils v7 1/7] mediactl: Add support for v4l2-ctrl-binding config
Make struct v4l2_subdev capable of aggregating v4l2-ctrl-bindings -
media device configuration entries. Added are also functions for
validating support for the control on given media entity and checking
whether a v4l2-ctrl-binding has been defined for a media entity.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libv4l2subdev.c | 32
utils/media-ctl/v4l2subdev.h| 19 +++
2 files changed, 51 insertions(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index c3439d7..4f8ee7f 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -50,7 +50,15 @@ int v4l2_subdev_create(struct media_entity *entity)
entity->sd->fd = -1;
+ entity->sd->v4l2_ctrl_bindings = malloc(sizeof(__u32));
+ if (entity->sd->v4l2_ctrl_bindings == NULL)
+ goto err_v4l2_ctrl_bindings_alloc;
+
return 0;
+
+err_v4l2_ctrl_bindings_alloc:
+ free(entity->sd);
+ return -ENOMEM;
}
int v4l2_subdev_create_opened(struct media_entity *entity, int fd)
@@ -102,6 +110,7 @@ void v4l2_subdev_close(struct media_entity *entity)
if (entity->sd->fd_owner)
close(entity->sd->fd);
+ free(entity->sd->v4l2_ctrl_bindings);
free(entity->sd);
}
@@ -884,3 +893,26 @@ const enum v4l2_mbus_pixelcode
*v4l2_subdev_pixelcode_list(unsigned int *length)
return mbus_codes;
}
+
+int v4l2_subdev_supports_v4l2_ctrl(struct media_device *media,
+ struct media_entity *entity,
+ __u32 ctrl_id)
+{
+ struct v4l2_queryctrl queryctrl = {};
+ int ret;
+
+ ret = v4l2_subdev_open(entity);
+ if (ret < 0)
+ return ret;
+
+ queryctrl.id = ctrl_id;
+
+ ret = ioctl(entity->sd->fd, VIDIOC_QUERYCTRL, );
+ if (ret < 0)
+ return ret;
+
+ media_dbg(media, "Validated control \"%s\" (0x%8.8x) on entity %s\n",
+ queryctrl.name, queryctrl.id, entity->info.name);
+
+ return 0;
+}
diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
index 011fab1..4dee6b1 100644
--- a/utils/media-ctl/v4l2subdev.h
+++ b/utils/media-ctl/v4l2subdev.h
@@ -26,10 +26,14 @@
struct media_device;
struct media_entity;
+struct media_device;
struct v4l2_subdev {
int fd;
unsigned int fd_owner:1;
+
+ __u32 *v4l2_ctrl_bindings;
+ unsigned int num_v4l2_ctrl_bindings;
};
/**
@@ -314,4 +318,19 @@ enum v4l2_field v4l2_subdev_string_to_field(const char
*string);
const enum v4l2_mbus_pixelcode *v4l2_subdev_pixelcode_list(
unsigned int *length);
+/**
+ * @brief Check if sub-device supports given v4l2 control
+ * @param media - media device.
+ * @param entity - media entity.
+ * @param ctrl_id - id of the v4l2 control to check.
+ *
+ * Verify if the sub-device associated with given media entity
+ * supports v4l2-control with given ctrl_id.
+ *
+ * @return 1 if the control is supported, 0 otherwise.
+ */
+int v4l2_subdev_supports_v4l2_ctrl(struct media_device *device,
+ struct media_entity *entity,
+ __u32 ctrl_id);
+
#endif
--
1.9.1
--
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 v4l-utils v7 0/7] Add a plugin for Exynos4 camera
This is a seventh version of the patch series adding a plugin for the Exynos4 camera. Last version [0] of the patch set was posted in January. The plugin doesn't link against libmediactl, but has its sources compiled in. Currently utils are built after the plugins, but libv4l-exynos4-camera plugin depends on the utils. In order to link the plugin against libmediactl the build system would have to be modified. Changes from v6: - close v4l2 sub-devices on media device release - moved non-generic code from libmediactl to the plugin - resigned from adding libmedia_ioctl library and moved all its code to the plugin, since it depended on pipeline representation, which was not generic for all possible media device topologies - used media_get_info()->name instead of adding media_entity_get_name - renamed media_get_backlinks_by_entity() to media_entity_get_backlinks(() - moved pipeline from struct media_device to the plugin - changed the way of associating video device file descriptor with media device - switched to using auto-generated media-bus-format-names.h header file - renamed v4l2-ctrl-redir config entry name to v4l2-ctrl-binding Changes from v5: - fixed and tested use cases with S5K6A3 sensor and FIMC-IS-ISP - added conversion "colorspace id to string" Changes from v4: - removed some redundant functions for traversing media device graph and switched over to using existing ones - avoided accessing struct v4l2_subdev from libmediactl - applied various improvements Changes from v3: - added struct v4l2_subdev and put entity fd and information about supported controls to it - improved functions for negotiating and setting pipeline format by using available libv4lsubdev API - applied minor improvements and cleanups Changes from v2: - switched to using mediatext library for parsing the media device configuration - extended libmediactl - switched to using libmediactl Changes from v1: - removed redundant mbus code negotiation - split the parser, media device helpers and ioctl wrappers to the separate modules - added mechanism for querying extended controls - applied various fixes and modifications The plugin was tested on v4.8-rc2 (exynos4-is driver doesn't proble properly with current master branch of linux-media.git) with patches fixing several issues for Exynos4 camera: [1], [2], [3]. The plugin expects a configuration file: /var/lib/libv4l/exynos4_capture_conf Exemplary configuration file for pipeline with sensor S5C73M3 (rear camera): == link-conf "s5p-mipi-csis.0":1 -> "FIMC.0":0 [1] v4l2-ctrl-binding 0x0098091f -> "fimc.0.capture" v4l2-ctrl-binding 0x00980902 -> "S5C73M3" v4l2-ctrl-binding 0x00980922 -> "fimc.0.capture" v4l2-ctrl-binding 0x009a0914 -> "S5C73M3" == With this settings the plugin can be tested on the exynos4412-trats2 board using following gstreamer pipeline: gst-launch-1.0 v4l2src device=/dev/video1 extra-controls="c,rotate=90,color_effects=2" ! video/x-raw,width=960,height=720 ! fbdevsink Exemplary configuration file for pipeline with sensor S5K6A3 (front camera): == link-conf "s5p-mipi-csis.1":1 -> "FIMC-LITE.1":0 [1] link-conf "FIMC-LITE.1":2 -> "FIMC-IS-ISP":0 [1] link-conf "FIMC-IS-ISP":1 -> "FIMC.0":1 [1] == gst-launch-1.0 v4l2src device=/dev/video1 extra-controls="c,rotate=270,color_effects=2,horizontal_flip=1" ! video/x-raw,width=960,height=920 ! fbdevsink Best Regards, Jacek Anaszewski [0] http://www.spinics.net/lists/linux-media/msg96510.html [1] https://patchwork.kernel.org/patch/9335197/ [2] https://patchwork.kernel.org/patch/9270985/ [3] https://patchwork.kernel.org/patch/9308923/ [4] https://patchwork.kernel.org/patch/9335273/ Jacek Anaszewski (7): mediactl: Add support for v4l2-ctrl-binding config mediatext: Add library mediactl: Add media_entity_get_backlinks() mediactl: Add media_device creation helpers mediactl: libv4l2subdev: Add colorspace logging mediactl: libv4l2subdev: add support for comparing mbus formats Add a libv4l plugin for Exynos4 camera configure.ac |1 + lib/Makefile.am |5 + lib/libv4l-exynos4-camera/Makefile.am | 19 + lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 1325 + utils/media-ctl/Makefile.am | 10 +- utils/media-ctl/libmediactl.c | 152 ++- utils/media-ctl/libmediatext.pc.in
[PATCH v4l-utils v7 3/7] mediactl: Add media_entity_get_backlinks()
Add a new graph helper useful for discovering video pipeline.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c | 21 +
utils/media-ctl/mediactl.h| 15 +++
2 files changed, 36 insertions(+)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 91ed003..155b65f 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -36,6 +36,7 @@
#include
#include
+#include
#include
#include "mediactl.h"
@@ -172,6 +173,26 @@ const struct media_entity_desc
*media_entity_get_info(struct media_entity *entit
return >info;
}
+int media_entity_get_backlinks(struct media_entity *entity,
+ struct media_link **backlinks,
+ unsigned int *num_backlinks)
+{
+ unsigned int num_bklinks = 0;
+ int i;
+
+ if (entity == NULL || backlinks == NULL || num_backlinks == NULL)
+ return -EINVAL;
+
+ for (i = 0; i < entity->num_links; ++i)
+ if ((entity->links[i].flags & MEDIA_LNK_FL_ENABLED) &&
+ (entity->links[i].sink->entity == entity))
+ backlinks[num_bklinks++] = >links[i];
+
+ *num_backlinks = num_bklinks;
+
+ return 0;
+}
+
/*
-
* Open/close
*/
diff --git a/utils/media-ctl/mediactl.h b/utils/media-ctl/mediactl.h
index 336cbf9..b1f33cd 100644
--- a/utils/media-ctl/mediactl.h
+++ b/utils/media-ctl/mediactl.h
@@ -434,6 +434,20 @@ int media_parse_setup_link(struct media_device *media,
int media_parse_setup_links(struct media_device *media, const char *p);
/**
+ * @brief Get entity's enabled backlinks
+ * @param entity - media entity.
+ * @param backlinks - array of pointers to matching backlinks.
+ * @param num_backlinks - number of matching backlinks.
+ *
+ * Get links that are connected to the entity sink pads.
+ *
+ * @return 0 on success, or a negative error code on failure.
+ */
+int media_entity_get_backlinks(struct media_entity *entity,
+ struct media_link **backlinks,
+ unsigned int *num_backlinks);
+
+/**
* @brief Get v4l2_subdev for the entity
* @param entity - media entity
*
@@ -443,4 +457,5 @@ int media_parse_setup_links(struct media_device *media,
const char *p);
*/
struct v4l2_subdev *media_entity_get_v4l2_subdev(struct media_entity *entity);
+
#endif
--
1.9.1
--
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 v4l-utils v7 4/7] mediactl: Add media_device creation helpers
Add helper functions that allow for easy instantiation of media_device
object basing on whether the media device contains v4l2 subdev with
given file descriptor.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c | 131 +-
utils/media-ctl/mediactl.h| 27 +
2 files changed, 156 insertions(+), 2 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 155b65f..d347a40 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -440,8 +441,9 @@ static int media_get_devname_udev(struct udev *udev,
return -EINVAL;
devnum = makedev(entity->info.v4l.major, entity->info.v4l.minor);
- media_dbg(entity->media, "looking up device: %u:%u\n",
- major(devnum), minor(devnum));
+ if (entity->media)
+ media_dbg(entity->media, "looking up device: %u:%u\n",
+ major(devnum), minor(devnum));
device = udev_device_new_from_devnum(udev, 'c', devnum);
if (device) {
p = udev_device_get_devnode(device);
@@ -523,6 +525,7 @@ static int media_get_devname_sysfs(struct media_entity
*entity)
return 0;
}
+
static int media_enum_entities(struct media_device *media)
{
struct media_entity *entity;
@@ -707,6 +710,92 @@ struct media_device *media_device_new(const char *devnode)
return media;
}
+struct media_device *media_device_new_by_subdev_fd(int fd, struct media_entity
**fd_entity)
+{
+ char video_devname[32], device_dir_path[256], media_dev_path[256],
media_major_minor[10];
+ struct media_device *media = NULL;
+ struct dirent *entry;
+ struct media_entity tmp_entity;
+ DIR *device_dir;
+ struct udev *udev;
+ char *p;
+ int ret, i;
+
+ if (fd_entity == NULL)
+ return NULL;
+
+ ret = media_get_devname_by_fd(fd, video_devname);
+ if (ret < 0)
+ return NULL;
+
+ p = strrchr(video_devname, '/');
+ if (p == NULL)
+ return NULL;
+
+ ret = media_udev_open();
+ if (ret < 0)
+ return NULL;
+
+ sprintf(device_dir_path, "/sys/class/video4linux/%s/device/", p + 1);
+
+ device_dir = opendir(device_dir_path);
+ if (device_dir == NULL)
+ return NULL;
+
+ while ((entry = readdir(device_dir))) {
+ if (strncmp(entry->d_name, "media", 4))
+ continue;
+
+ sprintf(media_dev_path, "%s%s/dev", device_dir_path,
entry->d_name);
+
+ fd = open(media_dev_path, O_RDONLY);
+ if (fd < 0)
+ continue;
+
+ ret = read(fd, media_major_minor, sizeof(media_major_minor));
+ if (ret < 0)
+ continue;
+
+ sscanf(media_major_minor, "%d:%d", _entity.info.dev.major,
_entity.info.dev.minor);
+
+ /* Try to get the device name via udev */
+ if (media_get_devname_udev(udev, _entity)) {
+ /* Fall back to get the device name via sysfs */
+ if (media_get_devname_sysfs(_entity))
+ continue;
+ }
+
+ media = media_device_new(tmp_entity.devname);
+ if (media == NULL)
+ continue;
+
+ ret = media_device_enumerate(media);
+ if (ret < 0) {
+ media_dbg(media, "Failed to enumerate %s (%d)\n",
+ tmp_entity.devname, ret);
+ media_device_unref(media);
+ media = NULL;
+ continue;
+ }
+
+ /* Get the entity associated with given fd */
+ for (i = 0; i < media->entities_count; i++) {
+ struct media_entity *entity = >entities[i];
+
+ if (!strcmp(entity->devname, video_devname)) {
+ *fd_entity = >entities[i];
+ break;
+ }
+ }
+
+ break;
+ }
+
+ media_udev_close(udev);
+
+ return media;
+}
+
struct media_device *media_device_new_emulated(struct media_device_info *info)
{
struct media_device *media;
@@ -748,6 +837,44 @@ void media_device_unref(struct media_device *media)
free(media);
}
+int media_get_devname_by_fd(int fd, char *node_name)
+{
+ struct udev *udev;
+ struct media_entity tmp_entity;
+ struct stat stat;
+
[PATCH v4l-utils v7 5/7] mediactl: libv4l2subdev: Add colorspace logging
Add a function for obtaining colorspace name by id.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libv4l2subdev.c | 32
utils/media-ctl/v4l2subdev.h| 10 ++
2 files changed, 42 insertions(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 4f8ee7f..31393bb 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include "mediactl.h"
#include "mediactl-priv.h"
@@ -831,6 +832,37 @@ const char *v4l2_subdev_pixelcode_to_string(enum
v4l2_mbus_pixelcode code)
return "unknown";
}
+static struct {
+ const char *name;
+ enum v4l2_colorspace cs;
+} colorspaces[] = {
+{ "DEFAULT", V4L2_COLORSPACE_DEFAULT },
+{ "SMPTE170M", V4L2_COLORSPACE_SMPTE170M },
+{ "SMPTE240M", V4L2_COLORSPACE_SMPTE240M },
+{ "REC709", V4L2_COLORSPACE_REC709 },
+{ "BT878", V4L2_COLORSPACE_BT878 },
+{ "470_SYSTEM_M", V4L2_COLORSPACE_470_SYSTEM_M },
+{ "470_SYSTEM_BG", V4L2_COLORSPACE_470_SYSTEM_BG },
+{ "JPEG", V4L2_COLORSPACE_JPEG },
+{ "SRGB", V4L2_COLORSPACE_SRGB },
+{ "ADOBERGB", V4L2_COLORSPACE_ADOBERGB },
+{ "BT2020", V4L2_COLORSPACE_BT2020 },
+{ "RAW", V4L2_COLORSPACE_RAW },
+{ "DCI_P3", V4L2_COLORSPACE_DCI_P3 },
+};
+
+const char *v4l2_subdev_colorspace_to_string(enum v4l2_colorspace cs)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(colorspaces); ++i) {
+ if (colorspaces[i].cs == cs)
+ return colorspaces[i].name;
+ }
+
+ return "unknown";
+}
+
enum v4l2_mbus_pixelcode v4l2_subdev_string_to_pixelcode(const char *string)
{
unsigned int i;
diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
index 4dee6b1..cf1250d 100644
--- a/utils/media-ctl/v4l2subdev.h
+++ b/utils/media-ctl/v4l2subdev.h
@@ -278,6 +278,16 @@ int v4l2_subdev_parse_setup_formats(struct media_device
*media, const char *p);
const char *v4l2_subdev_pixelcode_to_string(enum v4l2_mbus_pixelcode code);
/**
+ * @brief Convert colorspace to string.
+ * @param code - input string
+ *
+ * Convert colorspace @a to a human-readable string.
+ *
+ * @return A pointer to a string on success, NULL on failure.
+ */
+const char *v4l2_subdev_colorspace_to_string(enum v4l2_colorspace cs);
+
+/**
* @brief Parse string to media bus pixel code.
* @param string - nul terminalted string, textual media bus pixel code
*
--
1.9.1
--
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 v4l-utils v7 7/7] Add a libv4l plugin for Exynos4 camera
The plugin provides support for the media device on Exynos4 SoC.
It performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
configure.ac |1 +
lib/Makefile.am |5 +
lib/libv4l-exynos4-camera/Makefile.am | 19 +
lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c | 1325 +
4 files changed, 1350 insertions(+)
create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
diff --git a/configure.ac b/configure.ac
index 8447f05..692718a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_CONFIG_FILES([Makefile
lib/libdvbv5/Makefile
lib/libv4l2rds/Makefile
lib/libv4l-mplane/Makefile
+ lib/libv4l-exynos4-camera/Makefile
utils/Makefile
utils/libv4l2util/Makefile
diff --git a/lib/Makefile.am b/lib/Makefile.am
index a105c95..b5e52db 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -5,6 +5,11 @@ SUBDIRS = \
libv4l2rds \
libv4l-mplane
+if WITH_V4LUTILS
+SUBDIRS += \
+ libv4l-exynos4-camera
+endif
+
if WITH_LIBDVBV5
SUBDIRS += \
libdvbv5
diff --git a/lib/libv4l-exynos4-camera/Makefile.am
b/lib/libv4l-exynos4-camera/Makefile.am
new file mode 100644
index 000..c38b7f6
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/Makefile.am
@@ -0,0 +1,19 @@
+if WITH_V4L_PLUGINS
+libv4l2plugin_LTLIBRARIES = libv4l-exynos4-camera.la
+endif
+
+media-bus-format-names.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*FMT_//; /FIXED/ d; s/\t.*//;
s/.*/{ \"&\", MEDIA_BUS_FMT_& },/;' \
+ < $< > $@
+
+media-bus-format-codes.h: ../../include/linux/media-bus-format.h
+ sed -e '/#define MEDIA_BUS_FMT/ ! d; s/.*#define //; /FIXED/ d;
s/\t.*//; s/.*/ &,/;' \
+ < $< > $@
+
+BUILT_SOURCES = media-bus-format-names.h media-bus-format-codes.h
+CLEANFILES = $(BUILT_SOURCES)
+
+nodist_libv4l_exynos4_camera_la_SOURCES = $(BUILT_SOURCES)
+libv4l_exynos4_camera_la_SOURCES = libv4l-exynos4-camera.c
../../utils/media-ctl/libmediactl.c ../../utils/media-ctl/libv4l2subdev.c
../../utils/media-ctl/mediatext.c
+libv4l_exynos4_camera_la_CFLAGS = -fvisibility=hidden -std=gnu99
+libv4l_exynos4_camera_la_LDFLAGS = -avoid-version -module -shared
-export-dynamic -lpthread
diff --git a/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
new file mode 100644
index 000..c219fe5
--- /dev/null
+++ b/lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c
@@ -0,0 +1,1325 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Jacek Anaszewski <j.anaszew...@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../../utils/media-ctl/mediactl.h"
+#include "../../utils/media-ctl/mediatext.h"
+#include "../../utils/media-ctl/v4l2subdev.h"
+#include "libv4l-plugin.h"
+
+#ifdef DEBUG
+#define V4L2_EXYNOS4_DBG(format, ARG...)\
+ printf("[%s:%d] [%s] " format " \n", __FILE__, __LINE__, __func__,
##ARG)
+#else
+#define V4L2_EXYNOS4_DBG(format, ARG...)
+#endif
+
+#define V4L2_EXYNOS4_ERR(format, ARG...)\
+ fprintf(stderr, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define V4L2_EXYNOS4_LOG(format, ARG...)\
+ fprintf(stdout, "Libv4l Exynos4 camera plugin: "format "\n", ##ARG)
+
+#define VIDIOC_CTRL(type) \
+ ((type) == VIDIOC_S_CTRL ? "VIDIOC_S_CTRL" :\
+ "VIDIOC_G_CTRL")
+
+#if HAVE_VISIBILITY
+#define PLUGIN_PUBLIC __attribute__ ((visibility("default")))
+#else
+#define PLUGIN_PUBLIC
+#endif
+
+#define SYS_IOCTL(fd, cmd, arg) \
+ syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg))
+
+#define SIMPLE_CONVERT_IOCTL(fd, cmd, arg, __struc) ({
[PATCH v4l-utils v7 2/7] mediatext: Add library
libmediatext is a helper library for converting configurations (Media
controller links, V4L2 controls and V4L2 sub-device media bus formats and
selections) from text-based form into IOCTLs.
libmediatext depends on libv4l2subdev and libmediactl.
Signed-off-by: Sakari Ailus <sakari.ai...@linux.intel.com>
Signed-off-by: Teemu Tuominen <teemu.tuomi...@intel.com>
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
---
utils/media-ctl/Makefile.am| 10 +-
utils/media-ctl/libmediatext.pc.in | 10 ++
utils/media-ctl/mediatext-test.c | 64
utils/media-ctl/mediatext.c| 312 +
utils/media-ctl/mediatext.h| 52 +++
5 files changed, 446 insertions(+), 2 deletions(-)
create mode 100644 utils/media-ctl/libmediatext.pc.in
create mode 100644 utils/media-ctl/mediatext-test.c
create mode 100644 utils/media-ctl/mediatext.c
create mode 100644 utils/media-ctl/mediatext.h
diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am
index ee7dcc9..2f12357 100644
--- a/utils/media-ctl/Makefile.am
+++ b/utils/media-ctl/Makefile.am
@@ -1,4 +1,4 @@
-noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la
+noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la
libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h
libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
@@ -21,9 +21,15 @@ libv4l2subdev_la_LIBADD = libmediactl.la
libv4l2subdev_la_CFLAGS = -static
libv4l2subdev_la_LDFLAGS = -static
+libmediatext_la_SOURCES = mediatext.c
+libmediatext_la_CFLAGS = -static $(LIBUDEV_CFLAGS)
+libmediatext_la_LDFLAGS = -static $(LIBUDEV_LIBS)
+
mediactl_includedir=$(includedir)/mediactl
noinst_HEADERS = mediactl.h v4l2subdev.h
-bin_PROGRAMS = media-ctl
+bin_PROGRAMS = media-ctl mediatext-test
media_ctl_SOURCES = media-ctl.c options.c options.h tools.h
media_ctl_LDADD = libmediactl.la libv4l2subdev.la
+mediatext_test_SOURCES = mediatext-test.c
+mediatext_test_LDADD = libmediatext.la libmediactl.la libv4l2subdev.la
diff --git a/utils/media-ctl/libmediatext.pc.in
b/utils/media-ctl/libmediatext.pc.in
new file mode 100644
index 000..6aa6353
--- /dev/null
+++ b/utils/media-ctl/libmediatext.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libmediatext
+Description: Media controller and V4L2 text-based configuration library
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
+Libs: -L${libdir} -lmediatext
diff --git a/utils/media-ctl/mediatext-test.c b/utils/media-ctl/mediatext-test.c
new file mode 100644
index 000..b8b9282
--- /dev/null
+++ b/utils/media-ctl/mediatext-test.c
@@ -0,0 +1,64 @@
+/*
+ * libmediatext test program
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Contact: Sakari Ailus <sakari.ai...@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+#include
+
+#include "mediactl.h"
+#include "mediatext.h"
+
+int main(int argc, char *argv[])
+{
+ struct media_device *device;
+ int rval;
+
+ if (argc != 3) {
+ fprintf(stderr, "usage: %s \n\n",
argv[0]);
+ fprintf(stderr, "\tstring := [ v4l2-ctrl |�v4l2-mbus |
link-reset | link-conf]\n\n");
+ fprintf(stderr, "\tv4l2-ctrl := \"entity\" ctrl_type ctrl_id
ctrl_value\n");
+ fprintf(stderr, "\tctrl_type := [ int | int64 | bitmask ]\n");
+ fprintf(stderr, "\tctrl_value := [ %%d | %%PRId64 |
bitmask_value ]\n");
+ fprintf(stderr, "\tbitmask_value := b\n\n");
+ fprintf(stderr, "\tv4l2-mbus := \n");
+ fprintf(stderr, "\tlink-conf := \"entity\":pad ->
\"entity\":pad[link-flags]\n");
+ fprintf(stderr, "\tv4l2-ctrl-binding := ctrl_id ->
\"entity\"\n");
+ return EXIT_FAILURE;
+ }
+
+ device = media_device_new(argv[1]);
+ if (!device)
+ return EXIT_FAILURE;
+
+ rval = media_device_enumerate(device);
+ if (rval)
+ return EXIT_FAILURE;
+
+ rval = mediatext_parse(device, argv[2]);
+ if (rval) {
+ fprintf(std
[PATCH v4l-utils v7 6/7] mediactl: libv4l2subdev: add support for comparing mbus formats
This patch adds a function for checking whether two mbus formats
are compatible.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libv4l2subdev.c | 42 +
utils/media-ctl/v4l2subdev.h| 21 +
2 files changed, 63 insertions(+)
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 31393bb..2ec9b5e 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -948,3 +948,45 @@ int v4l2_subdev_supports_v4l2_ctrl(struct media_device
*media,
return 0;
}
+
+enum v4l2_subdev_fmt_mismatch v4l2_subdev_format_compare(
+ struct v4l2_mbus_framefmt *fmt1,
+ struct v4l2_mbus_framefmt *fmt2)
+{
+ if (fmt1 == NULL || fmt2 == NULL)
+ return 0;
+
+ if (fmt1->width != fmt2->width) {
+ printf("width mismatch (fmt1: %d, fmt2: %d)\n",
+ fmt1->width, fmt2->width);
+ return FMT_MISMATCH_WIDTH;
+ }
+
+ if (fmt1->height != fmt2->height) {
+ printf("height mismatch (fmt1: %d, fmt2: %d)\n",
+ fmt1->height, fmt2->height);
+ return FMT_MISMATCH_HEIGHT;
+ }
+
+ if (fmt1->code != fmt2->code) {
+ printf("mbus code mismatch (fmt1: %s, fmt2: %s)\n",
+ v4l2_subdev_pixelcode_to_string(fmt1->code),
+ v4l2_subdev_pixelcode_to_string(fmt2->code));
+ return FMT_MISMATCH_CODE;
+ }
+
+ if (fmt1->field != fmt2->field) {
+ printf("field mismatch (fmt1: %d, fmt2: %d)\n",
+ fmt1->field, fmt2->field);
+ return FMT_MISMATCH_FIELD;
+ }
+
+ if (fmt1->colorspace != fmt2->colorspace) {
+ printf("colorspace mismatch (fmt1: %s, fmt2: %s)\n",
+ v4l2_subdev_colorspace_to_string(fmt1->colorspace),
+ v4l2_subdev_colorspace_to_string(fmt2->colorspace));
+ return FMT_MISMATCH_COLORSPACE;
+ }
+
+ return FMT_MISMATCH_NONE;
+}
diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
index cf1250d..c438f71 100644
--- a/utils/media-ctl/v4l2subdev.h
+++ b/utils/media-ctl/v4l2subdev.h
@@ -28,6 +28,15 @@ struct media_device;
struct media_entity;
struct media_device;
+enum v4l2_subdev_fmt_mismatch {
+ FMT_MISMATCH_NONE = 0,
+ FMT_MISMATCH_WIDTH,
+ FMT_MISMATCH_HEIGHT,
+ FMT_MISMATCH_CODE,
+ FMT_MISMATCH_FIELD,
+ FMT_MISMATCH_COLORSPACE,
+};
+
struct v4l2_subdev {
int fd;
unsigned int fd_owner:1;
@@ -342,5 +351,17 @@ const enum v4l2_mbus_pixelcode *v4l2_subdev_pixelcode_list(
int v4l2_subdev_supports_v4l2_ctrl(struct media_device *device,
struct media_entity *entity,
__u32 ctrl_id);
+/**
+ * @brief Compare mbus formats
+ * @param fmt1 - 1st mbus format to compare.
+ * @param fmt2 - 2nd mbus format to compare.
+ *
+ * Check whether two mbus formats are compatible.
+ *
+ * @return 1 if formats are compatible, 0 otherwise.
+ */
+enum v4l2_subdev_fmt_mismatch v4l2_subdev_format_compare(
+ struct v4l2_mbus_framefmt *fmt1,
+ struct v4l2_mbus_framefmt *fmt2);
#endif
--
1.9.1
--
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] [media] platform: constify vb2_ops structures
Hi Julia,
On 09/09/2016 01:59 AM, Julia Lawall wrote:
Check for vb2_ops structures that are only stored in the ops field of a
vb2_queue structure. That field is declared const, so vb2_ops structures
that have this property can be declared as const also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
[...]
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 785e693..d9c07b8 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2538,7 +2538,7 @@ static void s5p_jpeg_stop_streaming(struct vb2_queue *q)
pm_runtime_put(ctx->jpeg->dev);
}
-static struct vb2_ops s5p_jpeg_qops = {
+static const struct vb2_ops s5p_jpeg_qops = {
.queue_setup= s5p_jpeg_queue_setup,
.buf_prepare= s5p_jpeg_buf_prepare,
.buf_queue = s5p_jpeg_buf_queue,
diff --git a/drivers/media/platform/ti-vpe/cal.c
b/drivers/media/platform/ti-vpe/cal.c
index e967fcf..44323cb 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1379,7 +1379,7 @@ static void cal_stop_streaming(struct vb2_queue *vq)
cal_runtime_put(ctx->dev);
}
Thanks for the patch.
For s5p-jpeg driver:
Reviewed-by: Jacek Anaszewski <j.anaszew...@samsung.com>
--
Best regards,
Jacek Anaszewski
--
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] media: s5p-jpeg add missing blank lines after declarations
Hi Shuah,
Thanks for the patch.
On 07/14/2016 10:01 PM, Shuah Khan wrote:
Missing blank lines after declarations are making it hard to read the
code. Fix them and also fix other checkpatch warnings at the same time.
Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 17bc94092..fe5554f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -537,6 +537,7 @@ static const u32 fourcc_to_dwngrd_schema_id[] = {
static int s5p_jpeg_get_dwngrd_sch_id_by_fourcc(u32 fourcc)
{
int i;
+
for (i = 0; i < ARRAY_SIZE(fourcc_to_dwngrd_schema_id); ++i) {
if (fourcc_to_dwngrd_schema_id[i] == fourcc)
return i;
@@ -1273,7 +1274,8 @@ static int enum_fmt(struct s5p_jpeg_fmt *sjpeg_formats,
int n,
if (num == f->index)
break;
/* Correct type but haven't reached our index yet,
-* just increment per-type index */
+* just increment per-type index
+ */
++num;
}
}
@@ -1349,6 +1351,7 @@ static int s5p_jpeg_g_fmt(struct file *file, void *priv,
struct v4l2_format *f)
pix->bytesperline = 0;
if (q_data->fmt->fourcc != V4L2_PIX_FMT_JPEG) {
u32 bpl = q_data->w;
+
if (q_data->fmt->colplanes == 1)
bpl = (bpl * q_data->fmt->depth) >> 3;
pix->bytesperline = bpl;
@@ -1374,6 +1377,7 @@ static struct s5p_jpeg_fmt *s5p_jpeg_find_format(struct
s5p_jpeg_ctx *ctx,
for (k = 0; k < ARRAY_SIZE(sjpeg_formats); k++) {
struct s5p_jpeg_fmt *fmt = _formats[k];
+
if (fmt->fourcc == pixelformat &&
fmt->flags & fmt_flag &&
fmt->flags & ctx->jpeg->variant->fmt_ver_flag) {
@@ -1431,7 +1435,8 @@ static int vidioc_try_fmt(struct v4l2_format *f, struct
s5p_jpeg_fmt *fmt,
return -EINVAL;
/* V4L2 specification suggests the driver corrects the format struct
-* if any of the dimensions is unsupported */
+* if any of the dimensions is unsupported
+ */
if (q_type == FMT_TYPE_OUTPUT)
jpeg_bound_align_image(ctx, >width, S5P_JPEG_MIN_WIDTH,
S5P_JPEG_MAX_WIDTH, 0,
@@ -2490,6 +2495,7 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
if (ctx->mode == S5P_JPEG_DECODE &&
vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
struct s5p_jpeg_q_data tmp, *q_data;
+
ctx->hdr_parsed = s5p_jpeg_parse_hdr(,
(unsigned long)vb2_plane_vaddr(vb, 0),
min((unsigned long)ctx->out_q.size,
@@ -3025,7 +3031,8 @@ static int s5p_jpeg_resume(struct device *dev)
static const struct dev_pm_ops s5p_jpeg_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(s5p_jpeg_suspend, s5p_jpeg_resume)
- SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume,
NULL)
+ SET_RUNTIME_PM_OPS(s5p_jpeg_runtime_suspend, s5p_jpeg_runtime_resume,
+ NULL)
};
static struct s5p_jpeg_variant s5p_jpeg_drvdata = {
Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com>
--
Best regards,
Jacek Anaszewski
--
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] leds: Add no-op gpio_led_register_device when LED subsystem is disabled
On 06/21/2016 01:48 PM, Andrew F. Davis wrote:
On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <a...@ti.com>
---
include/linux/leds.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
unsigned long *delay_off);
Currently there is some stuff here, and in fact it has been for
a long time.
Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?
v4.7-rc4, it may not apply due to the surrounding lines being changed in
the other patches which may not be applied to your tree. It is a single
line change per patch so hopefully the merge conflict resolutions will
be trivial.
A better solution could have been getting an ack from each maintainer
and having someone pull the whole series into one tree, but parts have
already been picked so it may be a little late for that.
OK, I resolved the issues and applied, thanks.
};
+#ifdef CONFIG_NEW_LEDS
struct platform_device *gpio_led_register_device(
int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+ int id, const struct gpio_led_platform_data *pdata)
+{
+ return 0;
+}
+#endif
enum cpu_led_event {
CPU_LED_IDLE_START, /* CPU enters idle */
--
Best regards,
Jacek Anaszewski
--
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] leds: Add no-op gpio_led_register_device when LED subsystem is disabled
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
Some systems use 'gpio_led_register_device' to make an in-memory copy of
their LED device table so the original can be removed as .init.rodata.
When the LED subsystem is not enabled source in the led directory is not
built and so this function may be undefined. Fix this here.
Signed-off-by: Andrew F. Davis <a...@ti.com>
---
include/linux/leds.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d2b1306..a4a3da6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -386,8 +386,16 @@ struct gpio_led_platform_data {
unsigned long *delay_off);
Currently there is some stuff here, and in fact it has been for
a long time.
Patch "[PATCH 12/12] leds: Only descend into leds directory when
CONFIG_NEW_LEDS is set" also doesn't apply.
What repository are you using?
};
+#ifdef CONFIG_NEW_LEDS
struct platform_device *gpio_led_register_device(
int id, const struct gpio_led_platform_data *pdata);
+#else
+static inline struct platform_device *gpio_led_register_device(
+ int id, const struct gpio_led_platform_data *pdata)
+{
+ return 0;
+}
+#endif
enum cpu_led_event {
CPU_LED_IDLE_START, /* CPU enters idle */
--
Best regards,
Jacek Anaszewski
--
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 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set
On 06/18/2016 12:46 AM, Andrew F. Davis wrote: On 06/15/2016 01:48 AM, Jacek Anaszewski wrote: Hi Andrew, Thanks for the patch. Please address the issue [1] raised by test bot and resubmit. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2016/6/13/1091 It looks like some systems use 'gpio_led_register_device' to make an in-memory copy of their LED device table so the original can be removed as .init.rodata. This doesn't necessarily depend on the LED subsystem but it kind of seems useless when the rest of the subsystem is disabled. One solution could be to use a dummy 'gpio_led_register_device' when the subsystem is not enabled. It sounds good. Please add a no-op version of gpio_led_register_device() to include/leds.h, in a separate patch. Thanks, Jacek Anaszewski Another is just to remove the five or so uses of 'gpio_led_register_device' and have those systems register LED device tables like other systems do. If nether of these are acceptable then this patch can be dropped from this series for now. Thanks, Andrew On 06/13/2016 10:02 PM, Andrew F. Davis wrote: When CONFIG_NEW_LEDS is not set make will still descend into the leds directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis <a...@ti.com> --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 567e32c..fa514d5 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -127,7 +127,7 @@ obj-$(CONFIG_CPU_FREQ)+= cpufreq/ obj-$(CONFIG_CPU_IDLE)+= cpuidle/ obj-$(CONFIG_MMC)+= mmc/ obj-$(CONFIG_MEMSTICK)+= memstick/ -obj-y+= leds/ +obj-$(CONFIG_NEW_LEDS)+= leds/ obj-$(CONFIG_INFINIBAND)+= infiniband/ obj-$(CONFIG_SGI_SN)+= sn/ obj-y+= firmware/ -- 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 3/6] [media] s5p-jpeg: set capablity bus_info as required by VIDIOC_QUERYCAP
Hi Javier, On 06/16/2016 11:40 PM, Javier Martinez Canillas wrote: The driver doesn't set the struct v4l2_capability cap_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail: v4l2-compliance.cpp(528): check_ustring(vcap.bus_info, sizeof(vcap.bus_info)) test VIDIOC_QUERYCAP: FAIL This patch fixes by setting the field in VIDIOC_QUERYCAP ioctl handler: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) test VIDIOC_QUERYCAP: OK Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c index 17bc94092864..e3ff3d4bd72e 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c @@ -1256,7 +1256,8 @@ static int s5p_jpeg_querycap(struct file *file, void *priv, strlcpy(cap->card, S5P_JPEG_M2M_NAME " decoder", sizeof(cap->card)); } - cap->bus_info[0] = 0; + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", +dev_name(ctx->jpeg->dev)); cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M; cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; return 0; Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com> -- Best regards, Jacek Anaszewski -- 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 4/6] [media] s5p-jpeg: only fill driver's name in capabilities driver field
Hi Javier,
On 06/16/2016 11:40 PM, Javier Martinez Canillas wrote:
The driver fills in both the struct v4l2_capability driver and card fields
the same values, that is the driver's name plus the information if the dev
is a decoder or an encoder.
But the driver field has a fixed length of 16 bytes so the filled data is
truncated:
Driver Info (not using libv4l2):
Driver name : s5p-jpeg decode
Card type : s5p-jpeg decoder
Bus info : platform:11f5.jpeg
Driver version: 4.7.0
Also, this field should only contain the driver's name so use just that.
The information if the device is a decoder or an encoder is in the card
type field anyways.
Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index e3ff3d4bd72e..f9fb52a53e79 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1246,12 +1246,12 @@ static int s5p_jpeg_querycap(struct file *file, void
*priv,
struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv);
if (ctx->mode == S5P_JPEG_ENCODE) {
- strlcpy(cap->driver, S5P_JPEG_M2M_NAME " encoder",
+ strlcpy(cap->driver, S5P_JPEG_M2M_NAME,
sizeof(cap->driver));
strlcpy(cap->card, S5P_JPEG_M2M_NAME " encoder",
sizeof(cap->card));
} else {
- strlcpy(cap->driver, S5P_JPEG_M2M_NAME " decoder",
+ strlcpy(cap->driver, S5P_JPEG_M2M_NAME,
sizeof(cap->driver));
strlcpy(cap->card, S5P_JPEG_M2M_NAME " decoder",
sizeof(cap->card));
Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com>
--
Best regards,
Jacek Anaszewski
--
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 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set
Hi Andrew, Thanks for the patch. Please address the issue [1] raised by test bot and resubmit. Thanks, Jacek Anaszewski [1] https://lkml.org/lkml/2016/6/13/1091 On 06/13/2016 10:02 PM, Andrew F. Davis wrote: When CONFIG_NEW_LEDS is not set make will still descend into the leds directory but nothing will be built. This produces unneeded build artifacts and messages in addition to slowing the build. Fix this here. Signed-off-by: Andrew F. Davis <a...@ti.com> --- drivers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 567e32c..fa514d5 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -127,7 +127,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq/ obj-$(CONFIG_CPU_IDLE)+= cpuidle/ obj-$(CONFIG_MMC) += mmc/ obj-$(CONFIG_MEMSTICK)+= memstick/ -obj-y += leds/ +obj-$(CONFIG_NEW_LEDS) += leds/ obj-$(CONFIG_INFINIBAND) += infiniband/ obj-$(CONFIG_SGI_SN) += sn/ obj-y += firmware/ -- Best regards, Jacek Anaszewski -- 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 13/15] mediactl: Add media device ioctl API
On 03/23/2016 05:24 PM, Sakari Ailus wrote: Hi Jacek, On Tue, Mar 22, 2016 at 10:36:05AM +0100, Jacek Anaszewski wrote: Hi Sakari, On 03/21/2016 01:07 AM, Sakari Ailus wrote: Hi Jacek, On Thu, Feb 18, 2016 at 02:14:40PM +0100, Jacek Anaszewski wrote: Hi Sakari, On 02/18/2016 01:09 PM, Sakari Ailus wrote: Hi Jacek, On Mon, Feb 15, 2016 at 02:06:06PM +0100, Jacek Anaszewski wrote: Hi Sakari, Thanks for the review. On 02/15/2016 01:41 PM, Sakari Ailus wrote: Hi Jacek, Jacek Anaszewski wrote: Ioctls executed on complex media devices need special handling. For instance some ioctls need to be targeted for specific sub-devices, depending on the media device configuration. The APIs being introduced address such requirements. Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com> Acked-by: Kyungmin Park <kyungmin.p...@samsung.com> --- utils/media-ctl/Makefile.am |2 +- utils/media-ctl/libv4l2media_ioctl.c | 404 ++ utils/media-ctl/libv4l2media_ioctl.h | 48 3 files changed, 453 insertions(+), 1 deletion(-) create mode 100644 utils/media-ctl/libv4l2media_ioctl.c create mode 100644 utils/media-ctl/libv4l2media_ioctl.h diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am index 3e883e0..7f18624 100644 --- a/utils/media-ctl/Makefile.am +++ b/utils/media-ctl/Makefile.am @@ -1,6 +1,6 @@ noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la -libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h +libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h libv4l2media_ioctl.c libv4l2media_ioctl.h libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS) libmediactl_la_LDFLAGS = -static $(LIBUDEV_LIBS) diff --git a/utils/media-ctl/libv4l2media_ioctl.c b/utils/media-ctl/libv4l2media_ioctl.c new file mode 100644 index 000..b186121 --- /dev/null +++ b/utils/media-ctl/libv4l2media_ioctl.c @@ -0,0 +1,404 @@ +/* + * Copyright (c) 2015 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Jacek Anaszewski <j.anaszew...@samsung.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + */ + +#include +#include +#include +#include + +#include + +#include "libv4l2media_ioctl.h" +#include "mediactl-priv.h" +#include "mediactl.h" +#include "v4l2subdev.h" + +#define VIDIOC_CTRL(type) \ + ((type) == VIDIOC_S_CTRL ? "VIDIOC_S_CTRL" : \ + "VIDIOC_G_CTRL") + +#define VIDIOC_EXT_CTRL(type) \ + ((type) == VIDIOC_S_EXT_CTRLS ? \ + "VIDIOC_S_EXT_CTRLS" : \ +((type) == VIDIOC_G_EXT_CTRLS ?\ + "VIDIOC_G_EXT_CTRLS" :\ + "VIDIOC_TRY_EXT_CTRLS")) + +#define SYS_IOCTL(fd, cmd, arg) \ + syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg)) + + +int media_ioctl_ctrl(struct media_device *media, int request, unsigned int request OK. +struct v4l2_control *arg) I wonder if it'd make sense to always use v4l2_ext_control instead. You can't access 64-bit integer controls with VIDIOC_S_CTRL for instance. This function is meant to handle VIDIOC_S_CTRL/VIDIOC_G_CTRL ioctls. For ext ctrls there is media_ioctl_ext_ctrl(). Is there any reason not to use extended control always? In other words, do we have a driver that does support Media controller but does not support extended controls? Shouldn't we support non-extended controls for backward compatibility reasons? I am not aware of the policy in this matter. To put it bluntly, supporting the non-extended controls in this use is waste of time IMHO. OK, I'll drop the non-ext controls related API then. As this is a user space library, I'd probably add a function to handle S/G/TRY control each. There is media_ioctl_ext_ctrl() that handles VIDIOC_S_EXT_CTRLS, VIDIOC_G_EXT_CTRLS and VIDIOC_TRY_EXT_CTRLS. Have you considered binding the control to a video node rather than a media device? We have many sensors on current media devices already, and e.g. exposure time control can be found in multiple sub-devices. Doesn't v4l2-ctrl-redir config entry address that? How does it work if you have, say, two video nodes where you can capture image
Re: [PATCH 13/15] mediactl: Add media device ioctl API
Hi Sakari, On 03/21/2016 01:07 AM, Sakari Ailus wrote: Hi Jacek, On Thu, Feb 18, 2016 at 02:14:40PM +0100, Jacek Anaszewski wrote: Hi Sakari, On 02/18/2016 01:09 PM, Sakari Ailus wrote: Hi Jacek, On Mon, Feb 15, 2016 at 02:06:06PM +0100, Jacek Anaszewski wrote: Hi Sakari, Thanks for the review. On 02/15/2016 01:41 PM, Sakari Ailus wrote: Hi Jacek, Jacek Anaszewski wrote: Ioctls executed on complex media devices need special handling. For instance some ioctls need to be targeted for specific sub-devices, depending on the media device configuration. The APIs being introduced address such requirements. Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com> Acked-by: Kyungmin Park <kyungmin.p...@samsung.com> --- utils/media-ctl/Makefile.am |2 +- utils/media-ctl/libv4l2media_ioctl.c | 404 ++ utils/media-ctl/libv4l2media_ioctl.h | 48 3 files changed, 453 insertions(+), 1 deletion(-) create mode 100644 utils/media-ctl/libv4l2media_ioctl.c create mode 100644 utils/media-ctl/libv4l2media_ioctl.h diff --git a/utils/media-ctl/Makefile.am b/utils/media-ctl/Makefile.am index 3e883e0..7f18624 100644 --- a/utils/media-ctl/Makefile.am +++ b/utils/media-ctl/Makefile.am @@ -1,6 +1,6 @@ noinst_LTLIBRARIES = libmediactl.la libv4l2subdev.la libmediatext.la -libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h +libmediactl_la_SOURCES = libmediactl.c mediactl-priv.h libv4l2media_ioctl.c libv4l2media_ioctl.h libmediactl_la_CFLAGS = -static $(LIBUDEV_CFLAGS) libmediactl_la_LDFLAGS = -static $(LIBUDEV_LIBS) diff --git a/utils/media-ctl/libv4l2media_ioctl.c b/utils/media-ctl/libv4l2media_ioctl.c new file mode 100644 index 000..b186121 --- /dev/null +++ b/utils/media-ctl/libv4l2media_ioctl.c @@ -0,0 +1,404 @@ +/* + * Copyright (c) 2015 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Jacek Anaszewski <j.anaszew...@samsung.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + */ + +#include +#include +#include +#include + +#include + +#include "libv4l2media_ioctl.h" +#include "mediactl-priv.h" +#include "mediactl.h" +#include "v4l2subdev.h" + +#define VIDIOC_CTRL(type) \ + ((type) == VIDIOC_S_CTRL ? "VIDIOC_S_CTRL" : \ + "VIDIOC_G_CTRL") + +#define VIDIOC_EXT_CTRL(type) \ + ((type) == VIDIOC_S_EXT_CTRLS ? \ + "VIDIOC_S_EXT_CTRLS" : \ +((type) == VIDIOC_G_EXT_CTRLS ?\ + "VIDIOC_G_EXT_CTRLS" :\ + "VIDIOC_TRY_EXT_CTRLS")) + +#define SYS_IOCTL(fd, cmd, arg) \ + syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg)) + + +int media_ioctl_ctrl(struct media_device *media, int request, unsigned int request OK. +struct v4l2_control *arg) I wonder if it'd make sense to always use v4l2_ext_control instead. You can't access 64-bit integer controls with VIDIOC_S_CTRL for instance. This function is meant to handle VIDIOC_S_CTRL/VIDIOC_G_CTRL ioctls. For ext ctrls there is media_ioctl_ext_ctrl(). Is there any reason not to use extended control always? In other words, do we have a driver that does support Media controller but does not support extended controls? Shouldn't we support non-extended controls for backward compatibility reasons? I am not aware of the policy in this matter. To put it bluntly, supporting the non-extended controls in this use is waste of time IMHO. OK, I'll drop the non-ext controls related API then. As this is a user space library, I'd probably add a function to handle S/G/TRY control each. There is media_ioctl_ext_ctrl() that handles VIDIOC_S_EXT_CTRLS, VIDIOC_G_EXT_CTRLS and VIDIOC_TRY_EXT_CTRLS. Have you considered binding the control to a video node rather than a media device? We have many sensors on current media devices already, and e.g. exposure time control can be found in multiple sub-devices. Doesn't v4l2-ctrl-redir config entry address that? How does it work if you have, say, two video nodes where you can capture images from a different sensor? I.e. your media graph could look like this: sensor0 -> CSI-2 0 -> video0 sen
Re: [PATCH 01/15] mediactl: Introduce v4l2_subdev structure
Hi Sakari,
On 03/21/2016 12:39 AM, Sakari Ailus wrote:
Hi Jacek,
On Thu, Feb 18, 2016 at 03:15:32PM +0100, Jacek Anaszewski wrote:
Hi Sakari,
Thanks for the review.
On 02/12/2016 01:42 PM, Sakari Ailus wrote:
Hi Jacek,
Thanks for continuing this work! And my apologies for reviewing only
now... please see the comments below.
Jacek Anaszewski wrote:
Add struct v4l2_subdev - a representation of the v4l2 sub-device,
related to the media entity. Add field 'sd', the pointer to
the newly introduced structure, to the struct media_entity
and move 'fd' property from struct media entity to struct v4l2_subdev.
Avoid accessing sub-device file descriptor from libmediactl and
make the v4l2_subdev_open capable of creating the v4l2_subdev
if the 'sd' pointer is uninitialized.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
---
utils/media-ctl/libmediactl.c |4 --
utils/media-ctl/libv4l2subdev.c | 82 +++
utils/media-ctl/mediactl-priv.h |5 ++-
utils/media-ctl/v4l2subdev.h| 38 ++
4 files changed, 107 insertions(+), 22 deletions(-)
diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
index 4a82d24..7e98440 100644
--- a/utils/media-ctl/libmediactl.c
+++ b/utils/media-ctl/libmediactl.c
@@ -525,7 +525,6 @@ static int media_enum_entities(struct media_device *media)
entity = >entities[media->entities_count];
memset(entity, 0, sizeof(*entity));
- entity->fd = -1;
entity->info.id = id | MEDIA_ENT_ID_FLAG_NEXT;
entity->media = media;
@@ -719,8 +718,6 @@ void media_device_unref(struct media_device *media)
free(entity->pads);
free(entity->links);
- if (entity->fd != -1)
- close(entity->fd);
}
free(media->entities);
@@ -747,7 +744,6 @@ int media_device_add_entity(struct media_device *media,
entity = >entities[media->entities_count - 1];
memset(entity, 0, sizeof *entity);
- entity->fd = -1;
entity->media = media;
strncpy(entity->devname, devnode, sizeof entity->devname);
entity->devname[sizeof entity->devname - 1] = '\0';
diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
index 33c1ee6..3977ce5 100644
--- a/utils/media-ctl/libv4l2subdev.c
+++ b/utils/media-ctl/libv4l2subdev.c
@@ -39,13 +39,61 @@
#include "tools.h"
#include "v4l2subdev.h"
+int v4l2_subdev_create(struct media_entity *entity)
+{
+ if (entity->sd)
+ return 0;
+
+ entity->sd = calloc(1, sizeof(*entity->sd));
+ if (entity->sd == NULL)
+ return -ENOMEM;
+
+ entity->sd->fd = -1;
+
+ return 0;
+}
+
+int v4l2_subdev_create_with_fd(struct media_entity *entity, int fd)
+{
+ int ret;
+
+ if (entity->sd)
+ return -EEXIST;
+
+ ret = v4l2_subdev_create(entity);
+ if (ret < 0)
+ return ret;
+
+ entity->sd->fd = fd;
+
+ return 0;
+}
+
+void v4l2_subdev_release(struct media_entity *entity, bool close_fd)
+{
+ if (entity->sd == NULL)
+ return;
+
+ if (close_fd)
+ v4l2_subdev_close(entity);
+
+ free(entity->sd->v4l2_control_redir);
+ free(entity->sd);
+}
+
int v4l2_subdev_open(struct media_entity *entity)
{
- if (entity->fd != -1)
+ int ret;
+
+ ret = v4l2_subdev_create(entity);
The current users of v4l2_subdev_open() in libv4l2subdev do not
explicitly close the sub-devices they open; thus calling
v4l2_subdev_create() here creates a memory leak.
Currently in my use cases there is no memory leak since I assumed
that the one who instantiates struct media_device should take
care of releasing it properly. I added v4l2_subdev_open_pipeline()
and v4l2_subdev_release_pipeline() API that is called on plugin
init and close respectively.
I'm referring to the use of the libv4l2subdev API as it's documented; the
media-ctl test program which also serves as a good example on the API.
Any sub-device IOCTL wrapper function will call v4l2_subdev_open() which
stores the file descriptor returned by open(2) to struct media_entity.fd.
v4l2_subdev_close() is not called explicitly. This is currently not
required.
The file handle is not leaked, as it is closed by media_device_unref() in
libmediactl.
This patch allocates memory for each sub-device in v4l2_subdev_create()
which is in turn called from v4l2_subdev_open(). As the calls to
v4l2_subdev_close() (which would release memory) are lacking, the memory is
leaked.
Probably it would be good to remove v4l2_subdev_open from
v4l2_subdev_* prefixed API and return error if sd property
of passed struct media_entity is n
Re: [PATCH 03/10] media framework: rename pads init function to media_entity_pads_init()
On 12/11/2015 02:34 PM, Mauro Carvalho Chehab wrote: With the MC next gen rework, what's left for media_entity_init() is to just initialize the PADs. However, certain devices, like a FLASH led/light doesn't have any input or output PAD. So, there's no reason why calling media_entity_init() would be mandatory. Also, despite its name, what this function actually does is to initialize the PADs data. So, rename it to media_entity_pads_init() in order to reflect that. The media entity actual init happens during entity register, at media_device_register_entity(). We should move init of num_links and num_backlinks to it. Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com> [...] diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c b/drivers/media/v4l2-core/v4l2-flash-led-class.c index 5c686a24712b..13d5a36bc5d8 100644 --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c @@ -651,7 +651,7 @@ struct v4l2_flash *v4l2_flash_init( sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; strlcpy(sd->name, config->dev_name, sizeof(sd->name)); - ret = media_entity_init(>entity, 0, NULL); + ret = media_entity_pads_init(>entity, 0, NULL); if (ret < 0) return ERR_PTR(ret); For this part: Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com> -- Best Regards, Jacek Anaszewski -- 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 v3 10/10] media: flash: use led_set_brightness_sync for torch brightness
On 11/16/2015 10:47 AM, Sakari Ailus wrote: Jacek Anaszewski wrote: This patch depends on the preceding LED core improvements patches from this patch set, and it would be best if it was merged through the LED tree. Can I get your ack for this? I've already obtained acks for the whole set from Sakari. I agree with this going through the LED tree. Applied this patch set, with fixed version of the patch 4/10 [1], thanks. [1] http://www.spinics.net/lists/linux-leds/msg05045.html -- Best Regards, Jacek Anaszewski -- 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 v3 10/10] media: flash: use led_set_brightness_sync for torch brightness
Hi Mauro,
This patch depends on the preceding LED core improvements patches
from this patch set, and it would be best if it was merged through
the LED tree. Can I get your ack for this? I've already obtained acks
for the whole set from Sakari.
Best Regards,
Jacek Anaszewski
On 10/07/2015 11:10 AM, Jacek Anaszewski wrote:
LED subsystem shifted responsibility for choosing between SYNC or ASYNC
way of setting brightness from drivers to the caller. Adapt the wrapper
to those changes.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: linux-media@vger.kernel.org
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..5d67335 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -107,10 +107,10 @@ static void v4l2_flash_set_led_brightness(struct
v4l2_flash *v4l2_flash,
if (ctrls[LED_MODE]->val != V4L2_FLASH_LED_MODE_TORCH)
return;
- led_set_brightness(_flash->fled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->fled_cdev->led_cdev,
brightness);
} else {
- led_set_brightness(_flash->iled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->iled_cdev->led_cdev,
brightness);
}
}
@@ -206,11 +206,11 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
case V4L2_CID_FLASH_LED_MODE:
switch (c->val) {
case V4L2_FLASH_LED_MODE_NONE:
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
return led_set_flash_strobe(fled_cdev, false);
case V4L2_FLASH_LED_MODE_FLASH:
/* Turn the torch LED off */
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
if (ctrls[STROBE_SOURCE]) {
external_strobe = (ctrls[STROBE_SOURCE]->val ==
V4L2_FLASH_STROBE_SOURCE_EXTERNAL);
--
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 v3 10/10] media: flash: use led_set_brightness_sync for torch brightness
LED subsystem shifted responsibility for choosing between SYNC or ASYNC
way of setting brightness from drivers to the caller. Adapt the wrapper
to those changes.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: linux-media@vger.kernel.org
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..5d67335 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -107,10 +107,10 @@ static void v4l2_flash_set_led_brightness(struct
v4l2_flash *v4l2_flash,
if (ctrls[LED_MODE]->val != V4L2_FLASH_LED_MODE_TORCH)
return;
- led_set_brightness(_flash->fled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->fled_cdev->led_cdev,
brightness);
} else {
- led_set_brightness(_flash->iled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->iled_cdev->led_cdev,
brightness);
}
}
@@ -206,11 +206,11 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
case V4L2_CID_FLASH_LED_MODE:
switch (c->val) {
case V4L2_FLASH_LED_MODE_NONE:
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
return led_set_flash_strobe(fled_cdev, false);
case V4L2_FLASH_LED_MODE_FLASH:
/* Turn the torch LED off */
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
if (ctrls[STROBE_SOURCE]) {
external_strobe = (ctrls[STROBE_SOURCE]->val ==
V4L2_FLASH_STROBE_SOURCE_EXTERNAL);
--
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] v4l2-flash-led-class: Add missing VIDEO_V4L2 Kconfig dependency
Fixes the following randconfig problem: drivers/built-in.o: In function `v4l2_flash_release': (.text+0x12204f): undefined reference to `v4l2_async_unregister_subdev' drivers/built-in.o: In function `v4l2_flash_release': (.text+0x122057): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_close': v4l2-flash-led-class.c:(.text+0x12208f): undefined reference to `v4l2_fh_is_singular' v4l2-flash-led-class.c:(.text+0x1220c8): undefined reference to `__v4l2_ctrl_s_ctrl' drivers/built-in.o: In function `v4l2_flash_open': v4l2-flash-led-class.c:(.text+0x12227f): undefined reference to `v4l2_fh_is_singular' drivers/built-in.o: In function `v4l2_flash_init_controls': v4l2-flash-led-class.c:(.text+0x12274e): undefined reference to `v4l2_ctrl_handler_init_class' v4l2-flash-led-class.c:(.text+0x122797): undefined reference to `v4l2_ctrl_new_std_menu' v4l2-flash-led-class.c:(.text+0x1227e0): undefined reference to `v4l2_ctrl_new_std' v4l2-flash-led-class.c:(.text+0x122826): undefined reference to `v4l2_ctrl_handler_setup' v4l2-flash-led-class.c:(.text+0x122839): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x1228e2): undefined reference to `v4l2_subdev_init' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x12293b): undefined reference to `v4l2_async_register_subdev' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x122949): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o:(.rodata+0x20ef8): undefined reference to `v4l2_subdev_queryctrl' drivers/built-in.o:(.rodata+0x20f10): undefined reference to `v4l2_subdev_querymenu' Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com> Reported-by: kbuild test robot <fengguang...@intel.com> Cc: Sakari Ailus <sakari.ai...@iki.fi> Cc: Hans Verkuil <hans.verk...@cisco.com> --- drivers/media/v4l2-core/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index 82876a6..9beece0 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -47,7 +47,7 @@ config V4L2_MEM2MEM_DEV # Used by LED subsystem flash drivers config V4L2_FLASH_LED_CLASS tristate "V4L2 flash API for LED flash class devices" - depends on VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API depends on LEDS_CLASS_FLASH ---help--- Say Y here to enable V4L2 flash API support for LED flash -- 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
Re: [PATCH] v4l2-flash-led-class: Add missing VIDEO_V4L2 Kconfig dependency
Hi Sakari, On 10/02/2015 11:41 AM, Sakari Ailus wrote: Hi Jacek, On Fri, Oct 02, 2015 at 11:19:15AM +0200, Jacek Anaszewski wrote: Fixes the following randconfig problem: drivers/built-in.o: In function `v4l2_flash_release': (.text+0x12204f): undefined reference to `v4l2_async_unregister_subdev' drivers/built-in.o: In function `v4l2_flash_release': (.text+0x122057): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_close': v4l2-flash-led-class.c:(.text+0x12208f): undefined reference to `v4l2_fh_is_singular' v4l2-flash-led-class.c:(.text+0x1220c8): undefined reference to `__v4l2_ctrl_s_ctrl' drivers/built-in.o: In function `v4l2_flash_open': v4l2-flash-led-class.c:(.text+0x12227f): undefined reference to `v4l2_fh_is_singular' drivers/built-in.o: In function `v4l2_flash_init_controls': v4l2-flash-led-class.c:(.text+0x12274e): undefined reference to `v4l2_ctrl_handler_init_class' v4l2-flash-led-class.c:(.text+0x122797): undefined reference to `v4l2_ctrl_new_std_menu' v4l2-flash-led-class.c:(.text+0x1227e0): undefined reference to `v4l2_ctrl_new_std' v4l2-flash-led-class.c:(.text+0x122826): undefined reference to `v4l2_ctrl_handler_setup' v4l2-flash-led-class.c:(.text+0x122839): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x1228e2): undefined reference to `v4l2_subdev_init' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x12293b): undefined reference to `v4l2_async_register_subdev' drivers/built-in.o: In function `v4l2_flash_init': (.text+0x122949): undefined reference to `v4l2_ctrl_handler_free' drivers/built-in.o:(.rodata+0x20ef8): undefined reference to `v4l2_subdev_queryctrl' drivers/built-in.o:(.rodata+0x20f10): undefined reference to `v4l2_subdev_querymenu' Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com> Reported-by: kbuild test robot <fengguang...@intel.com> Cc: Sakari Ailus <sakari.ai...@iki.fi> Cc: Hans Verkuil <hans.verk...@cisco.com> --- drivers/media/v4l2-core/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index 82876a6..9beece0 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -47,7 +47,7 @@ config V4L2_MEM2MEM_DEV # Used by LED subsystem flash drivers config V4L2_FLASH_LED_CLASS tristate "V4L2 flash API for LED flash class devices" - depends on VIDEO_V4L2_SUBDEV_API + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API depends on LEDS_CLASS_FLASH ---help--- Say Y here to enable V4L2 flash API support for LED flash Hmm. I wonder if VIDEO_V4L2_SUBDEV_API itself should depend on VIDEO_V4L2. That'd be logical, I don't think VIDEO_V4L2_SUBDEV_API could be meaningfully used with VIDEO_V4L2 disabled. The API implementation is in v4l2-subdev.c which itself depends on VIDEO_V4L2. Oddly enough, VIDEO_V4L2_SUBDEV_API is currently defined in drivers/media/Kconfig, it should probably be in drivers/media/v4l2-core/Kconfig instead. Since I don't see any Makefile referring to this symbol, it seems that moving it to drivers/media/v4l2-core/Kconfig and adding VIDEO_V4L2 dependency should be non-problematic operation. I can submit relevant patch if everyone agrees. -- Best Regards, Jacek Anaszewski -- 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 v2 12/12] media: flash: use led_set_brightness_sync for torch brightness
Hi Pavel,
Thanks for the review.
On 09/28/2015 10:37 PM, Pavel Machek wrote:
On Mon 2015-09-28 15:07:21, Jacek Anaszewski wrote:
LED subsystem shifted responsibility for choosing between SYNC or ASYNC
way of setting brightness from drivers to the caller. Adapt the wrapper
to those changes.
Umm. Maybe right patch, but wrong position in the queue, no?
If I understand changelog correctly, LED flashes will be subtly broken
before this patch is applied.
I guess this patch should be moved sooner so everything works at each
position in bisect...?
Moving it wouldn't improve anything. It would have to be merged with
patch 7/12 [1]. However, as you mentioned, LED flashes before this
patch will be broken only subtly, i.e. torch brightness will be set
from a work queue task and not synchronously. It would be barely
noticeable. Nonetheless, I can merge the patches in the next
version of the patch set.
[1] https://lkml.org/lkml/2015/9/28/322
Best regards,
Pavel
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: linux-media@vger.kernel.org
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..5d67335 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -107,10 +107,10 @@ static void v4l2_flash_set_led_brightness(struct
v4l2_flash *v4l2_flash,
if (ctrls[LED_MODE]->val != V4L2_FLASH_LED_MODE_TORCH)
return;
- led_set_brightness(_flash->fled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->fled_cdev->led_cdev,
brightness);
} else {
- led_set_brightness(_flash->iled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->iled_cdev->led_cdev,
brightness);
}
}
@@ -206,11 +206,11 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
case V4L2_CID_FLASH_LED_MODE:
switch (c->val) {
case V4L2_FLASH_LED_MODE_NONE:
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
return led_set_flash_strobe(fled_cdev, false);
case V4L2_FLASH_LED_MODE_FLASH:
/* Turn the torch LED off */
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
if (ctrls[STROBE_SOURCE]) {
external_strobe = (ctrls[STROBE_SOURCE]->val ==
V4L2_FLASH_STROBE_SOURCE_EXTERNAL);
--
Best Regards,
Jacek Anaszewski
--
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 12/12] media: flash: use led_set_brightness_sync for torch brightness
LED subsystem shifted responsibility for choosing between SYNC or ASYNC
way of setting brightness from drivers to the caller. Adapt the wrapper
to those changes.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Sakari Ailus <sakari.ai...@linux.intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: linux-media@vger.kernel.org
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..5d67335 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -107,10 +107,10 @@ static void v4l2_flash_set_led_brightness(struct
v4l2_flash *v4l2_flash,
if (ctrls[LED_MODE]->val != V4L2_FLASH_LED_MODE_TORCH)
return;
- led_set_brightness(_flash->fled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->fled_cdev->led_cdev,
brightness);
} else {
- led_set_brightness(_flash->iled_cdev->led_cdev,
+ led_set_brightness_sync(_flash->iled_cdev->led_cdev,
brightness);
}
}
@@ -206,11 +206,11 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
case V4L2_CID_FLASH_LED_MODE:
switch (c->val) {
case V4L2_FLASH_LED_MODE_NONE:
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
return led_set_flash_strobe(fled_cdev, false);
case V4L2_FLASH_LED_MODE_FLASH:
/* Turn the torch LED off */
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
if (ctrls[STROBE_SOURCE]) {
external_strobe = (ctrls[STROBE_SOURCE]->val ==
V4L2_FLASH_STROBE_SOURCE_EXTERNAL);
--
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
Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types
On 09/22/2015 11:13 AM, Andrzej Hajda wrote: On 09/21/2015 03:42 PM, David Howells wrote: Andrzej Hajda <a.hajda-sze3o3uu22jbdgjk7y7...@public.gmane.org> wrote: Semantic patch finds comparisons of types: unsigned < 0 unsigned >= 0 The former is always false, the latter is always true. Such comparisons are useless, so theoretically they could be safely removed, but their presence quite often indicates bugs. Or someone has left them in because they don't matter and there's the possibility that the type being tested might be or become signed under some circumstances. If the comparison is useless, I'd expect the compiler to just discard it - for such cases your patch is pointless. If I have, for example: unsigned x; if (x == 0 || x > 27) give_a_range_error(); I will write this as: unsigned x; if (x <= 0 || x > 27) give_a_range_error(); because it that gives a way to handle x being changed to signed at some point in the future for no cost. In which case, your changing the <= to an == "because the < part of the case is useless" is arguably wrong. This is why I have not checked for such cases - I have skipped checks of type unsigned <= 0 exactly for the reasons above. However I have left two other checks as they seems to me more suspicious - they are always true or false. But as Dmitry and Andrew pointed out Linus have quite strong opinion against removing range checks in such cases as he finds it clearer. I think it applies to patches 29-36. I am not sure about patches 26-28,37. Dropped 30/38 and 31/38 from LED tree then. -- Best Regards, Jacek Anaszewski -- 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 1/4] s5p-jpeg: generalize clocks handling
Hi Andrzej, Marek, On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote: From: Marek Szyprowski <m.szyprow...@samsung.com> Allow jpeg codec variants declare clocks they need. Before this patch is applied jpeg-core gets jpeg->sclk "speculatively": if it is not there, we assume no problem. This patch eliminates this by explicitly declaring what clocks are needed for each variant. This is a preparation for adding Exynos 5433 variant support, which needs 4 clocks of names not compatible with any previous version of jpeg hw module. Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com> [Rebase and commit message] Signed-off-by: Andrzej Pietrasiewicz <andrze...@samsung.com> --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 66 ++--- drivers/media/platform/s5p-jpeg/jpeg-core.h | 10 +++-- 2 files changed, 37 insertions(+), 39 deletions(-) Reviewed-by: Jacek Anaszewski <j.anaszew...@samsung.com> -- Best Regards, Jacek Anaszewski -- 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 3/4] MAINTAINERS: add exynos jpeg codec maintainers
On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote: Add Andrzej Pietrasiewicz and Jacek Anaszewski as maintainers of drivers/media/platform/s5p-jpeg. Signed-off-by: Andrzej Pietrasiewicz <andrze...@samsung.com> --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..ee9240b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1452,6 +1452,14 @@ L: linux-media@vger.kernel.org S:Maintained F:drivers/media/platform/s5p-tv/ +ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT +M: Andrzej Pietrasiewicz <andrze...@samsung.com> +M: Jacek Anaszewski <j.anaszew...@samsung.com> +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/s5p-jpeg/ + ARM/SHMOBILE ARM ARCHITECTURE M:Simon Horman <ho...@verge.net.au> M:Magnus Damm <magnus.d...@gmail.com> Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com> -- Best Regards, Jacek Anaszewski -- 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] s5p-jpeg: add support for 5433
Hi Andrzej, On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote: JPEG IP found in Exynos5433 is similar to what is in Exynos4, but there are some subtle differences which this patch takes into account. The most important difference is in what is processed by the JPEG IP and what has to be provided to it. In case of 5433 the IP does not parse Huffman and quantisation tables, so this has to be performed with the CPU and the majority of the code in this patch does that. A small but important difference is in what address is passed to the JPEG IP. In case of 5433 it is the SOS (start of scan) position, which is natural, because the headers must be parsed elsewhere. There is also a difference in how the hardware is put to work in device_run. Data structures are extended as appropriate to accommodate the above changes. Signed-off-by: Andrzej Pietrasiewicz <andrze...@samsung.com> --- .../bindings/media/exynos-jpeg-codec.txt | 3 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 378 +++-- drivers/media/platform/s5p-jpeg/jpeg-core.h| 31 ++ drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 80 - drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h | 11 +- drivers/media/platform/s5p-jpeg/jpeg-regs.h| 85 +++-- 6 files changed, 522 insertions(+), 66 deletions(-) Reviewed-by: Jacek Anaszewski <j.anaszew...@samsung.com> -- Best Regards, Jacek Anaszewski -- 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 v10.1] media: Add registration helpers for V4L2 flash sub-devices
On 07/28/2015 12:00 PM, Hans Verkuil wrote:
On 06/19/2015 09:31 AM, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
---
- fixed possible NULL fled_cdev pointer dereference
in the v4l2_flash_init function
drivers/media/v4l2-core/Kconfig| 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash-led-class.c | 710
include/media/v4l2-flash-led-class.h | 148 +
4 files changed, 871 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c
create mode 100644 include/media/v4l2-flash-led-class.h
snip
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
new file mode 100644
index 000..5bdfb8d
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
snip
+static const struct v4l2_subdev_core_ops v4l2_flash_core_ops = {
+ .queryctrl = v4l2_subdev_queryctrl,
+ .querymenu = v4l2_subdev_querymenu,
Why are these here? This should not be necessary. As long as the sd.ctrl_handler
pointer is set, this is handled automatically.
I removed these two lines and indeed driver works well without it.
+};
+
+static const struct v4l2_subdev_ops v4l2_flash_subdev_ops = {
+ .core = v4l2_flash_core_ops,
+};
+
And if v4l2_flash_core_ops goes away, then this can go away as well.
What should I pass as the second argument to v4l2_subdev_init then?
It seems that ops can't be NULL:
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct
v4l2_subdev_ops *ops)
{
INIT_LIST_HEAD(sd-list);
BUG_ON(!ops); ---
sd-ops = ops;
sd-v4l2_dev = NULL;
sd-flags = 0;
sd-name[0] = '\0';
sd-grp_id = 0;
sd-dev_priv = NULL;
sd-host_priv = NULL;
#if defined(CONFIG_MEDIA_CONTROLLER)
sd-entity.name = sd-name;
sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV;
#endif
}
I know this driver has been merged, but I just noticed this while looking at
something else.
Regards,
Hans
--
Best Regards,
Jacek Anaszewski
--
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: flash: Don't initialize core ops
queryctrl and querymenu menu ops don't need to be initialized
if sd.ctrl_handler is set. Since no other core ops are required
by the wrapper don't initialize related field of v4l2_flash_subdev_ops.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..57a1829 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -609,13 +609,7 @@ static const struct v4l2_subdev_internal_ops
v4l2_flash_subdev_internal_ops = {
.close = v4l2_flash_close,
};
-static const struct v4l2_subdev_core_ops v4l2_flash_core_ops = {
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
-};
-
static const struct v4l2_subdev_ops v4l2_flash_subdev_ops = {
- .core = v4l2_flash_core_ops,
};
struct v4l2_flash *v4l2_flash_init(
--
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
Re: [PATCH v10.1] media: Add registration helpers for V4L2 flash sub-devices
On 28.07.2015 12:00, Hans Verkuil wrote:
On 06/19/2015 09:31 AM, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
---
- fixed possible NULL fled_cdev pointer dereference
in the v4l2_flash_init function
drivers/media/v4l2-core/Kconfig| 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash-led-class.c | 710
include/media/v4l2-flash-led-class.h | 148 +
4 files changed, 871 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c
create mode 100644 include/media/v4l2-flash-led-class.h
snip
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
new file mode 100644
index 000..5bdfb8d
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
snip
+static const struct v4l2_subdev_core_ops v4l2_flash_core_ops = {
+ .queryctrl = v4l2_subdev_queryctrl,
+ .querymenu = v4l2_subdev_querymenu,
Why are these here? This should not be necessary. As long as the sd.ctrl_handler
pointer is set, this is handled automatically.
+};
+
+static const struct v4l2_subdev_ops v4l2_flash_subdev_ops = {
+ .core = v4l2_flash_core_ops,
+};
+
And if v4l2_flash_core_ops goes away, then this can go away as well.
I know this driver has been merged, but I just noticed this while looking at
something else.
I'll be able to verify this no sooner than in two weeks. Probably
you're right as I added this snippet without checking if it was
really necessary.
--
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
--
Best Regards,
Jacek Anaszewski
--
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/RFC 06/51] media: flash: use led_set_brightness_sync for torch brightness
LED subsystem shifted responsibility for choosing between SYNC or ASYNC
way of setting brightness from drivers to the caller. Adapt the wrapper
to those changes.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Cc: Sakari Ailus sakari.ai...@linux.intel.com
Cc: Pavel Machek pa...@ucw.cz
Cc: linux-media@vger.kernel.org
---
drivers/media/v4l2-core/v4l2-flash-led-class.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index 5bdfb8d..5d67335 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -107,10 +107,10 @@ static void v4l2_flash_set_led_brightness(struct
v4l2_flash *v4l2_flash,
if (ctrls[LED_MODE]-val != V4L2_FLASH_LED_MODE_TORCH)
return;
- led_set_brightness(v4l2_flash-fled_cdev-led_cdev,
+ led_set_brightness_sync(v4l2_flash-fled_cdev-led_cdev,
brightness);
} else {
- led_set_brightness(v4l2_flash-iled_cdev-led_cdev,
+ led_set_brightness_sync(v4l2_flash-iled_cdev-led_cdev,
brightness);
}
}
@@ -206,11 +206,11 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
case V4L2_CID_FLASH_LED_MODE:
switch (c-val) {
case V4L2_FLASH_LED_MODE_NONE:
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
return led_set_flash_strobe(fled_cdev, false);
case V4L2_FLASH_LED_MODE_FLASH:
/* Turn the torch LED off */
- led_set_brightness(led_cdev, LED_OFF);
+ led_set_brightness_sync(led_cdev, LED_OFF);
if (ctrls[STROBE_SOURCE]) {
external_strobe = (ctrls[STROBE_SOURCE]-val ==
V4L2_FLASH_STROBE_SOURCE_EXTERNAL);
--
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 v10.1] leds: aat1290: add support for V4L2 Flash sub-device
Add support for V4L2 Flash sub-device to the aat1290 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
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 rpur...@rpsys.net
Cc: Sakari Ailus sakari.ai...@iki.fi
---
- fixed sparse warnings by adding 'static' modifiers to the functions:
* aat1290_intensity_to_brightness
* aat1290_brightness_to_intensity
drivers/leds/Kconfig|1 +
drivers/leds/leds-aat1290.c | 137 +--
2 files changed, 132 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 14876d3..a1013c5 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -44,6 +44,7 @@ config LEDS_AAT1290
depends on LEDS_CLASS_FLASH
depends on GPIOLIB
depends on OF
+ depends on PINCTRL
help
This option enables support for the LEDs on the AAT1290.
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index b055882..2a5254c 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -17,9 +17,11 @@
#include linux/module.h
#include linux/mutex.h
#include linux/of.h
+#include linux/pinctrl/consumer.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/workqueue.h
+#include media/v4l2-flash-led-class.h
#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
#define AAT1290_MAX_MM_CURR_PERCENT_0 16
@@ -52,6 +54,8 @@ struct aat1290_led_config_data {
u32 max_flash_current;
/* maximum flash timeout */
u32 max_flash_tm;
+ /* external strobe capability */
+ bool has_external_strobe;
/* max LED brightness level */
enum led_brightness max_brightness;
};
@@ -64,6 +68,8 @@ struct aat1290_led {
/* corresponding LED Flash class device */
struct led_classdev_flash fled_cdev;
+ /* V4L2 Flash device */
+ struct v4l2_flash *v4l2_flash;
/* FLEN pin */
struct gpio_desc *gpio_fl_en;
@@ -230,11 +236,15 @@ static int aat1290_led_flash_timeout_set(struct
led_classdev_flash *fled_cdev,
}
static int aat1290_led_parse_dt(struct aat1290_led *led,
- struct aat1290_led_config_data *cfg)
+ struct aat1290_led_config_data *cfg,
+ struct device_node **sub_node)
{
struct led_classdev *led_cdev = led-fled_cdev.led_cdev;
struct device *dev = led-pdev-dev;
struct device_node *child_node;
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ struct pinctrl *pinctrl;
+#endif
int ret = 0;
led-gpio_fl_en = devm_gpiod_get(dev, flen, GPIOD_ASIS);
@@ -251,6 +261,17 @@ static int aat1290_led_parse_dt(struct aat1290_led *led,
return ret;
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ pinctrl = devm_pinctrl_get_select_default(led-pdev-dev);
+ if (IS_ERR(pinctrl)) {
+ cfg-has_external_strobe = false;
+ dev_info(dev,
+No support for external strobe detected.\n);
+ } else {
+ cfg-has_external_strobe = true;
+ }
+#endif
+
child_node = of_get_next_available_child(dev-of_node, NULL);
if (!child_node) {
dev_err(dev, No DT child node found for connected LED.\n);
@@ -288,6 +309,8 @@ static int aat1290_led_parse_dt(struct aat1290_led *led,
of_node_put(child_node);
+ *sub_node = child_node;
+
return ret;
}
@@ -316,7 +339,8 @@ static int init_mm_current_scale(struct aat1290_led *led,
int i, max_mm_current =
AAT1290_MAX_MM_CURRENT(cfg-max_flash_current);
- led-mm_current_scale = kzalloc(sizeof(max_mm_current_percent),
+ led-mm_current_scale = devm_kzalloc(led-pdev-dev,
+ sizeof(max_mm_current_percent),
GFP_KERNEL);
if (!led-mm_current_scale)
return -ENOMEM;
@@ -329,11 +353,12 @@ static int init_mm_current_scale(struct aat1290_led *led,
}
static int aat1290_led_get_configuration(struct aat1290_led *led,
- struct aat1290_led_config_data *cfg)
+ struct aat1290_led_config_data *cfg,
+ struct device_node **sub_node)
{
int ret;
- ret = aat1290_led_parse_dt(led, cfg);
+ ret = aat1290_led_parse_dt(led, cfg, sub_node);
if (ret 0)
return ret;
/*
@@ -346,7 +371,10 @@ static int aat1290_led_get_configuration(struct
aat1290_led *led,
aat1290_led_validate_mm_current(led, cfg);
- kfree(led-mm_current_scale);
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+#else
+ devm_kfree(led-pdev-dev
[PATCH] leds: aat1290: Add 'static' modifier to init_mm_current_scale
Fix sparse warning by adding static modifier to the function
init_mm_current_scale.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
---
drivers/leds/leds-aat1290.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index 8635404..b055882 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -308,7 +308,7 @@ static void aat1290_led_validate_mm_current(struct
aat1290_led *led,
cfg-max_brightness = b + 1;
}
-int init_mm_current_scale(struct aat1290_led *led,
+static int init_mm_current_scale(struct aat1290_led *led,
struct aat1290_led_config_data *cfg)
{
int max_mm_current_percent[] = { 20, 22, 25, 28, 32, 36, 40, 45, 50, 56,
--
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
Re: [PATCH v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Alexey,
On 06/18/2015 07:45 PM, Alexey Klimov wrote:
Hi Jacek,
On Mon, May 25, 2015 at 6:13 PM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
---
drivers/media/v4l2-core/Kconfig| 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash-led-class.c | 671
include/media/v4l2-flash-led-class.h | 148 ++
4 files changed, 832 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c
create mode 100644 include/media/v4l2-flash-led-class.h
[...]
+struct v4l2_flash *v4l2_flash_init(
+ struct device *dev, struct device_node *of_node,
+ struct led_classdev_flash *fled_cdev,
+ struct led_classdev_flash *iled_cdev,
+ const struct v4l2_flash_ops *ops,
+ struct v4l2_flash_config *config)
+{
+ struct v4l2_flash *v4l2_flash;
+ struct led_classdev *led_cdev = fled_cdev-led_cdev;
+ struct v4l2_subdev *sd;
+ int ret;
+
+ if (!fled_cdev || !ops || !config)
+ return ERR_PTR(-EINVAL);
Could you please if it is correct? You're checking fled_cdev but four
lines above you're using fled_cdev and taking led_cdev pointer from
there. Maybe it's better to move calculation of led_cdev down and
place after if-check?
Thanks for spotting this. I'll submit fixed version soon.
--
Best Regards,
Jacek Anaszewski
--
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 v10.1] media: Add registration helpers for V4L2 flash sub-devices
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
---
- fixed possible NULL fled_cdev pointer dereference
in the v4l2_flash_init function
drivers/media/v4l2-core/Kconfig| 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash-led-class.c | 710
include/media/v4l2-flash-led-class.h | 148 +
4 files changed, 871 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c
create mode 100644 include/media/v4l2-flash-led-class.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index f7a01a7..b4b0229 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -44,6 +44,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate V4L2 flash API for LED flash class devices
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable V4L2 flash API support for LED flash
+ class drivers.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..dc3de00 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash-led-class.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
new file mode 100644
index 000..5bdfb8d
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -0,0 +1,710 @@
+/*
+ * V4L2 flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski j.anaszew...@samsung.com
+ *
+ * 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.
+ */
+
+#include linux/led-class-flash.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/types.h
+#include media/v4l2-flash-led-class.h
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash v4l2_flash-ops-op)
+
+#define call_flash_op(v4l2_flash, op, arg) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash-ops-op(v4l2_flash, arg) : \
+ -EINVAL)
+
+enum ctrl_init_data_id {
+ LED_MODE,
+ TORCH_INTENSITY,
+ FLASH_INTENSITY,
+ INDICATOR_INTENSITY,
+ FLASH_TIMEOUT,
+ STROBE_SOURCE,
+ /*
+* Only above values are applicable to
+* the 'ctrls' array in the struct v4l2_flash.
+*/
+ FLASH_STROBE,
+ STROBE_STOP,
+ STROBE_STATUS,
+ FLASH_FAULT,
+ NUM_FLASH_CTRLS,
+};
+
+static enum led_brightness __intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl, s32 intensity)
+{
+ intensity -= ctrl-minimum;
+ intensity /= (u32) ctrl-step;
+
+ /*
+* Indicator LEDs, unlike torch LEDs, are turned on/off basing on
+* 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 (ctrl-minimum)
+ ++intensity;
+
+ return intensity;
+}
+
+static s32 __led_brightness_to_intensity(struct v4l2_ctrl *ctrl,
+enum led_brightness brightness)
+{
+ /*
+* Indicator LEDs, unlike torch LEDs, are turned on/off basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Do not decrement brightness read from the LED subsystem for
+* indicator LED as it may equal 0. For torch LEDs this function
+* is called only when V4L2_FLASH_LED_MODE_TORCH is set and the
+* brightness read is guaranteed to be greater than 0. In the mode
Re: [PATCH v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
On 06/08/2015 09:37 AM, Sakari Ailus wrote:
Hi Jacek,
On Mon, Jun 08, 2015 at 09:21:10AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/03/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Jun 03, 2015 at 09:56:39AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/02/2015 05:32 PM, Sakari Ailus wrote:
Hi, Jacek!
On Tue, Jun 02, 2015 at 11:13:54AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
Good catch.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
I think you could spare some newlines above (and below as well).
There must have been some issue on thunderbird side,
originally there were no newlines above.
Ok. I've used Seamonkey, I believe it uses the same editor. Some bugs were
unintroduced a few years ago, and since that I've mostly used a different
editor (and MUA) when replying to patches.
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
You can also declare led_cdev_ind here as you don't need it outside the
basic block.
With new approach it will be required also in error path.
True.
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
Please don't acquire the indicator mutex while holding the flash mutex. I
don't think there's a need to do so, thus creating a dependency between the
two.Just remember to check for v4l2_fh_is_singular() in both cases.
I thought that the code would be simpler this way. Nevertheless I
produced a new version by following your advise.
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
If ret is 0 here, you end up disabling the sysfs interface while open()
fails (and v4l2_flash_close() will not be run). Shouldn't you handle that?
Good point.
Please find the new version of v4l2_flash{open|close} functions below:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind = NULL;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
Hmm. I just realised that this might be a bit broken ---
v4l2_fh_is_singular() should return the same value independently of where in
subdev's open() handler it is called.
But adding file handles to the list and checking how many there are of them
is not properly serialised, i.e. another process could change the list in
between. I'll try to submit a patch for that. No need to wait for that
though.
So please ignore my earlier request to check for v4l2_fh_is_singular() for
multiple times, it won't help. Once is enough, albeit more than that won't
hurt.
Let's agree on the new shape of the functions then:
Looks good to me. Could you resend once more, please?
Of course, there will be also minor modifications in the other
patches of the patch set.
tatic int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev
Re: [PATCH v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Sakari,
On 06/03/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Wed, Jun 03, 2015 at 09:56:39AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/02/2015 05:32 PM, Sakari Ailus wrote:
Hi, Jacek!
On Tue, Jun 02, 2015 at 11:13:54AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled 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
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
Good catch.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
I think you could spare some newlines above (and below as well).
There must have been some issue on thunderbird side,
originally there were no newlines above.
Ok. I've used Seamonkey, I believe it uses the same editor. Some bugs were
unintroduced a few years ago, and since that I've mostly used a different
editor (and MUA) when replying to patches.
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
You can also declare led_cdev_ind here as you don't need it outside the
basic block.
With new approach it will be required also in error path.
True.
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
Please don't acquire the indicator mutex while holding the flash mutex. I
don't think there's a need to do so, thus creating a dependency between the
two.Just remember to check for v4l2_fh_is_singular() in both cases.
I thought that the code would be simpler this way. Nevertheless I
produced a new version by following your advise.
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
If ret is 0 here, you end up disabling the sysfs interface while open()
fails (and v4l2_flash_close() will not be run). Shouldn't you handle that?
Good point.
Please find the new version of v4l2_flash{open|close} functions below:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind = NULL;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
Hmm. I just realised that this might be a bit broken ---
v4l2_fh_is_singular() should return the same value independently of where in
subdev's open() handler it is called.
But adding file handles to the list and checking how many there are of them
is not properly serialised, i.e. another process could change the list in
between. I'll try to submit a patch for that. No need to wait for that
though.
So please ignore my earlier request to check for v4l2_fh_is_singular() for
multiple times, it won't help. Once is enough, albeit more than that won't
hurt.
Let's agree on the new shape of the functions then:
tatic int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind = NULL;
int ret = 0;
if (!v4l2_fh_is_singular(fh-vfh))
return 0;
mutex_lock(led_cdev-led_access
