Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878
Hi Laurent,
On 2018-04-04 00:11, Laurent Pinchart wrote:
>> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
>> +{
>> +struct dma_device *dma_dev = dmm->wa_dma_chan->device;
>> +struct dma_async_tx_descriptor *tx;
>> +enum dma_status status;
>> +dma_cookie_t cookie;
>> +
>> +tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
>> +if (!tx) {
>> +dev_err(dmm->dev, "Failed to prepare DMA memcpy\n");
>> +return -EIO;
>> +}
>> +
>> +cookie = tx->tx_submit(tx);
>> +if (dma_submit_error(cookie)) {
>> +dev_err(dmm->dev, "Failed to do DMA tx_submit\n");
>> +return -EIO;
>> +}
>> +
>> +dma_async_issue_pending(dmm->wa_dma_chan);
>> +status = dma_sync_wait(dmm->wa_dma_chan, cookie);
>
> dma_sync_wait() has a 5s timeout. You're calling this function with a
> spinlock
> held. The end result might be slightly better than a complete system lock as
> caused by the bug described in i878, but only slightly.
>
> Unless I'm mistaken the reason you can't sleep here is because of the need to
> access registers in the interrupt handler. Could we use threaded IRQs to
> solve
> this ?
You are right that dma_sync_wait() have 5s timeout. But it is theoretical in
this case as the DMA would finish the transfer way faster. As and experiment I
have tried this change:
@@ -86,6 +87,7 @@ static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src,
dma_addr_t dst)
struct dma_async_tx_descriptor *tx;
enum dma_status status;
dma_cookie_t cookie;
+ unsigned int tout = 0;
tx = dma_dev->device_prep_dma_memcpy(dmm->wa_dma_chan, dst, src, 4, 0);
if (!tx) {
@@ -99,10 +101,19 @@ static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src,
dma_addr_t dst)
return -EIO;
}
+ dev_err(dmm->dev, "i878 dma_async_issue_pending()\n");
dma_async_issue_pending(dmm->wa_dma_chan);
- status = dma_sync_wait(dmm->wa_dma_chan, cookie);
+ do {
+ status = dmaengine_tx_status(dmm->wa_dma_chan, cookie, NULL);
+ if (status == DMA_COMPLETE)
+ break;
+ cpu_relax();
+ } while (tout++ < 50);
+
if (status != DMA_COMPLETE)
dev_err(dmm->dev, "i878 wa DMA copy failure\n");
+ else
+ dev_err(dmm->dev, "i878 wa DMA copy OK (tout: %u)\n", tout);
dmaengine_terminate_all(dmm->wa_dma_chan);
return 0;
@@ -286,6 +298,7 @@ static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
u32 status = dmm_read(dmm, DMM_PAT_IRQSTATUS);
int i;
+ dev_err(dmm->dev, "%s - ENTER\n", __func__);
/* ack IRQ */
dmm_write(dmm, status, DMM_PAT_IRQSTATUS);
@@ -305,6 +318,7 @@ static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
status >>= 8;
}
+ dev_err(dmm->dev, "%s - LEAVE\n", __func__);
return IRQ_HANDLED;
}
and get:
[ 58.690093 <0.005598>] dmm 4e00.dmm: omap_dmm_irq_handler - ENTER
[ 58.695601 <0.005508>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.701284 <0.005683>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[ 58.706881 <0.005597>] dmm 4e00.dmm: omap_dmm_irq_handler - LEAVE
[ 58.712465 <0.005584>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.718150 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[ 58.724575 <0.006425>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.730260 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[ 58.735872 <0.005612>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.741554 <0.005682>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[ 58.747174 <0.005620>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.752857 <0.005683>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[ 58.758452 <0.005595>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.764137 <0.005685>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[ 58.769731 <0.005594>] dmm 4e00.dmm: omap_dmm_irq_handler - ENTER
[ 58.775237 <0.005506>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.780919 <0.005682>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 2)
[ 58.786515 <0.005596>] dmm 4e00.dmm: omap_dmm_irq_handler - LEAVE
[ 58.786545 <0.30>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.797698 <0.011153>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 1)
[ 58.811454 <0.013756>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.817149 <0.005695>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[ 58.823160 <0.006011>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.828846 <0.005686>] dmm 4e00.dmm: i878 wa DMA copy OK (tout: 0)
[ 58.834761 <0.005915>] dmm 4e00.dmm: i878 dma_async_issue_pending()
[ 58.84
Re: AMD graphics performance regression in 4.15 and later
Am 09.04.2018 um 17:17 schrieb Jean-Marc Valin: On 04/09/2018 05:42 AM, Christian König wrote: Backporting all the detection logic is to invasive, but you could just go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other code path. Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. Do you mean just taking the 4.15 code as is and replacing "#ifdef CONFIG_SWIOTLB" with "#if 0" in drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c or are you talking about using a different version of drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c ? Yes, exactly. The code then won't work any more on some ARMs or systems with more than 1TB of memory, but I don't think you care about that :) Christian. Jean-Marc ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC for a render API to support adaptive sync and VRR
Am 09.04.2018 um 23:45 schrieb Manasi Navare: Thanks for initiating the discussion. Find my comments below: On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote: Adding dri-devel, which I should've included from the start. On 2018-04-09 03:56 PM, Harry Wentland wrote: === What is adaptive sync and VRR? === Adaptive sync has been part of the DisplayPort spec for a while now and allows graphics adapters to drive displays with varying frame timings. VRR (variable refresh rate) is essentially the same, but defined for HDMI. === Why allow variable frame timings? === Variable render times don't align with fixed refresh rates, leading to stuttering, tearing, and/or input lag. e.g. (rc = render completion, dr = display refresh) rc B CDE F dr A B C C D E F ^ ^ frame missed repeated display twice refresh === Other use cases of adaptive sync Beside the variable render case, adaptive sync also allows adjustment of refresh rates without a mode change. One such use case would be 24 Hz video. One of the the advantages here when the render speed is slower than the display refresh rate, since we are stretching the vertical blanking interval the display adapters will follow "draw fast and then go idle" approach. This gives power savings when render rate is lower than the display refresh rate. === A DRM render API to support variable refresh rates === In order to benefit from adaptive sync and VRR userland needs a way to let us know whether to vary frame timings or to target a different frame time. These can be provided as atomic properties on a CRTC: * boolvariable_refresh_compatible * int target_frame_duration_ns (nanosecond frame duration) This gives us the following cases: variable_refresh_compatible = 0, target_frame_duration_ns = 0 * drive monitor at timing's normal refresh rate variable_refresh_compatible = 1, target_frame_duration_ns = 0 * send new frame to monitor as soon as it's available, if within min/max of monitor's reported capabilities variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0 * send new frame to monitor with the specified target_frame_duration_ns When a target_frame_duration_ns or variable_refresh_compatible cannot be supported the atomic check will reject the commit. What I would like is two sets of properties on a CRTC or preferably on a connector: KMD properties that UMD can query: * vrr_capable - This will be an immutable property for exposing hardware's capability of supporting VRR. This will be set by the kernel after reading the EDID mode information and monitor range capabilities. * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh rates supported. These properties are optional and will be created and attached to the DP/eDP connector when the connector is getting intialized. Mhm, aren't those properties actually per mode and not per CRTC/connector? Properties that you mentioned above that the UMD can set before kernel can enable VRR functionality *bool vrr_enable or vrr_compatible target_frame_duration_ns Yeah, that certainly makes sense. But target_frame_duration_ns is a bad name/semantics. We should use an absolute timestamp where the frame should be presented, otherwise you could run into a bunch of trouble with IOCTL restarts or missed blanks. Regards, Christian. The monitor only specifies the monitor range through EDID. Apart from this should we also need to scan the modes and check if there are modes that have the same pixel clock and horizontal timings but variable vertical totals? I have RFC patches for all the above mentioned. If we get a concensus/agreement on the above properties and method to check monitor's VRR capability, I can submit those patches atleast as RFC. Regards Manasi === Previous discussions === https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html === Feedback and moving forward === I'm hoping to get some feedback on this or continue the discussion on how adaptive sync / VRR might look like in the DRM ecosystem. Once there are no major concerns or objections left we'll probably start creating some patches to sketch this out a bit better and see how it looks in practice. Cheers, Harry ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc
On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote: > On 2018-04-09 13:17, Russell King - ARM Linux wrote: > > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: > >> During this, I found that the tda998x driver never sets the format in > >> the connector display_info. Thus, the atmel-hlcdc driver fails to select > >> output format. Since I had similar problems with ds90c185 lvds encoder > >> I added patches to override the atmel-hlcdc output format via a DT > >> property and things start to play together. > > > > That sounds like a hack. The tda998x driver doesn't set the format > > because it pre-dates the addition of this information in the display > > info structure, and none of its current users require that information. > > > > As you're the first to require it, rather than working around the > > driver by adding stuff to DT, it would be much better to improve the > > driver by adding this information. > > > > Thanks. > > Even if I improved the tda998x driver, it would not be correct. > > The background is that while the atmel-hlcdc driver supports rgb888, > our PCB is only wired for rgb565. And the tda19988 has rgb888 input > (we have the lsb bits tied to ground on our PCB). So, the tda998x > driver can request rgb888 and the atmel-hlcdc driver can say ok, > but it still would not be correct. So, where exactly do you suggest > that I model the narrowing of the display format? That isn't described in your covering email to the series - instead, your cover sounds like you're working around a deficiency in the tda998x driver. I think you need to make it clear that the reason you need the DT property is because of the way the hardware is wired, not because of the missing bus format in the TDA998x driver. From what you've just described, the missing bus format is merely incidental to the issue, and whether TDA998x provided this or not, you'd still need to override it. If we were to add the bus format to the tda998x at a later date, I would hope your driver would ignore it in this situation? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: Remove vla
Am 09.04.2018 um 23:06 schrieb Laura Abbott:
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms.
Actually that isn't correct.
Could be that we haven't upstreamed KFD support for them, but Vega10
have a different interrupt ring entry size and so would cause the error
message here.
Switch to a constant size array
instead.
I would say to just make make the array bigger.
Regards,
Christian.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..c9863858f343 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
{
struct kfd_dev *dev = container_of(work, struct kfd_dev,
interrupt_work);
+ uint32_t ih_ring_entry[4];
- uint32_t ih_ring_entry[DIV_ROUND_UP(
- dev->device_info->ih_ring_entry_size,
- sizeof(uint32_t))];
+ if (dev->device_info->ih_ring_entry_size > (4 * sizeof(uint32_t))) {
+ dev_err(kfd_chardev(), "Ring entry too small\n");
+ return;
+ }
while (dequeue_ih_ring_entry(dev, ih_ring_entry))
dev->device_info->event_interrupt_class->interrupt_wq(dev,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc
On 2018-04-09 14:02, Russell King - ARM Linux wrote: > On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote: >> On 2018-04-09 13:17, Russell King - ARM Linux wrote: >>> On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: During this, I found that the tda998x driver never sets the format in the connector display_info. Thus, the atmel-hlcdc driver fails to select output format. Since I had similar problems with ds90c185 lvds encoder I added patches to override the atmel-hlcdc output format via a DT property and things start to play together. >>> >>> That sounds like a hack. The tda998x driver doesn't set the format >>> because it pre-dates the addition of this information in the display >>> info structure, and none of its current users require that information. >>> >>> As you're the first to require it, rather than working around the >>> driver by adding stuff to DT, it would be much better to improve the >>> driver by adding this information. >>> >>> Thanks. >> >> Even if I improved the tda998x driver, it would not be correct. >> >> The background is that while the atmel-hlcdc driver supports rgb888, >> our PCB is only wired for rgb565. And the tda19988 has rgb888 input >> (we have the lsb bits tied to ground on our PCB). So, the tda998x >> driver can request rgb888 and the atmel-hlcdc driver can say ok, >> but it still would not be correct. So, where exactly do you suggest >> that I model the narrowing of the display format? > > That isn't described in your covering email to the series - instead, > your cover sounds like you're working around a deficiency in the > tda998x driver. Sorry, my bad, And sorry for the confusion. > I think you need to make it clear that the reason you need the DT > property is because of the way the hardware is wired, not because of > the missing bus format in the TDA998x driver. From what you've just > described, the missing bus format is merely incidental to the issue, > and whether TDA998x provided this or not, you'd still need to override > it. I'll reword if/when I send v2. > If we were to add the bus format to the tda998x at a later date, I > would hope your driver would ignore it in this situation? Assuming that by "your driver" you mean the atmel-hlcdc driver (which isn't mine), then yes, with the override in place anything the tda998x driver says about the connector format will still result in what the forced output mode says from the atmel-hlcdc driver. Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM_UDL and GPU under Xserver
Hi Daniel, On Mon, 2018-04-09 at 11:17 +0200, Daniel Vetter wrote: > On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote: > > Hi Daniel, > > > > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote: > > > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote: > > > > Hi Daniel, all, > > > > [snip] > > > > > > Ok it was quite some time ago so I forgot about that completely. > > > > I really made one trivial change in xf86-video-armada: > > > > >8-- > > > > --- a/src/armada_module.c > > > > +++ b/src/armada_module.c > > > > @@ -26,7 +26,7 @@ > > > > #define ARMADA_NAME"armada" > > > > #define ARMADA_DRIVER_NAME "armada" > > > > > > > > -#define DRM_MODULE_NAMES "armada-drm", "imx-drm" > > > > +#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl" > > > > #define DRM_DEFAULT_BUS_ID NULL > > > > >8-- > > > > > > > > Otherwise Xserver fails on start which is expected given "imx-drm" is > > > > intentionally removed. > > > > Here I meant I explicitly disabled DRM_IMX in the kernel configuraion > > so that it is not used in run-time. > > > > > You need to keep imx-drm around. And then light up the udl display using > > > prime. Afaiui it should all just work (but with maybe a few disconnected > > > outputs from imx-drm around that you don't need, but that's not a > > > problem). > > > > And given my comment above I don't really see any difference between > > DRM_IMX and DRM_UDL (except their HW implmentation which I guess should > > not bother upper layers) so why do wee need to treat them differently? > > > > Most probably I'm missing something but my thought was if we have > > 2 equally well supported KMS devices we may easily swap them and still > > have resulting setup functional. > > armada is not a generic drm driver, but can only be used for armada-drm > and imx-drm. You can't just use it with any drm device, for that you need > a generic driver like -modesetting. But "armada" is the name of xf86 "driver" only which then uses true DRM_ETNAVIV kernel driver. That's why I'm a bit confused. And from what I see DRM_ETNAVIV happily works with either DRM_xxx frame-buffer device be it DRM_IMX or DRM_UDL. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD graphics performance regression in 4.15 and later
On 04/09/2018 05:42 AM, Christian König wrote: > Backporting all the detection logic is to invasive, but you could just > go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the > other code path. > > Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. Do you mean just taking the 4.15 code as is and replacing "#ifdef CONFIG_SWIOTLB" with "#if 0" in drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c or are you talking about using a different version of drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c ? Jean-Marc ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM_UDL and GPU under Xserver
Hi Daniel, On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote: > > Hi Daniel, all, [snip] > > Ok it was quite some time ago so I forgot about that completely. > > I really made one trivial change in xf86-video-armada: > > >8-- > > --- a/src/armada_module.c > > +++ b/src/armada_module.c > > @@ -26,7 +26,7 @@ > > #define ARMADA_NAME"armada" > > #define ARMADA_DRIVER_NAME "armada" > > > > -#define DRM_MODULE_NAMES "armada-drm", "imx-drm" > > +#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl" > > #define DRM_DEFAULT_BUS_ID NULL > > >8-- > > > > Otherwise Xserver fails on start which is expected given "imx-drm" is > > intentionally removed. Here I meant I explicitly disabled DRM_IMX in the kernel configuraion so that it is not used in run-time. > You need to keep imx-drm around. And then light up the udl display using > prime. Afaiui it should all just work (but with maybe a few disconnected > outputs from imx-drm around that you don't need, but that's not a > problem). And given my comment above I don't really see any difference between DRM_IMX and DRM_UDL (except their HW implmentation which I guess should not bother upper layers) so why do wee need to treat them differently? Most probably I'm missing something but my thought was if we have 2 equally well supported KMS devices we may easily swap them and still have resulting setup functional. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/7] arm64: dts: renesas: r8a77970: add VSPD support
On Fri, Apr 06, 2018 at 04:33:21PM +0300, Laurent Pinchart wrote:
> On Friday, 6 April 2018 16:08:07 EEST Jacopo Mondi wrote:
> > From: Sergei Shtylyov
> >
> > Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
> > the next patch...
> >
> > Based on the original (and large) patch by Daisuke Matsushita
> > .
> >
> > Signed-off-by: Vladimir Barinov
> > Signed-off-by: Sergei Shtylyov
> > Signed-off-by: Niklas Söderlund
> > ---
> > arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77970.dtsi index 71f466d..db06c94 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > @@ -625,6 +625,16 @@
> > power-domains = <&sysc R8A77970_PD_ALWAYS_ON>;
> > resets = <&cpg 603>;
> > };
> > +
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x4000>;
>
> You need to extend the memory region to include the V6_CLUTn_TBL* registers.
> I
> would recommend simply extending it to 0x8000 as all other VSP instances,
> even
> if the registers at 0x7000-0x7fff are not implemented.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
I applied the first patch of this series. Please update this,
and any subsequent patches as appropriate and then repost the series
without the first patch.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] allow override of bus format in bridges
On 2018-04-09 14:51, Laurent Pinchart wrote:
> Hi Peter,
>
> On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
>> On 2018-04-04 14:35, Peter Rosin wrote:
>>> On 2018-04-04 11:07, Laurent Pinchart wrote:
On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
>> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
>>> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
Hi!
[I got to v2 sooner than expected]
I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...
The problem is that the bus_format of the SoC and the panel do
not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires for each color simply pulled
down internally in the encoder in my case which means that the
rgb565 bus_format is the format that works best. And the panel
is expecting lvds (vesa-24), which is what the encoder outputs.
The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.
panel: panel {
compatible = "panel-lvds";
width-mm = <304>;
height-mm = <228;
data-mapping = "vesa-24";
panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <48 88 88>;
hback-porch = <96 168 168>;
hsync-len = <32 64 64>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};
port {
panel_input: endpoint {
remote-endpoint = <&lvds_encoder_output>;
};
};
};
lvds-encoder {
compatible = "ti,ds90c185", "lvds-encoder";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_encoder_input: endpoint {
remote-endpoint =
<&hlcdc_output>;
};
};
port@1 {
reg = <1>;
lvds_encoder_output: endpoint {
remote-endpoint = <&panel_input>;
};
};
};
};
But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I intruduce an API that
allows display controller drivers to query the required bus_format of
any intermediate bridges, and match up with that instead of the
formats given by the drm_connector. I trigger this with this addition
to the lvds-encoder DT node:
interface-pix-fmt = "rgb565";
Naming is hard though, so I'm not sure if that's good?
I threw in the first patch, since that is the actual lvds encoder
I have in this case.
Suggestions welcome.
>>>
>>> Took a quick look, feels rather un-atomic. And there's beend
>>> discussing for other bridge related state that we might want to track
>>> (like the full adjusted_mode that might need to be adjusted at each
>>> stage in the chain). So here's my suggestions:
>>>
>>> - Add an optional per-bridge internal state struct using the support
>>> in https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling->
>>>
Re: GPU/DRM issue with DSI commands on msm 8916
Hi Archit, Thanks a lot for your reply. On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote: > On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote: >> I'm having issues with the GPU/DRM drivers on a msm8916 based platform >> which is very similar to the DragonBoard 410c. In my setup, a DSI >> display is directly connected to the SoC, and the video link is stable. >> >> However, when the host sends DCS commands down to the DSI panel (for >> instance to set the backlight brightness), the image drops out, most of >> the time only in terms of a short flicker, but sometimes it will >> completely kill the image. In the latter case, only restarting the >> Wayland compositor in userspace helps. This is also quite reproducible; >> sending a NOP command once a second would give a visual flicker in 90% >> of the cases, and it needs at most a minute to make the screen turn black. >> >> The interesting thing is that this used to work in a v4.9 based version, >> but it broke somewhere on the way to v4.14. Unfortunately, the platform >> does not boot a vanilla kernel, so I can't really bisect this. We >> currently depend on the Linaro downstream patches which can be found here: > > The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a > DSI point of view was probably the addition of runtime PM support. > > The register configurations that are responsible for interleaving DCS > commands while video mode is still on should be the same. Yeah, I think so too. I compared a lot of code but couldn't really find anything either. At least, the command buffer contents and lengths are identical. > You could comment out the pm_runtime_put_sync() calls in > drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got > reset during put_sync and weren't restored correctly after get_sync(). That was my first suspicion too, but unfortunately, that's not the culprit. > Does your device initialize a splash screen in the bootloader? It does, but that's the case for either of the two kernels. Do you think that matters? And as you mention it - I'm building the driver as module, because when built into the kernel, the msm driver fails to initialize the hardware, and the console is flooded with the following message: [ 63.356837] dsi_err_worker: status=4 > You could also compare the reg dumps between 4.9 and 4.14 by enabling > the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are > any register configuration differences between the two. I did that, and there a quite a number of changes, mostly because the KMS bits have changed a lot. Given that I'm not too familiar with this driver stack, I'm not sure what exactly to look at. > One (rather unlikely) possibility I can think of is if somehow the > buffers used to send/receive DCS commands aren't mapped/unmapped > correctly. There have been some msm_gem changes, and the IOMMU driver > is new. That's the main reason why I'm wondering if the contents of the > DCS buffers somehow got corrupt. That may well be, but I can't really see what's wrong in that area. Which iommu driver are you referring to, exactly? > Is the panel initialized using DCS > commands too? Yes, and that works. The thing is that the commands do in fact reach the panel and cause the desired effect, it's just that as a side effect, the display very likely drops out when a command is sent. The registers that are modified through msm_writel() by and between msm_dsi_host_xfer_prepare() and msm_dsi_host_xfer_restore() are exactly the same though. So it must be that some other part (the GPU or the KMS?) doesn't like the fact that the DSI core mangles with the hardware state in some way. What hardware are all these changes developed and tested on, btw? I guess it might be worth looking into differences between these platforms and my own. Again, thanks! Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/sii8620: add Kconfig dependency on extcon
Hi,
On 2018년 04월 09일 15:27, Andrzej Hajda wrote:
> The driver can work with or without extcon framework, but if extcon is
> build as module, sii8620 should be build as module as well.
>
> Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic
> to detect MHL")
> Reported-by: kbuild test robot
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3aa65bdecb0e..684ac626ac53 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,7 @@ config DRM_SIL_SII8620
> tristate "Silicon Image SII8620 HDMI/MHL bridge"
> depends on OF && RC_CORE
> select DRM_KMS_HELPER
> + imply EXTCON
> help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.
>
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] TDA998x CEC support
Hi, This patch series adds CEC support to the DRM TDA998x driver. The TDA998x family of devices integrate a TDA9950 CEC at a separate I2C address from the HDMI encoder. Implementation of the CEC part is separate to allow independent CEC implementations, or independent HDMI implementations (since the TDA9950 may be a separate device.) .../devicetree/bindings/display/bridge/tda998x.txt | 3 + drivers/gpu/drm/i2c/Kconfig| 6 + drivers/gpu/drm/i2c/Makefile | 1 + drivers/gpu/drm/i2c/tda9950.c | 509 + drivers/gpu/drm/i2c/tda998x_drv.c | 242 -- include/linux/platform_data/tda9950.h | 16 + 6 files changed, 750 insertions(+), 27 deletions(-) create mode 100644 drivers/gpu/drm/i2c/tda9950.c create mode 100644 include/linux/platform_data/tda9950.h v3: addressed most of Hans comments in v2 v2: updated DT property. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] allow override of bus format in bridges
On 2018-04-04 14:35, Peter Rosin wrote:
> On 2018-04-04 11:07, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
>>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> [I got to v2 sooner than expected]
>>
>> I have an Atmel sama5d31 hooked up to an lvds encoder and then
>> on to an lvds panel. Which seems like something that has been
>> done one or two times before...
>>
>> The problem is that the bus_format of the SoC and the panel do
>> not agree. The SoC driver (atmel-hlcdc) can handle the
>> rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
>> wired for the rgb565 case. The lvds encoder supports rgb888 on
>> its input side with the LSB wires for each color simply pulled
>> down internally in the encoder in my case which means that the
>> rgb565 bus_format is the format that works best. And the panel
>> is expecting lvds (vesa-24), which is what the encoder outputs.
>>
>> The reason I "blame" the bus_format of the drm_connector is that
>> with the below DT snippet, things do not work *exactly* due to
>> that. At least, it starts to work if I hack the panel-lvds driver
>> to report the rgb565 bus_format instead of vesa-24.
>>
>> panel: panel {
>> compatible = "panel-lvds";
>>
>> width-mm = <304>;
>> height-mm = <228;
>>
>> data-mapping = "vesa-24";
>>
>> panel-timing {
>> // 1024x768 @ 60Hz (typical)
>> clock-frequency = <5214 6500 7110>;
>> hactive = <1024>;
>> vactive = <768>;
>> hfront-porch = <48 88 88>;
>> hback-porch = <96 168 168>;
>> hsync-len = <32 64 64>;
>> vfront-porch = <8 13 14>;
>> vback-porch = <8 13 14>;
>> vsync-len = <8 12 14>;
>> };
>>
>> port {
>> panel_input: endpoint {
>> remote-endpoint = <&lvds_encoder_output>;
>> };
>> };
>> };
>>
>> lvds-encoder {
>> compatible = "ti,ds90c185", "lvds-encoder";
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> reg = <0>;
>>
>> lvds_encoder_input: endpoint {
>> remote-endpoint = <&hlcdc_output>;
>> };
>> };
>>
>> port@1 {
>> reg = <1>;
>>
>> lvds_encoder_output: endpoint {
>> remote-endpoint = <&panel_input>;
>> };
>> };
>> };
>> };
>>
>> But, instead of perverting the panel-lvds driver with support
>> for a totally fake non-lvds bus_format, I intruduce an API that allows
>> display controller drivers to query the required bus_format of any
>> intermediate bridges, and match up with that instead of the formats
>> given by the drm_connector. I trigger this with this addition to the
>>
>> lvds-encoder DT node:
>> interface-pix-fmt = "rgb565";
>>
>> Naming is hard though, so I'm not sure if that's good?
>>
>> I threw in the first patch, since that is the actual lvds encoder
>> I have in this case.
>>
>> Suggestions welcome.
>
> Took a quick look, feels rather un-atomic. And there's beend discussing
> for other bridge related state that we might want to track (like the full
> adjusted_mode that might need to be adjusted at each stage in the chain).
> So here's my suggestions:
>
> - Add an optional per-bridge internal state struct using the support in
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-driver->
> >> private-state
>
> Yes it says "driver private", but since bridge is just helper stuff
> that's all included. "driver private" == "not exposed as uapi" here.
> Include all the usual convenience wrappers to get at the state for a
> bridge.
>
> - Then stuff your bus_format into that new drm_bridge_stat
Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc
On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: > During this, I found that the tda998x driver never sets the format in > the connector display_info. Thus, the atmel-hlcdc driver fails to select > output format. Since I had similar problems with ds90c185 lvds encoder > I added patches to override the atmel-hlcdc output format via a DT > property and things start to play together. That sounds like a hack. The tda998x driver doesn't set the format because it pre-dates the addition of this information in the display info structure, and none of its current users require that information. As you're the first to require it, rather than working around the driver by adding stuff to DT, it would be much better to improve the driver by adding this information. Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] arm64: dts: renesas: r8a77970: add FCPVD support
On Fri, Apr 06, 2018 at 04:28:17PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Friday, 6 April 2018 16:08:06 EEST Jacopo Mondi wrote: > > From: Sergei Shtylyov > > > > Describe FCPVD0 in the R8A77970 device tree; it will be used by VSPD0 in > > the next patch... > > > > Based on the original (and large) patch by Daisuke Matsushita > > . > > > > Signed-off-by: Vladimir Barinov > > Signed-off-by: Sergei Shtylyov > > Signed-off-by: Niklas Söderlund > > Reviewed-by: Laurent Pinchart Thanks, applied for v4.18. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm/i2c: tda998x: add CEC support
The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
onto the same die. Add support for the TDA9950 CEC engine to the
TDA998x driver.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/Kconfig | 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 195 --
2 files changed, 187 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 3a232f5ff0a1..65d3acb61c03 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+ select CEC_CORE if CEC_NOTIFIER
select SND_SOC_HDMI_CODEC if SND_SOC
help
Support for NXP Semiconductors TDA998X HDMI encoders.
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 16e0439cad44..eb9916bd84a4 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -16,8 +16,10 @@
*/
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +31,8 @@
#include
#include
+#include
+
#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
struct tda998x_audio_port {
@@ -55,6 +59,7 @@ struct tda998x_priv {
struct platform_device *audio_pdev;
struct mutex audio_mutex;
+ struct mutex edid_mutex;
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
@@ -67,6 +72,9 @@ struct tda998x_priv {
struct drm_connector connector;
struct tda998x_audio_port audio_port[2];
+ struct tda9950_glue cec_glue;
+ struct gpio_desc *calib;
+ struct cec_notifier *cec_notify;
};
#define conn_to_tda998x_priv(x) \
@@ -345,6 +353,12 @@ struct tda998x_priv {
#define REG_CEC_INTSTATUS0xee/* read */
# define CEC_INTSTATUS_CEC (1 << 0)
# define CEC_INTSTATUS_HDMI (1 << 1)
+#define REG_CEC_CAL_XOSC_CTRL10xf2
+# define CEC_CAL_XOSC_CTRL1_ENA_CALBIT(0)
+#define REG_CEC_DES_FREQ2 0xf5
+# define CEC_DES_FREQ2_DIS_AUTOCAL BIT(7)
+#define REG_CEC_CLK 0xf6
+# define CEC_CLK_FRO 0x11
#define REG_CEC_FRO_IM_CLK_CTRL 0xfb/* read/write */
# define CEC_FRO_IM_CLK_CTRL_GHOST_DIS (1 << 7)
# define CEC_FRO_IM_CLK_CTRL_ENA_OTP (1 << 6)
@@ -359,6 +373,7 @@ struct tda998x_priv {
# define CEC_RXSHPDLEV_HPD(1 << 1)
#define REG_CEC_ENAMODS 0xff/* read/write */
+# define CEC_ENAMODS_EN_CEC_CLK (1 << 7)
# define CEC_ENAMODS_DIS_FRO (1 << 6)
# define CEC_ENAMODS_DIS_CCLK (1 << 5)
# define CEC_ENAMODS_EN_RXSENS(1 << 2)
@@ -417,6 +432,114 @@ cec_read(struct tda998x_priv *priv, u8 addr)
return val;
}
+static void cec_enamods(struct tda998x_priv *priv, u8 mods, bool enable)
+{
+ int val = cec_read(priv, REG_CEC_ENAMODS);
+
+ if (val < 0)
+ return;
+
+ if (enable)
+ val |= mods;
+ else
+ val &= ~mods;
+
+ cec_write(priv, REG_CEC_ENAMODS, val);
+}
+
+static void tda998x_cec_set_calibration(struct tda998x_priv *priv, bool enable)
+{
+ if (enable) {
+ u8 val;
+
+ cec_write(priv, 0xf3, 0xc0);
+ cec_write(priv, 0xf4, 0xd4);
+
+ /* Enable automatic calibration mode */
+ val = cec_read(priv, REG_CEC_DES_FREQ2);
+ val &= ~CEC_DES_FREQ2_DIS_AUTOCAL;
+ cec_write(priv, REG_CEC_DES_FREQ2, val);
+
+ /* Enable free running oscillator */
+ cec_write(priv, REG_CEC_CLK, CEC_CLK_FRO);
+ cec_enamods(priv, CEC_ENAMODS_DIS_FRO, false);
+
+ cec_write(priv, REG_CEC_CAL_XOSC_CTRL1,
+ CEC_CAL_XOSC_CTRL1_ENA_CAL);
+ } else {
+ cec_write(priv, REG_CEC_CAL_XOSC_CTRL1, 0);
+ }
+}
+
+/*
+ * Calibration for the internal oscillator: we need to set calibration mode,
+ * and then pulse the IRQ line low for a 10ms ± 1% period.
+ */
+static void tda998x_cec_calibration(struct tda998x_priv *priv)
+{
+ struct gpio_desc *calib = priv->calib;
+
+ mutex_lock(&priv->edid_mutex);
+ if (priv->hdmi->irq > 0)
+ disable_irq(priv->hdmi->irq);
+ gpiod_direction_output(calib, 1);
+ tda998x_cec_set_calibration(priv, true);
+
+ local_irq_disable();
+ gpiod_set_value(calib, 0);
+ mdelay(10);
+ gpiod_set_value(calib, 1);
+ local_irq_enable();
+
+ tda998x_cec_set_calibration(priv, false);
+ gpiod_direction_input(calib);
+ if (priv->hdmi->irq > 0)
+ enable_irq(priv->hdmi->irq);
+ mutex_unlock(&priv->edid_mutex);
+}
+
+static int tda998x_cec_hook_init(void *data)
+{
+ struct tda998x_priv *priv = data;
+ struct gpio_desc *calib;
+
+ calib
[PATCH v3 5/7] drm/i2c: tda9950: add CEC driver
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
but is also integrated into HDMI transceivers such as the TDA9989 and
TDA19989.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol. The driver just has to read and write
the messages, and handle error conditions.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/Kconfig | 5 +
drivers/gpu/drm/i2c/Makefile | 1 +
drivers/gpu/drm/i2c/tda9950.c | 509 ++
include/linux/platform_data/tda9950.h | 16 ++
4 files changed, 531 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/tda9950.c
create mode 100644 include/linux/platform_data/tda9950.h
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index a6c92beb410a..3a232f5ff0a1 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
help
Support for NXP Semiconductors TDA998X HDMI encoders.
+config DRM_I2C_NXP_TDA9950
+ tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+ select CEC_NOTIFIER
+ select CEC_CORE
+
endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index b20100c18ffb..a962f6f08568 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
tda998x-y := tda998x_drv.o
obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index ..3f7396caad48
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,509 @@
+/*
+ * TDA9950 Consumer Electronics Control driver
+ *
+ * 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.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface. The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction. See the TDA9950 data sheet for details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ REG_CSR = 0x00,
+ CSR_BUSY = BIT(7),
+ CSR_INT = BIT(6),
+ CSR_ERR = BIT(5),
+
+ REG_CER = 0x01,
+
+ REG_CVR = 0x02,
+
+ REG_CCR = 0x03,
+ CCR_RESET = BIT(7),
+ CCR_ON= BIT(6),
+
+ REG_ACKH = 0x04,
+ REG_ACKL = 0x05,
+
+ REG_CCONR = 0x06,
+ CCONR_ENABLE_ERROR = BIT(4),
+ CCONR_RETRY_MASK = 7,
+
+ REG_CDR0 = 0x07,
+
+ CDR1_REQ = 0x00,
+ CDR1_CNF = 0x01,
+ CDR1_IND = 0x81,
+ CDR1_ERR = 0x82,
+ CDR1_IER = 0x83,
+
+ CDR2_CNF_SUCCESS= 0x00,
+ CDR2_CNF_OFF_STATE = 0x80,
+ CDR2_CNF_BAD_REQ= 0x81,
+ CDR2_CNF_CEC_ACCESS = 0x82,
+ CDR2_CNF_ARB_ERROR = 0x83,
+ CDR2_CNF_BAD_TIMING = 0x84,
+ CDR2_CNF_NACK_ADDR = 0x85,
+ CDR2_CNF_NACK_DATA = 0x86,
+};
+
+struct tda9950_priv {
+ struct i2c_client *client;
+ struct device *hdmi;
+ struct cec_adapter *adap;
+ struct tda9950_glue *glue;
+ u16 addresses;
+ struct cec_msg rx_msg;
+ struct cec_notifier *notify;
+ bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int
cnt)
+{
+ struct i2c_msg msg;
+ u8 buf[cnt + 1];
+ int ret;
+
+ buf[0] = addr;
+ memcpy(buf + 1, p, cnt);
+
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = cnt + 1;
+ msg.buf = buf;
+
+ dev_dbg(&client->dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ if (ret < 0)
+ dev_err(&client->dev, "Error %d writing to cec:0x%x\n", ret,
addr);
+ return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+ tda9950_write_range(client, addr, &val, 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int
cnt)
+{
+ struct i2c_msg msg[2];
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = &addr;
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = cnt;
+ msg[1].buf = p;
+
+ ret = i2c_transfer(client->adapter, msg, 2);
+ if (ret < 0)
+ dev_err(&client->dev, "Error %d reading from cec:0x%x\n", ret,
addr);
+
+ dev_dbg(&client->dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+ return ret;
+
[PATCH 3/5] drm/atmel-hlcdc: allow overriding the output mode
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if the encoder and connector provided by the tda998x driver
is in use in which case the connector does not advertize and format at
all.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 ++--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 19 +++
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 8
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..9bfff228f893 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -220,12 +220,6 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc
*c,
drm_crtc_vblank_on(c);
}
-#define ATMEL_HLCDC_RGB444_OUTPUT BIT(0)
-#define ATMEL_HLCDC_RGB565_OUTPUT BIT(1)
-#define ATMEL_HLCDC_RGB666_OUTPUT BIT(2)
-#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
-#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
-
static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
{
unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -237,6 +231,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
drm_crtc_state *state)
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
+ if (crtc->dc->force_output_mode) {
+ hstate = drm_crtc_state_to_atmel_hlcdc_crtc_state(state);
+ hstate->output_mode = fls(crtc->dc->force_output_mode) - 1;
+ return 0;
+ }
+
for_each_new_connector_in_state(state->state, connector, cstate, i) {
struct drm_display_info *info = &connector->display_info;
unsigned int supported_fmts = 0;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index c1ea5c36b006..dccd0be548a9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -600,6 +600,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
struct platform_device *pdev = to_platform_device(dev->dev);
const struct of_device_id *match;
struct atmel_hlcdc_dc *dc;
+ const char *output_mode;
int ret;
match = of_match_node(atmel_hlcdc_of_match, dev->dev->parent->of_node);
@@ -634,6 +635,24 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
pm_runtime_enable(dev->dev);
+ ret = of_property_read_string(dev->dev->of_node,
+ "output-mode", &output_mode);
+ if (!ret) {
+ if (!strcmp(output_mode, "rgb444")) {
+ dc->force_output_mode = ATMEL_HLCDC_RGB444_OUTPUT;
+ } else if (!strcmp(output_mode, "rgb565")) {
+ dc->force_output_mode = ATMEL_HLCDC_RGB565_OUTPUT;
+ } else if (!strcmp(output_mode, "rgb666")) {
+ dc->force_output_mode = ATMEL_HLCDC_RGB666_OUTPUT;
+ } else if (!strcmp(output_mode, "rgb888")) {
+ dc->force_output_mode = ATMEL_HLCDC_RGB888_OUTPUT;
+ } else {
+ dev_err(dev->dev, "unknown output-mode\n");
+ ret = -EINVAL;
+ goto err_destroy_wq;
+ }
+ }
+
ret = drm_vblank_init(dev, 1);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize vblank\n");
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index ab32d5b268d2..a810171b9353 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -153,6 +153,12 @@
#define ATMEL_HLCDC_MAX_LAYERS 6
+#define ATMEL_HLCDC_RGB444_OUTPUT BIT(0)
+#define ATMEL_HLCDC_RGB565_OUTPUT BIT(1)
+#define ATMEL_HLCDC_RGB666_OUTPUT BIT(2)
+#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
+#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+
/**
* Atmel HLCDC Layer registers layout structure
*
@@ -365,6 +371,7 @@ struct atmel_hlcdc_plane_properties {
* @hlcdc: pointer to the atmel_hlcdc structure provided by the MFD device
* @fbdev: framebuffer device attached to the Display Controller
* @crtc: CRTC provided by the display controller
+ * @force_output_mode: if set, this output mode beats the selection heuristic
* @planes: instantiated planes
* @layers: active HLCDC layers
* @wq: display controller workqueue
@@ -376,6 +383,7 @@ struct atmel_hlcdc_dc {
struct dma_pool *dscrpool;
struct atmel_hlcdc *hlcdc;
struct drm_crtc *crtc;
+ unsigned int force_outp
[PATCH 5/5] drm/atmel-hlcdc: fix broken release date
Bump the minor version while at it.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index b411038890a9..aec0e0e05edb 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -782,9 +782,9 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.fops = &fops,
.name = "atmel-hlcdc",
.desc = "Atmel HLCD Controller DRM",
- .date = "20141504",
+ .date = "20180409",
.major = 1,
- .minor = 0,
+ .minor = 1,
};
static int atmel_hlcdc_dc_drm_init(struct platform_device *pdev)
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[RFC]DPU PATCH] drm/bridge: add support for sn65dsi86 bridge chip
This patchset add support for ti based sn65dsu86 bridge chip, which takes dsi video mode signal as input and coverts it to eDP signal as output. Current driver uses device tree entries to get the required gpio pin numbers that needs to be configured to enable the DSI reciever and eDP connector part. Also this driver implments two methods to determine the modes supported by the display panel depending on whether HPD is enabled or not. First method is based on EDID read which is used if panel supports HDP and the second method is based on custome modes added in dtsi file when panel does not support HPD. Current patch is not yet tested on an actual sn65dsi86 bridge HW. Sandeep Panda (1): drm/bridge: add sn65dsi86 bridge driver support .../bindings/display/bridge/ti,sn65dsi86.txt | 53 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1146 2 files changed, 1199 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] dt-bindings: display: atmel: add optional output-mode property
Useful for beating cases where an output mode selection heuristic fails. Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt index 82f2acb3d374..dc478455b883 100644 --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt @@ -10,6 +10,10 @@ Required properties: - #address-cells: should be set to 1. - #size-cells: should be set to 0. +Optional properties: + - output-mode: override any output mode selection hueristic and force a + particular output mode. One of "rgb444", "rgb565", "rgb666" and "rgb888". + Required children nodes: Children nodes are encoding available output ports and their connections to external devices using the OF graph reprensentation (see ../graph.txt). -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder
When the of-graph points to a tda998x-compatible HDMI encoder, register
as a component master and bind to the encoder/connector provided by
the tda998x driver.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 81 --
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 15 +++
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 130 +++
3 files changed, 220 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index dccd0be548a9..b411038890a9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -20,6 +20,7 @@
*/
#include
+#include
#include
#include
#include
@@ -568,10 +569,13 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device
*dev)
drm_mode_config_init(dev);
- ret = atmel_hlcdc_create_outputs(dev);
- if (ret) {
- dev_err(dev->dev, "failed to create HLCDC outputs: %d\n", ret);
- return ret;
+ if (!dc->is_componentized) {
+ ret = atmel_hlcdc_create_outputs(dev);
+ if (ret) {
+ dev_err(dev->dev,
+ "failed to create HLCDC outputs: %d\n", ret);
+ return ret;
+ }
}
ret = atmel_hlcdc_create_planes(dev);
@@ -586,6 +590,16 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device
*dev)
return ret;
}
+ if (dc->is_componentized) {
+ ret = component_bind_all(dev->dev, dev);
+ if (ret < 0)
+ return ret;
+
+ ret = atmel_hlcdc_add_component_encoder(dev);
+ if (ret < 0)
+ return ret;
+ }
+
dev->mode_config.min_width = dc->desc->min_width;
dev->mode_config.min_height = dc->desc->min_height;
dev->mode_config.max_width = dc->desc->max_width;
@@ -618,6 +632,9 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc)
return -ENOMEM;
+ dc->is_componentized =
+ atmel_hlcdc_get_external_components(dev->dev, NULL) > 0;
+
dc->wq = alloc_ordered_workqueue("atmel-hlcdc-dc", 0);
if (!dc->wq)
return -ENOMEM;
@@ -770,7 +787,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
.minor = 0,
};
-static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
+static int atmel_hlcdc_dc_drm_init(struct platform_device *pdev)
{
struct drm_device *ddev;
int ret;
@@ -798,7 +815,7 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device
*pdev)
return ret;
}
-static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
+static int atmel_hlcdc_dc_drm_fini(struct platform_device *pdev)
{
struct drm_device *ddev = platform_get_drvdata(pdev);
@@ -809,6 +826,58 @@ static int atmel_hlcdc_dc_drm_remove(struct
platform_device *pdev)
return 0;
}
+static int atmel_hlcdc_bind(struct device *dev)
+{
+ return atmel_hlcdc_dc_drm_init(to_platform_device(dev));
+}
+
+static void atmel_hlcdc_unbind(struct device *dev)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+
+ /* Check if a subcomponent has already triggered the unloading. */
+ if (!ddev->dev_private)
+ return;
+
+ atmel_hlcdc_dc_drm_fini(to_platform_device(dev));
+}
+
+static const struct component_master_ops atmel_hlcdc_comp_ops = {
+ .bind = atmel_hlcdc_bind,
+ .unbind = atmel_hlcdc_unbind,
+};
+
+static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
+{
+ struct component_match *match = NULL;
+ int ret;
+
+ ret = atmel_hlcdc_get_external_components(&pdev->dev, &match);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ return component_master_add_with_match(&pdev->dev,
+ &atmel_hlcdc_comp_ops,
+ match);
+ else
+ return atmel_hlcdc_dc_drm_init(pdev);
+}
+
+static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = atmel_hlcdc_get_external_components(&pdev->dev, NULL);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ component_master_del(&pdev->dev, &atmel_hlcdc_comp_ops);
+ else
+ atmel_hlcdc_dc_drm_fini(pdev);
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
{
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index a810171b9353..53f780827889 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -377,6 +377,10 @@ struct atmel_hlcdc_plane_propert
[PATCH v3 7/7] dt-bindings: tda998x: add the calibration gpio
Add the optional calibration gpio for integrated TDA9950 CEC support. This GPIO corresponds with the interrupt from the TDA998x, as the calibration requires driving the interrupt pin low. Reviewed-by: Rob Herring Signed-off-by: Russell King --- Documentation/devicetree/bindings/display/bridge/tda998x.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt index 24cc2466185a..1a4eaca40d94 100644 --- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt @@ -27,6 +27,9 @@ Required properties; in question is used. The implementation allows one or two DAIs. If two DAIs are defined, they must be of different type. + - nxp,calib-gpios: calibration GPIO, which must correspond with the + gpio used for the TDA998x interrupt pin. + [1] Documentation/sound/alsa/soc/DAI.txt [2] include/dt-bindings/display/tda998x.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc
On 2018-04-09 13:17, Russell King - ARM Linux wrote: > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: >> During this, I found that the tda998x driver never sets the format in >> the connector display_info. Thus, the atmel-hlcdc driver fails to select >> output format. Since I had similar problems with ds90c185 lvds encoder >> I added patches to override the atmel-hlcdc output format via a DT >> property and things start to play together. > > That sounds like a hack. The tda998x driver doesn't set the format > because it pre-dates the addition of this information in the display > info structure, and none of its current users require that information. > > As you're the first to require it, rather than working around the > driver by adding stuff to DT, it would be much better to improve the > driver by adding this information. > > Thanks. Even if I improved the tda998x driver, it would not be correct. The background is that while the atmel-hlcdc driver supports rgb888, our PCB is only wired for rgb565. And the tda19988 has rgb888 input (we have the lsb bits tied to ground on our PCB). So, the tda998x driver can request rgb888 and the atmel-hlcdc driver can say ok, but it still would not be correct. So, where exactly do you suggest that I model the narrowing of the display format? Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/i2c: tda998x: always disable and clear interrupts at probe
Always disable and clear interrupts at probe time to ensure that the
TDA998x is in a sane state. This ensures that the interrupt line,
which is also the CEC clock calibration signal, is always deasserted.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7f2762fab5c9..16e0439cad44 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1546,6 +1546,15 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
cec_write(priv, REG_CEC_FRO_IM_CLK_CTRL,
CEC_FRO_IM_CLK_CTRL_GHOST_DIS |
CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
+ /* ensure interrupts are disabled */
+ cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
+
+ /* clear pending interrupts */
+ cec_read(priv, REG_CEC_RXSHPDINT);
+ reg_read(priv, REG_INT_FLAGS_0);
+ reg_read(priv, REG_INT_FLAGS_1);
+ reg_read(priv, REG_INT_FLAGS_2);
+
/* initialize the optional IRQ */
if (client->irq) {
unsigned long irq_flags;
@@ -1553,11 +1562,6 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
/* init read EDID waitqueue and HDP work */
init_waitqueue_head(&priv->wq_edid);
- /* clear pending interrupts */
- reg_read(priv, REG_INT_FLAGS_0);
- reg_read(priv, REG_INT_FLAGS_1);
- reg_read(priv, REG_INT_FLAGS_2);
-
irq_flags =
irqd_get_trigger_type(irq_get_irq_data(client->irq));
irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc
Hi! I naively thought that since there was support for both nxp,tda19988 (in the tda998x driver) and the atmel-hlcdc, things would be a smooth ride. But it wasn't, so I started looking around, and found some missing pieces in the tilcdc driver. A "stole" some things and made it work for my use case. During this, I found that the tda998x driver never sets the format in the connector display_info. Thus, the atmel-hlcdc driver fails to select output format. Since I had similar problems with ds90c185 lvds encoder I added patches to override the atmel-hlcdc output format via a DT property and things start to play together. Since this series superseeds the bridge series, I have included the leftover bindings patch for the ti,ds90c185 here. I also noticed that the driver date for atmel-hlcdc is bonkers, and added a patch for that. However, I don't know if the tilcdc driver is interfacing with the tda998x driver in a sane and modern way, and I don't know if I have missed any subtle point when I "stole" the code and componentized the atmel-hlcdc driver. I also have not tested how this behaves if I run with the components as modules (not targeting that). Anyway, this series solves some real issues for my HW. Cheers, Peter Peter Rosin (5): dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 dt-bindings: display: atmel: add optional output-mode property drm/atmel-hlcdc: allow overriding the output mode drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder drm/atmel-hlcdc: fix broken release date .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 4 + .../bindings/display/bridge/lvds-transmitter.txt | 8 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 104 +++-- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 23 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 130 + 6 files changed, 266 insertions(+), 15 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] drm/i2c: tda998x: move mutex/waitqueue/timer/work init early
Move the mutex, waitqueue, timer and detect work initialisation early in the driver's initialisation, rather than being after we've registered the CEC device. Acked-by: Hans Verkuil Signed-off-by: Russell King --- drivers/gpu/drm/i2c/tda998x_drv.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index cd3f0873bbdd..83407159e957 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1475,7 +1475,11 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) u32 video; int rev_lo, rev_hi, ret; - mutex_init(&priv->audio_mutex); /* Protect access from audio thread */ + mutex_init(&priv->mutex); /* protect the page access */ + mutex_init(&priv->audio_mutex); /* protect access from audio thread */ + init_waitqueue_head(&priv->edid_delay_waitq); + timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0); + INIT_WORK(&priv->detect_work, tda998x_detect_work); priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3); priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1); @@ -1489,11 +1493,6 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) if (!priv->cec) return -ENODEV; - mutex_init(&priv->mutex); /* protect the page access */ - init_waitqueue_head(&priv->edid_delay_waitq); - timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0); - INIT_WORK(&priv->detect_work, tda998x_detect_work); - /* wake up the device: */ cec_write(priv, REG_CEC_ENAMODS, CEC_ENAMODS_EN_RXSENS | CEC_ENAMODS_EN_HDMI); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] drm/i2c: tda998x: move CEC device initialisation later
We no longer use the CEC client to access the CEC part itself, so we can
move this later in the initialisation sequence.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 2a99930f1bda..7f2762fab5c9 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1489,9 +1489,6 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
priv->cec_addr = 0x34 + (client->addr & 0x03);
priv->current_page = 0xff;
priv->hdmi = client;
- priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
- if (!priv->cec)
- return -ENODEV;
/* wake up the device: */
cec_write(priv, REG_CEC_ENAMODS,
@@ -1578,6 +1575,12 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
}
+ priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
+ if (!priv->cec) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
/* enable EDID read irq: */
reg_set(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
@@ -1594,14 +1597,14 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
ret = tda998x_get_audio_ports(priv, np);
if (ret)
- goto err_audio;
+ goto fail;
if (priv->audio_port[0].format != AFMT_UNUSED)
tda998x_audio_codec_init(priv, &client->dev);
return 0;
-err_audio:
+fail:
if (client->irq)
free_irq(client->irq, priv);
err_irq:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/7] drm/i2c: tda998x: fix error cleanup paths
If tda998x_get_audio_ports() fails, and we requested the interrupt, we
fail to free the interrupt before returning failure. Rework the failure
cleanup code and exit paths so that we always clean up properly after an
error, and always propagate the error code.
Acked-by: Hans Verkuil
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 83407159e957..2a99930f1bda 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1501,10 +1501,15 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
/* read version: */
rev_lo = reg_read(priv, REG_VERSION_LSB);
+ if (rev_lo < 0) {
+ dev_err(&client->dev, "failed to read version: %d\n", rev_lo);
+ return rev_lo;
+ }
+
rev_hi = reg_read(priv, REG_VERSION_MSB);
- if (rev_lo < 0 || rev_hi < 0) {
- ret = rev_lo < 0 ? rev_lo : rev_hi;
- goto fail;
+ if (rev_hi < 0) {
+ dev_err(&client->dev, "failed to read version: %d\n", rev_hi);
+ return rev_hi;
}
priv->rev = rev_lo | rev_hi << 8;
@@ -1528,7 +1533,7 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
default:
dev_err(&client->dev, "found unsupported device: %04x\n",
priv->rev);
- goto fail;
+ return -ENXIO;
}
/* after reset, enable DDC: */
@@ -1566,7 +1571,7 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
dev_err(&client->dev,
"failed to request IRQ#%u: %d\n",
client->irq, ret);
- goto fail;
+ goto err_irq;
}
/* enable HPD irq */
@@ -1589,19 +1594,19 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
ret = tda998x_get_audio_ports(priv, np);
if (ret)
- goto fail;
+ goto err_audio;
if (priv->audio_port[0].format != AFMT_UNUSED)
tda998x_audio_codec_init(priv, &client->dev);
return 0;
-fail:
- /* if encoder_init fails, the encoder slave is never registered,
-* so cleanup here:
-*/
- if (priv->cec)
- i2c_unregister_device(priv->cec);
- return -ENXIO;
+
+err_audio:
+ if (client->irq)
+ free_irq(client->irq, priv);
+err_irq:
+ i2c_unregister_device(priv->cec);
+ return ret;
}
static void tda998x_encoder_prepare(struct drm_encoder *encoder)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185
Start list of actual chips compatible with "lvds-encoder". Reviewed-by: Laurent Pinchart Signed-off-by: Peter Rosin --- .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt index fd39ad34c383..50220190c203 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt @@ -22,7 +22,13 @@ among others. Required properties: -- compatible: Must be "lvds-encoder" +- compatible: Must be one or more of the following + - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer + - "lvds-encoder" for a generic LVDS encoder device + + When compatible with the generic version, nodes must list the + device-specific version corresponding to the device first + followed by the generic version. Required nodes: -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[RFC]DPU PATCH] drm/bridge: add sn65dsi86 bridge driver support
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 53 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1146
2 files changed, 1199 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..5794770
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,53 @@
+SN65DSI86 DSItoeDP bridge chip
+--
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+
+Required properties:
+
+- compatible: Must be "ti,sn65dsi86"
+- reg: Main I2C slave ID (for I2C host driver)
+- sn,irq-gpio: Main IRQ gpio mapping
+- sn,enable-gpio Main reset gpio mapping
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+vga-bridge {
+ compatible = "ti,sn65dsi86";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x39>;
+
+ sn,irq-gpio = <&msmgpio 32 0>;
+ sn,enable-gpio = <&msmgpio 33 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&edp_in>;
+ };
+ };
+ };
+}
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..ff226b9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,1146 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sn65dsi86_reg_cfg {
+ u8 reg;
+ u8 val;
+ int sleep_in_ms;
+};
+
+struct sn65dsi86_video_cfg {
+ u32 h_active;
+ u32 h_front_porch;
+ u32 h_pulse_width;
+ u32 h_back_porch;
+ bool h_polarity;
+ u32 v_active;
+ u32 v_front_porch;
+ u32 v_pulse_width;
+ u32 v_back_porch;
+ bool v_polarity;
+ u32 pclk_khz;
+ u32 num_of_lanes;
+};
+
+struct sn65dsi86_gpios {
+ u32 irq_gpio;
+ u32 enable_gpio;
+ u32 i2c_sda;
+ u32 i2c_scl;
+ u32 panel_bias_en;
+ u32 panel_bklt_en;
+ u32 panel_bklt_ctrl;
+};
+
+struct sn65dsi86_reg_cfg reg_cfg_proto_0[] = {
+ {0x0A, 0x02, 0x0}, /* REFCLK 19.2MHz */
+ {0x10, 0x26, 0x14}, /* DSI lanes */
+ {0x12, 0x7B, 0x0}, /* DSIA CLK FREQ 309.03MHz */
+ {0x5A, 0x05, 0x0}, /* enhanced framing and ASSR */
+ {0x93, 0x30, 0x0}, /* 4 DP lanes no SSC */
+ {0x94, 0x80, 0x0}, /* HBR */
+ {0x0D, 0x01, 0x0}, /* PLL ENABLE */
+ {0x95, 0x00, 0x0}, /* POST-Cursor2 0dB */
+ {0x64, 0x01, 0x0}, /* WriteDPCD Register 0x0010A in Sink */
+ {0x74, 0x00, 0x0},
+ {0x75, 0x01, 0x0},
+ {0x76, 0x0A, 0x0},
+ {0x77, 0x01, 0x0},
+ {0x78, 0x81, 0x14},
+ {0x96, 0x0A, 0x14}, /* Semi-Auto TRAIN */
+ {0xFF, 0x14, 0x0},
+ {0x20, 0x70, 0x0}, /* CHA_ACTIVE_LINE_LENGTH */
+ {0x21, 0x08, 0x0},
+ {0x24, 0xA0, 0x0}, /* CHA_VERTICAL_DISPLAY_SIZE */
+ {0x25, 0x05, 0x0},
+ {0x2C, 0x20, 0x0}, /* CHA_HSYNC_PULSE_WIDTH */
+ {0x2D, 0x80, 0x0},
+ {0x30, 0x0A, 0x0}, /* CHA_VSYNC_PULSE_WIDTH */
+
Re: [RfC PATCH] Add udmabuf misc device
On 04/06/2018 09:57 PM, Dongwon Kim wrote: On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: Hi, I fail to see any common ground for xen-zcopy and udmabuf ... Does the above mean you can assume that xen-zcopy and udmabuf can co-exist as two different solutions? Well, udmabuf route isn't fully clear yet, but yes. See also gvt (intel vgpu), where the hypervisor interface is abstracted away into a separate kernel modules even though most of the actual vgpu emulation code is common. Thank you for your input, I'm just trying to figure out which of the three z-copy solutions intersect and how much And what about hyper-dmabuf? xen z-copy solution is pretty similar fundamentally to hyper_dmabuf in terms of these core sharing feature: 1. the sharing process - import prime/dmabuf from the producer -> extract underlying pages and get those shared -> return references for shared pages 2. the page sharing mechanism - it uses Xen-grant-table. And to give you a quick summary of differences as far as I understand between two implementations (please correct me if I am wrong, Oleksandr.) 1. xen-zcopy is DRM specific - can import only DRM prime buffer while hyper_dmabuf can export any dmabuf regardless of originator Well, this is true. And at the same time this is just a matter of extending the API: xen-zcopy is a helper driver designed for xen-front/back use-case, so this is why it only has DRM PRIME API 2. xen-zcopy doesn't seem to have dma-buf synchronization between two VMs while (as danvet called it as remote dmabuf api sharing) hyper_dmabuf sends out synchronization message to the exporting VM for synchronization. This is true. Again, this is because of the use-cases it covers. But having synchronization for a generic solution seems to be a good idea. 3. 1-level references - when using grant-table for sharing pages, there will be same # of refs (each 8 byte) To be precise, grant ref is 4 bytes as # of shared pages, which is passed to the userspace to be shared with importing VM in case of xen-zcopy. The reason for that is that xen-zcopy is a helper driver, e.g. the grant references come from the display backend [1], which implements Xen display protocol [2]. So, effectively the backend extracts references from frontend's requests and passes those to xen-zcopy as an array of refs. Compared to this, hyper_dmabuf does multiple level addressing to generate only one reference id that represents all shared pages. In the protocol [2] only one reference to the gref directory is passed between VMs (and the gref directory is a single-linked list of shared pages containing all of the grefs of the buffer). 4. inter VM messaging (hype_dmabuf only) - hyper_dmabuf has inter-vm msg communication defined for dmabuf synchronization and private data (meta info that Matt Roper mentioned) exchange. This is true, xen-zcopy has no means for inter VM sync and meta-data, simply because it doesn't have any code for inter VM exchange in it, e.g. the inter VM protocol is handled by the backend [1]. 5. driver-to-driver notification (hyper_dmabuf only) - importing VM gets notified when newdmabuf is exported from other VM - uevent can be optionally generated when this happens. 6. structure - hyper_dmabuf is targetting to provide a generic solution for inter-domain dmabuf sharing for most hypervisors, which is why it has two layers as mattrope mentioned, front-end that contains standard API and backend that is specific to hypervisor. Again, xen-zcopy is decoupled from inter VM communication No idea, didn't look at it in detail. Looks pretty complex from a distant view. Maybe because it tries to build a communication framework using dma-bufs instead of a simple dma-buf passing mechanism. we started with simple dma-buf sharing but realized there are many things we need to consider in real use-case, so we added communication , notification and dma-buf synchronization then re-structured it to front-end and back-end (this made things more compicated..) since Xen was not our only target. Also, we thought passing the reference for the buffer (hyper_dmabuf_id) is not secure so added uvent mechanism later. Yes, I am looking at it now, trying to figure out the full story and its implementation. BTW, Intel guys were about to share some test application for hyper-dmabuf, maybe I have missed one. It could probably better explain the use-cases and the complexity they have in hyper-dmabuf. One example is actually in github. If you want take a look at it, please visit: https://github.com/downor/linux_hyper_dmabuf_test/tree/xen/simple_export Thank you, I'll have a look Like xen-zcopy it seems to depend on the idea that the hypervisor manages all memory it is easy for guests to share pages with the help of the hypervisor. So, for xen-zcopy we were not trying to make it generic, it just solves display (dumb) zero-copying use-cases for Xen. We impleme
Re: [PATCH] drm/i2c: tda998x: Remove VLA usage
On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The vla in reg_write_range is based on the length of data > passed. The one use of a non-constant size for this range is bounded by > the size buffer passed to hdmi_infoframe_pack which is a fixed size. > Switch to this upper bound. Does this _really_ make it safer? What if the code is modified to write more than 32 bytes in the future? Sorry, I don't think this is safer at all. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/xen-front: use simple display pipe prepare_fb helper
On 04/09/2018 11:51 AM, Daniel Vetter wrote:
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 0bd6681fa4f3..a3479eb72d79 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -226,12 +226,6 @@ static bool display_send_page_flip(struct
drm_simple_display_pipe *pipe,
return false;
}
-static int display_prepare_fb(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
- return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
-}
-
static void display_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_plane_state)
{
@@ -294,7 +288,7 @@ static const struct drm_simple_display_pipe_funcs
display_funcs = {
.mode_valid = display_mode_valid,
.enable = display_enable,
.disable = display_disable,
- .prepare_fb = display_prepare_fb,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
.update = display_update,
};
Thank you,
Reviewed-by: Oleksandr Andrushchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers
On 04/05/2018 06:44 PM, Daniel Vetter wrote:
There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: David Lechner
Cc: "Noralf Trønnes"
Cc: Daniel Vetter
Cc: Shawn Guo
Cc: Neil Armstrong
Cc: Daniel Stone
Cc: Haneen Mohammed
Cc: Ben Widawsky
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 19 +++
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 17 -
drivers/gpu/drm/tinydrm/ili9225.c| 2 +-
drivers/gpu/drm/tinydrm/mi0283qt.c | 3 ++-
drivers/gpu/drm/tinydrm/repaper.c| 2 +-
drivers/gpu/drm/tinydrm/st7586.c | 2 +-
drivers/gpu/drm/tinydrm/st7735r.c| 2 +-
include/drm/drm_gem_framebuffer_helper.h | 3 +++
include/drm/drm_simple_kms_helper.h | 3 +++
include/drm/tinydrm/tinydrm.h| 2 --
10 files changed, 31 insertions(+), 24 deletions(-)
Reviewed-by: Oleksandr Andrushchenko
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 4d682a6e8bcb..acfbc0641a06 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/**
* DOC: overview
@@ -265,6 +266,24 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
}
EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
+/**
+ * drm_gem_fb_simple_display_pipe_prepare_fb - prepare_fb helper for
+ * &drm_simple_display_pipe
+ * @pipe: Simple display pipe
+ * @plane_state: Plane state
+ *
+ * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has a
+ * &dma_buf attached, extracts the exclusive fence and attaches it to plane
+ * state for the atomic helper to wait on. Drivers can use this as their
+ * &drm_simple_display_pipe_funcs.prepare_fb callback.
+ */
+int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe
*pipe,
+ struct drm_plane_state
*plane_state)
+{
+ return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
+}
+EXPORT_SYMBOL(drm_gem_fb_simple_display_pipe_prepare_fb);
+
/**
* drm_gem_fbdev_fb_create - Create a GEM backed &drm_framebuffer for fbdev
* emulation
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index e68b528ae64d..7e8e24d0b7a7 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -138,23 +138,6 @@ void tinydrm_display_pipe_update(struct
drm_simple_display_pipe *pipe,
}
EXPORT_SYMBOL(tinydrm_display_pipe_update);
-/**
- * tinydrm_display_pipe_prepare_fb - Display pipe prepare_fb helper
- * @pipe: Simple display pipe
- * @plane_state: Plane state
- *
- * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has an
- * dma-buf attached, extracts the exclusive fence and attaches it to plane
- * state for the atomic helper to wait on. Drivers can use this as their
- * &drm_simple_display_pipe_funcs->prepare_fb callback.
- */
-int tinydrm_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
- return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
-}
-EXPORT_SYMBOL(tinydrm_display_pipe_prepare_fb);
-
static int tinydrm_rotate_mode(struct drm_display_mode *mode,
unsigned int rotation)
{
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 0874e877b111..841c69aba059 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -354,7 +354,7 @@ static const struct drm_simple_display_pipe_funcs
ili9225_pipe_funcs = {
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = tinydrm_display_pipe_update,
- .prepare_fb = tinydrm_display_pipe_prepare_fb,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
};
static const struct drm_display_mode ili9225_mode = {
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 4e6d2ee94e55..d5ef65179c16 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
#include
@@ -134,7 +135,7 @@ static const struct drm_simple_display_pipe_funcs
mi0283qt_pipe_funcs = {
.enable = mi0283qt_enable,
.disable = mipi_dbi_pipe_disable,
.update = tinydrm_display_pipe_update,
- .prepare_fb = tinydrm_display_pipe_prepare_fb,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
};
static const struc
[PATCH] drm: xlnx: pl_disp: fix odd_ptr_err.cocci warnings
From: Fengguang Wu
PTR_ERR should normally access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
Fixes: 742243a44a73 ("drm: xlnx: pl_disp: Use xlnx pipeline calls")
CC: Hyun Kwon
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
---
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: fe04d2ee0dfea6b5fdbb04f4f6dbcaa13bfd2fda
commit: 742243a44a738b165f8da5cbdb6662139e85a5c5 [651/842] drm: xlnx:
pl_disp: Use xlnx pipeline calls
xlnx_pl_disp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
+++ b/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
@@ -482,7 +482,7 @@ static int xlnx_pl_disp_probe(struct pla
xlnx_pl_disp->master = xlnx_drm_pipeline_init(pdev);
if (IS_ERR(xlnx_pl_disp->master)) {
- ret = PTR_ERR(xlnx_pl_disp->dev);
+ ret = PTR_ERR(xlnx_pl_disp->master);
dev_err(dev, "failed to initialize the drm pipeline\n");
goto err_component;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: sii902x: add optional power supplies
Add the 3 optional power supplies using the exact description
found in the document named
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/sii902x.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 60373d7eb220..e17ba6db1ec8 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -86,6 +87,7 @@ struct sii902x {
struct drm_bridge bridge;
struct drm_connector connector;
struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[3];
};
static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
@@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
return PTR_ERR(sii902x->reset_gpio);
}
+ sii902x->supplies[0].supply = "iovcc";
+ sii902x->supplies[1].supply = "avcc12";
+ sii902x->supplies[2].supply = "cvcc12";
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
+ sii902x->supplies);
+ if (ret) {
+ dev_err(dev, "regulator_bulk_get failed\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
+ sii902x->supplies);
+ if (ret) {
+ dev_err(dev, "regulator_bulk_enable failed\n");
+ return ret;
+ }
+
+ usleep_range(1, 2);
+
sii902x_reset(sii902x);
ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
if (ret)
- return ret;
+ goto err_disable_regulator;
ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
&chipid, 4);
if (ret) {
dev_err(dev, "regmap_read failed %d\n", ret);
- return ret;
+ goto err_disable_regulator;
}
if (chipid[0] != 0xb0) {
dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
chipid[0]);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_disable_regulator;
}
/* Clear all pending interrupts */
@@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
IRQF_ONESHOT, dev_name(dev),
sii902x);
if (ret)
- return ret;
+ goto err_disable_regulator;
}
sii902x->bridge.funcs = &sii902x_bridge_funcs;
@@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
i2c_set_clientdata(client, sii902x);
return 0;
+
+err_disable_regulator:
+ regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
+ sii902x->supplies);
+
+ return ret;
}
static int sii902x_remove(struct i2c_client *client)
@@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
drm_bridge_remove(&sii902x->bridge);
+ regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
+ sii902x->supplies);
+
return 0;
}
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/bridge: sii902x: add optional power supplies
This patchset adds the 3 optional power supplies to the sii902x drm bridge driver. Philippe Cornu (2): dt-bindings/display/bridge: sii902x: add optional power supplies drm/bridge: sii902x: add optional power supplies .../devicetree/bindings/display/bridge/sii902x.txt | 3 ++ drivers/gpu/drm/bridge/sii902x.c | 39 +++--- 2 files changed, 38 insertions(+), 4 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Add the 3 optional power supplies using the exact description found in the document named "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". Signed-off-by: Philippe Cornu --- Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 56a3e68ccb80..cf53678fe574 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -8,6 +8,9 @@ Optional properties: - interrupts-extended or interrupt-parent + interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. + - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent). + - avcc12-supply: TMDS analog supply voltage (1.2V). + - cvcc12-supply: Digital core supply voltage (1.2V). Optional subnodes: - video input: this subnode can contain a video input port node -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.18-wip 43/120] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c:127 get_start_vline() warn: unsigned 'vertical_line_start' is never less than zero.
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 5d404d3139a4624892a12683240abfae931ee849
commit: 2852a36199784540a872f42fa6dc7d8d51eee0d8 [43/120] drm/amd/display: Add
vline IRQ programming for DCN
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c:127
get_start_vline() warn: unsigned 'vertical_line_start' is never less than zero.
vim +/vertical_line_start +127
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c
95
96 static uint32_t get_start_vline(struct timing_generator *optc, const
struct dc_crtc_timing *dc_crtc_timing)
97 {
98 struct dc_crtc_timing patched_crtc_timing;
99 uint32_t vesa_sync_start;
100 uint32_t asic_blank_end;
101 uint32_t interlace_factor;
102 uint32_t vertical_line_start;
103
104 patched_crtc_timing = *dc_crtc_timing;
105 optc1_apply_front_porch_workaround(optc, &patched_crtc_timing);
106
107 vesa_sync_start = patched_crtc_timing.h_addressable +
108 patched_crtc_timing.h_border_right +
109 patched_crtc_timing.h_front_porch;
110
111 asic_blank_end = patched_crtc_timing.h_total -
112 vesa_sync_start -
113 patched_crtc_timing.h_border_left;
114
115 interlace_factor = patched_crtc_timing.flags.INTERLACE ? 2 : 1;
116
117 vesa_sync_start = patched_crtc_timing.v_addressable +
118 patched_crtc_timing.v_border_bottom +
119 patched_crtc_timing.v_front_porch;
120
121 asic_blank_end = (patched_crtc_timing.v_total -
122 vesa_sync_start -
123 patched_crtc_timing.v_border_top)
124 * interlace_factor;
125
126 vertical_line_start = asic_blank_end -
optc->dlg_otg_param.vstartup_start + 1;
> 127 if (vertical_line_start < 0) {
128 ASSERT(0);
129 vertical_line_start = 0;
130 }
131
132 return vertical_line_start;
133 }
134
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 12/33] freesync.c:undefined reference to `__udivdi3'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 24110c70630998dc83da23cae910a9538f54ef64 commit: 0547606296e739e875a294d786233bf2e6680421 [12/33] drm/amd/display: Refactor FreeSync module config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 0547606296e739e875a294d786233bf2e6680421 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.o: In function `hwss_edp_power_control': dce110_hw_sequencer.c:(.text+0xda8): undefined reference to `__udivdi3' drivers/gpu/drm/amd/display/modules/freesync/freesync.o: In function `mod_freesync_build_vrr_params': >> freesync.c:(.text+0x3b5): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 1/2] drm/panel: Add Truly Dual DSI video mode panel
On 2018-04-08 09:36, Archit Taneja wrote:
Hi Abhinav,
Thanks for posting this driver. Some comments below.
On Saturday 07 April 2018 12:36 PM, Abhinav Kumar wrote:
From: Archit Taneja
Add support for truly dual DSI video mode panel
panel used in MSM reference platforms >
Signed-off-by: Archit Taneja
Signed-off-by: Abhinav Kumar
---
.../bindings/display/truly,dual_wqxga.txt | 47 ++
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-truly-dual-dsi.c | 530
+
4 files changed, 585 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
create mode 100644 drivers/gpu/drm/panel/panel-truly-dual-dsi.c
diff --git
a/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
new file mode 100644
index 000..a1b24c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,dual_wqxga"
The compatible string, kernel config and the driver file should be
based
on the panel model no. There can be many truly based panels that
support wqxga. Something like "truly,nt35597" would be better.
[Abhinav] Yes, will change it in v2.
+- vdda-supply: phandle of the regulator that provides the supply
voltage
+ Power IC supply
+- lab-supply: phandle of the regulator that provides the supply
voltage
+ for LCD bias
+- ibb-supply: phandle of the regulator that provides the supply
voltage
+ for LCD bias
Both seem to have the same description. Aren't lab and ibb qualcomm
specific terms? Could we use the pin names specified in the panel's
data sheet?
[Abhinav] There isnt a number specified on the data sheet. I will use
vdispp-supply and
vdispn-supply . Does that work?
+- reset-gpios: phandle of gpio for reset line
+ This should be 8mA, gpio can be configured using mux, pinctrl,
pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the
display
+ for single DSI or Dual DSI
Could we describe here how to use this gpio? I.e, whether we need to
set
it to low for dual DSI, etc?
[Abhinav] Yes, will do this in v2.
+- display-timings: Node for the Panel timings
+- link2: phandle to the secondary node of the panel
The link2 binding was a temporary hack we used. We should use the
of-graph bindings to represent the two DSI input ports of the panel.
[Abhinav] Alright will start using of-graph in the next patchset.
+
+Example:
+
+ dsi@ae94000 {
+ panel@0 {
+ compatible = "truly,dual_wqxga";
+ reg = <0>;
+ link2 = <&link2>;
+ vdda-supply = <&pm8998_l14>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&sde_dsi_active>;
+ pinctrl-1 = <&sde_dsi_suspend>;
+
+ reset-gpios = <&tlmm 6 0>;
+ mode-gpios = <&tlmm 52 0>;
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = <268316138>;
+ hactive = <1440>;
+ vactive = <2560>;
+ hfront-porch = <200>;
+ hback-porch = <64>;
+ hsync-len = <32>;
+ vfront-porch = <8>;
+ vback-porch = <7>;
+ vsync-len = <1>;
+ };
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 988048e..a63c3f7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TRULY_WQXGA
+ tristate "Truly WQXGA"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ help
+ Say Y here if you want to enable support for Truly WQXGA Dual DSI
+ Video Mode panel
endmenu
[Abhinav] These configs will be updated too
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index 3d2a88d..64891f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) +=
panel-sharp-ls043t1le01.o
obj-$(C
Re: [RFC 0/2] drm/vc4: Async page flip cleanup
Boris Brezillon writes: > Hello, > > This is an attempt at simplifying the async page flip handling in VC4 > in order to get rid of vc4_queue_seqno_cb() and its dependencies and > rely on fences instead. > > The reason I'm sending this as an RFC is because I'm pretty sure we can > put some of the code added in patch 1 in drm_atomic_helper.c. Also, I'd > like to have feedback from Padovan, Daniel and maybe others who have > already thought about handling async page flips generically. > And the last reason is that it's not been extensively tested, so it may > not work correctly :-). I'm certainly eager to see our custom async code die. Any KMS core folks want to comment on this proposal? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next-4.18-wip 95/120] dce110_hw_sequencer.c:undefined reference to `__udivdi3'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip head: 5d404d3139a4624892a12683240abfae931ee849 commit: 9c1f5ab7dcce1b9ddb9321b328c5445238450671 [95/120] drm/amd/display: add delay between panel pwr off to on. config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 9c1f5ab7dcce1b9ddb9321b328c5445238450671 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.o: In function `hwss_edp_power_control': >> dce110_hw_sequencer.c:(.text+0xd78): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] ARM: dts: bcm283x: Remove the vc4 GPU subsystem node.
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm283x.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9d293decf8d3..869bf350d426 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -609,10 +609,6 @@
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
};
-
- vc4: gpu {
- compatible = "brcm,bcm2835-vc4";
- };
};
clocks {
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.
The GPU subsystem node was a workaround to have a central device to
bind V3D and display to. Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of the subsystem devices are present.
Signed-off-by: Eric Anholt
---
.../bindings/display/brcm,bcm-vc4.txt | 7
drivers/gpu/drm/vc4/vc4_drv.c | 33 ++-
drivers/gpu/drm/vc4/vc4_hvs.c | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 1 +
4 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 284e2b14cfbe..5fd4717101d6 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -4,9 +4,6 @@ The VC4 device present on the Raspberry Pi includes a display
system
with HDMI output and the HVS (Hardware Video Scaler) for compositing
display planes.
-Required properties for VC4:
-- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
-
Required properties for Pixel Valve:
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
"brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
@@ -153,10 +150,6 @@ v3d: v3d@7ec0 {
interrupts = <1 10>;
};
-vc4: gpu {
- compatible = "brcm,bcm2835-vc4";
-};
-
panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 7c95ed5c5cac..d282ab7de03a 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -364,22 +364,34 @@ static int vc4_platform_drm_remove(struct platform_device
*pdev)
return 0;
}
-static const struct of_device_id vc4_of_match[] = {
- { .compatible = "brcm,bcm2835-vc4", },
- { .compatible = "brcm,cygnus-vc4", },
- {},
-};
-MODULE_DEVICE_TABLE(of, vc4_of_match);
-
static struct platform_driver vc4_platform_driver = {
.probe = vc4_platform_drm_probe,
.remove = vc4_platform_drm_remove,
.driver = {
.name = "vc4-drm",
- .of_match_table = vc4_of_match,
},
};
+static bool
+driver_of_table_has_a_match(const struct platform_driver *driver)
+{
+ int i;
+
+ for (i = 0; driver->driver.of_match_table[i].compatible; i++) {
+ const char *compat =
driver->driver.of_match_table[i].compatible;
+ struct device_node *node;
+
+ while ((node = of_find_compatible_node(node, NULL, compat))) {
+ if (of_device_is_available(node)) {
+ of_node_put(node);
+ return true;
+ }
+ }
+ }
+
+ return false;
+}
+
static int __init vc4_drm_register(void)
{
int ret;
@@ -389,6 +401,11 @@ static int __init vc4_drm_register(void)
if (ret)
return ret;
+ if (driver_of_table_has_a_match(&vc4_v3d_driver) ||
+ driver_of_table_has_a_match(&vc4_hvs_driver)) {
+ platform_device_register_simple("vc4-drm", -1, NULL, 0);
+ }
+
return platform_driver_register(&vc4_platform_driver);
}
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b62fc5b8d85..730813ee74ae 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -262,6 +262,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
{ .compatible = "brcm,bcm2835-hvs" },
{}
};
+MODULE_DEVICE_TABLE(of, vc4_hvs_dt_match);
struct platform_driver vc4_hvs_driver = {
.probe = vc4_hvs_dev_probe,
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index bfc2fa73d2ae..e77e9ebbab4b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -459,6 +459,7 @@ static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,vc4-v3d" },
{}
};
+MODULE_DEVICE_TABLE(of, vc4_v3d_dt_match);
struct platform_driver vc4_v3d_driver = {
.probe = vc4_v3d_dev_probe,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] ARM: dts: cygnus: Remove the vc4 GPU subsystem node.
This is no longer required by the DRM driver, and was just a temporary
hack for it.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf94d139..258bb3d61582 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -492,10 +492,6 @@
status = "disabled";
};
- vc4: gpu {
- compatible = "brcm,cygnus-vc4";
- };
-
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104216] Firefox quirks (black and/or white squares)
https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #23 from Germano Massullo --- Trying to get some answers from Mozilla developers https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c17 https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c18 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC for a render API to support adaptive sync and VRR
Thanks for initiating the discussion. Find my comments below: On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote: > Adding dri-devel, which I should've included from the start. > > On 2018-04-09 03:56 PM, Harry Wentland wrote: > > === What is adaptive sync and VRR? === > > > > Adaptive sync has been part of the DisplayPort spec for a while now and > > allows graphics adapters to drive displays with varying frame timings. VRR > > (variable refresh rate) is essentially the same, but defined for HDMI. > > > > > > > > === Why allow variable frame timings? === > > > > Variable render times don't align with fixed refresh rates, leading to > > stuttering, tearing, and/or input lag. > > > > e.g. (rc = render completion, dr = display refresh) > > > > rc B CDE F > > dr A B C C D E F > > > > ^ ^ > > frame missed > > repeated display > > twice refresh > > > > > > > > === Other use cases of adaptive sync > > > > Beside the variable render case, adaptive sync also allows adjustment of > > refresh rates without a mode change. One such use case would be 24 Hz video. > > One of the the advantages here when the render speed is slower than the display refresh rate, since we are stretching the vertical blanking interval the display adapters will follow "draw fast and then go idle" approach. This gives power savings when render rate is lower than the display refresh rate. > > > > > > === A DRM render API to support variable refresh rates === > > > > In order to benefit from adaptive sync and VRR userland needs a way to let > > us know whether to vary frame timings or to target a different frame time. > > These can be provided as atomic properties on a CRTC: > > * bool variable_refresh_compatible > > * int target_frame_duration_ns (nanosecond frame duration) > > > > This gives us the following cases: > > > > variable_refresh_compatible = 0, target_frame_duration_ns = 0 > > * drive monitor at timing's normal refresh rate > > > > variable_refresh_compatible = 1, target_frame_duration_ns = 0 > > * send new frame to monitor as soon as it's available, if within min/max > > of monitor's reported capabilities > > > > variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0 > > * send new frame to monitor with the specified target_frame_duration_ns > > > > When a target_frame_duration_ns or variable_refresh_compatible cannot be > > supported the atomic check will reject the commit. > > What I would like is two sets of properties on a CRTC or preferably on a connector: KMD properties that UMD can query: * vrr_capable - This will be an immutable property for exposing hardware's capability of supporting VRR. This will be set by the kernel after reading the EDID mode information and monitor range capabilities. * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh rates supported. These properties are optional and will be created and attached to the DP/eDP connector when the connector is getting intialized. Properties that you mentioned above that the UMD can set before kernel can enable VRR functionality *bool vrr_enable or vrr_compatible target_frame_duration_ns The monitor only specifies the monitor range through EDID. Apart from this should we also need to scan the modes and check if there are modes that have the same pixel clock and horizontal timings but variable vertical totals? I have RFC patches for all the above mentioned. If we get a concensus/agreement on the above properties and method to check monitor's VRR capability, I can submit those patches atleast as RFC. Regards Manasi > > > > > > === Previous discussions === > > > > https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html > > > > > > > > === Feedback and moving forward === > > > > I'm hoping to get some feedback on this or continue the discussion on how > > adaptive sync / VRR might look like in the DRM ecosystem. Once there are no > > major concerns or objections left we'll probably start creating some > > patches to sketch this out a bit better and see how it looks in practice. > > > > > > > > Cheers, > > Harry > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] clk: sunxi-ng: sun5i: Export the MBUS clock
On Tue, Apr 03, 2018 at 03:29:19PM +0200, Maxime Ripard wrote: > The MBUS clock is used by the MBUS controller, so let's export it so that > we can use it in our DT node. > > Signed-off-by: Maxime Ripard > --- > drivers/clk/sunxi-ng/ccu-sun5i.h | 4 > include/dt-bindings/clock/sun5i-ccu.h | 2 +- > 2 files changed, 1 insertion(+), 5 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] display: panel: Add AUO g070vvn01 display support (800x480)
On Tue, Apr 03, 2018 at 12:15:25PM +0200, Lukasz Majewski wrote:
> This commit adds support for AUO's 7.0" display.
>
> Signed-off-by: Lukasz Majewski
> ---
> .../bindings/display/panel/auo,g070vvn01 | 30 +
.txt
> drivers/gpu/drm/panel/panel-simple.c | 31
> ++
> 2 files changed, 61 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/auo,g070vvn01
>
> diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> new file mode 100644
> index ..bd4017362094
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> @@ -0,0 +1,30 @@
> +AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,g070vvn01"
> +- backlight: phandle of the backlight device attached to the panel
> +- power-supply: single regulator to provide the supply voltage
> +
> +Required nodes:
> +- port: Parallel port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is conntrolled
> +via PWM signal.
> +
> +Example:
> +
> +
> +Example device-tree definition when connected to iMX6Q based board
> +
> + lcd_panel: lcd-panel {
> + compatible = "auo,g070vvn01";
> + backlight = <&backlight_lcd>;
> + bus-format-override = "rgb565";
This is not documented though it appears in a few i.MX dts files.
> + power-supply = <®_display>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH 1/2] drm/msm/dsi: check video mode engine status before waiting
On 2018-04-09 08:28, Jordan Crouse wrote:
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise it leads to silent timeouts increasing display
turn ON time.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..24766c3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {
bool registered;
bool power_on;
+ bool enabled;
int irq;
};
@@ -986,13 +987,18 @@ static void dsi_set_tx_power_mode(int mode,
struct msm_dsi_host *msm_host)
static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
{
+ u32 ret = 0;
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
reinit_completion(&msm_host->video_comp);
- wait_for_completion_timeout(&msm_host->video_comp,
+ ret = wait_for_completion_timeout(&msm_host->video_comp,
msecs_to_jiffies(70));
+ if (ret <= 0)
+ pr_err("wait for video done failed\n");
+
Does this need to be rate limited? How often will it print? Also,
'wait for
video done timed out" would be more descriptive for the situation. I'm
not sure
from the context if you have a pr_fmt defined for this file but if you
don't you
might want to add the appropriate prefixes (or use dev_err) so the
reader can
get a bit more detailed information about where to look and what is
going on.
Jordan
[Abhinav] With the rest of this change, this error should not happen.
This will print whenever we need to call this for waiting for each panel
command.
The number of panel commands can vary with panel from < 10 to 100s at
times.
But since we do not expect this to happen at all, at this point i dont
think we need
to rate limit this.
Yes, will replace the pr_err with dev_err in V2.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i2c: tda998x: Remove VLA usage
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
This one really feels like it should be a #define but I wasn't sure
where the 32 came from. It looks like most other uses use one of the
#defines in include/linux/hdmi?
---
drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9e67a7b4e3a4..29e2f49601c7 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -470,7 +470,8 @@ static void
reg_write_range(struct tda998x_priv *priv, u16 reg, u8 *p, int cnt)
{
struct i2c_client *client = priv->hdmi;
- u8 buf[cnt+1];
+ /* This is the maximum size of the buffer passed in */
+ u8 buf[33];
int ret;
buf[0] = REG2ADDR(reg);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500: Remove VLA
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
This was a little hard to figure out but I think 32 should be a
comfortable upper bound based on all the structures I saw. Of course I
can't test it.
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 84507912be84..3d4fa9f6b94c 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -429,13 +429,20 @@ static const char *cmd_status_names[] = {
"Scaling not supported"
};
+#define MAX_ARG_LEN 32
+
static bool psb_intel_sdvo_write_cmd(struct psb_intel_sdvo *psb_intel_sdvo, u8
cmd,
const void *args, int args_len)
{
- u8 buf[args_len*2 + 2], status;
- struct i2c_msg msgs[args_len + 3];
+ u8 buf[MAX_ARG_LEN*2 + 2], status;
+ struct i2c_msg msgs[MAX_ARG_LEN + 3];
int i, ret;
+ if (args_len > MAX_ARG_LEN) {
+ DRM_ERROR("Need to increase arg length\n");
+ return false;
+ }
+
psb_intel_sdvo_debug_write(psb_intel_sdvo, cmd, args, args_len);
for (i = 0; i < args_len; i++) {
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Remove vla
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms. Switch to a constant size array
instead.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Laura Abbott
---
drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..c9863858f343 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
{
struct kfd_dev *dev = container_of(work, struct kfd_dev,
interrupt_work);
+ uint32_t ih_ring_entry[4];
- uint32_t ih_ring_entry[DIV_ROUND_UP(
- dev->device_info->ih_ring_entry_size,
- sizeof(uint32_t))];
+ if (dev->device_info->ih_ring_entry_size > (4 * sizeof(uint32_t))) {
+ dev_err(kfd_chardev(), "Ring entry too small\n");
+ return;
+ }
while (dequeue_ih_ring_entry(dev, ih_ring_entry))
dev->device_info->event_interrupt_class->interrupt_wq(dev,
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Fix leak of the file_priv that stored the perfmon.
Signed-off-by: Eric Anholt
Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace")
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..7c95ed5c5cac 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -130,6 +130,7 @@ static void vc4_close(struct drm_device *dev, struct
drm_file *file)
struct vc4_file *vc4file = file->driver_priv;
vc4_perfmon_close_file(vc4file);
+ kfree(vc4file);
}
static const struct vm_operations_struct vc4_vm_ops = {
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104597] [bisected] Compton weird colors
https://bugs.freedesktop.org/show_bug.cgi?id=104597 Timothy Arceri changed: What|Removed |Added CC||c...@fuckyouprius.com --- Comment #17 from Timothy Arceri --- *** Bug 105918 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 5/8] dt-bindings: panel: common: document orientation property
On Fri, Mar 30, 2018 at 07:18:19PM +0200, Sebastian Reichel wrote: > Merge "rotation" property description into common panel > binding. > > Suggested-by: Rob Herring > Signed-off-by: Sebastian Reichel > --- > .../devicetree/bindings/display/panel/panel-common.txt | 12 > > Documentation/devicetree/bindings/display/panel/panel.txt| 4 > 2 files changed, 12 insertions(+), 4 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt Reviewed-by: Rob Herring Thanks for consolidating. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drivers: remove force dma flag from buses
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. > > Signed-off-by: Nipun Gupta > --- > Changes in v2: > - This is a new change suggested by Robin and Christoph > and is added to the series. > > Changes in v3: > - Rebase and changes corresponding to the changes in patch 1/2 > > drivers/amba/bus.c| 1 - > drivers/base/platform.c | 3 +-- > drivers/bcma/main.c | 2 +- > drivers/dma/qcom/hidma_mgmt.c | 2 +- > drivers/gpu/host1x/bus.c | 5 ++--- > drivers/of/device.c | 6 -- > drivers/of/of_reserved_mem.c | 2 +- > drivers/pci/pci-driver.c | 3 +-- > include/linux/device.h| 4 > include/linux/of_device.h | 8 ++-- > 10 files changed, 17 insertions(+), 19 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #19 from MirceaKitsune --- (In reply to Alex Deucher from comment #18) > Those parameters are not used on your chip. That would be quite something, since after setting them I've clearly seen an enormous difference. I will investigate further in the upcoming days. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/vc4: false-positive negative cursor position warning
Daniel J Blueman writes: > Hi Eric et al, > > In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B > on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4, > tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y > < 0) [1], which therefore seems false-positive. > > Git history doesn't turn up any reason, eg it could cause undefined > hardware behaviour, which it doesn't appear to, so would it be better > to drop the warning, or adjust it to trip on x or y < -4 or so? If so, > I'll prepare a patch to adjust it. Ccing Boris, who's been doing work on the async update path. Take a look at vc4_plane_setup_clipping_and_scaling(state) -- that has the corrections necessary for negative x/y. We're calling that too late (through the avc4_plane_atomic_check() path) for this function's usage of the offsets[]. Since it affects the computed src_w/h, we'd have to update those as well in our async update. Our async update is racy in a way that makes me uncomfortable -- the HVS could process our display list at any point in our writel() sequence, which is not very atomic. Maybe we should be using a double-buffered HVS display list per element, and then have the main display list jump into each element's current display list and back out, so that we can do async flips to new plane state by just commiting a single writel() to the new HVS display element list. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #18 from Alex Deucher --- (In reply to MirceaKitsune from comment #17) > I will continue trying different values and seeing how tweaking them changes > the issue. Please let me know what you think. Those parameters are not used on your chip. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC for a render API to support adaptive sync and VRR
Adding dri-devel, which I should've included from the start. On 2018-04-09 03:56 PM, Harry Wentland wrote: > === What is adaptive sync and VRR? === > > Adaptive sync has been part of the DisplayPort spec for a while now and > allows graphics adapters to drive displays with varying frame timings. VRR > (variable refresh rate) is essentially the same, but defined for HDMI. > > > > === Why allow variable frame timings? === > > Variable render times don't align with fixed refresh rates, leading to > stuttering, tearing, and/or input lag. > > e.g. (rc = render completion, dr = display refresh) > > rc B CDE F > drA B C C D E F > > ^ ^ > frame missed >repeated display > twice refresh > > > > === Other use cases of adaptive sync > > Beside the variable render case, adaptive sync also allows adjustment of > refresh rates without a mode change. One such use case would be 24 Hz video. > > > > === A DRM render API to support variable refresh rates === > > In order to benefit from adaptive sync and VRR userland needs a way to let us > know whether to vary frame timings or to target a different frame time. These > can be provided as atomic properties on a CRTC: > * bool variable_refresh_compatible > * inttarget_frame_duration_ns (nanosecond frame duration) > > This gives us the following cases: > > variable_refresh_compatible = 0, target_frame_duration_ns = 0 > * drive monitor at timing's normal refresh rate > > variable_refresh_compatible = 1, target_frame_duration_ns = 0 > * send new frame to monitor as soon as it's available, if within min/max of > monitor's reported capabilities > > variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0 > * send new frame to monitor with the specified target_frame_duration_ns > > When a target_frame_duration_ns or variable_refresh_compatible cannot be > supported the atomic check will reject the commit. > > > > === Previous discussions === > > https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html > > > > === Feedback and moving forward === > > I'm hoping to get some feedback on this or continue the discussion on how > adaptive sync / VRR might look like in the DRM ecosystem. Once there are no > major concerns or objections left we'll probably start creating some patches > to sketch this out a bit better and see how it looks in practice. > > > > Cheers, > Harry > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix memory leak during BO teardown
Daniel J Blueman writes: > During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being > freed leading to leaking many 128B allocations. Fix the memory leak by > releasing it at teardown time. Reviewed, added a Fixes tag, and pushed to drm-misc-fixes. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #17 from MirceaKitsune --- I have a very important preliminary result: Today I tested the last amdgpu parameters on the list, and seem to have found a set that greatly mitigates the problem. Those parameters have given me up to 144 minutes before experiencing the freeze, a huge record compared to the previous 90 minutes! They are: amdgpu.prim_buf_per_se=16 amdgpu.pos_buf_per_se=16 amdgpu.cntl_sb_buf_per_se=16 amdgpu.param_buf_per_se=16 By default, all 4 of those settings are set to 0 by the system. Setting them to 16 has, at least during one test case, reduced the problem to 1/5 of its previous frequency. The descriptions of the variables are: parm: prim_buf_per_se:the size of Primitive Buffer per Shader Engine (default depending on gfx) (int) parm: pos_buf_per_se:the size of Position Buffer per Shader Engine (default depending on gfx) (int) parm: cntl_sb_buf_per_se:the size of Control Sideband per Shader Engine (default depending on gfx) (int) parm: param_buf_per_se:the size of Off-Chip Pramater Cache per Shader Engine (default depending on gfx) (int) I will continue trying different values and seeing how tweaking them changes the issue. Please let me know what you think. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format
On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote: > If the bridge changes the bus format, allow this to be described in > the bridge, instead of providing false information about the bus > format of the connector or panel. I guess this is dead, but I'll comment here anyway because this issue has come up several times and I think something is needed. > > Signed-off-by: Peter Rosin > --- > .../bindings/display/bridge/lvds-transmitter.txt | 6 ++ > drivers/gpu/drm/bridge/lvds-encoder.c | 25 > ++ > 2 files changed, 31 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > index 50220190c203..8d40a2069252 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > @@ -30,6 +30,12 @@ Required properties: >device-specific version corresponding to the device first >followed by the generic version. > > +Optional properties: > + > +- interface-pix-fmt: > + List of valid input bus formats of the encoder. Recognized bus formats > + are listed in ../bus-format.txt We already have bus interface properties defined in media/video-interfaces.txt. It's the same problem though the bus/pixel formats are somewhat different. "bus-width" is probably enough to handle your particular case, but I'd imagine that could easily not be the case. If so, we should extend the existing binding rather than diverge with something new. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen wrote: > Hi Rob, > > On 23/03/18 03:23, Rob Herring wrote: > >>> Ok, I think the description was a bit unclear. So, the driver can do >>> this just fine, it can reserve hw planes dynamically when needed. The >>> problem is the userspace. >>> >>> When a DRM application starts, it sees a bunch of planes, and can see on >>> which crtcs each plane can be used. The expectation is, of course, that >>> these planes can be used normally. If the driver would dynamically >>> reserve an additional, currently unused plane, the userspace would be >>> totally baffled, as it fails to configure basic plane setups. >>> >>> For example, the userspace could see that there are two planes, usable >>> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail >>> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, >>> except when the LCD already has a plane. Setting up two planes on the >>> LCD would work, but moving one or both planes to the HDMI would fail. Etc. >> >> I suspect this is a common problem. Not because the h/w requires >> different allocation of planes, but because the memory bandwidth can't >> handle having a 2nd plane if the resolution is above a certain >> size/depth. So while the plane doesn't disappear, the effect is the >> same. How does DRM handle this? > > I don't think DRM handles this. Each driver can probably filter out > videomodes which it knows can't be used even with single plane (we do > this on omapdrm), and also can give an error if the plane setup would > result in too high bandwidth use. > > So yes, plane setups can always fail, "mysteriously" from userspace's > perspective. But I don't think it's exactly comparable to this one. The > difference is that in this case we can avoid all the userspace issues > with a simple static plane partitioning done at probe time, but I can't > see how the bandwidth issue could be solved in a similar way. > >>> We could, of course, convey this information to the userspace at runtime >>> via the DRM properties, but then it would mean we'd need customized >>> applications. >>> >>> So, as far as I can see, keeping normal DRM behavior with 2k+ displays >>> on OMAP DSS requires a static virtual plane setup. The most simple setup >>> would be to just split the number of available planes by 2, but then in >>> many use cases that wastes one hw plane. >> >> For HDMI, you can't know in advance what resolution will be. So I >> think you always need to reserve 2 planes. Now, if you want to reduce > > We can decide not to support 2k+ resolutions for HDMI, which, with this > series, happens by not reserving dual-plane for the HDMI. Right. So turn this around. Define in DT what is the maximum resolution supported for HDMI and configure the planes based on that. The difference is defining a max is generic enough that it can work for others and for a variety of reasons whether it is # of planes, memory bandwidth, crappy monitor, poor board signal quality, etc. >> the max resolution for some reason, I guess we could have properties >> for that. That would be more generic and work whether you need to >> change plane allocation or have a limit for other reasons. >> >> For attached panels, you know the resolution up front and can allocate >> planes before the userspace interface is up. > > But reserve how many of the planes? We have N planes and M displays. For > some of the displays we know they're 2k+, some are known to be -2k and > some are unknown. The driver can't independently make any sensible > static reservation of the planes for the displays, because it doesn't > know what the user wants to do. After you've handled HDMI as above and any permanently attached panels with fixed resolutions, what is left for a user to configure? Perhaps only one display can support an overlay at that point because you are out of planes? > So either we reserve the extra planes at runtime on demand, making it > difficult to manage for the userspace, or we rely on the user to give > the driver a static partitioning of the planes according to the user's > use case. And by user, who do you mean exactly? The use case is tied to the board design and product or tied to the whims of an end user (e.g. I want to do video playback with overlay to disp 2)? You should equate users making DT changes with telling users to update/change their BIOS. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clips, 0);
> > > > +}
> > > > diff --git a/include/drm/drm_mode_config.h
> > > b/include/drm/drm_mode_config.h
> > > > index 7569f22..d8767da 100644
> > > > --- a/include/drm/drm_mode_config.h
> > > > +++ b/include/drm/drm_mode_config.h
> > > > @@ -628,6 +628,21 @@ struct drm_mode_config {
> > > > */
> > > > struct drm_property *prop_crtc_id;
> > > > /**
> > > > +* @prop_damage_clips: Optional plane property to mark damaged
> > > regions
> > > > +* on the plane in framebuffer coordinates of the framebuffer
> > > attached
> > > > +* to the plane.
> > >
> > > Why should we make this optional? Looks like just another thing drivers
> > > might screw up, since we have multiple callbacks and things to set up for
> > > proper dirty tracking.
> >
> > Thanks Daniel for the review.
> >
> > I think not all compositor will be interested in sending damage, that was
> > the
> > reason to make this optional. Also when damage is not set that means
> > user-space need full update just like eglSwapBuffersWithDamageKHR.
> >
> > I will add better documentation.
>
> I think if we also handle this case in the helper that'd be even better:
> In the case of no damage, the helper/core code could automatically supply
> a damage rect for the entire buffer. That way drivers don't have to handle
> this case specially.
> -Daniel
Agreed.
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> >> > malidp_pm_suspend_late checks if the runtime status is not suspended
> >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> >> > display engine/core interrupts and the clocks. It sets the runtime status
> >> > as suspended. Subsequently, malidp_pm_resume_early will invoke
> >> > malidp_runtime_pm_resume which enables the clocks and the interrupts
> >> > (previously disabled) and sets the runtime status as active.
> >> >
> >> > Signed-off-by: Ayan Kumar Halder
> >> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
> >>
> >> Why exactly do you need late/early hooks? If you have dependencies with
> >> other devices, pls consider adding device_links instead. This here
> >> shouldn't be necessary.
> >> -Daniel
> > We need to late/early hooks to disable malidp interrupts and the
> > clocks.
>
> Yes, but why this ordering constraint? Why can't you just disable the
> interrupts/clocks in the normal suspend code. I see that the patch
> does this, I want to understand why it does it.
> -Daniel
Apologies for my delayed response on this.
With reference to https://lwn.net/Articles/505683/ :-
1. "suspend() should leave the device in a quiescent state." We invoke
drm_mode_config_helper_suspend() which deactivates the crtc. I
understand that this is the quiescent state.
2. "suspend_late() can often be the same as runtime_suspend()." We
invoke runtime suspend/resume calls in late/early hooks.
This article is from 2012. That's not really recommended best practices
anymore. device_links have only been added a few years ago, so ofc an
article from 2012 can't tell you that you should use those instead :-)
That's why I brought this up, we have much better ways to handle device
dependencies now.
We aren't trying to manage any device dependencies here, I don't know
where that idea came from?
The kernel-doc on drm-next this afternoon says effectively the same
thing:
* @suspend: Executed before putting the system into a sleep state in which the
* contents of main memory are preserved. The exact action to perform
* depends on the device's subsystem (PM domain, device type, class or bus
* type), but generally the device must be quiescent after subsystem-level
* @suspend() has returned, so that it doesn't do any I/O or DMA.
* Subsystem-level @suspend() is executed for all devices after invoking
* subsystem-level @prepare() for all of them.
(i.e. suspend() makes the device quiescent).
* @suspend_late: Continue operations started by @suspend(). For a number of
* devices @suspend_late() may point to the same callback routine as the
* runtime suspend callback.
(suggests suspend_late() be assigned to the same function as runtime
suspend).
As for why, my understanding is like so:
For ->suspend(), we use the DRM helper, which disables the CRTC.
Normally disabling the CRTC would be enough to also invoke our
pm_runtime callback to do the final clock disable etc., however when a
system suspend is in-progress, the core forcibly takes a runtime
reference on all devices - preventing any pm_runtime paths from
running.
This means that after the CRTC is disabled in ->suspend(), our normal
pm_runtime path will not be invoked, and so the things done in
malidp_runtime_pm_suspend() will never happen.
We were just following the advice in the kernel-doc to deal with this.
The alternative would be to call malidp_runtime_pm_{suspend,resume}
from the "not late" hooks, but I'd ask why?
Also, you still haven't explained what exactly the dependency is.
Because there isn't one :-)
Thanks,
-Brian
-Daniel
> >> > ---
> >> > drivers/gpu/drm/arm/malidp_drv.c | 17 +
> >> > 1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
b/drivers/gpu/drm/arm/malidp_drv.c
> >> > index bd44a6d..f6124d8 100644
> >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> >> > @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct
device *dev)
> >> > return 0;
> >> > }
> >> >
> >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> >> > +{
> >> > + if (!pm_runtime_status_suspended(dev)) {
> >> > + malidp_runtime_pm_suspend(dev);
> >> > + pm_runtime_set_suspended(dev);
> >> > + }
> >> > + return 0;
> >> > +}
> >> > +
> >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> >> > +{
> >> > + malidp_runtime_pm_resume(dev);
> >> > + pm_runtime_set_active(dev);
> >> > + return 0;
> >> > +}
> >> >
[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2
https://bugzilla.kernel.org/show_bug.cgi?id=199319 zxvfxwing (zxvfxw...@protonmail.com) changed: What|Removed |Added CC||zxvfxw...@protonmail.com --- Comment #11 from zxvfxwing (zxvfxw...@protonmail.com) --- Flickering here too: 4.16.0-2-ARCH, RX480, Mesa 18.0.0, x11 (X.Org 1.19.6). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH 1/2] drm/msm/dsi: check video mode engine status before waiting
On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
>
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 7a03a94..24766c3 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -173,6 +173,7 @@ struct msm_dsi_host {
>
> bool registered;
> bool power_on;
> + bool enabled;
> int irq;
> };
>
> @@ -986,13 +987,18 @@ static void dsi_set_tx_power_mode(int mode, struct
> msm_dsi_host *msm_host)
>
> static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
> {
> + u32 ret = 0;
> +
> dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
>
> reinit_completion(&msm_host->video_comp);
>
> - wait_for_completion_timeout(&msm_host->video_comp,
> + ret = wait_for_completion_timeout(&msm_host->video_comp,
> msecs_to_jiffies(70));
>
> + if (ret <= 0)
> + pr_err("wait for video done failed\n");
> +
Does this need to be rate limited? How often will it print? Also, 'wait for
video done timed out" would be more descriptive for the situation. I'm not sure
from the context if you have a pr_fmt defined for this file but if you don't you
might want to add the appropriate prefixes (or use dev_err) so the reader can
get a bit more detailed information about where to look and what is going on.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: clarify adjusted_mode documentation for bridges
This patch clarifies the adjusted_mode documentation
for bridges.
Signed-off-by: Philippe Cornu
Signed-off-by: Laurent Pinchart
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
https://patchwork.freedesktop.org/patch/215449/
include/drm/drm_bridge.h | 16
include/drm/drm_crtc.h | 11 +++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7d632c6a9214 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -178,6 +178,22 @@ struct drm_bridge_funcs {
* then this would be &drm_encoder_helper_funcs.mode_set. The display
* pipe (i.e. clocks and timing signals) is off when this function is
* called.
+*
+* The adjusted_mode parameter corresponds to the mode output by the
CRTC
+* for the first bridge in the chain. It can be different from the mode
+* parameter that contains the desired mode for the connector at the end
+* of the bridges chain, for instance when the first bridge in the chain
+* performs scaling. The adjusted mode is mostly useful for the first
+* bridge in the chain and is likely irrelevant for the other bridges.
+*
+* For atomic drivers the adjusted_mode is the mode stored in
+* &drm_crtc_state.adjusted_mode.
+*
+* NOTE:
+*
+* If a need arises to store and access modes adjusted for other
locations
+* than the connection between the CRTC and the first bridge, the DRM
+* framework will have to be extended with DRM bridge states.
*/
void (*mode_set)(struct drm_bridge *bridge,
struct drm_display_mode *mode,
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a2d81d2907a9..65f749a9e9d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -134,10 +134,13 @@ struct drm_crtc_state {
*
* Internal display timings which can be used by the driver to handle
* differences between the mode requested by userspace in @mode and what
-* is actually programmed into the hardware. It is purely driver
-* implementation defined what exactly this adjusted mode means. Usually
-* it is used to store the hardware display timings used between the
-* CRTC and encoder blocks.
+* is actually programmed into the hardware.
+*
+* For drivers using drm_bridge, this stores the hardware display
timings
+* used between the CRTC and the first bridge. For other drivers, the
+* meaning of the adjusted_mode field is purely driver implementation
+* defined information, and will usually be used to store the hardware
+* display timings used between the CRTC and encoder blocks.
*/
struct drm_display_mode adjusted_mode;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers
On 04/05/2018 10:44 AM, Daniel Vetter wrote: There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: David Airlie Cc: David Lechner Cc: "Noralf Trønnes" Cc: Daniel Vetter Cc: Shawn Guo Cc: Neil Armstrong Cc: Daniel Stone Cc: Haneen Mohammed Cc: Ben Widawsky Cc: "Ville Syrjälä" --- Acked-by: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/msm/dsi: replace version checks with helper functions
Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
1 file changed, 29 insertions(+), 213 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 46e992f706d8..d82e673a1c7e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -426,19 +426,6 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&
- cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
- msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
- if (IS_ERR(msm_host->byte_intf_clk)) {
- ret = PTR_ERR(msm_host->byte_intf_clk);
- pr_err("%s: can't find byte_intf clock. ret=%d\n",
- __func__, ret);
- goto exit;
- }
- } else {
- msm_host->byte_intf_clk = NULL;
- }
-
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -453,31 +440,8 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {
- msm_host->src_clk = msm_clk_get(pdev, "src");
- if (IS_ERR(msm_host->src_clk)) {
- ret = PTR_ERR(msm_host->src_clk);
- pr_err("%s: can't find src clock. ret=%d\n",
- __func__, ret);
- msm_host->src_clk = NULL;
- goto exit;
- }
-
- msm_host->esc_clk_src = clk_get_parent(msm_host->esc_clk);
- if (!msm_host->esc_clk_src) {
- ret = -ENODEV;
- pr_err("%s: can't get esc clock parent. ret=%d\n",
- __func__, ret);
- goto exit;
- }
-
- msm_host->dsi_clk_src = clk_get_parent(msm_host->src_clk);
- if (!msm_host->dsi_clk_src) {
- ret = -ENODEV;
- pr_err("%s: can't get src clock parent. ret=%d\n",
- __func__, ret);
- }
- }
+ if (cfg_hnd->ops->clk_init_ver)
+ ret = cfg_hnd->ops->clk_init_ver(msm_host);
exit:
return ret;
}
@@ -681,16 +645,6 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
return ret;
}
-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)
-{
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
- return dsi_link_clk_enable_6g(msm_host);
- else
- return dsi_link_clk_enable_v2(msm_host);
-}
-
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
{
clk_disable_unprepare(msm_host->esc_clk);
@@ -708,24 +662,6 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)
-{
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
- clk_disable_unprepare(msm_host->esc_clk);
- clk_disable_unprepare(msm_host->pixel_clk);
- if (msm_host->byte_intf_clk)
- clk_disable_unprepare(msm_host->byte_intf_clk);
- clk_disable_unprepare(msm_host->byte_clk);
- } else {
- clk_disable_unprepare(msm_host->pixel_clk);
- clk_disable_unprepare(msm_host->src_clk);
- clk_disable_unprepare(msm_host->esc_clk);
- clk_disable_unprepare(msm_host->byte_clk);
- }
-}
-
int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host)
{
struct drm_display_mode *mode = msm_host->mode;
@@ -804,73 +740,6 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host)
return 0;
}
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
-{
- struct drm_display_mode *mode = msm_host->mode;
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
- u8 lanes = msm_host->lanes;
- u32 bpp = dsi_get_bpp(msm_host->format);
- u32 pclk_rate;
-
- if (!mode) {
- pr_err("%s: mode not set\n", __func__);
- return -EINVAL;
- }
-
- pclk_rate = mode->clock * 1000;
- if (lanes > 0) {
- msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
- } else {
- pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
- msm_host->byte_clk_rate = (pclk_r
[PATCH v3 2/3] drm/msm/dsi: add implementation for helper functions
Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 15 +++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 --
drivers/gpu/drm/msm/dsi/dsi_host.c | 218 -
3 files changed, 278 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 80be83e8fdec..dfa049d876bd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
int msm_dsi_host_init(struct msm_dsi *msm_dsi);
int msm_dsi_runtime_suspend(struct device *dev);
int msm_dsi_runtime_resume(struct device *dev);
+int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
+int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
+int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
+void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
+void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
+void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
+int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
+int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
/* dsi phy */
struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 0327bb54b01b..dcdfb1bb54f9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -136,20 +136,58 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
.num_dsi = 2,
};
+const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_v2,
+ .link_clk_disable = dsi_link_clk_disable_v2,
+ .clk_init_ver = dsi_clk_init_v2,
+ .tx_buf_alloc = dsi_tx_buf_alloc_v2,
+ .tx_buf_get = dsi_tx_buf_get_v2,
+ .tx_buf_put = NULL,
+ .dma_base_get = dsi_dma_base_get_v2,
+ .calc_clk_rate = dsi_calc_clk_rate_v2,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g,
+ .clk_init_ver = NULL,
+ .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+ .tx_buf_get = dsi_tx_buf_get_6g,
+ .tx_buf_put = dsi_tx_buf_put_6g,
+ .dma_base_get = dsi_dma_base_get_6g,
+ .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g,
+ .clk_init_ver = dsi_clk_init_6g_v2,
+ .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+ .tx_buf_get = dsi_tx_buf_get_6g,
+ .tx_buf_put = dsi_tx_buf_put_6g,
+ .dma_base_get = dsi_dma_base_get_6g,
+ .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
- {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, &apq8064_dsi_cfg},
+ {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
+ &apq8064_dsi_cfg, &msm_dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
- &msm8974_apq8084_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, &msm8994_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, &msm8916_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, &msm8996_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, &sdm845_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
+ &msm8994_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
+ &msm8916_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
+
[PATCH v3 0/3] Cleanup excessive DSI host controller version checks
This patch series aims to create and bind dsi host controller helper functions to functionalities that vary across DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers. These functionalities are currently under excessive version checks which is now replaced with the corresponding helper function. V3: Removed redundant mode checks in calc_clk_rate_6g/v2 Removed dev->struct_mutex unlock in tx_buf_alloc_6g Use msm_gem_kernel_new in tx_buf_alloc_6g Modified author to first name/last name format V2: Removes command broadcast support for DSI 6G v2.0+ controllers from the patch series and incorporates all the suggested corrections Sibi Sankar (3): drm/msm/dsi: add dsi host helper functions support drm/msm/dsi: add implementation for helper functions drm/msm/dsi: replace version checks with helper functions drivers/gpu/drm/msm/dsi/dsi.h | 16 ++ drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 +- drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12 ++ drivers/gpu/drm/msm/dsi/dsi_host.c | 356 - 4 files changed, 268 insertions(+), 172 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/msm/dsi: add dsi host helper functions support
Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..80be83e8fdec 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -149,6 +149,7 @@ static inline int msm_dsi_pll_set_usecase(struct
msm_dsi_pll *pll,
#endif
/* dsi host */
+struct msm_dsi_host;
int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 9cfdcf1c95d5..a795a062b779 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -40,10 +40,22 @@ struct msm_dsi_config {
const int num_dsi;
};
+struct msm_dsi_host_cfg_ops {
+ int (*link_clk_enable)(struct msm_dsi_host *msm_host);
+ void (*link_clk_disable)(struct msm_dsi_host *msm_host);
+ int (*clk_init_ver)(struct msm_dsi_host *msm_host);
+ int (*tx_buf_alloc)(struct msm_dsi_host *msm_host, int size);
+ void* (*tx_buf_get)(struct msm_dsi_host *msm_host);
+ void (*tx_buf_put)(struct msm_dsi_host *msm_host);
+ int (*dma_base_get)(struct msm_dsi_host *msm_host, uint64_t *iova);
+ int (*calc_clk_rate)(struct msm_dsi_host *msm_host);
+};
+
struct msm_dsi_cfg_handler {
u32 major;
u32 minor;
const struct msm_dsi_config *cfg;
+ const struct msm_dsi_host_cfg_ops *ops;
};
const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #7 from Zach Tibbitts --- This issue is also persisting with the latest update to Civ VI, including the Rise and Fall expansion. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #80 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Ricardo Ribalda from comment #79) > Hi Jerome > > Not really, I am waiting for some feedback from Andrey. > > > With the env. variable: > > GALLIUM_DDEBUG=flush > > it works better, but still not perfect. > > Andrey, did you managed to replicate the issue? I can send you a root file > system. > > > Regards! Unfortunately I have been side tracked by more prioritized issues, I definitely will get to this, it's on my TODO list. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU/DRM issue with DSI commands on msm 8916
On Monday 09 April 2018 04:28 PM, Daniel Mack wrote: Hi Archit, Thanks a lot for your reply. On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote: On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote: I'm having issues with the GPU/DRM drivers on a msm8916 based platform which is very similar to the DragonBoard 410c. In my setup, a DSI display is directly connected to the SoC, and the video link is stable. However, when the host sends DCS commands down to the DSI panel (for instance to set the backlight brightness), the image drops out, most of the time only in terms of a short flicker, but sometimes it will completely kill the image. In the latter case, only restarting the Wayland compositor in userspace helps. This is also quite reproducible; sending a NOP command once a second would give a visual flicker in 90% of the cases, and it needs at most a minute to make the screen turn black. The interesting thing is that this used to work in a v4.9 based version, but it broke somewhere on the way to v4.14. Unfortunately, the platform does not boot a vanilla kernel, so I can't really bisect this. We currently depend on the Linaro downstream patches which can be found here: The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a DSI point of view was probably the addition of runtime PM support. The register configurations that are responsible for interleaving DCS commands while video mode is still on should be the same. Yeah, I think so too. I compared a lot of code but couldn't really find anything either. At least, the command buffer contents and lengths are identical. You could comment out the pm_runtime_put_sync() calls in drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got reset during put_sync and weren't restored correctly after get_sync(). That was my first suspicion too, but unfortunately, that's not the culprit. I think it would be good to comment out the put_sync() calls in drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c and drivers/gpu/drm/msm/msm_drv.c too, since there is a parent-child hierarchy between DSI and the top level MDSS block. Commenting out the put_syncs() just in put_sync() might still result in the MDSS GDSC to switch off. Does your device initialize a splash screen in the bootloader? It does, but that's the case for either of the two kernels. Do you think that matters? And as you mention it - I'm building the driver as module, because when built into the kernel, the msm driver fails to initialize the hardware, and the console is flooded with the following message: The bootloader may have configured some additional registers that the DSI driver in the kernel doesn't touch. On 4.9, these registers would have retained their state since we don't do any PM stuff. On 4.14, these registers would probably lose their state, which results in a difference in behavior. This can be avoided by commenting all the put_sync() calls as mentioned above. [ 63.356837] dsi_err_worker: status=4 You could also compare the reg dumps between 4.9 and 4.14 by enabling the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are any register configuration differences between the two. I did that, and there a quite a number of changes, mostly because the KMS bits have changed a lot. Given that I'm not too familiar with this driver stack, I'm not sure what exactly to look at. Mostly to check if there were any changes in the DSI register writes, and maybe writes to the MDP5 INTF blocks. One (rather unlikely) possibility I can think of is if somehow the buffers used to send/receive DCS commands aren't mapped/unmapped correctly. There have been some msm_gem changes, and the IOMMU driver is new. That's the main reason why I'm wondering if the contents of the DCS buffers somehow got corrupt. That may well be, but I can't really see what's wrong in that area. Which iommu driver are you referring to, exactly? On 4.9, this driver is used: drivers/iommu/qcom On 4.14 we use: drivers/iommu/qcom_iommu.c Is the panel initialized using DCS commands too? Yes, and that works. The thing is that the commands do in fact reach the panel and cause the desired effect, it's just that as a side effect, the display very likely drops out when a command is sent. The registers that are modified through msm_writel() by and between msm_dsi_host_xfer_prepare() and msm_dsi_host_xfer_restore() are exactly the same though. So it must be that some other part (the GPU or the KMS?) doesn't like the fact that the DSI core mangles with the hardware state in some way. It seems unlikely that sending a DCS command via DSI core would affect MDP or the GPU. It feels like sending the DCS commands is causing the DSI lanes to be temporarily in an invalid state, resulting in the flicker. What hardware are all these changes developed and tested on, btw? I guess it might be worth looking into differences between these platforms and my own. The releases are mostly tested on
Re: [PATCH v2 0/5] allow override of bus format in bridges
Hi Peter,
On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
> On 2018-04-04 14:35, Peter Rosin wrote:
> > On 2018-04-04 11:07, Laurent Pinchart wrote:
> >> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> >>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> > On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> [I got to v2 sooner than expected]
> >>
> >> I have an Atmel sama5d31 hooked up to an lvds encoder and then
> >> on to an lvds panel. Which seems like something that has been
> >> done one or two times before...
> >>
> >> The problem is that the bus_format of the SoC and the panel do
> >> not agree. The SoC driver (atmel-hlcdc) can handle the
> >> rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
> >> wired for the rgb565 case. The lvds encoder supports rgb888 on
> >> its input side with the LSB wires for each color simply pulled
> >> down internally in the encoder in my case which means that the
> >> rgb565 bus_format is the format that works best. And the panel
> >> is expecting lvds (vesa-24), which is what the encoder outputs.
> >>
> >> The reason I "blame" the bus_format of the drm_connector is that
> >> with the below DT snippet, things do not work *exactly* due to
> >> that. At least, it starts to work if I hack the panel-lvds driver
> >> to report the rgb565 bus_format instead of vesa-24.
> >>
> >> panel: panel {
> >> compatible = "panel-lvds";
> >>
> >> width-mm = <304>;
> >> height-mm = <228;
> >>
> >> data-mapping = "vesa-24";
> >>
> >> panel-timing {
> >> // 1024x768 @ 60Hz (typical)
> >> clock-frequency = <5214 6500 7110>;
> >> hactive = <1024>;
> >> vactive = <768>;
> >> hfront-porch = <48 88 88>;
> >> hback-porch = <96 168 168>;
> >> hsync-len = <32 64 64>;
> >> vfront-porch = <8 13 14>;
> >> vback-porch = <8 13 14>;
> >> vsync-len = <8 12 14>;
> >> };
> >>
> >> port {
> >> panel_input: endpoint {
> >> remote-endpoint = <&lvds_encoder_output>;
> >> };
> >> };
> >> };
> >>
> >> lvds-encoder {
> >> compatible = "ti,ds90c185", "lvds-encoder";
> >>
> >> ports {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >>
> >> port@0 {
> >> reg = <0>;
> >>
> >> lvds_encoder_input: endpoint {
> >> remote-endpoint =
> >> <&hlcdc_output>;
> >> };
> >> };
> >>
> >> port@1 {
> >> reg = <1>;
> >>
> >> lvds_encoder_output: endpoint {
> >> remote-endpoint = <&panel_input>;
> >> };
> >> };
> >> };
> >> };
> >>
> >> But, instead of perverting the panel-lvds driver with support
> >> for a totally fake non-lvds bus_format, I intruduce an API that
> >> allows display controller drivers to query the required bus_format of
> >> any intermediate bridges, and match up with that instead of the
> >> formats given by the drm_connector. I trigger this with this addition
> >> to the lvds-encoder DT node:
> >> interface-pix-fmt = "rgb565";
> >>
> >> Naming is hard though, so I'm not sure if that's good?
> >>
> >> I threw in the first patch, since that is the actual lvds encoder
> >> I have in this case.
> >>
> >> Suggestions welcome.
> >
> > Took a quick look, feels rather un-atomic. And there's beend
> > discussing for other bridge related state that we might want to track
> > (like the full adjusted_mode that might need to be adjusted at each
> > stage in the chain). So here's my suggestions:
> >
> > - Add an optional per-bridge internal state struct using the support
> > in https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling->
> > > driver-private-state
> >
[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5
https://bugzilla.kernel.org/show_bug.cgi?id=199101 Sergey Kondakov (virtuous...@gmail.com) changed: What|Removed |Added CC||virtuous...@gmail.com --- Comment #16 from Sergey Kondakov (virtuous...@gmail.com) --- (In reply to Harry Wentland from comment #15) > We reproduced the issue and have someone looking into it. Too bad a fix doesn't seem to be included in 4.16.1. I myself got this on RX 580 (but on old FX-6100 / PCI-e v.2 system), wasn't able to revert commit above and just resorted to disabling DC with amdgpu.dc=0 boot option. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #6 from Jason Playne --- Can Confirm that this problem still persists on Kernel 4.16.1 and Mesa 18 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround
On 9 April 2018 at 11:24, Emil Velikov wrote: > On 9 April 2018 at 09:26, Daniel Vetter wrote: > >>> - point drm_device::dev to the parent of the virtio_device >>> The biggest hack imaginable, if even possible. >> >> What would/could break if we do this? Why is this a hack? > > It _feels_ very hacky to reach/store the parent of the _parent_ device given. > Dummy grep for \ showed hundreds of entries, but many of those > are unrelated. > Will give it a closer look - might not be as bad, as I originally thought. > Here are the side-effects: Semantic changes * using the wrong device for i2c - via drm_dp_add_port * passing the wrong device to framebuffer_alloc - via drm_fb_helper_alloc_fbi * using the wrong parent device to drm_gem_prime_import_dev Visual * printing the wrong device on DRM_DEV_ERROR, dev_info, drm_printer, etc Needs a pdev_to_virtio() since we have the struct virtio_device::struct device::struct device parent - via virtio_gpu_driver_load One, might get away with the above, by introducing drm_device::device bus_device, or alike. That one is used solely for the unique magic :-\ It sounds tad dirty, so I'm leaning with just commenting it. Open to alternative suggestions though. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2
https://bugzilla.kernel.org/show_bug.cgi?id=199319 --- Comment #10 from Mike Lothian (m...@fireburn.co.uk) --- I should add this is 4.16-rc7 (agd5f's 4.18-wip branch) Qt 5.10, KDE frameworks 5.44, Plasma 5.12.4, Xorg 1.19.5 using the modesetting DDX (I'll try the Intel & AMDGPU DDXs tonight. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2
https://bugzilla.kernel.org/show_bug.cgi?id=199319 Mike Lothian (m...@fireburn.co.uk) changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #9 from Mike Lothian (m...@fireburn.co.uk) --- I'm seeing this too, also plasma-wayland but with a PRIME Skylake/Tonga setup only Skylake is used on the desktop -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine
https://bugs.freedesktop.org/show_bug.cgi?id=105950 --- Comment #2 from Bas Vermeulen --- Created attachment 138698 --> https://bugs.freedesktop.org/attachment.cgi?id=138698&action=edit Patch for dispatch_packet endianness fix -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine
https://bugs.freedesktop.org/show_bug.cgi?id=105950 --- Comment #1 from Bas Vermeulen --- Created attachment 138697 --> https://bugs.freedesktop.org/attachment.cgi?id=138697&action=edit Patch for si_vgt_param_key endian fix -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105589] [CI] igt@kms_chamelium@* - fail - Failed assertion: !chamelium->env.fault_occurred - Last errno: 101, Network is unreachable (kms_chamelium:2833) igt_chamelium-CRITICAL: Chamelium RPC cal
https://bugs.freedesktop.org/show_bug.cgi?id=105589 Marta Löfstedt changed: What|Removed |Added Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine
https://bugs.freedesktop.org/show_bug.cgi?id=105950 Bug ID: 105950 Summary: radeonsi: OpenCL not working correctly on a big endian machine Product: Mesa Version: 17.3 Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: b...@daedalean.ai QA Contact: dri-devel@lists.freedesktop.org Running any OpenCL program on a big endian machine using a radeonsi card fails. - union si_vgt_param_key uses a bitfield shared with a 32 bit value. This causes the index to be wrong on a big endian machine, and crashes any OpenCL program with a segfault. - si_setup_user_sgprs_co_v2 in si_compute.c fills a dispatch_packet struct with values which are uploaded to the GPU. To ensure this works correctly, these values need to be converted to little endian. I'll send patches to the mesa-dev list for both these issues. Bas Vermeulen -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround
On 9 April 2018 at 09:26, Daniel Vetter wrote: >> - point drm_device::dev to the parent of the virtio_device >> The biggest hack imaginable, if even possible. > > What would/could break if we do this? Why is this a hack? It _feels_ very hacky to reach/store the parent of the _parent_ device given. Dummy grep for \ showed hundreds of entries, but many of those are unrelated. Will give it a closer look - might not be as bad, as I originally thought. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote: > On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote: > > Same on the mandatory/optional VCC supply thing. Let's try to make > > next version the final one. If the optional property with the dummy > > regulator doesn't satisfy you and it is preferred to have a fixed-regulator > > anyhow in DT I'll do in next version, othewise let's try not to change > > it again. I'll just remark here that in the current Eagle design vcc is > > connected to a power rail with no regulator at all :) > I don't like the dummy regulator much, as it generates a dev_warn(), which > makes me believe that it's a hack rather than a proper solution. You might > want to ask Mark Brown for his opinion. The DT should describe the physical supplies the device needs, if that's a fixed regulator with no software control then the DT should have a fixed regulator with no software control. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation
Hi Daniel, On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote: > On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote: > > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote: > >> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote: > >>> The mode and ajusted_mode passed to the bridge .mode_set() operation > >>> should never be modified by the bridge (and are not in any of the > >>> existing bridge drivers). Make them const to make this clear. > >>> > >>> Signed-off-by: Laurent Pinchart > >> > > >> > >> Why should the adjusted_mode not be modified? > > > > Why should it ? .mode_set() performs a mode set, mode adjustment should be > > performed in .mode_fixup(). > > Oh right, totally missed that you're only touching the ->mode_set > callbacks. Assuming gcc is happy (not going to check for that, too lazy): > > Reviewed-by: Daniel Vetter I've compile-tested this patch for all the drivers it touches and gcc didn't complain. I'll give 0day a few days to give it a go too, just in case. > >>> --- > >>> > >>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++-- > >>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8 > >>> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +- > >>> drivers/gpu/drm/bridge/analogix-anx78xx.c | 4 ++-- > >>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++-- > >>> drivers/gpu/drm/bridge/sii902x.c | 4 ++-- > >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++-- > >>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 16 --- > >>> drivers/gpu/drm/bridge/tc358767.c | 9 + > >>> drivers/gpu/drm/drm_bridge.c | 4 ++-- > >>> drivers/gpu/drm/exynos/exynos_drm_mic.c| 4 ++-- > >>> drivers/gpu/drm/mediatek/mtk_hdmi.c| 4 ++-- > >>> drivers/gpu/drm/msm/dsi/dsi.h | 2 +- > >>> drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- > >>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++-- > >>> drivers/gpu/drm/msm/edp/edp_bridge.c | 4 ++-- > >>> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4 ++-- > >>> drivers/gpu/drm/rcar-du/rcar_lvds.c| 4 ++-- > >>> drivers/gpu/drm/sti/sti_dvo.c | 4 ++-- > >>> drivers/gpu/drm/sti/sti_hda.c | 4 ++-- > >>> drivers/gpu/drm/sti/sti_hdmi.c | 4 ++-- > >>> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +- > >>> include/drm/bridge/dw_mipi_dsi.h | 3 ++- > >>> include/drm/drm_bridge.h | 8 > >>> 24 files changed, 57 insertions(+), 55 deletions(-) > >>> > >>> Philippe, > >>> > >>> I wrote this patch while reviewing your adjusted_mode documentation. I > >>> initially wanted to document the fact that the adjusted_mode argument > >>> to the bridge .mode_set() operation should not be modified by the > >>> bridge, and then realized that constifying it would be a better way to > >>> express that. I thus wouldn't mind if you took that patch in your tree > >>> and pushed it with the documentation patch once we get the necessary > >>> acks :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD graphics performance regression in 4.15 and later
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: Hi Christian, Thanks for the info. FYI, I've also opened a Firefox bug for that at: https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 Feel free to comment since you have a better understanding of what's going on. One last question: right now I'm running 4.15.0 with the "offending" patch reverted. Is that safe to run or are there possible bad interactions with other changes. That should work without problems. But I just had another idea as well, if you want you could still test the new code path which will be using in 4.17. Backporting all the detection logic is to invasive, but you could just go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the other code path. Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those. Regards, Christian. Cheers, Jean-Marc On 04/06/2018 01:20 PM, Christian König wrote: Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin: Hi Christian, On 04/09/2018 07:48 AM, Christian König wrote: Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE. Any reason why echo never > /sys/kernel/mm/transparent_hugepage/enabled doesn't solve the problem? Because we unfortunately try to allocate huge pages anyway, we unfortunately just fail in 100% of all cases. That basically gives you both, the extra allocation overhead and the still bad throughput. Also, I assume that disabling CONFIG_TRANSPARENT_HUGEPAGE will disable them for everything and not just what your patch added, right? Correct, that's why I wrote that disabling SWIOTLBs might be better. I'm not sure what you mean by "We mitigated the problem by avoiding the slow coherent DMA code path on almost all platforms on newer kernels". I tested up to 4.16 and the performance regression is just as bad as it is for 4.15. Indeed 4.16 still doesn't have that. You could use the amd-staging-drm-next branch or wait for 4.17. Is there a way to pull just that change or is there too much interactions with other changes? It adds a new detection if memory allocation needs to be coherent or not, that is not something you can easily pull into older versions. That isn't related to the GFX hardware, but to your CPU/motherboard and whatever else you have in the system. Well, I have an nvidia GPU in the same system (normally only used for CUDA) and if I use it instead of my RX 560 then I'm not seeing any performance issue with 4.15. That's because you are probably using the Nvidia binary driver which has a completely separate code base. Some part of your system needs SWIOTLB and that makes allocating memory much slower. What would that part be? FTR, I have a complete description of my system at https://jmvalin.dreamwidth.org/15583.html I don't know if it's related, but I can maybe see one thing in common between my machine and the Core 2 Quad from the other bug report and that's the "NUMA part". I have a dual-socket Xeon and (AFAIK) the Core 2 Quad is made of two two-core CPUs glued together with little communication between them. Yeah, that is probably the reason. Intel doesn't use TTM because they don't have dedicated VRAM, but the open source nvidia driver should be affected as well. I'm using the proprietary nvidia driver (because CUDA). Is that supposed to be affected as well? No. We already mitigated that problem and I don't see any solution which will arrive faster than 4.17. Is that supposed to make the slowdown unnoticeable or just slightly better? It completely goes away. The issue with the coherent path is that it tries to always allocate the lowest possible memory to make sure that it fits into the DMA constrains of all devices in the system. But since AMD GPU can handle 40bits of addresses you would need at least 1TB of memory in the system to trigger that (or a NUMA where some system is low and some in a high area). Christian. The only quick workaround I can see is to avoid firefox, chrome for example is reported to work perfectly fine. Or use an unaffected GPU/driver ;-) Cheers, Jean-Marc ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2
https://bugzilla.kernel.org/show_bug.cgi?id=199319 --- Comment #8 from m...@rainer-finke.de --- The random flickering every 30 seconds is the same from my point of view. What is different on my setup is that Plasma-Wayland with night shift enabled with a changed color flickers with every mouse movement since Linux 4.16. So the answer is partially. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] sunxi: Add DT representation for the MBUS controller
Hi Rob, On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote: > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard > wrote: > > Hi, > > > > We've had for quite some time to hack around in our drivers to take into > > account the fact that our DMA accesses are not done through the parent > > node, but through another bus with a different mapping than the CPU for the > > RAM (0 instead of 0x4000 for most SoCs). > > > > After some discussion after the submission of a camera device suffering of > > the same hacks, I've decided to put together a serie that introduce a > > property called dma-parent that allows to express the DMA relationship > > between a master and its bus, even if they are not direct parents in the DT. > > Reading thru v6 of the camera driver, it seems like having > intermediate buses would solve the problem in your case? I guess it would yes, but I guess it wouldn't model the hardware properly since this seems to be really a bus only meant to do DMA, and you're not accessing the registers of the device through that bus. And as far as I know, the DT implies that the topology is the one of the "control" side of the devices. We'll also need eventually to have retrieve the MBUS endpoints ID to be able to support perf and PM QoS properly. > As Arnd mentioned in that thread, something new needs to address all > the deficiencies with dma-ranges and describing DMA bus topologies. > This doesn't address the needs of describing bus interconnects. > There's been some efforts by the QCom folks with an interconnect > binding. They've mostly punted (for now at least) to not describing > the whole interconnect in DT and keeping the details in a driver. Is it that patch serie? https://lkml.org/lkml/2018/3/9/856 > On the flip side, this does mirror the established pattern used by > interrupts, so maybe it's okay on it's own. I'll wait for others to > comment. We'll see how it turns out then :) Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation
On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > > should never be modified by the bridge (and are not in any of the
> > > existing bridge drivers). Make them const to make this clear.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> >
> > Why should the adjusted_mode not be modified?
>
> Why should it ? .mode_set() performs a mode set, mode adjustment should be
> performed in .mode_fixup().
Oh right, totally missed that you're only touching the ->mode_set
callbacks. Assuming gcc is happy (not going to check for that, too lazy):
Reviewed-by: Daniel Vetter
>
> >
> > > ---
> > >
> > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 ++--
> > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8
> > > drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 4 ++--
> > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
> > > drivers/gpu/drm/bridge/sii902x.c | 4 ++--
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
> > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 16
> > > drivers/gpu/drm/bridge/tc358767.c | 9 +
> > > drivers/gpu/drm/drm_bridge.c | 4 ++--
> > > drivers/gpu/drm/exynos/exynos_drm_mic.c| 4 ++--
> > > drivers/gpu/drm/mediatek/mtk_hdmi.c| 4 ++--
> > > drivers/gpu/drm/msm/dsi/dsi.h | 2 +-
> > > drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
> > > drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++--
> > > drivers/gpu/drm/msm/edp/edp_bridge.c | 4 ++--
> > > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4 ++--
> > > drivers/gpu/drm/rcar-du/rcar_lvds.c| 4 ++--
> > > drivers/gpu/drm/sti/sti_dvo.c | 4 ++--
> > > drivers/gpu/drm/sti/sti_hda.c | 4 ++--
> > > drivers/gpu/drm/sti/sti_hdmi.c | 4 ++--
> > > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +-
> > > include/drm/bridge/dw_mipi_dsi.h | 3 ++-
> > > include/drm/drm_bridge.h | 8
> > > 24 files changed, 57 insertions(+), 55 deletions(-)
> > >
> > > Philippe,
> > >
> > > I wrote this patch while reviewing your adjusted_mode documentation. I
> > > initially wanted to document the fact that the adjusted_mode argument to
> > > the bridge .mode_set() operation should not be modified by the bridge,
> > > and then realized that constifying it would be a better way to express
> > > that. I thus wouldn't mind if you took that patch in your tree and
> > > pushed it with the documentation patch once we get the necessary acks
> > >
> > > :-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index
> > > d034b2cb5eee..f60d29defd18 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > @@ -389,7 +389,7 @@ static inline int adv7511_cec_init(struct device *dev,
> > > struct adv7511 *adv7511)>
> > > #ifdef CONFIG_DRM_I2C_ADV7533
> > > void adv7533_dsi_power_on(struct adv7511 *adv);
> > > void adv7533_dsi_power_off(struct adv7511 *adv);
> > >
> > > -void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode
> > > *mode);
> > > +void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> > > *mode);>
> > > int adv7533_patch_registers(struct adv7511 *adv);
> > > int adv7533_patch_cec_registers(struct adv7511 *adv);
> > > int adv7533_attach_dsi(struct adv7511 *adv);
> > >
> > > @@ -405,7 +405,7 @@ static inline void adv7533_dsi_power_off(struct
> > > adv7511 *adv)>
> > > }
> > >
> > > static inline void adv7533_mode_set(struct adv7511 *adv,
> > >
> > > - struct drm_display_mode *mode)
> > > + const struct drm_display_mode *mode)
> > >
> > > {
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index
> > > efa29db5fc2b..99028d36ed74 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > @@ -664,8 +664,8 @@ static int adv7511_mode_valid(struct adv7511 *adv7511,
> > >
> > > }
> > >
> > > static void adv7511_mode_set(struct adv7511 *adv7511,
> > >
> > > - struct drm_display_mode *mode,
> > > - struct drm_display_mode *adj_mode)
> > > + const struct drm_display_mode *mode,
> > > + const struct drm_display_mode *adj_mo
Re: DRM_UDL and GPU under Xserver
On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote: > Hi Daniel, > > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote: > > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote: > > > Hi Daniel, all, > > [snip] > > > > Ok it was quite some time ago so I forgot about that completely. > > > I really made one trivial change in xf86-video-armada: > > > >8-- > > > --- a/src/armada_module.c > > > +++ b/src/armada_module.c > > > @@ -26,7 +26,7 @@ > > > #define ARMADA_NAME"armada" > > > #define ARMADA_DRIVER_NAME "armada" > > > > > > -#define DRM_MODULE_NAMES "armada-drm", "imx-drm" > > > +#define DRM_MODULE_NAMES "armada-drm", "imx-drm", "udl" > > > #define DRM_DEFAULT_BUS_ID NULL > > > >8-- > > > > > > Otherwise Xserver fails on start which is expected given "imx-drm" is > > > intentionally removed. > > Here I meant I explicitly disabled DRM_IMX in the kernel configuraion > so that it is not used in run-time. > > > You need to keep imx-drm around. And then light up the udl display using > > prime. Afaiui it should all just work (but with maybe a few disconnected > > outputs from imx-drm around that you don't need, but that's not a > > problem). > > And given my comment above I don't really see any difference between > DRM_IMX and DRM_UDL (except their HW implmentation which I guess should > not bother upper layers) so why do wee need to treat them differently? > > Most probably I'm missing something but my thought was if we have > 2 equally well supported KMS devices we may easily swap them and still > have resulting setup functional. armada is not a generic drm driver, but can only be used for armada-drm and imx-drm. You can't just use it with any drm device, for that you need a generic driver like -modesetting. Just enable all the drivers you have for your hw, and it should work. Hacking on drivers without knowing what they expect tends to not work so well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
