[]..
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
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
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
[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
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
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
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
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
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
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
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:
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
*
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)
> > > > +{
13 matches
Mail list logo