Re: [PATCH 0/3] Deprecate drivers
On 12/02/14 23:42, Ondrej Zary wrote: On Tuesday 02 December 2014 16:40:30 Hans Verkuil wrote: This patch series deprecates the vino/saa7191 video driver (ancient SGI Indy computer), the parallel port webcams bw-qcam, c-qcam and w9966, the ISA video capture driver pms and the USB video capture tlg2300 driver. Hardware for these devices is next to impossible to obtain, these drivers haven't seen any development in ages, they often use deprecated APIs and without hardware that's very difficult to port. And cheap alternative products are easily available today. Just bought a QuickCam Pro parallel and some unknown parallel port webcam. Will you accept patches? :) OK, so there is some confusion here. You aren't offering to work on any of the deprecated drivers, are you? I'm sure you meant this email as a joke, but before the drivers are deprecated it is good to get that confirmed. Regards, Hans So move these drivers to staging for 3.19 and plan on removing them in 3.20. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Sakari, On 12/04/2014 12:40 PM, Jacek Anaszewski wrote: On 12/04/2014 11:07 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote: This patch adds device tree binding documentation for the flash cell of the Maxim max77693 multifunctional device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Andrzej Hajda a.ha...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Cc: Chanwoo Choi cw00.c...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/mfd/max77693.txt | 89 1 file changed, 89 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..25a6e78 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,7 +41,66 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : Must be maxim,max77693-led. + +Optional properties: +- maxim,fleds : Array of current outputs in order: fled1, fled2. +Note: both current outputs can be connected to a single led +Possible values: +MAX77693_LED_FLED_UNUSED - the output is left disconnected, +MAX77693_LED_FLED_USED - a diode is connected to the output. As you have a LED sub-nodes for each LED already, isn't this redundant? Well, it seems so :) I agreed here recklessly. This property allows to describe the situation when one LED is connected to both outputs. Single sub-node can describe two type of designs: one LED connected to a single output or one LED connected to both outputs. Therefore additional property is needed to assess what is the actual case. 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
[GIT PULL] SiLabs improvements
These are mostly small improvements, having very small functionality changes. regards Antti The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for you to fetch changes up to ade964f4a620194de8ae5c6f0719dd2ae7681b96: si2157: change firmware variable name and type (2014-12-06 23:32:14 +0200) Antti Palosaari (22): si2168: define symbol rate limits si2168: rename device state variable from 's' to 'dev' si2168: carry pointer to client instead of state si2168: get rid of own struct i2c_client pointer si2168: simplify si2168_cmd_execute() error path si2168: rename few things si2168: change firmware version print from debug to info si2168: change stream id debug log formatter si2168: add own goto label for kzalloc failure si2168: enhance firmware download routine si2168: remove unneeded fw variable initialization si2168: print chip version si2168: change firmware variable name and type si2157: rename device state variable from 's' to 'dev' si2157: simplify si2157_cmd_execute() error path si2157: carry pointer to client instead of state in tuner_priv si2157: change firmware download error handling si2157: trivial ID table changes si2157: add own goto label for kfree() on probe error si2157: print firmware version si2157: print chip version si2157: change firmware variable name and type drivers/media/dvb-frontends/si2168.c | 308 - drivers/media/dvb-frontends/si2168.h | 6 ++-- drivers/media/dvb-frontends/si2168_priv.h | 3 +- drivers/media/tuners/si2157.c | 189 +++ drivers/media/tuners/si2157_priv.h| 3 +- 5 files changed, 247 insertions(+), 262 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Jacek, On Wed, Dec 10, 2014 at 11:02:07AM +0100, Jacek Anaszewski wrote: Hi Sakari, On 12/04/2014 12:40 PM, Jacek Anaszewski wrote: On 12/04/2014 11:07 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Dec 03, 2014 at 05:06:41PM +0100, Jacek Anaszewski wrote: This patch adds device tree binding documentation for the flash cell of the Maxim max77693 multifunctional device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Signed-off-by: Andrzej Hajda a.ha...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Lee Jones lee.jo...@linaro.org Cc: Chanwoo Choi cw00.c...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/mfd/max77693.txt | 89 1 file changed, 89 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 01e9f30..25a6e78 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -41,7 +41,66 @@ Optional properties: To get more informations, please refer to documentaion. [*] refer Documentation/devicetree/bindings/pwm/pwm.txt +- led : the LED submodule device node + +There are two led outputs available - fled1 and fled2. Each of them can +control a separate led or they can be connected together to double +the maximum current for a single connected led. One led is represented +by one child node. + +Required properties: +- compatible : Must be maxim,max77693-led. + +Optional properties: +- maxim,fleds : Array of current outputs in order: fled1, fled2. +Note: both current outputs can be connected to a single led +Possible values: +MAX77693_LED_FLED_UNUSED - the output is left disconnected, +MAX77693_LED_FLED_USED - a diode is connected to the output. As you have a LED sub-nodes for each LED already, isn't this redundant? Well, it seems so :) I agreed here recklessly. This property allows to describe the If this is reckless then we're doing very, very well. :-D situation when one LED is connected to both outputs. Single sub-node can describe two type of designs: one LED connected to a single output or one LED connected to both outputs. Therefore additional property is needed to assess what is the actual case. Which output do you say such LED is connected then? I wonder if the reg property could be made an array, so you could say the LED is connected to this and that output. The advantage would be that this still works even if you have three outputs. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
On 10/12/14 11:02, Jacek Anaszewski wrote: +Optional properties: +- maxim,fleds : Array of current outputs in order: fled1, fled2. s/current outputs/LED current regulator outputs used/ ? +Note: both current outputs can be connected to a single led s/led/LED ? And there seem to be other similar occurrences that would need to be put in upper case. +Possible values: +MAX77693_LED_FLED_UNUSED - the output is left disconnected, +MAX77693_LED_FLED_USED - a diode is connected to the output. As noted below, I would simply use 0/1 for these. As you have a LED sub-nodes for each LED already, isn't this redundant? Well, it seems so :) I agreed here recklessly. This property allows to describe the situation when one LED is connected to both outputs. Single sub-node can describe two type of designs: one LED connected to a single output or one LED connected to both outputs. Therefore additional property is needed to assess what is the actual case. How about renaming maxim,fleds to maxim,active-outputs ? And simply using 0 and 1 to indicate if one is used or not, rather than defining macros for these true/false values ? -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi,
On 04/12/14 17:12, Pavel Machek wrote:
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then
boost
+ is enabled by default.
+ Possible values:
+ MAX77693_LED_BOOST_OFF - no boost,
+ MAX77693_LED_BOOST_ADAPTIVE - adaptive mode,
+ MAX77693_LED_BOOST_FIXED - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is
not fired
+ if chip estimates that system voltage could drop below this
level due
+ to flash power consumption.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : Identifier of the fled output the led is connected
to;
I'm pretty sure this will be needed for about every chip that can drive
multiple LEDs. Shouldn't it be documented in the generic documentation?
OK.
Well... fled_id is not exactly suitable name. On other busses, it
would be reg = 1?
I think we need to clarify what the LED device node subnodes really mean.
I thought initially they describe a physical current output of the LED
controller, but it turns out the subnode corresponds to a LED attached
to the LED controller. Since a LED can be connected to multiple outputs
of the LED controller I think 'reg' property doesn't make sense here.
Then presumably we should use a property in each subnode, telling which
LED controller outputs a LED is connected to?
For instance, if we assign numbers 0, 1 to FLED1, FLED2 outputs of
MAX77693 and there is just one LED connected to those outputs we would
have something like:
max77693: led {
compatible = maxim,max77693-led;
...
led1 {
maxim,fled-sources = 0 1;
...
};
};
Feel free to propose better name for the property, I guess we need to
avoid maxim,current-sources due to ambiguity of the word current.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 04/19] mfd: max77693: adjust max77693_led_platform_data
On 12/09/2014 03:41 PM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 02:50 PM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 11:04 AM, Lee Jones wrote:
On Tue, 09 Dec 2014, Jacek Anaszewski wrote:
On 12/09/2014 09:50 AM, Lee Jones wrote:
On Wed, 03 Dec 2014, Jacek Anaszewski wrote:
Add label array for Device Tree strings with the name of a LED device
and make flash_timeout a two element array, for caching the sub-led
related flash timeout. Added is also an array for caching pointers to the
sub-nodes representing sub-leds.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Lee Jones lee.jo...@linaro.org
---
include/linux/mfd/max77693.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index f0b6585..c80ee99 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -88,16 +88,18 @@ enum max77693_led_boost_mode {
};
struct max77693_led_platform_data {
+ const char *label[2];
u32 fleds[2];
u32 iout_torch[2];for_each_available_child_of_node
u32 iout_flash[2];
u32 trigger[2];
u32 trigger_type[2];
+ u32 flash_timeout[2];
u32 num_leds;
u32 boost_mode;
- u32 flash_timeout;
u32 boost_vout;
u32 low_vsys;
+ struct device_node *sub_nodes[2];
I haven't seen anyone do this before. Why can't you use the provided
OF functions to traverse through your tree?
I use for_each_available_child_of_node when parsing DT node, but I
need to cache the pointer to sub-node to be able to use it later
when it needs to be passed to V4L2 sub-device which is then
asynchronously matched by the phandle to sub-node.
If it is not well seen to cache it in the platform data then
I will find different way to accomplish this.
I haven't seen the end-driver for this, but why can't you use that
device's of_node pointer?
Maybe it is indeed a good idea. I could pass the of_node pointer
and the sub-led identifier to the V4L2 sub-device and there look
for the sub-node containing relevant identifier. The downside
would be only that for_each_available_child_of_node would
have to be called twice - in the led driver and in the V4L2 sub-device.
I think that we can live with it.
Are the LED and V4L2 drivers children of this MFD? If so, you can use
the of_compatible attribute in struct mfd_cell to populate the each
child's of_node dynamically i.e. the MFD core will do that for you.
V4L2 driver wraps LED driver. This way the LED device can be
controlled with use of two interfaces - LED subsystem sysfs
and V4L2 Flash. This is the aim of the whole patch set.
I've thought it over again and it seems that I will need to cache
somewhere these sub_nodes pointers. They have to be easily accessible
for the V4L2 sub-device as it can be asynchronously registered
or unregistered within V4L2 media device. Sub-devices are matched
basing on the sub-node phandle.
Not quite getting this. Can you explain this in another way please?
It turned out that it is possible to store the sub-node pointer in the
struct device returned by device_create_with_groups, while creating LED
class device. Its of_node property is uninitialized.
Regardless of it - there will be next version of this patch.
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/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
On 12/10/2014 01:20 PM, Sylwester Nawrocki wrote:
Hi,
On 04/12/14 17:12, Pavel Machek wrote:
+- maxim,boost-mode :
+ In boost mode the device can produce up to 1.2A of total current
+ on both outputs. The maximum current on each output is reduced
+ to 625mA then. If there are two child led nodes defined then boost
+ is enabled by default.
+ Possible values:
+ MAX77693_LED_BOOST_OFF - no boost,
+ MAX77693_LED_BOOST_ADAPTIVE - adaptive mode,
+ MAX77693_LED_BOOST_FIXED - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+ if chip estimates that system voltage could drop below this level due
+ to flash power consumption.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : Identifier of the fled output the led is connected to;
I'm pretty sure this will be needed for about every chip that can drive
multiple LEDs. Shouldn't it be documented in the generic documentation?
OK.
Well... fled_id is not exactly suitable name. On other busses, it
would be reg = 1?
I think we need to clarify what the LED device node subnodes really mean.
I thought initially they describe a physical current output of the LED
controller, but it turns out the subnode corresponds to a LED attached
to the LED controller. Since a LED can be connected to multiple outputs
of the LED controller I think 'reg' property doesn't make sense here.
Then presumably we should use a property in each subnode, telling which
LED controller outputs a LED is connected to?
For instance, if we assign numbers 0, 1 to FLED1, FLED2 outputs of
MAX77693 and there is just one LED connected to those outputs we would
have something like:
max77693: led {
compatible = maxim,max77693-led;
...
led1 {
maxim,fled-sources = 0 1;
...
};
};
Feel free to propose better name for the property, I guess we need to
avoid maxim,current-sources due to ambiguity of the word current.
For me this sounds reasonable. Moreover we will avoid the need for
address-cells and size-cells properties in the parent node.
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/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
On 12/09/2014 04:50 PM, Pavel Machek wrote: On Tue 2014-12-09 09:54:06, Jacek Anaszewski wrote: Hi Pavel, On 12/08/2014 09:18 PM, Pavel Machek wrote: On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe read is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. No, semantics should be same for all devices. If device clears fault register during I2C readout, kernel will simply gather faults in an variable, and clear them upon write to sysfs file. This approach would require implementing additional mechanisms on both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at runtime? Why? We can emulate sane and consistent behaviour for all the controllers: read gives you list of faults, write clears it. We can do it for all the controllers. I don't like the idea of listing the faults in the form of strings. I'd like to see the third opinion :) Only cost is few lines of code in the drivers where hardware clears faults at read. As above - the third opinion would be appreciated. would have to be implemented per driver. We would have to also consider how to approach the issue in case of sub-leds. Actually.. sub-leds. That is one physical LED being connected to two current sources at the same time, right? There are possible designs with two separate LEDs. -- 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/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi! both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at runtime? Why? We can emulate sane and consistent behaviour for all the controllers: read gives you list of faults, write clears it. We can do it for all the controllers. I don't like the idea of listing the faults in the form of strings. I'd like to see the third opinion :) Well, I see that you don't like to change existing code. But I hacked it this way and I'm going to ask n-th opinion so that I don't have to touch it is not a way to design interfaces. Only cost is few lines of code in the drivers where hardware clears faults at read. As above - the third opinion would be appreciated. Just email Greg if he likes /sys files with sideffects on read. Or just think. You never do grep in /sys? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/4] dma-buf: Add constraints sharing information
Hi Daniel, Thanks a bunch for your review comments! A few comments, post our discussion at LPC; On 12 October 2014 at 00:25, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote: At present, struct device lacks a mechanism of exposing memory access constraints for the device. Consequently, there is also no mechanism to share these constraints while sharing buffers using dma-buf. If we add support for sharing such constraints, we could use that to try to collect requirements of different buffer-sharing devices to allocate buffers from a pool that satisfies requirements of all such devices. This is an attempt to add this support; at the moment, only a bitmask is added, but if post discussion, we realise we need more information, we could always extend the definition of constraint. A new dma-buf op is also added, to allow exporters to interpret or decide on constraint-masks on their own. A default implementation is provided to just AND () all the constraint-masks. What constitutes a constraint-mask could be left for interpretation on a per-platform basis, while defining some common masks. Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Just a few high-level comments, I'm between conference travel but hopefully I can discuss this a bit at plumbers next week. - I agree that for the insane specific cases we need something opaque like the access constraints mask you propose here. But for the normal case I think the existing dma constraints in dma_params would go a long way, and I think we should look at Rob's RFC from aeons ago to solve those: https://lkml.org/lkml/2012/7/19/285 With this we should be able to cover the allocation constraints of 90% of all cases hopefully. - I'm not sure whether an opaque bitmask is good enough really, I suspect that we also need various priorities between different allocators. With the option that some allocators are flat-out incompatible. Your/Rob's idea to figure out the constraints wrt max number of segments in the sg_list can provide, like you said, maybe 80-90% of the allocation constraints hopefully. The opaque mask should help for the remaining 'crazy' cases, so I'll be glad to merge Rob's and my approach on defining the constraints. I should think a little bit more about the priority idea that you propose here (and in another patch), but atm I am unable to see how that could help solve the finding-out-constraints problem. - The big bummer imo with ION is that it fully side-steps, but this proposal here also seems to add entirely new allocators. My rough idea This proposal does borrow this bit from ION, but once we have the required changes done in the dma api itself, the allocators can just become shims to the dma api allocators (eg dma_alloc_coherent etc) for cases where they can be used directly, while leaving provision for any crazy platform-specific allocators, without the userspace having to worry about it. was that at allocate/attach time we iterate over all attached devices like in Rob's patch and compute the most constrained allocation requirements. Then we pick the underlying dma api allocator for these constraints. That probably means that we need to open up the dma api a bit. But I guess for a start we could simply try to allocate from the most constrained device. Together with the opaque bits you propose here we could even map additional crazy requirements like that an allocation must come from a specific memory bank (provided by a special-purpose CMA region). That might also mean that requirements are exclusive and no allocation is possible. My idea was a little variation on what you said here - rather than do compute the most constraint allocation 'after' devices have attached (and right now, we don't really have a way to know that - but that's another point), I'd proposed to do the compute on each attach request, so the requesting drivers can know immediately if the attachment will not work for the other currently attached devices. - I'm not sure we should allow drivers to override the access constraint checks really - the dma_buf interfaces already provide this possibility through the -attach callback. In there exporters are allowed to reject the attachment for any reason whatsover. This override the access constraint check is again meant only as a helper, but I could sure drop it. - I think we should at least provide a helper implementation to allocate dma-buffers for multiple devices using the dma constraints logic we implement here. I think we should even go as far as providing a default implementation for dma-bufs which uses dma_alloc_coherent and this new dma contstraints computation code
Re: [RFC 1/4] dma-buf: Add constraints sharing information
On Wed, Dec 10, 2014 at 07:01:16PM +0530, Sumit Semwal wrote: Hi Daniel, Thanks a bunch for your review comments! A few comments, post our discussion at LPC; On 12 October 2014 at 00:25, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote: At present, struct device lacks a mechanism of exposing memory access constraints for the device. Consequently, there is also no mechanism to share these constraints while sharing buffers using dma-buf. If we add support for sharing such constraints, we could use that to try to collect requirements of different buffer-sharing devices to allocate buffers from a pool that satisfies requirements of all such devices. This is an attempt to add this support; at the moment, only a bitmask is added, but if post discussion, we realise we need more information, we could always extend the definition of constraint. A new dma-buf op is also added, to allow exporters to interpret or decide on constraint-masks on their own. A default implementation is provided to just AND () all the constraint-masks. What constitutes a constraint-mask could be left for interpretation on a per-platform basis, while defining some common masks. Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Just a few high-level comments, I'm between conference travel but hopefully I can discuss this a bit at plumbers next week. - I agree that for the insane specific cases we need something opaque like the access constraints mask you propose here. But for the normal case I think the existing dma constraints in dma_params would go a long way, and I think we should look at Rob's RFC from aeons ago to solve those: https://lkml.org/lkml/2012/7/19/285 With this we should be able to cover the allocation constraints of 90% of all cases hopefully. - I'm not sure whether an opaque bitmask is good enough really, I suspect that we also need various priorities between different allocators. With the option that some allocators are flat-out incompatible. Your/Rob's idea to figure out the constraints wrt max number of segments in the sg_list can provide, like you said, maybe 80-90% of the allocation constraints hopefully. The opaque mask should help for the remaining 'crazy' cases, so I'll be glad to merge Rob's and my approach on defining the constraints. I should think a little bit more about the priority idea that you propose here (and in another patch), but atm I am unable to see how that could help solve the finding-out-constraints problem. - The big bummer imo with ION is that it fully side-steps, but this proposal here also seems to add entirely new allocators. My rough idea This proposal does borrow this bit from ION, but once we have the required changes done in the dma api itself, the allocators can just become shims to the dma api allocators (eg dma_alloc_coherent etc) for cases where they can be used directly, while leaving provision for any crazy platform-specific allocators, without the userspace having to worry about it. was that at allocate/attach time we iterate over all attached devices like in Rob's patch and compute the most constrained allocation requirements. Then we pick the underlying dma api allocator for these constraints. That probably means that we need to open up the dma api a bit. But I guess for a start we could simply try to allocate from the most constrained device. Together with the opaque bits you propose here we could even map additional crazy requirements like that an allocation must come from a specific memory bank (provided by a special-purpose CMA region). That might also mean that requirements are exclusive and no allocation is possible. My idea was a little variation on what you said here - rather than do compute the most constraint allocation 'after' devices have attached (and right now, we don't really have a way to know that - but that's another point), I'd proposed to do the compute on each attach request, so the requesting drivers can know immediately if the attachment will not work for the other currently attached devices. Well I said allocate/attach ;-) But yeah if we check at attach and reject anything that doesn't work then there's no need to check again when allocating, it /should/ work. But perhaps good to be paranoid and check again. - I'm not sure we should allow drivers to override the access constraint checks really - the dma_buf interfaces already provide this possibility through the -attach callback. In there exporters are allowed to reject the attachment for any reason whatsover. This override the access constraint check is again meant
Re: [PATCH/RFC v9 19/19] leds: aat1290: add support for V4L2 Flash sub-device
Hi Jacek,
On Wed, Dec 03, 2014 at 05:06:54PM +0100, Jacek Anaszewski wrote:
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...@linux.intel.com
---
drivers/leds/leds-aat1290.c | 61
+++
1 file changed, 61 insertions(+)
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index 15d969b..81a8f48 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -21,6 +21,7 @@
#include linux/gpio.h
#include linux/of_gpio.h
#include linux/of.h
+#include media/v4l2-flash.h
#include linux/workqueue.h
#define AAT1290_MOVIE_MODE_CURRENT_ADDR 17
@@ -63,6 +64,7 @@ struct aat1290_led {
struct mutex lock;
struct led_classdev_flash ldev;
+ struct v4l2_flash *v4l2_flash;
int flen_gpio;
int en_set_gpio;
@@ -280,11 +282,51 @@ static void aat1290_init_flash_settings(struct
aat1290_led *led,
setting-val = setting-max;
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+static void aat1290_init_v4l2_ctrl_config(struct aat1290_led_settings *s,
+ struct v4l2_flash_ctrl_config *config)
+{
+ struct led_flash_setting *setting;
+ struct v4l2_ctrl_config *c;
+
+ c = config-intensity;
+ setting = s-torch_brightness;
+ c-min = setting-min;
+ c-max = setting-max;
+ c-step = setting-step;
Hmm. How does the intensity get configured over the V4L2 controls? Based on
an earlier patch, the intensity control looks very much non-linear.
+ c-def = setting-val;
+
+ c = config-flash_timeout;
+ setting = s-flash_timeout;
+ c-min = setting-min;
+ c-max = setting-max;
+ c-step = setting-step;
+ c-def = setting-val;
+
+ config-has_external_strobe = false;
+}
+#else
+#define aat1290_init_v4l2_ctrl_config(s, config)
+#endif
+
static const struct led_flash_ops flash_ops = {
.strobe_set = aat1290_led_flash_strobe_set,
.timeout_set = aat1290_led_flash_timeout_set,
};
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+static const struct v4l2_flash_ops v4l2_flash_ops = {
+ .external_strobe_set = NULL,
+};
+
+static const struct v4l2_flash_ops *get_v4l2_flash_ops(void)
+{
+ return v4l2_flash_ops;
You can use v4l2_flash_ops directly, no need for a function to return them.
+}
+#else
+#define get_v4l2_flash_ops() (NULL)
+#endif
+
static int aat1290_led_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -292,6 +334,9 @@ static int aat1290_led_probe(struct platform_device *pdev)
struct aat1290_led *led;
struct led_classdev *led_cdev;
struct led_classdev_flash *flash;
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ struct v4l2_flash_ctrl_config v4l2_flash_config;
+#endif
struct aat1290_led_settings settings;
int flen_gpio, enset_gpio, ret;
@@ -344,6 +389,9 @@ static int aat1290_led_probe(struct platform_device *pdev)
flash-timeout = settings.flash_timeout;
+ /* Init V4L2 Flash controls basing on initialized settings */
+ aat1290_init_v4l2_ctrl_config(settings, v4l2_flash_config);
+
/* Init led class */
led_cdev = flash-led_cdev;
led_cdev-name = led-label;
@@ -361,8 +409,20 @@ static int aat1290_led_probe(struct platform_device
*pdev)
if (ret 0)
goto error_gpio_en_set;
+ /* Create V4L2 Flash subdev. */
+ led-v4l2_flash = v4l2_flash_init(flash,
+ get_v4l2_flash_ops(),
+ dev_node,
+ v4l2_flash_config);
Less newlines needed; up to you.
+ if (IS_ERR(led-v4l2_flash)) {
+ ret = PTR_ERR(led-v4l2_flash);
+ goto error_v4l2_flash_init;
+ }
+
return 0;
+error_v4l2_flash_init:
+ led_classdev_flash_unregister(flash);
error_gpio_en_set:
if (gpio_is_valid(enset_gpio))
gpio_free(enset_gpio);
@@ -378,6 +438,7 @@ static int aat1290_led_remove(struct platform_device
*pdev)
{
struct aat1290_led *led = platform_get_drvdata(pdev);
+ v4l2_flash_release(led-v4l2_flash);
led_classdev_flash_unregister(led-ldev);
cancel_work_sync(led-work_brightness_set);
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.20] Media cleanups
Hi Mauro, This patch series contains a bunch of cleanups: - Remove emacs editor comments throughout drivers/media - Switch last users of the deprecated get/set_crop pad ops to get/set_selection. - Drop obsolete get/set_crop and the unused enum_mbus_fmt ops. - Small Kconfig improvement. This used to be part of a 3.19 pull request, but that missed the cut, so here it is again for 3.20. Regards, Hans The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.20b for you to fetch changes up to 5579ceff0a6e2a8a6793302409c10f5968070d6a: media/i2c/Kconfig: drop superfluous MEDIA_CONTROLLER (2014-12-10 15:19:17 +0100) Hans Verkuil (5): media: remove emacs editor variables v4l2 subdevs: replace get/set_crop by get/set_selection v4l2-subdev: drop get/set_crop pad ops v4l2-subdev: drop unused op enum_mbus_fmt media/i2c/Kconfig: drop superfluous MEDIA_CONTROLLER Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml | 8 --- Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml | 8 --- drivers/media/common/btcx-risc.c | 6 - drivers/media/common/btcx-risc.h | 6 - drivers/media/dvb-frontends/au8522.h | 5 - drivers/media/dvb-frontends/lg2160.c | 6 - drivers/media/dvb-frontends/lgdt3305.c | 6 - drivers/media/dvb-frontends/lgdt330x.c | 6 - drivers/media/dvb-frontends/lgdt330x.h | 6 - drivers/media/dvb-frontends/lgdt330x_priv.h| 6 - drivers/media/dvb-frontends/nxt200x.h | 6 - drivers/media/dvb-frontends/or51132.c | 6 - drivers/media/dvb-frontends/or51132.h | 6 - drivers/media/dvb-frontends/s5h1409.c | 6 - drivers/media/dvb-frontends/s5h1409.h | 5 - drivers/media/dvb-frontends/s5h1411.c | 5 - drivers/media/dvb-frontends/s5h1411.h | 5 - drivers/media/i2c/Kconfig | 6 ++--- drivers/media/i2c/msp3400-driver.c | 8 --- drivers/media/i2c/mt9m032.c| 42 --- drivers/media/i2c/mt9p031.c| 41 +++--- drivers/media/i2c/mt9t001.c| 41 +++--- drivers/media/i2c/mt9v032.c| 43 +++ drivers/media/i2c/s5k6aa.c | 44 +--- drivers/media/pci/bt8xx/bt878.c| 6 - drivers/media/pci/bt8xx/bttv-cards.c | 7 -- drivers/media/pci/bt8xx/bttv-driver.c | 6 - drivers/media/pci/bt8xx/bttv-gpio.c| 6 - drivers/media/pci/bt8xx/bttv-if.c | 6 - drivers/media/pci/bt8xx/bttv-risc.c| 6 - drivers/media/pci/bt8xx/bttv-vbi.c | 7 -- drivers/media/pci/bt8xx/bttv.h | 5 - drivers/media/pci/bt8xx/bttvp.h| 6 - drivers/media/pci/cx88/cx88-core.c | 7 -- drivers/media/pci/cx88/cx88-mpeg.c | 7 -- drivers/media/pci/cx88/cx88-tvaudio.c | 7 -- drivers/media/tuners/mt20xx.c | 8 --- drivers/media/tuners/mt2131.c | 5 - drivers/media/tuners/mt2131.h | 5 - drivers/media/tuners/mt2131_priv.h | 5 - drivers/media/tuners/mxl5007t.c| 8 --- drivers/media/tuners/mxl5007t.h| 9 drivers/media/tuners/tda18271-fe.c | 8 --- drivers/media/tuners/tda18271-maps.c | 8 --- drivers/media/tuners/tda18271-priv.h | 8 --- drivers/media/tuners/tda827x.c | 8 --- drivers/media/tuners/tda8290.c | 8 --- drivers/media/tuners/tda9887.c | 8 --- drivers/media/tuners/tuner-simple.c| 8 --- drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c | 6 - drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h | 6
[PATCH for v3.19] sh_veu: v4l2_dev wasn't set
The v4l2_dev field of struct video_device must be set correctly. This was never done for this driver, so no video nodes were created anymore. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/sh_veu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c index be3b3bc..54cb88a 100644 --- a/drivers/media/platform/sh_veu.c +++ b/drivers/media/platform/sh_veu.c @@ -1179,6 +1179,7 @@ static int sh_veu_probe(struct platform_device *pdev) } *vdev = sh_veu_videodev; + vdev-v4l2_dev = veu-v4l2_dev; spin_lock_init(veu-lock); mutex_init(veu-fop_lock); vdev-lock = veu-fop_lock; -- 2.1.3 -- 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
LibV4L2 and CREATE_BUFS issues
Hi, we recently fixed our CREATE_BUFS support in GStreamer master. It works nicely with UVC drivers. The problem is that libv4l2 isn't aware of it, and endup taking terribly decision the least quickly lead to crash. I'm not sure what that right approach. It seems non-trivial to support it, at least it would require a bit more knowledge of the converter code and memory model. Maybe we should at least make sure that CREATE_BUF fails if we are doing conversion ? Some input on that would be appreciated. cheers, Nicolas -- 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] usb: hcd: get/put device and hcd for hcd_buffers()
* 'Greg Kroah-Hartman' | 2014-12-09 11:54:15 [-0500]: You can unbind the HCD driver from the PCI-device via sysfs and this is not something not only a developer does. This unbind calls the remove function of the driver and the only difference between unbind and rmmod is that the module remains inserted (but this is no news for you). If unbind causes a problem, it's the same problem that could happen if the hardware is hot-unplugged (like on a PCI card.) Stuff like that _does_ need to be fixed, and if your test shows this is a problem, I am all for fixing that. so I tried this with unbind and it didn't explode as assumed. On musb, for some reason the hcd struct never gets cleaned up. The driver free(s) URB memory after the hcd_pools are gone but since its size is 32KiB it uses dma_free_coherent() and this seems to work fine (sice the device is still there). So tried the same thing with EHCI. EHCI-hcd cleans up its HCD-struct as expected so I would have to poke at musb and figure out why it does not happen. Also, there is another difference: with EHCI I see first removal of buffers followed by removal of the pools. So it happens after disconnect but before the HCD pools are gone. I'm not sure why this happens with EHCI but not with MUSB. It seems that for some reason unbind triggers an error on /dev/video0 which makes gst-launch close that file. Once all users are gone, that hcd struct is cleaned up. Again, it works as I would expect it with EHCI but not with MUSB. So maybe, once I learned how MUSB dafeated the userspace notification about a gone device I might gain the same behavior that EHCI has. Also not freed hcd struct of musb looks also important :) thanks, greg k-h Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
randconfig build error with next-20141210, in drivers/media/usb/siano/smsusb.c
Building with the attached random configuration file, drivers/built-in.o: In function `smsusb_submit_urb': smsusb.c:(.text+0xa8fdc): undefined reference to `smscore_getbuffer' drivers/built-in.o: In function `smsusb_onresponse': smsusb.c:(.text+0xa902f): undefined reference to `smsendian_handle_message_header' smsusb.c:(.text+0xa909e): undefined reference to `smscore_translate_msg' smsusb.c:(.text+0xa90a5): undefined reference to `smsendian_handle_rx_message' smsusb.c:(.text+0xa90b0): undefined reference to `smscore_onresponse' drivers/built-in.o: In function `smsusb_stop_streaming': smsusb.c:(.text+0xa90f2): undefined reference to `smscore_putbuffer' drivers/built-in.o: In function `smsusb_term_device': smsusb.c:(.text+0xa922a): undefined reference to `smscore_unregister_device' drivers/built-in.o: In function `smsusb_sendrequest': smsusb.c:(.text+0xa9281): undefined reference to `smscore_translate_msg' smsusb.c:(.text+0xa9288): undefined reference to `smsendian_handle_tx_message' smsusb.c:(.text+0xa928f): undefined reference to `smsendian_handle_message_header' drivers/built-in.o: In function `smsusb_init_device': smsusb.c:(.text+0xa93de): undefined reference to `sms_get_board' smsusb.c:(.text+0xa94aa): undefined reference to `smscore_register_device' smsusb.c:(.text+0xa94c0): undefined reference to `smscore_set_board_id' smsusb.c:(.text+0xa9512): undefined reference to `smscore_start_device' drivers/built-in.o: In function `smsusb_probe': smsusb.c:(.text+0xa9550): undefined reference to `sms_get_board' smsusb.c:(.text+0xa9575): undefined reference to `sms_get_board' smsusb.c:(.text+0xa964b): undefined reference to `smscore_registry_getmode' smsusb.c:(.text+0xa9658): undefined reference to `sms_get_board' smsusb.c:(.text+0xa966e): undefined reference to `sms_get_board' smsusb.c:(.text+0xa972b): undefined reference to `sms_board_load_modules' make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.18.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_INTEL_MPX=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y
[REVIEW PATCH 7/7] smiapp: Add parentheses to macro arguments used in macros
This makes the macros a little bit safer. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/media/i2c/smiapp/smiapp-quirk.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.h b/drivers/media/i2c/smiapp/smiapp-quirk.h index a24eb43..dac5566 100644 --- a/drivers/media/i2c/smiapp/smiapp-quirk.h +++ b/drivers/media/i2c/smiapp/smiapp-quirk.h @@ -72,14 +72,14 @@ void smiapp_replace_limit(struct smiapp_sensor *sensor, .val = _val,\ } -#define smiapp_call_quirk(_sensor, _quirk, ...) \ - (_sensor-minfo.quirk \ -_sensor-minfo.quirk-_quirk ? \ -_sensor-minfo.quirk-_quirk(_sensor, ##__VA_ARGS__) : 0) +#define smiapp_call_quirk(sensor, _quirk, ...) \ + ((sensor)-minfo.quirk\ +(sensor)-minfo.quirk-_quirk ?\ +(sensor)-minfo.quirk-_quirk(sensor, ##__VA_ARGS__) : 0) -#define smiapp_needs_quirk(_sensor, _quirk)\ - (_sensor-minfo.quirk ? \ -_sensor-minfo.quirk-flags _quirk : 0) +#define smiapp_needs_quirk(sensor, _quirk) \ + ((sensor)-minfo.quirk ?\ +(sensor)-minfo.quirk-flags _quirk : 0) extern const struct smiapp_quirk smiapp_jt8ev1_quirk; extern const struct smiapp_quirk smiapp_imx125es_quirk; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 5/7] smiapp: Move enumerating available media bus codes later
As the controls creation is separated in two sections, the available media
bus codes and link frequencies can be enumerated later on.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index e8e88bd..bacef3e 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2703,12 +2703,6 @@ static int smiapp_init(struct smiapp_sensor *sensor)
if (sensor-minfo.smiapp_profile == SMIAPP_PROFILE_0)
pll-flags |= SMIAPP_PLL_FLAG_NO_OP_CLOCKS;
- rval = smiapp_get_mbus_formats(sensor);
- if (rval) {
- rval = -ENODEV;
- goto out_cleanup;
- }
-
for (i = 0; i SMIAPP_SUBDEVS; i++) {
struct {
struct smiapp_subdev *ssd;
@@ -2778,6 +2772,12 @@ static int smiapp_init(struct smiapp_sensor *sensor)
if (rval 0)
goto out_cleanup;
+ rval = smiapp_get_mbus_formats(sensor);
+ if (rval) {
+ rval = -ENODEV;
+ goto out_cleanup;
+ }
+
rval = smiapp_init_late_controls(sensor);
if (rval) {
rval = -ENODEV;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 4/7] smiapp: Separate late controls from the rest
The default values and limits for certain controls need the knowledge of
available media bus codes or link frequencies. Create such controls later
on, so that most of the initialisation of the sensor has already been done
when the init quirk is called.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c | 54 +---
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 66d94c3..e8e88bd 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -519,9 +519,6 @@ static const struct v4l2_ctrl_ops smiapp_ctrl_ops = {
static int smiapp_init_controls(struct smiapp_sensor *sensor)
{
struct i2c_client *client = v4l2_get_subdevdata(sensor-src-sd);
- unsigned long *valid_link_freqs = sensor-valid_link_freqs[
- sensor-csi_format-compressed - SMIAPP_COMPRESSED_BASE];
- unsigned int max, i;
int rval;
rval = v4l2_ctrl_handler_init(sensor-pixel_array-ctrl_handler, 12);
@@ -573,15 +570,6 @@ static int smiapp_init_controls(struct smiapp_sensor
*sensor)
ARRAY_SIZE(smiapp_test_patterns) - 1,
0, 0, smiapp_test_patterns);
- for (i = 0; i ARRAY_SIZE(sensor-test_data); i++) {
- int max_value = (1 sensor-csi_format-width) - 1;
- sensor-test_data[i] =
- v4l2_ctrl_new_std(
- sensor-pixel_array-ctrl_handler,
- smiapp_ctrl_ops, V4L2_CID_TEST_PATTERN_RED + i,
- 0, max_value, 1, max_value);
- }
-
if (sensor-pixel_array-ctrl_handler.error) {
dev_err(client-dev,
pixel array controls initialization failed (%d)\n,
@@ -600,13 +588,6 @@ static int smiapp_init_controls(struct smiapp_sensor
*sensor)
sensor-src-ctrl_handler.lock = sensor-mutex;
- for (max = 0; sensor-platform_data-op_sys_clock[max + 1]; max++);
-
- sensor-link_freq = v4l2_ctrl_new_int_menu(
- sensor-src-ctrl_handler, smiapp_ctrl_ops,
- V4L2_CID_LINK_FREQ, __fls(*valid_link_freqs),
- __ffs(*valid_link_freqs), sensor-platform_data-op_sys_clock);
-
sensor-pixel_rate_csi = v4l2_ctrl_new_std(
sensor-src-ctrl_handler, smiapp_ctrl_ops,
V4L2_CID_PIXEL_RATE, 1, INT_MAX, 1, 1);
@@ -623,6 +604,35 @@ static int smiapp_init_controls(struct smiapp_sensor
*sensor)
return 0;
}
+/*
+ * For controls that require information on available media bus codes
+ * and linke frequencies.
+ */
+static int smiapp_init_late_controls(struct smiapp_sensor *sensor)
+{
+ unsigned long *valid_link_freqs = sensor-valid_link_freqs[
+ sensor-csi_format-compressed - SMIAPP_COMPRESSED_BASE];
+ unsigned int max, i;
+
+ for (i = 0; i ARRAY_SIZE(sensor-test_data); i++) {
+ int max_value = (1 sensor-csi_format-width) - 1;
+ sensor-test_data[i] =
+ v4l2_ctrl_new_std(
+ sensor-pixel_array-ctrl_handler,
+ smiapp_ctrl_ops, V4L2_CID_TEST_PATTERN_RED + i,
+ 0, max_value, 1, max_value);
+ }
+
+ for (max = 0; sensor-platform_data-op_sys_clock[max + 1]; max++);
+
+ sensor-link_freq = v4l2_ctrl_new_int_menu(
+ sensor-src-ctrl_handler, smiapp_ctrl_ops,
+ V4L2_CID_LINK_FREQ, __fls(*valid_link_freqs),
+ __ffs(*valid_link_freqs), sensor-platform_data-op_sys_clock);
+
+ return sensor-src-ctrl_handler.error;
+}
+
static void smiapp_free_controls(struct smiapp_sensor *sensor)
{
unsigned int i;
@@ -2768,6 +2778,12 @@ static int smiapp_init(struct smiapp_sensor *sensor)
if (rval 0)
goto out_cleanup;
+ rval = smiapp_init_late_controls(sensor);
+ if (rval) {
+ rval = -ENODEV;
+ goto out_cleanup;
+ }
+
mutex_lock(sensor-mutex);
rval = smiapp_update_mode(sensor);
mutex_unlock(sensor-mutex);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 2/7] smiapp: Free control handlers in sub-device cleanup
From: Sakari Ailus sakari.ai...@linux.intel.com
Also call smiapp_cleanup() in smiapp_remove(), replacing code that did the
same than the function.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 4f36be5..72a0de6 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2522,6 +2522,8 @@ static void smiapp_cleanup(struct smiapp_sensor *sensor)
device_remove_file(client-dev, dev_attr_nvm);
device_remove_file(client-dev, dev_attr_ident);
+
+ smiapp_free_controls(sensor);
}
static int smiapp_init(struct smiapp_sensor *sensor)
@@ -3124,15 +3126,11 @@ static int smiapp_remove(struct i2c_client *client)
sensor-power_count = 0;
}
- device_remove_file(client-dev, dev_attr_ident);
- if (sensor-nvm)
- device_remove_file(client-dev, dev_attr_nvm);
-
for (i = 0; i sensor-ssds_used; i++) {
v4l2_device_unregister_subdev(sensor-ssds[i].sd);
media_entity_cleanup(sensor-ssds[i].sd.entity);
}
- smiapp_free_controls(sensor);
+ smiapp_cleanup(sensor);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 3/7] smiapp: Clean up smiapp_init_controls()
Clean up smiapp_init_controls() by adding newlines to appropriate places and by removing superfluous error handling. The caller will clean up control handlers in any case if the function fails. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com --- drivers/media/i2c/smiapp/smiapp-core.c | 19 ++- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index 72a0de6..66d94c3 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -527,6 +527,7 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) rval = v4l2_ctrl_handler_init(sensor-pixel_array-ctrl_handler, 12); if (rval) return rval; + sensor-pixel_array-ctrl_handler.lock = sensor-mutex; sensor-analog_gain = v4l2_ctrl_new_std( @@ -585,8 +586,7 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) dev_err(client-dev, pixel array controls initialization failed (%d)\n, sensor-pixel_array-ctrl_handler.error); - rval = sensor-pixel_array-ctrl_handler.error; - goto error; + return sensor-pixel_array-ctrl_handler.error; } sensor-pixel_array-sd.ctrl_handler = @@ -596,7 +596,8 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) rval = v4l2_ctrl_handler_init(sensor-src-ctrl_handler, 0); if (rval) - goto error; + return rval; + sensor-src-ctrl_handler.lock = sensor-mutex; for (max = 0; sensor-platform_data-op_sys_clock[max + 1]; max++); @@ -614,20 +615,12 @@ static int smiapp_init_controls(struct smiapp_sensor *sensor) dev_err(client-dev, src controls initialization failed (%d)\n, sensor-src-ctrl_handler.error); - rval = sensor-src-ctrl_handler.error; - goto error; + return sensor-src-ctrl_handler.error; } - sensor-src-sd.ctrl_handler = - sensor-src-ctrl_handler; + sensor-src-sd.ctrl_handler = sensor-src-ctrl_handler; return 0; - -error: - v4l2_ctrl_handler_free(sensor-pixel_array-ctrl_handler); - v4l2_ctrl_handler_free(sensor-src-ctrl_handler); - - return rval; } static void smiapp_free_controls(struct smiapp_sensor *sensor) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 6/7] smiapp: Replace pll_flags quirk with more generic init quirk
From: Sakari Ailus sakari.ai...@linux.intel.com
The pll_flags quirk just returned the extra PLL flags the sensor required,
but the init quirk is far more versatile. It can be used to perform any
extra initialisation needed by the sensor, including allocating memory for
sensor specific struct and creating sensor specific new controls.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c |5 -
drivers/media/i2c/smiapp/smiapp-quirk.c |8 +---
drivers/media/i2c/smiapp/smiapp-quirk.h |4
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index bacef3e..737da1e 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2697,7 +2697,6 @@ static int smiapp_init(struct smiapp_sensor *sensor)
pll-bus_type = SMIAPP_PLL_BUS_TYPE_CSI2;
pll-csi2.lanes = sensor-platform_data-lanes;
pll-ext_clk_freq_hz = sensor-platform_data-ext_clk;
- pll-flags = smiapp_call_quirk(sensor, pll_flags);
pll-scale_n = sensor-limits[SMIAPP_LIMIT_SCALER_N_MIN];
/* Profile 0 sensors have no separate OP clock branch. */
if (sensor-minfo.smiapp_profile == SMIAPP_PROFILE_0)
@@ -2772,6 +2771,10 @@ static int smiapp_init(struct smiapp_sensor *sensor)
if (rval 0)
goto out_cleanup;
+ rval = smiapp_call_quirk(sensor, init);
+ if (rval)
+ goto out_cleanup;
+
rval = smiapp_get_mbus_formats(sensor);
if (rval) {
rval = -ENODEV;
diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.c
b/drivers/media/i2c/smiapp/smiapp-quirk.c
index dd4ae6f..abf9ea7 100644
--- a/drivers/media/i2c/smiapp/smiapp-quirk.c
+++ b/drivers/media/i2c/smiapp/smiapp-quirk.c
@@ -214,9 +214,11 @@ static int jt8ev1_post_streamoff(struct smiapp_sensor
*sensor)
return smiapp_write_8(sensor, 0x3328, 0x80);
}
-static unsigned long jt8ev1_pll_flags(struct smiapp_sensor *sensor)
+static int jt8ev1_init(struct smiapp_sensor *sensor)
{
- return SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE;
+ sensor-pll.flags |= SMIAPP_PLL_FLAG_OP_PIX_CLOCK_PER_LANE;
+
+ return 0;
}
const struct smiapp_quirk smiapp_jt8ev1_quirk = {
@@ -224,7 +226,7 @@ const struct smiapp_quirk smiapp_jt8ev1_quirk = {
.post_poweron = jt8ev1_post_poweron,
.pre_streamon = jt8ev1_pre_streamon,
.post_streamoff = jt8ev1_post_streamoff,
- .pll_flags = jt8ev1_pll_flags,
+ .init = jt8ev1_init,
};
static int tcm8500md_limits(struct smiapp_sensor *sensor)
diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.h
b/drivers/media/i2c/smiapp/smiapp-quirk.h
index 3a3c3e5..a24eb43 100644
--- a/drivers/media/i2c/smiapp/smiapp-quirk.h
+++ b/drivers/media/i2c/smiapp/smiapp-quirk.h
@@ -29,6 +29,9 @@ struct smiapp_sensor;
* @post_poweron: Called always after the sensor has been fully powered on.
* @pre_streamon: Called just before streaming is enabled.
* @post_streamon: Called right after stopping streaming.
+ * @pll_flags: Return flags for the PLL calculator.
+ * @init: Quirk initialisation, called the last in probe(). This is
+ * also appropriate for adding sensor specific controls, for instance.
* @reg_access: Register access quirk. The quirk may divert the access
* to another register, or no register at all.
*
@@ -47,6 +50,7 @@ struct smiapp_quirk {
int (*pre_streamon)(struct smiapp_sensor *sensor);
int (*post_streamoff)(struct smiapp_sensor *sensor);
unsigned long (*pll_flags)(struct smiapp_sensor *sensor);
+ int (*init)(struct smiapp_sensor *sensor);
int (*reg_access)(struct smiapp_sensor *sensor, bool write, u32 *reg,
u32 *val);
unsigned long flags;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 1/7] smiapp: Access flash capabilities through limits
From: Sakari Ailus sakari.ai...@linux.intel.com
The flash capability register is already read as part of the limit
registers. Do no access it separately; instead use the value from the
limits.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/i2c/smiapp/smiapp-core.c |9 +
drivers/media/i2c/smiapp/smiapp.h |1 -
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 48e1a1f..4f36be5 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -1483,7 +1483,7 @@ static int smiapp_start_streaming(struct smiapp_sensor
*sensor)
if (rval 0)
goto out;
- if ((sensor-flash_capability
+ if ((sensor-limits[SMIAPP_LIMIT_FLASH_MODE_CAPABILITY]
(SMIAPP_FLASH_MODE_CAPABILITY_SINGLE_STROBE |
SMIAPP_FLASH_MODE_CAPABILITY_MULTIPLE_STROBE))
sensor-platform_data-strobe_setup != NULL
@@ -2529,7 +2529,6 @@ static int smiapp_init(struct smiapp_sensor *sensor)
struct i2c_client *client = v4l2_get_subdevdata(sensor-src-sd);
struct smiapp_pll *pll = sensor-pll;
struct smiapp_subdev *last = NULL;
- u32 tmp;
unsigned int i;
int rval;
@@ -2785,12 +2784,6 @@ static int smiapp_init(struct smiapp_sensor *sensor)
sensor-streaming = false;
sensor-dev_init_done = true;
- /* check flash capability */
- rval = smiapp_read(sensor, SMIAPP_REG_U8_FLASH_MODE_CAPABILITY, tmp);
- sensor-flash_capability = tmp;
- if (rval)
- goto out_cleanup;
-
smiapp_power_off(sensor);
return 0;
diff --git a/drivers/media/i2c/smiapp/smiapp.h
b/drivers/media/i2c/smiapp/smiapp.h
index 8fded46..ed010a8 100644
--- a/drivers/media/i2c/smiapp/smiapp.h
+++ b/drivers/media/i2c/smiapp/smiapp.h
@@ -216,7 +216,6 @@ struct smiapp_sensor {
u8 scaling_mode;
u8 hvflip_inv_mask; /* H/VFLIP inversion due to sensor orientation */
- u8 flash_capability;
u8 frame_skip;
int power_count;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 0/7] smiapp: Cleanups, small bugfixes
Hi, These patches contain cleanups, primarily in the sensor initialisation, and replace the pll_flags quirk by a generic init quirk which, besides setting pll flags, can be used to e.g. creating sensor specific controls. -- Kind regards, Sakari -- 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
VPU on iMX51 babbage board
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following
these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed
v4l-coda7541-imx53.bin in /lib/firmware
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt
of writing in VPU address space in the function coda_write of file
driver/media/platform/coda/coda-common.c
Is there anything preventing the coda driver to work with iMX51?
Could anyone provide any suggestion on how investigate the problem?
Thanks
Regards
Pierluigi
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index 56569ce..e8b372b 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -44,6 +44,7 @@
interface-pix-fmt = rgb24;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp1;
+ status = disabled;
display-timings {
native-mode = timing0;
timing0: dvi {
@@ -71,7 +72,6 @@
interface-pix-fmt = rgb565;
pinctrl-names = default;
pinctrl-0 = pinctrl_ipu_disp2;
- status = disabled;
display-timings {
native-mode = timing1;
timing1: claawvga {
@@ -338,6 +338,10 @@
status = okay;
};
+vpu {
+ status = okay;
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = pinctrl_i2c1;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 92660e1..ce82b1f 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -143,9 +143,17 @@
};
ipu_di1: port@3 {
+#address-cells = 1;
+#size-cells = 0;
reg = 3;
-ipu_di1_disp1: endpoint {
+ipu_di1_disp1: endpoint@0 {
+ reg = 0;
+};
+
+ipu_di1_tve: endpoint@2 {
+ reg = 2;
+ remote-endpoint = tve_in;
};
};
};
@@ -578,6 +586,33 @@
clock-names = ipg, ahb, ptp;
status = disabled;
};
+
+ tve: tve@83ff {
+compatible = fsl,imx53-tve;
+reg = 0x83ff 0x1000;
+interrupts = 92;
+clocks = clks IMX5_CLK_TVE_GATE,
+ clks IMX5_CLK_IPU_DI1_SEL;
+clock-names = tve, di1_sel;
+status = disabled;
+
+port {
+ tve_in: endpoint {
+ remote-endpoint = ipu_di1_tve;
+ };
+};
+ };
+
+ vpu: vpu@83ff4000 {
+compatible = fsl,imx53-vpu;
+reg = 0x83ff4000 0x1000;
+interrupts = 9;
+clocks = clks IMX5_CLK_VPU_REFERENCE_GATE,
+ clks IMX5_CLK_VPU_GATE;
+clock-names = per, ahb;
+resets = src 1;
+iram = iram;
+ };
};
};
};
CONFIG_KERNEL_LZO=y
CONFIG_SYSVIPC=y
CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_CGROUPS=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MXC=y
CONFIG_MACH_MX31LILLY=y
CONFIG_MACH_MX31LITE=y
CONFIG_MACH_PCM037=y
CONFIG_MACH_PCM037_EET=y
CONFIG_MACH_MX31_3DS=y
CONFIG_MACH_MX31MOBOARD=y
CONFIG_MACH_QONG=y
CONFIG_MACH_ARMADILLO5X0=y
CONFIG_MACH_KZM_ARM11_01=y
CONFIG_MACH_IMX31_DT=y
CONFIG_MACH_IMX35_DT=y
CONFIG_MACH_PCM043=y
CONFIG_MACH_MX35_3DS=y
CONFIG_MACH_VPR200=y
CONFIG_SOC_IMX50=y
CONFIG_SOC_IMX51=y
CONFIG_SOC_IMX53=y
CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_VF610=y
CONFIG_PCI=y
CONFIG_PCI_IMX6=y
CONFIG_SMP=y
CONFIG_VMSPLIT_2G=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_CMA=y
CONFIG_CMDLINE=noinitrd console=ttymxc0,115200
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_BINFMT_MISC=m
CONFIG_PM_RUNTIME=y
CONFIG_PM_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_IPV6=y
CONFIG_NETFILTER=y
CONFIG_CAN=y
CONFIG_CAN_FLEXCAN=y
CONFIG_CFG80211=y
CONFIG_MAC80211=y
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_DMA_CMA=y
CONFIG_IMX_WEIM=y
CONFIG_CONNECTOR=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SST25L=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_GPMI_NAND=y
CONFIG_MTD_NAND_MXC=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_AT25=y
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
[PATCH v4 2/2] staging: media: lirc: lirc_zilog.c: keep consistency in dev functions
The previous patch switched some dev functions to move the string to a second
line. Doing this for all similar functions because it makes the driver easier
to read if all similar lines use the same criteria.
Signed-off-by: Luis de Bethencourt l...@debethencourt.com
---
drivers/staging/media/lirc/lirc_zilog.c | 57 ++---
1 file changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 8814a7e..27464da 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -369,7 +369,7 @@ static int add_to_buf(struct IR *ir)
ret = i2c_master_send(rx-c, sendbuf, 1);
if (ret != 1) {
dev_err(ir-l.dev, i2c_master_send failed with %d\n,
- ret);
+ ret);
if (failures = 3) {
mutex_unlock(ir-ir_lock);
dev_err(ir-l.dev,
@@ -412,8 +412,9 @@ static int add_to_buf(struct IR *ir)
rx-b[0] = keybuf[3];
rx-b[1] = keybuf[4];
rx-b[2] = keybuf[5];
- dev_dbg(ir-l.dev, key (0x%02x/0x%02x)\n,
- rx-b[0], rx-b[1]);
+ dev_dbg(ir-l.dev,
+ key (0x%02x/0x%02x)\n,
+ rx-b[0], rx-b[1]);
}
/* key pressed ? */
@@ -657,8 +658,8 @@ static int send_data_block(struct IR_tx *tx, unsigned char
*data_block)
dev_dbg(tx-ir-l.dev, %*ph, 5, buf);
ret = i2c_master_send(tx-c, buf, tosend + 1);
if (ret != tosend + 1) {
- dev_err(tx-ir-l.dev, i2c_master_send failed with
%d\n,
- ret);
+ dev_err(tx-ir-l.dev,
+ i2c_master_send failed with %d\n, ret);
return ret 0 ? ret : -EFAULT;
}
i += tosend;
@@ -711,7 +712,7 @@ static int send_boot_data(struct IR_tx *tx)
}
if ((buf[0] != 0x80) (buf[0] != 0xa0)) {
dev_err(tx-ir-l.dev, unexpected IR TX init response: %02x\n,
- buf[0]);
+ buf[0]);
return 0;
}
dev_notice(tx-ir-l.dev,
@@ -763,8 +764,9 @@ static int fw_load(struct IR_tx *tx)
/* Request codeset data file */
ret = request_firmware(fw_entry, haup-ir-blaster.bin, tx-ir-l.dev);
if (ret != 0) {
- dev_err(tx-ir-l.dev, firmware haup-ir-blaster.bin not
available (%d)\n,
- ret);
+ dev_err(tx-ir-l.dev,
+ firmware haup-ir-blaster.bin not available (%d)\n,
+ ret);
ret = ret 0 ? ret : -EFAULT;
goto out;
}
@@ -814,7 +816,7 @@ static int fw_load(struct IR_tx *tx)
goto corrupt;
dev_dbg(tx-ir-l.dev, %u IR blaster codesets loaded\n,
- tx_data-num_code_sets);
+ tx_data-num_code_sets);
tx_data-code_sets = vmalloc(
tx_data-num_code_sets * sizeof(char *));
@@ -944,8 +946,9 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
unsigned char buf[MAX_XFER_SIZE];
if (rbuf-chunk_size sizeof(buf)) {
- dev_err(ir-l.dev, chunk_size is too big
(%d)!\n,
- rbuf-chunk_size);
+ dev_err(ir-l.dev,
+ chunk_size is too big (%d)!\n,
+ rbuf-chunk_size);
ret = -EINVAL;
break;
}
@@ -968,8 +971,8 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
put_ir_rx(rx, false);
set_current_state(TASK_RUNNING);
- dev_dbg(ir-l.dev, read result = %d (%s)\n,
- ret, ret ? Error : OK);
+ dev_dbg(ir-l.dev, read result = %d (%s)\n, ret,
+ ret ? Error : OK);
return ret ? ret : written;
}
@@ -1081,7 +1084,7 @@ static int send_code(struct IR_tx *tx, unsigned int code,
unsigned int key)
}
if (buf[0] != 0x80) {
dev_err(tx-ir-l.dev, unexpected IR TX response #2: %02x\n,
- buf[0]);
+ buf[0]);
return -EFAULT;
}
@@ -1233,7 +1236,7 @@ static unsigned int poll(struct file *filep, poll_table
*wait)
ret = lirc_buffer_empty(rbuf) ? 0 : (POLLIN|POLLRDNORM);
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
Hi Pavel and Jacek, On Tue, Dec 09, 2014 at 04:50:33PM +0100, Pavel Machek wrote: On Tue 2014-12-09 09:54:06, Jacek Anaszewski wrote: Hi Pavel, On 12/08/2014 09:18 PM, Pavel Machek wrote: On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe read is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. No, semantics should be same for all devices. If device clears fault register during I2C readout, kernel will simply gather faults in an variable, and clear them upon write to sysfs file. This approach would require implementing additional mechanisms on both sides: LED Flash class core and a LED Flash class driver. In the former the sysfs attribute write permissions would have to be decided in the runtime and in the latter caching mechanism Write attributes at runtime? Why? We can emulate sane and consistent behaviour for all the controllers: read gives you list of faults, write clears it. We can do it for all the controllers. Only cost is few lines of code in the drivers where hardware clears faults at read. Please take the time to read this, and consider it. I'd say the cost is I2C register access, not so much a few lines added to the drivers. The functionality and behaviour between the flash controllers varies. They have different faults, presence of (some) faults may prevent strobing, some support reading the flash status and some don't. Some of the flash faults are mostly relevant in production testing, some can be used to find hardware issues during use (rare) and some are produced in common use (timeout, for instance). The V4L2 flash API defines that reading the faults clears them, but does not state whether presence of faults would prevent further use of the flash. This is flash controller chip specific. I think you *could* force a policy on the level of kernel API, for instance require that the user clears the faults before strobing again rather than relying on the chip requiring this instead. Most of the time there are no faults. When there are, they may appear at some point of time after the strobing, but how long? Probably roughly after the timeout period the flash should have faults available if there were any --- except if the strobe is external such as a sensor timed strobe. In that case the software running on the CPU has no knowledge when the flash is strobed nor when the faults should be read. So the requirement of checking the faults would probably have to be limited to software strobe only. The user would still have to be able to check the faults for externally strobed pulses. Would it be acceptable that the interface was different there? So, after the user has strobed, when the user should check the flash faults? After the timeout period has passed? Right before strobing again? If this was a requirement, it adds an additional I2C access to potentially the place which should absolutely have no extra delay --- the flash strobe time. This would be highly unwanted. The faults seldom happened in regular use, but more recent flash controllers have LED overtemperature or undervoltage faults, the latter of which isn't really a fault, but status information telling that the flash current will be limited. Reading the faults in this case is more important than it has used to be. Finally, should the LED flash class enforce such a policy, would the V4L2 flash API which is provided to the same devices be changed as well? I'm not against that if we have 1) can come up with a good policy that is understood to be meaningful for all thinkable flash controller implementations and 2) agreement the behaviour can be changed. Btw. I think I'm slightly leaning towards liking flash faults in form of strings
Re: [PATCH v4 1/2] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines
On Wed, 2014-12-10 at 22:33 +, Luis de Bethencourt wrote:
checkpatch makes an exception to the 80-colum rule for quotes strings, and
Documentation/CodingStyle recommends not splitting quotes strings across lines
because it breaks the ability to grep for the string. Fixing these.
[]
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
[]
@@ -794,9 +796,9 @@ static int fw_load(struct IR_tx *tx)
if (!read_uint8(data, tx_data-endp, version))
goto corrupt;
if (version != 1) {
- dev_err(tx-ir-l.dev, unsupported code set file version (%u,
expected
- 1) -- please upgrade to a newer driver,
- version);
+ dev_err(tx-ir-l.dev,
+ unsupported code set file version (%u, expected 1) --
please upgrade to a newer driver,
+ version);
Unrelated but this one should have a '\n' termination
at the end of the format.
--
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] uvcvideo: Add GUID for BGR 8:8:8
Hi William,
Thank you for the patch.
On Monday 08 December 2014 18:57:58 William Manley wrote:
The Magewell XI100DUSB-HDMI[1] video capture device reports the pixel
format e436eb7d-524f-11ce-9f53-0020af0ba770. This is its GUID for
BGR 8:8:8.
The UVC 1.5 spec[2] only defines GUIDs for YUY2, NV12, M420 and I420.
This seems to be an extension documented in the Microsoft Windows Media
Format SDK[3] - or at least the Media Format SDK was the only hit that
Google gave when searching for the GUID. This Media Format SDK defines
this GUID as corresponding to `MEDIASUBTYPE_RGB24`. Note though, the
XI100DUSB outputs BGR e.g. byte-reversed. I don't know if its the
capture device in error or Microsoft mean BGR when they say RGB.
I believe Microsoft defines RGB as BGR. They do at least in BMP
(https://en.wikipedia.org/wiki/BMP_file_format), probably because they
consider the RGB pixel to be stored in little-endian format.
[1]:
http://www.magewell.com/hardware/dongles/xi100dusb-hdmi/xi100dusb-hdmi_feat
ures.html?lang=en [2]:
http://www.usb.org/developers/docs/devclass_docs/USB_Video_Class_1_5.zip
[3]:
http://msdn.microsoft.com/en-gb/library/windows/desktop/dd757532(v=vs.85).a
spx
Signed-off-by: William Manley w...@williammanley.net
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I'll apply the patch to my tree and submit it for v3.20.
Could you please send me the output of 'lsusb -v' for your device, if possible
running as root ?
---
drivers/media/usb/uvc/uvc_driver.c | 5 +
drivers/media/usb/uvc/uvcvideo.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c index 7c8322d..dc7cff1 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -138,6 +138,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.fcc= V4L2_PIX_FMT_RGB565,
},
{
+ .name = BGR 8:8:8 (BGR3),
+ .guid = UVC_GUID_FORMAT_BGR3,
+ .fcc= V4L2_PIX_FMT_BGR24,
+ },
+ {
.name = H.264,
.guid = UVC_GUID_FORMAT_H264,
.fcc= V4L2_PIX_FMT_H264,
diff --git a/drivers/media/usb/uvc/uvcvideo.h
b/drivers/media/usb/uvc/uvcvideo.h index 864ada7..ed0210d 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -109,6 +109,9 @@
#define UVC_GUID_FORMAT_RGBP \
{ 'R', 'G', 'B', 'P', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_BGR3 \
+ { 0x7d, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \
+ 0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70}
#define UVC_GUID_FORMAT_M420 \
{ 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
--
Regards,
Laurent Pinchart
--
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 v4 1/2] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines
On Wed, Dec 10, 2014 at 03:39:09PM -0800, Joe Perches wrote:
On Wed, 2014-12-10 at 22:33 +, Luis de Bethencourt wrote:
checkpatch makes an exception to the 80-colum rule for quotes strings, and
Documentation/CodingStyle recommends not splitting quotes strings across
lines
because it breaks the ability to grep for the string. Fixing these.
[]
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
[]
@@ -794,9 +796,9 @@ static int fw_load(struct IR_tx *tx)
if (!read_uint8(data, tx_data-endp, version))
goto corrupt;
if (version != 1) {
- dev_err(tx-ir-l.dev, unsupported code set file version (%u,
expected
- 1) -- please upgrade to a newer driver,
- version);
+ dev_err(tx-ir-l.dev,
+ unsupported code set file version (%u, expected 1) --
please upgrade to a newer driver,
+ version);
Unrelated but this one should have a '\n' termination
at the end of the format.
I can add that change, no problem. As part of this patch or a third one?
Thanks for reviewing,
Luis
--
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 v4 1/2] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines
On Wed, 2014-12-10 at 23:57 +, Luis de Bethencourt wrote: On Wed, Dec 10, 2014 at 03:39:09PM -0800, Joe Perches wrote: On Wed, 2014-12-10 at 22:33 +, Luis de Bethencourt wrote: diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c [] + dev_err(tx-ir-l.dev, + unsupported code set file version (%u, expected 1) -- please upgrade to a newer driver, + version); Unrelated but this one should have a '\n' termination at the end of the format. I can add that change, no problem. As part of this patch or a third one? Up to you. -- 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: VPU on iMX51 babbage board
On Wed, Dec 10, 2014 at 7:54 PM, Pierluigi Passaro
pierluigi.pass...@phoenixsoftware.it wrote:
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these
steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed
v4l-coda7541-imx53.bin in /lib/firmware
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of
writing in VPU address space in the function coda_write of file
driver/media/platform/coda/coda-common.c
Is there anything preventing the coda driver to work with iMX51?
Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsi you would need this:
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -121,6 +121,7 @@
iram: iram@1ffe {
compatible = mmio-sram;
reg = 0x1ffe 0x2;
+clocks = clks IMX5_CLK_OCRAM;
};
ipu: ipu@4000 {
@@ -584,6 +585,18 @@
clock-names = ipg, ahb, ptp;
status = disabled;
};
+
+vpu: vpu@83ff4000 {
+compatible = fsl,imx53-vpu;
+reg = 0x83ff4000 0x1000;
+interrupts = 9;
+clocks = clks IMX5_CLK_VPU_REFERENCE_GATE,
+ clks IMX5_CLK_VPU_GATE;
+clock-names = per, ahb;
+resets = src 1;
+iram = iram;
+};
};
+
};
};
Also, not sure if all the required coda patches are available in
3.18, so I tried it on linux-next 20141210 on a imx51-babbage (I had
to disable USB, otherwise linux-next will hang on this board):
[1.368454] coda 83ff4000.vpu: Initialized CODA7541.
[1.373572] coda 83ff4000.vpu: Firmware version: 1.4.50
[1.396695] coda 83ff4000.vpu: codec registered as /dev/video[0-3]
Also, no sure if we need to distinguish mx51 versus mx53 in the coda driver.
Adding Philipp in case he can comment.
Regards,
Fabio Estevam
--
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 v4 1/2] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines
On Wed, Dec 10, 2014 at 04:01:04PM -0800, Joe Perches wrote: On Wed, 2014-12-10 at 23:57 +, Luis de Bethencourt wrote: On Wed, Dec 10, 2014 at 03:39:09PM -0800, Joe Perches wrote: On Wed, 2014-12-10 at 22:33 +, Luis de Bethencourt wrote: diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c [] + dev_err(tx-ir-l.dev, + unsupported code set file version (%u, expected 1) -- please upgrade to a newer driver, + version); Unrelated but this one should have a '\n' termination at the end of the format. I can add that change, no problem. As part of this patch or a third one? Up to you. I like keeping my patches divided in functional units. Resubmitting these patches as v5 with your suggestion as the third one, since it needs to be applied on top of the other 2. Thanks Joe! Luis -- 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 v5 1/3] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines
checkpatch makes an exception to the 80-colum rule for quotes strings, and
Documentation/CodingStyle recommends not splitting quotes strings across lines
because it breaks the ability to grep for the string. Fixing these.
WARNING: quoted string split across lines
Signed-off-by: Luis de Bethencourt l...@debethencourt.com
---
drivers/staging/media/lirc/lirc_zilog.c | 61 ++---
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index dca806a..8814a7e 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -372,14 +372,14 @@ static int add_to_buf(struct IR *ir)
ret);
if (failures = 3) {
mutex_unlock(ir-ir_lock);
- dev_err(ir-l.dev, unable to read from the IR
chip
- after 3 resets, giving up\n);
+ dev_err(ir-l.dev,
+ unable to read from the IR chip after
3 resets, giving up\n);
break;
}
/* Looks like the chip crashed, reset it */
- dev_err(ir-l.dev, polling the IR receiver chip
failed,
- trying reset\n);
+ dev_err(ir-l.dev,
+ polling the IR receiver chip failed, trying
reset\n);
set_current_state(TASK_UNINTERRUPTIBLE);
if (kthread_should_stop()) {
@@ -405,8 +405,9 @@ static int add_to_buf(struct IR *ir)
ret = i2c_master_recv(rx-c, keybuf, sizeof(keybuf));
mutex_unlock(ir-ir_lock);
if (ret != sizeof(keybuf)) {
- dev_err(ir-l.dev, i2c_master_recv failed with %d --
- keeping last read buffer\n, ret);
+ dev_err(ir-l.dev,
+ i2c_master_recv failed with %d -- keeping last
read buffer\n,
+ ret);
} else {
rx-b[0] = keybuf[3];
rx-b[1] = keybuf[4];
@@ -713,8 +714,9 @@ static int send_boot_data(struct IR_tx *tx)
buf[0]);
return 0;
}
- dev_notice(tx-ir-l.dev, Zilog/Hauppauge IR blaster firmware version
-%d.%d.%d loaded\n, buf[1], buf[2], buf[3]);
+ dev_notice(tx-ir-l.dev,
+ Zilog/Hauppauge IR blaster firmware version %d.%d.%d
loaded\n,
+ buf[1], buf[2], buf[3]);
return 0;
}
@@ -794,9 +796,9 @@ static int fw_load(struct IR_tx *tx)
if (!read_uint8(data, tx_data-endp, version))
goto corrupt;
if (version != 1) {
- dev_err(tx-ir-l.dev, unsupported code set file version (%u,
expected
- 1) -- please upgrade to a newer driver,
- version);
+ dev_err(tx-ir-l.dev,
+ unsupported code set file version (%u, expected 1) --
please upgrade to a newer driver,
+ version);
fw_unload_locked();
ret = -EFAULT;
goto out;
@@ -983,8 +985,9 @@ static int send_code(struct IR_tx *tx, unsigned int code,
unsigned int key)
ret = get_key_data(data_block, code, key);
if (ret == -EPROTO) {
- dev_err(tx-ir-l.dev, failed to get data for code %u, key %u
-- check
- lircd.conf entries\n, code, key);
+ dev_err(tx-ir-l.dev,
+ failed to get data for code %u, key %u -- check
lircd.conf entries\n,
+ code, key);
return ret;
} else if (ret != 0)
return ret;
@@ -1059,12 +1062,14 @@ static int send_code(struct IR_tx *tx, unsigned int
code, unsigned int key)
ret = i2c_master_send(tx-c, buf, 1);
if (ret == 1)
break;
- dev_dbg(tx-ir-l.dev, NAK expected: i2c_master_send
- failed with %d (try %d)\n, ret, i+1);
+ dev_dbg(tx-ir-l.dev,
+ NAK expected: i2c_master_send failed with %d (try
%d)\n,
+ ret, i+1);
}
if (ret != 1) {
- dev_err(tx-ir-l.dev, IR TX chip never got ready: last
i2c_master_send
- failed with %d\n, ret);
+ dev_err(tx-ir-l.dev,
+ IR TX chip never got ready: last i2c_master_send
failed with %d\n,
+ ret);
return ret 0 ? ret : -EFAULT;
}
@@ -1167,12 +1172,12 @@ static ssize_t
[PATCH v5 2/3] staging: media: lirc: lirc_zilog.c: keep consistency in dev functions
The previous patch switched some dev functions to move the string to a second
line. Doing this for all similar functions because it makes the driver easier
to read if all similar lines use the same criteria.
Signed-off-by: Luis de Bethencourt l...@debethencourt.com
---
drivers/staging/media/lirc/lirc_zilog.c | 57 ++---
1 file changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 8814a7e..27464da 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -369,7 +369,7 @@ static int add_to_buf(struct IR *ir)
ret = i2c_master_send(rx-c, sendbuf, 1);
if (ret != 1) {
dev_err(ir-l.dev, i2c_master_send failed with %d\n,
- ret);
+ ret);
if (failures = 3) {
mutex_unlock(ir-ir_lock);
dev_err(ir-l.dev,
@@ -412,8 +412,9 @@ static int add_to_buf(struct IR *ir)
rx-b[0] = keybuf[3];
rx-b[1] = keybuf[4];
rx-b[2] = keybuf[5];
- dev_dbg(ir-l.dev, key (0x%02x/0x%02x)\n,
- rx-b[0], rx-b[1]);
+ dev_dbg(ir-l.dev,
+ key (0x%02x/0x%02x)\n,
+ rx-b[0], rx-b[1]);
}
/* key pressed ? */
@@ -657,8 +658,8 @@ static int send_data_block(struct IR_tx *tx, unsigned char
*data_block)
dev_dbg(tx-ir-l.dev, %*ph, 5, buf);
ret = i2c_master_send(tx-c, buf, tosend + 1);
if (ret != tosend + 1) {
- dev_err(tx-ir-l.dev, i2c_master_send failed with
%d\n,
- ret);
+ dev_err(tx-ir-l.dev,
+ i2c_master_send failed with %d\n, ret);
return ret 0 ? ret : -EFAULT;
}
i += tosend;
@@ -711,7 +712,7 @@ static int send_boot_data(struct IR_tx *tx)
}
if ((buf[0] != 0x80) (buf[0] != 0xa0)) {
dev_err(tx-ir-l.dev, unexpected IR TX init response: %02x\n,
- buf[0]);
+ buf[0]);
return 0;
}
dev_notice(tx-ir-l.dev,
@@ -763,8 +764,9 @@ static int fw_load(struct IR_tx *tx)
/* Request codeset data file */
ret = request_firmware(fw_entry, haup-ir-blaster.bin, tx-ir-l.dev);
if (ret != 0) {
- dev_err(tx-ir-l.dev, firmware haup-ir-blaster.bin not
available (%d)\n,
- ret);
+ dev_err(tx-ir-l.dev,
+ firmware haup-ir-blaster.bin not available (%d)\n,
+ ret);
ret = ret 0 ? ret : -EFAULT;
goto out;
}
@@ -814,7 +816,7 @@ static int fw_load(struct IR_tx *tx)
goto corrupt;
dev_dbg(tx-ir-l.dev, %u IR blaster codesets loaded\n,
- tx_data-num_code_sets);
+ tx_data-num_code_sets);
tx_data-code_sets = vmalloc(
tx_data-num_code_sets * sizeof(char *));
@@ -944,8 +946,9 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
unsigned char buf[MAX_XFER_SIZE];
if (rbuf-chunk_size sizeof(buf)) {
- dev_err(ir-l.dev, chunk_size is too big
(%d)!\n,
- rbuf-chunk_size);
+ dev_err(ir-l.dev,
+ chunk_size is too big (%d)!\n,
+ rbuf-chunk_size);
ret = -EINVAL;
break;
}
@@ -968,8 +971,8 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
put_ir_rx(rx, false);
set_current_state(TASK_RUNNING);
- dev_dbg(ir-l.dev, read result = %d (%s)\n,
- ret, ret ? Error : OK);
+ dev_dbg(ir-l.dev, read result = %d (%s)\n, ret,
+ ret ? Error : OK);
return ret ? ret : written;
}
@@ -1081,7 +1084,7 @@ static int send_code(struct IR_tx *tx, unsigned int code,
unsigned int key)
}
if (buf[0] != 0x80) {
dev_err(tx-ir-l.dev, unexpected IR TX response #2: %02x\n,
- buf[0]);
+ buf[0]);
return -EFAULT;
}
@@ -1233,7 +1236,7 @@ static unsigned int poll(struct file *filep, poll_table
*wait)
ret = lirc_buffer_empty(rbuf) ? 0 : (POLLIN|POLLRDNORM);
[PATCH v5 3/3] staging: media: lirc: lirc_zilog.c: missing newline in dev_err()
Missing newline character at the end of string passed to dev_err()
Signed-off-by: Luis de Bethencourt l...@debethencourt.com
---
drivers/staging/media/lirc/lirc_zilog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 27464da..7def690 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -799,7 +799,7 @@ static int fw_load(struct IR_tx *tx)
goto corrupt;
if (version != 1) {
dev_err(tx-ir-l.dev,
- unsupported code set file version (%u, expected 1) --
please upgrade to a newer driver,
+ unsupported code set file version (%u, expected 1) --
please upgrade to a newer driver\n,
version);
fw_unload_locked();
ret = -EFAULT;
--
2.1.3
--
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: au0828 - convert to use videobuf2
Convert au0828 to use videobuf2. Tested with NTSC.
Tested video and vbi devices with xawtv, tvtime,
and vlc. Ran v4l2-compliance to ensure there are
no new regressions in video and vbi now has 3 fewer
failures.
video before:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Video after:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_G_FMT: FAIL 3 failures
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
vbi before:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
test VIDIOC_EXPBUF: FAIL
test USERPTR: FAIL
Total: 72, Succeeded: 66, Failed: 6, Warnings: 0
vbi after:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test USERPTR: OK
Total: 72, Succeeded: 69, Failed: 3, Warnings: 0
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
Note:
Also Alsa audio is having issues on 3.18-rc7 without any vb2
conversion changes. Is that a known issue? Several ALSA PCM
underrun and overrun errors and audio stops.
drivers/media/usb/au0828/Kconfig| 2 +-
drivers/media/usb/au0828/au0828-cards.c | 2 +-
drivers/media/usb/au0828/au0828-vbi.c | 122 ++--
drivers/media/usb/au0828/au0828-video.c | 960 +---
drivers/media/usb/au0828/au0828.h | 61 +-
5 files changed, 462 insertions(+), 685 deletions(-)
diff --git a/drivers/media/usb/au0828/Kconfig b/drivers/media/usb/au0828/Kconfig
index 1d410ac..78b797e 100644
--- a/drivers/media/usb/au0828/Kconfig
+++ b/drivers/media/usb/au0828/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_AU0828
depends on I2C INPUT DVB_CORE USB
select I2C_ALGOBIT
select VIDEO_TVEEPROM
- select VIDEOBUF_VMALLOC
+ select VIDEOBUF2_VMALLOC
select DVB_AU8522_DTV if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/usb/au0828/au0828-cards.c
b/drivers/media/usb/au0828/au0828-cards.c
index 9eb77ac..ae2e563 100644
--- a/drivers/media/usb/au0828/au0828-cards.c
+++ b/drivers/media/usb/au0828/au0828-cards.c
@@ -39,7 +39,7 @@ static void hvr950q_cs5340_audio(void *priv, int enable)
struct au0828_board au0828_boards[] = {
[AU0828_BOARD_UNKNOWN] = {
.name = Unknown board,
- .tuner_type = UNSET,
+ .tuner_type = -1U,
.tuner_addr = ADDR_UNSET,
},
[AU0828_BOARD_HAUPPAUGE_HVR850] = {
diff --git a/drivers/media/usb/au0828/au0828-vbi.c
b/drivers/media/usb/au0828/au0828-vbi.c
index 932d24f..e8b4798 100644
--- a/drivers/media/usb/au0828/au0828-vbi.c
+++ b/drivers/media/usb/au0828/au0828-vbi.c
@@ -34,105 +34,71 @@ MODULE_PARM_DESC(vbibufs, number of vbi buffers, range
2-32);
/* -- */
-static void
-free_buffer(struct videobuf_queue *vq, struct au0828_buffer *buf)
+static int vbi_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct au0828_fh *fh = vq-priv_data;
- struct au0828_dev*dev = fh-dev;
- unsigned long flags = 0;
- if (in_interrupt())
- BUG();
-
- /* We used to wait for the buffer to finish here, but this didn't work
- because, as we were keeping the state as VIDEOBUF_QUEUED,
- videobuf_queue_cancel marked it as finished for us.
- (Also, it could wedge forever if the hardware was misconfigured.)
-
- This should be safe; by the time we get here, the buffer isn't
- queued anymore. If we ever start marking the buffers as
- VIDEOBUF_ACTIVE, it won't be, though.
- */
- spin_lock_irqsave(dev-slock, flags);
- if (dev-isoc_ctl.vbi_buf == buf)
- dev-isoc_ctl.vbi_buf = NULL;
- spin_unlock_irqrestore(dev-slock, flags);
+ struct au0828_dev *dev = vb2_get_drv_priv(vq);
+ unsigned long size;
- videobuf_vmalloc_free(buf-vb);
- buf-vb.state = VIDEOBUF_NEEDS_INIT;
-}
+ if (fmt)
+ size = fmt-fmt.pix.sizeimage;
+ else
+ size = dev-vbi_width * dev-vbi_height * 2;
-static int
-vbi_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size)
-{
- struct au0828_fh *fh = q-priv_data;
- struct au0828_dev*dev = fh-dev;
+ if (0 == *nbuffers)
+ *nbuffers = 32;
+ if (*nbuffers 2)
+ *nbuffers = 2;
+ if (*nbuffers 32)
+ *nbuffers = 32;
- *size = dev-vbi_width * dev-vbi_height * 2;
+ *nplanes = 1;
+ sizes[0] = size;
- if (0 == *count)
- *count = vbibufs;
- if (*count 2)
-
Re: [PATCH] [media] uvcvideo: Add GUID for BGR 8:8:8
On 10/12/14 23:54, Laurent Pinchart wrote: Hi William, Thank you for the patch. On Monday 08 December 2014 18:57:58 William Manley wrote: The Magewell XI100DUSB-HDMI[1] video capture device reports the pixel format e436eb7d-524f-11ce-9f53-0020af0ba770. This is its GUID for BGR 8:8:8. The UVC 1.5 spec[2] only defines GUIDs for YUY2, NV12, M420 and I420. This seems to be an extension documented in the Microsoft Windows Media Format SDK[3] - or at least the Media Format SDK was the only hit that Google gave when searching for the GUID. This Media Format SDK defines this GUID as corresponding to `MEDIASUBTYPE_RGB24`. Note though, the XI100DUSB outputs BGR e.g. byte-reversed. I don't know if its the capture device in error or Microsoft mean BGR when they say RGB. I believe Microsoft defines RGB as BGR. They do at least in BMP (https://en.wikipedia.org/wiki/BMP_file_format), probably because they consider the RGB pixel to be stored in little-endian format. Thanks, that's helpful. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I'll apply the patch to my tree and submit it for v3.20. Great Could you please send me the output of 'lsusb -v' for your device, if possible running as root ? lsusb output attached. Thanks Will Bus 003 Device 002: ID 2935:0001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 9 idVendor 0x2935 idProduct 0x0001 bcdDevice0.00 iManufacturer 1 Magewell iProduct2 XI100DUSB-HDMI iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 2474 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 3 XI100DUSB-HDMI Video Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 3 XI100DUSB-HDMI Video VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 52 dwClockFrequency 48.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength0 bControlSize 3 bmControls 0x VideoControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 2 bSourceID 1 wMaxMultiplier 16384 bControlSize3 bmControls 0x000f Brightness Contrast Hue Saturation iProcessing 0 bmVideoStandards 0x 9 None SECAM - 625/50 VideoControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 2 iTerminal 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 bMaxBurst 0 Interface Descriptor: bLength
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Dec 11 04:00:30 CET 2014 git branch: test git hash: 71947828caef0c83d4245f7d1eaddc799b4ff1d1 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK linux-3.18-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v3][PATCH 0/5] media: ov2640: add device tree support
This patch series add device tree support for ov2640. And also add the document for the devicetree properties. v2-v3: 1. fix the gpiod_xxx api usage as we use reset pin as ACTIVE_LOW. 2. update the devicetree binding document. v1 - v2: 1. modified the dt bindings according to Laurent's suggestion. 2. add a fix patch for soc_camera. Otherwise the .reset() function won't work. Josh Wu (5): media: soc-camera: use icd-control instead of icd-pdev for reset() media: ov2640: add async probe function media: ov2640: add primary dt support media: ov2640: add a master clock for sensor media: ov2640: dt: add the device tree binding document .../devicetree/bindings/media/i2c/ov2640.txt | 53 drivers/media/i2c/soc_camera/ov2640.c | 141 ++--- drivers/media/platform/soc_camera/soc_camera.c | 8 +- 3 files changed, 182 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt -- 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
[v3][PATCH 1/5] media: soc-camera: use icd-control instead of icd-pdev for reset()
icd-control is the sub device dev, i.e. i2c device.
icd-pdev is the soc camera device's device.
To be consitent with power() function, we will call reset() with
icd-control as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
v2-v3:
1. check whether icd-control is NULL or not.
drivers/media/platform/soc_camera/soc_camera.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..7e6b914 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -688,7 +688,8 @@ static int soc_camera_open(struct file *file)
/* The camera could have been already on, try to reset */
if (sdesc-subdev_desc.reset)
- sdesc-subdev_desc.reset(icd-pdev);
+ if (icd-control)
+ sdesc-subdev_desc.reset(icd-control);
ret = soc_camera_add_device(icd);
if (ret 0) {
@@ -1175,7 +1176,8 @@ static void scan_add_host(struct soc_camera_host *ici)
/* The camera could have been already on, try to reset
*/
if (ssdd-reset)
- ssdd-reset(icd-pdev);
+ if (icd-control)
+ ssdd-reset(icd-control);
icd-parent = ici-v4l2_dev.dev;
@@ -1461,7 +1463,7 @@ static int soc_camera_async_bound(struct
v4l2_async_notifier *notifier,
memcpy(sdesc-subdev_desc, ssdd,
sizeof(sdesc-subdev_desc));
if (ssdd-reset)
- ssdd-reset(icd-pdev);
+ ssdd-reset(client-dev);
}
icd-control = client-dev;
--
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
[v3][PATCH 2/5] media: ov2640: add async probe function
To support async probe for ov2640, we need remove the code to get 'mclk'
in ov2640_probe() function. oterwise, if soc_camera host is not probed
in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
function.
So in this patch, we move such 'mclk' getting code to ov2640_s_power()
function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is called,
then we can get the 'mclk' and that make us enable/disable soc_camera
host's clock as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
v2 - v3:
v1 - v2:
no changes.
drivers/media/i2c/soc_camera/ov2640.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv-clk) {
+ clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(clk))
+ dev_warn(client-dev, Cannot get the mclk. maybe
soc-camera host is not probed yet.\n);
+ else
+ priv-clk = clk;
+ }
return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
}
@@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
if (priv-hdl.error)
return priv-hdl.error;
- priv-clk = v4l2_clk_get(client-dev, mclk);
- if (IS_ERR(priv-clk)) {
- ret = PTR_ERR(priv-clk);
- goto eclkget;
- }
-
ret = ov2640_video_probe(client);
if (ret) {
- v4l2_clk_put(priv-clk);
-eclkget:
- v4l2_ctrl_handler_free(priv-hdl);
+ goto evideoprobe;
} else {
dev_info(adapter-dev, OV2640 Probed\n);
}
+ ret = v4l2_async_register_subdev(priv-subdev);
+ if (ret 0)
+ goto evideoprobe;
+
+ return 0;
+
+evideoprobe:
+ v4l2_ctrl_handler_free(priv-hdl);
return ret;
}
@@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
- v4l2_clk_put(priv-clk);
+ v4l2_async_unregister_subdev(priv-subdev);
+ if (priv-clk)
+ v4l2_clk_put(priv-clk);
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
return 0;
--
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
[v3][PATCH 3/5] media: ov2640: add primary dt support
Add device tree support for ov2640.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
---
v2 - v3:
1. fix gpiod usage.
2. refine the ov2640_probe() function.
v1 - v2:
1. use gpiod APIs.
2. change the gpio pin's name according to datasheet.
3. reduce the delay for .reset() function.
drivers/media/i2c/soc_camera/ov2640.c | 87 ---
1 file changed, 81 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 9ee910d..e0bcf5b 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -18,6 +18,8 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/delay.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include linux/v4l2-mediabus.h
#include linux/videodev2.h
@@ -283,6 +285,10 @@ struct ov2640_priv {
u32 cfmt_code;
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
+
+ struct soc_camera_subdev_desc ssdd_dt;
+ struct gpio_desc *resetb_gpio;
+ struct gpio_desc *pwdn_gpio;
};
/*
@@ -1047,6 +1053,63 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.video = ov2640_subdev_video_ops,
};
+/* OF probe functions */
+static int ov2640_hw_power(struct device *dev, int on)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ dev_dbg(client-dev, %s: %s the camera\n,
+ __func__, on ? ENABLE : DISABLE);
+
+ if (priv-pwdn_gpio)
+ gpiod_direction_output(priv-pwdn_gpio, !on);
+
+ return 0;
+}
+
+static int ov2640_hw_reset(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ if (priv-resetb_gpio) {
+ /* Active the resetb pin to perform a reset pulse */
+ gpiod_direction_output(priv-resetb_gpio, 1);
+ usleep_range(3000, 5000);
+ gpiod_direction_output(priv-resetb_gpio, 0);
+ }
+
+ return 0;
+}
+
+static int ov2640_probe_dt(struct i2c_client *client,
+ struct ov2640_priv *priv)
+{
+ /* reset is not actived */
+ priv-resetb_gpio = devm_gpiod_get_optional(client-dev, resetb,
+ GPIOD_OUT_LOW);
+ if (!priv-resetb_gpio)
+ dev_dbg(client-dev, resetb gpio is not assigned!\n);
+ else if (IS_ERR(priv-resetb_gpio))
+ return PTR_ERR(priv-resetb_gpio);
+
+ /* Power down actived */
+ priv-pwdn_gpio = devm_gpiod_get_optional(client-dev, pwdn,
+ GPIOD_OUT_HIGH);
+ if (!priv-pwdn_gpio)
+ dev_dbg(client-dev, pwdn gpio is not assigned!\n);
+ else if (IS_ERR(priv-pwdn_gpio))
+ return PTR_ERR(priv-pwdn_gpio);
+
+ /* Initialize the soc_camera_subdev_desc */
+ priv-ssdd_dt.power = ov2640_hw_power;
+ priv-ssdd_dt.reset = ov2640_hw_reset;
+ client-dev.platform_data = priv-ssdd_dt;
+
+ return 0;
+}
+
/*
* i2c_driver functions
*/
@@ -1058,12 +1121,6 @@ static int ov2640_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
int ret;
- if (!ssdd) {
- dev_err(adapter-dev,
- OV2640: Missing platform_data for driver\n);
- return -EINVAL;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(adapter-dev,
OV2640: I2C-Adapter doesn't support SMBUS\n);
@@ -1077,6 +1134,17 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
+ if (!ssdd !client-dev.of_node) {
+ dev_err(client-dev, Missing platform_data for driver\n);
+ return -EINVAL;
+ }
+
+ if (!ssdd client-dev.of_node) {
+ ret = ov2640_probe_dt(client, priv);
+ if (ret)
+ return ret;
+ }
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
@@ -1123,9 +1191,16 @@ static const struct i2c_device_id ov2640_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ov2640_id);
+static const struct of_device_id ov2640_of_match[] = {
+ {.compatible = ovti,ov2640, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ov2640_of_match);
+
static struct i2c_driver ov2640_i2c_driver = {
.driver = {
.name = ov2640,
+ .of_match_table = of_match_ptr(ov2640_of_match),
},
.probe= ov2640_probe,
.remove = ov2640_remove,
--
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
[v3][PATCH 4/5] media: ov2640: add a master clock for sensor
The master clock (xvclk) is mandatory. It's a common clock framework clock.
It can make sensor output a pixel clock to the camera interface.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
---
v2 - v3:
1. should return PTR_ERR().
v1 - v2:
1. change the clock's name.
2. Make the clock is mandatory.
drivers/media/i2c/soc_camera/ov2640.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index e0bcf5b..055702c 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -13,6 +13,7 @@
* published by the Free Software Foundation.
*/
+#include linux/clk.h
#include linux/init.h
#include linux/module.h
#include linux/i2c.h
@@ -31,6 +32,7 @@
#define VAL_SET(x, mask, rshift, lshift) \
x) rshift) mask) lshift)
+
/*
* DSP registers
* register offset for BANK_SEL == BANK_SEL_DSP
@@ -284,6 +286,7 @@ struct ov2640_priv {
struct v4l2_ctrl_handlerhdl;
u32 cfmt_code;
struct v4l2_clk *clk;
+ struct clk *master_clk;
const struct ov2640_win_size*win;
struct soc_camera_subdev_desc ssdd_dt;
@@ -746,6 +749,7 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
struct v4l2_clk *clk;
+ int ret;
if (!priv-clk) {
clk = v4l2_clk_get(client-dev, mclk);
@@ -755,7 +759,20 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
priv-clk = clk;
}
- return soc_camera_set_power(client-dev, ssdd, priv-clk, on);
+ if (on) {
+ ret = clk_prepare_enable(priv-master_clk);
+ if (ret)
+ return ret;
+ } else {
+ clk_disable_unprepare(priv-master_clk);
+ }
+
+ ret = soc_camera_set_power(client-dev, ssdd, priv-clk, on);
+
+ if (ret on)
+ clk_disable_unprepare(priv-master_clk);
+
+ return ret;
}
/* Select the nearest higher resolution for capture */
@@ -1145,6 +1162,10 @@ static int ov2640_probe(struct i2c_client *client,
return ret;
}
+ priv-master_clk = devm_clk_get(client-dev, xvclk);
+ if (IS_ERR(priv-master_clk))
+ return PTR_ERR(priv-master_clk);
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
--
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
[v3][PATCH 5/5] media: ov2640: dt: add the device tree binding document
Add the document for ov2640 dt.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
---
v2 - v3:
1. fix incorrect description.
2. Add assigned-clocks assigned-clock-rates.
3. resetb pin should be ACTIVE_LOW.
v1 - v2:
1. change the compatible string to be consistent with verdor file.
2. change the clock and pins' name.
3. add missed pinctrl in example.
.../devicetree/bindings/media/i2c/ov2640.txt | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
new file mode 100644
index 000..958e120
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,53 @@
+* Omnivision ov2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties:
+- compatible: Must be ovti,ov2640
+- clocks: reference to the xvclk input clock. It can be an external fixed
+ clock or a programmable clock from SoC.
+- clock-names: Must be xvclk.
+- assigned-clocks: reference to the above 'clocks' property.
+- assigned-clock-rates: reference to the clock frequency of xvclk. Typical
+value is 25Mhz (2500).
+This clock should only have single user. Specifying
+Conflicting rate configuration in multiple consumer
+nodes for a shared clock is forbidden.
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_pck1 pinctrl_ov2640_pwdn
pinctrl_ov2640_resetb;
+
+ resetb-gpios = pioE 24 GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29 GPIO_ACTIVE_HIGH;
+
+ clocks = pck1;
+ clock-names = xvclk;
+
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
--
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
