* [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Ondřej Jirman @ 2016-11-21 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121191416.706b80c25d476fa002a001b1@free.fr>
Dne 21.11.2016 v 19:14 Jean-Francois Moine napsal(a):
> On Mon, 21 Nov 2016 01:54:53 +0100
> Ond?ej Jirman <megous@megous.com> wrote:
>
>> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
>>> This patchset series adds HDMI video support to the Allwinner
>>> sun8i SoCs which include the display engine 2 (DE2).
>>> The driver contains the code for the A83T and H3, but it could be
>>> used/extended for other SoCs as the A64, H2 and H5.
>>
>> Hi,
>>
>> I'm trying to test your patches on Orange Pi PC, and I've run into a few
>> issues: (I'm using sunxi-ng with the same patches as last time, to make
>> it work with your driver)
>>
>> 1] I just get pink output on the monitor - there's some signal, but it's
>> pink (or more like magenta).
>>
>> dmesg ouput indicates no error:
>>
>> [ 1.887823] [drm] Initialized
>> [ 1.888503] sun8i-de2 1000000.de-controller: bound
>> 1c0c000.lcd-controller (ops 0xc0a63894)
>> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
>> 0xc0a63b54)
>> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 2.057307] [drm] No driver support for vblank timestamp query.
>> [ 2.690862] Console: switching to colour frame buffer device 240x67
>> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
> [snip]
>
> My H3 boards work correctly, except the Orange PI 2 when it cannot read
> the EDID (but it is OK after reboot).
>
> Did you check if the EDID was correctly read?
EDID is correctly read (I verified that it is the same as with the v5
version of the driver), but there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.
> Which resolution do you expect?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/1453ca53/attachment.sig>
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121181616.GN1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 06:16:16PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +0000, 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
> > 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> > the right thing is happening wrt disabling the controller:
>
> Here's my version of your patch:
Thanks! I'll add it to my tree and see if David Airlie is happy to push it
this late into the release cycle. Otherwise it is going to end up in linux-next
quickly and then in drm-next before v4.10.
>
> 8<=============
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
>
> 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 pixels _into_ the framebuffer.
>
> This occurs whenever the display mode size is changed - using xrandr
> in Xorg shows that changing the resolution triggers the problem
> almost every time, but changing the refresh rate does not.
>
> Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> and repeated disable/enable cycles do not make the issue re-appear.
> Further debugging shows that we try to update the controller
> configuration while enabled.
>
> Alwys ensure that the HDLCD is disabled prior to updating the
> controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
> so that DRM knows whether it can expect vblank interrupts.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index c239616f5334..9d683be2e5d3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> clk_prepare_enable(hdlcd->clk);
> hdlcd_crtc_mode_set_nofb(crtc);
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> + drm_crtc_vblank_on(crtc);
> }
>
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>
> - if (!crtc->state->active)
> - return;
> -
> + drm_crtc_vblank_off(crtc);
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> clk_disable_unprepare(hdlcd->clk);
> }
> --
> 2.7.4
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> 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! /
---------------
?\_(?)_/?
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121175602.GM1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +0000, 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 +0000, 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 +0000, 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 Daniel was commenting that this was not needed.
> > > > >
> > > > > Removing that test results in:
> > > > >
> > > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > > >
> > > > > and the kernel hanging, seemingly in an IRQs-off region.
> > > >
> > > > Right, I need to sort this one out. Are you doing these tests out of
> > > > some tagged branch that I can get in sync with?
> >
> > Hi Russell,
> >
> > >
> > > No, not yet, and some of the changes I have are rather hacky.
> > >
> > > I do always build my full tree of patches (which is currently running at
> > > around 320 patches at the moment) but I never share that entire patch
> > > set. However, none of those touch i2c (apart from the ones I've recently
> > > posted) and the only patches touching hdlcd are those I've posted so far.
> > >
> > > Most of the problems I'm finding are through trying basic stuff - I'm not
> > > doing anything special or unusual to find them, at the moment quite
> > > literally just starting Xorg up and shutting it down. For example, the
> > > above was caused by logging in on serial, running:
> > >
> > > Xorg -terminate -verbose
> > >
> > > and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> > > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > > up when the machine is booting for its nightly KVM boot tests.)
> > >
> > > I'm afraid that when I try someone elses code, I have a tendency to find
> > > loads of seemingly trivial bugs when I try putting it through some basic
> > > tests.
> >
> > I'm not being able to reproduce your bug conditions. I'm running the following
> > setup when testing:
> >
> > - mainline v4.9-rc6
> > - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
> > hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> > - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> > - modified the hdlcd_crtc.c file with the following patch:
> >
> > -8<-----------------------------------------------------------------------
> > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > index 48019ae..656dc43 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> > {
> > struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >
> > - if (!crtc->state->active)
> > - return;
> > -
> > + drm_crtc_vblank_off(crtc);
>
> Don't you need a drm_crtc_vblank_on() call in the enable function?
I do, thanks for calling me on that!
>
> > hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> > clk_disable_unprepare(hdlcd->clk);
> > }
> > ->8-----------------------------------------------------------------------
> >
> > That takes care of the pxlclk refcounting issue you were seeing. I've started
> > Xorg several times (and yes, I do see EDID checksum error every now and then,
> > specially when running xrandr). When closing down Xorg I get back the framebuffer
> > console with the login prompt and no image shifting.
>
> 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
> 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:
OK, so I'll take it that you did not also use your patch to fix the base plane
calculations, or was that included as well in your stack?
>
> [ 76.869136] hdlcd_crtc_disable: active 0
> [ 76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 85.262451] hdlcd_crtc_disable: active 0
> [ 85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 92.658038] hdlcd_crtc_disable: active 0
> [ 92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
> [ 97.805205] hdlcd_crtc_disable: active 0
> [ 97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
> [ 97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
> [ 97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
>
> > My monitor is a TV that
> > reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> > propertly with each other to be able to set the interlaced mode correctly, so
> > I've had to disable support for interlacing mode in tda998x_drv.c and now the
> > preferred mode that gets picked up is 1920x1200 at 60Hz.
>
> That's more of a generic DRM issue - the CRTC layer doesn't get a
> look-in when a connector parses the modes supplied from the display,
> so there's no real way for the CRTC layer to apply any kind of
> limitations to the available modes, except when a mode is attempted
> to be set.
>
> I don't want to see an "interlace" DT property introduced for the
> TDA998x, because that's the wrong approach - it would be adding a
> property for the needs of the implementation, and not a description
> of the hardware.
AFAICT the issue is the fact that while HDLCD could scan out the alternate
lines with a bit of a convoluted hack, there is no way to tell TDA19988
to generate the interlaced timings. And no, I'm not advocating introducing
a DT property as this is a runtime mode, depending on the resolution
selected by userspace.
>
> > Please advise on what other steps I can take to try to reproduce this.
>
> I guess if you've tried and failed to reproduce it, there is something
> very specific to my setup which I can't describe.
>
> > P.S: What revision of Juno do you have? Any chance you can capture the start
> > of the boot process where the firmware component prints the version numbers?
>
> All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
> (he spent _all_ of last Tuesday logged in to one of my systems trying
> to upgrade the firmware) is now running the Linaro 16.10 firmware.
> Sudeep says that my hardware is a very early revision which went out
> the door without being properly calibrated.
:) That is what you get for having special access to early samples of hardware :)
Might be worth asking your ARM contacts if a swap with an R2 is possible.
But, yes, my tests were also run on a Juno R0 (HBI0282B is just the R0 code)
and mine I'm pretty sure is earlier build than yours (board #13 no less).
>
> Whether that has any bearing on the reproducability of this or not, I've
> no idea.
The one factor that could affect it is the capability of the SCP firmware
to generate the exact pixel clock for your 1080p mode. If it doesn't, then
restoring the old mode might lead to an incorrect synchronisation with the
TDA chip. Current (less than 1.5 years old I guess) SCP firmware has that
sorted via an hdlcd.dat file that pre-calculates a lot of common pixel clock
frequencies).
Best regards,
Liviu
>
> If you want to see the boot messages, head to my autobuilder status page
> and look at the juno-kvm entries - they contain all the boot messages
> from initial power up of the juno. I'll send you a link in private
> mail so googlebot doesn't end up hammering on it after it expires.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> 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! /
---------------
?\_(?)_/?
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121175602.GM1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 05:56:02PM +0000, 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
> 1280x1024 and it behaves correctly. Indeed, my debug prints show that
> the right thing is happening wrt disabling the controller:
Here's my version of your patch:
8<=============
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] drm/arm: hdlcd: fix plane base address update
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 pixels _into_ the framebuffer.
This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.
Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.
Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index c239616f5334..9d683be2e5d3 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -151,15 +151,14 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
clk_prepare_enable(hdlcd->clk);
hdlcd_crtc_mode_set_nofb(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+ drm_crtc_vblank_on(crtc);
}
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
- if (!crtc->state->active)
- return;
-
+ drm_crtc_vblank_off(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
clk_disable_unprepare(hdlcd->clk);
}
--
2.7.4
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support
From: Jean-Francois Moine @ 2016-11-21 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1c9a02ff-ce6c-7ad7-36fa-8a2ea0b7675e@megous.com>
On Mon, 21 Nov 2016 01:54:53 +0100
Ond?ej Jirman <megous@megous.com> wrote:
> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3, but it could be
> > used/extended for other SoCs as the A64, H2 and H5.
>
> Hi,
>
> I'm trying to test your patches on Orange Pi PC, and I've run into a few
> issues: (I'm using sunxi-ng with the same patches as last time, to make
> it work with your driver)
>
> 1] I just get pink output on the monitor - there's some signal, but it's
> pink (or more like magenta).
>
> dmesg ouput indicates no error:
>
> [ 1.887823] [drm] Initialized
> [ 1.888503] sun8i-de2 1000000.de-controller: bound
> 1c0c000.lcd-controller (ops 0xc0a63894)
> [ 2.057298] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
> 0xc0a63b54)
> [ 2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 2.057307] [drm] No driver support for vblank timestamp query.
> [ 2.690862] Console: switching to colour frame buffer device 240x67
> [ 2.723059] sun8i-de2 1000000.de-controller: fb0: frame buffer device
[snip]
My H3 boards work correctly, except the Orange PI 2 when it cannot read
the EDID (but it is OK after reboot).
Did you check if the EDID was correctly read?
Which resolution do you expect?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Sudeep Holla @ 2016-11-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0f3bc66-6dfd-dcdc-a15d-a8f9fdda6048@arm.com>
Hi Robin,
On 21/11/16 17:47, Robin Murphy wrote:
> Hi Bartosz, Sekhar,
>
> On 21/11/16 16:48, Bartosz Golaszewski wrote:
[...]
>> Hi Sekhar,
>>
>> thanks for spotting that.
>>
>> I think we should introduce this function right away, rather than
>> having two static functions doing the same thing. If you don't mind,
>> I'll try to find a good spot for it and send a follow-up series fixing
>> the issue.
>
> As it happens, that was already proposed last week, for much the same
> reason:
>
> http://www.mail-archive.com/linuxppc-dev at lists.ozlabs.org/msg111395.html
>
Thanks for pointing this out, yet another platform to move to the new
API after v4.10.
Hi Shekar, Bartosz,
For v4.10, please continue with the open coding as proposed in this
thread in order to avoid cross tree dependencies. I will rework on the
above patch once v4.10 merge window closes to include all these
occurrence and replace them.
--
Regards,
Sudeep
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121173231.GM1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 05:32:32PM +0000, 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 +0000, 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 +0000, 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 Daniel was commenting that this was not needed.
> > > >
> > > > Removing that test results in:
> > > >
> > > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > > >
> > > > and the kernel hanging, seemingly in an IRQs-off region.
> > >
> > > Right, I need to sort this one out. Are you doing these tests out of
> > > some tagged branch that I can get in sync with?
>
> Hi Russell,
>
> >
> > No, not yet, and some of the changes I have are rather hacky.
> >
> > I do always build my full tree of patches (which is currently running at
> > around 320 patches at the moment) but I never share that entire patch
> > set. However, none of those touch i2c (apart from the ones I've recently
> > posted) and the only patches touching hdlcd are those I've posted so far.
> >
> > Most of the problems I'm finding are through trying basic stuff - I'm not
> > doing anything special or unusual to find them, at the moment quite
> > literally just starting Xorg up and shutting it down. For example, the
> > above was caused by logging in on serial, running:
> >
> > Xorg -terminate -verbose
> >
> > and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> > prompts on both the "framebuffer" and serial - I don't want Xorg coming
> > up when the machine is booting for its nightly KVM boot tests.)
> >
> > I'm afraid that when I try someone elses code, I have a tendency to find
> > loads of seemingly trivial bugs when I try putting it through some basic
> > tests.
>
> I'm not being able to reproduce your bug conditions. I'm running the following
> setup when testing:
>
> - mainline v4.9-rc6
> - edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
> hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
> - patched tda998x_drv.c to set interlace_allowed = 0, see below why
> - modified the hdlcd_crtc.c file with the following patch:
>
> -8<-----------------------------------------------------------------------
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 48019ae..656dc43 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
>
> - if (!crtc->state->active)
> - return;
> -
> + drm_crtc_vblank_off(crtc);
Don't you need a drm_crtc_vblank_on() call in the enable function?
> hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
> clk_disable_unprepare(hdlcd->clk);
> }
> ->8-----------------------------------------------------------------------
>
> That takes care of the pxlclk refcounting issue you were seeing. I've started
> Xorg several times (and yes, I do see EDID checksum error every now and then,
> specially when running xrandr). When closing down Xorg I get back the framebuffer
> console with the login prompt and no image shifting.
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
1280x1024 and it behaves correctly. Indeed, my debug prints show that
the right thing is happening wrt disabling the controller:
[ 76.869136] hdlcd_crtc_disable: active 0
[ 76.869159] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 76.888983] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 76.888995] hdlcd_crtc_enable: active 1 cmd 00000000
[ 85.262451] hdlcd_crtc_disable: active 0
[ 85.262474] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 85.286667] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 85.286679] hdlcd_crtc_enable: active 1 cmd 00000000
[ 92.658038] hdlcd_crtc_disable: active 0
[ 92.658057] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 92.680659] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 92.680668] hdlcd_crtc_enable: active 1 cmd 00000000
[ 97.805205] hdlcd_crtc_disable: active 0
[ 97.805220] hdlcd_plane_atomic_update: pitch 5120 lines 1024
[ 97.834415] hdlcd_plane_atomic_update: pitch 7680 lines 1080
[ 97.834423] hdlcd_crtc_enable: active 1 cmd 00000000
> My monitor is a TV that
> reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
> propertly with each other to be able to set the interlaced mode correctly, so
> I've had to disable support for interlacing mode in tda998x_drv.c and now the
> preferred mode that gets picked up is 1920x1200 at 60Hz.
That's more of a generic DRM issue - the CRTC layer doesn't get a
look-in when a connector parses the modes supplied from the display,
so there's no real way for the CRTC layer to apply any kind of
limitations to the available modes, except when a mode is attempted
to be set.
I don't want to see an "interlace" DT property introduced for the
TDA998x, because that's the wrong approach - it would be adding a
property for the needs of the implementation, and not a description
of the hardware.
> Please advise on what other steps I can take to try to reproduce this.
I guess if you've tried and failed to reproduce it, there is something
very specific to my setup which I can't describe.
> P.S: What revision of Juno do you have? Any chance you can capture the start
> of the boot process where the firmware component prints the version numbers?
All I know is that it's a HBI0282B, which thanks to Sudeep's efforts
(he spent _all_ of last Tuesday logged in to one of my systems trying
to upgrade the firmware) is now running the Linaro 16.10 firmware.
Sudeep says that my hardware is a very early revision which went out
the door without being properly calibrated.
Whether that has any bearing on the reproducability of this or not, I've
no idea.
If you want to see the boot messages, head to my autobuilder status page
and look at the juno-kvm entries - they contain all the boot messages
from initial power up of the juno. I'll send you a link in private
mail so googlebot doesn't end up hammering on it after it expires.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Robin Murphy @ 2016-11-21 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUXJi6PDq0qc-0+r2mLPASLpJUt_njWtXr4Mx4k0Fa82g@mail.gmail.com>
Hi Bartosz, Sekhar,
On 21/11/16 16:48, Bartosz Golaszewski wrote:
> 2016-11-21 17:33 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> +{
>>> + const struct da8xx_ddrctl_config_knob *knob;
>>> + const struct da8xx_ddrctl_setting *setting;
>>> + struct device_node *node;
>>> + struct resource *res;
>>> + void __iomem *ddrctl;
>>> + struct device *dev;
>>> + u32 reg;
>>> +
>>> + dev = &pdev->dev;
>>> + node = dev->of_node;
>>> +
>>> + setting = da8xx_ddrctl_get_board_settings();
>>> + if (!setting) {
>>> + dev_err(dev, "no settings for board '%s'\n",
>>> + of_flat_dt_get_machine_name());
>>> + return -EINVAL;
>>> + }
>>
>> This causes a section mismatch because of_flat_dt_get_machine_name()
>> has an __init annotation. I did not notice that before, sorry.
>>
>> It can be fixed with a patch like below:
>>
>> ---8<---
>> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
>> index a20e7bbbcbe0..9ca5aab3ac54 100644
>> --- a/drivers/memory/da8xx-ddrctl.c
>> +++ b/drivers/memory/da8xx-ddrctl.c
>> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
>> return NULL;
>> }
>>
>> +static const char* da8xx_ddrctl_get_machine_name(void)
>> +{
>> + const char *str;
>> + int ret;
>> +
>> + ret = of_property_read_string(of_root, "model", &str);
>> + if (ret)
>> + ret = of_property_read_string(of_root, "compatible", &str);
>> +
>> + return str;
>> +}
>> +
>> static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> {
>> const struct da8xx_ddrctl_config_knob *knob;
>> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> setting = da8xx_ddrctl_get_board_settings();
>> if (!setting) {
>> dev_err(dev, "no settings for board '%s'\n",
>> - of_flat_dt_get_machine_name());
>> + da8xx_ddrctl_get_machine_name());
>> return -EINVAL;
>> }
>> ---8<---
>>
>> A similar fix is required for the other driver in this series (patch
>> 2/5). I need some advise on whether I should introduce a common
>> function to get the machine name post kernel boot-up (I cannot see an
>> existing one). If yes, any advise on which file it should go into?
>>
>
> Hi Sekhar,
>
> thanks for spotting that.
>
> I think we should introduce this function right away, rather than
> having two static functions doing the same thing. If you don't mind,
> I'll try to find a good spot for it and send a follow-up series fixing
> the issue.
As it happens, that was already proposed last week, for much the same
reason:
http://www.mail-archive.com/linuxppc-dev at lists.ozlabs.org/msg111395.html
Robin.
>
> Best regards,
> Bartosz Golaszewski
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: David Lechner @ 2016-11-21 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTPxwxtE1xs1b6+sfwvRNKVLGKM-9Fjs3tVOSaBA+5Wnxg@mail.gmail.com>
On 11/21/2016 11:29 AM, Axel Haslam wrote:
> On Mon, Nov 21, 2016 at 6:04 PM, David Lechner <david@lechnology.com> wrote:
>> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>>
>>> This adds the DT node for the ohci controller and
>>> enables it for the omapl138-lckd platform.
>>>
>>> DEPENDENCIES:
>>>
>>> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
>>> https://lkml.org/lkml/2016/11/21/558
>>>
>>> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
>>> https://lkml.org/lkml/2016/11/4/465
>>>
>>> Axel Haslam (2):
>>> ARM: dts: da850: Add usb device node
>>> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>>>
>>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>> 2 files changed, 16 insertions(+)
>>>
>>
>> It does not look like you rebased these patches. Sekhar pushed the musb
>> counterpart to v4.10/dt yesterday, which will cause conflicts with this
>> series.
>>
>> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
>
> Hi David,
>
> i verified that they apply to the current linux-davinci/master.
> Anyways, i can rebase
> and resend once the dependencies are met, and we are ready to merge it.
>
> Regards
> Axel.
>
OK. I think the first patch is fine, but you will have two &usb_phy {
status = "okay"; }; in da850-lcdk.dts now even if applies cleanly. ;-)
^ permalink raw reply
* [PATCHv3 5/6] arm64: Use __pa_symbol for kernel symbols
From: Laura Abbott @ 2016-11-21 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118143543.GC1197@leverpostej>
On 11/18/2016 06:35 AM, Mark Rutland wrote:
> Hi Laura,
>
> On Thu, Nov 17, 2016 at 05:16:55PM -0800, Laura Abbott wrote:
>>
>> __pa_symbol is technically the marco that should be used for kernel
>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
>> will do bounds checking.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v3: Conversion of more sites besides just _end. Addition of __lm_sym_addr
>> macro to take care of the _va(__pa_symbol(..)) idiom.
>>
>> Note that a copy of __pa_symbol was added to avoid a mess of headers
>> since the #ifndef __pa_symbol case is defined in linux/mm.h
>
> I think we also need to fix up virt_to_phys(__cpu_soft_restart) in
> arch/arm64/kernel/cpu-reset.h. Otherwise, this looks complete for uses
> falling under arch/arm64/.
>
> I also think it's worth mentioning in the commit message that this patch
> adds and __lm_sym_addr() and uses it in some places so that low-level
> helpers can use virt_to_phys() or __pa() consistently.
>
> The PSCI change doesn't conflict with patches [1] that'll go via
> arm-soc, so I'm happy for that PSCI change to go via the arm64 tree,
> though it may be worth splitting into its own patch just in case
> something unexpected crops up.
>
> With those fixed up:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/466522.html
>
> Otherwise, I just have a few nits below.
>
>> @@ -271,7 +271,7 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
>> kvm_flush_dcache_to_poc(page_address(page), PUD_SIZE);
>> }
>>
>> -#define kvm_virt_to_phys(x) __virt_to_phys((unsigned long)(x))
>> +#define kvm_virt_to_phys(x) __pa_symbol((unsigned long)(x))
>
> Nit: we can drop the unsigned long cast given __pa_symbol() contains
> one.
>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index ffbb9a5..c2041a3 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -52,7 +52,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
>> * for zero-mapped memory areas etc..
>> */
>> extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>> -#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa(empty_zero_page)))
>> +#define ZERO_PAGE(vaddr) pfn_to_page(PHYS_PFN(__pa_symbol(empty_zero_page)))
>
> Nit: I think we can also simplify this to:
>
> phys_to_page(__pa_symbol(empty_zero_page))
>
> ... since phys_to_page(p) is (pfn_to_page(__phys_to_pfn(p)))
> ... and __phys_to_pfn(p) is PHYS_PFN(p)
>
>> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>> index 6f2ac4f..af8967a 100644
>> --- a/arch/arm64/kernel/insn.c
>> +++ b/arch/arm64/kernel/insn.c
>> @@ -97,7 +97,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
>> if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
>> page = vmalloc_to_page(addr);
>> else if (!module)
>> - page = pfn_to_page(PHYS_PFN(__pa(addr)));
>> + page = pfn_to_page(PHYS_PFN(__pa_symbol(addr)));
>
> Nit: likewise, we can use phys_to_page() here.
>
>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>> index a2c2478..791e87a 100644
>> --- a/arch/arm64/kernel/vdso.c
>> +++ b/arch/arm64/kernel/vdso.c
>> @@ -140,11 +140,11 @@ static int __init vdso_init(void)
>> return -ENOMEM;
>>
>> /* Grab the vDSO data page. */
>> - vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa(vdso_data)));
>> + vdso_pagelist[0] = pfn_to_page(PHYS_PFN(__pa_symbol(vdso_data)));
>
> Nit: phys_to_page() again.
>
>>
>> /* Grab the vDSO code pages. */
>> for (i = 0; i < vdso_pages; i++)
>> - vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) + i);
>> + vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa_symbol(&vdso_start)) + i);
>
> Nit: phys_to_page() again.
I think it makes sense to keep this one as is. It's offsetting
by pfn number and trying force phys_to_page would make it more
difficult to read.
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [PATCH] ARM: dts: AM571x-IDK Initial Support
From: Rob Herring @ 2016-11-21 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121055801.573-1-lokeshvutla@ti.com>
On Mon, Nov 21, 2016 at 11:28:01AM +0530, Lokesh Vutla wrote:
> From: Schuyler Patton <spatton@ti.com>
>
> The AM571x-IDK board is a board based on TI's AM5718 SOC
> which has a single core 1.5GHz A15 processor. This board is a
> development platform for the Industrial market with:
> - 1GB of DDR3L
> - Dual 1Gbps Ethernet
> - HDMI,
> - PRU-ICSS
> - uSD
> - 16GB eMMC
> - CAN
> - RS-485
> - PCIe
> - USB3.0
> - Video Input Port
> - Industrial IO port and expansion connector
>
> The link to the data sheet and TRM can be found here:
>
> http://www.ti.com/product/AM5718
>
> Initial support is only for basic peripherals.
>
> Signed-off-by: Schuyler Patton <spatton@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
>
> Logs: http://pastebin.ubuntu.com/23510390/
>
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am571x-idk.dts | 82 ++++++++++++++++++++++
> 3 files changed, 86 insertions(+)
> create mode 100644 arch/arm/boot/dts/am571x-idk.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index f53e2ee..647ffd3 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -175,6 +175,9 @@ Boards:
> - AM5728 IDK
> compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
>
> +- AM5718 IDK
> + compatible = "ti,am5718-idk", "ti,am5728", "ti,dra722", "ti,dra72", "ti,dra7"
I've said this before I think, but 5 compat string is a bit much. Some
of these genericish ones should be dropped. Doesn't really hurt though.
A couple of nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
> +
> - DRA742 EVM: Software Development Board for DRA742
> compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..c298078 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -588,6 +588,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
> am57xx-cl-som-am57x.dtb \
> am57xx-sbc-am57x.dtb \
> am572x-idk.dtb \
> + am571x-idk.dtb \
> dra7-evm.dtb \
> dra72-evm.dtb \
> dra72-evm-revc.dtb
> diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
> new file mode 100644
> index 0000000..a6a743e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am571x-idk.dts
> @@ -0,0 +1,82 @@
> +/*
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "dra72x.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "am57xx-idk-common.dtsi"
> +
> +/ {
> + model = "TI AM5718 IDK";
> + compatible = "ti,am5718-idk", "ti,am5718", "ti,dra722",
> + "ti,dra72", "ti,dra7";
> +
> + memory at 0 {
unit address is wrong.
> + device_type = "memory";
> + reg = <0x0 0x80000000 0x0 0x40000000>;
> + };
> +
> + status-leds {
Just "leds"
> + compatible = "gpio-leds";
> + cpu0-led {
> + label = "status0:red:cpu0";
> + gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "cpu0";
> + };
> +
> + usr0-led {
> + label = "status0:green:usr";
> + gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + heartbeat-led {
> + label = "status0:blue:heartbeat";
> + gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + usr1-led {
> + label = "status1:red:usr";
> + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + usr2-led {
> + label = "status1:green:usr";
> + gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + mmc0-led {
> + label = "status1:blue:mmc0";
> + gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> + };
> +
> + extcon_usb2: extcon_usb2 {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = <&gpio5 7 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&mmc1 {
> + status = "okay";
> + vmmc-supply = <&ldo1_reg>;
> + bus-width = <4>;
> + cd-gpios = <&gpio6 27 0>; /* gpio 219 */
> +};
> +
> +&omap_dwc3_2 {
> + extcon = <&extcon_usb2>;
> +};
> --
> 2.10.1
>
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121140349.GG1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +0000, 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 +0000, 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 Daniel was commenting that this was not needed.
> > >
> > > Removing that test results in:
> > >
> > > [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> > >
> > > and the kernel hanging, seemingly in an IRQs-off region.
> >
> > Right, I need to sort this one out. Are you doing these tests out of
> > some tagged branch that I can get in sync with?
Hi Russell,
>
> No, not yet, and some of the changes I have are rather hacky.
>
> I do always build my full tree of patches (which is currently running at
> around 320 patches at the moment) but I never share that entire patch
> set. However, none of those touch i2c (apart from the ones I've recently
> posted) and the only patches touching hdlcd are those I've posted so far.
>
> Most of the problems I'm finding are through trying basic stuff - I'm not
> doing anything special or unusual to find them, at the moment quite
> literally just starting Xorg up and shutting it down. For example, the
> above was caused by logging in on serial, running:
>
> Xorg -terminate -verbose
>
> and then hitting ^C. (I have lxdm disabled so systemd boots to VT login
> prompts on both the "framebuffer" and serial - I don't want Xorg coming
> up when the machine is booting for its nightly KVM boot tests.)
>
> I'm afraid that when I try someone elses code, I have a tendency to find
> loads of seemingly trivial bugs when I try putting it through some basic
> tests.
I'm not being able to reproduce your bug conditions. I'm running the following
setup when testing:
- mainline v4.9-rc6
- edited the juno-base.dtsi file to disable the hdlcd at 7f600000 and
hdmi-transmitter at 70 nodes to remove the second HDMI output from the test.
- patched tda998x_drv.c to set interlace_allowed = 0, see below why
- modified the hdlcd_crtc.c file with the following patch:
-8<-----------------------------------------------------------------------
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae..656dc43 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -156,9 +156,7 @@ static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
- if (!crtc->state->active)
- return;
-
+ drm_crtc_vblank_off(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
clk_disable_unprepare(hdlcd->clk);
}
->8-----------------------------------------------------------------------
That takes care of the pxlclk refcounting issue you were seeing. I've started
Xorg several times (and yes, I do see EDID checksum error every now and then,
specially when running xrandr). When closing down Xorg I get back the framebuffer
console with the login prompt and no image shifting. My monitor is a TV that
reports that preferred mode is 1080i, however HDLCD and TDA19988 don't talk
propertly with each other to be able to set the interlaced mode correctly, so
I've had to disable support for interlacing mode in tda998x_drv.c and now the
preferred mode that gets picked up is 1920x1200 at 60Hz.
Please advise on what other steps I can take to try to reproduce this.
P.S: What revision of Juno do you have? Any chance you can capture the start
of the boot process where the firmware component prints the version numbers?
Best regards,
Liviu
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> 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! /
---------------
?\_(?)_/?
^ permalink raw reply related
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2013ba47-e7e4-045e-0232-4ebd7450c3ad@ti.com>
2016-11-21 18:26 GMT+01:00 Jyri Sarha <jsarha@ti.com>:
> On 11/21/16 19:16, Bartosz Golaszewski wrote:
>> It has been determined that the highest resolution supported correctly
>> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
>> crtc_max_width().
>>
>
> I don't think this is the right way to limit the supported video modes.
> There is technically there is no such limit, is there?
>
> If memory bandwidth is limiting the functionality of higher resolutions,
> you should use "max-bandwidth" tilcdc device-tree property [1].
>
> Cheers,
> Jyri
>
Will do, thanks.
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2016-11-21 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d414c4d-3d08-f3d9-2bc5-aa90c8a631ce@lechnology.com>
On Mon, Nov 21, 2016 at 6:04 PM, David Lechner <david@lechnology.com> wrote:
> On 11/21/2016 10:59 AM, Axel Haslam wrote:
>>
>> This adds the DT node for the ohci controller and
>> enables it for the omapl138-lckd platform.
>>
>> DEPENDENCIES:
>>
>> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
>> https://lkml.org/lkml/2016/11/21/558
>>
>> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
>> https://lkml.org/lkml/2016/11/4/465
>>
>> Axel Haslam (2):
>> ARM: dts: da850: Add usb device node
>> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>>
>> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>> 2 files changed, 16 insertions(+)
>>
>
> It does not look like you rebased these patches. Sekhar pushed the musb
> counterpart to v4.10/dt yesterday, which will cause conflicts with this
> series.
>
> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
Hi David,
i verified that they apply to the current linux-davinci/master.
Anyways, i can rebase
and resend once the dependencies are met, and we are ready to merge it.
Regards
Axel.
^ permalink raw reply
* pull request: linux-firmware: Update Mediatek MT8173 VPU firmware
From: Kyle McMartin @ 2016-11-21 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478866149-2023-1-git-send-email-andrew-ct.chen@mediatek.com>
On Fri, Nov 11, 2016 at 08:09:08PM +0800, Andrew-CT Chen wrote:
> Hi linux-firmware maintainers,
>
> The following changes since commit a179db97914da5e650c21ba8f9b0bae04a0f8a41:
>
> amdgpu: update SMC firmware for VI parts (2016-10-05 10:30:11 -0700)
>
> are available in the git repository at:
>
> https://github.com/andrewct-chen/linux_fw_vpu_v1.0.3.git v1.0.3
>
pulled, thanks.
--kyle
^ permalink raw reply
* [PATCH] arm64: dts: r8a7796: Add all MSIOF nodes
From: Geert Uytterhoeven @ 2016-11-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
Add the device nodes for all MSIOF SPI controllers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Tested with MSIOF2(B) on EXIO connector D of r8a7796/salvator-x, using
spidev, gpio-74x164, and a logic analyzer.
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 54 ++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d2f1925552..c34c684088542850 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -368,6 +368,60 @@
status = "disabled";
};
+ msiof0: spi at e6e90000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6e90000 0 0x0064>;
+ interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 211>;
+ dmas = <&dmac1 0x41>, <&dmac1 0x40>,
+ <&dmac2 0x41>, <&dmac2 0x40>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof1: spi at e6ea0000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6ea0000 0 0x0064>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 210>;
+ dmas = <&dmac1 0x43>, <&dmac1 0x42>,
+ <&dmac2 0x43>, <&dmac2 0x42>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof2: spi at e6c00000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c00000 0 0x0064>;
+ interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 209>;
+ dmas = <&dmac0 0x45>, <&dmac0 0x44>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ msiof3: spi at e6c10000 {
+ compatible = "renesas,msiof-r8a7796";
+ reg = <0 0xe6c10000 0 0x0064>;
+ interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 208>;
+ dmas = <&dmac0 0x47>, <&dmac0 0x46>;
+ dma-names = "tx", "rx";
+ power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7796",
"renesas,rcar-dmac";
--
1.9.1
^ permalink raw reply related
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Jyri Sarha @ 2016-11-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-2-git-send-email-bgolaszewski@baylibre.com>
On 11/21/16 19:16, Bartosz Golaszewski wrote:
> It has been determined that the highest resolution supported correctly
> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
> crtc_max_width().
>
I don't think this is the right way to limit the supported video modes.
There is technically there is no such limit, is there?
If memory bandwidth is limiting the functionality of higher resolutions,
you should use "max-bandwidth" tilcdc device-tree property [1].
Cheers,
Jyri
[1] In "Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt":
Optional properties:
- max-bandwidth: The maximum pixels per second that the memory
interface / lcd controller combination can sustain
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index dfe3dd0..9081de5 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -683,7 +683,7 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
> int max_width = 0;
>
> if (priv->rev == 1)
> - max_width = 1024;
> + max_width = 800;
> else if (priv->rev == 2)
> max_width = 2048;
>
>
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Gabriele Paoloni @ 2016-11-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121164700.GL25762@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn
> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-
> owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: 21 November 2016 16:47
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> Subject: Re: [PATCH] PCI: Add information about describing PCI in ACPI
>
> On Mon, Nov 21, 2016 at 08:52:52AM +0000, Gabriele Paoloni wrote:
> > Hi Bjorn
> >
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > > Sent: 18 November 2016 17:54
> > > To: Gabriele Paoloni
> > > Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> > > acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > > kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> > > Subject: Re: [PATCH] PCI: Add information about describing PCI in
> ACPI
> > >
> > > On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > > > > -----Original Message-----
> > > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > > > Sent: 17 November 2016 18:00
> > >
> > > > > +Static tables like MCFG, HPET, ECDT, etc., are *not*
> mechanisms
> > > for
> > > > > +reserving address space! The static tables are for things the
> OS
> > > > > +needs to know early in boot, before it can parse the ACPI
> > > namespace.
> > > > > +If a new table is defined, an old OS needs to operate
> correctly
> > > even
> > > > > +though it ignores the table. _CRS allows that because it is
> > > generic
> > > > > +and understood by the old OS; a static table does not.
> > > >
> > > > Right so if my understanding is correct you are saying that
> resources
> > > > described in the MCFG table should also be declared in PNP0C02
> > > devices
> > > > so that the PNP driver can reserve these resources.
> > >
> > > Yes.
> > >
> > > > On the other side the PCI Root bridge driver should not reserve
> such
> > > > resources.
> > > >
> > > > Well if my understanding is correct I think we have a problem
> here:
> > > > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
> > > >
> > > > As you can see pci_ecam_create() will conflict with the pnp
> driver
> > > > as it will try to reserve the resources from the MCFG table...
> > > >
> > > > Maybe we need to rework pci_ecam_create() ?
> > >
> > > I think it's OK as it is.
> > >
> > > The pnp/system.c driver does try to reserve PNP0C02 resources, and
> it
> > > marks them as "not busy". That way they appear in /proc/iomem and
> > > won't be allocated for anything else, but they can still be
> requested
> > > by drivers, e.g., pci/ecam.c, which will mark them "busy".
> > >
> > > This is analogous to what the PCI core does in
> pci_claim_resource().
> > > This is really a function of the ACPI/PNP *core*, which should
> reserve
> > > all _CRS resources for all devices (not just PNP0C02 devices). But
> > > it's done by pnp/system.c, and only for PNP0C02, because there's a
> > > bunch of historical baggage there.
> > >
> > > You'll also notice that in this case, things are out of order:
> > > logically the pnp/system.c reservation should happen first, but in
> > > fact the pci/ecam.c request happens *before* the pnp/system.c one.
> > > That means the pnp/system.c one might fail and complain "[mem ...]
> > > could not be reserved".
> >
> > Correct me if I am wrong...
> >
> > So currently we are relying on the fact that pci_ecam_create() is
> called
> > before the pnp driver.
> > If the pnp driver came first we would end up in pci_ecam_create()
> failing
> > here:
> > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L76
> >
> > I am not sure but it seems to me like a bit weak condition to rely
> on...
> > what about removing the error condition in pci_ecam_create() and
> logging
> > just a dev_info()?
>
> Huh. I'm confused. I *thought* it would be safe to reverse the
> order, which would effectively be this:
>
> system_pnp_probe
> reserve_resources_of_dev
> reserve_range
> request_mem_region([mem 0xb0000000-0xb1ffffff])
> ...
> pci_ecam_create
> request_resource_conflict([mem 0xb0000000-0xb1ffffff])
>
>
> but I experimented with the patch below on qemu, and it failed as you
> predicted:
>
> ** res test **
> requested [mem 0xa0000000-0xafffffff]
> can't claim ECAM area [mem 0xa0000000-0xafffffff]: conflict with ECAM
> PNP [mem 0xa0000000-0xafffffff]
>
> I expected the request_resource_conflict() to succeed since it's
> completely contained in the "ECAM PNP" region. But I guess I don't
> understand kernel/resource.c well enough.
I think it fails because effectively the PNP driver is populating the
iomem_resource resource tree and therefore pci_ecam_create() finds that
it cannot add the cfg resource to the same hierarchy as it is already
there...
>
> I'm not sure we need to fix anything yet, since we currently do the
> ecam.c request before the system.c one, and any change there would be
> a long ways off. If/when that *does* change, I think the correct fix
> would be to change ecam.c so its request succeeds (by changing the way
> it does the request, fixing kernel/resource.c, or whatever) rather
> than to reduce the log level and ignore the failure.
Well in my mind I didn't want just to make the error disappear...
If all the resources should be reserved by the PNP driver then ideally
we could take away request_resource_conflict() from pci_ecam_create(),
but this would make buggy some systems with an already shipped BIOS
that relied on pci_ecam_create() reservation rather than PNP reservation.
Just removing the error condition and converting dev_err() into
dev_info() seems to me like accommodating already shipped BIOS images
and flagging a reservation that is already done by somebody else
without compromising the functionality of the PCI Root bridge driver
(so far the only reason why I can see the error condition there is
to catch a buggy MCFG with overlapping addresses; so if this is the
case maybe we need to have a different diagnostic check to make sure
that the MCFG table is alright)
BTW if you think that so far we can keep this as it is I am ok.
Many Thanks
Gab
>
> Bjorn
>
>
> diff --git a/arch/x86/pci/init.c b/arch/x86/pci/init.c
> index adb62aa..5a35638 100644
> --- a/arch/x86/pci/init.c
> +++ b/arch/x86/pci/init.c
> @@ -7,6 +7,8 @@
> in the right sequence from here. */
> static __init int pci_arch_init(void)
> {
> + struct resource *res, *conflict;
> + static struct resource cfg;
> #ifdef CONFIG_PCI_DIRECT
> int type = 0;
>
> @@ -39,6 +41,26 @@ static __init int pci_arch_init(void)
>
> dmi_check_skip_isa_align();
>
> + printk("\n** res test **\n");
> +
> + res = request_mem_region(0xa0000000, 0x10000000, "ECAM PNP");
> + printk("requested %pR\n", res);
> + if (!res)
> + return 0;
> + res->flags &= ~IORESOURCE_BUSY;
> +
> + cfg.start = 0xa0000000;
> + cfg.end = 0xafffffff;
> + cfg.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + cfg.name = "PCI ECAM";
> +
> + conflict = request_resource_conflict(&iomem_resource, &cfg);
> + if (conflict)
> + printk("can't claim ECAM area %pR: conflict with %s %pR\n",
> + &cfg, conflict->name, conflict);
> +
> + printk("\n");
> +
> return 0;
> }
> arch_initcall(pci_arch_init);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] coresight: perf: Add a missing call to etm_free_aux
From: Mathieu Poirier @ 2016-11-21 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119174124.20136-1-lambert.quentin@gmail.com>
On Sat, Nov 19, 2016 at 06:41:24PM +0100, Quentin Lambert wrote:
> Most error branches following the call to alloc_event_data contain a call to
> etm_free_aux. This patch add a call to etm_free_aux to an error branch
> that does not call it.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -215,7 +215,7 @@ static void *etm_setup_aux(int event_cpu
> */
> sink = coresight_get_enabled_sink(true);
> if (!sink)
> - return NULL;
> + goto err;
>
> INIT_WORK(&event_data->work, free_event_data);
>
Applied, after wrapping the commit log to 75 characters or less.
Please run checkpatch.pl on your next submission and compiling
your work before sending a patches is highly suggested.
Thanks,
Mathieu
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-1-git-send-email-bgolaszewski@baylibre.com>
It has been determined that the highest resolution supported correctly
by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
crtc_max_width().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index dfe3dd0..9081de5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -683,7 +683,7 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
int max_width = 0;
if (priv->rev == 1)
- max_width = 1024;
+ max_width = 800;
else if (priv->rev == 2)
max_width = 2048;
--
2.9.3
^ permalink raw reply related
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
While debugging the drm_bridge support for revision 1 I noticed the
driver was selecting the 1024x768 resolution as default from the set
retrieved from EDID. The following patch reduces the max_width for
rev1 in tilcdc.
Bartosz Golaszewski (1):
drm: tilcdc: reduce max_width for revision 1
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH v4 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC
From: Rob Herring @ 2016-11-21 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479638740-20520-2-git-send-email-hao5781286@gmail.com>
On Sun, Nov 20, 2016 at 06:45:38PM +0800, Hao Zhang wrote:
> This add the property of Allwinner sun50i A64 dma.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The new Amlogic GXM SoC (S912) is part of the Meson GX family and is nearly
> identical to GXM but with a second Quad-A53 core cluster.
>
> The GXM dtsi includes the GXL dtsi and the p20x dtsi is refactored in a
> common p20x/q20x to support the GXM Q200 and Q201 board that uses the exact
> same board layout since the S905D and S912 are pinout compatible.
>
> The last patch adds support for the Nexbox A1 Set-Top-Box based on the S912.
>
> Changes since RFC :
> - Refactor the p20x/q20x dtsi into a single common file
> - Add support for Nexbox A1
Thanks for refactoring. Looks great.
Applied.
Kevin
^ permalink raw reply
* [PATCH v2 3/3] usb: ohci-da8xx: rename driver to ohci-da8xx
From: Axel Haslam @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-4-ahaslam@baylibre.com>
Hi Greg,
On Thu, Nov 3, 2016 at 5:03 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The davinci ohci driver name (currently "ohci") is too generic.
> To be consistent with other usb dirvers, append the "-da8xx" postfix
> to the name.
>
if there are no objections, would it be possible to pick up this patch?
the corresponding phy patch was merged and the platform changes
are ack'ed, and will we taken by the davinci maintainer once this patch
gets in.
i can resend stand-alone if its preferred.
Regards
Axel
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> drivers/usb/host/ohci-da8xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index 30c4878..429d58b 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -27,7 +27,7 @@
> #include "ohci.h"
>
> #define DRIVER_DESC "DA8XX"
> -#define DRV_NAME "ohci"
> +#define DRV_NAME "ohci-da8xx"
>
> static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
>
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH v6 2/5] drm: sun8i: add HDMI video support to A83T and H3
From: Rob Herring @ 2016-11-21 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cea6a5397664213c6a917028ec2e429d25972490.1479641523.git.moinejf@free.fr>
On Sun, Nov 20, 2016 at 10:56:23AM +0100, Jean-Francois Moine wrote:
> This patch adds a HDMI video driver to the Allwinner's SoCs A83T and H3.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 53 ++
> drivers/gpu/drm/sun8i/Kconfig | 7 +
> drivers/gpu/drm/sun8i/Makefile | 2 +
> drivers/gpu/drm/sun8i/de2_hdmi.c | 394 ++++++++++
> drivers/gpu/drm/sun8i/de2_hdmi.h | 51 ++
> drivers/gpu/drm/sun8i/de2_hdmi_io.c | 839 +++++++++++++++++++++
> 6 files changed, 1346 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> new file mode 100644
> index 0000000..85709ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> @@ -0,0 +1,53 @@
> +Allwinner HDMI Transmitter
> +==========================
> +
> +The Allwinner HDMI transmitters are included in the SoCs.
> +They support audio and video.
> +
> +Required properties:
> + - #address-cells : should be <1>
> + - #size-cells : should be <0>
> + - compatible : should be one of
> + "allwinner,sun8i-a83t-hdmi"
> + "allwinner,sun8i-h3-hdmi"
> + - clocks : phandles to the HDMI clocks as described in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - clock-names : must be
> + "gate" : bus gate
> + "clock" : streaming clock
> + "ddc-clock" : DDC clock
> + - resets : One or two phandles to the HDMI resets
> + - reset-names : when 2 phandles, must be
> + "hdmi0" and "hdmi1"
> +
> +Required nodes:
> + - port: Audio and video input port nodes with endpoint definitions
> + as defined in Documentation/devicetree/bindings/graph.txt.
> + port at 0 is video and port at 1 is audio.
This should probably also have an output port to the hdmi-connector
binding. It is not needed so much if this block handles DDC and HPD
itself, but if those are a separate I2C controller and GPIO,
respectively, then you need it for sure. There's also power on the
connector or other connectors like muxed on Type-C.
> +
> +Example:
> +
> + hdmi: hdmi at 01ee0000 {
> + compatible = "allwinner,sun8i-a83t-hdmi";
> + reg = <0x01ee0000 0x20000>;
> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
> + <&ccu CLK_HDMI_DDC>;
> + clock-names = "gate", "clock", "ddc-clock";
> + resets = <&ccu RST_HDMI0>, <&ccu RST_HDMI1>;
> + reset-names = "hdmi0", "hdmi1";
> + ...
Please show all properties in example.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 0 { /* video */
> + reg = <0>;
> + hdmi_lcd1: endpoint {
> + remote-endpoint = <&lcd1_hdmi>;
> + };
> + };
> + port at 1 { /* audio */
> + reg = <1>;
> + hdmi_i2s2: endpoint {
> + remote-endpoint = <&i2s2_hdmi>;
> + };
> + };
> + };
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox