Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1274106 > unrolled thread

Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

Started byLiviu Dudau <Liviu.Dudau@arm.com>
First post2015-11-20 15:30 +0100
Last post2015-11-20 18:00 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting. Liviu Dudau <Liviu.Dudau@arm.com> - 2015-11-20 15:30 +0100
    Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting. Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-20 17:40 +0100
      Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting. Liviu Dudau <Liviu.Dudau@arm.com> - 2015-11-20 17:50 +0100
        Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting. Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-20 18:00 +0100

#1274106 — Re: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.

FromLiviu Dudau <Liviu.Dudau@arm.com>
Date2015-11-20 15:30 +0100
SubjectRe: [PATCH 0/3] drm/i2c: tda998x: Add support for atomic modesetting.
Message-ID<qwURk-8na-29@gated-at.bofh.it>
On Wed, Nov 11, 2015 at 05:57:18PM +0000, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:51:52PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Nov 11, 2015 at 03:34:32PM +0000, Liviu Dudau wrote:
> > > While going through the code testing I've noticed an unbalanced
> > > .unbind missing drm_connector_unregister()
> > 
> > That actually doesn't matter, as DRM automatically tears them down anyway,
> > so this isn't an urgent change.  However, it's good practice to do so.
> 
> It looks like it doesn't, or at least not if the error code is -EPROBE_DEFER.
> On Juno, where the clocks are provided by SCPI and the load order is not
> guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> is not cleaned up, so on the next attempt the drm_connector_register() call
> will fail.
> 
> Best regards,
> Liviu

Gentle ping. Russell, are you happy with this patchset? If so, would you mind
giving me your Acks?

Many thanks,
Liviu

> 
> > 
> > -- 
> > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > according to speedtest.net.
> > 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1274241

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2015-11-20 17:40 +0100
Message-ID<qwWT9-1dJ-37@gated-at.bofh.it>
In reply to#1274106
On Fri, Nov 20, 2015 at 02:24:04PM +0000, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:57:18PM +0000, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:51:52PM +0000, Russell King - ARM Linux wrote:
> > > On Wed, Nov 11, 2015 at 03:34:32PM +0000, Liviu Dudau wrote:
> > > > While going through the code testing I've noticed an unbalanced
> > > > .unbind missing drm_connector_unregister()
> > > 
> > > That actually doesn't matter, as DRM automatically tears them down anyway,
> > > so this isn't an urgent change.  However, it's good practice to do so.
> > 
> > It looks like it doesn't, or at least not if the error code is -EPROBE_DEFER.
> > On Juno, where the clocks are provided by SCPI and the load order is not
> > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> > is not cleaned up, so on the next attempt the drm_connector_register() call
> > will fail.
> > 
> > Best regards,
> > Liviu
> 
> Gentle ping. Russell, are you happy with this patchset? If so, would you mind
> giving me your Acks?

As I'm the maintainer for the driver, I'll merge it, thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274257

FromLiviu Dudau <Liviu.Dudau@arm.com>
Date2015-11-20 17:50 +0100
Message-ID<qwX2P-1hA-43@gated-at.bofh.it>
In reply to#1274241
On Fri, Nov 20, 2015 at 04:32:59PM +0000, Russell King - ARM Linux wrote:
> On Fri, Nov 20, 2015 at 02:24:04PM +0000, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:57:18PM +0000, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:51:52PM +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Nov 11, 2015 at 03:34:32PM +0000, Liviu Dudau wrote:
> > > > > While going through the code testing I've noticed an unbalanced
> > > > > .unbind missing drm_connector_unregister()
> > > > 
> > > > That actually doesn't matter, as DRM automatically tears them down anyway,
> > > > so this isn't an urgent change.  However, it's good practice to do so.
> > > 
> > > It looks like it doesn't, or at least not if the error code is -EPROBE_DEFER.
> > > On Juno, where the clocks are provided by SCPI and the load order is not
> > > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> > > is not cleaned up, so on the next attempt the drm_connector_register() call
> > > will fail.
> > > 
> > > Best regards,
> > > Liviu
> > 
> > Gentle ping. Russell, are you happy with this patchset? If so, would you mind
> > giving me your Acks?
> 
> As I'm the maintainer for the driver, I'll merge it, thanks.

Cheers!

Do I need to do anything?

Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1274267

FromRussell King - ARM Linux <linux@arm.linux.org.uk>
Date2015-11-20 18:00 +0100
Message-ID<qwXcu-1li-17@gated-at.bofh.it>
In reply to#1274257
On Fri, Nov 20, 2015 at 04:44:55PM +0000, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 04:32:59PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 20, 2015 at 02:24:04PM +0000, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:57:18PM +0000, Liviu Dudau wrote:
> > > > On Wed, Nov 11, 2015 at 05:51:52PM +0000, Russell King - ARM Linux wrote:
> > > > > On Wed, Nov 11, 2015 at 03:34:32PM +0000, Liviu Dudau wrote:
> > > > > > While going through the code testing I've noticed an unbalanced
> > > > > > .unbind missing drm_connector_unregister()
> > > > > 
> > > > > That actually doesn't matter, as DRM automatically tears them down anyway,
> > > > > so this isn't an urgent change.  However, it's good practice to do so.
> > > > 
> > > > It looks like it doesn't, or at least not if the error code is -EPROBE_DEFER.
> > > > On Juno, where the clocks are provided by SCPI and the load order is not
> > > > guaranteed, the first bind will fail with -EPROBE_DEFER but the sysfs entry
> > > > is not cleaned up, so on the next attempt the drm_connector_register() call
> > > > will fail.
> > > > 
> > > > Best regards,
> > > > Liviu
> > > 
> > > Gentle ping. Russell, are you happy with this patchset? If so, would you mind
> > > giving me your Acks?
> > 
> > As I'm the maintainer for the driver, I'll merge it, thanks.
> 
> Cheers!
> 
> Do I need to do anything?

The easy way to ensure that it doesn't get forgotten is to put it in my
patch system, just like ARM patches do.  It'll then nag me each time I
look at it (and also means I don't have to save it out, copy it across
to the machine with the git tree on it, and then apply it there...)

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web