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))
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 do we have kfree() here? clk_get() doesn't allocate the data structure
being freed here
Hi Vivek,
On 25/11/14 12:48, Vivek Gautam wrote:
On Sat, Nov 22, 2014 at 8:42 PM, Kukjin Kim kg...@kernel.org 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.
instead of doing this manually
in each driver. So, fix the drivers and documentation, too.
Acked-by: Sylwester Nawrocki s.nawro...@amsung.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed
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 s.nawro...@amsung.com
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6:
Applying: i2c
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
at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Cc: Tomasz Figa t.f...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
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 booting with DT.
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
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
[1] http://www.spinics.net/lists/arm-kernel
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 from
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
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:
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com for patches
1...3/9, 5...7/9
and Tested-by: Sylwester Nawrocki
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
create/destroy a PHY and APIs for the PHY users
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 provider*
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 support platforms
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 kis...@ti.com
wrote:
Added a generic PHY framework that provides a set of APIs for the PHY
drivers
to create/destroy a PHY
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 make use of the PHY, it has to get a
reference
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;
+reg
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
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
+++
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
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
device node is opened. So I
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
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 buffers from user
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 ioctl on
a v4l2
On 12/09/2011 04:10 PM, Ming Lei wrote:
On Fri, Dec 9, 2011 at 7:25 AM, Sylwester Nawrocki snj...@gmail.com 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 generic FD now:
- one is to detect
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 low
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 v4l2
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 common
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 snj...@gmail.com wrote:
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
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.org/downloads/v4l-dvb
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 detection
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,
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 verification
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 snj...@gmail.com wrote:
Cc: LMML
On 11/26/2011 05:31 AM, tom.leim...@gmail.com wrote:
From: Ming Lei ming@canonical.com
One face detection IP[1
Cc: LMML
On 11/26/2011 05:31 AM, tom.leim...@gmail.com wrote:
From: Ming Lei ming@canonical.com
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
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,
is
795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
Cheers,
Sylwester Nawrocki
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
42 matches
Mail list logo
