Re: [PATCH 5/9] clk: qcom: gcc-msm8960: add child devices support.

2015-09-07 Thread Rajendra Nayak
[].. No. The driver should work just fine without having to interrogate the device's compatible string. If we still need the compatible check for some reason, then we can always match based on qcom,gcc-msm8960, qcom,gcc-apq8064, etc. But I don't see why Thats not quite possible I guess. 2

[PATCH v2] usb: phy: msm: Unregister VBUS and ID events notifiers

2015-09-07 Thread Ivan T. Ivanov
Right now even if driver failed to probe extcon framework will still deliver its VBUS and ID events, which will lead to random exception codes. Fix this by removing VBUS and ID events notifiers when probe fail. Fixes: 591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID

Re: [PATCH] usb: phy: msm: Unregister driver interest for VBUS and ID events

2015-09-07 Thread Ivan T. Ivanov
On Mon, 2015-08-24 at 10:11 -0700, Tim Bird wrote: > On 08/18/2015 12:56 AM, Ivan T. Ivanov wrote: > > Right now even if driver failed to probe extcon framework will > > still deliver its VBUS and ID events, which will lead to random > > exception codes. > > > > Fix this by removing driver

[PATCH] usb: phy: qcom: Switch to new extcon framework API

2015-09-07 Thread Ivan T. Ivanov
[un]register_interest and reading cable state by name have been deprecated. Switch to new API. Signed-off-by: Ivan T. Ivanov --- drivers/usb/phy/phy-qcom-8x16-usb.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git

[PATCH v2 5/5] drm/i2c: adv7511: Add dsi driver for adv7533

2015-09-07 Thread Archit Taneja
Add a separate mipi_dsi_driver for adv7533. In the case of this chip, both the i2c and dsi drivers will operate together. Both the drivers are expected to use the same per-device driver data struct. The i2c driver takes the responsibility of allocating the struct, and the dsi device gets a

[PATCH v2 1/5] drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled

2015-09-07 Thread Archit Taneja
When the adv7511 i2c client doesn't have an interrupt line, we observe a deadlock on caused by trying to lock drm device's mode_config.mutex twice in the same context. Here is the sequence that causes it: ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace drm_mode_getconnector (acquires

[PATCH v2 2/5] drm/i2c: adv7511: Initial support for adv7533

2015-09-07 Thread Archit Taneja
From: Lars-Peter Clausen ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511, with additional blocks to translate input DSI data to parallel RGB data. Besides the ADV7511 i2c register map, it has additional registers that require to be configured to activate the

[PATCH v2 4/5] drm/i2c: adv7511: Add drm_bridge/connector for ADV7533

2015-09-07 Thread Archit Taneja
Create bridge and connector helper functions. These internally refer to the ADV75xx helper functions. The driver registers a drm_bridge object during probe. The bridge, in turn registers a HDMI connector when a user attaches the bridge. Therefore, when the device type is ADV7533, we create

[PATCH v2 0/5] drm/i2c: adv7511: ADV7533 support

2015-09-07 Thread Archit Taneja
ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an additional DSI RX block that takes in DSI video mode output. This series adds support for ADV7533. Unlike ADV7511 that's modelled as a drm i2c slave encoder, ADV7533 is a drm_bridge object. The bridge ops further create a HDMI

[PATCH v2 3/5] drm/i2c: adv7511: Refactor encoder slave functions

2015-09-07 Thread Archit Taneja
ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on the other hand, is going be a normal i2c client device creating bridge and connector entities. Move the code in encoder slave functions to generate helpers that are agnostic to the drm object type. These helpers will later

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

2015-09-07 Thread Archit Taneja
Thierry, On 08/21/2015 11:39 AM, Archit Taneja wrote: On 08/20/2015 05:18 PM, Thierry Reding wrote: On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote: Hi Thierry, Lucas, On 08/19/2015 08:32 PM, Thierry Reding wrote: On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

[PATCH v4] usb: chipidea: Use extcon framework for VBUS and ID detect

2015-09-07 Thread Ivan T. Ivanov
On recent Qualcomm platforms VBUS and ID lines are not routed to USB PHY LINK controller. Use extcon framework to receive connect and disconnect ID and VBUS notification. Signed-off-by: Ivan T. Ivanov --- Changes sice v3 [1]: * Migrate to new extcon framework API *

Re: [PATCH v3] usb: chipidea: Use extcon framework for VBUS and ID detect

2015-09-07 Thread Ivan T. Ivanov
On Fri, 2015-06-05 at 17:26 +0800, Peter Chen wrote: > On Fri, Jun 05, 2015 at 10:37:07AM +0300, Ivan T. Ivanov wrote: > > > > > + > > > > +static int ci_id_notifier(struct notifier_block *nb, unsigned long > > > > event, > > > > + void *ptr) > > > > +{