On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wro
On Mon, Nov 21, 2016 at 05:35:20PM +0100, Daniel Vetter wrote:
> I totally butcherd the job on typing the kernel-doc for these, and no
> one realized. Noticed by Russell. Maarten has a more complete approach
> to this confusion, by making it more explicit what the new/old state
> is, instead of thi
On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable. With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1
On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote:
> > Hi,
>
> Hi Russell,
>
> >
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up o
On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Dani
On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() h
On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID. Then when Xorg started up
On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote:
> Hi Liviu, Russell,
>
> I'd been meaning to try digging into this if it hadn't gone away since I
> first noticed it, but I don't really have the time and it still happens
> with 4.9-rc and today's -next. Representative splat below, but
On Fri, Jun 09, 2017 at 02:59:20PM +0200, Neil Armstrong wrote:
> On 05/30/2017 04:23 PM, Russell King wrote:
> > Add CEC notifier support to the HDMI bridge driver, so that the CEC
> > part of the IP can receive its physical address.
> >
> > Signed-off-by: Russell Kin
On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
> not used, but a custom one, so this notifier is actually useful for
> this platform and maybe others.
Is the CEC controller configured into dw-hdmi (is the conf
On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote:
> From: Russell King
>
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
>
> Tested-by: Neil Armstrong
> Acked-by: Neil Armstrong
>
On Thu, Jul 06, 2017 at 02:38:41PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 06, 2017 at 12:56:43PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote:
> > > Well, from what I can see in 4.12, the cec
On Thu, Jul 06, 2017 at 01:55:58PM +0200, Neil Armstrong wrote:
> On 07/06/2017 01:45 PM, Russell King - ARM Linux wrote:
> > Well, from what I can see in 4.12, the cec-notifier stuff is rather
> > broken (tda998x has stopped working as its stuck with a physical
> > address o
On Thu, Jul 06, 2017 at 01:29:54PM +0200, Neil Armstrong wrote:
> On 07/06/2017 01:05 PM, Russell King - ARM Linux wrote:
> > On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote:
> >> From: Russell King
> >>
> >> Add CEC notifier support to the
On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote:
> Well, from what I can see in 4.12, the cec-notifier stuff is rather
> broken (tda998x has stopped working as its stuck with a physical
> address of f.f.f.f) so I think the whole thing is rather moot right
> n
On Thu, Jul 06, 2017 at 12:56:43PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 06, 2017 at 12:45:55PM +0100, Russell King - ARM Linux wrote:
> > Well, from what I can see in 4.12, the cec-notifier stuff is rather
> > broken (tda998x has stopped working as its stuck
On Mon, Mar 06, 2017 at 02:50:58PM +0100, Philipp Zabel wrote:
> Sorry, I should have mentioned that this must be called from inside an
> existing kernel git repository. The idea is that you don't have to clone
> the whole kernel through our pipe, but can use the upstream repository,
> which has a
On Wed, Mar 08, 2017 at 11:42:17AM -0300, Gustavo Padovan wrote:
> Hi Philipp,
>
> 2017-03-08 Philipp Zabel :
>
> > The next patch will need the dma_fence to create the sync_file in
> > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
> >
> > Signed-off-by: Philipp Zabel
> > ---
On Wed, Mar 08, 2017 at 09:15:24AM +0100, Romain Perier wrote:
> - dw_hdmi_update_power() will be called. As hdmi->force will be equal to
> DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This
> field has not been updated by the irq handler, so it will be false and
> DRM_FORCE_ON won
On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote:
> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> step E. and is kept enabled for later use. This clock should be enabled
> and disabled along with the actual audio stream and not always on (that
> is bad for PM)
On Fri, Mar 10, 2017 at 11:58:19AM +0100, Romain Perier wrote:
> Hello,
>
> Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit :
> > I also would not think that it's platform specific - remember that
> > this is Designware IP, and it's likely that other platfor
On Fri, Mar 10, 2017 at 11:21:53AM +0100, Romain Perier wrote:
> Hello,
>
> Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit :
> > On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote:
> >> Currently, the audio sampler clock is enabled from dw_hdmi_setup(
On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
> On 03/10/2017 10:35 AM, Romain Perier wrote:
> > Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> > step E. and is kept enabled for later use. This clock should be enabled
> > and disabled along with the actual
On Mon, Mar 13, 2017 at 12:55:58PM +, Jose Abreu wrote:
> Hi,
>
>
> On 13-03-2017 09:36, Russell King - ARM Linux wrote:
> > On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
> >> On 03/10/2017 10:35 AM, Romain Perier wrote:
> >>> Curren
On Wed, Mar 15, 2017 at 02:03:09PM +0100, Lucas Stach wrote:
> Am Sonntag, den 12.03.2017, 19:00 + schrieb Russell King:
> > Each Vivante GPU contains a clock divider which can divide the GPU clock
> > by 2^n, which can lower the power dissipation from the GPU. It has been
>
On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> > Hi Gustavo,
> >
> > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> > [...]
> > > I was thinking on some function that would iterate over all fences in
>
On Fri, Mar 17, 2017 at 03:58:27PM +0100, Lucas Stach wrote:
> Am Freitag, den 17.03.2017, 14:42 + schrieb Russell King - ARM
> Linux:
> > On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> > > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabe
On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
> This is a modesetting driver for the pl111 CLCD display controller
> found on various ARM platforms such as the Versatile Express. The
> driver has only been tested on the bcm911360_entphn platform so far,
> with PRIME-based buffer shar
On Mon, Mar 20, 2017 at 02:26:16PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > Add support for video hotplug detect and EDID/ELD notifiers, which is used
> > to convey inform
On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version
On Mon, Mar 20, 2017 at 10:19:35AM +0100, Lucas Stach wrote:
> Yes, probably we want to have both at some point. The cooling-device
> stuff is about throttling the GPU when the SoC reaches critical
> temperatures.
>
> The devfreq governors are about providing exactly the right performance
> point.
On Sun, Mar 19, 2017 at 01:03:42PM -0700, Chris Healy wrote:
> I don't have any input on this binary divider subject but I do want to
> bring up some observations regarding Etnaviv GPU power management that
> seems relevant.
GPU cooling isn't really to do with GPU power management, it's more
to do
On Mon, Mar 20, 2017 at 04:36:14PM -0700, Eric Anholt wrote:
> +static struct amba_driver pl111_amba_driver = {
> + .drv = {
> + .name = "clcd-pl11x",
either:
.name = "clcd-pl111",
or:
.name = "drm-clcd-pl111",
otherwise the driver names will cla
On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c
> b/drivers/gpu/drm/armada/armada_overlay.c
> index 34cb73d0db77..b54fd8cbd3a6 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.
On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote:
> Hm, I certainly want it... but it would be unreasonable of me to expect
> Eric to cold-code a big upfront design for systems he can't even test
> this on.
>
> What I would request would rather be: please do not put in any
> immediate
Hi,
This series adds dw-hdmi CEC support. This is done in four stages:
1. Remove definitions that are not required from dw-hdmi.h
2. Add cec-notifier support
3. Fix up the clkdis register support, as this register contains a
clock disable bit for the CEC module.
4. Add the driver.
The CEC dr
On Thu, Jun 01, 2017 at 01:53:21AM +0100, Jose Abreu wrote:
> Hi Russell,
>
>
> On 30-05-2017 15:23, Russell King wrote:
> > +static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
> > + u32 signal_free_time, struct cec_msg *ms
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> First a few top-level questions:
Hi Hans,
> 1) What was the reason for using the cec-notifier here? Isn't this
>tightly integrated into the main dw-hdmi block? For the tda driver
>it is clearly required, but
On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
> This will change. Patches to fix the config handling are pending for 4.12.
>
> Here you can see the pending patches:
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
>
> The patches from 'cec-notifier.h: handle unreac
On Fri, Jun 02, 2017 at 11:06:24AM +0200, Hans Verkuil wrote:
> On 06/02/17 08:43, Jose Abreu wrote:
> > Hi Hans,
> >
> >
> > On 02-06-2017 07:31, Hans Verkuil wrote:
> >> On 06/01/2017 03:47 PM, Neil Armstrong wrote:
> >>> On 05/30/2017 04:23 PM,
On Fri, Jun 02, 2017 at 06:02:28AM +0100, Jose Abreu wrote:
> You should check that CEC is: not in standy, acknowledges
> broadcast messages, signal free time is 5bit period, and not lost
> arbitration, which basically means CEC_CTRL must be 0x2 and
> IH_CEC_STAT0 must not have ARB_LOST set.
If AR
On Fri, Jun 02, 2017 at 11:28:08AM +0200, Hans Verkuil wrote:
> The 'signal_free_time' argument of adap_transmit will have the recommended
> signal free time. You can test against the CEC_SIGNAL_FREE_TIME_* defines
> from media/cec.h. You probably saw this already, but just in case you missed
> thi
On Mon, Jun 05, 2017 at 10:33:50AM +0900, Inki Dae wrote:
> 2017년 06월 02일 22:58에 Andreas Färber 이(가) 쓴 글:
> > Hello,
> >
> > We're observing the following build failure with v4.12-rc3, latest
> > linux.git and linux-next.git:
> >
> > [ 9825s] LD vmlinux.o
> > [ 9904s] MODPOST vmlinux.o
>
BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote:
> +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + if (dev->archdata.dmabounce)
> + return 0;
I'm not convinced that we need this check here:
dev->archdata.dmabounce =
On Thu, Oct 20, 2016 at 11:20:05AM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
> > Moreover, as I've already said, converting tda998x to a DRM bridge
> > will not get rid of the encoder/connect
On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
> 3) Rough conversion to bridge:
So I thought I might give this a try, and see what's needed to complete
the patch, but...
I thought we'd got past the dark ages of email clients screwing up
patches, but it seems not. This patch is to
On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> wrote:
> > Convert DT component matching to use component_match_add_release().
> >
> > Signed-off-by: Russell King
> > ---
> > Can we please get thi
On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>
>
> On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote:
> >On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
> >>
> >>
> >>On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
&
On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
>
>
> On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
> >Hi Russell,
> >
> >On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
> >>On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent
On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> (sorry, I lost your original mail)
> > >>> DRM bridges indeed don't create encoders. That task is left to the
> > >>> display
> > >>> driver. The re
As part of the discussion about converting tda998x to a bridge, here's
some preparatory work for that, which includes a bunch of fixes. I'm
sending this out _early_ as I'm not going to be working on any kernel
stuff next week (it's likely I won't even be reading email.) So it may
be a little roug
On Wed, Oct 19, 2016 at 10:46:48AM +0100, Brian Starkey wrote:
> Hi Jyri,
>
> I believe this will break mali-dp and hdlcd, unless something changed
> while I wasn't looking. Please see this previous thread where I did
> the same thing and then had to have it reverted: [1]
>
> Before removing this
On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> >> wrote:
> >
On Mon, Oct 24, 2016 at 10:39:27AM +0530, Archit Taneja wrote:
> Sorry about that. I'll post out a proper patch for this once we resolve
> the drm_bridge shortcomings you've mentioned. I can create one if you
> want to try it now.
As said elsewhere, I've been away, so I haven't had a chance to loo
On Mon, Oct 24, 2016 at 08:53:04AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 11:58:00AM +0530, Archit Taneja wrote:
> > On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> > > Looking at drm_bridge_disable() and drm_bridge_enable(), the control
> &g
On Mon, Oct 31, 2016 at 09:00:08AM +, Russell King - ARM Linux wrote:
> I need the patch against v4.8. I'm happy to pick it up and add it
> to my drm-tda998x-devel branch, which you can then merge into
> drm-misc if you wish.
... or if Brian wants to send a git pull request
On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> The first one is that this overscanning should be reported by the
> connector I guess? but this is really TV specific, so we need one way
> to let the user tell how the image is displayed on its side, and we
> cannot really autodetect
On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey
> wrote:
> >>
> >>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> >>> b/drivers/gpu/drm/i2c/tda998x_drv.c
> >>> index f4315bc..6e6fca2 100644
> >>> --- a/drivers/gpu/drm/i2c/tda998x_
On Mon, Oct 24, 2016 at 04:27:45PM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 12:14:14PM +0200, Arnd Bergmann wrote:
> > On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> > > We get 1 warning when building kernel with W=1:
> > > drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: w
On Sun, Oct 30, 2016 at 01:56:25PM +, James Le Cuirot wrote:
> These were previously set in dw_hdmi_connector_get_modes but this
> isn't called when the EDID is overridden. This can be seen in
> drm_helper_probe_single_connector_modes. Using the
> drm_kms_helper.edid_firmware parameter therefor
On Thu, Oct 27, 2016 at 12:17:24AM +0200, Maxime Ripard wrote:
> Hi Rob,
>
> On Wed, Oct 26, 2016 at 05:13:46PM -0500, Rob Herring wrote:
> > On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> > > Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> > > an enable pin
On Fri, Oct 28, 2016 at 01:22:21AM +, Kuninori Morimoto wrote:
> +static struct platform_driver snd_dw_hdmi_driver = {
> + .probe = snd_dw_hdmi_probe,
The driver must have a .remove function, because the platform device it
is binding against can appear and disappear.
--
RMK's Patch syst
On Tue, Oct 25, 2016 at 12:19:19PM +0200, Daniel Vetter wrote:
> On Tue, Oct 25, 2016 at 10:52:33AM +0100, Brian Starkey wrote:
> > Hi Daniel,
> >
> > On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey
> > > wrote:
> > > > >
> > >
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> >> Actually, could you please hold off picking this up? We need to make
> &
x27;ve merged
4.8-rc7 in (and fixed the multitude of conflicts), and manually made the
changes in your patch. Nothing seems to have broken, so I think we're
good.
Acked-by: Russell King
Daniel, please take this change through the drm-misc tree as I'm unlikely
to have a branch which I can a
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> Actually, could you please hold off picking this up? We need to make
> changes in mali-dp and hdlcd or this will mess up their registration.
> I will send those patches later today, but better if this all goes in
> together (whenever
On Thu, Sep 22, 2016 at 05:32:35AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> >> wrote:
On Thu, Sep 22, 2016 at 02:38:45PM +0100, Brian Starkey wrote:
> However, without patching all three drivers in the same commit, there
> would always be some breakage. HDLCD and Mali-DP call
> drm_dev_register() before binding the components - this was needed to
> work with tda998x, which needed th
On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
> Hm, maybe we should simply not call ->lastclose for kms drivers. That is
> kinda only a hack for ums/dri1 drivers.
Are you sure about that - isn't it needed so that the fbdev mode gets
restored when the last DRM user exits, so that t
ks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie
Thanks. You can have an:
Acked-by: Russell King
with one change to this patch:
> ---
> drivers/gpu/drm/armada/armada_gem.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/d
On Sun, Sep 25, 2016 at 03:59:19PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for
> 'tda998x_audio_digital_mute' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in
t; }
>
> - priv->drm.platformdev = to_platform_device(dev);
> priv->drm.dev_private = priv;
>
> - platform_set_drvdata(priv->drm.platformdev, &priv->drm);
> + dev_set_drvdata(dev, &priv->drm);
>
> INIT_WORK(&priv->
On Fri, Dec 30, 2016 at 05:33:38PM +0100, Daniel Vetter wrote:
> I reported the include issue for tracepoints a while ago, but nothing
> seems to have happened. Now it bit us, since the drm_mm_print
> conversion was broken for armada. Fix them both.
Nothing's happened because I haven't had an oppo
On Fri, May 13, 2016 at 12:33:36PM +0200, Lothar WaÃmann wrote:
> I'm always very suspicious when seeing code moving of_node's from
> one device to another or assigning of_node's to platform devices that
> weren't instantiated via DT.
It's completely wrong to add an of_node to a device on the sam
On Thu, May 26, 2016 at 10:53:30AM +0200, Maxime Ripard wrote:
> Hi Laurent,
>
> On Mon, May 16, 2016 at 04:24:15PM +0300, Laurent Pinchart wrote:
> > Hi Maxime,
> >
> > Thank you for the patch.
> >
> > On Monday 16 May 2016 14:47:13 Maxime Ripard wrote:
> > > +fallback:
> > > + /*
> > > + * In
On Thu, Feb 18, 2016 at 04:18:23PM +0100, Jean-Francois Moine wrote:
> On Thu, 18 Feb 2016 08:35:30 -0600
> Rob Herring wrote:
>
> > On Wed, Feb 17, 2016 at 04:49:05PM +0200, Jyri Sarha wrote:
> > > From: Jean-Francois Moine
> > >
> > > Two kinds of ports may be declared in a DT graph of ports:
On Mon, Feb 22, 2016 at 11:51:47AM +, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 02:22:04PM +, Liviu Dudau wrote:
> > Rockchip DRM driver cannot use the same compare_of() function to
> > match ports and remote ports (aka encoders) as their OF sub-trees
> > look different. Add a second com
On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
> On 02/18/16 16:35, Rob Herring wrote:
> >This should be implied from the port unit address. In other words,
> >port at 0 is defined to be the rgb port. Now, if this is one of several
> >modes for the video port, then that is a different
On Fri, Feb 26, 2016 at 12:14:44PM +0200, Jyri Sarha wrote:
> On 02/26/16 02:43, Russell King - ARM Linux wrote:
> >On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
> >>On 02/18/16 16:35, Rob Herring wrote:
> >>>This should be implied from the por
ect, thanks.
Acked-by: Russell King
Lucas,
I guess you'll be picking this patch up, or shall we ask David to take
it directly?
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Mon, Jan 04, 2016 at 03:13:22PM +0100, Lucas Stach wrote:
> Am Montag, den 04.01.2016, 13:54 + schrieb Russell King - ARM
> Linux:
> > On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote:
> > > We have to drop a lock before returning -ENOMEM here.
> > &
On Mon, Dec 07, 2015 at 03:01:43PM +, Russell King - ARM Linux wrote:
> Given the lack of interest in these patches, I've put these into my
> "for-next" branch so that they can get some exposure in linux-next.
These have been in for-next, and no one's reported a
On Tue, Jan 05, 2016 at 04:40:54PM +0100, Jean-Michel Hautbois wrote:
> Hi Russell,
>
> 2015-08-27 10:42 GMT+02:00 Philipp Zabel :
> >
> > Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM
> > Linux:
> > > Following on from the previous su
Some comments from an ARM architecture point of view. I haven't
reviewed it from a DRM point of view yet.
On Tue, Jan 05, 2016 at 07:40:11PM +0100, Jean-Francois Moine wrote:
> +struct tcon {
> + u32 gctl;
> +#define TCON_GCTL_TCON_En 0x8000
> + u32 gint0;
> +#define
On Fri, Jan 08, 2016 at 10:02:06AM +0100, Philipp Zabel wrote:
> Allow userspace to read the initial connector state via sysfs without
> having to issue a detect manually. There is no reason to keep the state
> unknown during initialization.
Can you describe how it can be unknown? I've always see
On Fri, Jan 08, 2016 at 10:02:07AM +0100, Philipp Zabel wrote:
> Due to the voltage divider on the HPD line, the HDMI connector on
> imx6q-sabrelite doesn't reliably detect connected DVI monitors.
> This patch allows to use the RX_SENSE signals as a workaround when
> enabled by a boolean device tre
On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote:
> The compiler will do this, but the void hits when grepping all the
> hooks for a subsystem wide audit are slightly annoying. So remove them
> for next time around.
I'll try to remember to queue this after -rc1, though a reminder
afte
On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote:
> On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote:
> > Add a helper for the EDID like data structure, which is typically passed
> > from a HDMI adapter to its associated audio driver. This informs the
> >
On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote:
> At Fri, 22 May 2015 14:15:35 +0100,
> Russell King - ARM Linux wrote:
> >
> > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote:
> > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrot
On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote:
> At Fri, 22 May 2015 14:53:31 +0100,
> Russell King - ARM Linux wrote:
> >
> > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote:
> > > At Fri, 22 May 2015 14:15:35 +0100,
> >
On Fri, May 22, 2015 at 04:05:22PM +0200, Takashi Iwai wrote:
> At Fri, 22 May 2015 16:02:13 +0200,
> Takashi Iwai wrote:
> > OK, if so, then I rebase on top of -rc1. The branch isn't merged yet,
> > so no big problem.
>
> Now the rebased branch is pushed.
>
> I also merged this branch now to fo
On Mon, May 25, 2015 at 10:17:25AM -0300, Fabio Estevam wrote:
> Use '%zd' for printing 'ssize_t' format in order to fix the following
> build warning on ARM64:
>
> drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_write_avi':
> drivers/gpu/drm/i2c/tda998x_drv.c:647:3: warning: format '%d' e
On Wed, May 27, 2015 at 12:43:08PM +0200, Daniel Vetter wrote:
> On Sat, May 09, 2015 at 11:26:57AM +0100, Russell King wrote:
> > Parse the ELD (EDID like data) stored from the HDMI driver to restrict
> > the sample rates and channels which are available to ALSA. This causes
>
On Wed, May 27, 2015 at 02:45:48PM +0200, Alexander Holler wrote:
> Hello,
>
> I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
You may wish to try using my patch set(s) at (url purposely obfuscated,
sorry):
http : // www . home . arm . linux . org . uk / ~rmk / cubox
On Wed, May 27, 2015 at 11:29:52PM +0200, Daniel Vetter wrote:
> The only issue that might be
> there with your sw approach is that a concurrent probe/hotplug in drm
> might free the edid and hence the eld, while the snd side is trying to
> copy that.
Talking only about the particular case of dw-h
On Wed, May 27, 2015 at 02:49:17PM +0200, Lucas Stach wrote:
> Hi Alexander,
>
> Am Mittwoch, den 27.05.2015, 14:45 +0200 schrieb Alexander Holler:
> > Hello,
> >
> > I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
> >
> > When I unload the driver with rmmod an oops ha
On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> drm/exynos_drm.h:30:2: error: unknown type name âuint64_tâ
>
> Signed-off-by: Mikko Rapeli
This is another thing which we need to address. We should not be using
unsigned int/unsigned lon
On Mon, Oct 19, 2015 at 04:07:47PM +0100, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote endpoint
On Mon, Nov 09, 2015 at 05:39:25PM +0800, Mark yao wrote:
> Hi Liviu
> Rockchip drm can't work with drm_of_component_probe function now,
>
> At drm_of_component_probe:
> component_match_add(dev, &match, compare_of, port);
> And original rockchip drm use:
>
801 - 900 of 2033 matches
Mail list logo
