On 05/02/15 20:44, Sylwester Nawrocki wrote:
>> +void __clk_put(struct clk *clk)
>> > +{
>> > + if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>> > + return;
>> > +
>> > + clk_core_put(clk->core);
>> > + kfree(clk);
>
> Why d
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
> int __clk_get(struct clk *clk)
> {
> - if (clk) {
> - if (!try_module_get(clk->owner))
> + struct clk_core *core = !clk ? NULL : clk->core;
> +
> + if (core) {
> + if (!try_module_get(core->owner))
>
Hi Vivek,
On 25/11/14 12:48, Vivek Gautam wrote:
> On Sat, Nov 22, 2014 at 8:42 PM, Kukjin Kim wrote:
>> > On 11/22/14 17:40, Kishon Vijay Abraham I wrote:
>>> >> On Friday 21 November 2014 08:41 PM, Felipe Balbi wrote:
...
>>> I took dwc3 driver patches.
>>> >>
>>> >> I took the phy patches
nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
>
> Acked-by: Sylwester Nawrocki
> Acked-by: Rob Herring
> Reviewed-by: Felipe Balbi
> Acked-by: Rafael J. Wysocki
> Signed-off-by: Wolfram Sang
With this patch t
sted on an AT91 board. More tests
> very welcome. Thanks!
>
>
> drivers/i2c/busses/i2c-s3c2410.c|2 -
> drivers/media/platform/exynos4-is/fimc-is-i2c.c | 3 -
For these:
Acked-by: Sylwester Nawrocki
However this patch fails to apply onto either v3.11-rc4 or
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abrah
e documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Cc: Tomasz Figa
> Cc: Greg Kroah-Hartman
> Signed-off-by: Kishon Vijay Abraham I
> Acked-by: Felipe Balbi
> Tested-by: Sylwester Nawrocki
> ---
>
On 07/24/2013 08:32 PM, Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
>> On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
>>> On Tue, 23 Jul 2013, Tomasz Figa wrote:
Where would you want to have those phy_address arrays stored? There
are no board files when booti
On 07/21/2013 05:48 PM, Greg KH wrote:
On Sun, Jul 21, 2013 at 12:22:48PM +0200, Sascha Hauer wrote:
On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform d
Hi,
On 06/18/2013 11:49 AM, Felipe Balbi wrote:
> On Mon, Jun 17, 2013 at 12:16:35PM +0200, Sylwester Nawrocki wrote:
>> I have already used this API for our MIPI CSI-2/DSIM DPHYs driver,
>> the RFC patch series can be found at [1].
>>
>> Thanks,
>> Sylwester
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
> +/**
> + * phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @id: id of the phy
> + * @ops: function pointers for performing phy operations
> + * @label: label given to the phy
> + * @priv: private data
Hi Kishon,
I've noticed there is a little inconsistency between the code and
documentation.
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provid
rected few typos in Documentation
> * Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
> PHY Subsystem is kept as module and the dependent modules are built-in)
> * Added if pm_runtime_enabled check before runtime pm calls.
Looks good, feel free to add:
Hi,
On 06/04/2013 02:26 PM, Kishon Vijay Abraham I wrote:
>>> +static inline int phy_init(struct phy *phy)
>>> +{
>>> + pm_runtime_get_sync(&phy->dev);
>>
>> Hmm, no need to check return value here ? Also it looks a bit unexpected to
>
> I purposely dint check the return values in order to supp
On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. For dt-boot, the PHY drivers should
> also register *PHY provid
Hi,
On 05/29/2013 07:38 AM, Kishon Vijay Abraham I wrote:
> On Wednesday 29 May 2013 04:07 AM, Sylwester Nawrocki wrote:
>> > On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
>>> >> The PHY framework provides a set of APIs for the PHY drivers to
>>> >
Hi Kishon,
On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY
On 04/15/2013 12:36 PM, Kishon Vijay Abraham I wrote:
> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
>> On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I
>> wrote:
>>> Added a generic PHY framework that provides a set of APIs for the PHY
>>> drivers
>>> to create/destroy a PHY a
Hi,
On 04/04/2013 11:21 AM, Kishon Vijay Abraham I wrote:
> On Thursday 04 April 2013 03:16 AM, Sylwester Nawrocki wrote:
>> On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
>>> +4. Getting a reference to the PHY
>>> +
>>> +Before the controller can
On 04/03/2013 02:53 PM, Kishon Vijay Abraham I wrote:
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
s/dt data/device tree ?
+PHY subsystem refer Documentation/phy.txt
On 04/02/2013 12:38 AM, Stephen Warren wrote:
On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+example2:
+phys: phy {
+compatible = "xxx"
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
Just couple minor comments...
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY wit
Hi Kishon,
On 03/20/2013 10:12 AM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle,
On 01/04/2012 09:13 AM, Ming Lei wrote:
>>> +
>>> +int odif_open(struct file *file)
>>> +{
>>> + struct odif_dev *dev = video_drvdata(file);
>>> +
>>> + kref_get(&dev->ref);
>>> + return v4l2_fh_open(file);
>>> +}
>>
>> Individual drivers may need to perform some initialization when
>>
Hi Ming,
sorry for the late response. It's all looking better now, however there
is still a few things that could be improved.
On 12/14/2011 03:00 PM, Ming Lei wrote:
> This patch introduces two new IOCTLs and related data
> structure which will be used by the coming video device
> with object de
Hi Ming,
On 12/14/2011 03:00 PM, Ming Lei wrote:
> This patch introduces object detection generic driver.
>
> The driver is responsible for all v4l2 stuff, buffer management
> and other general things, and doesn't touch object detection hardware
> directly. Several interfaces are exported to low
Hi,
On 12/12/2011 10:49 AM, Ming Lei wrote:
>>> If FD result is associated with a frame, how can user space get the frame
>>> seq if no v4l2 buffer is involved? Without a frame sequence, it is a bit
>>> difficult to retrieve FD results from user space.
>>
>> If you pass image data in memory buffer
Hi Ming,
On 12/02/2011 04:02 PM, Ming Lei wrote:
> This patch introduces one driver for face detection purpose.
>
> The driver is responsible for all v4l2 stuff, buffer management
> and other general things, and doesn't touch face detection hardware
> directly. Several interfaces are exported to
On 12/09/2011 04:10 PM, Ming Lei wrote:
> On Fri, Dec 9, 2011 at 7:25 AM, Sylwester Nawrocki wrote:
>> On 12/07/2011 02:40 PM, Ming Lei wrote:
>>> Yes, that is the motivation of the generic FD module. I think we can focus
>>> on
>>> two use cases for the
Hi,
On 12/09/2011 05:34 AM, Ming Lei wrote:
> + * struct v4l2_obj_detection
> + * @buf_index: entry, index of v4l2_buffer for face detection
>>
>> I would prefer having the frame sequence number here. It will be more
>> future proof IMHO. If for instance we decide to use such an ioct
On 12/07/2011 02:40 PM, Ming Lei wrote:
>>> I understand the API you mentioned here should belong to kernel internal
>>> API, correct me if it is wrong.
>>
>> Yes, I meant the in kernel design, i.e. generic face detection kernel module
>> and an OMAP4 FDIF driver. It makes lots of sense to separate
On 12/08/2011 04:42 AM, Ming Lei wrote:
>>> +/**
>>> + * struct v4l2_obj_detection
>>> + * @buf_index: entry, index of v4l2_buffer for face detection
I would prefer having the frame sequence number here. It will be more
future proof IMHO. If for instance we decide to use such an ioctl on
a v
On 12/06/2011 11:01 PM, Sylwester Nawrocki wrote:
[...]
>
> It might be much better as the v4l2 events are associated with the frame
> sequence. And if we use controls then you get control events for free,
> and each event carries a frame sequence number int it
> (http://linuxtv.or
On 12/06/2011 03:07 PM, Ming Lei wrote:
> Hi,
>
> Thanks for your review.
>
> On Tue, Dec 6, 2011 at 5:55 AM, Sylwester Nawrocki wrote:
>> Hi Ming,
>>
>> (I've pruned the Cc list, leaving just the mailing lists)
>>
>> On 12/02/2011 04:02 PM, Mi
On 12/02/2011 04:02 PM, Ming Lei wrote:
> This patch introduces two new IOCTLs and related data
> structure defination which will be used by the coming
> face detection video device.
>
> The two IOCTLs and related data structure are used by
> user space application to retrieve the results of face
Hi Ming,
(I've pruned the Cc list, leaving just the mailing lists)
On 12/02/2011 04:02 PM, Ming Lei wrote:
> This patch introduces one driver for face detection purpose.
>
> The driver is responsible for all v4l2 stuff, buffer management
> and other general things, and doesn't touch face detecti
Hi Ming,
On 12/02/2011 10:12 AM, Ming Lei wrote:
> Hi,
>
> These v1 patches(against -next tree) introduce v4l2 based face
> detection(FD) device driver, and enable FD hardware[1] on omap4 SoC..
> The idea of implementing it on v4l2 is from from Alan Cox, Sylwester
> and Greg-Kh.
>
> For verifica
Hi Ming,
On 11/27/2011 04:40 AM, Ming Lei wrote:
> Hi guys,
>
> Thanks for your comment.
>
> On Sun, Nov 27, 2011 at 6:16 AM, Sylwester Nawrocki wrote:
>> Cc: LMML
>>
>> On 11/26/2011 05:31 AM, tom.leim...@gmail.com wrote:
>>> From: Ming Lei
>
Cc: LMML
On 11/26/2011 05:31 AM, tom.leim...@gmail.com wrote:
> From: Ming Lei
>
> One face detection IP[1] is integared inside OMAP4 SoC, so
> introduce this driver to make face detection function work
> on OMAP4 SoC.
Face detection IP is of course not specific to OMAP, I've seen it in other S
On 09/17/2011 11:34 AM, Martin Hostettler wrote:
> Adds board support for an MT9M032 based camera to omap3evm.
...
> +
> +static int __init camera_init(void)
> +{
> + int ret = -EINVAL;
> +
> + omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
> + if (gpio_request(nCAM_VD_SEL, "nCA
08 if (!atomic_read(&fh->cam->in_reset)) {
> 409 dev_dbg(cam->dev, "resetting camera, csr
> 0x%x\n", csr);
> 410 omap24xxcam_reset(cam);
> 411 }
> 412 } else
> 413
42 matches
Mail list logo
