Hi,
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixe
On Mon, Nov 21, 2016 at 06:23:24PM +, Liviu Dudau wrote:
> 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 seem
On Mon, Nov 21, 2016 at 02:30:53PM +, Russell King - ARM Linux wrote:
> 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_disabl
On Tue, Nov 22, 2016 at 08:51:11AM +0900, Gustavo Padovan wrote:
> 2016-11-21 Daniel Vetter :
> > /**
> > * drm_atomic_helper_commit_tail - commit atomic update to hardware
> > - * @state: new modeset state to be committed
> > + * @old_state: atomic state object with old state structures
> > *
On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +, 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 +, 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 +, 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 +, 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 King
> > ---
> > drivers/gpu/d
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
> Acked-by: Hans Verkuil
> S
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
> which has a much better internet connection, for most of the data:
>
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> cd linux
> git fetch https://git.pengutronix.de/git/pza/linux.git
> tags/v4.10-ipu-dp-plane-fix
> git checkout -b &quo
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
> > suggested that t
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 from Russell King:
>
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 *msg)
> > +{
> > + struct dw_
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, Russell King wrote:
> Add a CEC driver for t
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
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
; b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > index 68e895021005..06a4c584f3cb 100644
> > --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> > @@ -10,6 +10,7 @@
> >
> > #include
> > #include
> > +#include
> &g
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
d in my drm-tda998x-devel branch
as an unstable series of commits (iow, I'm going to rebase/rework these
at some point, so the commit IDs are not stable, so do not merge this.)
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
drivers/gpu/drm/i2c/tda998x_drv.c | 782
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
> &
On Wed, Sep 21, 2016 at 09:57:38AM +0100, Brian Starkey wrote:
> Hi Russell,
>
> Are you in a position to be able to test this now?
Normally, I'd say no, because I'd normally wait for 4.8 to be out before
moving the cubox tree up. However, as we're close to 4.8, I've merged
4.8-rc7 in (and fixed
ers where removing the
connector registration in tda998x causes them to break? It's a bit
late to be checking your own drivers when you've been chasing me...
Sorry, but it sounds like we're not ready to make this change - and as
it's the very last day that changes will appear in linu
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
On Sun, Sep 25, 2016 at 03:22:25PM +0800, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/armada/armada_gem.c:215:27: warning: no previous prototype
> for 'armada_gem_alloc_object' [-Wmissing-prototypes]
> drivers/gpu/drm/armada/armada_gem.c:423:1: warning: n
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
On Sun, Dec 18, 2016 at 12:39:16AM +0200, Laurent Pinchart wrote:
> The field contains a pointer to the parent platform device of the DRM
> device. As struct drm_device also contains a dev pointer to the struct
> device embedded in the platform_device structure, the platformdev field
> is redundant
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
On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote:
> We have to drop a lock before returning -ENOMEM here.
>
> Fixes: a8c21a5451d8 ('drm/etnaviv: add initial etnaviv DRM driver')
> Signed-off-by: Dan Carpenter
diffstat missing?
In any case, the patch is correct, thanks.
Acked-by: R
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
> > audio driver of 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,
> >
t; I also merged this branch now to for-next branch, so that it'll be
> tested through linux-next.
Thanks!
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
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
> > the ALSA device t
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
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
301 - 400 of 1611 matches
Mail list logo
