Re: PCIe coherency in spec (was: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available)
在 2024-07-03星期三的 23:11 -0700，Christoph Hellwig写道： > On Thu, Jul 04, 2024 at 10:00:52AM +0800, Icenowy Zheng wrote: > > So I here want to ask a question as an individual hacker: what's > > the > > policy of linux-pci towards these non-coherent PCIe > > implementations? > > > > If the sentences of Christian is right, these implementations are > > just > > out-of-spec, should them get purged out of the kernel, or at least > > raising a warning that some HW won't work because of inconformant > > implementation? > > Nothing in the PCIe specifications that mandates a programming model. > Non-coherent DMA is extremely common in lower end devices, and > despite > all the issues that it causes well supported in Linux. > > What are you trying to solve? Currently the DRM TTM subsystem (and GPU drivers using it) will assume coherency and fail on these non-coherent systems with cryptic error messages (like `[drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring gfx test failed (-110)`) without mentioning coherency issues at all. My original patchset tries to solve this problem by make the TTM subsystem sensible of coherency status (and prevent CPU-side cached mapping when non-coherent), but got argued by TTM maintainer and the maintainer says TTM's ignorance on non-coherent systems is intentional. >
Re: PCIe coherency in spec (was: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available)
在 2024-07-03星期三的 16:08 -0500，Bjorn Helgaas写道： > On Wed, Jul 03, 2024 at 04:52:30PM +0800, Jiaxun Yang wrote: > > 在2024年7月2日七月 下午6:03，Jiaxun Yang写道： > > > 在2024年7月2日七月 下午5:27，Christian König写道： > > > > Am 02.07.24 um 11:06 schrieb Icenowy Zheng: > > > > > [SNIP] However I don't think the definition of the AGP spec > > > > > could apply on all > > > > > PCI(e) implementations. The AGP spec itself don't apply on > > > > > implementations that do not implement AGP (which is the most > > > > > PCI(e) > > > > > implementations today), and it's not in the reference list of > > > > > the PCIe > > > > > spec, so it does no help on this context. > > > > No, exactly that is not correct. > > > > > > > > See as I explained the No-Snoop extension to PCIe was created > > > > to help > > > > with AGP support and later merged into the base PCIe > > > > specification. > > > > > > > > So the AGP spec is now part of the PCIe spec. > > > > Hi Bjorn & linux-pci folks, > > > > It seems like we have some disputes on interpretation pf PCIe > > specification. > > > > We are seeking your expertise on the question: Does PCIe > > specification mandate Cache coherency via snoop? > > I'm not qualified to opine on this. I'd say it's a question for the > PCI SIG protocol workgroup. https://forum.pcisig.com/ is a place to > start. Sorry for the disturbance. As individual hacker, I am not eligble of being a PCI-SIG member and join the discussion there. So I here want to ask a question as an individual hacker: what's the policy of linux-pci towards these non-coherent PCIe implementations? If the sentences of Christian is right, these implementations are just out-of-spec, should them get purged out of the kernel, or at least raising a warning that some HW won't work because of inconformant implementation? > > Bjorn
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
在 2024-07-02星期二的 11:27 +0200，Christian König写道： > Am 02.07.24 um 11:06 schrieb Icenowy Zheng: > > [SNIP] > > However I don't think the definition of the AGP spec could apply on > > all > > PCI(e) implementations. The AGP spec itself don't apply on > > implementations that do not implement AGP (which is the most PCI(e) > > implementations today), and it's not in the reference list of the > > PCIe > > spec, so it does no help on this context. > > No, exactly that is not correct. > > See as I explained the No-Snoop extension to PCIe was created to help > with AGP support and later merged into the base PCIe specification. > > So the AGP spec is now part of the PCIe spec. > [SNIP] I don't think AGP spec is part of the PCIe spec, at least not part of the PCIe spec I was reading. It does not contain the word "AGP" at all, and despite it has a "Reference Documents" chapter, this chapter didn't include the AGP spec, unlike PCI spec / PCI-X addendum which are listed there. In addition, your logic that No-Snoop is related to AGP only apply when discussing about the history of PCIe, not when inspecting it from a synchronic view, which is what new implementers of a spec should do. > > > We have quite a bunch of V4L, sound and I also think network > > > devices > > > which work like that. But those are non-PCI devices. > > I think in the Linux kernel most drivers (of course including PCI > > ones) > > use DMA buffer in this way, which makes them natually compatible > > with > > non-coherent PCIe implementations. TTM is one of the few exceptions > > here. > > Yes and that is absolutely intentional. > > See we don't want to support any non-coherent PCIe implementation. > However, considering users exist for this setup, I here seriously hope the support to be gained since today. > [SNIP] > > > And if I'm not completely mistaken the RISC-V specification was > > > also > > > updated to disallow stuff like this. > > > > > > So yes you can have boards which implement non-snooped PCIe, but > > > you > > > get > > > exactly zero support from hardware vendors to run software on it. > > > > > It's a quite usual case for free softwares to get no support from > > hardware vendors, and some of them are even developed by reverse > > engineering. I don't think it as a blocker for the Linux kernel to > > merge as many hardwares' support as possible. > > We seem to have a misunderstanding here, this is not a software > issue. > The hardware platform is considered broken by the hardware vendor! I don't think in this case Arm Ltd / RISC-V International is considered the vendor -- the SoC vendor is. You can rarely get support directly from the CPU ISA vendor (or CPU IP vendor, which differs mostly in the RISC-V situation) in the case a SoC or a final product with some SoC is purchased, and the SoC/product's vendor would rarely declare their hardware platform as broken. > > In other words people have stitched together hardware in a way which > is > not supported by the creator of that hardware. > > So as long as you can't convince anybody from ARM or the RISC-V team > or > whoever created that hardware to confirm that the hardware actually > works you won't get any support for that. The world isn't black-or-white, and the thing contradictory to "confirmed working" is "not confirmed working" instead of "confirmed not working". To get the thing really working (or prove it doesn't work at all by practice) is part of the traditional fun of a hacker. > > Regards, > Christian.
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
在 2024-07-02星期二的 10:10 +0200，Christian König写道： > Am 02.07.24 um 10:08 schrieb Christian König: > > Am 02.07.24 um 03:46 schrieb Icenowy Zheng: > > > 在 2024-07-01星期一的 13:40 +0200，Christian König写道： > > > > Am 29.06.24 um 22:51 schrieb Icenowy Zheng: > > > > > 于 2024年6月30日 GMT+08:00 03:57:47，Jiaxun Yang > > > > > 写道： > > > > > > 在2024年6月29日六月 上午6:22，Icenowy Zheng写道： > > > > > > [...] > > > > > > > @@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct > > > > > > > ttm_buffer_object *bo, > > > > > > > struct ttm_resource *res, > > > > > > > caching = res->bus.caching; > > > > > > > } > > > > > > > > > > > > > > + /* Downgrade cached mapping for non-snooping > > > > > > > devices */ > > > > > > > + if (!bo->bdev->dma_coherent && caching == > > > > > > > ttm_cached) > > > > > > > + caching = ttm_write_combined; > > > > > > Hi Icenowy, > > > > > > > > > > > > Thanks for your patch! You saved many non-coh PCIe host > > > > > > implementations a day!. > > > > Ah, wait a second. > > > > > > > > Such a thing as non-coherent PCIe implementation doesn't exist. > > > > The > > > > PCIe > > > > specification makes it mandatory for memory access to be cache > > > > coherent. > > > Really? I tried to get PCIe spec 2.0, PCI spec 3.0 and PCI-X > > > addendum > > > 1.0, none of this explicitly requires the PCIe controller and the > > > CPU > > > being fully coherent. The PCI-X spec even says "Note that PCI-X, > > > like > > > conventional PCI, does not require systems to support coherent > > > caches > > > for addresses accessed by PCI-X requesters". > > > > See the very first PCI specification, AGP 2.0 and the PCIe > > extension > > for non-snooped access. > > > > Originally it wasn't well defined what the PCI 1.0 spec meant with > > coherency (e.g. snooping vs uncached). > > > > AGP was the first specification which explicitly defined that all > > AGP > > memory accesses must be non-snooped and all PCI accesses must snoop > > the CPU caches. > > > > PCIe then had an extension which defined the "No Snooping > > Attribute" > > to allow emulating the AGP behavior. > > > > For the current PCIe 6.1 specification the non-snoop extension was > > merged into the base specification. > > > > Here see section "2.2.6.5 No Snoop Attribute", e.g. "Hardware > > enforced > > cache coherency expected" > > > > As well as the notes under section 7.5.3.4 Device Control Register: > > > > Enable No Snoop - If this bit is Set, the Function is permitted to > > Set > > the No Snoop bit in the Requester > > Attributes of transactions it initiates that do not require > > hardware > > enforced cache coherency (see Section 2.2.6.5 ). > > > > To summarize it: Not snooping caches is an extension, snooping > > caches > > is mandatory. > > > > > In addition, in the perspective of Linux, I think bypassing CPU > > > cache > > > of shared memory is considered as coherent access too, see > > > dma_alloc_coherent() function's naming. > > > > Yes that's correct, but this is for platform devices. E.g. other > > I/O > > from drivers who doesn't need to work with malloced system memory > > for > > example. > > > > We have quite a bunch of V4L, sound and I also think network > > devices > > which work like that. But those are non-PCI devices. > > > > > > There are a bunch of non-compliant PCIe implementations which > > > > have > > > > broken cache coherency, but those explicitly violate the > > > > specification > > > > and because of that are not supported. > > > Regardless of it violating the spec or not, these devices work > > > with > > > Linux subsystems that use dma_alloc_coherent to allocate DMA > > > buffers > > > (which is the most common case), and GPU drivers just give out > > > cryptic > > > error messages like "ring gfx test failed" without any mention of > > > coherency issues at all, which makes th
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
在 2024-07-02星期二的 10:08 +0200，Christian König写道： > Am 02.07.24 um 03:46 schrieb Icenowy Zheng: > > 在 2024-07-01星期一的 13:40 +0200，Christian König写道： > > > Am 29.06.24 um 22:51 schrieb Icenowy Zheng: > > > > 于 2024年6月30日 GMT+08:00 03:57:47，Jiaxun Yang > > > > 写道： > > > > > 在2024年6月29日六月 上午6:22，Icenowy Zheng写道： > > > > > [...] > > > > > > @@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct > > > > > > ttm_buffer_object *bo, > > > > > > struct ttm_resource *res, > > > > > > caching = res->bus.caching; > > > > > > } > > > > > > > > > > > > + /* Downgrade cached mapping for non-snooping > > > > > > devices */ > > > > > > + if (!bo->bdev->dma_coherent && caching == > > > > > > ttm_cached) > > > > > > + caching = ttm_write_combined; > > > > > Hi Icenowy, > > > > > > > > > > Thanks for your patch! You saved many non-coh PCIe host > > > > > implementations a day!. > > > Ah, wait a second. > > > > > > Such a thing as non-coherent PCIe implementation doesn't exist. > > > The > > > PCIe > > > specification makes it mandatory for memory access to be cache > > > coherent. > > Really? I tried to get PCIe spec 2.0, PCI spec 3.0 and PCI-X > > addendum > > 1.0, none of this explicitly requires the PCIe controller and the > > CPU > > being fully coherent. The PCI-X spec even says "Note that PCI-X, > > like > > conventional PCI, does not require systems to support coherent > > caches > > for addresses accessed by PCI-X requesters". > > See the very first PCI specification, AGP 2.0 and the PCIe extension > for > non-snooped access. > > Originally it wasn't well defined what the PCI 1.0 spec meant with > coherency (e.g. snooping vs uncached). > I think the word in PCI-X addendum could be understood as kind of clarification, which makes at least PCI-X (and maybe retrospectively PCI) coherency optional. > AGP was the first specification which explicitly defined that all AGP > memory accesses must be non-snooped and all PCI accesses must snoop > the > CPU caches. However I don't think the definition of the AGP spec could apply on all PCI(e) implementations. The AGP spec itself don't apply on implementations that do not implement AGP (which is the most PCI(e) implementations today), and it's not in the reference list of the PCIe spec, so it does no help on this context. > > PCIe then had an extension which defined the "No Snooping Attribute" > to > allow emulating the AGP behavior. > > For the current PCIe 6.1 specification the non-snoop extension was > merged into the base specification. > > Here see section "2.2.6.5 No Snoop Attribute", e.g. "Hardware > enforced > cache coherency expected" > > As well as the notes under section 7.5.3.4 Device Control Register: > > Enable No Snoop - If this bit is Set, the Function is permitted to > Set > the No Snoop bit in the Requester > Attributes of transactions it initiates that do not require hardware > enforced cache coherency (see Section 2.2.6.5 ). > > To summarize it: Not snooping caches is an extension, snooping caches > is > mandatory. I don't get any such new PCIe specifications, but in Section 2.2.6.3 of PCIe specification 2.0, it declares these attribute bits as "hints" "Level of support is dependent on target applications", and suggests to refer to PCI-X 2.0 (which is the document that I referenced the sentence originally from). This makes it reasonable that No-Snoop bit is only meaningful in a coherent implementation, and it becomes just no-op for non-coherent implementations. If PCIe specification really requires coherent access by default, this should be mentioned in other parts of the spec, instead of only get referred by the No-Snoop bit definition. > > > In addition, in the perspective of Linux, I think bypassing CPU > > cache > > of shared memory is considered as coherent access too, see > > dma_alloc_coherent() function's naming. > > Yes that's correct, but this is for platform devices. E.g. other I/O > from drivers who doesn't need to work with malloced system memory for > example. > > We have quite a bunch of V4L, sound and I also think network devices > which work like that. But those are non-PCI devices. I think in the Linux kernel most drivers (of course including PCI ones) use DMA buffer in this way, which makes them
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
在 2024-07-01星期一的 13:40 +0200，Christian König写道：
> Am 29.06.24 um 22:51 schrieb Icenowy Zheng:
> >
> > 于 2024年6月30日 GMT+08:00 03:57:47，Jiaxun Yang
> > 写道：
> > >
> > > 在2024年6月29日六月 上午6:22，Icenowy Zheng写道：
> > > [...]
> > > > @@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct
> > > > ttm_buffer_object *bo,
> > > > struct ttm_resource *res,
> > > > caching = res->bus.caching;
> > > > }
> > > >
> > > > + /* Downgrade cached mapping for non-snooping devices */
> > > > + if (!bo->bdev->dma_coherent && caching == ttm_cached)
> > > > + caching = ttm_write_combined;
> > > Hi Icenowy,
> > >
> > > Thanks for your patch! You saved many non-coh PCIe host
> > > implementations a day!.
>
> Ah, wait a second.
>
> Such a thing as non-coherent PCIe implementation doesn't exist. The
> PCIe
> specification makes it mandatory for memory access to be cache
> coherent.
Really? I tried to get PCIe spec 2.0, PCI spec 3.0 and PCI-X addendum
1.0, none of this explicitly requires the PCIe controller and the CPU
being fully coherent. The PCI-X spec even says "Note that PCI-X, like
conventional PCI, does not require systems to support coherent caches
for addresses accessed by PCI-X requesters".
In addition, in the perspective of Linux, I think bypassing CPU cache
of shared memory is considered as coherent access too, see
dma_alloc_coherent() function's naming.
>
> There are a bunch of non-compliant PCIe implementations which have
> broken cache coherency, but those explicitly violate the
> specification
> and because of that are not supported.
Regardless of it violating the spec or not, these devices work with
Linux subsystems that use dma_alloc_coherent to allocate DMA buffers
(which is the most common case), and GPU drivers just give out cryptic
error messages like "ring gfx test failed" without any mention of
coherency issues at all, which makes the fact that Linux DRM/TTM
subsystem currently requires PCIe snooping CPU cache more obscure.
>
> Regards,
> Christian.
>
> > >
> > > Unfortunately I don't think we can safely ttm_cached to
> > > ttm_write_comnined, we've
> > > had enough drama with write combine behaviour on all different
> > > platforms.
> > >
> > > See drm_arch_can_wc_memory in drm_cache.h.
> > >
> > Yes this really sounds like an issue.
> >
> > Maybe the behavior of ttm_write_combined should furtherly be
> > decided
> > by drm_arch_can_wc_memory() in case of quirks?
> >
> > > Thanks
> > >
> > > > +
> > > > return ttm_prot_from_caching(caching, tmp);
> > > > }
> > > > EXPORT_SYMBOL(ttm_io_prot);
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c
> > > > b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > index 7b00ddf0ce49f..3335df45fba5e 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > > > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > @@ -152,6 +152,10 @@ static void ttm_tt_init_fields(struct
> > > > ttm_tt *ttm,
> > > > enum ttm_caching caching,
> > > > unsigned long extra_pages)
> > > > {
> > > > + /* Downgrade cached mapping for non-snooping devices */
> > > > + if (!bo->bdev->dma_coherent && caching == ttm_cached)
> > > > + caching = ttm_write_combined;
> > > > +
> > > > ttm->num_pages = (PAGE_ALIGN(bo->base.size) >>
> > > > PAGE_SHIFT) + extra_pages;
> > > > ttm->page_flags = page_flags;
> > > > ttm->dma_address = NULL;
> > > > diff --git a/include/drm/ttm/ttm_caching.h
> > > > b/include/drm/ttm/ttm_caching.h
> > > > index a18f43e93abab..f92d7911f50e4 100644
> > > > --- a/include/drm/ttm/ttm_caching.h
> > > > +++ b/include/drm/ttm/ttm_caching.h
> > > > @@ -47,7 +47,8 @@ enum ttm_caching {
> > > >
> > > > /**
> > > > * @ttm_cached: Fully cached like normal system memory,
> > > > requires that
> > > > - * devices snoop the CPU cache on accesses.
> > > > + * devices snoop the CPU cache on accesses. Downgraded
> > > > to
> > > > + * ttm_write_combined when the snooping capaiblity is
> > > > missing.
> > > > */
> > > > ttm_cached
> > > > };
> > > > --
> > > > 2.45.2
>
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
在 2024-06-29星期六的 20:57 +0100，Jiaxun Yang写道：
>
>
> 在2024年6月29日六月 上午6:22，Icenowy Zheng写道：
> [...]
> > @@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object
> > *bo,
> > struct ttm_resource *res,
> > caching = res->bus.caching;
> > }
> >
> > + /* Downgrade cached mapping for non-snooping devices */
> > + if (!bo->bdev->dma_coherent && caching == ttm_cached)
> > + caching = ttm_write_combined;
> Hi Icenowy,
>
> Thanks for your patch! You saved many non-coh PCIe host
> implementations a day!.
>
> Unfortunately I don't think we can safely ttm_cached to
> ttm_write_comnined, we've
> had enough drama with write combine behaviour on all different
> platforms.
I think on these platforms, ttm_write_combined should be prevented to
be mapped to pgprot_writecombine instead, but downgrade ttm_cached to
ttm_write_combined (and then being treated same as ttm_uncached) is
acceptable.
>
> See drm_arch_can_wc_memory in drm_cache.h.
>
> Thanks
>
> > +
> > return ttm_prot_from_caching(caching, tmp);
> > }
> > EXPORT_SYMBOL(ttm_io_prot);
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c
> > b/drivers/gpu/drm/ttm/ttm_tt.c
> > index 7b00ddf0ce49f..3335df45fba5e 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -152,6 +152,10 @@ static void ttm_tt_init_fields(struct ttm_tt
> > *ttm,
> > enum ttm_caching caching,
> > unsigned long extra_pages)
> > {
> > + /* Downgrade cached mapping for non-snooping devices */
> > + if (!bo->bdev->dma_coherent && caching == ttm_cached)
> > + caching = ttm_write_combined;
> > +
> > ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT)
> > + extra_pages;
> > ttm->page_flags = page_flags;
> > ttm->dma_address = NULL;
> > diff --git a/include/drm/ttm/ttm_caching.h
> > b/include/drm/ttm/ttm_caching.h
> > index a18f43e93abab..f92d7911f50e4 100644
> > --- a/include/drm/ttm/ttm_caching.h
> > +++ b/include/drm/ttm/ttm_caching.h
> > @@ -47,7 +47,8 @@ enum ttm_caching {
> >
> > /**
> > * @ttm_cached: Fully cached like normal system memory,
> > requires that
> > - * devices snoop the CPU cache on accesses.
> > + * devices snoop the CPU cache on accesses. Downgraded to
> > + * ttm_write_combined when the snooping capaiblity is
> > missing.
> > */
> > ttm_cached
> > };
> > --
> > 2.45.2
>
Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
于 2024年6月30日 GMT+08:00 03:57:47，Jiaxun Yang 写道：
>
>
>在2024年6月29日六月 上午6:22，Icenowy Zheng写道：
>[...]
>> @@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo,
>> struct ttm_resource *res,
>> caching = res->bus.caching;
>> }
>>
>> +/* Downgrade cached mapping for non-snooping devices */
>> +if (!bo->bdev->dma_coherent && caching == ttm_cached)
>> +caching = ttm_write_combined;
>Hi Icenowy,
>
>Thanks for your patch! You saved many non-coh PCIe host implementations a day!.
>
>Unfortunately I don't think we can safely ttm_cached to ttm_write_comnined,
>we've
>had enough drama with write combine behaviour on all different platforms.
>
>See drm_arch_can_wc_memory in drm_cache.h.
>
Yes this really sounds like an issue.
Maybe the behavior of ttm_write_combined should furtherly be decided
by drm_arch_can_wc_memory() in case of quirks?
>Thanks
>
>> +
>> return ttm_prot_from_caching(caching, tmp);
>> }
>> EXPORT_SYMBOL(ttm_io_prot);
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>> index 7b00ddf0ce49f..3335df45fba5e 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -152,6 +152,10 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
>> enum ttm_caching caching,
>> unsigned long extra_pages)
>> {
>> +/* Downgrade cached mapping for non-snooping devices */
>> +if (!bo->bdev->dma_coherent && caching == ttm_cached)
>> +caching = ttm_write_combined;
>> +
>> ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
>> extra_pages;
>> ttm->page_flags = page_flags;
>> ttm->dma_address = NULL;
>> diff --git a/include/drm/ttm/ttm_caching.h b/include/drm/ttm/ttm_caching.h
>> index a18f43e93abab..f92d7911f50e4 100644
>> --- a/include/drm/ttm/ttm_caching.h
>> +++ b/include/drm/ttm/ttm_caching.h
>> @@ -47,7 +47,8 @@ enum ttm_caching {
>>
>> /**
>> * @ttm_cached: Fully cached like normal system memory, requires that
>> - * devices snoop the CPU cache on accesses.
>> + * devices snoop the CPU cache on accesses. Downgraded to
>> + * ttm_write_combined when the snooping capaiblity is missing.
>> */
>> ttm_cached
>> };
>> --
>> 2.45.2
>
[RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
As we can now acquire the presence of the full DMA coherency (snooping
capability) from ttm_device, we can now map the CPU side memory as
write-combined when cached is requested and snooping is not avilable.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
drivers/gpu/drm/ttm/ttm_tt.c | 4
include/drm/ttm/ttm_caching.h | 3 ++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 0b3f4267130c4..6519ce047787d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -302,6 +302,10 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct
ttm_resource *res,
caching = res->bus.caching;
}
+ /* Downgrade cached mapping for non-snooping devices */
+ if (!bo->bdev->dma_coherent && caching == ttm_cached)
+ caching = ttm_write_combined;
+
return ttm_prot_from_caching(caching, tmp);
}
EXPORT_SYMBOL(ttm_io_prot);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 7b00ddf0ce49f..3335df45fba5e 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -152,6 +152,10 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
enum ttm_caching caching,
unsigned long extra_pages)
{
+ /* Downgrade cached mapping for non-snooping devices */
+ if (!bo->bdev->dma_coherent && caching == ttm_cached)
+ caching = ttm_write_combined;
+
ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
extra_pages;
ttm->page_flags = page_flags;
ttm->dma_address = NULL;
diff --git a/include/drm/ttm/ttm_caching.h b/include/drm/ttm/ttm_caching.h
index a18f43e93abab..f92d7911f50e4 100644
--- a/include/drm/ttm/ttm_caching.h
+++ b/include/drm/ttm/ttm_caching.h
@@ -47,7 +47,8 @@ enum ttm_caching {
/**
* @ttm_cached: Fully cached like normal system memory, requires that
-* devices snoop the CPU cache on accesses.
+* devices snoop the CPU cache on accesses. Downgraded to
+* ttm_write_combined when the snooping capaiblity is missing.
*/
ttm_cached
};
--
2.45.2
[RFC PATCH 1/2] drm/ttm: save the device's DMA coherency status in ttm_device
Currently TTM utilizes cached memory regardless of whether the device
have full DMA coherency (can snoop CPU cache).
Save the device's DMA coherency status in struct ttm_device, to allow
further support of devices w/o snooping capability (the capability
missing on at least one part of the transmission between the CPU and the
device).
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/ttm/ttm_device.c | 2 ++
include/drm/ttm/ttm_device.h | 5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 434cf0258000e..b923c14861c1a 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -237,6 +237,8 @@ int ttm_device_init(struct ttm_device *bdev, const struct
ttm_device_funcs *func
list_add_tail(>device_list, >device_list);
mutex_unlock(_global_mutex);
+ bdev->dma_coherent = dev->dma_coherent;
+
return 0;
}
EXPORT_SYMBOL(ttm_device_init);
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index c22f30535c848..9daf7f47d6507 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -225,6 +225,11 @@ struct ttm_device {
*/
const struct ttm_device_funcs *funcs;
+ /**
+* @dma_coherent: if the device backed is dma-coherent.
+*/
+ bool dma_coherent;
+
/**
* @sysman: Resource manager for the system domain.
* Access via ttm_manager_type.
--
2.45.2
[RFC PATCH 0/2] drm/ttm: support device w/o coherency
This patchset tries to make TTM support devices w/o full DMA coherency capability (usually due to part of the link between the device and the CPU, esp. PCIe controller, do not have full coherency). The patchset itself looks quite straightforward, however I don't know why this isn't included in the kernel in years, so make it a RFC. Tested on Rockchip RK3566, which has a PCIe controller w/o full coherency with an AMD OLAND GPU (R7 240). Mainly radeon driver is tested, but amdgpu driver is tried and at least OpenGL (glmark2) works. (The board used for testing is a Quartz64, which has a PCIe slot that can directly be seated with a PCIe graphics card) Icenowy Zheng (2): drm/ttm: save the device's DMA coherency status in ttm_device drm/ttm: downgrade cached to write_combined when snooping not available drivers/gpu/drm/ttm/ttm_bo_util.c | 4 drivers/gpu/drm/ttm/ttm_device.c | 2 ++ drivers/gpu/drm/ttm/ttm_tt.c | 4 include/drm/ttm/ttm_caching.h | 3 ++- include/drm/ttm/ttm_device.h | 5 + 5 files changed, 17 insertions(+), 1 deletion(-) -- 2.45.2
Re: [etnaviv-next v14 0/8] drm/etnaviv: Add driver wrapper for vivante GPUs attached on PCI(e) device
在 2024-06-25星期二的 14:01 +0200，Lucas Stach写道： > Am Dienstag, dem 25.06.2024 um 11:18 +0800 schrieb Icenowy Zheng: > > 在 2024-05-20星期一的 00:53 +0800，Sui Jingfeng写道： > > > drm/etnaviv use the component framework to bind multiple GPU > > > cores to > > > a > > > virtual master, the virtual master is manually create during > > > driver > > > load > > > time. This works well for various SoCs, yet there are some PCIe > > > card > > > has > > > the vivante GPU cores integrated. The driver lacks the support > > > for > > > PCIe > > > devices currently. > > > > > > Adds PCIe driver wrapper on the top of what drm/etnaviv already > > > has, > > > the > > > component framework is still being used to bind subdevices, even > > > though > > > there is only one GPU core. But the process is going to be > > > reversed, > > > we > > > create virtual platform device for each of the vivante GPU IP > > > core > > > shipped > > > by the PCIe master. The PCIe master is real, bind all the virtual > > > child > > > to the master with component framework. > > > > > > > > > v6: > > > * Fix build issue on system without CONFIG_PCI enabled > > > v7: > > > * Add a separate patch for the platform driver > > > rearrangement > > > (Bjorn) > > > * Switch to runtime check if the GPU is dma coherent or > > > not > > > (Lucas) > > > * Add ETNAVIV_PARAM_GPU_COHERENT to allow userspace to > > > query > > > (Lucas) > > > * Remove etnaviv_gpu.no_clk member (Lucas) > > > * Fix Various typos and coding style fixed (Bjorn) > > > v8: > > > * Fix typos and remove unnecessary header included > > > (Bjorn). > > > * Add a dedicated function to create the virtual master > > > platform > > > device. > > > v9: > > > * Use PCI_VDEVICE() macro (Bjorn) > > > * Add trivial stubs for the PCI driver (Bjorn) > > > * Remove a redundant dev_err() usage (Bjorn) > > > * Clean up etnaviv_pdev_probe() with > > > etnaviv_of_first_available_node() > > > v10: > > > * Add one more cleanup patch > > > * Resolve the conflict with a patch from Rob > > > * Make the dummy PCI stub inlined > > > * Print only if the platform is dma-coherrent > > > V11: > > > * Drop unnecessary changes (Lucas) > > > * Tweak according to other reviews of v10. > > > > > > V12: > > > * Create a virtual platform device for the subcomponent > > > GPU > > > cores > > > * Bind all subordinate GPU cores to the real PCI master > > > via > > > component. > > > > > > V13: > > > * Drop the non-component code path, always use the > > > component > > > framework > > > to bind subcomponent GPU core. Even though there is > > > only > > > one core. > > > * Defer the irq handler register. > > > * Rebase and improve the commit message > > > > > > V14: > > > * Rebase onto etnaviv-next and improve commit message. > > > > > > Tested with JD9230P GPU and LingJiu GP102 GPU. > > > > BTW how should VRAM and displayed related parts be handled on these > > dGPUs? > > > The only way to handle VRAM properly would be to rewrite our GEM > internals using TTM. I suggest for these kind of dGPU to create a brand new driver instead. BTW, Jingfeng, what's the situation of the Loongson 7A1000 GPU? Do it share the same address space with the CPU? (The display of 7A is another virtual PCI device that is already handled in loongson-drm driver and don't need to be worried) > > Regards, > Lucas > > > > > > > Sui Jingfeng (8): > > > drm/etnaviv: Add a dedicated helper function to get various > > > clocks > > > drm/etnaviv: Add constructor and destructor for the > > > etnaviv_drm_private structure > > > drm/etnaviv: Embed struct drm_device into struct > > > etnaviv_drm_private > > > drm/etnaviv: Fix wrong cache property being used for vmap() > > > drm/etnaviv: Add support for cached coherent caching mode > > > drm/etnaviv: Replace the '>dev' with 'dev' > > > drm/etnaviv
Re: [etnaviv-next v14 0/8] drm/etnaviv: Add driver wrapper for vivante GPUs attached on PCI(e) device
在 2024-05-20星期一的 00:53 +0800，Sui Jingfeng写道： > drm/etnaviv use the component framework to bind multiple GPU cores to > a > virtual master, the virtual master is manually create during driver > load > time. This works well for various SoCs, yet there are some PCIe card > has > the vivante GPU cores integrated. The driver lacks the support for > PCIe > devices currently. > > Adds PCIe driver wrapper on the top of what drm/etnaviv already has, > the > component framework is still being used to bind subdevices, even > though > there is only one GPU core. But the process is going to be reversed, > we > create virtual platform device for each of the vivante GPU IP core > shipped > by the PCIe master. The PCIe master is real, bind all the virtual > child > to the master with component framework. > > > v6: > * Fix build issue on system without CONFIG_PCI enabled > v7: > * Add a separate patch for the platform driver rearrangement > (Bjorn) > * Switch to runtime check if the GPU is dma coherent or not > (Lucas) > * Add ETNAVIV_PARAM_GPU_COHERENT to allow userspace to query > (Lucas) > * Remove etnaviv_gpu.no_clk member (Lucas) > * Fix Various typos and coding style fixed (Bjorn) > v8: > * Fix typos and remove unnecessary header included (Bjorn). > * Add a dedicated function to create the virtual master > platform > device. > v9: > * Use PCI_VDEVICE() macro (Bjorn) > * Add trivial stubs for the PCI driver (Bjorn) > * Remove a redundant dev_err() usage (Bjorn) > * Clean up etnaviv_pdev_probe() with > etnaviv_of_first_available_node() > v10: > * Add one more cleanup patch > * Resolve the conflict with a patch from Rob > * Make the dummy PCI stub inlined > * Print only if the platform is dma-coherrent > V11: > * Drop unnecessary changes (Lucas) > * Tweak according to other reviews of v10. > > V12: > * Create a virtual platform device for the subcomponent GPU > cores > * Bind all subordinate GPU cores to the real PCI master via > component. > > V13: > * Drop the non-component code path, always use the component > framework > to bind subcomponent GPU core. Even though there is only > one core. > * Defer the irq handler register. > * Rebase and improve the commit message > > V14: > * Rebase onto etnaviv-next and improve commit message. > > Tested with JD9230P GPU and LingJiu GP102 GPU. BTW how should VRAM and displayed related parts be handled on these dGPUs? > > Sui Jingfeng (8): > drm/etnaviv: Add a dedicated helper function to get various clocks > drm/etnaviv: Add constructor and destructor for the > etnaviv_drm_private structure > drm/etnaviv: Embed struct drm_device into struct > etnaviv_drm_private > drm/etnaviv: Fix wrong cache property being used for vmap() > drm/etnaviv: Add support for cached coherent caching mode > drm/etnaviv: Replace the '>dev' with 'dev' > drm/etnaviv: Allow creating subdevices and pass platform specific > data > drm/etnaviv: Add support for vivante GPU cores attached via PCIe > device > > drivers/gpu/drm/etnaviv/Kconfig | 8 + > drivers/gpu/drm/etnaviv/Makefile | 2 + > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 159 ++-- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 27 +++ > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 22 ++- > drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 144 +- > drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 4 + > drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 187 > +++ > drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 18 ++ > include/uapi/drm/etnaviv_drm.h | 1 + > 12 files changed, 468 insertions(+), 110 deletions(-) > create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c > create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h > > > base-commit: 52272bfff15ee70c7bd5be9368f175948fb8ecfd
Re: [PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > > > Am 17.06.24 um 12:58 schrieb Icenowy Zheng:
> > > > > > The duplication of EOP packets for GFX7/8, with the former
> > > > > > one
> > > > > > have
> > > > > > seq-1 written and the latter one have seq written, seems to
> > > > > > confuse
> > > > > > some
> > > > > > hardware platform (e.g. Loongson 7A series PCIe
> > > > > > controllers).
> > > > > >
> > > > > > Make the content of the duplicated EOP packet the same with
> > > > > > the
> > > > > > real
> > > > > > one, only masking any possible interrupts.
> > > > > Well completely NAK to that, exactly that disables the
> > > > > workaround.
> > > > >
> > > > > The CPU needs to see two different values written here.
> > > > Why do the CPU need to see two different values here? Only the
> > > > second
> > > > packet will raise an interrupt before and after applying this
> > > > patch,
> > > > and the first packet's result should just be overriden on
> > > > ordinary
> > > > platforms. The CPU won't see the first one, until it's polling
> > > > for
> > > > the
> > > > address for a very short interval, so short that the GPU CP
> > > > couldn't
> > > > execute 2 commands.
> > > Yes exactly that. We need to make two writes, one with the old
> > > value
> > > (seq - 1) and a second with the real value (seq).
> > >
> > > Otherwise it is possible that a polling CPU would see the
> > > sequence
> > > before the second EOP is issued with results in incoherent view
> > > of
> > > memory.
> > In this case shouldn't we write seq-1 before any work, and then
> > write
> > seq after work, like what is done in Mesa?
>
> No. This hw workaround requires that two consecutive write operations
> happen directly behind each other on the PCIe bus with two different
> values.
>
> To make the software logic around that work without any changes we
> use
> the values seq - 1 and seq because those are guaranteed to be
> different
> and not trigger any unwanted software behavior.
>
> Only then we can guarantee that we have a coherent view of system
> memory.
BTW is there any operation that could be taken to examine this specific
workaround?
Is there any case possible to reproduce?
>
> > As what I see, Mesa uses another command buffer to emit a
> > EVENT_WRITE_EOP writing 0, and commit this command buffer before
> > the
> > real command buffer.
> >
> > > > Or do you mean the GPU needs to see two different values being
> > > > written,
> > > > or they will be merged into only one write request?
> > > >
> > > > Please give out more information about this workaround,
> > > > otherwise
> > > > the
> > > > GPU hang problem on Loongson platforms will persist.
> > > Well if Loongson can't handle two consecutive write operations to
> > > the
> > > same address with different values then you have a massive
> > > platform
> > > bug.
> > I think the issue is triggered when two consecutive write
> > operations
> > and one IRQ is present, which is exactly the case of this function.
>
> Well then you have a massive platform bug.
>
> Two consecutive writes to the same bus address are perfectly legal
> from
> the PCIe specification and can happen all the time, even without this
> specific hw workaround.
>
> Regards,
> Christian.
>
> >
> > > That is something which can happen all the time throughout the
> > > operation.
> > >
> > > Regards,
> > > Christian.
> > >
> > > > > Regards,
> > > > > Christian.
> > > > >
> > > > > > Fixes: bf26da927a1c ("drm/amdgpu: add cache flush
> > > > > > workaround to
> > > > > > gfx8 emit_fence")
> > > > > > Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK
> > > > > > parts")
> > > > > > Signed-off-by: Icenowy Zheng
Re: [PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
在 2024-06-17星期一的 16:42 +0200，Christian König写道：
> Am 17.06.24 um 16:30 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> > > Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > > > Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > > > > > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > > > > > Am 17.06.24 um 12:58 schrieb Icenowy Zheng:
> > > > > > > > The duplication of EOP packets for GFX7/8, with the
> > > > > > > > former
> > > > > > > > one
> > > > > > > > have
> > > > > > > > seq-1 written and the latter one have seq written,
> > > > > > > > seems to
> > > > > > > > confuse
> > > > > > > > some
> > > > > > > > hardware platform (e.g. Loongson 7A series PCIe
> > > > > > > > controllers).
> > > > > > > >
> > > > > > > > Make the content of the duplicated EOP packet the same
> > > > > > > > with
> > > > > > > > the
> > > > > > > > real
> > > > > > > > one, only masking any possible interrupts.
> > > > > > > Well completely NAK to that, exactly that disables the
> > > > > > > workaround.
> > > > > > >
> > > > > > > The CPU needs to see two different values written here.
> > > > > > Why do the CPU need to see two different values here? Only
> > > > > > the
> > > > > > second
> > > > > > packet will raise an interrupt before and after applying
> > > > > > this
> > > > > > patch,
> > > > > > and the first packet's result should just be overriden on
> > > > > > ordinary
> > > > > > platforms. The CPU won't see the first one, until it's
> > > > > > polling
> > > > > > for
> > > > > > the
> > > > > > address for a very short interval, so short that the GPU CP
> > > > > > couldn't
> > > > > > execute 2 commands.
> > > > > Yes exactly that. We need to make two writes, one with the
> > > > > old
> > > > > value
> > > > > (seq - 1) and a second with the real value (seq).
> > > > >
> > > > > Otherwise it is possible that a polling CPU would see the
> > > > > sequence
> > > > > before the second EOP is issued with results in incoherent
> > > > > view
> > > > > of
> > > > > memory.
> > > > In this case shouldn't we write seq-1 before any work, and then
> > > > write
> > > > seq after work, like what is done in Mesa?
> > > No. This hw workaround requires that two consecutive write
> > > operations
> > > happen directly behind each other on the PCIe bus with two
> > > different
> > > values.
> > Well to be honest the workaround code in Mesa seems to not be
> > working
> > in this way ...
>
> Mesa doesn't have any workaround for that hw issue, the code there
> uses
> a quite different approach.
Ah? Commit bf26da927a1c ("drm/amdgpu: add cache flush workaround to
gfx8 emit_fence") says "Both PAL and Mesa use it for gfx8 too, so port
this commit to gfx_v8_0_ring_emit_fence_gfx", so maybe the workaround
should just be not necessary here?
>
> > > To make the software logic around that work without any changes
> > > we
> > > use
> > > the values seq - 1 and seq because those are guaranteed to be
> > > different
> > > and not trigger any unwanted software behavior.
> > >
> > > Only then we can guarantee that we have a coherent view of system
> > > memory.
> > Any more details about it?
>
> No, sorry. All I know is that it's a bug in the cache flush logic
> which
> can be worked around by issuing two write behind each other to the
> same
> location.
So the issue is that the first EOP write does not properly flush the
cache? Could EVENT_WRITE be used instead of EVENT_WRITE_EOP in this
workaround to properly flush it without hurting the fence value?
>
> > BTW in this case, could I try to write it for 3 times instead of 2,
> > with seq-1, seq and seq?
>
> That could potentially work as well, but at
Re: [PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
在 2024-06-17星期一的 15:59 +0200，Christian König写道：
> Am 17.06.24 um 15:43 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> > > Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > > > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > > > Am 17.06.24 um 12:58 schrieb Icenowy Zheng:
> > > > > > The duplication of EOP packets for GFX7/8, with the former
> > > > > > one
> > > > > > have
> > > > > > seq-1 written and the latter one have seq written, seems to
> > > > > > confuse
> > > > > > some
> > > > > > hardware platform (e.g. Loongson 7A series PCIe
> > > > > > controllers).
> > > > > >
> > > > > > Make the content of the duplicated EOP packet the same with
> > > > > > the
> > > > > > real
> > > > > > one, only masking any possible interrupts.
> > > > > Well completely NAK to that, exactly that disables the
> > > > > workaround.
> > > > >
> > > > > The CPU needs to see two different values written here.
> > > > Why do the CPU need to see two different values here? Only the
> > > > second
> > > > packet will raise an interrupt before and after applying this
> > > > patch,
> > > > and the first packet's result should just be overriden on
> > > > ordinary
> > > > platforms. The CPU won't see the first one, until it's polling
> > > > for
> > > > the
> > > > address for a very short interval, so short that the GPU CP
> > > > couldn't
> > > > execute 2 commands.
> > > Yes exactly that. We need to make two writes, one with the old
> > > value
> > > (seq - 1) and a second with the real value (seq).
> > >
> > > Otherwise it is possible that a polling CPU would see the
> > > sequence
> > > before the second EOP is issued with results in incoherent view
> > > of
> > > memory.
> > In this case shouldn't we write seq-1 before any work, and then
> > write
> > seq after work, like what is done in Mesa?
>
> No. This hw workaround requires that two consecutive write operations
> happen directly behind each other on the PCIe bus with two different
> values.
Well to be honest the workaround code in Mesa seems to not be working
in this way ...
>
> To make the software logic around that work without any changes we
> use
> the values seq - 1 and seq because those are guaranteed to be
> different
> and not trigger any unwanted software behavior.
>
> Only then we can guarantee that we have a coherent view of system
> memory.
Any more details about it?
BTW in this case, could I try to write it for 3 times instead of 2,
with seq-1, seq and seq?
>
> > As what I see, Mesa uses another command buffer to emit a
> > EVENT_WRITE_EOP writing 0, and commit this command buffer before
> > the
> > real command buffer.
> >
> > > > Or do you mean the GPU needs to see two different values being
> > > > written,
> > > > or they will be merged into only one write request?
> > > >
> > > > Please give out more information about this workaround,
> > > > otherwise
> > > > the
> > > > GPU hang problem on Loongson platforms will persist.
> > > Well if Loongson can't handle two consecutive write operations to
> > > the
> > > same address with different values then you have a massive
> > > platform
> > > bug.
> > I think the issue is triggered when two consecutive write
> > operations
> > and one IRQ is present, which is exactly the case of this function.
>
> Well then you have a massive platform bug.
>
> Two consecutive writes to the same bus address are perfectly legal
> from
> the PCIe specification and can happen all the time, even without this
> specific hw workaround.
Yes I know it, and I am not from Loongson, just some user trying to
mess around it.
>
> Regards,
> Christian.
>
> >
> > > That is something which can happen all the time throughout the
> > > operation.
> > >
> > > Regards,
> > > Christian.
> > >
> > > > > Regards,
> > > > > Christian.
> > > > >
> > > > > > Fixes: bf26da927a1c ("drm/amdgpu: add cache flush
> > > > > > workaround to
> > > > > > gfx8 emit_fence")
> >
Re: [PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
在 2024-06-17星期一的 15:09 +0200，Christian König写道：
> Am 17.06.24 um 15:03 schrieb Icenowy Zheng:
> > 在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> > > Am 17.06.24 um 12:58 schrieb Icenowy Zheng:
> > > > The duplication of EOP packets for GFX7/8, with the former one
> > > > have
> > > > seq-1 written and the latter one have seq written, seems to
> > > > confuse
> > > > some
> > > > hardware platform (e.g. Loongson 7A series PCIe controllers).
> > > >
> > > > Make the content of the duplicated EOP packet the same with the
> > > > real
> > > > one, only masking any possible interrupts.
> > > Well completely NAK to that, exactly that disables the
> > > workaround.
> > >
> > > The CPU needs to see two different values written here.
> > Why do the CPU need to see two different values here? Only the
> > second
> > packet will raise an interrupt before and after applying this
> > patch,
> > and the first packet's result should just be overriden on ordinary
> > platforms. The CPU won't see the first one, until it's polling for
> > the
> > address for a very short interval, so short that the GPU CP
> > couldn't
> > execute 2 commands.
>
> Yes exactly that. We need to make two writes, one with the old value
> (seq - 1) and a second with the real value (seq).
>
> Otherwise it is possible that a polling CPU would see the sequence
> before the second EOP is issued with results in incoherent view of
> memory.
In this case shouldn't we write seq-1 before any work, and then write
seq after work, like what is done in Mesa?
As what I see, Mesa uses another command buffer to emit a
EVENT_WRITE_EOP writing 0, and commit this command buffer before the
real command buffer.
>
> > Or do you mean the GPU needs to see two different values being
> > written,
> > or they will be merged into only one write request?
> >
> > Please give out more information about this workaround, otherwise
> > the
> > GPU hang problem on Loongson platforms will persist.
>
> Well if Loongson can't handle two consecutive write operations to the
> same address with different values then you have a massive platform
> bug.
I think the issue is triggered when two consecutive write operations
and one IRQ is present, which is exactly the case of this function.
>
> That is something which can happen all the time throughout the
> operation.
>
> Regards,
> Christian.
>
> >
> > > Regards,
> > > Christian.
> > >
> > > > Fixes: bf26da927a1c ("drm/amdgpu: add cache flush workaround to
> > > > gfx8 emit_fence")
> > > > Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
> > > > Signed-off-by: Icenowy Zheng
> > > > ---
> > > > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +---
> > > > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12
> > > > 2 files changed, 9 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > > > b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > > > index 541dbd70d8c75..778f27f1a34fe 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > > > @@ -2117,9 +2117,8 @@ static void
> > > > gfx_v7_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64
> > > > addr,
> > > > {
> > > > bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
> > > > bool int_sel = flags & AMDGPU_FENCE_FLAG_INT;
> > > > - /* Workaround for cache flush problems. First send a
> > > > dummy
> > > > EOP
> > > > - * event down the pipe with seq one below.
> > > > - */
> > > > +
> > > > + /* Workaround for cache flush problems, send EOP twice.
> > > > */
> > > > amdgpu_ring_write(ring,
> > > > PACKET3(PACKET3_EVENT_WRITE_EOP,
> > > > 4));
> > > > amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
> > > > EOP_TC_ACTION_EN |
> > > > @@ -2127,11 +2126,10 @@ static void
> > > > gfx_v7_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64
> > > > addr,
> > > > EVENT_INDEX(5)));
> > > > amdgpu_ring_write(ring, addr & 0xfffc);
> > > > amdgpu_ring_w
Re: [PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
在 2024-06-17星期一的 14:35 +0200，Christian König写道：
> Am 17.06.24 um 12:58 schrieb Icenowy Zheng:
> > The duplication of EOP packets for GFX7/8, with the former one have
> > seq-1 written and the latter one have seq written, seems to confuse
> > some
> > hardware platform (e.g. Loongson 7A series PCIe controllers).
> >
> > Make the content of the duplicated EOP packet the same with the
> > real
> > one, only masking any possible interrupts.
>
> Well completely NAK to that, exactly that disables the workaround.
>
> The CPU needs to see two different values written here.
Why do the CPU need to see two different values here? Only the second
packet will raise an interrupt before and after applying this patch,
and the first packet's result should just be overriden on ordinary
platforms. The CPU won't see the first one, until it's polling for the
address for a very short interval, so short that the GPU CP couldn't
execute 2 commands.
Or do you mean the GPU needs to see two different values being written,
or they will be merged into only one write request?
Please give out more information about this workaround, otherwise the
GPU hang problem on Loongson platforms will persist.
>
> Regards,
> Christian.
>
> >
> > Fixes: bf26da927a1c ("drm/amdgpu: add cache flush workaround to
> > gfx8 emit_fence")
> > Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +---
> > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12
> > 2 files changed, 9 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > index 541dbd70d8c75..778f27f1a34fe 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> > @@ -2117,9 +2117,8 @@ static void
> > gfx_v7_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64 addr,
> > {
> > bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
> > bool int_sel = flags & AMDGPU_FENCE_FLAG_INT;
> > - /* Workaround for cache flush problems. First send a dummy
> > EOP
> > - * event down the pipe with seq one below.
> > - */
> > +
> > + /* Workaround for cache flush problems, send EOP twice. */
> > amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP,
> > 4));
> > amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
> > EOP_TC_ACTION_EN |
> > @@ -2127,11 +2126,10 @@ static void
> > gfx_v7_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64 addr,
> > EVENT_INDEX(5)));
> > amdgpu_ring_write(ring, addr & 0xfffc);
> > amdgpu_ring_write(ring, (upper_32_bits(addr) & 0x) |
> > - DATA_SEL(1) | INT_SEL(0));
> > - amdgpu_ring_write(ring, lower_32_bits(seq - 1));
> > - amdgpu_ring_write(ring, upper_32_bits(seq - 1));
> > + DATA_SEL(write64bit ? 2 : 1) |
> > INT_SEL(0));
> > + amdgpu_ring_write(ring, lower_32_bits(seq));
> > + amdgpu_ring_write(ring, upper_32_bits(seq));
> >
> > - /* Then send the real EOP event down the pipe. */
> > amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP,
> > 4));
> > amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
> > EOP_TC_ACTION_EN |
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > index 2f0e72caee1af..39a7d60f1fd69 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> > @@ -6153,9 +6153,7 @@ static void
> > gfx_v8_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64 addr,
> > bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
> > bool int_sel = flags & AMDGPU_FENCE_FLAG_INT;
> >
> > - /* Workaround for cache flush problems. First send a dummy
> > EOP
> > - * event down the pipe with seq one below.
> > - */
> > + /* Workaround for cache flush problems, send EOP twice. */
> > amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP,
> > 4));
> > amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
> > EOP_TC_ACTION_EN |
> > @@ -6164,12 +6162,10 @@ static void
> > gfx_v8_0_ring_emit_fence_gfx(struct amdgpu_ring *ring, u64 addr,
> >
[PATCH 2/2] drm/radeon: repeat the same EOP packet for EOP workaround on CIK
Ths first EOP packet with a sequence number as seq-1 seems to confuse
some PCIe hardware (e.g. Loongson 7A PCHs).
Use the real sequence number instead.
Fixes: a9c73a0e022c ("drm/radeon: workaround for CP HW bug on CIK")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/radeon/cik.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 8275eeba0b349..9d203054f922a 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3543,9 +3543,7 @@ void cik_fence_gfx_ring_emit(struct radeon_device *rdev,
struct radeon_ring *ring = >ring[fence->ring];
u64 addr = rdev->fence_drv[fence->ring].gpu_addr;
- /* Workaround for cache flush problems. First send a dummy EOP
-* event down the pipe with seq one below.
-*/
+ /* Workaround for cache flush problems by sending the EOP event twice */
radeon_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
radeon_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
@@ -3554,10 +3552,9 @@ void cik_fence_gfx_ring_emit(struct radeon_device *rdev,
radeon_ring_write(ring, addr & 0xfffc);
radeon_ring_write(ring, (upper_32_bits(addr) & 0x) |
DATA_SEL(1) | INT_SEL(0));
- radeon_ring_write(ring, fence->seq - 1);
+ radeon_ring_write(ring, fence->seq);
radeon_ring_write(ring, 0);
- /* Then send the real EOP event down the pipe. */
radeon_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
radeon_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
--
2.45.1
[PATCH 1/2] drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content
The duplication of EOP packets for GFX7/8, with the former one have
seq-1 written and the latter one have seq written, seems to confuse some
hardware platform (e.g. Loongson 7A series PCIe controllers).
Make the content of the duplicated EOP packet the same with the real
one, only masking any possible interrupts.
Fixes: bf26da927a1c ("drm/amdgpu: add cache flush workaround to gfx8
emit_fence")
Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 541dbd70d8c75..778f27f1a34fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -2117,9 +2117,8 @@ static void gfx_v7_0_ring_emit_fence_gfx(struct
amdgpu_ring *ring, u64 addr,
{
bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
bool int_sel = flags & AMDGPU_FENCE_FLAG_INT;
- /* Workaround for cache flush problems. First send a dummy EOP
-* event down the pipe with seq one below.
-*/
+
+ /* Workaround for cache flush problems, send EOP twice. */
amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
@@ -2127,11 +2126,10 @@ static void gfx_v7_0_ring_emit_fence_gfx(struct
amdgpu_ring *ring, u64 addr,
EVENT_INDEX(5)));
amdgpu_ring_write(ring, addr & 0xfffc);
amdgpu_ring_write(ring, (upper_32_bits(addr) & 0x) |
- DATA_SEL(1) | INT_SEL(0));
- amdgpu_ring_write(ring, lower_32_bits(seq - 1));
- amdgpu_ring_write(ring, upper_32_bits(seq - 1));
+ DATA_SEL(write64bit ? 2 : 1) | INT_SEL(0));
+ amdgpu_ring_write(ring, lower_32_bits(seq));
+ amdgpu_ring_write(ring, upper_32_bits(seq));
- /* Then send the real EOP event down the pipe. */
amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 2f0e72caee1af..39a7d60f1fd69 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -6153,9 +6153,7 @@ static void gfx_v8_0_ring_emit_fence_gfx(struct
amdgpu_ring *ring, u64 addr,
bool write64bit = flags & AMDGPU_FENCE_FLAG_64BIT;
bool int_sel = flags & AMDGPU_FENCE_FLAG_INT;
- /* Workaround for cache flush problems. First send a dummy EOP
-* event down the pipe with seq one below.
-*/
+ /* Workaround for cache flush problems, send EOP twice. */
amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
@@ -6164,12 +6162,10 @@ static void gfx_v8_0_ring_emit_fence_gfx(struct
amdgpu_ring *ring, u64 addr,
EVENT_INDEX(5)));
amdgpu_ring_write(ring, addr & 0xfffc);
amdgpu_ring_write(ring, (upper_32_bits(addr) & 0x) |
- DATA_SEL(1) | INT_SEL(0));
- amdgpu_ring_write(ring, lower_32_bits(seq - 1));
- amdgpu_ring_write(ring, upper_32_bits(seq - 1));
+ DATA_SEL(write64bit ? 2 : 1) | INT_SEL(0));
+ amdgpu_ring_write(ring, lower_32_bits(seq));
+ amdgpu_ring_write(ring, upper_32_bits(seq));
- /* Then send the real EOP event down the pipe:
-* EVENT_WRITE_EOP - flush caches, send int */
amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE_EOP, 4));
amdgpu_ring_write(ring, (EOP_TCL1_ACTION_EN |
EOP_TC_ACTION_EN |
--
2.45.1
[PATCH 0/2] Fixes of AMD GFX7/8 hang on Loongson platforms
This patchset tries to fix some workaround code in amdgpu/radeon driver, that makes Loongson 3A+7A platform suffering from GPU crashes. Icenowy Zheng (2): drm/amdgpu: make duplicated EOP packet for GFX7/8 have real content drm/radeon: repeat the same EOP packet for EOP workaround on CIK drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 12 +--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12 drivers/gpu/drm/radeon/cik.c | 7 ++- 3 files changed, 11 insertions(+), 20 deletions(-) -- 2.45.1
Re: [PATCH v2 5/6] drm/panel: st7703: Drive XBD599 panel at higher clock rate
在 2024-02-25星期日的 17:46 +0100，Frank Oltmanns写道： > Hi Maxime, > > On 2024-02-22 at 11:29:51 +0100, Maxime Ripard > wrote: > > [[PGP Signed Part:Undecided]] > > On Sun, Feb 11, 2024 at 04:42:43PM +0100, Frank Oltmanns wrote: > > > > > > On 2024-02-08 at 20:05:08 +0100, Maxime Ripard > > > wrote: > > > > [[PGP Signed Part:Undecided]] > > > > Hi Frank, > > > > > > > > On Mon, Feb 05, 2024 at 04:22:28PM +0100, Frank Oltmanns wrote: > > > > > This panel is used in the pinephone that runs on a Allwinner > > > > > A64 SOC. > > > > > The SOC requires pll-mipi to run at more than 500 MHz. > > > > > > > > > > This is the relevant clock tree: > > > > > pll-mipi > > > > > tcon0 > > > > > tcon-data-clock > > > > > > > > > > tcon-data-clock has to run at 1/4 the DSI per-lane bit rate. > > > > > The XBD599 > > > > > has 24 bpp and 4 lanes. Therefore, the resulting requested > > > > > tcon-data-clock rate is: > > > > > crtc_clock * 1000 * (24 / 4) / 4 > > > > > > > > > > tcon-data-clock runs at tcon0 / 4 (fixed divisor), so it > > > > > requests a > > > > > parent rate of > > > > > 4 * (crtc_clock * 1000 * (24 / 4) / 4) > > > > > > > > > > Since tcon0 is a ccu_mux, the rate of tcon0 equals the rate > > > > > of pll-mipi. > > > > > > > > > > pll-mipi's constraint to run at 500MHz or higher forces us to > > > > > have a > > > > > crtc_clock >= 8 kHz if we want a 60 Hz vertical refresh > > > > > rate. > > > > > > > > > > Change [hv]sync_(start|end) so that we reach a clock rate of > > > > > 83502 kHz > > > > > so that it is high enough to align with pll-pipi limits. > > > > > > > > > > Signed-off-by: Frank Oltmanns > > > > > > > > That commit log is great, but it's kind of off-topic. It's a > > > > panel > > > > driver, it can be used on any MIPI-DSI controller, the only > > > > relevant > > > > information there should be the panel timings required in the > > > > datasheet. > > > > > > > > The PLL setup is something for the MIPI-DSI driver to adjust, > > > > not for > > > > the panel to care for. > > > > > > > > > > I absolutely agree. It even was the reason for my submission of a > > > sunxi-ng patch series last year that was accepted, to make pll- > > > mipi more > > > flexible. :) > > > > > > The only remaining option I currently see for adjusting the > > > sunxi-ng > > > driver to further accomodate the panel, is trying to use a higher > > > divisor than 4 for calculating tcon-data-clock from tcon0. I > > > remember > > > reading a discussion about this, but as far as I remember that > > > proposal > > > was rejected (by you, IIRC). > > > > > > While I appreciate other suggestion as well, I'll look into > > > options for > > > using a different divisor than 4. > > > > Like I said, I'm not against the patch at all, it looks great to me > > on > > principle. I just think you should completely rephrase the commit > > log > > using the datasheet as the only reliable source of the display > > timings. > > Whether sun4i can work around the panel requirements is something > > completely orthogonal to the discussion, and thus the commit log. > > > > I was trying to follow the guidelines [1] for describing the reason > behind my changes to the panel. My original commit message was a lot > shorter, which, understandably, resulted in follow up questions [2]. > With the current commit log, I'm trying to address those questions. > According to the device tree, the panel is only used in the > pinephone. > The only reason for the change is that the SoC used by the only user > of > this panel can not provide the rate the panel requests with the > current > values. I think this information is relevant. > > Unfortunately, as described in [2], I cannot back these values with > any > datasheets because I couldn't find any. I could only find hints that > they are not publicly available. Icenowy (added to CC) submitted the > original values. Sorry but this kind of things are just magic from the vendor that I could hardly explain... > > Best regards, > Frank > > [1]: > https://www.kernel.org/doc/html/v6.7/process/submitting-patches.html#describe-your-changes > [2]: https://lore.kernel.org/lkml/87wmsvo0fh@oltmanns.dev/ > > > > > Maxime > > > > [[End of PGP Signed Part]] >
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-07星期四的 19:31 +0800，Keith Zhao写道：
>
>
> On 2023/12/7 16:41, Icenowy Zheng wrote:
> > 在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
> > *snip*
> >
> > > +static void update_cursor_plane(struct vs_dc *dc, struct
> > > vs_plane
> > > *plane,
> > > + struct drm_plane *drm_plane,
> > > + struct drm_atomic_state
> > > *drm_state)
> > > +{
> > > + struct drm_plane_state *state =
> > > drm_atomic_get_new_plane_state(drm_state,
> > > +
> > >
> > > drm_plane);
> > > + struct vs_plane_state *plane_state =
> > > to_vs_plane_state(state);
> > > + struct drm_framebuffer *drm_fb = state->fb;
> > > + struct dc_hw_cursor cursor;
> > > +
> > > + cursor.address = plane_state->dma_addr[0];
> > > + cursor.x = state->crtc_x;
> > > + cursor.y = state->crtc_y;
> >
> > From my experiments on poking with registers on T-Head TH1520 (also
> > uses DC8200 display controller and a similar driver), the DC8200
> > hardware have a different definition of cursor position X and Y
> > with
> > the CRTC plane state.
> >
> > For CRTC plane state, hot_x and hot_y are only provided as
> > reference,
> > and the cursor should be displayed with its (0,0) drawn to (crtc_x,
> > crtc_y) ([XY]_crtc are values specified in CRTC state, the right
> > part
> > of the assignments here), when the cursor is moved to (0,0) but the
> > hot
> > point is not (0,0), it could be negative.
> >
> > However, for DC8200 registers definition, cursor XY position could
> > not
> > be negative -- the cursor will disappear then; because in its
> > definition, the cursor XY position should be where the cursor is
> > pointing to, instead of its (0,0). DC8200 will draw (0,0) of the
> > cursor
> > to (x - hot_x, y - hot_y). So to met the expectation of the KMS
> > plane
> > settings, the DC8200 position should be set to (crtc_x + hot_x,
> > crtc_y
> > + hot_y) instead. Thus these two lines of code should be:
> >
> > ```
> > cursor.x = state->crtc_x + drm_fb->hot_x;
> > cursor.y = state->crtc_y + drm_fb->hot_y;
> > ```
Well I realized that this change is not correct too: when moving the
mouse cursor with the screen rotated, the mouse cursor will disappear
at some screen border.
My current idea is:
As the CRTC hot point is just a reference, we can just ignore it, and
use the HW hot point to implement negative cursor position.
The patch is like the follow:
-cursor.x = state->crtc_x;
-cursor.y = state->crtc_y;
-cursor.hot_x = drm_fb->hot_x;
-cursor.hot_y = drm_fb->hot_y;
+if (state->crtc_x > 0) {
+cursor.x = state->crtc_x;
+cursor.hot_x = 0;
+} else {
+cursor.hot_x = -state->crtc_x;
+cursor.x = 0;
+}
+if (state->crtc_y > 0) {
+cursor.y = state->crtc_y;
+cursor.hot_y = 0;
+} else {
+cursor.hot_y = -state->crtc_y;
+cursor.y = 0;
+}
drm_fb could just be removed in this function then because it's no
longer needed (it's used to get the cursor's hot point, which we
ignored now).
> >
> >
> > > + cursor.hot_x = drm_fb->hot_x;
> > > + cursor.hot_y = drm_fb->hot_y;
> > > + cursor.display_id = to_vs_display_id(dc, state->crtc);
> > > + update_cursor_size(state, );
> > > + cursor.enable = true;
> > > +
> > > + dc_hw_update_cursor(>hw, cursor.display_id, );
> > > +}
> > *snip
> hello Icenowy:
> you are deep understanding on dc8200.
> by the way of practice
> I tested this change on the debian desktop, is there a way to compare
> the cursor behavior change?
> Thanks
>
>
>
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-07星期四的 19:31 +0800，Keith Zhao写道：
>
>
> On 2023/12/7 16:41, Icenowy Zheng wrote:
> > 在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
> > *snip*
> >
> > > +static void update_cursor_plane(struct vs_dc *dc, struct
> > > vs_plane
> > > *plane,
> > > + struct drm_plane *drm_plane,
> > > + struct drm_atomic_state
> > > *drm_state)
> > > +{
> > > + struct drm_plane_state *state =
> > > drm_atomic_get_new_plane_state(drm_state,
> > > +
> > >
> > > drm_plane);
> > > + struct vs_plane_state *plane_state =
> > > to_vs_plane_state(state);
> > > + struct drm_framebuffer *drm_fb = state->fb;
> > > + struct dc_hw_cursor cursor;
> > > +
> > > + cursor.address = plane_state->dma_addr[0];
> > > + cursor.x = state->crtc_x;
> > > + cursor.y = state->crtc_y;
> >
> > From my experiments on poking with registers on T-Head TH1520 (also
> > uses DC8200 display controller and a similar driver), the DC8200
> > hardware have a different definition of cursor position X and Y
> > with
> > the CRTC plane state.
> >
> > For CRTC plane state, hot_x and hot_y are only provided as
> > reference,
> > and the cursor should be displayed with its (0,0) drawn to (crtc_x,
> > crtc_y) ([XY]_crtc are values specified in CRTC state, the right
> > part
> > of the assignments here), when the cursor is moved to (0,0) but the
> > hot
> > point is not (0,0), it could be negative.
> >
> > However, for DC8200 registers definition, cursor XY position could
> > not
> > be negative -- the cursor will disappear then; because in its
> > definition, the cursor XY position should be where the cursor is
> > pointing to, instead of its (0,0). DC8200 will draw (0,0) of the
> > cursor
> > to (x - hot_x, y - hot_y). So to met the expectation of the KMS
> > plane
> > settings, the DC8200 position should be set to (crtc_x + hot_x,
> > crtc_y
> > + hot_y) instead. Thus these two lines of code should be:
> >
> > ```
> > cursor.x = state->crtc_x + drm_fb->hot_x;
> > cursor.y = state->crtc_y + drm_fb->hot_y;
> > ```
> >
> >
> > > + cursor.hot_x = drm_fb->hot_x;
> > > + cursor.hot_y = drm_fb->hot_y;
> > > + cursor.display_id = to_vs_display_id(dc, state->crtc);
> > > + update_cursor_size(state, );
> > > + cursor.enable = true;
> > > +
> > > + dc_hw_update_cursor(>hw, cursor.display_id, );
> > > +}
> > *snip
> hello Icenowy:
> you are deep understanding on dc8200.
> by the way of practice
> I tested this change on the debian desktop, is there a way to compare
> the cursor behavior change?
Try selecting some small-sized text in a textbox?
> Thanks
>
>
>
Re: [v3 4/6] drm/vs: Add KMS crtc
在 2023-12-04星期一的 20:33 +0800，Keith Zhao写道：
*snip*
> +static void update_cursor_plane(struct vs_dc *dc, struct vs_plane
> *plane,
> + struct drm_plane *drm_plane,
> + struct drm_atomic_state *drm_state)
> +{
> + struct drm_plane_state *state =
> drm_atomic_get_new_plane_state(drm_state,
> +
> drm_plane);
> + struct vs_plane_state *plane_state =
> to_vs_plane_state(state);
> + struct drm_framebuffer *drm_fb = state->fb;
> + struct dc_hw_cursor cursor;
> +
> + cursor.address = plane_state->dma_addr[0];
> + cursor.x = state->crtc_x;
> + cursor.y = state->crtc_y;
From my experiments on poking with registers on T-Head TH1520 (also
uses DC8200 display controller and a similar driver), the DC8200
hardware have a different definition of cursor position X and Y with
the CRTC plane state.
For CRTC plane state, hot_x and hot_y are only provided as reference,
and the cursor should be displayed with its (0,0) drawn to (crtc_x,
crtc_y) ([XY]_crtc are values specified in CRTC state, the right part
of the assignments here), when the cursor is moved to (0,0) but the hot
point is not (0,0), it could be negative.
However, for DC8200 registers definition, cursor XY position could not
be negative -- the cursor will disappear then; because in its
definition, the cursor XY position should be where the cursor is
pointing to, instead of its (0,0). DC8200 will draw (0,0) of the cursor
to (x - hot_x, y - hot_y). So to met the expectation of the KMS plane
settings, the DC8200 position should be set to (crtc_x + hot_x, crtc_y
+ hot_y) instead. Thus these two lines of code should be:
```
cursor.x = state->crtc_x + drm_fb->hot_x;
cursor.y = state->crtc_y + drm_fb->hot_y;
```
> + cursor.hot_x = drm_fb->hot_x;
> + cursor.hot_y = drm_fb->hot_y;
> + cursor.display_id = to_vs_display_id(dc, state->crtc);
> + update_cursor_size(state, );
> + cursor.enable = true;
> +
> + dc_hw_update_cursor(>hw, cursor.display_id, );
> +}
*snip
Re: [PATCH] drm/loongson: Add support for the DC in LS2K1000 SoC
在 2023-10-12星期四的 00:26 +0800，Sui Jingfeng写道：
> LS2K1000 is a low end SoC (two core 1.0gHz), it don't has dedicated
> VRAM.
> It requires the framebuffer to be phisically continguous to scanout.
> The
> display controller in LS2K1000 don't has built-in GPIO hardware, the
> structure (register bit field) of its pixel, DC, GPU, DDR PLL are
> also
> defferent from other model. But for the display controller itself,
> Most of
> hardware features of it are same with ls7a1000.
>
> Below is a simple dts for it.
Why don't you write a proper, YAML-formatted binding?
This will help handling the correctness of device trees, and a binding
is required to allow the driver to enter.
>
> aliases {
> i2c0 =
> i2c1 =
> };
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> display_reserved: framebuffer@3000 {
> compatible = "shared-dma-pool";
> reg = <0x0 0x2000 0x0 0x0800>; /* 128M */
> linux,cma-default;
> };
> };
>
> i2c0: i2c-gpio-0 {
> compatible = "i2c-gpio";
> scl-gpios = < 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> sda-gpios = < 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> i2c-gpio,delay-us = <5>; /* ~100 kHz */
> status = "okay";
> };
>
> i2c1: i2c-gpio-1 {
> compatible = "i2c-gpio";
> scl-gpios = < 33 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> sda-gpios = < 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> i2c-gpio,delay-us = <5>; /* ~100 kHz */
> status = "okay";
> };
>
> display-controller@6,0 {
> reg = <0x3000 0x0 0x0 0x0 0x0>;
> interrupt-parent = <>;
> interrupts = <28 IRQ_TYPE_LEVEL_HIGH>
> memory-region = <_reserved>;
Is a system-wide CMA pool enough for this usage? And for a display
controller, will 128M be too much? (I assume the Vivante GPU do not
require contingous memory).
> status = "okay";
> };
>
> This patch is tested on ls2k1000 evaluation board.
>
> $ dmesg | grep ":00:06.0"
>
> loongson :00:06.0: Found LS2K1000 SoC, revision: 0
> loongson :00:06.0: [drm] dc: 250MHz, ddr: 400MHz, gpu: 228MHz
> loongson :00:06.0: [drm] Using of reserved mem:
> 800@0x2000
> loongson :00:06.0: [drm] VRAM: 8192 pages ready
> loongson :00:06.0: [drm] GTT: 32768 pages ready
> loongson :00:06.0: [drm] display pipe-0 has a DVO
> loongson :00:06.0: [drm] display pipe-1 has a DVO
> loongson :00:06.0: [drm] Total 2 outputs
> loongson :00:06.0: [drm] registered irq: 28
> [drm] Initialized loongson 1.0.0 20220701 for :00:06.0 on minor
> 0
> loongson :00:06.0: [drm] fb0: loongsondrmfb frame buffer device
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/loongson/Makefile | 1 +
> drivers/gpu/drm/loongson/loongson_device.c | 59 +++
> drivers/gpu/drm/loongson/lsdc_drv.c | 44 -
> drivers/gpu/drm/loongson/lsdc_drv.h | 9 ++
> drivers/gpu/drm/loongson/lsdc_gfxpll.c | 11 +-
> drivers/gpu/drm/loongson/lsdc_gfxpll.h | 4 +
> drivers/gpu/drm/loongson/lsdc_gfxpll_2k1000.c | 141
> drivers/gpu/drm/loongson/lsdc_i2c.c | 41 +
> drivers/gpu/drm/loongson/lsdc_i2c.h | 4 +
> drivers/gpu/drm/loongson/lsdc_pixpll.c | 153
> +-
> drivers/gpu/drm/loongson/lsdc_pixpll.h | 4 +
> drivers/gpu/drm/loongson/lsdc_probe.c | 27
> drivers/gpu/drm/loongson/lsdc_probe.h | 2 +
> drivers/gpu/drm/loongson/lsdc_regs.h | 36 +
> 14 files changed, 528 insertions(+), 8 deletions(-)
> create mode 100644 drivers/gpu/drm/loongson/lsdc_gfxpll_2k1000.c
>
> diff --git a/drivers/gpu/drm/loongson/Makefile
> b/drivers/gpu/drm/loongson/Makefile
> index 91e72bd900c1..d6e709e19fba 100644
> --- a/drivers/gpu/drm/loongson/Makefile
> +++ b/drivers/gpu/drm/loongson/Makefile
> @@ -7,6 +7,7 @@ loongson-y := \
> lsdc_drv.o \
> lsdc_gem.o \
> lsdc_gfxpll.o \
> + lsdc_gfxpll_2k1000.o \
> lsdc_i2c.o \
> lsdc_irq.o \
> lsdc_output_7a1000.o \
> diff --git a/drivers/gpu/drm/loongson/loongson_device.c
> b/drivers/gpu/drm/loongson/loongson_device.c
> index 9986c8a2a255..67274d9e3b12 100644
> --- a/drivers/gpu/drm/loongson/loongson_device.c
> +++ b/drivers/gpu/drm/loongson/loongson_device.c
> @@ -6,6 +6,7 @@
> #include
>
> #include "lsdc_drv.h"
> +#include "lsdc_probe.h"
>
> static const struct lsdc_kms_funcs ls7a1000_kms_funcs = {
> .create_i2c = lsdc_create_i2c_chan,
> @@ -25,6 +26,20 @@ static const struct lsdc_kms_funcs
> ls7a2000_kms_funcs = {
> .crtc_init = ls7a2000_crtc_init,
> };
>
> +/*
> + * Most of hardware features of ls2k1000 are same with ls7a1000, we
> take the
> + * ls7a1000_kms_funcs as a prototype, copy and modify to form a
> variant for
> + *
[PATCH] drm/amdgpu: fix SI failure due to doorbells allocation
SI hardware does not have doorbells at all, however currently the code
will try to do the allocation and thus fail, makes SI AMDGPU not usable.
Fix this failure by skipping doorbells allocation when doorbells count
is zero.
Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
index d0249ada91d30..599aece42017a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c
@@ -142,6 +142,10 @@ int amdgpu_doorbell_create_kernel_doorbells(struct
amdgpu_device *adev)
int r;
int size;
+ /* SI HW does not have doorbells, skip allocation */
+ if (adev->doorbell.num_kernel_doorbells == 0)
+ return 0;
+
/* Reserve first num_kernel_doorbells (page-aligned) for kernel ops */
size = ALIGN(adev->doorbell.num_kernel_doorbells * sizeof(u32),
PAGE_SIZE);
--
2.39.1
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:48 +0200，Frank Oltmanns写道：
>
> On 2023-08-07 at 17:43:52 +0800, Icenowy Zheng
> wrote:
> > 在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> > > From: Icenowy Zheng
> > >
> > > Notify TCON0 clock (and in consequence PLL-MIPI by
> > > CLK_SET_RATE_PARENT)
> > > to reset when PLL-Video0 changes (because of HDMI PHY clk which
> > > is a
> > > child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way
> > > we
> > > can
> > > get clock tree to satisfy both pipelines.
> >
> > Well for fixing one's patch that contains SoB, use the following
> > format:
> >
> > Signed-off-by: A
> > [B: fixed something]
> > Signed-off-by: B
>
> Ah, okay. Will do. But I keep A in the "From: " line, correct?
Yes.
>
> Thanks,
> Frank
>
> > > ---
> > > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > index ef567775fc95..93beedb0428e 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > > @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb =
> > > {
> > > .bypass_index = 1, /* index of 24 MHz oscillator */
> > > };
> > >
> > > +/*
> > > + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH,
> > > tcon0
> > > clock will
> > > + * conflict with HDMI PHY clock which is on another display
> > > pipeline.
> > > + *
> > > + * Therefore, a notifier is required to restore the rate of
> > > TCON0
> > > when the rate
> > > + * of PLL-Video0 changed.
> > > + */
> > > +static struct ccu_rate_reset_nb
> > > sun50i_a64_pll_video0_reset_tcon0_nb
> > > = {
> > > + .common = _video0_clk.common,
> > > +};
> > > +
> > > static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> > > {
> > > void __iomem *reg;
> > > @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> > > platform_device *pdev)
> > > ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> > > _a64_cpu_nb);
> > >
> > > + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is
> > > changed
> > > */
> > > + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> > > tcon0_clk.common.hw.clk;
> > > + ccu_rate_reset_notifier_register(_a64_pll_video0_r
> > > eset
> > > _tcon0_nb);
> > > +
> > > return 0;
> > > }
> > >
> > >
Re: [PATCH 2/3] clk: sunxi-ng: a64: keep tcon0 clock rate when pll-video0's rate changes
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> Notify TCON0 clock (and in consequence PLL-MIPI by
> CLK_SET_RATE_PARENT)
> to reset when PLL-Video0 changes (because of HDMI PHY clk which is a
> child of PLL-Video0 and has CLK_SET_RATE_PARENT set). In this way we
> can
> get clock tree to satisfy both pipelines.
Well for fixing one's patch that contains SoB, use the following
format:
Signed-off-by: A
[B: fixed something]
Signed-off-by: B
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index ef567775fc95..93beedb0428e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -943,6 +943,17 @@ static struct ccu_mux_nb sun50i_a64_cpu_nb = {
> .bypass_index = 1, /* index of 24 MHz oscillator */
> };
>
> +/*
> + * Since PLL-Video0 is an ancestor of both tcon0 and HDMI PYH, tcon0
> clock will
> + * conflict with HDMI PHY clock which is on another display
> pipeline.
> + *
> + * Therefore, a notifier is required to restore the rate of TCON0
> when the rate
> + * of PLL-Video0 changed.
> + */
> +static struct ccu_rate_reset_nb sun50i_a64_pll_video0_reset_tcon0_nb
> = {
> + .common = _video0_clk.common,
> +};
> +
> static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> {
> void __iomem *reg;
> @@ -978,6 +989,10 @@ static int sun50i_a64_ccu_probe(struct
> platform_device *pdev)
> ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> _a64_cpu_nb);
>
> + /* Reset the rate of TCON0 clock when PLL-VIDEO0 is changed
> */
> + sun50i_a64_pll_video0_reset_tcon0_nb.target_clk =
> tcon0_clk.common.hw.clk;
> + ccu_rate_reset_notifier_register(_a64_pll_video0_reset
> _tcon0_nb);
> +
> return 0;
> }
>
>
Re: [PATCH 1/3] clk: sunxi-ng: add support for rate resetting notifier
在 2023-08-07星期一的 11:36 +0200，Frank Oltmanns写道：
> From: Icenowy Zheng
>
> In some situaitons, we will want a clock rate be kept while its
> parent
> can change, for example, to make dual-head work on A64, TCON0 clock
> needs to be kept for LCD display and its parent (or grandparent)
> PLL-Video0 need to be changed for HDMI display. (There's a quirk on
> A64
> that HDMI PHY can only use PLL-Video0, not PLL-Video1).
>
> Add a notifier helper to create such kind of rate keeping notifier by
> reset the rate after the parent changed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/clk/sunxi-ng/ccu_common.c | 22 ++
> drivers/clk/sunxi-ng/ccu_common.h | 12
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-
> ng/ccu_common.c
> index 8d28a7a079d0..434fa46ad460 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.c
> +++ b/drivers/clk/sunxi-ng/ccu_common.c
> @@ -87,6 +87,28 @@ int ccu_pll_notifier_register(struct ccu_pll_nb
> *pll_nb)
> }
> EXPORT_SYMBOL_NS_GPL(ccu_pll_notifier_register, SUNXI_CCU);
>
> +static int ccu_rate_reset_notifier_cb(struct notifier_block *nb,
> + unsigned long event, void
> *data)
> +{
> + struct ccu_rate_reset_nb *rate_reset =
> to_ccu_rate_reset_nb(nb);
> +
> + if (event == PRE_RATE_CHANGE) {
> + rate_reset->saved_rate = clk_get_rate(rate_reset-
> >target_clk);
In fact I think we should have a better way to save the intended clock
rate ;-)
> + } else if (event == POST_RATE_CHANGE) {
> + clk_set_rate(rate_reset->target_clk, rate_reset-
> >saved_rate);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb)
> +{
> + rate_reset_nb->clk_nb.notifier_call =
> ccu_rate_reset_notifier_cb;
> +
> + return clk_notifier_register(rate_reset_nb->common->hw.clk,
> + _reset_nb->clk_nb);
> +}
> +
> static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct device
> *dev,
> struct device_node *node, void __iomem
> *reg,
> const struct sunxi_ccu_desc *desc)
> diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-
> ng/ccu_common.h
> index fbf16c6b896d..6b0b05fae123 100644
> --- a/drivers/clk/sunxi-ng/ccu_common.h
> +++ b/drivers/clk/sunxi-ng/ccu_common.h
> @@ -69,4 +69,16 @@ int devm_sunxi_ccu_probe(struct device *dev, void
> __iomem *reg,
> void of_sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
> const struct sunxi_ccu_desc *desc);
>
> +struct ccu_rate_reset_nb {
> + struct notifier_block clk_nb;
> + struct ccu_common *common;
> +
> + struct clk *target_clk;
> + unsigned long saved_rate;
> +};
> +
> +#define to_ccu_rate_reset_nb(_nb) container_of(_nb, struct
> ccu_rate_reset_nb, clk_nb)
> +
> +int ccu_rate_reset_notifier_register(struct ccu_rate_reset_nb
> *rate_reset_nb);
> +
> #endif /* _COMMON_H_ */
>
Re: [PATCH] drm/bridge: ps8640: Drop the ability of ps8640 to fetch the EDID
在 2023-06-14星期三的 14:31 -0700，Doug Anderson写道：
> Hi,
>
> On Wed, Jun 14, 2023 at 1:22 AM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 13/06/23 01:32, Douglas Anderson ha scritto:
> > > In order to read the EDID from an eDP panel, you not only need to
> > > power on the bridge chip itself but also the panel. In the ps8640
> > > driver, this was made to work by having the bridge chip manually
> > > power
> > > the panel on by calling pre_enable() on everything connectorward
> > > on
> > > the bridge chain. This worked OK, but...
> > >
> > > ...when trying to do the same thing on ti-sn65dsi86, feedback was
> > > that
> > > this wasn't a great idea. As a result, we designed the "DP AUX"
> > > bus. With the design we ended up with the panel driver itself was
> > > in
> > > charge of reading the EDID. The panel driver could power itself
> > > on and
> > > the bridge chip was able to power itself on because it
> > > implemented the
> > > DP AUX bus.
> > >
> > > Despite the fact that we came up with a new scheme, implemented
> > > in on
> > > ti-sn65dsi86, and even implemented it on parade-ps8640, we still
> > > kept
> > > the old code around. This was because the new scheme required a
> > > DT
> > > change. Previously the panel was a simple "platform_device" and
> > > in DT
> > > at the top level. With the new design the panel needs to be
> > > listed in
> > > DT under the DP controller node. The old code allowed us to
> > > properly
> > > fetch EDIDs with ps8640 with the old DTs.
> > >
> > > Unfortunately, the old code stopped working as of commit
> > > 102e80d1fa2c
> > > ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs").
> > > There
> > > are cases at bootup where connector->state->state is NULL and the
> > > kernel crashed at:
> > > * drm_atomic_bridge_chain_pre_enable
> > > * drm_atomic_get_old_bridge_state
> > > * drm_atomic_get_old_private_obj_state
> > >
> > > A bit of digging was done to see if there was an easy fix but
> > > there
> > > was nothing obvious. Instead, the only device using ps8640 the
> > > "old"
> > > way had its DT updated so that the panel was no longer a simple
> > > "platform_deice". See commit c2d94f72140a ("arm64: dts: mediatek:
> > > mt8173-elm: Move display to ps8640 auxiliary bus") and commit
> > > 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel
> > > model
> > > number in DT").
> > >
> > > Let's delete the old, crashing code so nobody gets tempted to
> > > copy it
> > > or figure out how it works (since it doesn't).
> > >
> > > NOTE: from a device tree "purist" point of view, we're supposed
> > > to
> > > keep old device trees working and this patch is technically
> > > "against
> > > policy". Reasons I'm still proposing it anyway:
> > > 1. Officially, old mt8173-elm device trees worked via the "little
> > > white lie" approach. The DT would list an
> > > arbitrary/representative
> > > panel that would be used for power sequencing. The mode
> > > information
> > > in the panel driver would then be ignored / overridden by the
> > > EDID
> > > reading code in ps8640. I don't feel too terrible breaking
> > > DTs that
> > > contained the wrong "compatible" string to begin with. NOTE
> > > that
> > > any old device trees that _didn't_ lie about their compatible
> > > will
> > > still work because the mode information will come from the
> > > hardcoded panels in panel-edp.
> > > 2. The only users of the old code were Chromebooks and
> > > Chromebooks
> > > don't bake their DTs into the BIOS (they are bundled with the
> > > kernel). Thus we don't need to worry about breaking someone
> > > using
> > > an old DT with a new kernel.
> > > 3. The old code was crashing anyway. If someone wants to fix the
> > > old
> > > code instead of deleting it then they have my blessing, but
> > > without
> > > a proper fix the old code isn't useful.
> > >
> > > I'll list this as "Fixing" the code that made the old code start
> > > failing. There's not lots of reason to bring this back any
> > > further
> > > than that.
> >
> > Hoping to see removal of non-aux EDID reading code from all drivers
> > that can
> > support aux-bus is exactly why I moved Elm to the proper... aux-
> > bus.. so...
> >
> > Yes! Let's go!
> >
> > >
> > > Fixes: 102e80d1fa2c ("drm/bridge: ps8640: Use atomic variants of
> > > drm_bridge_funcs")
> >
> > ...but this Fixes tag will cause this commit to be backported to
> > kernel versions
> > before my commit moving Elm to aux-bus, and break display on those.
> >
> > I would suggest to either find a different Fixes tag, or don't add
> > any, since
> > technically this is a deprecation commit. We could imply that the
> > old technique
> > is deprecated since kernel version X.Y and get away with it.
> >
> > Otherwise, if you want it backported *anyway*, the safest way would
> > be to Cc it
> > to stable and explicitly say which versions should it be backported
> > to.
>
> The problem is
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 18:28 +0200，Matthias Brugger写道：
>
>
> On 29/05/2023 10:45, Icenowy Zheng wrote:
> > 在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> > > Il 26/05/23 16:24, Doug Anderson ha scritto:
> > > > Hi,
> > > >
> > > > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > > > wrote:
> > > > >
> > > > > Currently a specific panel number is used in the Elm DTSI,
> > > > > which
> > > > > is
> > > > > corresponded to a 12" panel. However, according to the
> > > > > official
> > > > > Chrome
> > > > > OS devices document, Elm refers to Acer Chromebook R13,
> > > > > which, as
> > > > > the
> > > > > name specifies, uses a 13.3" panel, which comes with EDID
> > > > > information.
> > > > >
> > > > > As the kernel currently prioritizes the hardcoded timing
> > > > > parameters
> > > > > matched with the panel number compatible, a wrong timing will
> > > > > be
> > > > > applied
> > > > > to the 13.3" panel on Acer Chromebook R13, which leads to
> > > > > blank
> > > > > display.
> > > > >
> > > > > Because the Elm DTSI is shared with Hana board, and Hana
> > > > > corresponds to
> > > > > multiple devices from 11" to 14", a certain panel model
> > > > > number
> > > > > shouldn't
> > > > > be present, and driving the panel according to its EDID
> > > > > information is
> > > > > necessary.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng
> > > > > ---
> > > > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > We went through a bunch of back-and-forth here but in the end
> > > > in
> > > > the
> > > > ChromeOS tree we have "edp-panel" as the "compatible" here in
> > > > the
> > > > ChromeOS 5.15 tree and this makes sense.
> > > >
> > > > Reviewed-by: Douglas Anderson
> > > >
> > > > ...in theory one would wish for a "Fixes" tag, but I think in
> > > > previous
> > > > discussions it was decided that it was too complicated.
> > > > Hardcoding
> > > > the
> > > > other compatible string has always been technically wrong, but
> > > > I
> > > > guess
> > > > it worked at some point in time. The more correct way (as
> > > > you're
> > > > doing
> > > > here) needs the DP AUX bus support and the generic eDP panels,
> > > > both
> > > > of
> > > > which are significantly newer than the elm dts. So I guess
> > > > leaving
> > > > no
> > > > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> > > >
> > > > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > > > display
> > > > to ps8640 auxiliary bus")
> > >
> > > I remember I didn't change the compatible to panel-edp because it
> > > didn't
> > > work at that time, but it does now... I'm not sure what actually
> > > fixed that
> > > and if the commit(s) was/were backported to that suggested point,
> > > so
> > > I
> > > would leave the Fixes tag out, as that may break older kernel.
> >
> > Well at least I developed this patch on v6.3.
> >
> > (In fact the same kernel config do not boot to system at all on
> > v6.0/v6.1 when I do make olddefconfig then build)
> >
>
> I applied the patch without the fixes tag. Lets stay on the secure
> side to not
> break older kernels.
Well I think this patch is at least meaningful to get backported to
v6.3.
Should we cc sta...@vger.kernel.org ?
>
> Regards,
> Matthias
>
> > >
> > > Anyway, for this commit:
> > >
> > > Reviewed-by: AngeloGioacchino Del Regno
> > >
> >
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-29星期一的 10:02 +0200，AngeloGioacchino Del Regno写道：
> Il 26/05/23 16:24, Doug Anderson ha scritto:
> > Hi,
> >
> > On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng
> > wrote:
> > >
> > > Currently a specific panel number is used in the Elm DTSI, which
> > > is
> > > corresponded to a 12" panel. However, according to the official
> > > Chrome
> > > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > > the
> > > name specifies, uses a 13.3" panel, which comes with EDID
> > > information.
> > >
> > > As the kernel currently prioritizes the hardcoded timing
> > > parameters
> > > matched with the panel number compatible, a wrong timing will be
> > > applied
> > > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > > display.
> > >
> > > Because the Elm DTSI is shared with Hana board, and Hana
> > > corresponds to
> > > multiple devices from 11" to 14", a certain panel model number
> > > shouldn't
> > > be present, and driving the panel according to its EDID
> > > information is
> > > necessary.
> > >
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > We went through a bunch of back-and-forth here but in the end in
> > the
> > ChromeOS tree we have "edp-panel" as the "compatible" here in the
> > ChromeOS 5.15 tree and this makes sense.
> >
> > Reviewed-by: Douglas Anderson
> >
> > ...in theory one would wish for a "Fixes" tag, but I think in
> > previous
> > discussions it was decided that it was too complicated. Hardcoding
> > the
> > other compatible string has always been technically wrong, but I
> > guess
> > it worked at some point in time. The more correct way (as you're
> > doing
> > here) needs the DP AUX bus support and the generic eDP panels, both
> > of
> > which are significantly newer than the elm dts. So I guess leaving
> > no
> > "Fixes" tag is OK, or perhaps you could do the somewhat weak:
> >
> > Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move
> > display
> > to ps8640 auxiliary bus")
>
> I remember I didn't change the compatible to panel-edp because it
> didn't
> work at that time, but it does now... I'm not sure what actually
> fixed that
> and if the commit(s) was/were backported to that suggested point, so
> I
> would leave the Fixes tag out, as that may break older kernel.
Well at least I developed this patch on v6.3.
(In fact the same kernel config do not boot to system at all on
v6.0/v6.1 when I do make olddefconfig then build)
>
> Anyway, for this commit:
>
> Reviewed-by: AngeloGioacchino Del Regno
>
Re: [PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
在 2023-05-26星期五的 07:24 -0700，Doug Anderson写道：
> Hi,
>
> On Fri, May 26, 2023 at 3:09 AM Icenowy Zheng wrote:
> >
> > Currently a specific panel number is used in the Elm DTSI, which is
> > corresponded to a 12" panel. However, according to the official
> > Chrome
> > OS devices document, Elm refers to Acer Chromebook R13, which, as
> > the
> > name specifies, uses a 13.3" panel, which comes with EDID
> > information.
> >
> > As the kernel currently prioritizes the hardcoded timing parameters
> > matched with the panel number compatible, a wrong timing will be
> > applied
> > to the 13.3" panel on Acer Chromebook R13, which leads to blank
> > display.
> >
> > Because the Elm DTSI is shared with Hana board, and Hana
> > corresponds to
> > multiple devices from 11" to 14", a certain panel model number
> > shouldn't
> > be present, and driving the panel according to its EDID information
> > is
> > necessary.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> We went through a bunch of back-and-forth here but in the end in the
> ChromeOS tree we have "edp-panel" as the "compatible" here in the
> ChromeOS 5.15 tree and this makes sense.
I only have Elm, so I am curious that do all Hana's only rely on panel
EDID to use different displays?
BTW The Chrome OS document say that Elm and Hana are both board based
on Oak baseboard, should the DTSI be renamed mt8173-oak.dtsi, and still
let mt8173-elm.dts include it and then set model information?
>
> Reviewed-by: Douglas Anderson
>
> ...in theory one would wish for a "Fixes" tag, but I think in
> previous
> discussions it was decided that it was too complicated. Hardcoding
> the
> other compatible string has always been technically wrong, but I
> guess
> it worked at some point in time. The more correct way (as you're
> doing
> here) needs the DP AUX bus support and the generic eDP panels, both
> of
> which are significantly newer than the elm dts. So I guess leaving no
> "Fixes" tag is OK, or perhaps you could do the somewhat weak:
Well I remembered when I was developing the support for Pine64
Pinebook, which is also an ARM64 laptop with an eDP panel (via a DPI-
eDP bridge, ANX6345). At first I didn't use any panel node in the DT,
and the kernel maintainers argued to the bridge that seems to be
connected to nothing (because DP is a discoverable port), and
fortunately 2 Pinebook SKUs (11.6" and 14") is finally reduced to one,
and it's then possible to hardcode a panel model in the Pinebook DT.
According to my memory, the need to specify the panel is to properly
handle eDP panel power up timing, because it's not a very standard
thing. (Well, in my memory, when I was testing that code, on a
(engineering sample) 14" Pinebook, the EDID timing overrided the
hardcoded 11.6" timing and it properly works, the 14" panel is 1366x768
but the 11.6" panel is 1920x1080.)
(BTW when I checked the DT of Olimex TERES-I, which uses the same DPI-
eDP bridge, it is still in the status of a dangling bridge, and of
course it works ;-) )
>
> Fixes: c2d94f72140a ("arm64: dts: mediatek: mt8173-elm: Move display
> to ps8640 auxiliary bus")
Well this sound quite reasonable, as the kernel should have proper AUX
support at this commit.
[PATCH] arm64: dts: mediatek: mt8173-elm: remove panel model number in DT
Currently a specific panel number is used in the Elm DTSI, which is
corresponded to a 12" panel. However, according to the official Chrome
OS devices document, Elm refers to Acer Chromebook R13, which, as the
name specifies, uses a 13.3" panel, which comes with EDID information.
As the kernel currently prioritizes the hardcoded timing parameters
matched with the panel number compatible, a wrong timing will be applied
to the 13.3" panel on Acer Chromebook R13, which leads to blank display.
Because the Elm DTSI is shared with Hana board, and Hana corresponds to
multiple devices from 11" to 14", a certain panel model number shouldn't
be present, and driving the panel according to its EDID information is
necessary.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index d452cab28c67..737737528eed 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -285,7 +285,7 @@ ps8640_out: endpoint {
aux-bus {
panel: panel {
- compatible = "lg,lp120up1";
+ compatible = "edp-panel";
power-supply = <_fixed_3v3>;
backlight = <>;
--
2.39.1
Re: [PATCH] drm/sun4i: mixer: fix scanline for V3s and D1
在 2022-05-22星期日的 10:36 +0200，Jernej Škrabec写道：
> Hi!
>
> Dne sobota, 21. maj 2022 ob 15:34:43 CEST je Genfu Pan napisal(a):
> > Accrording the SDK from Allwinner, the scanline value of yuv and
> > rgb for
> > V3s are both 1024.
>
> s/scanline value/scanline length/
>
> Which SDK? All SDKs that I have or found on internet don't mention
> YUV nor RGB
> scanline limit. That doesn't mean there is none, I'm just unable to
> verify
> your claim. Did you test this by yourself? Also, please make YUV
> scanline
> change separate patch with fixes tag.
BTW I think chip manuals all say that the chip supports NxN resolution
in DE2 chapter, e.g. the V3 datasheet says DE2 "Output size up to
1024x1024".
However there's no information about D1's second mixer.
>
> > The is also the same for mixer 1 of D1. Currently the
> > scanline value of rgb is hardcoded to 2048 for all SOCs.
> >
> > Change the scanline_yuv property of V3s to 1024. > Add the
> > scanline_rgb
> > property to the mixer config and replace the hardcoded value with
> > it before
> > scaling.
>
> I guess RGB scanline patch would also need fixes tag, since it fixes
> existing
> bug.
>
> >
> > Signed-off-by: Genfu Pan
> > ---
> > drivers/gpu/drm/sun4i/sun8i_mixer.c | 13 -
> > drivers/gpu/drm/sun4i/sun8i_mixer.h | 1 +
> > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 3 +--
> > 3 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index 875a1156c..e64e08207
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -567,6 +567,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer0_cfg = { .ccsc = CCSC_MIXER0_LAYOUT,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -575,6 +576,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_a83t_mixer1_cfg = { .ccsc = CCSC_MIXER1_LAYOUT,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -584,6 +586,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_h3_mixer0_cfg
> > = { .mod_rate = 43200,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -593,6 +596,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -602,6 +606,7 @@ static const struct sun8i_mixer_cfg
> > sun8i_r40_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -610,7 +615,8 @@ static const struct sun8i_mixer_cfg
> > sun8i_v3s_mixer_cfg
> > = { .vi_num = 2,
> > .ui_num = 1,
> > .scaler_mask = 0x3,
> > - .scanline_yuv = 2048,
> > + .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ccsc = CCSC_MIXER0_LAYOUT,
> > .mod_rate = 15000,
> > };
> > @@ -620,6 +626,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer0_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -629,6 +636,7 @@ static const struct sun8i_mixer_cfg
> > sun20i_d1_mixer1_cfg
> > = { .mod_rate = 29700,
> > .scaler_mask= 0x1,
> > .scanline_yuv = 1024,
> > + .scanline_rgb = 1024,
> > .ui_num = 0,
> > .vi_num = 1,
> > };
> > @@ -638,6 +646,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer0_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
> > };
> > @@ -647,6 +656,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_a64_mixer1_cfg = { .mod_rate = 29700,
> > .scaler_mask= 0x3,
> > .scanline_yuv = 2048,
> > + .scanline_rgb = 2048,
> > .ui_num = 1,
> > .vi_num = 1,
> > };
> > @@ -657,6 +667,7 @@ static const struct sun8i_mixer_cfg
> > sun50i_h6_mixer0_cfg
> > = { .mod_rate = 6,
> > .scaler_mask= 0xf,
> > .scanline_yuv = 4096,
> > + .scanline_rgb = 2048,
> > .ui_num = 3,
> > .vi_num = 1,
Re: [PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
在 2022-02-14星期一的 11:07 -0500，Ilia Mirkin写道：
> I'm not saying this is wrong, but could you file a bug at
> gitlab.freedesktop.org/drm/nouveau/-/issues and include the VBIOS
> (/sys/kernel/debug/dri/0/vbios.rom)? That would make it easier to
> review the full situation.
Created at https://gitlab.freedesktop.org/drm/nouveau/-/issues/158 .
>
> On Mon, Feb 14, 2022 at 11:03 AM Icenowy Zheng wrote:
> >
> > On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is
> > currently
> > always used by nouveau) fails, but the BIOS declares 2 HWSQ entries
> > and
> > entry 1 works.
> >
> > Add a quirk to use HWSQ entry 1.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > index e8c445eb11004..2691d0e0cf9f1 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > @@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
> > drm_device *dev,
> > if (!hwsq_offset)
> > return 0;
> >
> > +#ifdef __powerpc__
> > + /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
> > + if (of_machine_is_compatible("PowerBook6,1"))
> > + return load_nv17_hwsq_ucode_entry(dev, bios,
> > + hwsq_offset + sz,
> > 1);
> > +#endif
> > +
> > /* always use entry 0? */
> > return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset +
> > sz, 0);
> > }
> > --
> > 2.30.2
> >
[PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6,1
On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is currently
always used by nouveau) fails, but the BIOS declares 2 HWSQ entries and
entry 1 works.
Add a quirk to use HWSQ entry 1.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index e8c445eb11004..2691d0e0cf9f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct
drm_device *dev,
if (!hwsq_offset)
return 0;
+#ifdef __powerpc__
+ /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
+ if (of_machine_is_compatible("PowerBook6,1"))
+ return load_nv17_hwsq_ucode_entry(dev, bios,
+ hwsq_offset + sz, 1);
+#endif
+
/* always use entry 0? */
return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset + sz, 0);
}
--
2.30.2
Re: [PATCH] drm/panel: k101-im2ba02: Make use of the helper function dev_err_probe()
在 2021-09-16星期四的 18:42 +0800，Cai Huoqing写道：
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> And using dev_err_probe() can reduce code size, and the error value
> gets printed.
>
> Signed-off-by: Cai Huoqing
Looks good to me, and thanks for pointing out this helper.
Acked-by: Icenowy Zheng
> ---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> index 2a602aee61c3..cb0bb3076099 100644
> --- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> +++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
> @@ -456,16 +456,13 @@ static int k101_im2ba02_dsi_probe(struct
> mipi_dsi_device *dsi)
>
> ret = devm_regulator_bulk_get(>dev, ARRAY_SIZE(ctx-
> >supplies),
> ctx->supplies);
> - if (ret < 0) {
> - dev_err(>dev, "Couldn't get regulators\n");
> - return ret;
> - }
> + if (ret < 0)
> + return dev_err_probe(>dev, ret, "Couldn't get
> regulators\n");
>
> ctx->reset = devm_gpiod_get(>dev, "reset",
> GPIOD_OUT_LOW);
> - if (IS_ERR(ctx->reset)) {
> - dev_err(>dev, "Couldn't get our reset GPIO\n");
> - return PTR_ERR(ctx->reset);
> - }
> + if (IS_ERR(ctx->reset))
> + return dev_err_probe(>dev, PTR_ERR(ctx->reset),
> + "Couldn't get our reset
> GPIO\n");
>
> drm_panel_init(>panel, >dev, _im2ba02_funcs,
> DRM_MODE_CONNECTOR_DSI);
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 17:08 +0200，Thomas Zimmermann写道：
> Hi
>
> Am 02.08.21 um 08:35 schrieb Icenowy Zheng:
> > Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> > commands.
> >
> > Currently a ST7789V-based panel is added to it. This panel has its
> > configuration pre-programmed into the controller, so no vendor-
> > specific
> > configuration is needed.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/gpu/drm/tiny/Kconfig | 12 ++
> > drivers/gpu/drm/tiny/Makefile | 1 +
> > drivers/gpu/drm/tiny/simple-dbi.c | 244
> > ++
> > 3 files changed, 257 insertions(+)
> > create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
> >
> > diff --git a/drivers/gpu/drm/tiny/Kconfig
> > b/drivers/gpu/drm/tiny/Kconfig
> > index d31be274a2bd..6cfc57b68a46 100644
> > --- a/drivers/gpu/drm/tiny/Kconfig
> > +++ b/drivers/gpu/drm/tiny/Kconfig
> > @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
> >
> > If M is selected the module will be called repaper.
> >
> > +config TINYDRM_SIMPLE_DBI
> > + tristate "DRM support for generic MIPI DBI panels"
> > + depends on DRM && SPI
> > + select DRM_KMS_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DBI
> > + help
> > + DRM driver for generic DBI panels that are MIPI DCS
> > compatible
> > + and needs no vendor-specific setup commands.
> > +
> > + If M is selected the module will be called simple-dbi.
> > +
> > config TINYDRM_ST7586
> > tristate "DRM support for Sitronix ST7586 display panels"
> > depends on DRM && SPI
> > diff --git a/drivers/gpu/drm/tiny/Makefile
> > b/drivers/gpu/drm/tiny/Makefile
> > index e09942895c77..2553de651aa3 100644
> > --- a/drivers/gpu/drm/tiny/Makefile
> > +++ b/drivers/gpu/drm/tiny/Makefile
> > @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> > mi0283qt.o
> > obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> > obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> > obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> > +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> > diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> > b/drivers/gpu/drm/tiny/simple-dbi.c
> > new file mode 100644
> > index ..2b207e43d500
> > --- /dev/null
> > +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> > @@ -0,0 +1,244 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * DRM driver for display panels with configuration preset and
> > needs only
> > + * standard MIPI DCS commands to bring up.
> > + *
> > + * Copyright (C) 2021 Sipeed
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> > +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> > +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> > +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> > +
> > +struct simple_dbi_cfg {
> > + const struct drm_display_mode mode;
> > + unsigned int left_offset;
> > + unsigned int top_offset;
> > + bool inverted;
> > + bool write_only;
> > + bool bgr;
> > + bool right_to_left;
> > + bool bottom_to_top;
> > +};
> > +
> > +struct simple_dbi_priv {
> > + struct mipi_dbi_dev dbidev; /* Must be first for
> > .release() */
>
> Which release?
Ah, some copy-n-paste waste.
Will drop this in v2.
>
> > + const struct simple_dbi_cfg *cfg;
> > +};
> > +
> > +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> > *pipe,
> > + struct drm_crtc_state *crtc_state,
> > + struct drm_plane_state
> > *plane_state)
> > +{
> > + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> > >crtc.dev);
> > + struct simple_dbi_priv *priv = container_of(dbidev,
> > + struct
> > simple_dbi_priv,
> > + dbidev);
> > +
Re: [PATCH 3/4] drm/tiny: add simple-dbi driver
在 2021-08-02星期一的 14:35 +0800，Icenowy Zheng写道：
> Add a driver for generic MIPI DBI panels initialized with MIPI DCS
> commands.
>
> Currently a ST7789V-based panel is added to it. This panel has its
> configuration pre-programmed into the controller, so no vendor-
> specific
> configuration is needed.
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/gpu/drm/tiny/Kconfig | 12 ++
> drivers/gpu/drm/tiny/Makefile | 1 +
> drivers/gpu/drm/tiny/simple-dbi.c | 244
> ++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
>
> diff --git a/drivers/gpu/drm/tiny/Kconfig
> b/drivers/gpu/drm/tiny/Kconfig
> index d31be274a2bd..6cfc57b68a46 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -144,6 +144,18 @@ config TINYDRM_REPAPER
>
> If M is selected the module will be called repaper.
>
> +config TINYDRM_SIMPLE_DBI
> + tristate "DRM support for generic MIPI DBI panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + help
> + DRM driver for generic DBI panels that are MIPI DCS
> compatible
> + and needs no vendor-specific setup commands.
> +
> + If M is selected the module will be called simple-dbi.
> +
> config TINYDRM_ST7586
> tristate "DRM support for Sitronix ST7586 display panels"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile
> b/drivers/gpu/drm/tiny/Makefile
> index e09942895c77..2553de651aa3 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+=
> mi0283qt.o
> obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
> obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
> +obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
> diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
> b/drivers/gpu/drm/tiny/simple-dbi.c
> new file mode 100644
> index ..2b207e43d500
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/simple-dbi.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for display panels with configuration preset and needs
> only
> + * standard MIPI DCS commands to bring up.
> + *
> + * Copyright (C) 2021 Sipeed
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
> +#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
> +#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
> +#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
> +
> +struct simple_dbi_cfg {
> + const struct drm_display_mode mode;
> + unsigned int left_offset;
> + unsigned int top_offset;
> + bool inverted;
> + bool write_only;
> + bool bgr;
> + bool right_to_left;
> + bool bottom_to_top;
> +};
> +
> +struct simple_dbi_priv {
> + struct mipi_dbi_dev dbidev; /* Must be first for
> .release() */
> + const struct simple_dbi_cfg *cfg;
> +};
> +
> +static void simple_dbi_pipe_enable(struct drm_simple_display_pipe
> *pipe,
> + struct drm_crtc_state *crtc_state,
> + struct drm_plane_state *plane_state)
> +{
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe-
> >crtc.dev);
> + struct simple_dbi_priv *priv = container_of(dbidev,
> + struct
> simple_dbi_priv,
> + dbidev);
> + struct mipi_dbi *dbi = >dbi;
> + int ret, idx;
> + u8 addr_mode = 0x00;
> +
> + if (!drm_dev_enter(pipe->crtc.dev, ))
> + return;
> +
> + DRM_DEBUG_KMS("\n");
> +
> + ret = mipi_dbi_poweron_reset(dbidev);
> + if (ret)
> + goto out_exit;
> +
> + mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
> + msleep(5);
> +
> + /* Currently tinydrm supports 16bit only now */
> + mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
> + MIPI_DCS_PIXEL_FMT_16BIT);
> +
> + if (priv->cfg->inverted)
> + mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE)
[PATCH 4/4] MAINTAINERS: add simple-dbi driver
As I pushed the simple-dbi driver, add myself as the maintainer now. Signed-off-by: Icenowy Zheng --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3a00771b9fe2..e05c4910c062 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5803,6 +5803,13 @@ S: Maintained F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c +DRM DRIVER FOR GENERIC MIPI-DBI LCD PANELS +M: Icenowy Zheng +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/simple-dbi.yaml +F: drivers/gpu/drm/tiny/simple-dbi.c + DRM DRIVER FOR GENERIC USB DISPLAY M: Noralf Trønnes S: Maintained -- 2.30.2
[PATCH 2/4] dt-bindings: display: add binding for simple-dbi panels
As we're going to introduce a driver for MIPI DBI panels that need only
standard MIPI-DCS commands to initialize (usually because the controller
has some configuration pre-programmed), add a DT binding file for it,
which now includes only one DBI Type C Option 3 panel, ZSX154-B1206.
Signed-off-by: Icenowy Zheng
---
.../bindings/display/simple-dbi.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml
diff --git a/Documentation/devicetree/bindings/display/simple-dbi.yaml
b/Documentation/devicetree/bindings/display/simple-dbi.yaml
new file mode 100644
index ..f49b0fda0935
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/simple-dbi.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/simple-dbi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MIPI DCS-compatible DBI panels Device Tree Bindings
+
+maintainers:
+ - Icenowy Zheng
+
+description:
+ This binding is for display panels that utilizes MIPI DBI Type C, follows
+ MIPI DCS and needs no vendor-specific initialization commands.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ Zhishengxin ZSX154-B1206 1.54" 240x240 SPI LCD
+items:
+ - const: zsx,zsx154-b1206
+
+ spi-max-frequency:
+maximum: 3000
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+ - if:
+ properties:
+compatible:
+ contains:
+const: zsx,zsx154-b1206
+
+then:
+ required:
+- dc-gpios
+- reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0 {
+compatible = "zsx,zsx154-b1206";
+reg = <0>;
+spi-max-frequency = <3000>;
+dc-gpios = < 7 4 GPIO_ACTIVE_HIGH>;
+reset-gpios = <_pio 2 21 GPIO_ACTIVE_HIGH>;
+};
+};
+
+...
--
2.30.2
[PATCH 1/4] dt-bindings: vendor-prefixes: add Zhishengxin
Shenzhen Zhishengxin Technology Co., Ltd. is a LCD module supplier. Add vendor prefix for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 62cb1d9341f5..d8fdec851f38 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1334,6 +1334,8 @@ patternProperties: description: Zinitix Co., Ltd "^zkmagic,.*": description: Shenzhen Zkmagic Technology Co., Ltd. + "^zsx,.*": +description: Shenzhen Zhishengxin Technology Co., Ltd. "^zte,.*": description: ZTE Corp. "^zyxel,.*": -- 2.30.2
[PATCH 0/4] Add simple-dbi tinydrm driver
This patchset adds a tinydrm driver called simple-dbi, which is a driver that utilizes only standardized commands in MIPI DCS to activate a MIPI DBI panel that requires no extra configuration, usually because the configuration is pre-programmed into the OTP of the LCD controller. Icenowy Zheng (4): dt-bindings: vendor-prefixes: add Zhishengxin dt-bindings: display: add binding for simple-dbi panels drm/tiny: add simple-dbi driver MAINTAINERS: add simple-dbi driver .../bindings/display/simple-dbi.yaml | 72 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/tiny/Kconfig | 12 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/simple-dbi.c | 244 ++ 6 files changed, 338 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/simple-dbi.yaml create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c -- 2.30.2
[PATCH 3/4] drm/tiny: add simple-dbi driver
Add a driver for generic MIPI DBI panels initialized with MIPI DCS
commands.
Currently a ST7789V-based panel is added to it. This panel has its
configuration pre-programmed into the controller, so no vendor-specific
configuration is needed.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/tiny/Kconfig | 12 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/simple-dbi.c | 244 ++
3 files changed, 257 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/simple-dbi.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d31be274a2bd..6cfc57b68a46 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -144,6 +144,18 @@ config TINYDRM_REPAPER
If M is selected the module will be called repaper.
+config TINYDRM_SIMPLE_DBI
+ tristate "DRM support for generic MIPI DBI panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ help
+ DRM driver for generic DBI panels that are MIPI DCS compatible
+ and needs no vendor-specific setup commands.
+
+ If M is selected the module will be called simple-dbi.
+
config TINYDRM_ST7586
tristate "DRM support for Sitronix ST7586 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index e09942895c77..2553de651aa3 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
obj-$(CONFIG_TINYDRM_ST7735R) += st7735r.o
+obj-$(CONFIG_TINYDRM_SIMPLE_DBI) += simple-dbi.o
diff --git a/drivers/gpu/drm/tiny/simple-dbi.c
b/drivers/gpu/drm/tiny/simple-dbi.c
new file mode 100644
index ..2b207e43d500
--- /dev/null
+++ b/drivers/gpu/drm/tiny/simple-dbi.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for display panels with configuration preset and needs only
+ * standard MIPI DCS commands to bring up.
+ *
+ * Copyright (C) 2021 Sipeed
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MIPI_DCS_ADDRESS_MODE_BGR BIT(3)
+#define MIPI_DCS_ADDRESS_MODE_REVERSE BIT(5)
+#define MIPI_DCS_ADDRESS_MODE_RTL BIT(6)
+#define MIPI_DCS_ADDRESS_MODE_BTT BIT(7)
+
+struct simple_dbi_cfg {
+ const struct drm_display_mode mode;
+ unsigned int left_offset;
+ unsigned int top_offset;
+ bool inverted;
+ bool write_only;
+ bool bgr;
+ bool right_to_left;
+ bool bottom_to_top;
+};
+
+struct simple_dbi_priv {
+ struct mipi_dbi_dev dbidev; /* Must be first for .release() */
+ const struct simple_dbi_cfg *cfg;
+};
+
+static void simple_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct simple_dbi_priv *priv = container_of(dbidev,
+ struct simple_dbi_priv,
+ dbidev);
+ struct mipi_dbi *dbi = >dbi;
+ int ret, idx;
+ u8 addr_mode = 0x00;
+
+ if (!drm_dev_enter(pipe->crtc.dev, ))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_reset(dbidev);
+ if (ret)
+ goto out_exit;
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(5);
+
+ /* Currently tinydrm supports 16bit only now */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+
+ if (priv->cfg->inverted)
+ mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE);
+ else
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_INVERT_MODE);
+
+ if (priv->cfg->bgr)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BGR;
+
+ if (priv->cfg->right_to_left)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_RTL;
+
+ if (priv->cfg->bottom_to_top)
+ addr_mode |= MIPI_DCS_ADDRESS_MODE_BTT;
+
+ switch (dbidev->rotation) {
+ default:
+ break;
+ case 90:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_REVERSE;
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ break;
+ case 180:
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_RTL;
+ addr_mode ^= MIPI_DCS_ADDRESS_MODE_BTT;
+ b
[PATCH] drm/rockchip: kick firmware-based framebuffer when initializing
Since U-Boot now supports EFI and FB passing via EFI GOP, when booting rockchip SoCs via EFI, a EFI FB is available. However, currently when re-initializing display pipeline, the EFI FB is not removed, lead to fbcon not working (because the EFI FB is no longer bound to the display pipeline although it's still /dev/fb0 and fbcon is bound to it). Add some code for removing firmware-based FB when initializing KMS of rockchipdrm. Tested on Pinebook Pro (RK3399) with U-Boot patchset for initializing eDP display applied. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 212bd87c0c4a..3905fce6ce0b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -158,6 +158,9 @@ static int rockchip_drm_bind(struct device *dev) */ drm_dev->irq_enabled = true; + /* Remove early framebuffers (ie. efifb) */ + drm_fb_helper_remove_conflicting_framebuffers(NULL, "rockchipdrmfb", false); + ret = rockchip_drm_fbdev_init(drm_dev); if (ret) goto err_unbind_all; -- 2.30.2
Re: [PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
于 2021年1月6日 GMT+08:00 下午5:47:20, Jagan Teki 写到:
>On Sat, Nov 28, 2020 at 6:23 PM Icenowy Zheng wrote:
>>
>> Attaching the panel can fail, so cleanup work is necessary, otherwise
>> a pointer to freed struct drm_panel* will remain in drm_panel code.
>>
>> Do the cleanup if panel attaching failed.
>>
>> Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D
>MIPI-DSI LCD panel")
>
>The fact that this has failed to probe due to recent changes in
>sun6i_mipi_dsi.c I don't know how to put that into the commit message.
It's not related, we shouldn't assume this panel driver will always
be used with sunxi SoCs.
It's a panel driver bug that cannot deal with -EPROBE_DEFER well.
>> Signed-off-by: Icenowy Zheng
>> ---
>
>Reviewed-by: Jagan Teki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: ilitek-ili9881c: fix attach failure cleanup
When mipi_dsi_attach() fails (e.g. got a -EPROBE_DEFER), the panel should
be removed, otherwise a pointer to it will be kept and then lead to
use-after-free when DRM panel codes are called (e.g. the panel is probed
again).
Fix this by adding cleanup code after mipi_dsi_attach() failure.
Fixes: 26aec25593c2 ("drm/panel: Add Ilitek ILI9881c panel driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0145129d7c66..22f2268f00f7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -674,7 +674,13 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(>panel);
+ return ret;
+ }
+
+ return 0;
}
static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
Attaching the panel can fail, so cleanup work is necessary, otherwise
a pointer to freed struct drm_panel* will remain in drm_panel code.
Do the cleanup if panel attaching failed.
Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD
panel")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(>panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02
Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel (which is already supported by panel-feixin-k101-im2ba02 driver) with the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its compatible string should be added to ilitek,ili9881c file. Add the compatible string for it. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index a39332276bab2..c60b3bd74337e 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - bananapi,lhr050h41 +- feixin,k101-im2byl02 - const: ilitek,ili9881c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/panel: ilitek-ili9881c: prepare for adding support for extra panels
There're more panels with ILI9881C controller than the Bananapi one
supported by this driver.
Extract the mode and init sequence part, to prepare the driver for
adding new panels.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 56 ---
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ed8635a6fbdf..4f8e6865029f1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -20,14 +21,6 @@
#include
-struct ili9881c {
- struct drm_panelpanel;
- struct mipi_dsi_device *dsi;
-
- struct regulator*power;
- struct gpio_desc*reset;
-};
-
enum ili9881c_op {
ILI9881C_SWITCH_PAGE,
ILI9881C_COMMAND,
@@ -45,6 +38,21 @@ struct ili9881c_instr {
} arg;
};
+struct ili9881c_desc {
+ const struct ili9881c_instr *init;
+ const size_t init_length;
+ const struct drm_display_mode *mode;
+};
+
+struct ili9881c {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct ili9881c_desc *desc;
+
+ struct regulator*power;
+ struct gpio_desc*reset;
+};
+
#define ILI9881C_SWITCH_PAGE_INSTR(_page) \
{ \
.op = ILI9881C_SWITCH_PAGE, \
@@ -64,7 +72,7 @@ struct ili9881c_instr {
}, \
}
-static const struct ili9881c_instr ili9881c_init[] = {
+static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(3),
ILI9881C_COMMAND_INSTR(0x01, 0x00),
ILI9881C_COMMAND_INSTR(0x02, 0x00),
@@ -311,8 +319,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
gpiod_set_value(ctx->reset, 0);
msleep(20);
- for (i = 0; i < ARRAY_SIZE(ili9881c_init); i++) {
- const struct ili9881c_instr *instr = _init[i];
+ for (i = 0; i < ctx->desc->init_length; i++) {
+ const struct ili9881c_instr *instr = >desc->init[i];
if (instr->op == ILI9881C_SWITCH_PAGE)
ret = ili9881c_switch_page(ctx, instr->arg.page);
@@ -368,7 +376,7 @@ static int ili9881c_unprepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode bananapi_default_mode = {
+static const struct drm_display_mode lhr050h41_default_mode = {
.clock = 62000,
.hdisplay = 720,
@@ -380,6 +388,9 @@ static const struct drm_display_mode bananapi_default_mode
= {
.vsync_start= 1280 + 10,
.vsync_end = 1280 + 10 + 10,
.vtotal = 1280 + 10 + 10 + 20,
+
+ .width_mm = 62,
+ .height_mm = 110,
};
static int ili9881c_get_modes(struct drm_panel *panel,
@@ -388,12 +399,12 @@ static int ili9881c_get_modes(struct drm_panel *panel,
struct ili9881c *ctx = panel_to_ili9881c(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _default_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
if (!mode) {
dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
- bananapi_default_mode.hdisplay,
- bananapi_default_mode.vdisplay,
- drm_mode_vrefresh(_default_mode));
+ ctx->desc->mode->hdisplay,
+ ctx->desc->mode->vdisplay,
+ drm_mode_vrefresh(ctx->desc->mode));
return -ENOMEM;
}
@@ -402,8 +413,8 @@ static int ili9881c_get_modes(struct drm_panel *panel,
mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
- connector->display_info.width_mm = 62;
- connector->display_info.height_mm = 110;
+ connector->display_info.width_mm = mode->width_mm;
+ connector->display_info.height_mm = mode->height_mm;
return 1;
}
@@ -426,6 +437,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dsi = dsi;
+ ctx->desc = of_device_get_match_data(>dev);
drm_panel_init(>panel, >dev, _funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -467,8 +479,14 @@ static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
return 0;
}
+static const struct ili9881c_desc lhr050h41_desc = {
+ .init = lhr050h41_init,
+ .init_length = ARRAY_SIZE(lhr050h41_init),
+ .mode = _default_mode,
+};
+
static cons
[PATCH 3/4] drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel
Feixin K101-IM2BYL02 is a new panel by Feixin designed as a replacement
to their K101-IM2BA02 panel. This panel utilizes the Ilitek ILI9881C
controller.
Add this panel's initialzation sequence and timing to ILI9881C driver.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 217 ++
1 file changed, 217 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 4f8e6865029f1..638108c519f02 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -260,6 +260,199 @@ static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_COMMAND_INSTR(0xD3, 0x3F),
};
+static const struct ili9881c_instr k101_im2byl02_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x00),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x08),
+ ILI9881C_COMMAND_INSTR(0x07, 0x00),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0A, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0B, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0D, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0E, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x10, 0x00),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1E, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1F, 0xC0),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x06),
+ ILI9881C_COMMAND_INSTR(0x23, 0x01),
+ ILI9881C_COMMAND_INSTR(0x24, 0x88),
+ ILI9881C_COMMAND_INSTR(0x25, 0x88),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x3B),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x00), /* GPWR1/2 non overlap time 2.62us
*/
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x00),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+ ILI9881C_COMMAND_INSTR(0x50, 0x01),
+ ILI9881C_COMMAND_INSTR(0x51, 0x23),
+ ILI9881C_COMMAND_INSTR(0x52, 0x45),
+ ILI9881C_COMMAND_INSTR(0x53, 0x67),
+ ILI9881C_COMMAND_INSTR(0x54, 0x89),
+ ILI9881C_COMMAND_INSTR(0x55, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x56, 0x01),
+ ILI9881C_COMMAND_INSTR(0x57, 0x23),
+ ILI9881C_COMMAND_INSTR(0x58, 0x45),
+ ILI9881C_COMMAND_INSTR(0x59, 0x67),
+ ILI9881C_COMMAND_INSTR(0x5A, 0x89),
+ ILI9881C_COMMAND_INSTR(0x5B, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x5C, 0xCD),
+ ILI9881C_COMMAND_INSTR(0x5D, 0xEF),
+ ILI9881C_COMMAND_INSTR(0x5E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x5F, 0x01),
+ ILI9881C_COMMAND_INSTR(0x60, 0x01),
+ ILI9881C_COMMAND_INSTR(0x61, 0x06),
+ ILI9881C_COMMAND_INSTR(0x62, 0x06),
+ ILI9881C_COMMAND_INSTR(0x63, 0x07),
+ ILI9881C_COMMAND_INSTR(0x64, 0x07),
+ ILI9881C_COMMAND_INSTR(0x65, 0x00),
+ ILI9881C_COMMAND_INSTR(0x66, 0x00),
+ ILI9881C_COMMAND_INSTR(0x67, 0x02),
+ ILI9881C_COMMAND_INSTR(0x68, 0x02
[PATCH 0/4] Add support for Feixin K101-IM2BYL02 panel
The controller chip of Feixin K101-IM2BA02 is going to be discontinued, so Feixin start to provide K101-IM2BYL02 panel as a replacement, which utilizes Ilitek ILI9881C controller. Add support for K101-IM2BYL02 panel. By the way, is there a way that can try both kind of panels in the same kernel/DTB combo? K101-IM2BYL02 has the same pinout with K101-IM2BA02, and PineTab schedule to switch to it w/o modifying the mainboard. Icenowy Zheng (4): drm/panel: ilitek-ili9881c: prepare for adding support for extra panels dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02 drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab .../display/panel/ilitek,ili9881c.yaml| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 + drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 273 -- 3 files changed, 265 insertions(+), 19 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab
Newer PineTab may switch to K101-IM2BYL02.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index dc4ab6b434f97..15c4f5b5b17a7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -152,6 +152,7 @@ {
vcc-dsi-supply = <_dldo1>;
status = "okay";
+#if 0
panel@0 {
compatible = "feixin,k101-im2ba02";
reg = <0>;
@@ -161,6 +162,15 @@ panel@0 {
reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
backlight = <>;
};
+#endif
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <_dc1sw>;
+ reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <>;
+ };
};
{
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 13/13] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
于 2020年7月1日 GMT+08:00 下午6:31:26, Ondrej Jirman 写到:
>Pinephone has a Goodix GT917S capacitive touchscreen controller on
>I2C0 bus. Add support for it.
>
>Signed-off-by: Ondrej Jirman
>Acked-by: Linus Walleij
>---
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>index 85a7aa5efd32..2d5694446d17 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>@@ -123,6 +123,25 @@ {
> status = "okay";
> };
>
>+ {
>+ pinctrl-names = "default";
>+ pinctrl-0 = <_pins>;
>+ status = "okay";
>+
>+ touchscreen@5d {
>+ compatible = "goodix,gt917s", "goodix,gt911";
Please drop gt911 here. GT917S belong to the GT1x product line, not the same
line with GT911.
You will see this in the driver.
>+ reg = <0x5d>;
>+ interrupt-parent = <>;
>+ interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
>+ irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>+ reset-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
>+ AVDD28-supply = <_ldo_io0>;
>+ VDDIO-supply = <_ldo_io0>;
>+ touchscreen-size-x = <720>;
>+ touchscreen-size-y = <1440>;
>+ };
>+};
>+
> {
> status = "okay";
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
于 2020年3月20日 GMT+08:00 下午5:11:22, Linus Walleij 写到: >On Fri, Mar 20, 2020 at 9:07 AM Icenowy Zheng wrote: >> 于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij > 写到: >> >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng >wrote: > >> >As noticed in the review of the driver, this display is very close >to >> >himax,hx8363. >> > >> >I think the best is to determin what actual display controller it >is, >> >I think it is some kind of Ilitek controller since Ilitek ili9342 is >> >clearly very similar. >> >> It's Sitronix ST7703, same as the Librem 5 panel. > >Heh, I wonder how it comes that it is so similar to Ilitek. >I guess I will never understand how the silicon ecosystem works >in asia (I did read a lot of Bunnie Huang's articles and hardware >hacking book to try to understand...) > >This file should be named sitronix,st7703.yaml then. > >According to the code in the Librem 5: >https://source.puri.sm/Librem5/linux-next/blob/imx8-current-librem5/drivers/gpu/drm/panel/panel-sitronix-st7701.c >The actual name of the display is Techstar ts8550b. Sorry, for Librem 5 panel, I mean Rocktech JH057N00900 here. This is also the code that my patchset based on. >And the display controller is st7701, so maybe we should >actually name it sitronix,st770x.yaml if there are some >sub-variants of st770x? > >> >properties: >> > compatible: >> >items: >> > - const: xingbangda,xbd599 >> > - const: ilitek,ili9342 >> > >> >Possibly use oneOf and add support for the himax,hx8363 >> >already while you're at it. > >This should at least be: > >compatible: > items: > - enum: > - xingbangda,xbd599 > - himax,hx8363 > - techstar,ts8550b > - enum: > - sitronix,st7701 > - sitronix,st7703 > >So panel nodes using this panel become >compatible = "xingbangda,sbd599", "sitronix,st7703" >etc. > >This way it is straight-forward for drivers to identify the panel >vendor and display controller. > >Yours, >Linus Walleij > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij 写到: >Hi Icenowy, > >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng wrote: > >> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. >> >> Add its device tree binding. >> >> Signed-off-by: Icenowy Zheng >(...) > >> +properties: >> + compatible: >> +const: xingbangda,xbd599 > >As noticed in the review of the driver, this display is very close to >himax,hx8363. > >I think the best is to determin what actual display controller it is, >I think it is some kind of Ilitek controller since Ilitek ili9342 is >clearly very similar. It's Sitronix ST7703, same as the Librem 5 panel. > >The best would be something like name the bindings >ilitek-ili9342.yaml and then: > >properties: > compatible: >items: > - const: xingbangda,xbd599 > - const: ilitek,ili9342 > >Possibly use oneOf and add support for the himax,hx8363 >already while you're at it. > >Yours, >Linus Walleij > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Add its device nodes.
>
> Signed-off-by: Icenowy Zheng
> ---
> No changes in v2.
>
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index cefda145c3c9..96d9150423e0 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -16,6 +16,15 @@ aliases {
> serial0 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> 46 51 56 62 68 75 83 91 100>;
Should I drop the 0 here and replace it with 14?
I have heard community complaining about setting 0 to brightness make
the screen black.
(I think in this situation bl_power or blank the DSI panel can still
totally shut down the backlight).
> + default-brightness-level = <15>;
> + enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + power-supply = <_ldo_io0>;
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +93,30 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-dsi-supply = <_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + panel@0 {
> + compatible = "xingbangda,xbd599";
> + reg = <0>;
> + reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> + iovcc-supply = <_dldo2>;
> + vcc-supply = <_ldo_io0>;
> + backlight = <>;
> + };
> +};
> +
> {
> status = "okay";
> };
> @@ -188,6 +221,10 @@ _pio {
>*/
> };
>
> +_pwm {
> + status = "okay";
> +};
> +
> _rsb {
> status = "okay";
>
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <_dldo2>;
+ vcc-supply = <_ldo_io0>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -188,6 +221,10 @@ _pio {
*/
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++
3 files changed, 376 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index a1723c1b5fbf..cf0c59015a44 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -433,6 +433,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 96a883cd6630..c84ed5215984 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..8d56b6579111
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02,
[PATCH v2 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 366 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 470 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- No changes in v2. drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- No changes in v2. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 23ca95bee298..0d9e966eff19 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1106,6 +1106,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Example fix.
- Format fix.
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..b27bcf11198f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+description: regulator that supplies the VCC voltage
+ iovcc-supply:
+description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_dldo2>;
+vcc-supply = <_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
于 2020年3月14日 GMT+08:00 下午4:00:00, Sam Ravnborg 写到:
>Hi Icenowy
>
>A few details in the following.
>
> Sam
>
>On Thu, Mar 12, 2020 at 12:33:27AM +0800, Icenowy Zheng wrote:
>> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
>> Xingbangda, which is used on PinePhone final assembled phones.
>>
>> Add support for it.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/panel/Kconfig | 9 +
>> drivers/gpu/drm/panel/Makefile| 1 +
>> .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367
>++
>> 3 files changed, 377 insertions(+)
>> create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>>
>> +++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
>> @@ -0,0 +1,367 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Xingbangda XBD599 MIPI-DSI panel driver
>> + *
>> + * Copyright (C) 2019 Icenowy Zheng
>2020?
The work started at Mid 2019.
Is 2019-2020 okay?
>
>> + *
>> + * Based on panel-rocktech-jh057n00900.c, which is:
>> + * Copyright (C) Purism SPC 2019
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>Sort alphabetically.
>
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRV_NAME "panel-xingbangda-xbd599"
>No reason for this indirection, it is only used once
>
>> +
>> +/* Manufacturer specific Commands send via DSI */
>> +#define ST7703_CMD_ALL_PIXEL_OFF 0x22
>> +#define ST7703_CMD_ALL_PIXEL_ON 0x23
>> +#define ST7703_CMD_SETDISP 0xB2
>> +#define ST7703_CMD_SETRGBIF 0xB3
>> +#define ST7703_CMD_SETCYC0xB4
>> +#define ST7703_CMD_SETBGP0xB5
>> +#define ST7703_CMD_SETVCOM 0xB6
>> +#define ST7703_CMD_SETOTP0xB7
>> +#define ST7703_CMD_SETPOWER_EXT 0xB8
>> +#define ST7703_CMD_SETEXTC 0xB9
>> +#define ST7703_CMD_SETMIPI 0xBA
>> +#define ST7703_CMD_SETVDC0xBC
>> +#define ST7703_CMD_SETSCR0xC0
>> +#define ST7703_CMD_SETPOWER 0xC1
>> +#define ST7703_CMD_UNK_C60xC6
>> +#define ST7703_CMD_SETPANEL 0xCC
>> +#define ST7703_CMD_SETGAMMA 0xE0
>> +#define ST7703_CMD_SETEQ 0xE3
>> +#define ST7703_CMD_SETGIP1 0xE9
>> +#define ST7703_CMD_SETGIP2 0xEA
>> +
>> +static const char * const regulator_names[] = {
>> +"iovcc",
>> +"vcc",
>> +};
>> +
>> +struct xbd599 {
>> +struct device *dev;
>> +struct drm_panel panel;
>> +struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
>> +bool prepared;
>> +};
>> +
>> +static inline struct xbd599 *panel_to_xbd599(struct drm_panel
>*panel)
>> +{
>> +return container_of(panel, struct xbd599, panel);
>> +}
>> +
>> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do {\
>> +static const u8 d[] = { seq }; \
>> +int ret;\
>> +ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
>> +if (ret < 0)\
>> +return ret; \
>> +} while (0)
>> +
>> +static int xbd599_init_sequence(struct xbd599 *ctx)
>> +{
>> +struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>> +struct device *dev = ctx->dev;
>> +int ret;
>> +
>> +/*
>> + * Init sequence was supplied by the panel vendor.
>> + */
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
>> + 0xF1, 0x12, 0x83);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
>> + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
>> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
>> + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
>> + 0x00, 0x00, 0x37);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
>> + 0x25, 0x22, 0x20, 0x03);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
>> + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00,
>> + 0x00, 0x00);
>> +dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
>> + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70,
>&g
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index cefda145c3c9..96d9150423e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -16,6 +16,15 @@ aliases {
serial0 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ power-supply = <_ldo_io0>;
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -84,6 +93,30 @@ {
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "xingbangda,xbd599";
+ reg = <0>;
+ reset-gpios = < 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
+ iovcc-supply = <_dldo2>;
+ vcc-supply = <_ldo_io0>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -188,6 +221,10 @@ _pio {
*/
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation
The max() function call in horizontal timing calculation shouldn't pad a length already subtracted with overhead to overhead, instead it should only prevent the set timing to underflow. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 059939789730..5f2313c40328 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -555,7 +555,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HSA_PACKET_OVERHEAD10 hsa = max((unsigned int)HSA_PACKET_OVERHEAD, - (mode->hsync_end - mode->hsync_start) * Bpp - HSA_PACKET_OVERHEAD); + (mode->hsync_end - mode->hsync_start) * Bpp) - HSA_PACKET_OVERHEAD; /* * The backporch is set using a blanking packet (4 @@ -564,7 +564,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBP_PACKET_OVERHEAD6 hbp = max((unsigned int)HBP_PACKET_OVERHEAD, - (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); + (mode->htotal - mode->hsync_end) * Bpp) - HBP_PACKET_OVERHEAD; /* * The frontporch is set using a sync event (4 bytes) @@ -574,7 +574,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, - (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); + (mode->hsync_start - mode->hdisplay) * Bpp) - HFP_PACKET_OVERHEAD; /* * The blanking is set using a sync event (4 bytes) @@ -583,8 +583,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, */ #define HBLK_PACKET_OVERHEAD 10 hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, - (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp - - HBLK_PACKET_OVERHEAD); + (mode->htotal - (mode->hsync_end - mode->hsync_start)) * Bpp) - + HBLK_PACKET_OVERHEAD; /* * And I'm not entirely sure what vblk is about. The driver in -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add support for PinePhone LCD panel
This patchset adds support for the LCD panel of PinePhone. The first 3 patches are for the panel itself, and the last 2 patches are for enabling it on PinePhone. PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered on XBD599. Icenowy Zheng (5): dt-bindings: vendor-prefixes: Add Xingbangda dt-bindings: panel: add binding for Xingbangda XBD599 panel drm: panel: add Xingbangda XBD599 panel drm/sun4i: sun6i_mipi_dsi: fix horizontal timing calculation arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone .../display/panel/xingbangda,xbd599.yaml | 50 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 10 +- 7 files changed, 471 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: panel: add Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-xingbangda-xbd599.c | 367 ++
3 files changed, 377 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index da3b84602cdd..d648f40469c7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -413,6 +413,15 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
DSI
Video Mode panel
+config DRM_PANEL_XINGBANGDA_XBD599
+ tristate "Xingbangda XBD599 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Xingbangda XBD599
+ MIPI DSI Video Mode panel.
+
config DRM_PANEL_XINPENG_XPP055C272
tristate "Xinpeng XPP055C272 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index af1e2a3cc5fc..d9645f079e59 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,4 +44,5 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) +=
panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_XINGBANGDA_XBD599) += panel-xingbangda-xbd599.o
obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
new file mode 100644
index ..68a5d8bb7f26
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-xingbangda-xbd599.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xingbangda XBD599 MIPI-DSI panel driver
+ *
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ * Based on panel-rocktech-jh057n00900.c, which is:
+ * Copyright (C) Purism SPC 2019
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-xingbangda-xbd599"
+
+/* Manufacturer specific Commands send via DSI */
+#define ST7703_CMD_ALL_PIXEL_OFF 0x22
+#define ST7703_CMD_ALL_PIXEL_ON 0x23
+#define ST7703_CMD_SETDISP 0xB2
+#define ST7703_CMD_SETRGBIF 0xB3
+#define ST7703_CMD_SETCYC 0xB4
+#define ST7703_CMD_SETBGP 0xB5
+#define ST7703_CMD_SETVCOM 0xB6
+#define ST7703_CMD_SETOTP 0xB7
+#define ST7703_CMD_SETPOWER_EXT 0xB8
+#define ST7703_CMD_SETEXTC 0xB9
+#define ST7703_CMD_SETMIPI 0xBA
+#define ST7703_CMD_SETVDC 0xBC
+#define ST7703_CMD_SETSCR 0xC0
+#define ST7703_CMD_SETPOWER 0xC1
+#define ST7703_CMD_UNK_C6 0xC6
+#define ST7703_CMD_SETPANEL 0xCC
+#define ST7703_CMD_SETGAMMA 0xE0
+#define ST7703_CMD_SETEQ0xE3
+#define ST7703_CMD_SETGIP1 0xE9
+#define ST7703_CMD_SETGIP2 0xEA
+
+static const char * const regulator_names[] = {
+ "iovcc",
+ "vcc",
+};
+
+struct xbd599 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ bool prepared;
+};
+
+static inline struct xbd599 *panel_to_xbd599(struct drm_panel *panel)
+{
+ return container_of(panel, struct xbd599, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int xbd599_init_sequence(struct xbd599 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+ int ret;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC,
+ 0xF1, 0x12, 0x83);
+ dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
+ 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25,
+ 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11,
+ 0x00, 0x0
[PATCH 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
new file mode 100644
index ..62816b34de31
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/xingbangda,xbd599.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/xingbangda,xbd599.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xingbangda XBD599 5.99in MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: xingbangda,xbd599
+ reg: true
+ backlight: true
+ reset-gpios: true
+ vcc-supply:
+ description: regulator that supplies the VCC voltage
+ iovcc-supply:
+ description: regulator that supplies the IOVCC voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - vcc-supply
+ - iovcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "xingbangda,xbd599";
+reg = <0>;
+backlight = <>;
+iovcc-supply = <_dldo2>;
+vcc-supply = <_ldo_io0>;
+};
+};
+
+...
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefixes: Add Xingbangda
Shenzhen Xingbangda Display Technology Co., Ltd is a company which produces LCD modules. It supplies the LCD panels of the PinePhone series (the developers' kit and the final phone). Add the vendor prefix of it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b8e9ef79cab9..038a2180d34b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1102,6 +1102,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": +description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道： > Hi Ondrej, > > On 5/3/20 20:35, Ondřej Jirman wrote: > > Hi, > > > > On Thu, Mar 05, 2020 at 10:29:33AM -0800, Vasily Khoruzhick wrote: > > > On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > > > wrote: > > > > Hi Vasily, > > > > > > CC: Icenowy and Ondrej > > > > Would you mind to check which firmware version is running the > > > > anx7688 in > > > > PinePhone, I think should be easy to check with i2c-tools. > > > > > > Icenowy, Ondrej, can you guys please check anx7688 firmware > > > version? > > > > i2cget 0 0x28 0x00 w > > 0x > > > > i2cget 0 0x28 0x02 w > > 0x7688 > > > > i2cget 0 0x28 0x80 w > > 0x > > > > Can you check the value for 0x81 too? root@ice-pinephone [ ~ ] # i2cdump 0 0x28 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x28, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: aa aa 88 76 ac 00 00 00 00 00 00 00 00 00 05 05???v?.?? 10: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000... 20: 00 00 00 00 00 00 00 00 00 00 00 24 f2 e4 ff 00...$??.. 30: 06 40 00 04 94 11 20 ff ff 03 00 bf ff ff 10 01?@.??? ..?.?..?? 40: 72 a4 00 09 00 08 05 84 15 40 17 00 00 0a 00 e0r?.?.@?..?.? 50: 00 00 00 0a 10 00 e0 df ff ff 00 00 00 10 71 00...??.??.?q. 60: 10 10 04 29 2d 21 10 01 09 13 00 03 e8 13 88 00???)-!.. 70: 00 19 18 83 16 5c 11 00 ff 00 00 0d 04 38 42 07.\???8B? 80: 00 00 00 00 00 74 1b 19 44 08 75 00 00 00 00 00.t??D?u. 90: 01 02 00 00 00 00 03 00 ff 30 00 59 01 00 00 00???..0.Y?... a0: 00 ff fe ff ff 00 00 00 00 00 00 00 00 00 00 02..?? b0: 00 00 00 00 00 00 40 00 28 00 00 00 00 44 08 00..@.(D?. c0: 00 00 00 00 80 00 10 01 0a 10 18 00 00 fd 00 00?.?..?.. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 50 10 08 50 00 02 00 70 00 00 30 10 0b 02 1c 01P??P.?.p..0? f0: 00 0b 07 00 94 11 7f 00 00 00 00 00 00 01 0e ff.??.???..??. root@ice-pinephone [ ~ ] # i2cdump 0 0x2c No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x2c, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 29 1f 88 76 00 ac 11 00 11 20 10 10 00 00 00 00)??v.??.? ?? 10: 03 00 ff 8f ff 7f 00 00 00 00 05 00 10 0a 0c 00?..?.??.???. 20: 00 00 00 00 99 06 c0 00 00 00 00 00 00 00 02 00???...?. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00?... 80: 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00?%.. 90: 0f 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00??.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Thanks, > Enric > > > > regards, > > o. > > > > > > Thanks in advance, > > > > Enric > > > > > > > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
于 2020年3月6日 GMT+08:00 上午2:29:33, Vasily Khoruzhick 写到: >On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra > wrote: >> >> Hi Vasily, > >CC: Icenowy and Ondrej >> >> Would you mind to check which firmware version is running the anx7688 >in >> PinePhone, I think should be easy to check with i2c-tools. > >Icenowy, Ondrej, can you guys please check anx7688 firmware version? At 0x2c, 0x80 is 0x01, 0x81 is 0x25 01.25, right? > >> Thanks in advance, >> Enric >> >> [snip] -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock
于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala
写到:
>From: Ville Syrjälä
>
>The currently listed dotclock disagrees with the currently
>listed vrefresh rate. Change the dotclock to match the vrefresh.
>
>Someone tell me which (if either) of the dotclock or vreresh is
>correct?
dotclock is correct and vrefresh is only a placeholder value.
>
>Cc: Icenowy Zheng
>Cc: Sam Ravnborg
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>index fddbfddf6566..8debee85f4ec 100644
>--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
>@@ -391,7 +391,7 @@ static int k101_im2ba02_unprepare(struct drm_panel
>*panel)
> }
>
> static const struct drm_display_mode k101_im2ba02_default_mode = {
>- .clock = 7,
>+ .clock = 67286,
> .vrefresh = 60,
>
> .hdisplay = 800,
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月26日 GMT+08:00 下午6:58:43, Thomas Zimmermann 写到:
>Hi Iceynow,
>
>Torsten asked me to merge your patch via drm-misc-next. I'd add the
>additional cc and fixes tags that Torsten listed. Are you OK with that?
I think this fixes a driver (and a board) available in 5.6.
Maybe it should enter fixes?
>
>Best regards
>Thomas
>
>Am 22.02.20 um 03:43 schrieb Icenowy Zheng:
>>
>>
>> 于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>>> On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>>>> Current code tries to store the link rate (in bps, which is a big
>>>> number) in a u8, which surely overflow. Then it's converted back to
>>>> bandwidth code (which is thus 0) and written to the chip.
>>>>
>>>> The code sometimes works because the chip will automatically
>fallback
>>> to
>>>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>>> value.
>>>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>>> link,
>>>> it failed.
>>>>
>>>> As we had already read the link bandwidth as bandwidth code in
>>> earlier
>>>> code (to check whether it is supported), use it when setting
>>> bandwidth,
>>>> instead of converting it to link rate and then converting back.
>>>>
>>>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for
>v5.5")
>>>> Signed-off-by: Icenowy Zheng
>>>> ---
>>>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> index 56f55c53abfd..2dfa2fd2a23b 100644
>>>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>>>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>>> anx6345 *anx6345)
>>>>if (err)
>>>>return err;
>>>>
>>>> - dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>>>> - dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>>>> + dpcd[0] = dp_bw;
>>>
>>> Why do you make this assignment and not use dp_bw directly in the
>call?
>>
>> Because the dpcd array is then written as a continous array
>> back to DPCD.
>>
>>>
>>>>err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>>>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
>>> ^^
>>>>if (err)
>>>> --
>>>> 2.24.1
>>>
>>> BTW, my version is only a bit more verbose:
>>>
>>> https://patchwork.freedesktop.org/patch/354344/
>>>
>>> Torsten
>>
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
Current code tries to store the link rate (in bps, which is a big
number) in a u8, which surely overflow. Then it's converted back to
bandwidth code (which is thus 0) and written to the chip.
The code sometimes works because the chip will automatically fallback to
the lowest possible DP link rate (1.62Gbps) when get the invalid value.
However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps link,
it failed.
As we had already read the link bandwidth as bandwidth code in earlier
code (to check whether it is supported), use it when setting bandwidth,
instead of converting it to link rate and then converting back.
Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 56f55c53abfd..2dfa2fd2a23b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct anx6345 *anx6345)
if (err)
return err;
- dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
- dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
+ dpcd[0] = dp_bw;
err = regmap_write(anx6345->map[I2C_IDX_DPTX],
SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
if (err)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix-anx6345: fix set of link bandwidth
于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>> Current code tries to store the link rate (in bps, which is a big
>> number) in a u8, which surely overflow. Then it's converted back to
>> bandwidth code (which is thus 0) and written to the chip.
>>
>> The code sometimes works because the chip will automatically fallback
>to
>> the lowest possible DP link rate (1.62Gbps) when get the invalid
>value.
>> However, on the eDP panel of Olimex TERES-I, which wants 2.7Gbps
>link,
>> it failed.
>>
>> As we had already read the link bandwidth as bandwidth code in
>earlier
>> code (to check whether it is supported), use it when setting
>bandwidth,
>> instead of converting it to link rate and then converting back.
>>
>> Fixes: e1cff82c1097 ("drm/bridge: fix anx6345 compilation for v5.5")
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> index 56f55c53abfd..2dfa2fd2a23b 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>> @@ -210,8 +210,7 @@ static int anx6345_dp_link_training(struct
>anx6345 *anx6345)
>> if (err)
>> return err;
>>
>> -dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
>> -dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
>> +dpcd[0] = dp_bw;
>
>Why do you make this assignment and not use dp_bw directly in the call?
Because the dpcd array is then written as a continous array
back to DPCD.
>
>> err = regmap_write(anx6345->map[I2C_IDX_DPTX],
>> SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
> ^^
>> if (err)
>> --
>> 2.24.1
>
>BTW, my version is only a bit more verbose:
>
>https://patchwork.freedesktop.org/patch/354344/
>
> Torsten
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng Reviewed-by: Rob Herring --- Changes in v2: - Added Review tag by Rob. Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Set backlight property to optional. (Technically this panel requires
backlight, but theortically it can be not adjustable.)
- Tweaked the example to pass schema check.
.../display/panel/feixin,k101-im2ba02.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..be1ecce9c3c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <_dc1sw>;
+dvdd-supply = <_dc1sw>;
+cvdd-supply = <_ldo_io1>;
+reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Compared to v1 of the patchset, the accelerometer support is temporarily removed because a DT binding is lacked (although a proper driver exists). Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 55 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++ 9 files changed, 1065 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Use regulator_bulk.
- Small code fixes.
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 526 ++
4 files changed, 542 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 98cf0b034f61..2ec9ae62478a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5251,6 +5251,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..fddbfddf6566
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,526 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+static const char * const regulator_names[] = {
+ "dvdd",
+ "avdd",
+ "cvdd"
+};
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -
[PATCH v2 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng Acked-by: Sam Ravnborg Acked-by: Rob Herring --- Changes in v2: - Added ACKs from Sam and Rob. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 97c0a06b35cd..07d52254427b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -337,6 +337,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, the
front camera currently lacks a driver and a facility to share the bus
with the rear one, and the accelerometer currently lacks a DT binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Remove I2C pinmuxes.
- Dropped binding-less accelerometer.
- Used exponent curve for backlight.
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 460 ++
2 files changed, 461 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..c76c94855f43
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,460 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+#include "sun50i-a64-cpu-opp.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 =
+ ethernet0 =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42 46 51
56 62 68 75 83 91 100>;
+ default-brightness-level = <15>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-
[PATCH 3/5] drm/panel: Add Feixin K101 IM2BA02 panel
Feixin K101 IM2BA02 is a 800x1280 4-lane MIPI-DSI LCD panel.
Add a panel driver for it.
Signed-off-by: Icenowy Zheng
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++
4 files changed, 564 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 908399316455..ef7d13125344 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5218,6 +5218,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIXIN K101 IM2BA02 MIPI-DSI LCD PANELS
+M: Icenowy Zheng
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+F: Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+
DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..4641ec804e5e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -50,6 +50,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIXIN_K101_IM2BA02
+ tristate "Feixin K101 IM2BA02 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Feixin K101 IM2BA02
+ 4-lane 800x1280 MIPI DSI panel.
+
config DRM_PANEL_FEIYANG_FY07024DI26A30D
tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..442c17ccc62e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
new file mode 100644
index ..45a62bdabb3f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -0,0 +1,548 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define K101_IM2BA02_INIT_CMD_LEN 2
+
+struct k101_im2ba02 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct regulator*cvdd;
+ struct gpio_desc*reset;
+};
+
+static inline struct k101_im2ba02 *panel_to_k101_im2ba02(struct drm_panel
*panel)
+{
+ return container_of(panel, struct k101_im2ba02, panel);
+}
+
+struct k101_im2ba02_init_cmd {
+ u8 data[K101_IM2BA02_INIT_CMD_LEN];
+};
+
+static const struct k101_im2ba02_init_cmd k101_im2ba02_init_cmds[] = {
+ /* Switch to page 0 */
+ { .data = { 0xE0, 0x00 } },
+
+ /* Seems to be some password */
+ { .data = { 0xE1, 0x93} },
+ { .data = { 0xE2, 0x65 } },
+ { .data = { 0xE3, 0xF8 } },
+
+ /* Lane number, 0x02 - 3 lanes, 0x03 - 4 lanes */
+ { .data = { 0x80, 0x03 } },
+
+ /* Sequence control */
+ { .data = { 0x70, 0x02 } },
+ { .data = { 0x71, 0x23 } },
+ { .data = { 0x72, 0x06 } },
+
+ /* Switch to page 1 */
+ { .data = { 0xE0, 0x01 } },
+
+ /* Set VCOM */
+ { .data = { 0x00, 0x00 } },
+ { .data = { 0x01, 0x66 } },
+ /* Set VCOM_Reverse */
+ { .data = { 0x03, 0x00 } },
+ { .data = { 0x04, 0x25 } },
+
+ /* Set Gamma Power, VG[MS][PN] */
+ { .data = { 0x17, 0x00 } },
+ { .data = { 0x18, 0x6D } },
+ { .data = { 0x19, 0x00 } },
+ { .data = { 0x1A, 0x00 } },
+ { .data = { 0x1B, 0xBF } }, /* VGMN = -4.5V */
+ { .data = { 0x1C, 0x00 } },
+
+ /* Set Gate Power */
+ { .data = { 0x1F, 0x3E } }, /* VGH_R = 15V */
+ { .data = { 0x20, 0x28 } }, /* VGL_R = -11V */
+ { .data = { 0x21, 0x28 } }, /* VGL_R2 = -11V */
+ { .data = { 0x22, 0x0E } }, /* PA[6:4] = 0, PA[0] = 0 */
+
+ /* Set Panel */
+ { .data = { 0x37, 0x09 } }
[PATCH 0/5] Add support for Pine64 PineTab
This patchset tries to add support for the PineTab tablet from Pine64. As it uses a specific MIPI-DSI panel, the support of the panel should be introduced first, with its DT binding. Then a device tree is added. Thanks to the community's contributions these years, we now have most of the functionalities of the tablet available in this device tree. Icenowy Zheng (5): dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel drm/panel: Add Feixin K101 IM2BA02 panel dt-bindings: arm: sunxi: add binding for PineTab tablet arm64: dts: allwinner: a64: add support for PineTab .../devicetree/bindings/arm/sunxi.yaml| 5 + .../display/panel/feixin,k101-im2ba02.yaml| 54 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + arch/arm64/boot/dts/allwinner/Makefile| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 +++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-feixin-k101-im2ba02.c | 548 ++ 9 files changed, 1087 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts create mode 100644 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet
Add the device tree binding for Pine64's PineTab tablet, which uses Allwinner A64 SoC. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..159060b65c5d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -636,6 +636,11 @@ properties: - const: pine64,pinebook - const: allwinner,sun50i-a64 + - description: Pine64 PineTab +items: + - const: pine64,pinetab + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd
Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD modules. Add its vendor prefix. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 3dab8150dae7..a6d53bbbe33d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -335,6 +335,8 @@ patternProperties: description: Fastrax Oy "^fcs,.*": description: Fairchild Semiconductor + "^feixin,.*": +description: Shenzhen Feixin Photoelectic Co., Ltd "^feiyang,.*": description: Shenzhen Fly Young Technology Co.,LTD. "^firefly,.*": -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] arm64: dts: allwinner: a64: add support for PineTab
PineTab is a 10.1" tablet by Pine64 with Allwinner A64 inside.
It includes the following peripherals:
USB:
- A microUSB Type-B port connected to the OTG-capable USB PHY of
Allwinner A64. The ID pin is connected to a GPIO of the A64 SoC, and the
Vbus is connected to the Vbus of AXP803 PMIC. These enables OTG
functionality on this port.
- A USB Type-A port is connected to the internal hub attached to the
non-OTG USB PHY of Allwinner A64.
- There are reserved pins for an external keyboard connected to the
internal hub.
Power:
- The microUSB port has its Vbus connected to AXP803, mentioned above.
- A DC jack (of a strange size, 2.5mm outer diameter) is connected to
the ACIN of AXP803.
- A Li-Polymer battery is connected to the battery pins of AXP803.
Storage:
- An tradition Pine64 eMMC slot is on the board, mounted with an eMMC
module by factory.
- An external microSD slot is hidden under a protect case.
Display:
- A MIPI-DSI LCD panel (800x1280) is connected to the DSI port of A64 SoC.
- A mini HDMI port.
Input:
- A touch panel attached to a Goodix GT9271 touch controller.
- Volume keys connected to the LRADC of the A64 SoC.
Camera:
- An OV5640 CMOS camera is at rear, connected to the CSI bus of A64 SoC.
- A GC2145 CMOS camera is at front, shares the same CSI bus with OV5640.
Audio:
- A headphone jack is conencted to the SoC's internal codec.
- A speaker connected is to the Line Out port of SoC's internal codec, via
an amplifier.
Misc:
- Debug UART is muxed with the headphone jack, with the switch next to
the microSD slot.
- A bosch BMA223 accelerometer is connected to the I2C bus of A64 SoC.
- Wi-Fi and Bluetooth are available via a RTL8723CS chip, similar to the
one in Pinebook.
This commit adds a basically usable device tree for it, implementing
most of the features mentioned above. HDMI is not supported now because
bad LCD-HDMI coexistence situation of mainline A64 display driver, and
the front camera currently lacks a driver and a facility to share the
bus with the rear one.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../boot/dts/allwinner/sun50i-a64-pinetab.dts | 461 ++
2 files changed, 462 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index cf4f78617c3f..6dad63881cd3 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
new file mode 100644
index ..1dfa3668636e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "PineTab";
+ compatible = "pine64,pinetab", "allwinner,sun50i-a64";
+
+ aliases {
+ serial0 =
+ ethernet0 =
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = < 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
+ power-supply = <_bl>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ i2c-csi {
+ compatible = "i2c-gpio";
+ sda-gpios = < 4 13 GPIO_ACTIVE_HIGH>; /* PE13 */
+ scl-gpios = < 4 12 GPIO_ACTIVE_HIGH>; /* PE12 */
+ i2c-gpio,delay-us = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Rear camera */
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mclk_pin>;
+ clocks = < CLK_CSI_MCLK>;
+ clock-names = "xclk";
+
+ AVDD-supply = <_dldo3>;
+
[PATCH 2/5] dt-bindings: panel: add Feixin K101 IM2BA02 MIPI-DSI panel
Feixin K101 IM2BA02 is a 10.1" 800x1280 4-lane MIPI-DSI panel.
Add device tree binding for it.
Signed-off-by: Icenowy Zheng
---
.../display/panel/feixin,k101-im2ba02.yaml| 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
new file mode 100644
index ..7176d14893ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/feixin,k101-im2ba02.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Feixin K101 IM2BA02 10.1" MIPI-DSI LCD panel
+
+maintainers:
+ - Icenowy Zheng
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: feixin,k101-im2ba02
+ reg: true
+ backlight: true
+ reset-gpios: true
+ avdd-supply:
+ description: regulator that supplies the AVDD voltage
+ dvdd-supply:
+ description: regulator that supplies the DVDD voltage
+ cvdd-supply:
+ description: regulator that supplies the CVDD voltage
+
+required:
+ - compatible
+ - reg
+ - backlight
+ - avdd-supply
+ - dvdd-supply
+ - cvdd-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "feixin,k101-im2ba02";
+reg = <0>;
+avdd-supply = <_dc1sw>;
+dvdd-supply = <_dc1sw>;
+cvdd-supply = <_ldo_io1>;
+reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+};
+};
+
+...
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lima] [RFC v1 0/1] drm: lima: devfreq and cooling device support
于 2019年12月24日 GMT+08:00 下午7:28:41, Martin Blumenstingl 写到: >Hi Alyssa, > >On Mon, Dec 16, 2019 at 4:48 PM Alyssa Rosenzweig > wrote: >> >> If so much code is being duplicated over, I'm wondering if it makes >> sense for us to move some of the common devfreq code to core DRM >> helpers? >if you have any recommendation where to put it then please let me know >(I am not familiar with the DRM subsystem at all) > >my initial idea was that the devfreq logic needs the same information >that the scheduler needs (whether we're submitting something to be >executed, there was a timeout, ...). >however, looking at drivers/gpu/drm/scheduler/ this seems pretty >stand-alone so I'm not sure it should go there >also the Mali-4x0 GPUs have some "PMU" which *may* be used instead of It's optional. We cannot promise its existance on a given hardware, and I heard that at least on Allwinner H5 Mali PMU is broken. >polling the statistics internally >so this is where I realize that with my current knowledge I don't know >enough about lima, panfrost, DRM or the devfreq subsystem to get a >good idea where to put the code. > > >Martin >___ >lima mailing list >l...@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/lima -- 使用 K-9 Mail 发送自我的Android设备。 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
于 2019年10月7日 GMT+08:00 下午7:51:48, Maxime Ripard 写到: >On Mon, Oct 07, 2019 at 12:03:00AM +0800, Icenowy Zheng wrote: >> From: Jagan Teki >> >> The LCD timing definitions between Linux DRM vs Allwinner are >different, >> below diagram shows this clear differences. >> >>Active Front Sync Back >>Region Porch >Porch >> ><---><><--><--> >> //| >> // | >> // |.. > >> >> <- [hv]display -> >> <- [hv]sync_start > >> <- [hv]sync_end --> >> < [hv]total >--> >> >> <- lcd_[xy] > <- lcd_[hv]spw -> >><-- lcd_[hv]bp -> >> < lcd_[hv]t >--> >> >> The DSI driver misinterpreted the vbp term from the BSP code to refer >> only to the backporch, when in fact it was backporch + sync. Thus the >> driver incorrectly used the vertical front porch plus sync in its >> calculation of the DRQ set bit value, when it should not have >included >> the sync timing. >> >> Including additional sync timings leads to flip_done timed out as: >> >> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 >drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 >> [CRTC:46:crtc-0] vblank wait timed out >> Modules linked in: >> CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted >5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 >> Hardware name: Allwinner sun8i Family >> Workqueue: events deferred_probe_work_func >> [] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >> [] (show_stack) from [] (dump_stack+0x84/0x98) >> [] (dump_stack) from [] (__warn+0xfc/0x114) >> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) >> [] (warn_slowpath_fmt) from [] >(drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) >> [] (drm_atomic_helper_wait_for_vblanks.part.1) from >[] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) >> [] (drm_atomic_helper_commit_tail_rpm) from [] >(commit_tail+0x40/0x6c) >> [] (commit_tail) from [] >(drm_atomic_helper_commit+0xbc/0x128) >> [] (drm_atomic_helper_commit) from [] >(restore_fbdev_mode_atomic+0x1cc/0x1dc) >> [] (restore_fbdev_mode_atomic) from [] >(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) >> [] (drm_fb_helper_restore_fbdev_mode_unlocked) from >[] (drm_fb_helper_set_par+0x30/0x54) >> [] (drm_fb_helper_set_par) from [] >(fbcon_init+0x560/0x5ac) >> [] (fbcon_init) from [] (visual_init+0xbc/0x104) >> [] (visual_init) from [] >(do_bind_con_driver+0x1b0/0x390) >> [] (do_bind_con_driver) from [] >(do_take_over_console+0x13c/0x1c4) >> [] (do_take_over_console) from [] >(do_fbcon_takeover+0x74/0xcc) >> [] (do_fbcon_takeover) from [] >(notifier_call_chain+0x44/0x84) >> [] (notifier_call_chain) from [] >(__blocking_notifier_call_chain+0x48/0x60) >> [] (__blocking_notifier_call_chain) from [] >(blocking_notifier_call_chain+0x18/0x20) >> [] (blocking_notifier_call_chain) from [] >(register_framebuffer+0x1e0/0x2f8) >> [] (register_framebuffer) from [] >(__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) >> [] (__drm_fb_helper_initial_config_and_unlock) from >[] (drm_fbdev_client_hotplug+0xe8/0x1b8) >> [] (drm_fbdev_client_hotplug) from [] >(drm_fbdev_generic_setup+0x88/0x118) >> [] (drm_fbdev_generic_setup) from [] >(sun4i_drv_bind+0x128/0x160) >> [] (sun4i_drv_bind) from [] >(try_to_bring_up_master+0x164/0x1a0) >> [] (try_to_bring_up_master) from [] >(__component_add+0x94/0x140) >> [] (__component_add) from [] >(sun6i_dsi_probe+0x144/0x234) >> [] (sun6i_dsi_probe) from [] >(platform_drv_probe+0x48/0x9c) >> [] (platform_drv_probe) from [] >(really_probe+0x1dc/0x2c8) >> [] (really_probe) from [] >(driver_probe_device+0x60/0x160) >> [] (driver_probe_device) from [] >(bus_for_each_drv+0x74/0xb8) >> [] (bus_for_each_drv) from [] >(__device_attach+0xd0/0x13c) >> [] (__device_attach) from [] >(bus_probe_device+0x84/0x8c) >> [] (bus_probe_device) from [] >(deferred_probe_work_func+0x64/0x90) >> [] (deferred_probe_work_func) fro
[PATCH v2 3/3] drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length
The packet length of DCS long write packet should not be added with 1
when constructing long write packet.
Fix this.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 8fe8051c34e6..c958ca9bae63 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -832,8 +832,8 @@ static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi
*dsi,
u32 pkt = msg->type;
if (msg->type == MIPI_DSI_DCS_LONG_WRITE) {
- pkt |= ((msg->tx_len + 1) & 0x) << 8;
- pkt |= (((msg->tx_len + 1) >> 8) & 0x) << 16;
+ pkt |= ((msg->tx_len) & 0x) << 8;
+ pkt |= (((msg->tx_len) >> 8) & 0x) << 16;
} else {
pkt |= (((u8 *)msg->tx_buf)[0] << 8);
if (msg->tx_len > 1)
--
2.21.0
[PATCH v2 2/3] drm/sun4i: dsi: fix the overhead of the horizontal front porch
The formula in the BSP kernel indicates that a 16-byte overhead is used when sending the HFP. However, this value is currently set to 6 in the sun6i_mipi_dsi driver, which makes some panels flashing. Fix this overhead value. Signed-off-by: Icenowy Zheng --- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index b8a0d0501ca7..8fe8051c34e6 100644 --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c @@ -569,11 +569,12 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi, (mode->htotal - mode->hsync_end) * Bpp - HBP_PACKET_OVERHEAD); /* -* The frontporch is set using a blanking packet (4 -* bytes + payload + 2 bytes). Its minimal size is -* therefore 6 bytes +* The frontporch is set using a sync event (4 bytes) +* and two blanking packets (each one is 4 bytes + +* payload + 2 bytes). Its minimal size is therefore +* 16 bytes */ -#define HFP_PACKET_OVERHEAD6 +#define HFP_PACKET_OVERHEAD16 hfp = max((unsigned int)HFP_PACKET_OVERHEAD, (mode->hsync_start - mode->hdisplay) * Bpp - HFP_PACKET_OVERHEAD); -- 2.21.0
[PATCH v2 1/3] drm/sun4i: dsi: Fix video start delay computation
From: Jagan Teki The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <---><><--><--> //| // | // |.. <- [hv]display -> <- [hv]sync_start > <- [hv]sync_end --> < [hv]total --> <- lcd_[xy] > <- lcd_[hv]spw -> <-- lcd_[hv]bp -> < lcd_[hv]t --> The DSI driver misinterpreted the vbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the vertical front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xfc/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) [] (drm_fb_helper_set_par) from [] (fbcon_init+0x560/0x5ac) [] (fbcon_init) from [] (visual_init+0xbc/0x104) [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) [] (do_bind_con_driver) from [] (do_take_over_console+0x13c/0x1c4) [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xcc) [] (do_fbcon_takeover) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) [] (blocking_notifier_call_chain) from [] (register_framebuffer+0x1e0/0x2f8) [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) [] (drm_fbdev_client_hotplug) from [] (drm_fbdev_generic_setup+0x88/0x118) [] (drm_fbdev_generic_setup) from [] (sun4i_drv_bind+0x128/0x160) [] (sun4i_drv_bind) from [] (try_to_bring_up_master+0x164/0x1a0) [] (try_to_bring_up_master) from [] (__component_add+0x94/0x140) [] (__component_add) from [] (sun6i_dsi_probe+0x144/0x234) [] (sun6i_dsi_probe) from [] (platform_drv_probe+0x48/0x9c) [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2c8) [] (really_probe) from [] (driver_probe_device+0x60/0x160) [] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x420) [] (process_one_work) from [] (worker_thread+0x274/0x5a0) [] (worker_thread) from [] (kthread+0x11c/0x14c) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 9fc0: 9fe0: 0013 ---[ end trace 495200a78b24980e ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer Signed-off-by: Jagan Teki ---
[PATCH v2 0/3] drm/sun4i: dsi: misc fixes
This patchset contains several fixes to the sun6i_mipi_dsi driver. First, it's a rebased version of video start delay porch fix from Jagan Teki. The next patch fixes the overhead of HFP packet, according to the source code of BSP [1]. The final patch fixes DCS long write, which fixes initialization issue with a panel with ST7703 controller (XBD599 panel used by PinePhone). This seems to be a misread of [2]. (The formula in [2] is para_num+1, and the code of the sun6i_mipi_dsi driver uses tx_len, which is the length including the command; thus tx_len is equal to para_num+1, so it shouldn't be added with 1 for another time.) Icenowy Zheng (2): drm/sun4i: dsi: fix the overhead of the horizontal front porch drm/sun4i: sun6i_mipi_dsi: fix DCS long write packet length Jagan Teki (1): drm/sun4i: dsi: Fix video start delay computation [1] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L920 [2] https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L227 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) -- 2.21.0
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道： > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > > Hi Wens, > > > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng > > wrote: > > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > > > This commit, although claimed as a refactor, in fact changed the > > > formula. > > > > > > By expanding the original formula, we can find that the const 10 > > > is > > > not > > > substracted, instead it's added to the value (because 10 is > > > negative > > > when calculating hsa, and hsa itself is negative when calculating > > > hblk). > > > This breaks the similar pattern to other formulas, so restoring > > > the > > > original formula is more proper. > > > > > > Signed-off-by: Icenowy Zheng > > > --- > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > > sun6i_dsi *dsi, > > > (mode->hsync_start - mode->hdisplay) * > > > Bpp - HFP_PACKET_OVERHEAD); > > > > > > /* > > > -* The blanking is set using a sync event (4 > > > bytes) > > > -* and a blanking packet (4 bytes + payload + 2 > > > -* bytes). Its minimal size is therefore 10 > > > bytes. > > > +* hblk seems to be the line + porches length. > > > */ > > > -#define HBLK_PACKET_OVERHEAD 10 > > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > > - (mode->htotal - (mode->hsync_end - > > > mode- > > > > hsync_start)) * Bpp - > > > - HBLK_PACKET_OVERHEAD); > > > + hblk = mode->htotal * Bpp - hsa; > > > > The original formula is correct according to BSP [1] and work with > > my > > panels which I have tested before. May be the horizontal timings on > > panels you have leads to negative value. > > Do you tested the same timing with BSP kernel? > > It's quite difficult to get a negative value here, because the value > is > quite big (includes mode->hdisplay * Bpp). By re-checking with the BSP source code, I found that the constant in the HFP formula is indeed wrong -- it should be 16, not 6. > > Strangely, only change the formula here back makes the timing > translated from FEX file works (tested on PineTab and PinePhone > production ver). The translation rule is from [1]. > > So I still insist on the patch because it's needed by experiment. > > [1] http://linux-sunxi.org/LCD > > > [1] > > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > Hi Wens, > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng wrote: > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > This commit, although claimed as a refactor, in fact changed the > > formula. > > > > By expanding the original formula, we can find that the const 10 is > > not > > substracted, instead it's added to the value (because 10 is > > negative > > when calculating hsa, and hsa itself is negative when calculating > > hblk). > > This breaks the similar pattern to other formulas, so restoring the > > original formula is more proper. > > > > Signed-off-by: Icenowy Zheng > > --- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > sun6i_dsi *dsi, > > (mode->hsync_start - mode->hdisplay) * > > Bpp - HFP_PACKET_OVERHEAD); > > > > /* > > -* The blanking is set using a sync event (4 bytes) > > -* and a blanking packet (4 bytes + payload + 2 > > -* bytes). Its minimal size is therefore 10 bytes. > > +* hblk seems to be the line + porches length. > > */ > > -#define HBLK_PACKET_OVERHEAD 10 > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > - (mode->htotal - (mode->hsync_end - mode- > > >hsync_start)) * Bpp - > > - HBLK_PACKET_OVERHEAD); > > + hblk = mode->htotal * Bpp - hsa; > > The original formula is correct according to BSP [1] and work with my > panels which I have tested before. May be the horizontal timings on > panels you have leads to negative value. Do you tested the same timing with BSP kernel? It's quite difficult to get a negative value here, because the value is quite big (includes mode->hdisplay * Bpp). Strangely, only change the formula here back makes the timing translated from FEX file works (tested on PineTab and PinePhone production ver). The translation rule is from [1]. So I still insist on the patch because it's needed by experiment. [1] http://linux-sunxi.org/LCD > > [1] > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919
Re: [linux-sunxi] [PATCH 1/3] Revert "drm/sun4i: dsi: Change the start delay calculation"
于 2019年10月3日 GMT+08:00 下午9:19:16, Maxime Ripard 写到: >On Thu, Oct 03, 2019 at 12:38:43PM +0530, Jagan Teki wrote: >> On Tue, Oct 1, 2019 at 1:33 PM Icenowy Zheng wrote: >> > >> > This reverts commit da676c6aa6413d59ab0a80c97bbc273025e640b2. >> > >> > The original commit adds a start parameter to the calculation of >the >> > start delay according to some old BSP versions from Allwinner. >However, >> > there're two ways to add this delay -- add it in DSI controller or >add >> > it in the TCON. Add it in both controllers won't work. >> > >> > The code before this commit is picked from new versions of BSP >kernel, >> > which has a comment for the 1 that says "put start_delay to tcon". >By >> > checking the sun4i_tcon0_mode_set_cpu() in sun4i_tcon driver, it >has >> > already added this delay, so we shouldn't repeat to add the delay >in DSI >> > controller, otherwise the timing won't match. >> >> Thanks for this change. look like this is proper reason for adding + >> 1. also adding bsp code links here might help for future reference. >> >> Otherwise, >> >> Reviewed-by: Jagan Teki > >The commit log was better in this one. I ended up merging this one, >with your R-b. Please note that Jagan's v11 3/7 is still needed. > >Maxime -- 使用 K-9 Mail 发送自我的Android设备。
