Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
>
>
>On 1/22/24 10:28 AM, H. Peter Anvin wrote:
>> On January 22, 2024 8:32:22 AM PST, Dave Hansen
>> wrote:
>>> On 1/9/24 00:40, Alexey Makhalov wrote:
>>>> +#ifdef CONFIG_INTEL_TDX_GUEST
>>>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>>>> + struct tdx_module_args *args)
>>>> +{
>>>> + if (!hypervisor_is_type(X86_HYPER_VMWARE))
>>>> + return ULONG_MAX;
>>>> +
>>>> + if (cmd & ~VMWARE_CMD_MASK) {
>>>> + pr_warn_once("Out of range command %lx\n", cmd);
>>>> + return ULONG_MAX;
>>>> + }
>>>> +
>>>> + args->r10 = VMWARE_TDX_VENDOR_LEAF;
>>>> + args->r11 = VMWARE_TDX_HCALL_FUNC;
>>>> + args->r12 = VMWARE_HYPERVISOR_MAGIC;
>>>> + args->r13 = cmd;
>>>> + args->r15 = 0; /* CPL */
>>>> +
>>>> + __tdx_hypercall(args);
>>>> +
>>>> + return args->r12;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
>>>> +#endif
>>>
>>> This is the kind of wrapper that I was hoping for. Thanks.
>>>
>>> Acked-by: Dave Hansen
>>>
>>
>> I'm slightly confused by this TBH.
>>
>> Why are the arguments passed in as a structure, which is modified by the
>> wrapper to boot? This is analogous to a system call interface.
>>
>> Furthermore, this is an out-of-line function; it should never be called with
>> !X86_HYPER_VMWARE or you are introducing overhead for other hypervisors; I
>> believe a pr_warn_once() is in order at least, just as you have for the
>> out-of-range test.
>>
>
>This patch series introduces vmware_hypercall family of functions similar to
>kvm_hypercall. Similarity: both vmware and kvm implementations are static
>inline functions and both of them use __tdx_hypercall (global not exported
>symbol). Difference: kvm_hypercall functions are used _only_ within the
>kernel, but vmware_hypercall are also used by modules.
>Exporting __tdx_hypercall function is an original Dave's concern.
>So we ended up with exporting wrapper, not generic, but VMware specific with
>added checks against arbitrary use.
>vmware_tdx_hypercall is not designed for !X86_HYPER_VMWARE callers. But such a
>calls are not forbidden.
>Arguments in a structure is an API for __tdx_hypercall(). Input and output
>argument handling are done by vmware_hypercall callers, while VMware specific
>dress up is inside the wrapper.
>
>Peter, do you think code comments are required to make it clear for the reader?
>
>
TBH that explanation didn't make much sense to me...
Re: [PATCH v6 7/7] x86/vmware: Add TDX hypercall support
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
>On 1/9/24 00:40, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>> + struct tdx_module_args *args)
>> +{
>> +if (!hypervisor_is_type(X86_HYPER_VMWARE))
>> +return ULONG_MAX;
>> +
>> +if (cmd & ~VMWARE_CMD_MASK) {
>> +pr_warn_once("Out of range command %lx\n", cmd);
>> +return ULONG_MAX;
>> +}
>> +
>> +args->r10 = VMWARE_TDX_VENDOR_LEAF;
>> +args->r11 = VMWARE_TDX_HCALL_FUNC;
>> +args->r12 = VMWARE_HYPERVISOR_MAGIC;
>> +args->r13 = cmd;
>> +args->r15 = 0; /* CPL */
>> +
>> +__tdx_hypercall(args);
>> +
>> +return args->r12;
>> +}
>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
>> +#endif
>
>This is the kind of wrapper that I was hoping for. Thanks.
>
>Acked-by: Dave Hansen
>
I'm slightly confused by this TBH.
Why are the arguments passed in as a structure, which is modified by the
wrapper to boot? This is analogous to a system call interface.
Furthermore, this is an out-of-line function; it should never be called with
!X86_HYPER_VMWARE or you are introducing overhead for other hypervisors; I
believe a pr_warn_once() is in order at least, just as you have for the
out-of-range test.
Re: [PATCH RFC v2 04/11] ARM: dts: omap4: Add device tree entry for SGX GPU
Hi,
> Am 15.01.2024 um 09:25 schrieb Maxime Ripard :
>
> Hi,
>
> On Fri, Jan 12, 2024 at 06:33:58PM +0100, H. Nikolaus Schaller wrote:
>>> Am 08.01.2024 um 19:32 schrieb Andrew Davis :
>>>
>>> Add SGX GPU device entry to base OMAP4 dtsi file.
>>>
>>> Signed-off-by: Andrew Davis
>>> ---
>>> arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
>>> b/arch/arm/boot/dts/ti/omap/omap4.dtsi
>>> index 2bbff9032be3e..559b2bfe4ca7c 100644
>>> --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi
>>> @@ -501,10 +501,11 @@ sgx_module: target-module@5600 {
>>> #size-cells = <1>;
>>> ranges = <0 0x5600 0x200>;
>>>
>>> - /*
>>> - * Closed source PowerVR driver, no child device
>>> - * binding or driver in mainline
>>> - */
>>> + gpu@0 {
>>
>> I wonder why we don't add a "gpu:" label here.
>>
>> Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:,
>> hdmi:, etc.),
>> obviously for convenience when using a .dtsi file.
>>
>> It would allow a board-specific DTS to easily add status = "disabled" to
>> avoid driver
>> probing or disabling the GPU (e.g. if there is no display).
>
> There's no reason to disable it in the DT: the hardware block would
> still be there and it's rendering to memory so it still could be useful.
Well, if you know that the board does not have a dm3730 but a dm3725 without
GPU it is better to disable the GPU completely instead of loading the driver
and make it detect by some internal bits that it has no GPU on the SoC.
> If there's no display on the board and you really don't want the GPU
> driver, then you can disable the driver or block the module loading, but
> it should be a distro / package / user decision, not a DT / kernel one
> still.
The same holds for aes: dss: dsi: hdmi: etc. If they are not used by some
board file, they don't change a single bit of the DTB [1] which IMHO would
be of reasonable concern to question additional labels.
BR and thanks,
Nikolaus
[1]
https://devicetree-specification.readthedocs.io/en/stable/source-language.html
"Labels are only used in the devicetree source format and are not encoded into
the
DTB binary."
Re: [PATCH RFC v2 04/11] ARM: dts: omap4: Add device tree entry for SGX GPU
Hi,
I just comment on this example, but it applies almost the same for all other
.dtsi changes.
> Am 08.01.2024 um 19:32 schrieb Andrew Davis :
>
> Add SGX GPU device entry to base OMAP4 dtsi file.
>
> Signed-off-by: Andrew Davis
> ---
> arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
> b/arch/arm/boot/dts/ti/omap/omap4.dtsi
> index 2bbff9032be3e..559b2bfe4ca7c 100644
> --- a/arch/arm/boot/dts/ti/omap/omap4.dtsi
> +++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi
> @@ -501,10 +501,11 @@ sgx_module: target-module@5600 {
> #size-cells = <1>;
> ranges = <0 0x5600 0x200>;
>
> - /*
> - * Closed source PowerVR driver, no child device
> - * binding or driver in mainline
> - */
> + gpu@0 {
I wonder why we don't add a "gpu:" label here.
Almost all other subsystem nodes have one (e.g. emif:, aes:, dss:, dsi:, hdmi:,
etc.),
obviously for convenience when using a .dtsi file.
It would allow a board-specific DTS to easily add status = "disabled" to avoid
driver
probing or disabling the GPU (e.g. if there is no display).
> + compatible = "ti,omap4430-gpu", "img,powervr-sgx540";
It still appears to me that the "img,powervr-sgx540" (or similar) entry is
redundant
information.
I have experimentally updated our openpvrsgx driver and we do not have any use
for
this information (at least in the kernel driver):
https://github.com/goldelico/letux-kernel/commit/f2f7cb3b858ef255f52f2b82a8bb34c047337afe
It shows how easy it is to derive the sgx version and revision number if we ever
need it inside the driver.
So if you want to keep a reference to powervr, it would suffice to have
> + compatible = "ti,omap4430-gpu", "img,powervr-sgx";
Otherwise your device tree entries compile fine and seem to work (at least in
a cursory test on PandaBoard ES).
> + reg = <0x0 0x200>; /* 32MB */
> + interrupts = ;
> + };
> };
BR and thanks,
Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 21.12.2023 um 09:58 schrieb Maxime Ripard : > > Cool, so what you're saying is that your plan is to support those GPUs > upstream in the imagination driver? Yes, I would like to see PowerVR Series 5 SGX supported upstream since there are still so many devices in the wild which could use it. The most advanced being the Pyra handheld gaming computer but there are omap4 based phones or other omap3/amm335x based devices. And the only reason the OpenPVRSGX group was founded (BTW not by me, I am just maintaining the code and running a mailing list because it was rejected to host it on vger.kernel.org), was to make that happen. From the GitHub description: This is about shaping existing GPL Linux kernel drivers for the PVR/SGX5 architecture so that they can become accepted into drivers/staging But nobody can currently tell if it can be integrated with the recently upstreamed Rogue driver (I wouldn't call that *the* imagination driver) or if it better stays a separate driver because the first would need touching closed user-space code and GPU firmware. And nobody knows who is capable and willing to work on it. It depends on access to (confidential) documentation and available time to make such a big task a rewarding project. And discussions like this one are not at all encouraging to even try. >> Now, IMHO all the pros and cons are on the table and the question is >> who makes a decision how to go. > > You haven't listed any pro so far, you're claiming that the one I raise > are irrelevant. I have listed some "pros" for "single file" but you apparently don't see them as such. I can't change that. The main argument is that a single file is simpler than two files duplicating parts, which are apparently the same (integration of PVR architectures into SoC doesn't differ very much: shared register block, DMA memory, clocks, resets etc.). Yours is that two files duplicating such common things is "more convenient". I just wonder for whom. But it seems as if the IMHO second best solution has already been chosen. So let it be. >> Then the currently-out-of-tree driver for the sgx5 can be reworked in >> less than half an hour without loosing functionality. > > Again, you're making it harder than it needs to be for no particular > reason other than the potential file name clash that can be addressed. What I want to avoid is a situation that upstream activities do not take the existing and working out-of-tree SGX driver into account and make porting (not even speaking of upstreaming) that driver more difficult than necessary and force device tree files to contain redundant information nobody will need and use. You can of course ignore experience and suggestions of people who have worked on an SGX driver for a while. But that is the reason why I participate in this discussion and raise my voice. Now, I am looking forward to a v2 of this patch. BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 18.12.2023 um 11:14 schrieb Maxime Ripard : > > On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote: >> Hi Maxime, >> >>> Am 15.12.2023 um 14:33 schrieb Maxime Ripard : >>> >>>>> >>>>> It's for a separate architecture, with a separate driver, maintained out >>>>> of tree by a separate community, with a separate set of requirements as >>>>> evidenced by the other thread. And that's all fine in itself, but >>>>> there's very little reason to put these two bindings in the same file. >>>>> >>>>> We could also turn this around, why is it important that it's in the >>>>> same file? >>>> >>>> Same vendor. And enough similarity in architectures, even a logical >>>> sequence >>>> of development of versions (SGX = Version 5, Rogue = Version 6+) behind. >>>> (SGX and Rogue seem to be just trade names for their architecture >>>> development). >>> >>> Again, none of that matters for *where* the binding is stored. >> >> So what then speaks against extending the existing bindings file as proposed >> here? > > I mean, apart from everything you quoted, then sure, nothing speaks > against it. > >>>> AFAIK bindings should describe hardware and not communities or drivers >>>> or who is currently maintaining it. The latter can change, the first not. >>> >>> Bindings are supposed to describe hardware indeed. Nothing was ever said >>> about where those bindings are supposed to be located. >>> >>> There's hundreds of other YAML bindings describing devices of the same >>> vendors and different devices from the same generation. >> >> Usually SoC seem to be split over multiple files by subsystem. Not by >> versions >> or generations. If the subsystems are similar enough they share the same >> bindings >> doc instead of having one for each generation duplicating a lot of code. >> >> Here is a comparable example that combines multiple vendors and generations: >> >> Documentation/devicetree/bindings/usb/generic-ehci.yaml > > EHCI is a single interface for USB2.0 controllers. It's a standard API, > and is made of a single driver that requires minor modifications to deal > with multiple devices. > > We're very far from the same situation here. How far are we really? And, it is the purpose of the driver to handle different cases. That there are currently two drivers is just a matter of history and not a necessity. > >>> If anything it'll make it easier for you. I'm really not sure why it is >>> controversial and you're fighting this so hard. >> >> Well, you made it controversial by proposing to split what IMHO belongs >> together. > > No, reviews aren't controversial. > The controversy started when you chose > to oppose it while you could have just rolled with it. Well, you asked "I think it would be best to have a separate file for this, img,sgx.yaml maybe?" and "Because it's more convenient?" I understood that as an invitation for discussing the pros and cons and working out the most convenient solution. And that involves playing the devil's advocate which of course is controversial by principle. Now, IMHO all the pros and cons are on the table and the question is who makes a decision how to go. > >> I feel that the original patch is good enough for its purpose and follows >> some design pattern that can be deduced from other binding docs. > > [citation needed] Joke: Documentation/devicetree/bindings/* - I am not aware of a formal analysis of course. But see my example for ehci. It follows the pattern I mean. If clocks, regs, interrupts, resets, and more properties are (almost) the same, then group them and just differentiate by different compatible strings. If necessary use some - if: clauses. It is the task of drivers to handle the details. As my other (maybe more important) comment to this patch did indicate we IMHO can easily live with something like + - items: + - enum: + - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable + - ti,omap3430-gpu # sgx530 Rev 121 + - ti,omap3630-gpu # sgx530 Rev 125 + - ingenic,jz4780-gpu # sgx540 Rev 130 + - ti,omap4430-gpu # sgx540 Rev 120 + - allwinner,sun6i-a31-gpu # sgx544 MP2 Rev 115 + - ti,omap4470-gpu # sgx544 MP1 Rev 112 + - ti,omap5432-gpu # sgx544 MP2 Rev 105 + - ti,am5728-gpu # sgx544 MP2 Rev 116 + - ti,am6548-gpu # sgx544 MP1 Rev 117 And leave it to drivers using a table to deduce the generation and revision or read it out from the chip. And there can even be different drivers handling only a subset of the potential compatibles. Then the currently-out-of-tree driver for the sgx5 can be reworked in less than half an hour without loosing functionality. BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
Hi Maxime, > Am 15.12.2023 um 14:33 schrieb Maxime Ripard : > >>> >>> It's for a separate architecture, with a separate driver, maintained out >>> of tree by a separate community, with a separate set of requirements as >>> evidenced by the other thread. And that's all fine in itself, but >>> there's very little reason to put these two bindings in the same file. >>> >>> We could also turn this around, why is it important that it's in the >>> same file? >> >> Same vendor. And enough similarity in architectures, even a logical sequence >> of development of versions (SGX = Version 5, Rogue = Version 6+) behind. >> (SGX and Rogue seem to be just trade names for their architecture >> development). > > Again, none of that matters for *where* the binding is stored. So what then speaks against extending the existing bindings file as proposed here? > >> AFAIK bindings should describe hardware and not communities or drivers >> or who is currently maintaining it. The latter can change, the first not. > > Bindings are supposed to describe hardware indeed. Nothing was ever said > about where those bindings are supposed to be located. > > There's hundreds of other YAML bindings describing devices of the same > vendors and different devices from the same generation. Usually SoC seem to be split over multiple files by subsystem. Not by versions or generations. If the subsystems are similar enough they share the same bindings doc instead of having one for each generation duplicating a lot of code. Here is a comparable example that combines multiple vendors and generations: Documentation/devicetree/bindings/usb/generic-ehci.yaml > If anything it'll make it easier for you. I'm really not sure why it is > controversial and you're fighting this so hard. Well, you made it controversial by proposing to split what IMHO belongs together. I feel that the original patch is good enough for its purpose and follows some design pattern that can be deduced from other binding docs. BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
Hi Maxime, > Am 07.12.2023 um 10:20 schrieb Maxime Ripard : > > On Tue, Dec 05, 2023 at 02:50:08PM +0100, H. Nikolaus Schaller wrote: >> Hi, >> >>> Am 05.12.2023 um 14:29 schrieb Maxime Ripard : >>> >>> Hi, >>> >>> On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote: >>>>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard : >>>>> >>>>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote: >>>>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from >>>>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC, >>>>>> including register space and interrupts. Clocks, reset, and power domain >>>>>> information is SoC specific. >>>>>> >>>>>> Signed-off-by: Andrew Davis >>>>>> --- >>>>>> .../devicetree/bindings/gpu/img,powervr.yaml | 69 +-- >>>>>> 1 file changed, 63 insertions(+), 6 deletions(-) >>>>> >>>>> I think it would be best to have a separate file for this, img,sgx.yaml >>>>> maybe? >>>> >>>> Why? >>> >>> Because it's more convenient? >> >> Is it? > > It's for a separate architecture, with a separate driver, maintained out > of tree by a separate community, with a separate set of requirements as > evidenced by the other thread. And that's all fine in itself, but > there's very little reason to put these two bindings in the same file. > > We could also turn this around, why is it important that it's in the > same file? Same vendor. And enough similarity in architectures, even a logical sequence of development of versions (SGX = Version 5, Rogue = Version 6+) behind. (SGX and Rogue seem to be just trade names for their architecture development). AFAIK bindings should describe hardware and not communities or drivers or who is currently maintaining it. The latter can change, the first not. > >>>> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations >>>> 5 and 6++: >>>> >>>> https://en.wikipedia.org/wiki/PowerVR >>> >>> That's not really relevant as far as bindings go. >> >> But maybe for choosing binding file names. Well they are machine readable >> but sometimes humans work with them. > > Heh. It's something that can also be easily grepped, Yes, arbitrarily introduced confusion can always be resolved by search engines and makes them necessary and more and more advanced :) > and the name is > never going to reflect all the compatibles in a binding so it's what > you'll end up doing anyway. But feel free to suggest another name to > avoid the confusion. Well, 1. rename img,powervr.yaml => img,powervr-rogue.yaml 2. new file img,powervr-sgx.yaml to have at least a systematic approach here. >>> We have multiple >>> binding files for devices of the same generation, or single bindings >>> covering multiple generations. >>> >>> The important part is that every compatible is documented. It doesn't >>> really matter how or where. >> >> Yes, and that is why I would find it more convenient to have a single >> "img,powervr.yaml" for all variations unless it becomes filled with >> unrelated stuff (which isn't as far as I see). > > Again, hard disagree there. I am fine with that. I just advocate to follow the KISS principle. Same vendor, similar purpose, similar architecture => single bindings file as Andrew proposed. BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
(non-html)
> Am 06.12.2023 um 17:15 schrieb Andrew Davis :
>
> On 12/6/23 10:02 AM, Conor Dooley wrote:
>> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis :
>>>>
>>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>>> + - enum:
>>>>>> + - ti,omap3430-gpu # Rev 121
>>>>>> + - ti,omap3630-gpu # Rev 125
>>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration
>>>>> (clock/reset/power
>>>>> hookup etc.) or of the integrated SGX core?
>>>>
>>>> The Rev is a property of the SGX core, not the SoC integration.
>>>
>>> Then, it should belong there and not be a comment of the ti,omap*-gpu
>>> record.
>>> In this way it does not seem to be a proper hardware description.
>>>
>>> BTW: there are examples where the revision is part of the compatible
>>> string, even
>>> if the (Linux) driver makes no use of it:
>>>
>>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
>> AFAICT these Xilinx devices that put the revisions in the compatible are
>> a different case - they're "soft" IP intended for use in the fabric of
>> an FPGA, and assigning a device specific compatible there does not make
>> sense.
>> In this case it appears that the revision is completely known once you
>> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
>> string is not required.
>>>
>>>> But it seems that
>>>> compatible string is being used to define both (as we see being debated in
>>>> the other
>>>> thread on this series).
>>>>
>>>>> In my understanding the Revs are different variants of the SGX core
>>>>> (errata
>>>>> fixes, instruction set, pipeline size etc.). And therefore the current
>>>>> driver code
>>>>> has to be configured by some macros to handle such cases.
>>>>> So the Rev should IMHO be part of the next line:
>>>>>> + - const: img,powervr-sgx530
>>>>> + - enum:
>>>>> + - img,powervr-sgx530-121
>>>>> + - img,powervr-sgx530-125
>>>>> We have a similar definition in the openpvrsgx code.
>>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121",
>>>>> "img,sgx530";
>>>>> (I don't mind about the powervr- prefix).
>>>>> This would allow a generic and universal sgx driver (loaded through just
>>>>> matching
>>>>> "img,sgx530") to handle the errata and revision specifics at runtime
>>>>> based on the
>>>>> compatible entry ("img,sgx530-121") and know about SoC integration
>>>>> ("ti,omap3-sgx530-121").
>> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
>> sgx530-125 compatibles are also required to be present for the driver to
>> actually function. The revision specific compatibles I would not object
>> to, but everything in here has different revisions anyway - does the
>> same revision actually appear in multiple devices? If it doesn't then I
>> don't see any value in the suffixed compatibles either.
>
> Everything here has different revisions because any device that uses
> the same revision can also use the same base compatible string. For
> instance AM335x SoCs use the SGX530 revision 125, same as OMAP3630,
> so I simply reuse that compatible in their DT as you can see in
> patch [5/10]. I didn't see the need for a new compatible string
> for identical (i.e. "compatible") IP and integration.
Ok, this is a point. As long as there is no SoC which can come with different
SGX revisions the SoC compatible is enough for everything.
I never looked it that way.
>
> The first device to use that IP/revision combo gets the named
> compatible, all others re-use the same compatible where possible.
Hm. If we take this rule, we can even completely leave out all
+ - const: img,powervr-sgx530
+ - const: img,powervr-sgx540
+ - const: img,powervr-sgx544
and just have a list of allsgx compatible SoC:
+ - items:
+ - enum:
+ - ti,am62-gpu # IMG AXE GPU model/revision is fully discoverable
+ - ti,omap3430-gpu # sgx530 Rev 121
+ - ti,omap3630-gpu # sgx530 Rev 125
+
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 06.12.2023 um 17:15 schrieb Andrew Davis :
>
> On 12/6/23 10:02 AM, Conor Dooley wrote:
>> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis :
>>>>
>>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>>> + - enum:
>>>>>> + - ti,omap3430-gpu # Rev 121
>>>>>> + - ti,omap3630-gpu # Rev 125
>>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration
>>>>> (clock/reset/power
>>>>> hookup etc.) or of the integrated SGX core?
>>>>
>>>> The Rev is a property of the SGX core, not the SoC integration.
>>>
>>> Then, it should belong there and not be a comment of the ti,omap*-gpu
>>> record.
>>> In this way it does not seem to be a proper hardware description.
>>>
>>> BTW: there are examples where the revision is part of the compatible
>>> string, even
>>> if the (Linux) driver makes no use of it:
>>>
>>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
>> AFAICT these Xilinx devices that put the revisions in the compatible are
>> a different case - they're "soft" IP intended for use in the fabric of
>> an FPGA, and assigning a device specific compatible there does not make
>> sense.
>> In this case it appears that the revision is completely known once you
>> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
>> string is not required.
>>>
>>>> But it seems that
>>>> compatible string is being used to define both (as we see being debated in
>>>> the other
>>>> thread on this series).
>>>>
>>>>> In my understanding the Revs are different variants of the SGX core
>>>>> (errata
>>>>> fixes, instruction set, pipeline size etc.). And therefore the current
>>>>> driver code
>>>>> has to be configured by some macros to handle such cases.
>>>>> So the Rev should IMHO be part of the next line:
>>>>>> + - const: img,powervr-sgx530
>>>>> + - enum:
>>>>> + - img,powervr-sgx530-121
>>>>> + - img,powervr-sgx530-125
>>>>> We have a similar definition in the openpvrsgx code.
>>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121",
>>>>> "img,sgx530";
>>>>> (I don't mind about the powervr- prefix).
>>>>> This would allow a generic and universal sgx driver (loaded through just
>>>>> matching
>>>>> "img,sgx530") to handle the errata and revision specifics at runtime
>>>>> based on the
>>>>> compatible entry ("img,sgx530-121") and know about SoC integration
>>>>> ("ti,omap3-sgx530-121").
>> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
>> sgx530-125 compatibles are also required to be present for the driver to
>> actually function. The revision specific compatibles I would not object
>> to, but everything in here has different revisions anyway - does the
>> same revision actually appear in multiple devices? If it doesn't then I
>> don't see any value in the suffixed compatibles either.
>
> Everything here has different revisions because any device that uses
> the same revision can also use the same base compatible string. For
> instance AM335x SoCs use the SGX530 revision 125, same as OMAP3630,
> so I simply reuse that compatible in their DT as you can see in
> patch [5/10]. I didn't see the need for a new compatible string
> for identical (i.e. "compatible") IP and integration.
Ok, this is a point. As long as there is no SoC which can come with different
SGX revisions the SoC compatible is enough for everything.
I never looked it that way.
>
> The first device to use that IP/revision combo gets the named
> compatible, all others re-use the same compatible where possible.
Hm. If we take this rule, we can even completely leave out all
+ - const: img,powervr-sgx530
+ - const: img,powervr-sgx540
+ - const: img,powervr-sgx544
and just have a list of allsgx compatible SoC:
+ - items:
+ - enum:
+ - ti,am62-gpu# IMG AXE GPU model/revision is fully
discoverable
+ - ti,omap3430-gpu # sgx530 Rev 121
+ - ti,omap3630-gpu # sgx530 Rev 125
+ - ingenic
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 06.12.2023 um 17:02 schrieb Conor Dooley :
>
> On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
>>> Am 05.12.2023 um 18:33 schrieb Andrew Davis :
>>>
>>> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>>>> + - enum:
>>>>> + - ti,omap3430-gpu # Rev 121
>>>>> + - ti,omap3630-gpu # Rev 125
>>>> Is the "Rev 121" and "Rev 125" a property of the SoC integration
>>>> (clock/reset/power
>>>> hookup etc.) or of the integrated SGX core?
>>>
>>> The Rev is a property of the SGX core, not the SoC integration.
>>
>> Then, it should belong there and not be a comment of the ti,omap*-gpu record.
>> In this way it does not seem to be a proper hardware description.
>>
>> BTW: there are examples where the revision is part of the compatible string,
>> even
>> if the (Linux) driver makes no use of it:
>>
>> drivers/net/ethernet/xilinx/xilinx_emaclite.c
>
> AFAICT these Xilinx devices that put the revisions in the compatible are
> a different case - they're "soft" IP intended for use in the fabric of
> an FPGA, and assigning a device specific compatible there does not make
> sense.
>
> In this case it appears that the revision is completely known once you
> see "ti,omap3630-gpu", so encoding the extra "121" into the compatible
> string is not required.
Well, I would not put my hand in the fire for this assumption.
And I am a friend of explicitly stating what is instead ot encoding indirectly.
>
>>
>>> But it seems that
>>> compatible string is being used to define both (as we see being debated in
>>> the other
>>> thread on this series).
>>>
>>>> In my understanding the Revs are different variants of the SGX core (errata
>>>> fixes, instruction set, pipeline size etc.). And therefore the current
>>>> driver code
>>>> has to be configured by some macros to handle such cases.
>>>> So the Rev should IMHO be part of the next line:
>>>>> + - const: img,powervr-sgx530
>>>> + - enum:
>>>> + - img,powervr-sgx530-121
>>>> + - img,powervr-sgx530-125
>>>> We have a similar definition in the openpvrsgx code.
>>>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121",
>>>> "img,sgx530";
>>>> (I don't mind about the powervr- prefix).
>>>> This would allow a generic and universal sgx driver (loaded through just
>>>> matching
>>>> "img,sgx530") to handle the errata and revision specifics at runtime based
>>>> on the
>>>> compatible entry ("img,sgx530-121") and know about SoC integration
>>>> ("ti,omap3-sgx530-121").
>
> The "raw" sgx530 compatible does not seem helpful if the sgx530-121 or
> sgx530-125 compatibles are also required to be present for the driver to
> actually function.
Indeed. This seems to be redundant (but may need some pattern processing).
> The revision specific compatibles I would not object
> to, but everything in here has different revisions anyway - does the
> same revision actually appear in multiple devices? If it doesn't then I
> don't see any value in the suffixed compatibles either.
Well, we don't know.
So far only a subset of SoC with the SGX GPU core variants has been considered
(mainly because lack of user space code and device owners).
Maybe someone with insider knowledge can give a hint if the SGX version numbers
were assigned uniquely for each SoC integration project.
>
>>>> And user-space can be made to load the right firmware variant based on
>>>> "img,sgx530-121"
>>>> I don't know if there is some register which allows to discover the
>>>> revision long
>>>> before the SGX subsystem is initialized and the firmware is up and running.
>>>> What I know is that it is possible to read out the revision after starting
>>>> the firmware
>>>> but it may just echo the version number of the firmware binary provided
>>>> from user-space.
>>>
>>> We should be able to read out the revision (register EUR_CR_CORE_REVISION),
>>> the problem is
>>> today the driver is built for a given revision at compile time.
>>
>> Yes, that is something we had planned to get rid of for a long time by using
>> different compatible
>> strings and some variant specific struct l
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 05.12.2023 um 18:33 schrieb Andrew Davis :
>
> On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
>>> + - enum:
>>> + - ti,omap3430-gpu # Rev 121
>>> + - ti,omap3630-gpu # Rev 125
>> Is the "Rev 121" and "Rev 125" a property of the SoC integration
>> (clock/reset/power
>> hookup etc.) or of the integrated SGX core?
>
> The Rev is a property of the SGX core, not the SoC integration.
Then, it should belong there and not be a comment of the ti,omap*-gpu record.
In this way it does not seem to be a proper hardware description.
BTW: there are examples where the revision is part of the compatible string,
even
if the (Linux) driver makes no use of it:
drivers/net/ethernet/xilinx/xilinx_emaclite.c
> But it seems that
> compatible string is being used to define both (as we see being debated in
> the other
> thread on this series).
>
>> In my understanding the Revs are different variants of the SGX core (errata
>> fixes, instruction set, pipeline size etc.). And therefore the current
>> driver code
>> has to be configured by some macros to handle such cases.
>> So the Rev should IMHO be part of the next line:
>>> + - const: img,powervr-sgx530
>> + - enum:
>> + - img,powervr-sgx530-121
>> + - img,powervr-sgx530-125
>> We have a similar definition in the openpvrsgx code.
>> Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
>> (I don't mind about the powervr- prefix).
>> This would allow a generic and universal sgx driver (loaded through just
>> matching
>> "img,sgx530") to handle the errata and revision specifics at runtime based
>> on the
>> compatible entry ("img,sgx530-121") and know about SoC integration
>> ("ti,omap3-sgx530-121").
>> And user-space can be made to load the right firmware variant based on
>> "img,sgx530-121"
>> I don't know if there is some register which allows to discover the revision
>> long
>> before the SGX subsystem is initialized and the firmware is up and running.
>> What I know is that it is possible to read out the revision after starting
>> the firmware
>> but it may just echo the version number of the firmware binary provided from
>> user-space.
>
> We should be able to read out the revision (register EUR_CR_CORE_REVISION),
> the problem is
> today the driver is built for a given revision at compile time.
Yes, that is something we had planned to get rid of for a long time by using
different compatible
strings and some variant specific struct like many others drivers are doing it.
But it was a to big task so nobody did start with it.
> That is a software issue,
> not something that we need to encode in DT. While the core ID (SGX5xx) can be
> also detected
> (EUR_CR_CORE_ID), the location of that register changes, and so it does need
> encoded in
> DT compatible.
Ok, I didn't know about such registers as there is not much public information
available.
Fair enough, there are some error reports about in different forums.
On the other hand we then must read out this register in more or less early
initialization
stages. Even if we know this information to be static and it could be as simple
as a list
of compatible strings in the driver.
> The string "ti,omap3430-gpu" tells us the revision if we cannot detect it (as
> in the current
> driver), and the SoC integration is generic anyway (just a reg and interrupt).
It of course tells, but may need a translation table that needs to be
maintained in a
different format. Basically the same what the comments show in a non-machine
readable
format.
I just wonder why the specific version can or should not become simply part of
the DTS
and needs this indirection.
Basically it is a matter of openness for future (driver) development and why it
needs
careful decisions.
So in other words: I would prefer to see the comments about versions encoded in
the device
tree binary to make it machine readable.
BR and thanks,
Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
Hi, > Am 05.12.2023 um 14:29 schrieb Maxime Ripard : > > Hi, > > On Tue, Dec 05, 2023 at 09:18:58AM +0100, H. Nikolaus Schaller wrote: >>> Am 05.12.2023 um 07:57 schrieb Maxime Ripard : >>> >>> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote: >>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from >>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC, >>>> including register space and interrupts. Clocks, reset, and power domain >>>> information is SoC specific. >>>> >>>> Signed-off-by: Andrew Davis >>>> --- >>>> .../devicetree/bindings/gpu/img,powervr.yaml | 69 +-- >>>> 1 file changed, 63 insertions(+), 6 deletions(-) >>> >>> I think it would be best to have a separate file for this, img,sgx.yaml >>> maybe? >> >> Why? > > Because it's more convenient? Is it? >> The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 >> and 6++: >> >> https://en.wikipedia.org/wiki/PowerVR > > That's not really relevant as far as bindings go. But maybe for choosing binding file names. Well they are machine readable but sometimes humans work with them. > We have multiple > binding files for devices of the same generation, or single bindings > covering multiple generations. > > The important part is that every compatible is documented. It doesn't > really matter how or where. Yes, and that is why I would find it more convenient to have a single "img,powervr.yaml" for all variations unless it becomes filled with unrelated stuff (which isn't as far as I see). BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
> Am 05.12.2023 um 07:57 schrieb Maxime Ripard : > > On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote: >> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from >> multiple vendors. Describe how the SGX GPU is integrated in these SoC, >> including register space and interrupts. Clocks, reset, and power domain >> information is SoC specific. >> >> Signed-off-by: Andrew Davis >> --- >> .../devicetree/bindings/gpu/img,powervr.yaml | 69 +-- >> 1 file changed, 63 insertions(+), 6 deletions(-) > > I think it would be best to have a separate file for this, img,sgx.yaml > maybe? Why? The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 6++: https://en.wikipedia.org/wiki/PowerVR So I would suggest to keep either img,powervr.yaml for all of them or img,powervr-sgx.yaml img,powervr-rogue.yaml etc. But as far as I can see the hardware integration into SoC (and hence description) is quite similar so a single file should suffice. BR, Nikolaus
Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
Hi Andrew,
> Am 04.12.2023 um 19:22 schrieb Andrew Davis :
>
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors.
Great and thanks for the new attempt to get at least the Device Tree side
upstream. Really appreciated!
> Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts.
> Clocks, reset, and power domain
> information is SoC specific.
Indeed. This makes it understandable why you did not directly
take our scheme from the openpvrsgx project.
>
> Signed-off-by: Andrew Davis
> ---
> .../devicetree/bindings/gpu/img,powervr.yaml | 69 +--
> 1 file changed, 63 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> index a13298f1a1827..9f036891dad0b 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> @@ -11,11 +11,33 @@ maintainers:
> - Frank Binns
>
> properties:
> + $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> compatible:
> -items:
> - - enum:
> - - ti,am62-gpu
> - - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +oneOf:
> + - items:
> + - enum:
> + - ti,am62-gpu
> + - const: img,img-axe # IMG AXE GPU model/revision is fully
> discoverable
> + - items:
> + - enum:
> + - ti,omap3430-gpu # Rev 121
> + - ti,omap3630-gpu # Rev 125
Is the "Rev 121" and "Rev 125" a property of the SoC integration
(clock/reset/power
hookup etc.) or of the integrated SGX core?
In my understanding the Revs are different variants of the SGX core (errata
fixes, instruction set, pipeline size etc.). And therefore the current driver
code
has to be configured by some macros to handle such cases.
So the Rev should IMHO be part of the next line:
> + - const: img,powervr-sgx530
+ - enum:
+ - img,powervr-sgx530-121
+ - img,powervr-sgx530-125
We have a similar definition in the openpvrsgx code.
Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";
(I don't mind about the powervr- prefix).
This would allow a generic and universal sgx driver (loaded through just
matching
"img,sgx530") to handle the errata and revision specifics at runtime based on
the
compatible entry ("img,sgx530-121") and know about SoC integration
("ti,omap3-sgx530-121").
And user-space can be made to load the right firmware variant based on
"img,sgx530-121"
I don't know if there is some register which allows to discover the revision
long
before the SGX subsystem is initialized and the firmware is up and running.
What I know is that it is possible to read out the revision after starting the
firmware
but it may just echo the version number of the firmware binary provided from
user-space.
> + - items:
> + - enum:
> + - ingenic,jz4780-gpu # Rev 130
> + - ti,omap4430-gpu # Rev 120
> + - const: img,powervr-sgx540
> + - items:
> + - enum:
> + - allwinner,sun6i-a31-gpu # MP2 Rev 115
> + - ti,omap4470-gpu # MP1 Rev 112
> + - ti,omap5432-gpu # MP2 Rev 105
> + - ti,am5728-gpu # MP2 Rev 116
> + - ti,am6548-gpu # MP1 Rev 117
> + - const: img,powervr-sgx544
>
> reg:
> maxItems: 1
> @@ -40,8 +62,6 @@ properties:
> required:
> - compatible
> - reg
> - - clocks
> - - clock-names
> - interrupts
>
> additionalProperties: false
> @@ -56,6 +76,43 @@ allOf:
> properties:
> clocks:
> maxItems: 1
> + required:
> +- clocks
> +- clock-names
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: ti,am654-sgx544
> +then:
> + properties:
> +power-domains:
> + minItems: 1
> + required:
> +- power-domains
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: allwinner,sun6i-a31-gpu
> +then:
> + properties:
> +clocks:
> + minItems: 2
> +clock-names:
> + minItems: 2
> + required:
> +- clocks
> +- clock-names
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: ingenic,jz4780-gpu
> +then:
> + required:
> +- clocks
> +- clock-names
>
> examples:
> - |
> --
> 2.39.2
>
BR and thanks,
Nikolaus
Re: [PATCH v9 00/20] Imagination Technologies PowerVR DRM driver
> Am 22.11.2023 um 20:34 schrieb Maxime Ripard : > > Hi, > > On Wed, Nov 22, 2023 at 04:34:21PM +, Donald Robson wrote: >> This patch series adds the initial DRM driver for Imagination Technologies >> PowerVR >> GPUs, starting with those based on our Rogue architecture. It's worth >> pointing >> out that this is a new driver, written from the ground up, rather than a >> refactored version of our existing downstream driver (pvrsrvkm). >> >> This new DRM driver supports: >> - GEM shmem allocations >> - dma-buf / PRIME >> - Per-context userspace managed virtual address space >> - DRM sync objects (binary and timeline) >> - Power management suspend / resume >> - GPU job submission (geometry, fragment, compute, transfer) >> - META firmware processor >> - MIPS firmware processor >> - GPU hang detection and recovery >> >> Currently our main focus is on the AXE-1-16M GPU. Testing so far has been >> done >> using a TI SK-AM62 board (AXE-1-16M GPU). The driver has also been confirmed >> to >> work on the BeaglePlay board. Firmware for the AXE-1-16M can be found here: >> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr >> >> A Vulkan driver that works with our downstream kernel driver has already been >> merged into Mesa [1][2]. Support for this new DRM driver is being maintained >> in >> a merge request [3], with the branch located here: >> https://gitlab.freedesktop.org/frankbinns/mesa/-/tree/powervr-winsys >> >> Vulkan driver links referred to above: >> [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15243 >> [2] >> https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/imagination/vulkan >> [3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15507 >> >> Job stream formats are documented at: >> https://gitlab.freedesktop.org/mesa/mesa/-/blob/f8d2b42ae65c2f16f36a43e0ae39d288431e4263/src/imagination/csbgen/rogue_kmd_stream.xml >> >> The Vulkan driver is progressing towards Vulkan 1.0. The current combination >> of this >> kernel driver with the Mesa Vulkan driver (powervr-mesa-next branch) >> successfully >> completes Vulkan CTS 1.3.4.1 in our local runs. The driver is expected to >> pass the >> Khronos Conformance Process once the submission is made. >> >> The code in this patch series, along with the needed dts changes can be >> found here: >> https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/dev/v9_dts >> The full development history can be found here: >> https://gitlab.freedesktop.org/frankbinns/powervr/-/tree/powervr-next > > I just merged all the patches to drm-misc-next. > > Congrats :) A big applause to the team that accomplished this! Let me take this opportunity to ask if there could be a similar effort supported by imgtec for the SGX drivers? There are still a lot of devices using this version of PVR in the wild, like OpenPandora or Pyra Handheld, that are stuck with older Linux kernels (which are now unmaintained) because there are no compatible SGX drivers for modern kernels. And we have the openpvrsgx community that can definitely help with debugging (we all own various OMAP and jz4780 devices), but we lack the documentation to actually develop and upstream such a driver (and user-space code) ourselves. Nikolaus
Re: [PATCH] drm/mipi-dsi: Fix detach call without attach
Hi, I have tested this on an OMAP5 Pyra. > Am 21.09.2023 um 12:50 schrieb Tomi Valkeinen > : > > It's been reported that DSI host driver's detach can be called without > the attach ever happening: > > https://lore.kernel.org/all/20230412073954.20601-1-t...@atomide.com/ > This patch works equally well as my proposal and is indeed a better solution (solving the issue and not just suppressing a warning). Tested-by: H. Nikolaus Schaller BR and thanks, Nikolaus
[PATCH] omap: dsi: do not WARN on detach if dsidev was never attached
dsi_init_output() called by dsi_probe() may fail. In that
case mipi_dsi_host_unregister() is called which may call
omap_dsi_host_detach() with uninitialized dsi->dsidev
because omap_dsi_host_attach() was never called before.
This happens if the panel driver asks for an EPROBE_DEFER.
So let's suppress the WARN() in this special case.
[7.416759] WARNING: CPU: 0 PID: 32 at
drivers/gpu/drm/omapdrm/dss/dsi.c:4419 omap_dsi_host_detach+0x3c/0xbc [omapdrm]
[7.436053] Modules linked in: ina2xx_adc snd_soc_ts3a227e bq2429x_charger
bq27xxx_battery_i2c(+) bq27xxx_battery ina2xx tca8418_keypad as5013(+) omapdrm
hci_uart cec palmas_pwrbutton btbcm bmp280_spi palmas_gpadc bluetooth usb3503
ecdh_generic bmc150_accel_i2c bmg160_i2c ecc bmc150_accel_core bmg160_core
bmc150_magn_i2c bmp280_i2c bmc150_magn bno055 industrialio_triggered_buffer
bmp280 kfifo_buf snd_soc_omap_aess display_connector drm_kms_helper syscopyarea
snd_soc_omap_mcbsp snd_soc_ti_sdma sysfillrect ti_tpd12s015 sysimgblt
fb_sys_fops wwan_on_off snd_soc_gtm601 generic_adc_battery drm
snd_soc_w2cbw003_bt industrialio drm_panel_orientation_quirks pwm_bl
pwm_omap_dmtimer ip_tables x_tables ipv6 autofs4
[7.507068] CPU: 0 PID: 32 Comm: kworker/u4:2 Tainted: GW
6.1.0-rc3-letux-lpae+ #11107
[7.516964] Hardware name: Generic OMAP5 (Flattened Device Tree)
[7.523284] Workqueue: events_unbound deferred_probe_work_func
[7.529456] unwind_backtrace from show_stack+0x10/0x14
[7.534972] show_stack from dump_stack_lvl+0x40/0x4c
[7.540315] dump_stack_lvl from __warn+0xb0/0x164
[7.545379] __warn from warn_slowpath_fmt+0x70/0x9c
[7.550625] warn_slowpath_fmt from omap_dsi_host_detach+0x3c/0xbc [omapdrm]
[7.558137] omap_dsi_host_detach [omapdrm] from
mipi_dsi_remove_device_fn+0x10/0x20
[7.566376] mipi_dsi_remove_device_fn from device_for_each_child+0x60/0x94
[7.573729] device_for_each_child from mipi_dsi_host_unregister+0x20/0x54
[7.580992] mipi_dsi_host_unregister from dsi_probe+0x5d8/0x744 [omapdrm]
[7.588315] dsi_probe [omapdrm] from platform_probe+0x58/0xa8
[7.594542] platform_probe from really_probe+0x144/0x2ac
[7.600249] really_probe from __driver_probe_device+0xc4/0xd8
[7.606411] __driver_probe_device from driver_probe_device+0x3c/0xb8
[7.613216] driver_probe_device from __device_attach_driver+0x58/0xbc
[7.620115] __device_attach_driver from bus_for_each_drv+0xa0/0xb4
[7.626737] bus_for_each_drv from __device_attach+0xdc/0x150
[7.632808] __device_attach from bus_probe_device+0x28/0x80
[7.638792] bus_probe_device from deferred_probe_work_func+0x84/0xa0
[7.645595] deferred_probe_work_func from process_one_work+0x1a4/0x2d8
[7.652587] process_one_work from worker_thread+0x214/0x2b8
[7.658567] worker_thread from kthread+0xe4/0xf0
[7.663542] kthread from ret_from_fork+0x14/0x1c
[7.668515] Exception stack(0xf01b5fb0 to 0xf01b5ff8)
[7.673827] 5fa0:
[7.682435] 5fc0:
[7.691038] 5fe0: 0013
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index ea63c64d3a1ab..c37eb6b1b9a39 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -4411,7 +4411,7 @@ static int omap_dsi_host_detach(struct mipi_dsi_host
*host,
{
struct dsi_data *dsi = host_to_omap(host);
- if (WARN_ON(dsi->dsidev != client))
+ if (!dsi->dsidev || WARN_ON(dsi->dsidev != client))
return -EINVAL;
cancel_delayed_work_sync(>dsi_disable_work);
--
2.42.0
Re: [PATCH] drm/omap: dsi: Fix deferred probe warnings
Hi Tomi and Tony,
> Am 13.09.2023 um 13:59 schrieb Tomi Valkeinen
> :
>
> On 12/04/2023 10:39, Tony Lindgren wrote:
>> We may not have dsi->dsidev initialized during probe, and that can
>> lead into various dsi related warnings as omap_dsi_host_detach() gets
>> called with dsi->dsidev set to NULL.
>> The warnings can be "Fixed dependency cycle(s)" followed by a
>> WARNING: CPU: 0 PID: 787 at drivers/gpu/drm/omapdrm/dss/dsi.c:4414.
>> Let's fix the warnings by checking for a valid dsi->dsidev.
>> Signed-off-by: Tony Lindgren
>> ---
>> drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
>> @@ -4411,7 +4411,7 @@ static int omap_dsi_host_detach(struct mipi_dsi_host
>> *host,
>> {
>> struct dsi_data *dsi = host_to_omap(host);
>> - if (WARN_ON(dsi->dsidev != client))
>> +if (dsi->dsidev && WARN_ON(dsi->dsidev != client))
>> return -EINVAL;
>> cancel_delayed_work_sync(>dsi_disable_work);
>
> Shouldn't this rather be
>
> if (!dsi->dsidev)
> return 0;
>
> before the if (WARN_ON(dsi->dsidev != client)) line?
Yes you are right. We have a different variant in our Pyra kernel:
What we currently have in our Pyra tree is:
https://git.goldelico.com/?p=letux-kernel.git;a=commitdiff;h=5bf7bd64eec1eb924e794e8d6600919f0dae8c5a;hp=27a0cd6263194d1465e9c53293d35f8c8c988f9d
struct dsi_data *dsi = host_to_omap(host);
- if (WARN_ON(dsi->dsidev != client))
+printk("%s\n", __func__);
+
+ if (!dsi->dsidev || WARN_ON(dsi->dsidev != client))
return -EINVAL;
cancel_delayed_work_sync(>dsi_disable_work);
>
> If dsi->dsidev is NULL, then attach hasn't been called, and we shouldn't do
> anything in the detach callback either.
>
> With your change we'll end up doing all the work in the detach callback,
> without ever doing their counterpart in the attach side.
If useful, I can post above mentioned patch (without printk).
BR and thanks,
Nikolaus
Re: [PATCH v3 00/17] Imagination Technologies PowerVR DRM driver
Hi Frank, I have added Merlijn who is doing a lot with PVRSGX for Maemo-Leste and the phone-devel list since most SoC we find using a PVRSGX are smartphone processors. > Am 26.06.2023 um 15:45 schrieb Frank Binns : > > Hi Nikolaus, > >> >> Some questions to the author of the new driver: >> - are there plans to support SGX5 (the predecessor of Rogue6)? > > We don't currently have any plans to support SGX. Our main focus is currently > on > Rogue and then we'll move onto Volcanic. Okay, that's completely understandable from a commercial perspective. > >> - will this be able to run the existing firmware and user-space code of >> pvrsrvkm? > > I'm afraid not. The interface for existing firmware and userspace code were > designed with different requirements in mind and don't cater to the kernel's > strict compatibility guarantees. As such, the uapi for this new driver is > very different to pvrsrvkm's, although naturally there are similarities: > https://gitlab.freedesktop.org/sarah-walker-imgtec/powervr/-/blob/dev/v3/include/uapi/drm/pvr_drm.h This makes sense. So the new Rogue/Volcanic and the older PVRSGX drivers should be able to coexist (at least in source code as there is no hardware having both). > We've also worked with our firmware team to make changes to the firmware > interface to better support this new driver. Specifically, parts of the > firmware > interface are no longer conditional on the GPU feature set / hardware > workarounds, meaning we now have a single interface which can work across all > existing Rogue GPUs, which makes things a lot easier for this new kernel > driver. That is what I have dreamed of for SGX as well. We could have replaced all the #if for specific versions and errata by some code to runtime check with the device tree for the specific SGX version. But this was never done because it is complex, difficult to automate and our means for testing things are limited. And we could not decide which DDK version we should build on as there is no common denominator for all SoC. > >> - or will it have new firmware and user-space code for these older chips? >> - or will there be open user-space code for SGX (and Rogue)? > > We're using the same Rogue firmware as our closed source driver, just with > modifications to the interface to cater for this new kernel driver. In terms > of Ok. Well, it was to be expected that SGX and Rogue firmware are quite different. > userspace, we already have a Vulkan driver upstreamed to Mesa: > https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/imagination/vulkan Nice! > > and will be working to enable GLES support via Mesa's Zink GL(ES)-to-Vulkan > translation layer. This naturally limits support to Series 6 onwards, as > anything older isn't capable of supporting Vulkan. I see. > >> >>> Specifically I would ask that the DT bindings include all old and new >>> PowerVR >>> hardware in one go, unless they have very specific hardware definition >>> needs, >>> which I doubt. >> >> Our current bindings for all SoC with a SGX5 GPU inside and which have at >> least >> some official Linux support are here: >> >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/omap-pvr-soc-glue-v8/Documentation/devicetree/bindings/gpu/img%2Cpvrsgx.yaml >> >> There was an attempt to upstream at least this plus glue code (i.e. device >> tree >> sources) some years ago but there was no consensus about the number and >> names of >> clocks that should be included in such a bindings document. > > I've taken a look and your bindings look very similar to the ones we've come > up > with. If you decide to attempt to upstream these again, please feel free to CC > me, Sarah and Donald (all on this email chain) so we can provide some > feedback. That is good! It would be a good moment to give it another try as we can have even more reviewers than before... > >> >>> Also I think they could use your help to get the proper firmware for the >>> older >>> hardware licensed properly from Imagination and included into linux-firmware >>> so they do not need to ship files on the side. >> >> Indeed, this and some "universal" user-space code would help a lot. Currently >> we have collected a lot of binaries for several architectures (e.g. Intel, >> OMAP, JZ4780), >> but all from different DDK versions and very different assumptions about >> system >> library versions. > > The way the SGX driver was designed means that it has to be built for a > specific > GPU, the version of the firmware, userspace driver(s) & kernel driver have to > exactly match and the build configuration has to match as well. Essentially, > we > don't have "universal" userspace code ourselves. With our focus being on Rogue > and beyond, we don't currently have any plans to work on this. Hm. This makes me wonder if it could be possible to open source the SGX code since it is a different architecture than Rogue, is no longer your focus and AFAIK the
Re: [PATCH v3 00/17] Imagination Technologies PowerVR DRM driver
Hi Linus, thanks for sharing this conversation with me. > Am 16.06.2023 um 14:29 schrieb Linus Walleij : > > Hi Sarah, > > thanks for starting this long awaited work! > > On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker wrote: > >> This patch series adds the initial DRM driver for Imagination Technologies >> PowerVR >> GPUs, starting with those based on our Rogue architecture. It's worth >> pointing >> out that this is a new driver, written from the ground up, rather than a >> refactored version of our existing downstream driver (pvrsrvkm). Great! > > This seems to be a fairly good starting point, a bit of trade-off > between latest-and-greatest > and recent enough devices that need aftermarket support. > > I assume you are aware of the community existing around Series 5 > (should be the immediate > predecessor to Rogue?): > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx > > I don't know how active those people are these days, but I can see that a > branch Well, there hasn't been much progress due to lack of documentation and compatibility issues of user-space code. Just keeping the code compatible to latest upstream kernels. But at least for OMAP3 and OMAP5 processors people are actively using this work. There is even a gaming console (www.pyra-handheld.com) in active production with a strong need for an up-to-date SGX544 driver running on OMAP5. > was updated for v6.4-rc3 just three weeks ago. > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/pvrsrvkm-6.4-rc3 > > I think it would be good for community building to make sure that you get > these > people involved in reviewing, especially neutral stuff like device tree > bindings > but also to make sure no architectural choices are done that will make it hard > to retrofit a proper driver for the older engines if this community > decide to work > on it. Some questions to the author of the new driver: - are there plans to support SGX5 (the predecessor of Rogue6)? - will this be able to run the existing firmware and user-space code of pvrsrvkm? - or will it have new firmware and user-space code for these older chips? - or will there be open user-space code for SGX (and Rogue)? > > Specifically I would ask that the DT bindings include all old and new PowerVR > hardware in one go, unless they have very specific hardware definition needs, > which I doubt. Our current bindings for all SoC with a SGX5 GPU inside and which have at least some official Linux support are here: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/omap-pvr-soc-glue-v8/Documentation/devicetree/bindings/gpu/img%2Cpvrsgx.yaml There was an attempt to upstream at least this plus glue code (i.e. device tree sources) some years ago but there was no consensus about the number and names of clocks that should be included in such a bindings document. > > Also I think they could use your help to get the proper firmware for the older > hardware licensed properly from Imagination and included into linux-firmware > so they do not need to ship files on the side. Indeed, this and some "universal" user-space code would help a lot. Currently we have collected a lot of binaries for several architectures (e.g. Intel, OMAP, JZ4780), but all from different DDK versions and very different assumptions about system library versions. > > Yours, > Linus Walleij Best regards, Nikolaus Schaller
Re: [PATCH v3 00/17] Imagination Technologies PowerVR DRM driver
Hi Linus, thanks for sharing this conversation with me. > Am 16.06.2023 um 14:29 schrieb Linus Walleij : > > Hi Sarah, > > thanks for starting this long awaited work! > > On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker wrote: > >> This patch series adds the initial DRM driver for Imagination Technologies >> PowerVR >> GPUs, starting with those based on our Rogue architecture. It's worth >> pointing >> out that this is a new driver, written from the ground up, rather than a >> refactored version of our existing downstream driver (pvrsrvkm). Great! > > This seems to be a fairly good starting point, a bit of trade-off > between latest-and-greatest > and recent enough devices that need aftermarket support. > > I assume you are aware of the community existing around Series 5 > (should be the immediate > predecessor to Rogue?): > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx > > I don't know how active those people are these days, but I can see that a > branch Well, there hasn't been much progress due to lack of documentation and compatibility issues of user-space code. Just keeping the code compatible to latest upstream kernels. But at least for OMAP3 and OMAP5 processors people are actively using this work. There is even a gaming console (www.pyra-handheld.com) in active production with a strong need for an up-to-date SGX544 driver running on OMAP5. > was updated for v6.4-rc3 just three weeks ago. > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/pvrsrvkm-6.4-rc3 > > I think it would be good for community building to make sure that you get > these > people involved in reviewing, especially neutral stuff like device tree > bindings > but also to make sure no architectural choices are done that will make it hard > to retrofit a proper driver for the older engines if this community > decide to work > on it. Some questions to the author of the new driver: - are there plans to support SGX5 (the predecessor of Rogue6)? - will this be able to run the existing firmware and user-space code of pvrsrvkm? - or will it have new firmware and user-space code for these older chips? - or will there be open user-space code for SGX (and Rogue)? > > Specifically I would ask that the DT bindings include all old and new PowerVR > hardware in one go, unless they have very specific hardware definition needs, > which I doubt. Our current bindings for all SoC with a SGX5 GPU inside and which have at least some official Linux support are here: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/omap-pvr-soc-glue-v8/Documentation/devicetree/bindings/gpu/img%2Cpvrsgx.yaml There was an attempt to upstream at least this plus glue code (i.e. device tree sources) some years ago but there was no consensus about the number and names of clocks that should be included in such a bindings document. > > Also I think they could use your help to get the proper firmware for the older > hardware licensed properly from Imagination and included into linux-firmware > so they do not need to ship files on the side. Indeed, this and some "universal" user-space code would help a lot. Currently we have collected a lot of binaries for several architectures (e.g. Intel, OMAP, JZ4780), but all from different DDK versions and very different assumptions about system library versions. > > Yours, > Linus Walleij Best regards, Nikolaus Schaller
Re: [PATCH] drm/omap: dsi: Fix deferred probe warnings
> Am 12.04.2023 um 10:50 schrieb Laurent Pinchart > : > > Hi Tony, > > Thank you for the patch. > > On Wed, Apr 12, 2023 at 10:39:53AM +0300, Tony Lindgren wrote: >> We may not have dsi->dsidev initialized during probe, and that can >> lead into various dsi related warnings as omap_dsi_host_detach() gets >> called with dsi->dsidev set to NULL. >> >> The warnings can be "Fixed dependency cycle(s)" followed by a >> WARNING: CPU: 0 PID: 787 at drivers/gpu/drm/omapdrm/dss/dsi.c:4414. > > How can this happen ? I assume .detach() can't be called without a > priori successful call to .attach(), that that sets dsi->dsidev. I have a similar patch (not submitted because it looks like a workaround) in our LetuxOS kernel: https://git.goldelico.com/?p=letux-kernel.git;a=commitdiff;h=0656acb534439d4546b33826de62694e1df1b8ad There I had commented: dsi_init_output() called by dsi_probe() may fail. In that case mipi_dsi_host_unregister() is called which may call omap_dsi_host_detach() with uninitialized dsi->dsidev because omap_dsi_host_attach() was never called before. This happens if the panel driver asks for an EPROBE_DEFER. So let's suppress the WARN() in this special case. [7.416759] WARNING: CPU: 0 PID: 32 at drivers/gpu/drm/omapdrm/dss/dsi.c:4419 omap_dsi_host_detach+0x3c/0xbc [omapdrm] [7.436053] Modules linked in: ina2xx_adc snd_soc_ts3a227e bq2429x_charger bq27xxx_battery_i2c(+) bq27xxx_battery ina2xx tca8418_keypad as5013(+) omapdrm hci_uart cec palmas_pwrbutton btbcm bmp280_spi palmas_gpadc bluetooth usb3503 ecdh_generic bmc150_accel_i2c bmg160_i2c ecc bmc150_accel_core bmg160_core bmc150_magn_i2c bmp280_i2c bmc150_magn bno055 industrialio_triggered_buffer bmp280 kfifo_buf snd_soc_omap_aess display_connector drm_kms_helper syscopyarea snd_soc_omap_mcbsp snd_soc_ti_sdma sysfillrect ti_tpd12s015 sysimgblt fb_sys_fops wwan_on_off snd_soc_gtm601 generic_adc_battery drm snd_soc_w2cbw003_bt industrialio drm_panel_orientation_quirks pwm_bl pwm_omap_dmtimer ip_tables x_tables ipv6 autofs4 [7.507068] CPU: 0 PID: 32 Comm: kworker/u4:2 Tainted: GW 6.1.0-rc3-letux-lpae+ #11107 [7.516964] Hardware name: Generic OMAP5 (Flattened Device Tree) [7.523284] Workqueue: events_unbound deferred_probe_work_func [7.529456] unwind_backtrace from show_stack+0x10/0x14 [7.534972] show_stack from dump_stack_lvl+0x40/0x4c [7.540315] dump_stack_lvl from __warn+0xb0/0x164 [7.545379] __warn from warn_slowpath_fmt+0x70/0x9c [7.550625] warn_slowpath_fmt from omap_dsi_host_detach+0x3c/0xbc [omapdrm] [7.558137] omap_dsi_host_detach [omapdrm] from mipi_dsi_remove_device_fn+0x10/0x20 [7.566376] mipi_dsi_remove_device_fn from device_for_each_child+0x60/0x94 [7.573729] device_for_each_child from mipi_dsi_host_unregister+0x20/0x54 [7.580992] mipi_dsi_host_unregister from dsi_probe+0x5d8/0x744 [omapdrm] [7.588315] dsi_probe [omapdrm] from platform_probe+0x58/0xa8 [7.594542] platform_probe from really_probe+0x144/0x2ac [7.600249] really_probe from __driver_probe_device+0xc4/0xd8 [7.606411] __driver_probe_device from driver_probe_device+0x3c/0xb8 [7.613216] driver_probe_device from __device_attach_driver+0x58/0xbc [7.620115] __device_attach_driver from bus_for_each_drv+0xa0/0xb4 [7.626737] bus_for_each_drv from __device_attach+0xdc/0x150 [7.632808] __device_attach from bus_probe_device+0x28/0x80 [7.638792] bus_probe_device from deferred_probe_work_func+0x84/0xa0 [7.645595] deferred_probe_work_func from process_one_work+0x1a4/0x2d8 [7.652587] process_one_work from worker_thread+0x214/0x2b8 [7.658567] worker_thread from kthread+0xe4/0xf0 [7.663542] kthread from ret_from_fork+0x14/0x1c [7.668515] Exception stack(0xf01b5fb0 to 0xf01b5ff8) [7.673827] 5fa0: [7.682435] 5fc0: [7.691038] 5fe0: 0013 Hope this helps to find the real cause. BR, Nikolaus
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
Hi Ivaylo, > Am 31.10.2022 um 10:58 schrieb Ivaylo Dimitrov : > > > > On 31.10.22 г. 9:57 ч., H. Nikolaus Schaller wrote: >>> Am 31.10.2022 um 08:44 schrieb H. Nikolaus Schaller : >>> >>> Hi Ivaylo, >>> >>>> Am 31.10.2022 um 08:05 schrieb Ivaylo Dimitrov >>>> : >>>> >>>> HI Nikolaus, >>>> >>>> On 31.10.22 г. 0:08 ч., H. Nikolaus Schaller wrote: >>>>> Hi Ivaylo, >>>>> it took a while until I found time to test newer kernels (mainline + >>>>> Letux additions) >>>>> on the OMAP5 Pyra but unfortunately I did not get screen display for >>>>> v6.1. Even worse, >>>>> the console was flooded by >>>> >>>> Could you elaborate on that - do you have anything on the display (during >>>> boot or dunno). Do you have simplefb enabled, so boot log to be visible on >>>> the display? >>> >>> No bootlog enabled but I have some printk in the panel driver. It is >>> initially enabled, then disabled and enabled again. Then the issues start... >>> >>>> Is that wayland you are trying to run? Do you have PVR driver enabled? Did >>>> you try to boot vanilla kernel? >>> >>> I have tested with Debian Stretch with standard Xorg with "omap" driver. >>> PVR is not enabled. >> Have cross-checked: my setup uses the fbdev driver. > > omapfb and not omapdrm? or I am missing something. I just have "fbdev" in the xorg.conf. Certainly not the best choice but it seems to be the most generic setup without having to tweak every combination of user-space release and kernel version and hardware variant. Section "Monitor" Identifier "lcd" VendorName "BOE" ModelName "W677L" Option "Rotate" "right"# use TILER rotation DisplaySize 111 62 # LCD size in millimeters EndSection Section "Device" Identifier "display0" Driver "fbdev" Option "Monitor-DSI-1" "lcd" Option "HWcursor" "False" EndSection Of course the kernel config uses DRM_OMAP: root@letux:~# uname -a Linux letux 6.1.0-rc2-letux-lpae+ #11029 SMP PREEMPT Sun Oct 30 22:41:25 CET 2022 armv7l GNU/Linux root@letux:~# root@letux:~# ls -l /sys/devices/platform/omapdrm.0/drm/card1/card1-DSI-1 total 0 lrwxrwxrwx 1 root root0 Oct 31 10:03 device -> ../../card1 -r--r--r-- 1 root root 4096 Oct 31 10:03 dpms -r--r--r-- 1 root root0 Oct 31 10:03 edid -r--r--r-- 1 root root 4096 Oct 31 10:03 enabled -r--r--r-- 1 root root 4096 Oct 31 10:03 modes drwxr-xr-x 2 root root0 Oct 31 10:03 power -rw-r--r-- 1 root root 4096 Oct 31 10:03 status lrwxrwxrwx 1 root root0 Oct 31 10:00 subsystem -> ../../../../../../class/drm -rw-r--r-- 1 root root 4096 Oct 31 10:00 uevent root@letux:~# root@letux:~# gunzip
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
> Am 31.10.2022 um 08:44 schrieb H. Nikolaus Schaller : > > Hi Ivaylo, > >> Am 31.10.2022 um 08:05 schrieb Ivaylo Dimitrov : >> >> HI Nikolaus, >> >> On 31.10.22 г. 0:08 ч., H. Nikolaus Schaller wrote: >>> Hi Ivaylo, >>> it took a while until I found time to test newer kernels (mainline + Letux >>> additions) >>> on the OMAP5 Pyra but unfortunately I did not get screen display for v6.1. >>> Even worse, >>> the console was flooded by >> >> Could you elaborate on that - do you have anything on the display (during >> boot or dunno). Do you have simplefb enabled, so boot log to be visible on >> the display? > > No bootlog enabled but I have some printk in the panel driver. It is > initially enabled, then disabled and enabled again. Then the issues start... > >> Is that wayland you are trying to run? Do you have PVR driver enabled? Did >> you try to boot vanilla kernel? > > I have tested with Debian Stretch with standard Xorg with "omap" driver. PVR > is not enabled. Have cross-checked: my setup uses the fbdev driver. > And without your patch everything is fine on all kernels since 4.something. > > Vanilla kernel can not be booted on that machine - there is not even a device > tree... > >> >>> [ 39.419846] WARNING: CPU: 0 PID: 3673 at drivers/bus/omap_l3_noc.c:139 >>> l3_interrupt_handler+0x23c/0x330 >>> [ 39.429914] 4400.l3-noc:L3 Custom Error: MASTER MPU TARGET GPMC >>> (Idle): Data Access in Supervisor mode during Functional access >>> ... >> >> I have no idea what that error is supposed to mean. @Tony? > > A coincidence is that the display is sometimes showing some artistic > patterns. So maybe DMA accesses non-existing memory? > >> >>> making the system unuseable. >>> After doing some manual bisect by installing different kernel versions on >>> the boot SD card, >>> I was able to identify that it crept in between v5.18 and v5.19-rc1. A git >>> bisect on this >>> range (adding Letux patches on top of each bisect base) did reveal this >>> patch as the first bad one. >>> After reverting it seems as if I can use any v5.19 .. v6.1-rc2 kernel >>> without issues. >>> Now I wonder why this patch breaks my system? >> >> A wild guess - omap5 has some cache issues (as is visible from >> 7cb0d6c17b96b8bf3c25de2dfde4fdeb9191f4c3), which lead to the above. Before >> the patch *all* access to the BO backing memory was done through TILER/DMM, >> mitigating the issue. After the patch, whoever tries to render to >> non-scanout buffer is doing it directly to the memory, causing the issue. >> >> Another possibility - someone assumes that memory is always linear, which is >> true when it is accessed through DMM, but it is not after the patch. Do you >> have my "drm: pvrsgx: dmabuf import - Do not assume scatterlist memory is >> contiguous" patch in your PVR driver? Maybe there is another driver that >> lacks similar patch. > > Yes, it is included. > > Best regards, > Nikolaus > >> >> Regards, >> Ivo >> >>> BR and thanks, >>> Nikolaus >>>> Am 19.01.2022 um 11:23 schrieb Ivaylo Dimitrov >>>> : >>>> >>>> On devices with DMM, all allocations are done through either DMM or TILER. >>>> DMM/TILER being a limited resource means that such allocations will start >>>> to fail before actual free memory is exhausted. What is even worse is that >>>> with time DMM/TILER space gets fragmented to the point that even if we have >>>> enough free DMM/TILER space and free memory, allocation fails because there >>>> is no big enough free block in DMM/TILER space. >>>> >>>> Such failures can be easily observed with OMAP xorg DDX, for example - >>>> starting few GUI applications (so buffers for their windows are allocated) >>>> and then rotating landscape<->portrait while closing and opening new >>>> windows soon results in allocation failures. >>>> >>>> Fix that by mapping buffers through DMM/TILER only when really needed, >>>> like, for scanout buffers. >>>> >>>> Signed-off-by: Ivaylo Dimitrov >>>> --- >>>> drivers/gpu/drm/omapdrm/omap_gem.c | 12 >>>> 1 file changed, 8 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c &g
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
Hi Ivaylo,
> Am 31.10.2022 um 08:05 schrieb Ivaylo Dimitrov :
>
> HI Nikolaus,
>
> On 31.10.22 г. 0:08 ч., H. Nikolaus Schaller wrote:
>> Hi Ivaylo,
>> it took a while until I found time to test newer kernels (mainline + Letux
>> additions)
>> on the OMAP5 Pyra but unfortunately I did not get screen display for v6.1.
>> Even worse,
>> the console was flooded by
>
> Could you elaborate on that - do you have anything on the display (during
> boot or dunno). Do you have simplefb enabled, so boot log to be visible on
> the display?
No bootlog enabled but I have some printk in the panel driver. It is initially
enabled, then disabled and enabled again. Then the issues start...
> Is that wayland you are trying to run? Do you have PVR driver enabled? Did
> you try to boot vanilla kernel?
I have tested with Debian Stretch with standard Xorg with "omap" driver. PVR is
not enabled. And without your patch everything is fine on all kernels since
4.something.
Vanilla kernel can not be booted on that machine - there is not even a device
tree...
>
>> [ 39.419846] WARNING: CPU: 0 PID: 3673 at drivers/bus/omap_l3_noc.c:139
>> l3_interrupt_handler+0x23c/0x330
>> [ 39.429914] 4400.l3-noc:L3 Custom Error: MASTER MPU TARGET GPMC
>> (Idle): Data Access in Supervisor mode during Functional access
>> ...
>
> I have no idea what that error is supposed to mean. @Tony?
A coincidence is that the display is sometimes showing some artistic patterns.
So maybe DMA accesses non-existing memory?
>
>> making the system unuseable.
>> After doing some manual bisect by installing different kernel versions on
>> the boot SD card,
>> I was able to identify that it crept in between v5.18 and v5.19-rc1. A git
>> bisect on this
>> range (adding Letux patches on top of each bisect base) did reveal this
>> patch as the first bad one.
>> After reverting it seems as if I can use any v5.19 .. v6.1-rc2 kernel
>> without issues.
>> Now I wonder why this patch breaks my system?
>
> A wild guess - omap5 has some cache issues (as is visible from
> 7cb0d6c17b96b8bf3c25de2dfde4fdeb9191f4c3), which lead to the above. Before
> the patch *all* access to the BO backing memory was done through TILER/DMM,
> mitigating the issue. After the patch, whoever tries to render to non-scanout
> buffer is doing it directly to the memory, causing the issue.
>
> Another possibility - someone assumes that memory is always linear, which is
> true when it is accessed through DMM, but it is not after the patch. Do you
> have my "drm: pvrsgx: dmabuf import - Do not assume scatterlist memory is
> contiguous" patch in your PVR driver? Maybe there is another driver that
> lacks similar patch.
Yes, it is included.
Best regards,
Nikolaus
>
> Regards,
> Ivo
>
>> BR and thanks,
>> Nikolaus
>>> Am 19.01.2022 um 11:23 schrieb Ivaylo Dimitrov
>>> :
>>>
>>> On devices with DMM, all allocations are done through either DMM or TILER.
>>> DMM/TILER being a limited resource means that such allocations will start
>>> to fail before actual free memory is exhausted. What is even worse is that
>>> with time DMM/TILER space gets fragmented to the point that even if we have
>>> enough free DMM/TILER space and free memory, allocation fails because there
>>> is no big enough free block in DMM/TILER space.
>>>
>>> Such failures can be easily observed with OMAP xorg DDX, for example -
>>> starting few GUI applications (so buffers for their windows are allocated)
>>> and then rotating landscape<->portrait while closing and opening new
>>> windows soon results in allocation failures.
>>>
>>> Fix that by mapping buffers through DMM/TILER only when really needed,
>>> like, for scanout buffers.
>>>
>>> Signed-off-by: Ivaylo Dimitrov
>>> ---
>>> drivers/gpu/drm/omapdrm/omap_gem.c | 12
>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
>>> b/drivers/gpu/drm/omapdrm/omap_gem.c
>>> index 41c1a6d..cf57179 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
>>> @@ -821,10 +821,12 @@ int omap_gem_pin(struct drm_gem_object *obj,
>>> dma_addr_t *dma_addr)
>>> if (ret)
>>> goto fail;
>>>
>>> - if (priv->has_dmm) {
>>> - ret = omap_gem_pin_tiler(obj);
>>> -
Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER
Hi Ivaylo,
it took a while until I found time to test newer kernels (mainline + Letux
additions)
on the OMAP5 Pyra but unfortunately I did not get screen display for v6.1. Even
worse,
the console was flooded by
[ 39.419846] WARNING: CPU: 0 PID: 3673 at drivers/bus/omap_l3_noc.c:139
l3_interrupt_handler+0x23c/0x330
[ 39.429914] 4400.l3-noc:L3 Custom Error: MASTER MPU TARGET GPMC (Idle):
Data Access in Supervisor mode during Functional access
...
making the system unuseable.
After doing some manual bisect by installing different kernel versions on the
boot SD card,
I was able to identify that it crept in between v5.18 and v5.19-rc1. A git
bisect on this
range (adding Letux patches on top of each bisect base) did reveal this patch
as the first bad one.
After reverting it seems as if I can use any v5.19 .. v6.1-rc2 kernel without
issues.
Now I wonder why this patch breaks my system?
BR and thanks,
Nikolaus
> Am 19.01.2022 um 11:23 schrieb Ivaylo Dimitrov :
>
> On devices with DMM, all allocations are done through either DMM or TILER.
> DMM/TILER being a limited resource means that such allocations will start
> to fail before actual free memory is exhausted. What is even worse is that
> with time DMM/TILER space gets fragmented to the point that even if we have
> enough free DMM/TILER space and free memory, allocation fails because there
> is no big enough free block in DMM/TILER space.
>
> Such failures can be easily observed with OMAP xorg DDX, for example -
> starting few GUI applications (so buffers for their windows are allocated)
> and then rotating landscape<->portrait while closing and opening new
> windows soon results in allocation failures.
>
> Fix that by mapping buffers through DMM/TILER only when really needed,
> like, for scanout buffers.
>
> Signed-off-by: Ivaylo Dimitrov
> ---
> drivers/gpu/drm/omapdrm/omap_gem.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c
> index 41c1a6d..cf57179 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -821,10 +821,12 @@ int omap_gem_pin(struct drm_gem_object *obj, dma_addr_t
> *dma_addr)
> if (ret)
> goto fail;
>
> - if (priv->has_dmm) {
> - ret = omap_gem_pin_tiler(obj);
> - if (ret)
> - goto fail;
> + if (omap_obj->flags & OMAP_BO_SCANOUT) {
> + if (priv->has_dmm) {
> + ret = omap_gem_pin_tiler(obj);
> + if (ret)
> + goto fail;
> + }
> }
> } else {
> refcount_inc(_obj->pin_cnt);
> @@ -861,6 +863,8 @@ static void omap_gem_unpin_locked(struct drm_gem_object
> *obj)
> kfree(omap_obj->sgt);
> omap_obj->sgt = NULL;
> }
> + if (!(omap_obj->flags & OMAP_BO_SCANOUT))
> + return;
> if (priv->has_dmm) {
> ret = tiler_unpin(omap_obj->block);
> if (ret) {
> --
> 1.9.1
>
[PATCH v18 2/3] drm/ingenic: Implement proper .atomic_get_input_bus_fmts
From: Paul Cercueil
The .atomic_get_input_bus_fmts() callback of our top bridge should
return the possible input formats for a given output format. If the
requested output format is not supported, then NULL should be returned,
otherwise the bus format negociation will end with a bus format that the
encoder does not support.
Signed-off-by: Paul Cercueil
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 28 ++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index a4f5a323f4906..8eb0ad501a7b9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -833,6 +833,32 @@ static int ingenic_drm_bridge_atomic_check(struct
drm_bridge *bridge,
}
}
+static u32 *
+ingenic_drm_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ switch (output_fmt) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ case MEDIA_BUS_FMT_RGB888_3X8:
+ case MEDIA_BUS_FMT_RGB888_3X8_DELTA:
+ break;
+ default:
+ *num_input_fmts = 0;
+ return NULL;
+ }
+
+ return drm_atomic_helper_bridge_propagate_bus_fmt(bridge, bridge_state,
+ crtc_state,
conn_state,
+ output_fmt,
+ num_input_fmts);
+}
+
static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
{
struct ingenic_drm *priv = drm_device_get_priv(arg);
@@ -984,7 +1010,7 @@ static const struct drm_bridge_funcs
ingenic_drm_bridge_funcs = {
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
+ .atomic_get_input_bus_fmts =
ingenic_drm_bridge_atomic_get_input_bus_fmts,
};
static const struct drm_mode_config_funcs ingenic_drm_mode_config_funcs = {
--
2.33.0
[PATCH v18 3/3] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Note that there is no hpd-gpio installed on the CI20 board HDMI
connector. Hence there is no hpd detection by the connector driver
and we have to enable polling in the dw-hdmi core driver.
For that we need to set .poll_enabled but that struct component
can only be accessed by core code. Hence we use the public
setter function drm_kms_helper_hotplug_event() introduced before.
Also note that we disable Color Space Conversion since it is not
working on jz4780.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 103 ++
3 files changed, 113 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..72f8b44998a51
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
[PATCH v18 1/3] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code but is needed to make the CI20
board work.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v18 0/3] MIPS: JZ4780 and CI20 HDMI
PATCH V18 2022-04-07 13:16:10:
* removed CSC filter patches (3-5/6) by Neil Armstrong
as they no longer seem to be required
* added "Reviewed-by: Laurent Pinchart " to
ddc-en patch (6/6)
PATCH V17 2022-04-06 18:26:08:
* removed our local attempts to enable HPD because
"drm/bridge_connector: enable HPD by default if supported"
became available and solves the issue globally (by
nikita.yo...@cogentembedded.com)
* add new mechanism to disable Color Space Conversion (by
narmstr...@baylibre.com)
* rebased to v5.18-rc1 based drm-misc/drm-misc-next
PATCH V16 2022-02-26 18:13:02:
* fixed and renamed dw-hdmi bus negotiation patch (by narmstr...@baylibre.com)
* reordered and merged HPD fix (suggested by p...@crapouillou.net)
* fixed MODULE_ALIAS for dw-hdmi-ingenic (reported by p...@crapouillou.net)
* dropped some already merged commits from the series
PATCH V15 2022-02-12 16:50:54:
* remove already (elsewhere) merged commits (suggested by p...@crapouillou.net)
* clarify commit message for (now) 1/7 ((suggested by p...@crapouillou.net))
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cov
Re: [PATCH v17 5/6] drm/bridge: dw-hdmi: add YCBCR formats only if CSC is available
> Am 07.04.2022 um 10:29 schrieb Neil Armstrong : > > On 06/04/2022 18:26, H. Nikolaus Schaller wrote: >> otherwise they will produce a black HDMI screen. >> Signed-off-by: H. Nikolaus Schaller >> --- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> index b5a665c5e406e..ec40dd8865065 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -2628,10 +2628,12 @@ static u32 >> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, >> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; >> } >> - if (hdmi->sink_is_hdmi && info->color_formats & >> DRM_COLOR_FORMAT_YCBCR422) >> +if (hdmi->csc_available && hdmi->sink_is_hdmi && >> +(info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) >> output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; >> - if (hdmi->sink_is_hdmi && info->color_formats & >> DRM_COLOR_FORMAT_YCBCR444) >> +if (hdmi->csc_available && hdmi->sink_is_hdmi && >> +(info->color_formats & DRM_COLOR_FORMAT_YCBCR444)) >> output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >> /* Default 8bit RGB fallback */ > > This patch shouldn't be needed anymore with proper filtering in patch 1. It can indeed be removed as well. BR and thanks, Nikolaus
Re: [PATCH v17 6/6] drm/bridge: display-connector: add ddc-en gpio support
Hi Laurent, > Am 07.04.2022 um 09:30 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > Thank you for the patch. > > On Wed, Apr 06, 2022 at 06:26:08PM +0200, H. Nikolaus Schaller wrote: >> "hdmi-connector.yaml" bindings defines an optional property >> "ddc-en-gpios" for a single gpio to enable DDC operation. >> >> Usually this controls +5V power on the HDMI connector. >> This +5V may also be needed for HPD. >> >> This was not reflected in code but is needed to make the CI20 >> board work. >> >> Now, the driver activates the ddc gpio after probe and >> deactivates after remove so it is "almost on". >> >> But only if this driver is loaded (and not e.g. blacklisted >> as module). >> >> Signed-off-by: H. Nikolaus Schaller > > Reviewed-by: Laurent Pinchart Added to v18 (which is needed to remove some now redundant patches and fix a detail in the ingenic-drm driver). BR and thanks for review, Nikolaus
Re: [PATCH v17 4/6] drm/bridge: dw-hdmi: handle unusable or non-configured CSC module
Hi Neil,
> Am 07.04.2022 um 10:28 schrieb Neil Armstrong :
>
> Hi,
>
> On 06/04/2022 18:26, H. Nikolaus Schaller wrote:
>> From: Neil Armstrong
>> The dw-hdmi integrates an optional Color Space Conversion feature used
>> to handle color-space conversions.
>> On some platforms, the CSC isn't built-in or non-functional.
>> This adds the necessary code to disable the CSC functionality
>> and limit the bus format negotiation to force using the same
>> input bus format as the output bus format.
>> Signed-off-by: Neil Armstrong
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 100 +++---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
>> include/drm/bridge/dw_hdmi.h | 1 +
>> 3 files changed, 71 insertions(+), 31 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index f50af40e10340..b5a665c5e406e 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -158,6 +158,8 @@ struct dw_hdmi {
>> struct hdmi_data_info hdmi_data;
>> const struct dw_hdmi_plat_data *plat_data;
>> + bool csc_available; /* indicates if the CSC engine is
>> usable */
>> +
>> int vic;
>> u8 edid[HDMI_EDID_LEN];
>> @@ -1009,9 +1011,10 @@ static int is_color_space_interpolation(struct
>> dw_hdmi *hdmi)
>>static bool is_csc_needed(struct dw_hdmi *hdmi)
>> {
>> -return is_color_space_conversion(hdmi) ||
>> - is_color_space_decimation(hdmi) ||
>> - is_color_space_interpolation(hdmi);
>> +return hdmi->csc_available &&
>> + (is_color_space_conversion(hdmi) ||
>> +is_color_space_decimation(hdmi) ||
>> +is_color_space_interpolation(hdmi));
>> }
>>static void dw_hdmi_update_csc_coeffs(struct dw_hdmi *hdmi)
>> @@ -1064,6 +1067,9 @@ static void hdmi_video_csc(struct dw_hdmi *hdmi)
>> int interpolation = HDMI_CSC_CFG_INTMODE_DISABLE;
>> int decimation = 0;
>> + if (!hdmi->csc_available)
>> +return;
>> +
>> /* YCC422 interpolation to 444 mode */
>> if (is_color_space_interpolation(hdmi))
>> interpolation = HDMI_CSC_CFG_INTMODE_CHROMA_INT_FORMULA1;
>> @@ -2665,6 +2671,7 @@ static u32
>> *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>> u32 output_fmt,
>> unsigned int *num_input_fmts)
>> {
>> +struct dw_hdmi *hdmi = bridge->driver_private;
>> u32 *input_fmts;
>> unsigned int i = 0;
>> @@ -2683,62 +2690,81 @@ static u32
>> *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
>> /* 8bit */
>> case MEDIA_BUS_FMT_RGB888_1X24:
>> input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
>> -input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> -input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> +if (hdmi->csc_available) {
>> +input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> +input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> +}
>> break;
>> case MEDIA_BUS_FMT_YUV8_1X24:
>> input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> -input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> -input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
>> +if (hdmi->csc_available) {
>> +input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> +input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
>> +}
>> break;
>> case MEDIA_BUS_FMT_UYVY8_1X16:
>> input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> -input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> -input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
>> +if (hdmi->csc_available) {
>> +input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> +input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
>> +}
>> break;
>> /* 10bit */
>> case MEDIA_BUS_FMT_RGB101010_1X30:
>> input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> -input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
>> -input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
>> +if (hdmi->
[PATCH v17 2/6] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Note that there is no hpd-gpio installed on the CI20 board HDMI
connector. Hence there is no hpd detection by the connector driver
and we have to enable polling in the dw-hdmi core driver.
For that we need to set .poll_enabled but that struct component
can only be accessed by core code. Hence we use the public
setter function drm_kms_helper_hotplug_event() introduced before.
Also note that we disable Color Space Conversion since it is not
working on jz4780.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..10c56183613b0
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+ .disable_csc= 0,/* DRM_COLOR_FORMAT_YCBCR do not work */
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, in
[PATCH v17 4/6] drm/bridge: dw-hdmi: handle unusable or non-configured CSC module
From: Neil Armstrong
The dw-hdmi integrates an optional Color Space Conversion feature used
to handle color-space conversions.
On some platforms, the CSC isn't built-in or non-functional.
This adds the necessary code to disable the CSC functionality
and limit the bus format negotiation to force using the same
input bus format as the output bus format.
Signed-off-by: Neil Armstrong
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 100 +++---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f50af40e10340..b5a665c5e406e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -158,6 +158,8 @@ struct dw_hdmi {
struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
+ bool csc_available; /* indicates if the CSC engine is
usable */
+
int vic;
u8 edid[HDMI_EDID_LEN];
@@ -1009,9 +1011,10 @@ static int is_color_space_interpolation(struct dw_hdmi
*hdmi)
static bool is_csc_needed(struct dw_hdmi *hdmi)
{
- return is_color_space_conversion(hdmi) ||
- is_color_space_decimation(hdmi) ||
- is_color_space_interpolation(hdmi);
+ return hdmi->csc_available &&
+ (is_color_space_conversion(hdmi) ||
+ is_color_space_decimation(hdmi) ||
+ is_color_space_interpolation(hdmi));
}
static void dw_hdmi_update_csc_coeffs(struct dw_hdmi *hdmi)
@@ -1064,6 +1067,9 @@ static void hdmi_video_csc(struct dw_hdmi *hdmi)
int interpolation = HDMI_CSC_CFG_INTMODE_DISABLE;
int decimation = 0;
+ if (!hdmi->csc_available)
+ return;
+
/* YCC422 interpolation to 444 mode */
if (is_color_space_interpolation(hdmi))
interpolation = HDMI_CSC_CFG_INTMODE_CHROMA_INT_FORMULA1;
@@ -2665,6 +2671,7 @@ static u32
*dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
u32 output_fmt,
unsigned int *num_input_fmts)
{
+ struct dw_hdmi *hdmi = bridge->driver_private;
u32 *input_fmts;
unsigned int i = 0;
@@ -2683,62 +2690,81 @@ static u32
*dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
/* 8bit */
case MEDIA_BUS_FMT_RGB888_1X24:
input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
- input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
- input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ if (hdmi->csc_available) {
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ }
break;
case MEDIA_BUS_FMT_YUV8_1X24:
input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
- input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ if (hdmi->csc_available) {
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ }
break;
case MEDIA_BUS_FMT_UYVY8_1X16:
input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
- input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ if (hdmi->csc_available) {
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+ }
break;
/* 10bit */
case MEDIA_BUS_FMT_RGB101010_1X30:
input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
- input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
- input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ if (hdmi->csc_available) {
+ input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ }
break;
case MEDIA_BUS_FMT_YUV10_1X30:
input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
- input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
- input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ if (hdmi->csc_available) {
+ input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ }
break;
case MEDIA_BUS_FMT_UYVY10_1X20:
input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
- input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X
[PATCH v17 3/6] drm/bridge: dw-hdmi: filter out YUV output formats when DVI
From: Neil Armstrong
When the display is not an HDMI sink, only the RGB output format is
valid. Thus stop returning YUV output formats when sink is not HDMI.
Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format
negociation")
Signed-off-by: Neil Armstrong
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a563460f8d209..f50af40e10340 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2538,6 +2538,7 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
struct drm_connector *conn = conn_state->connector;
struct drm_display_info *info = >display_info;
struct drm_display_mode *mode = _state->mode;
+ struct dw_hdmi *hdmi = bridge->driver_private;
u8 max_bpc = conn_state->max_requested_bpc;
bool is_hdmi2_sink = info->hdmi.scdc.supported ||
(info->color_formats & DRM_COLOR_FORMAT_YCBCR420);
@@ -2564,7 +2565,7 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
* If the current mode enforces 4:2:0, force the output but format
* to 4:2:0 and do not add the YUV422/444/RGB formats
*/
- if (conn->ycbcr_420_allowed &&
+ if (hdmi->sink_is_hdmi && conn->ycbcr_420_allowed &&
(drm_mode_is_420_only(info, mode) ||
(is_hdmi2_sink && drm_mode_is_420_also(info, mode {
@@ -2595,36 +2596,36 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
*/
if (max_bpc >= 16 && info->bpc == 16) {
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48;
output_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48;
}
if (max_bpc >= 12 && info->bpc >= 12) {
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
output_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36;
}
if (max_bpc >= 10 && info->bpc >= 10) {
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (hdmi->sink_is_hdmi && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v17 0/6] MIPS: JZ4780 and CI20 HDMI
PATCH V17 2022-04-06 18:26:08:
* removed our local attempts to enable HPD because
"drm/bridge_connector: enable HPD by default if supported"
became available and solves the issue globally (by
nikita.yo...@cogentembedded.com)
* add new mechanism to disable Color Space Conversion (by
narmstr...@baylibre.com)
* rebased to v5.18-rc1 based drm-misc/drm-misc-next
PATCH V16 2022-02-26 18:13:02:
* fixed and renamed dw-hdmi bus negotiation patch (by narmstr...@baylibre.com)
* reordered and merged HPD fix (suggested by p...@crapouillou.net)
* fixed MODULE_ALIAS for dw-hdmi-ingenic (reported by p...@crapouillou.net)
* dropped some already merged commits from the series
PATCH V15 2022-02-12 16:50:54:
* remove already (elsewhere) merged commits (suggested by p...@crapouillou.net)
* clarify commit message for (now) 1/7 ((suggested by p...@crapouillou.net))
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits exc
[PATCH v17 6/6] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code but is needed to make the CI20
board work.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v17 5/6] drm/bridge: dw-hdmi: add YCBCR formats only if CSC is available
otherwise they will produce a black HDMI screen. Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index b5a665c5e406e..ec40dd8865065 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2628,10 +2628,12 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; } - if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) + if (hdmi->csc_available && hdmi->sink_is_hdmi && + (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)) output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + if (hdmi->csc_available && hdmi->sink_is_hdmi && + (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)) output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; /* Default 8bit RGB fallback */ -- 2.33.0
[PATCH v17 1/6] drm/ingenic: Implement proper .atomic_get_input_bus_fmts
From: Paul Cercueil
The .atomic_get_input_bus_fmts() callback of our top bridge should
return the possible input formats for a given output format. If the
requested output format is not supported, then NULL should be returned,
otherwise the bus format negociation will end with a bus format that the
encoder does not support.
Signed-off-by: Paul Cercueil
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 28 ++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index a4f5a323f4906..8eb0ad501a7b9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -833,6 +833,32 @@ static int ingenic_drm_bridge_atomic_check(struct
drm_bridge *bridge,
}
}
+static u32 *
+ingenic_drm_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state
*bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state
*conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ switch (output_fmt) {
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ case MEDIA_BUS_FMT_RGB888_3X8:
+ case MEDIA_BUS_FMT_RGB888_3X8_DELTA:
+ break;
+ default:
+ *num_input_fmts = 0;
+ return NULL;
+ }
+
+ return drm_atomic_helper_bridge_propagate_bus_fmt(bridge, bridge_state,
+ crtc_state,
conn_state,
+ output_fmt,
+ num_input_fmts);
+}
+
static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
{
struct ingenic_drm *priv = drm_device_get_priv(arg);
@@ -984,7 +1010,7 @@ static const struct drm_bridge_funcs
ingenic_drm_bridge_funcs = {
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
+ .atomic_get_input_bus_fmts =
ingenic_drm_bridge_atomic_get_input_bus_fmts,
};
static const struct drm_mode_config_funcs ingenic_drm_mode_config_funcs = {
--
2.33.0
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul, > Am 04.03.2022 um 19:41 schrieb H. Nikolaus Schaller : > > > >> Am 04.03.2022 um 19:33 schrieb Paul Cercueil : >> >> >> >> Le ven., mars 4 2022 at 19:15:13 +0100, H. Nikolaus Schaller >> a écrit : >>> Hi Paul, >>>> Am 04.03.2022 um 19:04 schrieb Paul Cercueil : >>>> Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller >>>> a écrit : >>>>> Hi Paul, Neil, >>>>>> Am 04.03.2022 um 17:47 schrieb Paul Cercueil : >>>>>> From what I understood in Nikolaus' last message, HDMI hotplug is >>>>>> actually correctly detected, so there's no need for polling. What is >>>>>> missing is the call to drm_kms_helper_hotplug_event *somewhere*, so that >>>>>> the information is correctly relayed to userspace. >>>>> Exactly. >>>>> As Maxime pointed out it should already be called by >>>>> drm_helper_hpd_irq_event() in dw_hdmi_irq() but isn't >>>>> because mode_config.poll_enabled isn't enabled. >>>>> So we can either >>>>> a) enable mode_config.poll_enabled so that it is called by >>>>> drm_helper_hpd_irq_event() or >>>>> b) make drm_kms_helper_hotplug_event() being called explicitly in >>>>> dw_hdmi_irq(). >>>>> We could guard that by mode_config.poll_enabled to avoid >>>>> drm_kms_helper_hotplug_event() >>>>> being called twice (but I think the "changed" mechanism will take care >>>>> of). >>>>>> I think this issue can be fixed by calling >>>>>> drm_bridge_connector_enable_hpd() on the connector in ingenic-drm-drv.c. >>>>> I don't see yet how this would solve it, but it may work. >>>> dw_hdmi_irq() calls drm_bridge_hpd_notify(), which would call >>>> bridge->hpd_cb() if it was non-NULL. >>> Ok, this is a case c). >>> I vaguely remember having tried to analyse what bridge->hpd_cb is but >>> stopped since it is NULL... >>>> Calling drm_bridge_connector_enable_hpd() will set the bridge->hpd_cb() >>>> callback to point to drm_bridge_connector_hpd_cb(), which itself will call >>>> drm_kms_helper_hotplug_event(). Therefore, all that is missing is one call >>>> to drm_bridge_connector_enable_hpd(). >>> Ah, ok, I see. >>>>> Anyways, this all is a missing feature (sometimes called "bug") of the >>>>> *dw-hdmi driver* and IMHO >>>>> neither of the connector nor the ingenic-drm-drv. >>> Well, a little more analysis shows that drm_bridge_connector_enable_hpd is >>> called >>> in the *-drv.c for some other plaforms: >>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-dev.c#L292 >>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-kms.c#L145 >>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_drv.c#L393 >>> https://elixir.bootlin.com/linux/v5.17-rc6/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L317 >>>>> So I think it should not be solved outside dw-hdmi. >>> Hm. Can we call drm_bridge_connector_enable_hpd() from inside dw-hdmi? >>> Or would this be the solution if merged? (I currently can't try code). >>> https://lore.kernel.org/lkml/a7d0b013-6114-07b3-0a7b-0d17db8a3...@cogentembedded.com/T/ >> >> Looks correct to me. It has been reviewed by two people so I believe it will >> be merged very soon. > > Great. I will try asap. If it works we can drop all our private ideas... > > And focus on the last missing piece for jz4780 HDMI: the output format > negotiation (which still is not working properly - but I have to analyse why). Yes, it works. And I see you have merged it to drm-misc-next so that I can build on it. So there is only the bus format negotiation to be understood and finally solved for v17. Great and thanks, Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
> Am 04.03.2022 um 19:33 schrieb Paul Cercueil : > > > > Le ven., mars 4 2022 at 19:15:13 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 04.03.2022 um 19:04 schrieb Paul Cercueil : >>> Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller >>> a écrit : >>>> Hi Paul, Neil, >>>>> Am 04.03.2022 um 17:47 schrieb Paul Cercueil : >>>>> From what I understood in Nikolaus' last message, HDMI hotplug is >>>>> actually correctly detected, so there's no need for polling. What is >>>>> missing is the call to drm_kms_helper_hotplug_event *somewhere*, so that >>>>> the information is correctly relayed to userspace. >>>> Exactly. >>>> As Maxime pointed out it should already be called by >>>> drm_helper_hpd_irq_event() in dw_hdmi_irq() but isn't >>>> because mode_config.poll_enabled isn't enabled. >>>> So we can either >>>> a) enable mode_config.poll_enabled so that it is called by >>>> drm_helper_hpd_irq_event() or >>>> b) make drm_kms_helper_hotplug_event() being called explicitly in >>>> dw_hdmi_irq(). >>>> We could guard that by mode_config.poll_enabled to avoid >>>> drm_kms_helper_hotplug_event() >>>> being called twice (but I think the "changed" mechanism will take care >>>> of). >>>>> I think this issue can be fixed by calling >>>>> drm_bridge_connector_enable_hpd() on the connector in ingenic-drm-drv.c. >>>> I don't see yet how this would solve it, but it may work. >>> dw_hdmi_irq() calls drm_bridge_hpd_notify(), which would call >>> bridge->hpd_cb() if it was non-NULL. >> Ok, this is a case c). >> I vaguely remember having tried to analyse what bridge->hpd_cb is but >> stopped since it is NULL... >>> Calling drm_bridge_connector_enable_hpd() will set the bridge->hpd_cb() >>> callback to point to drm_bridge_connector_hpd_cb(), which itself will call >>> drm_kms_helper_hotplug_event(). Therefore, all that is missing is one call >>> to drm_bridge_connector_enable_hpd(). >> Ah, ok, I see. >>>> Anyways, this all is a missing feature (sometimes called "bug") of the >>>> *dw-hdmi driver* and IMHO >>>> neither of the connector nor the ingenic-drm-drv. >> Well, a little more analysis shows that drm_bridge_connector_enable_hpd is >> called >> in the *-drv.c for some other plaforms: >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-dev.c#L292 >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-kms.c#L145 >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_drv.c#L393 >> https://elixir.bootlin.com/linux/v5.17-rc6/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L317 >>>> So I think it should not be solved outside dw-hdmi. >> Hm. Can we call drm_bridge_connector_enable_hpd() from inside dw-hdmi? >> Or would this be the solution if merged? (I currently can't try code). >> https://lore.kernel.org/lkml/a7d0b013-6114-07b3-0a7b-0d17db8a3...@cogentembedded.com/T/ > > Looks correct to me. It has been reviewed by two people so I believe it will > be merged very soon. Great. I will try asap. If it works we can drop all our private ideas... And focus on the last missing piece for jz4780 HDMI: the output format negotiation (which still is not working properly - but I have to analyse why). BR and thanks, Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul, > Am 04.03.2022 um 19:04 schrieb Paul Cercueil : > > > > Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, Neil, >>> Am 04.03.2022 um 17:47 schrieb Paul Cercueil : >>> From what I understood in Nikolaus' last message, HDMI hotplug is actually >>> correctly detected, so there's no need for polling. What is missing is the >>> call to drm_kms_helper_hotplug_event *somewhere*, so that the information >>> is correctly relayed to userspace. >> Exactly. >> As Maxime pointed out it should already be called by >> drm_helper_hpd_irq_event() in dw_hdmi_irq() but isn't >> because mode_config.poll_enabled isn't enabled. >> So we can either >> a) enable mode_config.poll_enabled so that it is called by >> drm_helper_hpd_irq_event() or >> b) make drm_kms_helper_hotplug_event() being called explicitly in >> dw_hdmi_irq(). >> We could guard that by mode_config.poll_enabled to avoid >> drm_kms_helper_hotplug_event() >> being called twice (but I think the "changed" mechanism will take care of). >>> I think this issue can be fixed by calling >>> drm_bridge_connector_enable_hpd() on the connector in ingenic-drm-drv.c. >> I don't see yet how this would solve it, but it may work. > > dw_hdmi_irq() calls drm_bridge_hpd_notify(), which would call > bridge->hpd_cb() if it was non-NULL. Ok, this is a case c). I vaguely remember having tried to analyse what bridge->hpd_cb is but stopped since it is NULL... > > Calling drm_bridge_connector_enable_hpd() will set the bridge->hpd_cb() > callback to point to drm_bridge_connector_hpd_cb(), which itself will call > drm_kms_helper_hotplug_event(). Therefore, all that is missing is one call to > drm_bridge_connector_enable_hpd(). Ah, ok, I see. >> Anyways, this all is a missing feature (sometimes called "bug") of the >> *dw-hdmi driver* and IMHO >> neither of the connector nor the ingenic-drm-drv. Well, a little more analysis shows that drm_bridge_connector_enable_hpd is called in the *-drv.c for some other plaforms: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-dev.c#L292 https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/imx/dcss/dcss-kms.c#L145 https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_drv.c#L393 https://elixir.bootlin.com/linux/v5.17-rc6/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L317 >> So I think it should not be solved outside dw-hdmi. Hm. Can we call drm_bridge_connector_enable_hpd() from inside dw-hdmi? Or would this be the solution if merged? (I currently can't try code). https://lore.kernel.org/lkml/a7d0b013-6114-07b3-0a7b-0d17db8a3...@cogentembedded.com/T/ BR and thanks, Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul, Neil, > Am 04.03.2022 um 17:47 schrieb Paul Cercueil : > > From what I understood in Nikolaus' last message, HDMI hotplug is actually > correctly detected, so there's no need for polling. What is missing is the > call to drm_kms_helper_hotplug_event *somewhere*, so that the information is > correctly relayed to userspace. Exactly. As Maxime pointed out it should already be called by drm_helper_hpd_irq_event() in dw_hdmi_irq() but isn't because mode_config.poll_enabled isn't enabled. So we can either a) enable mode_config.poll_enabled so that it is called by drm_helper_hpd_irq_event() or b) make drm_kms_helper_hotplug_event() being called explicitly in dw_hdmi_irq(). We could guard that by mode_config.poll_enabled to avoid drm_kms_helper_hotplug_event() being called twice (but I think the "changed" mechanism will take care of). > I think this issue can be fixed by calling drm_bridge_connector_enable_hpd() > on the connector in ingenic-drm-drv.c. I don't see yet how this would solve it, but it may work. Anyways, this all is a missing feature (sometimes called "bug") of the *dw-hdmi driver* and IMHO neither of the connector nor the ingenic-drm-drv. So I think it should not be solved outside dw-hdmi. BR and thanks, Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul, Neil, > Am 03.03.2022 um 18:20 schrieb Paul Cercueil : > > Hi Nikolaus, > > [snip] > >>> Well he said "the Ingenic DRM core" aka ingenic-drm-drv.c. You do have >>> access to the main drm_device in the ingenic_drm_bind() function, so you >>> can add it there (with a cleanup function calling >>> drm_kms_helper_poll_fini() registered with drmm_add_action_or_reset()). >> Well, do you really want to mix HPD detection between connector, Synopsys >> bridge and Ingenic DRM core? These are independent... >> Or should be accessed only through the bridge chain pointers. >> IMHO we should keep separate functions separate. > > The drm_kms_helper_poll_init() just says "this DRM device may have connectors > that need to be polled" so it very well fits inside the main driver, IMHO. As far as I understand, it has the side-effect to always set dev->mode_config.poll_enabled and schedule_delayed_work() for all devices. I am not sure if this is intended for arbitrary ingenic-drm devices. But you know better than me. Hm. But wait, I think I now finally remember why I have proposed it the way it is! It is always better to go back to requirements and find the least invasive solution. - HPD IRQ works and calls dw_hdmi_irq() [as can be shown by adding printk()] - it is just that the udevd is only notified if poll_enabled = true (but no polling takes place!). An earlier version (v4) to fix this proposed to add an explicit call to drm_kms_helper_hotplug_event() in dw_hdmi_irq() but that was rejected a while ago because drm_helper_hpd_irq_event() will already call it: https://www.spinics.net/lists/dri-devel/msg316846.html Since this did not take into account that dev->mode_config.poll_enabled must be set true, I then proposed the enable_poll() mechanism just to set this bit for the ingenic-dw-hdmi specialization. So a HPD event is delivered to the dw-hdmi driver as dw_hdmi_irq() and that calls drm_helper_hpd_irq_event() but not drm_kms_helper_hotplug_event() and user-space is not getting aware. It is all a hack because we mix the dw-hdmi driver which originally did register its own connector with an explicit connector... In summary I now thing that the v4 patch is the simplest and least invasive solution. We neither have to introduce a dw_hdmi_enable_poll() function or call drm_kms_helper_poll_init() anywhere. It is just a single line to add to dw-hdmi. And neither touches ingenic-dw-hdmi nor ingenic-drm-drv. So let's go back to v4 version (just modify commit message to better describe why we have to call drm_kms_helper_hotplug_event() explicitly) and forget about alternatives. BR, Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul,
> Am 03.03.2022 um 17:51 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le jeu., mars 3 2022 at 17:43:05 +0100, H. Nikolaus Schaller
> a écrit :
>> Hi Neil,
>>> Am 03.03.2022 um 17:30 schrieb H. Nikolaus Schaller :
>>> Hi Neil,
>>>> Am 03.03.2022 um 17:23 schrieb Neil Armstrong :
>>>> Hi,
>>>> On 26/02/2022 18:12, H. Nikolaus Schaller wrote:
>>>>> so that specialization drivers like ingenic-dw-hdmi can enable polling.
>>>>> Signed-off-by: H. Nikolaus Schaller
>>>>> ---
>>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
>>>>> include/drm/bridge/dw_hdmi.h | 1 +
>>>>> 2 files changed, 10 insertions(+)
>>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> index 4befc104d2200..43e375da131e8 100644
>>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>>> @@ -3217,6 +3217,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>>>>> return 0;
>>>>> }
>>>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
>>>>> +{
>>>>> + if (hdmi->bridge.dev)
>>>>> + hdmi->bridge.dev->mode_config.poll_enabled = enable;
>>>>> + else
>>>>> + dev_warn(hdmi->dev, "no hdmi->bridge.dev");
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
>>>>> +
>>>>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>>>>> const struct dw_hdmi_plat_data *plat_data)
>>>>> {
>>>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>>>> index 2a1f85f9a8a3f..963960794b40e 100644
>>>>> --- a/include/drm/bridge/dw_hdmi.h
>>>>> +++ b/include/drm/bridge/dw_hdmi.h
>>>>> @@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
>>>>> dw_hdmi *hdmi,
>>>>> void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
>>>>> bool force, bool disabled, bool rxsense);
>>>>> void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
>>>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
>>>>> #endif /* __IMX_HDMI_H__ */
>>>> As I understand, this is because the IRQ line of the dw-hdmi IP isn't
>>>> connected right ? and you use the display-connector ddc gpio instead ?
>>> Yes. The IRQ line is not connected on all boards as far as I can see.
>>>> In this case I think the Ingenic DRM core should call
>>>> drm_kms_helper_poll_init(drm) instead.
>>> Ah, that is good. it seems to do "dw_hdmi_enable_poll()" in a more generic
>>> way.
>> Well, I looked through source code and it is defined as
>> void drm_kms_helper_poll_init(struct drm_device *dev)
>> But there is no direct pointer to some drm_device available.
>> Neither in dw-hdmi nor ingenic-dw-hdmi.
>
> Well he said "the Ingenic DRM core" aka ingenic-drm-drv.c. You do have access
> to the main drm_device in the ingenic_drm_bind() function, so you can add it
> there (with a cleanup function calling drm_kms_helper_poll_fini() registered
> with drmm_add_action_or_reset()).
Well, do you really want to mix HPD detection between connector, Synopsys
bridge and Ingenic DRM core? These are independent...
Or should be accessed only through the bridge chain pointers.
IMHO we should keep separate functions separate.
And maybe this should also be conditional? Maybe not depend on compatible =
jz4780 but compatible = ci20?
Looks to me to be a quick fix in the wrong place.
Let's fix the CSC issue first.
BR,
Nikolaus
Re: [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Paul and Neil,
> Am 03.03.2022 um 17:46 schrieb Paul Cercueil :
>
> Hi Neil,
>
> Le jeu., mars 3 2022 at 17:23:02 +0100, Neil Armstrong
> a écrit :
>> Hi,
>> On 26/02/2022 18:12, H. Nikolaus Schaller wrote:
>>> so that specialization drivers like ingenic-dw-hdmi can enable polling.
>>> Signed-off-by: H. Nikolaus Schaller
>>> ---
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
>>> include/drm/bridge/dw_hdmi.h | 1 +
>>> 2 files changed, 10 insertions(+)
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index 4befc104d2200..43e375da131e8 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -3217,6 +3217,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>>> return 0;
>>> }
>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
>>> +{
>>> + if (hdmi->bridge.dev)
>>> + hdmi->bridge.dev->mode_config.poll_enabled = enable;
>>> + else
>>> + dev_warn(hdmi->dev, "no hdmi->bridge.dev");
>>> +}
>>> +EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
>>> +
>>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>>> const struct dw_hdmi_plat_data *plat_data)
>>> {
>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>> index 2a1f85f9a8a3f..963960794b40e 100644
>>> --- a/include/drm/bridge/dw_hdmi.h
>>> +++ b/include/drm/bridge/dw_hdmi.h
>>> @@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
>>> dw_hdmi *hdmi,
>>> void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
>>> bool force, bool disabled, bool rxsense);
>>> void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
>>> #endif /* __IMX_HDMI_H__ */
>> As I understand, this is because the IRQ line of the dw-hdmi IP isn't
>> connected right ? and you use the display-connector ddc gpio instead ?
Ah, I should finish work for today since I am no longer reading every word
properly...
No, we do NOT use the display connector for HPD. We use HPD of the dw-hdmi.
Either IRQ is not enabled properly or not working in IRQ mode.
But it works if polling is enabled.
>
> According to the CI20 schematic, it is wired properly. So that's strange.
Yes, HTPLG input goes through an 1kΩ + 1µF low-pass filter to debounce
HDMI_HTPLG.
This goes to the HPD (BGA ball N19).
There is an optional Q14 driving HDMI_DETE_N.
This could become the hpd-gpios property of the connector in the device tree.
But it is optional.
So we have to use dw-hdmi HPD and make it work (in combination with a chained
hdmi-connector).
>
>> In this case I think the Ingenic DRM core should call
>> drm_kms_helper_poll_init(drm) instead.
>
> Yes, the ingenic-drm driver does not poll for connectors because until now it
> never has been needed.
Well, if we go back a while we only needed it after introducing the
hdmi-connectors
and making dw-hdmi a bridge.
Originally the dw-hdmi driver did properly take care of everything (by
registering its own connector).
BR and thanks,
Nikolaus
Re: [Letux-kernel] [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Neil,
> Am 03.03.2022 um 17:30 schrieb H. Nikolaus Schaller :
>
> Hi Neil,
>
>> Am 03.03.2022 um 17:23 schrieb Neil Armstrong :
>>
>> Hi,
>>
>> On 26/02/2022 18:12, H. Nikolaus Schaller wrote:
>>> so that specialization drivers like ingenic-dw-hdmi can enable polling.
>>> Signed-off-by: H. Nikolaus Schaller
>>> ---
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
>>> include/drm/bridge/dw_hdmi.h | 1 +
>>> 2 files changed, 10 insertions(+)
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index 4befc104d2200..43e375da131e8 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -3217,6 +3217,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>>> return 0;
>>> }
>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
>>> +{
>>> + if (hdmi->bridge.dev)
>>> + hdmi->bridge.dev->mode_config.poll_enabled = enable;
>>> + else
>>> + dev_warn(hdmi->dev, "no hdmi->bridge.dev");
>>> +}
>>> +EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
>>> +
>>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>>> const struct dw_hdmi_plat_data *plat_data)
>>> {
>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>> index 2a1f85f9a8a3f..963960794b40e 100644
>>> --- a/include/drm/bridge/dw_hdmi.h
>>> +++ b/include/drm/bridge/dw_hdmi.h
>>> @@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
>>> dw_hdmi *hdmi,
>>> void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
>>> bool force, bool disabled, bool rxsense);
>>> void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
>>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
>>> #endif /* __IMX_HDMI_H__ */
>>
>> As I understand, this is because the IRQ line of the dw-hdmi IP isn't
>> connected right ? and you use the display-connector ddc gpio instead ?
>
> Yes. The IRQ line is not connected on all boards as far as I can see.
>
>>
>> In this case I think the Ingenic DRM core should call
>> drm_kms_helper_poll_init(drm) instead.
>
> Ah, that is good. it seems to do "dw_hdmi_enable_poll()" in a more generic
> way.
Well, I looked through source code and it is defined as
void drm_kms_helper_poll_init(struct drm_device *dev)
But there is no direct pointer to some drm_device available.
Neither in dw-hdmi nor ingenic-dw-hdmi.
What should the parameter to drm_kms_helper_poll_init(drm) be?
From comparing code to be able to set mode_config.poll_enabled = enable it
should be
>bridge.dev
but the struct dw_hdmi *hdmi is an opaque type for the ingenic-dw-hdmi driver.
So it can't access the hdmi-bridge directly.
What we can do is to make dw_hdmi_enable_poll() call drm_kms_helper_poll_init()
or drm_kms_helper_poll_fini().
BR and thanks,
Nikolaus
Re: [PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
Hi Neil,
> Am 03.03.2022 um 17:23 schrieb Neil Armstrong :
>
> Hi,
>
> On 26/02/2022 18:12, H. Nikolaus Schaller wrote:
>> so that specialization drivers like ingenic-dw-hdmi can enable polling.
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
>> include/drm/bridge/dw_hdmi.h | 1 +
>> 2 files changed, 10 insertions(+)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 4befc104d2200..43e375da131e8 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -3217,6 +3217,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>> return 0;
>> }
>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
>> +{
>> +if (hdmi->bridge.dev)
>> +hdmi->bridge.dev->mode_config.poll_enabled = enable;
>> +else
>> +dev_warn(hdmi->dev, "no hdmi->bridge.dev");
>> +}
>> +EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
>> +
>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>>const struct dw_hdmi_plat_data *plat_data)
>> {
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index 2a1f85f9a8a3f..963960794b40e 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
>> dw_hdmi *hdmi,
>> void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
>> bool force, bool disabled, bool rxsense);
>> void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
>>#endif /* __IMX_HDMI_H__ */
>
> As I understand, this is because the IRQ line of the dw-hdmi IP isn't
> connected right ? and you use the display-connector ddc gpio instead ?
Yes. The IRQ line is not connected on all boards as far as I can see.
>
> In this case I think the Ingenic DRM core should call
> drm_kms_helper_poll_init(drm) instead.
Ah, that is good. it seems to do "dw_hdmi_enable_poll()" in a more generic way.
Will test and rework for v17 asap.
BR and thanks,
Nikolaus
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil, > Am 03.03.2022 um 12:45 schrieb H. Nikolaus Schaller : > > Hi Neil, > >> Am 03.03.2022 um 12:42 schrieb Neil Armstrong : >> >>> So how can we get that merged? IMHO your proposal should be before we add >>> ingenic-dw-hdmi. >>> If you have a version with proper commit message I can add it to the >>> beginning of my >>> seried and include it in a v17. Or if you get yours merged to >>> drm-misc/drm-misc-next I >>> can build on top. >> >> You can add it in your v17 patchset with my authorship and my Signed-off-by >> tag + yours. >> >> As commit message something like : >> >> drm/bridge: dw-hdmi: handle unusable or non-configured CSC module >> >> The dw-hdmi integrates an optional Color Space Conversion feature used >> to handle color-space conversions. >> >> On some platforms, the CSC isn't built-in or non-functional. >> >> This adds the necessary code to disable the CSC functionality >> and limit the bus format negotiation to force using the same >> input bus format as the output bus format. >> > > Fine! Will do. I was a little too early. While preparing the patches I found that I still had the hack to force sink_is_hdmi = false in my test branch. Sorry for that. Removing this made the panel go black again, even with your latest proposal. So I looked deeper into your patch and it seems to influence the input formats only in dw_hdmi_bridge_atomic_get_input_bus_fmts()? While the problem I see is with output formats and we had worked on modifying dw_hdmi_bridge_atomic_get_output_bus_fmts(). BR and thanks, Nikolaus
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil, > Am 03.03.2022 um 12:42 schrieb Neil Armstrong : > >> So how can we get that merged? IMHO your proposal should be before we add >> ingenic-dw-hdmi. >> If you have a version with proper commit message I can add it to the >> beginning of my >> seried and include it in a v17. Or if you get yours merged to >> drm-misc/drm-misc-next I >> can build on top. > > You can add it in your v17 patchset with my authorship and my Signed-off-by > tag + yours. > > As commit message something like : > > drm/bridge: dw-hdmi: handle unusable or non-configured CSC module > > The dw-hdmi integrates an optional Color Space Conversion feature used > to handle color-space conversions. > > On some platforms, the CSC isn't built-in or non-functional. > > This adds the necessary code to disable the CSC functionality > and limit the bus format negotiation to force using the same > input bus format as the output bus format. > Fine! Will do. BR and thanks, Nikolaus
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil, > Am 03.03.2022 um 09:35 schrieb Neil Armstrong : > > Hi, > > On 02/03/2022 23:24, H. Nikolaus Schaller wrote: >> Hi Neil, >>> Am 02.03.2022 um 15:34 schrieb Neil Armstrong : >>> >>> Hi, >>> >>>> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) >>> >>> I don't understand what's wrong, can you try to make the logic select >>> MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? >> I have forced hdmi->sink_is_hdmi = false and replaced >> /* Default 8bit RGB fallback */ >> -output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; >> +output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >> And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. >> (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). >> So this indicates that YUV conversion is not working properly. Maybe missing >> some special >> setup. >> What I have to test if it works on a different monitor. Same effect on a Xiaomi monitor (user manual just telling HDMI1,4 compatible), an older Acer video projector and a Sharp TV set. The Xiaomi monitor does not say "No signal" but shows a black screen. The others do not even report any HDMI signals. All work well with MEDIA_BUS_FMT_RGB888_1X24. This means the transcoding to YUV does not work properly on the jz4780 SoC setup. So it looks as if we have to disable it (at least unless someone finds a fix). >> Not that this specific panel >> (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV >> capabilities >> but does not handle them... >> On the other hand this panel works on RasPi and OMAP5 (where I admit I do >> not know in >> which mode). > > Pretty sure they don't support YUV HDMI output. > > If you can try on a certified HDMI devices like a TV, it would here figuring > out where comes the issue. I am not sure if the Sharp TV is fully certified but would assume... > >>> If your CSC is broken, we'll need to disable it on your platform. >> Indeed. >> So it seems as if we need a mechanism to overwrite >> dw_hdmi_bridge_atomic_get_output_bus_fmts() >> in our ingenic-dw-hdmi platform specialization [1] to always return >> MEDIA_BUS_FMT_RGB888_1X24. >> Or alternatively set sink_is_hdmi = false there (unfortunately there is no >> direct access to >> struct dw_hdmi in a specialization drivers). >> Is this already possible or how can it be done? > > It's not handled yet, but we may add the logic to handle the lack of CSC > config bit and > add a glue config bit to override this like we already did for CEC. > > I wrote an initial support to disable CSC (only compile-tested), could you > try on your platform with setting disable_csc = 1 in your dw-hdmi glue code ? This works! So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. If you have a version with proper commit message I can add it to the beginning of my seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I can build on top. BR and thanks, Nikolaus
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil, > Am 02.03.2022 um 15:34 schrieb Neil Armstrong : > > Hi, > >> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) > > I don't understand what's wrong, can you try to make the logic select > MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? I have forced hdmi->sink_is_hdmi = false and replaced /* Default 8bit RGB fallback */ - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). So this indicates that YUV conversion is not working properly. Maybe missing some special setup. What I have to test if it works on a different monitor. Not that this specific panel (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV capabilities but does not handle them... On the other hand this panel works on RasPi and OMAP5 (where I admit I do not know in which mode). > If your CSC is broken, we'll need to disable it on your platform. Indeed. So it seems as if we need a mechanism to overwrite dw_hdmi_bridge_atomic_get_output_bus_fmts() in our ingenic-dw-hdmi platform specialization [1] to always return MEDIA_BUS_FMT_RGB888_1X24. Or alternatively set sink_is_hdmi = false there (unfortunately there is no direct access to struct dw_hdmi in a specialization drivers). Is this already possible or how can it be done? BR and thanks, Nikolaus [1]: https://lore.kernel.org/all/24a27226a22adf5f5573f013e5d7d89b0ec73664.1645895582.git@goldelico.com/
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil,
> Am 02.03.2022 um 11:25 schrieb Neil Armstrong :
>
>> I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be
>> expected
>> since I am using a HDMI connector and panel... So your patch will still add
>> the UYVY formats.
>> Either the synposys module inside the jz4780 or the panel does not
>> understand them.
>
> By selecting the UYVY formats, the driver will enable the colorspace
> converters in the dw-hdmi IP,
> I don't see why it doesn't work here...
>
> There is a bit called `Support Color Space Converter` in config0_id:
> bit | Name| R/W | Desc
> 2 | csc | R | Indicates if Color Space
> Conversion block is present
>
> Could you dump all the config0 bits:
>
> ===><=
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 54d8fdad395f..547731482da8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3431,6 +3431,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device
> *pdev,
>pdevinfo.id = PLATFORM_DEVID_AUTO;
>
>config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
> + dev_info(dev, "config0: %x\n", config0);
>config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>
>if (iores && config3 & HDMI_CONFIG3_AHBAUDDMA) {
> ===><=
>
> If this bit is missing, this would explain the black screen.
[9.291011] dw-hdmi-ingenic 1018.hdmi: config0: bf
Hm. Or is the color-space conversion of the sw-hdmi module inside the jz4780
broken
or not configured properly?
(cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false)
BR and thanks,
Nikolaus
Re: [PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Hi Neil,
> Am 01.03.2022 um 10:18 schrieb Neil Armstrong :
>
> Hi,
>
> On 26/02/2022 18:13, H. Nikolaus Schaller wrote:
>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> introduced a new mechanism to negotiate bus formats between hdmi connectors
>> and bridges which is to be used e.g. for the jz4780 based CI20 board.
>> In this case dw-hdmi sets up a list of formats in
>> dw_hdmi_bridge_atomic_get_output_bus_fmts().
>> This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but
>> only produces a black screen.
>> Analysis revealed an omission in
>> Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format
>> negociation")
>> to check for 8 bit with when adding UYVY8 or YUV8 formats.
>> This fix is based on the observation that max_bpc = 0 when running this
>> function while info->bpc = 8.
>
> In fact if bpc = 0, it should be considered as 8, so the issue is elsewhere.
>
>> Adding the proposed patch makes the jz4780/CI20 panel work again with default
>> MEDIA_BUS_FMT_RGB888_1X24 mode.
>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format
>> negociation")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 43e375da131e8..c08e2cc96584c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2621,11 +2621,13 @@ static u32
>> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> }
>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> -output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> +if (max_bpc >= 8 && info->bpc >= 8) {
>> +if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> +output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> -output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> +if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> +output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> +}
>
> It should not select YUV here if it's not possible, so something is wrong.
>
> Can you check if
> https://lore.kernel.org/r/20220119123656.1456355-2-narmstr...@baylibre.com
> fixes this issue instead ?
Well, I had to manually fix it to be appliable to drm-misc/drm-misc-next
and specifically:
c03d0b52ff71 ("drm/connector: Fix typo in output format")
My resulting patch is attached.
Unfortunately it did not work.
I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be
expected
since I am using a HDMI connector and panel... So your patch will still add the
UYVY formats.
Either the synposys module inside the jz4780 or the panel does not understand
them.
Here is the EDID. Unfortunately it does not pretty print the extended
descriptors for UYVY etc.
so that I don't know the exact capabilities of the panel. And what I am not
sure is if the
jz4780 SoC can convert to UYVY or how it can.
root@letux:~# parse-edid
sink_is_hdmi=1
So please let me know which parameters I should try to printk()...
BR and thanks,
Nikolaus
--
From c84a3c4a500684e57b1243fe5386696c48fa1e1b Mon Sep 17 00:00:00 2001
From: Neil Armstrong
Date: Wed, 19 Jan 2022 13:36:56 +0100
Subject: [PATCH] drm/bridge: dw-hdmi: filter out YUV output formats when DVI
When the display is not an HDMI sink, only the RGB output format is
valid. Thus stop returning YUV output formats when sink is not HDMI.
Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format
negociation")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 43e375da131e8..0ec0cbe448e05 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2538,6 +2538,7 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
struct drm_connector *conn = conn_state->connector;
struct drm_display_info *info = >display_info;
struct drm_display_
[PATCH v16 2/4] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Note that there is no hpd-gpio installed on the CI20 board HDMI
connector. Hence there is no hpd detection by the connector driver
and we have to enable polling in the dw-hdmi core driver.
For that we need to set .poll_enabled but that struct component
can only be accessed by core code. Hence we use the public
setter function drm_kms_helper_hotplug_event() introduced before.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 105 ++
3 files changed, 115 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..508d4b6bfa243
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ dw_hdmi_enable_poll(hdmi, true);
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdm
[PATCH v16 1/4] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
so that specialization drivers like ingenic-dw-hdmi can enable polling.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4befc104d2200..43e375da131e8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3217,6 +3217,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v16 4/4] drm/bridge: dw-hdmi: fix bus formats negotiation for 8 bit modes
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connectors
and bridges which is to be used e.g. for the jz4780 based CI20 board.
In this case dw-hdmi sets up a list of formats in
dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but
only produces a black screen.
Analysis revealed an omission in
Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format
negociation")
to check for 8 bit with when adding UYVY8 or YUV8 formats.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8.
Adding the proposed patch makes the jz4780/CI20 panel work again with default
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format
negociation")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 43e375da131e8..c08e2cc96584c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2621,11 +2621,13 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
- output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ if (max_bpc >= 8 && info->bpc >= 8) {
+ if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
- output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+ }
/* Default 8bit RGB fallback */
output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
--
2.33.0
[PATCH v16 3/4] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v16 0/4] MIPS: JZ4780 and CI20 HDMI
PATCH V16 2022-02-26 18:13:02:
* fixed and renamed dw-hdmi bus negotiation patch (by narmstr...@baylibre.com)
* reordered and merged HPD fix (suggested by p...@crapouillou.net)
* fixed MODULE_ALIAS for dw-hdmi-ingenic (reported by p...@crapouillou.net)
* dropped some already merged commits from the series
PATCH V15 2022-02-12 16:50:54:
* remove already (elsewhere) merged commits (suggested by p...@crapouillou.net)
* clarify commit message for (now) 1/7 ((suggested by p...@crapouillou.net))
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by
p...@crapouillou.net)
- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by p...@crapouillou.net)
- removed some c
Re: [PATCH v15 4/7] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Hi Neil,
> Am 21.02.2022 um 09:11 schrieb Neil Armstrong :
>
> Hi,
>
> On 12/02/2022 16:50, H. Nikolaus Schaller wrote:
>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> introduced a new mechanism to negotiate bus formats between hdmi connector
>> and the synopsys hdmi driver inside the jz4780.
>> By this, the dw-hdmi is no longer the only bridge and sets up a list
>> of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
>> This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but
>> only
>> produces a black screen.
>> This fix is based on the observation that max_bpc = 0 when running this
>> function while info->bpc = 8. Since the formats checks before this always
>> test
>> for max_bpc >= info->pbc indirectly my assumption is that we must check it
>> here as well.
>> Adding the proposed patch makes the CI20/jz4780 panel work again in
>> MEDIA_BUS_FMT_RGB888_1X24 mode.
>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index b0d8110dd412c..826a055a7a273 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2620,10 +2620,10 @@ static u32
>> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> }
>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR422)
>> output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR444)
>> output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> /* Default 8bit RGB fallback */
>
> Please do the same for all other cases and change the patch subject to
> something more accurate like:
> "drm/bridge: dw-hdmi: take display info bpc in account for bus formats
> negociation"
thank you very much for this analysis.
In fact my fix was also not correctly doing the right comparisons. The rules
should have the
same structure as for all cases before, i.e. check for >= 8 and then handle
both color formats.
I have fixed and tested on my CI20 board and updated the description and Fixes:
tags.
v16 will come now (as part of the jz4780 hdmi series).
BR and thanks,
Nikolaus
Re: [PATCH v15 1/7] drm/ingenic: Fix support for JZ4780 HDMI output
> Am 14.02.2022 um 13:36 schrieb Paul Cercueil : > > Hi, > > Le lun., févr. 14 2022 at 13:33:25 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 14.02.2022 um 13:29 schrieb Paul Cercueil : >>> Hi, >>> Le lun., févr. 14 2022 at 11:19:40 +0100, H. Nikolaus Schaller >>> a écrit : >>>> Hi Paul, >>>>> Am 14.02.2022 um 11:13 schrieb Paul Cercueil : >>>>> Hi, >>>>> Le sam., févr. 12 2022 at 16:50:49 +0100, H. Nikolaus Schaller >>>>> a écrit : >>>>>> From: Paul Boddie >>>>>> We have to make sure that >>>>>> - JZ_LCD_OSDC_ALPHAEN is set >>>>>> - plane f0 is disabled and not seen from user-space >>>>> Actually it will still be seen from user-space, but it won't be possible >>>>> to use it. So before applying I'll change this to: >>>>> "plane f0 is disabled as it's not working yet" >>>>> If that's OK with you. >>>> Yes. You understand much better than me the implications... >>> I reworded it to "plane f0 is disabled as it's not working yet", added a >>> Fixes: tag, and pushed this patch to drm-misc-next. >> great and thanks. >> So I drop it from v16. > > Neil told me he'd review patch [4/7] this week so maybe hold off v16 for a > few days. Ok. BR and thanks, Nikolaus
Re: [PATCH v15 1/7] drm/ingenic: Fix support for JZ4780 HDMI output
Hi Paul, > Am 14.02.2022 um 13:29 schrieb Paul Cercueil : > > Hi, > > Le lun., févr. 14 2022 at 11:19:40 +0100, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 14.02.2022 um 11:13 schrieb Paul Cercueil : >>> Hi, >>> Le sam., févr. 12 2022 at 16:50:49 +0100, H. Nikolaus Schaller >>> a écrit : >>>> From: Paul Boddie >>>> We have to make sure that >>>> - JZ_LCD_OSDC_ALPHAEN is set >>>> - plane f0 is disabled and not seen from user-space >>> Actually it will still be seen from user-space, but it won't be possible to >>> use it. So before applying I'll change this to: >>> "plane f0 is disabled as it's not working yet" >>> If that's OK with you. >> Yes. You understand much better than me the implications... > > I reworded it to "plane f0 is disabled as it's not working yet", added a > Fixes: tag, and pushed this patch to drm-misc-next. great and thanks. So I drop it from v16. BR and thanks, Nikolaus
Re: [PATCH v15 2/7] drm/ingenic: Add dw-hdmi driver specialization for jz4780
Hi Paul,
> Am 14.02.2022 um 11:24 schrieb Paul Cercueil :
>
> Hi,
>
> Le sam., févr. 12 2022 at 16:50:50 +0100, H. Nikolaus Schaller
> a écrit :
>> +static void ingenic_dw_hdmi_cleanup(void *data)
>> +{
>> +struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
>> +
>> +dw_hdmi_remove(hdmi);
>> +}
>> +
>> +static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
>> +{
>> +struct dw_hdmi *hdmi;
>> +
>> +hdmi = dw_hdmi_probe(pdev, _dw_hdmi_plat_data);
>> +if (IS_ERR(hdmi))
>> +return PTR_ERR(hdmi);
>> +
>> +return devm_add_action_or_reset(>dev, ingenic_dw_hdmi_cleanup,
>> hdmi);
>
> I think I said it already, but in this driver you could use a .remove
> callback, there's not much point in using devm cleanups in such a simple
> setup.
Well it was your suggestion after v8:
https://lore.kernel.org/all/dia33r.qe29k7rkli...@crapouillou.net/
So we now almost go back to RFC v1 almost 2 years ago:
https://patchwork.kernel.org/project/linux-mips/patch/2c131e1fb19e19f958a612f7186bc83f4afb0b0a.1582744379.git@goldelico.com/
Of course there was a good reason to better handle the regulator
AND the dw_hdmi_remove() by a single mechanism.
Now the regulator has gone and been replaced by the hdmi connector
and we can go back.
>
> In your probe you could just:
> return PTR_ERR_OR_ZERO(hdmi);
No, this does not work since we need to platform_set_drvdata().
to be able to access the private struct in the remove callback.
And checking errors after platform_set_drvdata() can be done but
looks strange to me.
It is up to you what you prefer.
>
>> +}
>> +
>> +static struct platform_driver ingenic_dw_hdmi_driver = {
>> +.probe = ingenic_dw_hdmi_probe,
>> +.driver = {
>> +.name = "dw-hdmi-ingenic",
>> +.of_match_table = ingenic_dw_hdmi_dt_ids,
>> +},
>> +};
>> +module_platform_driver(ingenic_dw_hdmi_driver);
>> +
>> +MODULE_DESCRIPTION("JZ4780 Specific DW-HDMI Driver Extension");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_ALIAS("platform:dwhdmi-ingenic");
>
> Should probably be "platform:dw-hdmi-ingenic"?
Yes, indeed. Thanks for spotting!
Was also good in v1. Probably someone deleted the hyphen unnoticed during
editing of "jz4780" to "ingenic"...
BR and thanks,
Nikolaus
Re: [PATCH v15 1/7] drm/ingenic: Fix support for JZ4780 HDMI output
Hi Paul, > Am 14.02.2022 um 11:13 schrieb Paul Cercueil : > > Hi, > > Le sam., févr. 12 2022 at 16:50:49 +0100, H. Nikolaus Schaller > a écrit : >> From: Paul Boddie >> We have to make sure that >> - JZ_LCD_OSDC_ALPHAEN is set >> - plane f0 is disabled and not seen from user-space > > Actually it will still be seen from user-space, but it won't be possible to > use it. So before applying I'll change this to: > "plane f0 is disabled as it's not working yet" > > If that's OK with you. Yes. You understand much better than me the implications... BR and thanks, Nikolaus
[PATCH v15 1/7] drm/ingenic: Fix support for JZ4780 HDMI output
From: Paul Boddie
We have to make sure that
- JZ_LCD_OSDC_ALPHAEN is set
- plane f0 is disabled and not seen from user-space
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7f10d6eed549d..dcf44cb00821f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
- if (plane == >f0)
+ if (priv->soc_info->plane_f0_not_working && plane == >f0)
return -EINVAL;
crtc_state = drm_atomic_get_existing_crtc_state(state,
@@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
.use_extended_hwdesc = true,
+ .plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
.max_height = 2048,
.formats_f1 = jz4770_formats_f1,
--
2.33.0
[PATCH v15 4/7] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b0d8110dd412c..826a055a7a273 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v15 3/7] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v15 7/7] [RFC] drm/ingenic: add some more features specific to jz4780
From: Paul Boddie
The jz4780 has some more features which should be initialized
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821f..fb2cdb188b993 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,9 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool has_alpha;
+ bool has_pcfg;
+ bool has_recover;
+ bool has_rgbc;
bool map_noncoherent;
bool use_extended_hwdesc;
bool plane_f0_not_working;
@@ -732,6 +735,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->has_recover)
+ cfg |= JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN;
+
if (priv->soc_info->use_extended_hwdesc)
cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
@@ -1320,6 +1326,22 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
osdc |= JZ_LCD_OSDC_ALPHAEN;
regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
+ /* Magic values from the vendor kernel for the priority thresholds. */
+ if (soc_info->has_pcfg)
+ regmap_write(priv->map, JZ_REG_LCD_PCFG,
+JZ_LCD_PCFG_PRI_MODE |
+JZ_LCD_PCFG_HP_BST_16 |
+(511 << JZ_LCD_PCFG_THRESHOLD2_OFFSET) |
+(400 << JZ_LCD_PCFG_THRESHOLD1_OFFSET) |
+(256 << JZ_LCD_PCFG_THRESHOLD0_OFFSET));
+
+ /* RGB output control may be superfluous. */
+ if (soc_info->has_rgbc)
+ regmap_write(priv->map, JZ_REG_LCD_RGBC,
+JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
+JZ_LCD_RGBC_ODD_RGB |
+JZ_LCD_RGBC_EVEN_RGB);
+
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1483,6 +1505,9 @@ static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4740_formats,
@@ -1494,6 +1519,9 @@ static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4725b_formats_f1,
@@ -1506,6 +1534,9 @@ static const struct jz_soc_info jz4770_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = true,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 1280,
.max_height = 720,
.formats_f1 = jz4770_formats_f1,
@@ -1518,6 +1549,9 @@ static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
.has_alpha = true,
+ .has_pcfg = true,
+ .has_recover = true,
+ .has_rgbc = true,
.use_extended_hwdesc = true,
.plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
--
2.33.0
[PATCH v15 5/7] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
so that specialization drivers like ingenic-dw-hdmi can enable polling.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 826a055a7a273..fc2d5422c8a19 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v15 2/7] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, _dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(>dev, ingenic_dw_hdmi_cleanup,
hdmi);
[PATCH v15 6/7] drm/ingenic: dw-hdmi: make hot plug detection work for CI20
There is no hpd-gpio installed on the CI20 board HDMI connector. Hence there is no hpd detection by the connector driver and we have to enable polling by the dw-hdmi driver. We need to set .poll_enabled but that struct component can only be accessed in the core code. Hence we use the public setter function drm_kms_helper_hotplug_event(). Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c index 34e986dd606cf..90547a28dc5c7 100644 --- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c @@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data, if (mode->clock > 216000) return MODE_CLOCK_HIGH; + dw_hdmi_enable_poll(hdmi, true); + return MODE_OK; } -- 2.33.0
[PATCH v15 0/7] MIPS: JZ4780 and CI20 HDMI
PATCH V15 2022-02-12 16:50:54:
* remove already (elsewhere) merged commits (suggested by p...@crapouillou.net)
* clarify commit message for (now) 1/7 ((suggested by p...@crapouillou.net))
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by
p...@crapouillou.net)
- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by p...@crapouillou.net)
- removed some comments (suggested by p...@crapouillou.net)
PATCH V5 2021-10-05 14:28:44:
- dropped mode_fixup and timings support in dw-hdmi as it is no longer needed
in this V5 (by h...@goldelico.com)
- dropped "drm/ingenic: add some jz4780 specific features" (stimulated by
p...@crapouillou.net)
- fixed typo i
Re: [PATCH v14 8/9] [already applied to mips-fixes] MIPS: DTS: CI20: fix how ddc power is enabled
> Am 12.02.2022 um 15:58 schrieb Paul Cercueil :
>
> Hi,
>
> Le sam., févr. 12 2022 at 15:19:26 +0100, H. Nikolaus Schaller
> a écrit :
>> Originally we proposed a new hdmi-5v-supply regulator reference
>> for CI20 device tree but that was superseded by a better idea to use
>> the already defined "ddc-en-gpios" property of the "hdmi-connector".
>> Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
>> been applied to v5.17-rc1, we add this on top.
>> Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
>> Signed-off-by: H. Nikolaus Schaller
>> Reviewed-by: Paul Cercueil
>
> Since it's already applied you don't have to send this patch anymore.
I see, it has arrived in linux-next but not yet in drm-misc-next...
So if someone wants to test the series directly on top of drm-misc-next (as I
am doing), it would be incomplete without.
IMHO these side-branches and partial merges here and there sometimes make more
problems than they seem to solve...
But I leave already applied out commits for v15.
>
> Cheers,
> -Paul
>
>> ---
>> arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
>> 1 file changed, 2 insertions(+), 13 deletions(-)
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 3e336b3dbb109..ab6e3dc0bc1d0 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -83,6 +83,8 @@ hdmi_out: connector {
>> label = "HDMI OUT";
>> type = "a";
>> +ddc-en-gpios = < 25 GPIO_ACTIVE_HIGH>;
>> +
>> port {
>> hdmi_con: endpoint {
>> remote-endpoint = <_hdmi_out>;
>> @@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
>> gpio = < 14 GPIO_ACTIVE_LOW>;
>> enable-active-high;
>> };
>> -
>> -hdmi_power: fixedregulator@3 {
>> -compatible = "regulator-fixed";
>> -
>> -regulator-name = "hdmi_power";
>> -regulator-min-microvolt = <500>;
>> -regulator-max-microvolt = <500>;
>> -
>> -gpio = < 25 0>;
>> -enable-active-high;
>> -};
>> };
>> {
>> @@ -576,8 +567,6 @@ {
>> pinctrl-names = "default";
>> pinctrl-0 = <_hdmi_ddc>;
>> -hdmi-5v-supply = <_power>;
>> -
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> --
>> 2.33.0
>
>
Re: [PATCH v14 5/9] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
> Am 12.02.2022 um 16:06 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le sam., févr. 12 2022 at 15:19:23 +0100, H. Nikolaus Schaller
> a écrit :
>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> introduced a new mechanism to negotiate bus formats between hdmi connector
>> and the synopsys hdmi driver inside the jz4780.
>> By this, the dw-hdmi is no longer the only bridge and sets up a list
>> of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
>> This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but
>> only
>> produces a black screen.
>
> Neil pushed a fix yesterday that looks like it could fix your issue.
> The fix is: 1528038385c0 ("drm/bridge: dw-hdmi: use safe format when first in
> bridge chain")
>
> Could you try if it does indeed fix your issue?
Sure.
Would have been nice and is a fix addressing same base commit, but is not a
replacement for my attempt :(
Fortunately we can have both.
>
> Cheers,
> -Paul
>
>> This fix is based on the observation that max_bpc = 0 when running this
>> function while info->bpc = 8. Since the formats checks before this always
>> test
>> for max_bpc >= info->pbc indirectly my assumption is that we must check it
>> here as well.
>> Adding the proposed patch makes the CI20/jz4780 panel work again in
>> MEDIA_BUS_FMT_RGB888_1X24 mode.
>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index b0d8110dd412c..826a055a7a273 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2620,10 +2620,10 @@ static u32
>> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> }
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR422)
>> output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR444)
>> output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> /* Default 8bit RGB fallback */
>> --
>> 2.33.0
>
>
Re: [PATCH v14 1/9] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul,
> Am 12.02.2022 um 15:44 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le sam., févr. 12 2022 at 15:19:19 +0100, H. Nikolaus Schaller
> a écrit :
>> From: Paul Boddie
>> Add support for the LCD controller present on JZ4780 SoCs.
>> This SoC uses 8-byte descriptors which extend the current
>> 4-byte descriptors used for other Ingenic SoCs.
>> Note that plane f0 is not working and disabled to be
>> seen from user-space.
>> Tested on MIPS Creator CI20 board.
>
> That's not really what the patch does though. It's a fix for a commit that
> has the exact same title and description, and is already merged: b807fd2c43fe
> ("drm/ingenic: Add support for JZ4780 and HDMI output").
Well, last version was not a fix...
I simply did not notice that parts of the commit contents were removed by
rebase to drm-misc-next and the commit message diverged...
> Please rewrite the patch's title and description to actually describe its
> purpose.
Well, git rebase should do this for us if it removes the code described in the
commit and makes a fix out of it. What do we have automation for :)
v15 will come now...
BR and thanks,
Nikolaus
>
> Cheers,
> -Paul
>
>> Signed-off-by: Paul Boddie
>> Signed-off-by: Ezequiel Garcia
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> index 7f10d6eed549d..dcf44cb00821f 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> @@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
>> struct jz_soc_info {
>> bool needs_dev_clk;
>> bool has_osd;
>> +bool has_alpha;
>> bool map_noncoherent;
>> bool use_extended_hwdesc;
>> +bool plane_f0_not_working;
>> unsigned int max_width, max_height;
>> const u32 *formats_f0, *formats_f1;
>> unsigned int num_formats_f0, num_formats_f1;
>> @@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct
>> drm_plane *plane,
>> if (!crtc)
>> return 0;
>> -if (plane == >f0)
>> +if (priv->soc_info->plane_f0_not_working && plane == >f0)
>> return -EINVAL;
>> crtc_state = drm_atomic_get_existing_crtc_state(state,
>> @@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
>> has_components)
>> long parent_rate;
>> unsigned int i, clone_mask = 0;
>> int ret, irq;
>> +u32 osdc = 0;
>> soc_info = of_device_get_match_data(dev);
>> if (!soc_info) {
>> @@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
>> has_components)
>> /* Enable OSD if available */
>> if (soc_info->has_osd)
>> -regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
>> +osdc |= JZ_LCD_OSDC_OSDEN;
>> +if (soc_info->has_alpha)
>> +osdc |= JZ_LCD_OSDC_ALPHAEN;
>> +regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
>> mutex_init(>clk_mutex);
>> priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
>> @@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
>> static const struct jz_soc_info jz4780_soc_info = {
>> .needs_dev_clk = true,
>> .has_osd = true,
>> +.has_alpha = true,
>> .use_extended_hwdesc = true,
>> +.plane_f0_not_working = true, /* REVISIT */
>> .max_width = 4096,
>> .max_height = 2048,
>> .formats_f1 = jz4770_formats_f1,
>> --
>> 2.33.0
>
>
[PATCH v14 9/9] [RFC] drm/ingenic: add some more features specific to jz4780
From: Paul Boddie
The jz4780 has some more features which should be initialized
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821f..fb2cdb188b993 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,9 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool has_alpha;
+ bool has_pcfg;
+ bool has_recover;
+ bool has_rgbc;
bool map_noncoherent;
bool use_extended_hwdesc;
bool plane_f0_not_working;
@@ -732,6 +735,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->has_recover)
+ cfg |= JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN;
+
if (priv->soc_info->use_extended_hwdesc)
cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
@@ -1320,6 +1326,22 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
osdc |= JZ_LCD_OSDC_ALPHAEN;
regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
+ /* Magic values from the vendor kernel for the priority thresholds. */
+ if (soc_info->has_pcfg)
+ regmap_write(priv->map, JZ_REG_LCD_PCFG,
+JZ_LCD_PCFG_PRI_MODE |
+JZ_LCD_PCFG_HP_BST_16 |
+(511 << JZ_LCD_PCFG_THRESHOLD2_OFFSET) |
+(400 << JZ_LCD_PCFG_THRESHOLD1_OFFSET) |
+(256 << JZ_LCD_PCFG_THRESHOLD0_OFFSET));
+
+ /* RGB output control may be superfluous. */
+ if (soc_info->has_rgbc)
+ regmap_write(priv->map, JZ_REG_LCD_RGBC,
+JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
+JZ_LCD_RGBC_ODD_RGB |
+JZ_LCD_RGBC_EVEN_RGB);
+
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1483,6 +1505,9 @@ static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4740_formats,
@@ -1494,6 +1519,9 @@ static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4725b_formats_f1,
@@ -1506,6 +1534,9 @@ static const struct jz_soc_info jz4770_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = true,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 1280,
.max_height = 720,
.formats_f1 = jz4770_formats_f1,
@@ -1518,6 +1549,9 @@ static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
.has_alpha = true,
+ .has_pcfg = true,
+ .has_recover = true,
+ .has_rgbc = true,
.use_extended_hwdesc = true,
.plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
--
2.33.0
[PATCH v14 7/9] drm/ingenic: dw-hdmi: make hot plug detection work for CI20
There is no hpd-gpio installed on the CI20 board HDMI connector. Hence there is no hpd detection by the connector driver and we have to enable polling by the dw-hdmi driver. We need to set .poll_enabled but that struct component can only be accessed in the core code. Hence we use the public setter function drm_kms_helper_hotplug_event(). Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c index 34e986dd606cf..90547a28dc5c7 100644 --- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c @@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data, if (mode->clock > 216000) return MODE_CLOCK_HIGH; + dw_hdmi_enable_poll(hdmi, true); + return MODE_OK; } -- 2.33.0
[PATCH v14 8/9] [already applied to mips-fixes] MIPS: DTS: CI20: fix how ddc power is enabled
Originally we proposed a new hdmi-5v-supply regulator reference
for CI20 device tree but that was superseded by a better idea to use
the already defined "ddc-en-gpios" property of the "hdmi-connector".
Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
been applied to v5.17-rc1, we add this on top.
Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Paul Cercueil
---
arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 3e336b3dbb109..ab6e3dc0bc1d0 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -83,6 +83,8 @@ hdmi_out: connector {
label = "HDMI OUT";
type = "a";
+ ddc-en-gpios = < 25 GPIO_ACTIVE_HIGH>;
+
port {
hdmi_con: endpoint {
remote-endpoint = <_hdmi_out>;
@@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
gpio = < 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-
- hdmi_power: fixedregulator@3 {
- compatible = "regulator-fixed";
-
- regulator-name = "hdmi_power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = < 25 0>;
- enable-active-high;
- };
};
{
@@ -576,8 +567,6 @@ {
pinctrl-names = "default";
pinctrl-0 = <_hdmi_ddc>;
- hdmi-5v-supply = <_power>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.33.0
[PATCH v14 5/9] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b0d8110dd412c..826a055a7a273 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v14 4/9] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v14 6/9] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
so that specialization drivers like ingenic-dw-hdmi can enable polling.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 826a055a7a273..fc2d5422c8a19 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v14 1/9] drm/ingenic: Add support for JZ4780 and HDMI output
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Note that plane f0 is not working and disabled to be
seen from user-space.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7f10d6eed549d..dcf44cb00821f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
- if (plane == >f0)
+ if (priv->soc_info->plane_f0_not_working && plane == >f0)
return -EINVAL;
crtc_state = drm_atomic_get_existing_crtc_state(state,
@@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
.use_extended_hwdesc = true,
+ .plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
.max_height = 2048,
.formats_f1 = jz4770_formats_f1,
--
2.33.0
[PATCH v14 2/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
---
.../display/bridge/ingenic,jz4780-hdmi.yaml | 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
new file mode 100644
index 0..b8219eab4475a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+const: ingenic,jz4780-dw-hdmi
+
+ reg-io-width:
+const: 4
+
+ clocks:
+maxItems: 2
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from LCD controller output.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Link to the HDMI connector.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ports
+ - reg-io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <>;
+interrupt-parent = <>;
+interrupts = <3>;
+clocks = < JZ4780_CLK_AHB0>, < JZ4780_CLK_HDMI>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in: port@0 {
+reg = <0>;
+dw_hdmi_in: endpoint {
+remote-endpoint = <_lcd_out>;
+};
+};
+hdmi_out: port@1 {
+reg = <1>;
+dw_hdmi_out: endpoint {
+remote-endpoint = <_con>;
+};
+};
+};
+};
+
+...
--
2.33.0
[PATCH v14 3/9] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, _dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(>dev, ingenic_dw_hdmi_cleanup,
hdmi);
[PATCH v14 0/9] MIPS: JZ4780 and CI20 HDMI
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by
p...@crapouillou.net)
- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by p...@crapouillou.net)
- removed some comments (suggested by p...@crapouillou.net)
PATCH V5 2021-10-05 14:28:44:
- dropped mode_fixup and timings support in dw-hdmi as it is no longer needed
in this V5 (by h...@goldelico.com)
- dropped "drm/ingenic: add some jz4780 specific features" (stimulated by
p...@crapouillou.net)
- fixed typo in commit subject: "synopsis" -> "synopsys" (by h...@goldelico.com)
- swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by
h...@goldelico.com)
- im
Re: [PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI
Hi,
> Am 09.02.2022 um 15:02 schrieb Paul Cercueil :
>
> Hi,
>
> Le mer., févr. 9 2022 at 14:51:12 +0100, H. Nikolaus Schaller
> a écrit :
>> Paul,
>>> Am 09.02.2022 um 12:52 schrieb Paul Cercueil :
>>> Hi Nikolaus,
>>> I tried applying patches 1-2, but they don't apply cleanly on top of
>>> drm-misc/drm-misc-next.
>> Ok I had rebased to linux-next some days ago and it appears that patch 1/9
>> has now arrived in drm-misc/drm-misc-next.
>> So we can drop 1/9.
>
> Yes, some weeks ago I did apply patch 1/9 from one of your previous
> patchsets. Patch 2 was applied as well (commit b807fd2c43fe ("drm/ingenic:
> Add support for JZ4780 and HDMI output")), but you then said that it didn't
> work and needed a fix.
>
> For this patchset you should always base on top of drm-misc/drm-misc-next,
> and not on linux-next; they have different schedules. You can drop patch #1,
> and rework patch #2 so that it only fixes the previously incorrect behaviour.
>
>>> Could you rebase on top of that tree?
>> Sure.
>> Unfortunatley my v14 breaks the display again. It is not much fun to develop
>> on top of such a moving target...
>
> I can imagine...
Have found it. Was a typo in a rebase conflict resolution...
So, v14 can come now.
BR and thanks,
Nikolaus
Re: [PATCH v13 5/9] drm/synopsys+ingenic: repair hot plug detection
Hi Paul,
> Am 09.02.2022 um 13:01 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le mer., févr. 2 2022 at 17:31:19 +0100, H. Nikolaus Schaller
> a écrit :
>> so that it calls drm_kms_helper_hotplug_event().
>> We need to set .poll_enabled but that struct component
>> can only be accessed in the core code. Hence we add a public
>> setter function.
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
>> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++
>> include/drm/bridge/dw_hdmi.h | 1 +
>> 3 files changed, 12 insertions(+)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 54d8fdad395f5..52e7cd2e020d3 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>> return 0;
>> }
>> +void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
>> +{
>> +if (hdmi->bridge.dev)
>> +hdmi->bridge.dev->mode_config.poll_enabled = enable;
>> +else
>> +dev_warn(hdmi->dev, "no hdmi->bridge.dev");
>> +}
>> +EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
>> +
>> struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>>const struct dw_hdmi_plat_data *plat_data)
>> {
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> index 34e986dd606cf..90547a28dc5c7 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
>> @@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void
>> *data,
>> if (mode->clock > 216000)
>> return MODE_CLOCK_HIGH;
>> +dw_hdmi_enable_poll(hdmi, true);
>> +
>
> It would be a better idea to move this patch before the patch that creates
> ingenic-dw-hdmi.c. Then you wouldn't have to patch a file that was just
> introduced.
The main reason to have a separate patch was that I was not sure what is
already merged somewhere and what is not.
And fixing something which is not yet introduced makes it quite difficult to
explain, why it is needed at all...
So I would prefer to leave it as is until more comments arrive.
>
> As for the patch itself, I guess it's fine, but is that really needed? My
> understanding is that it's the hdmi-connector's job to poll.
The hardware gpio that we can define for the hdmi-connector seems not to be
available on all CI20 boards.
Hence we must trigger (enable) the poll logic of the dw-hdmi bridge from the
SoC specialization.
This seems to be best done in the ingenic-dw-hdmi driver.
Unless someone has a better idea how the dw-hdmi driver could find out that it
should poll if a connector is defined.
The base driver seems as if it has been developed long ago without connectors
and bridge chains in mind.
Hence we are retrofitting fixes for changes introduced outside the drivers.
BR,
Nikolaus
Re: [PATCH v13 6/9] dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector
Hi Paul,
> Am 09.02.2022 um 13:18 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le mer., févr. 2 2022 at 17:31:20 +0100, H. Nikolaus Schaller
> a écrit :
>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> introduced a new mechanism to negotiate bus formats between hdmi connector
>> and the synopsys hdmi driver inside the jz4780.
>> By this, the dw-hdmi is no longer the only bridge and sets up a list
>> of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
>> This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but
>> only
>> produces a black screen.
>> This fix is based on the observation that max_bpc = 0 when running this
>> function while info->bpc = 8. Since the formats checks before this always
>> test
>> for max_bpc >= info->pbc indirectly my assumption is that we must check it
>> here as well.
>
> This fix looks really strange to me, so I'll let the DRM experts comment.
Well, yes. We should maybe look for comments by the synopsys/dw-hdmi
specialists.
>
> It would still be better to move the patch before the introduction of
> dw-ingenic-hdmi.c, so that once this one is introduced, everything works.
> This also enables bisectability.
Ok, good.
BR and thanks,
Nikolaus
>
> Cheers,
> -Paul
>
>
>> Adding the proposed patch makes the CI20/jz4780 panel work again in
>> MEDIA_BUS_FMT_RGB888_1X24 mode.
>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 52e7cd2e020d3..34703a15ee4ff 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2620,10 +2620,10 @@ static u32
>> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> }
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCRCB422)
>> output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCRCB444)
>> output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> /* Default 8bit RGB fallback */
>> --
>> 2.33.0
>
>
Re: [PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI
Paul, > Am 09.02.2022 um 12:52 schrieb Paul Cercueil : > > Hi Nikolaus, > > I tried applying patches 1-2, but they don't apply cleanly on top of > drm-misc/drm-misc-next. Ok I had rebased to linux-next some days ago and it appears that patch 1/9 has now arrived in drm-misc/drm-misc-next. So we can drop 1/9. > > Could you rebase on top of that tree? Sure. Unfortunatley my v14 breaks the display again. It is not much fun to develop on top of such a moving target... So I have to find out first what was broken this time before I can send out a new version. BR, Nikolaus
[PATCH v13 8/9] MIPS: DTS: CI20: fix how ddc power is enabled
Originally we proposed a new hdmi-5v-supply regulator reference
for CI20 device tree but that was superseded by a better idea to use
the already defined "ddc-en-gpios" property of the "hdmi-connector".
Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
been applied to v5.17-rc1, we add this on top.
Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Paul Cercueil
---
arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 3e336b3dbb109..ab6e3dc0bc1d0 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -83,6 +83,8 @@ hdmi_out: connector {
label = "HDMI OUT";
type = "a";
+ ddc-en-gpios = < 25 GPIO_ACTIVE_HIGH>;
+
port {
hdmi_con: endpoint {
remote-endpoint = <_hdmi_out>;
@@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
gpio = < 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-
- hdmi_power: fixedregulator@3 {
- compatible = "regulator-fixed";
-
- regulator-name = "hdmi_power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = < 25 0>;
- enable-active-high;
- };
};
{
@@ -576,8 +567,6 @@ {
pinctrl-names = "default";
pinctrl-0 = <_hdmi_ddc>;
- hdmi-5v-supply = <_power>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.33.0
[PATCH v13 5/9] drm/synopsys+ingenic: repair hot plug detection
so that it calls drm_kms_helper_hotplug_event().
We need to set .poll_enabled but that struct component
can only be accessed in the core code. Hence we add a public
setter function.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f5..52e7cd2e020d3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
index 34e986dd606cf..90547a28dc5c7 100644
--- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
if (mode->clock > 216000)
return MODE_CLOCK_HIGH;
+ dw_hdmi_enable_poll(hdmi, true);
+
return MODE_OK;
}
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v13 6/9] dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 52e7cd2e020d3..34703a15ee4ff 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCRCB422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCRCB444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v13 4/9] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, _dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(>dev, ingenic_dw_hdmi_cleanup,
hdmi);
[PATCH v13 7/9] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(>dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(>dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = _connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v13 2/9] drm/ingenic: Add support for JZ4780 and HDMI output
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 63 ++-
drivers/gpu/drm/ingenic/ingenic-drm.h | 38 ++
2 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 9c60fc4605e4b..caa70fdd45466 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -6,6 +6,7 @@
#include "ingenic-drm.h"
+#include
#include
#include
#include
@@ -49,6 +50,11 @@ struct ingenic_dma_hwdesc {
u32 addr;
u32 id;
u32 cmd;
+ /* extended hw descriptor for jz4780 */
+ u32 offsize;
+ u32 pagewidth;
+ u32 cpos;
+ u32 dessize;
} __aligned(16);
struct ingenic_dma_hwdescs {
@@ -59,7 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
+ bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -446,6 +455,9 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
+ if (priv->soc_info->plane_f0_not_working && plane == >f0)
+ return -EINVAL;
+
crtc_state = drm_atomic_get_existing_crtc_state(state,
crtc);
if (WARN_ON(!crtc_state))
@@ -662,6 +674,33 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
hwdesc->cmd = JZ_LCD_CMD_EOF_IRQ | (width * height * cpp / 4);
hwdesc->next = dma_hwdesc_addr(priv, next_id);
+ if (priv->soc_info->use_extended_hwdesc) {
+ hwdesc->cmd |= JZ_LCD_CMD_FRM_ENABLE;
+
+ /* Extended 8-byte descriptor */
+ hwdesc->cpos = 0;
+ hwdesc->offsize = 0;
+ hwdesc->pagewidth = 0;
+
+ switch (newstate->fb->format->format) {
+ case DRM_FORMAT_XRGB1555:
+ hwdesc->cpos |= JZ_LCD_CPOS_RGB555;
+ fallthrough;
+ case DRM_FORMAT_RGB565:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_15_16;
+ break;
+ case DRM_FORMAT_XRGB:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_18_24;
+ break;
+ }
+ hwdesc->cpos |= (JZ_LCD_CPOS_COEFFICIENT_1 <<
+JZ_LCD_CPOS_COEFFICIENT_OFFSET);
+ hwdesc->dessize =
+ (0xff << JZ_LCD_DESSIZE_ALPHA_OFFSET) |
+ FIELD_PREP(JZ_LCD_DESSIZE_HEIGHT_MASK, height -
1) |
+ FIELD_PREP(JZ_LCD_DESSIZE_WIDTH_MASK, width -
1);
+ }
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
fourcc = newstate->fb->format->format;
@@ -693,6 +732,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->use_extended_hwdesc)
+ cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
+
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
@@ -1015,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1272,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(>clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1468,10 +1514,25 @@ static const
[PATCH v13 3/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
---
.../display/bridge/ingenic,jz4780-hdmi.yaml | 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
new file mode 100644
index 0..b8219eab4475a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+const: ingenic,jz4780-dw-hdmi
+
+ reg-io-width:
+const: 4
+
+ clocks:
+maxItems: 2
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from LCD controller output.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Link to the HDMI connector.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ports
+ - reg-io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <>;
+interrupt-parent = <>;
+interrupts = <3>;
+clocks = < JZ4780_CLK_AHB0>, < JZ4780_CLK_HDMI>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in: port@0 {
+reg = <0>;
+dw_hdmi_in: endpoint {
+remote-endpoint = <_lcd_out>;
+};
+};
+hdmi_out: port@1 {
+reg = <1>;
+dw_hdmi_out: endpoint {
+remote-endpoint = <_con>;
+};
+};
+};
+};
+
+...
--
2.33.0
[PATCH v13 1/9] drm/ingenic: prepare ingenic drm for later addition of JZ4780
This changes the way the regmap is allocated to prepare for the
later addition of the JZ4780 which has more registers and bits
than the others.
Therefore we make the regmap as big as the reg property in
the device tree tells.
Suggested-by: Paul Cercueil
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index b4943a56be09b..9c60fc4605e4b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -173,7 +173,6 @@ static const struct regmap_config ingenic_drm_regmap_config
= {
.val_bits = 32,
.reg_stride = 4,
- .max_register = JZ_REG_LCD_SIZE1,
.writeable_reg = ingenic_drm_writeable_reg,
};
@@ -1011,6 +1010,8 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
struct ingenic_drm_bridge *ib;
struct drm_device *drm;
void __iomem *base;
+ struct resource *res;
+ struct regmap_config regmap_config;
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
@@ -1056,14 +1057,16 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
drm->mode_config.funcs = _drm_mode_config_funcs;
drm->mode_config.helper_private = _drm_mode_config_helpers;
- base = devm_platform_ioremap_resource(pdev, 0);
+ base = devm_platform_get_and_ioremap_resource(pdev, 0, );
if (IS_ERR(base)) {
dev_err(dev, "Failed to get memory resource\n");
return PTR_ERR(base);
}
+ regmap_config = ingenic_drm_regmap_config;
+ regmap_config.max_register = res->end - res->start;
priv->map = devm_regmap_init_mmio(dev, base,
- _drm_regmap_config);
+ _config);
if (IS_ERR(priv->map)) {
dev_err(dev, "Failed to create regmap\n");
return PTR_ERR(priv->map);
--
2.33.0
[PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI
PATCH V13 2022-02-02 17:31:22: * 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by p...@crapouillou.net) * 4/9: replace ".." by "." (by p...@crapouillou.net) * 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net) * 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net) PATCH V12 2022-01-31 13:26:54: This version reworks how hdmi ddc power is controlled by connector and not by ddc/hdmi bridge driver. Also some patches of the previous version of this series have been removed since they are already applied to mips-next/linux/next/v5.17-rc1. Fixes and changes: - repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com) - fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and p...@crapouillou.net) - adjustments for ci20.dts to use connector gpio for +5v (suggested by several) - to add control of "ddc-en-gpios" to hdmi-connector driver (by h...@goldelico.com) - regulator code removed because we now use the "ddc-en-gpios" of the connector driver (suggested by p...@crapouillou.net) - bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested by robh...@kernel.org) - rebase on v5.17-rc2 PATCH V11 2021-12-02 19:39:52: - patch 4/8: change devm_regulator_get_optional to devm_regulator_get and remove NULL check (requested by broo...@kernel.org) - patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org) PATCH V10 2021-11-30 22:26:41: - patch 3/8: fix $id and $ref paths (found by r...@kernel.org) PATCH V9 2021-11-24 22:29:14: - patch 6/8: remove optional <0> for assigned-clocks and unintentionally included "unwedge" setup (found by p...@crapouillou.net) - patch 4/8: some cosmetics make regulator enable/disable only if not NULL (found by p...@crapouillou.net) simplify/fix error handling and driver cleanup on remove (proposed by p...@crapouillou.net) - patch 3/8: fix #include path in example (found by p...@crapouillou.net) fix missing "i" in unevaluatedProperties (found by r...@kernel.org) fix 4 spaces indentation for required: property (found by r...@kernel.org) PATCH V8 2021-11-23 19:14:00: - fix a bad editing result from patch 2/8 (found by p...@crapouillou.net) PATCH V7 2021-11-23 18:46:23: - changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net) - fixed LCD1 irq number (bug found by p...@crapouillou.net) - removed "- 4" for calculating max_register (suggested by p...@crapouillou.net) - use unevaluatedPropertes instead of additionalProperties (suggested by r...@kernel.org) - moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org) - adjusted assigned-clocks changes to upstream which added some for SSI (by h...@goldelico.com) - rebased and tested with v5.16-rc2 + patch set drm/ingenic by p...@crapouillou.net (by h...@goldelico.com) PATCH V6 2021-11-10 20:43:33: - changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com) - made ingenic-dw-hdmi an independent platform driver which can be compiled as module and removed error patch fixes for IPU (suggested by p...@crapouillou.net) - moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by p...@crapouillou.net) - fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee (by h...@goldelico.com) - added a base patch to calculate regmap size from DTS reg property (requested by p...@crapouillou.net) - restored resetting all bits except one in LCDOSDC (requested by p...@crapouillou.net) - clarified setting of cpos (suggested by p...@crapouillou.net) - moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net) - simplified mask definitions for JZ_LCD_DESSIZE (requested by p...@crapouillou.net) - removed setting alpha premultiplication (suggested by p...@crapouillou.net) - removed some comments (suggested by p...@crapouillou.net) PATCH V5 2021-10-05 14:28:44: - dropped mode_fixup and timings support in dw-hdmi as it is no longer needed in this V5 (by h...@goldelico.com) - dropped "drm/ingenic: add some jz4780 specific features" (stimulated by p...@crapouillou.net) - fixed typo in commit subject: "synopsis" -> "synopsys" (by h...@goldelico.com) - swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by h...@goldelico.com) - improved, simplified, fixed, dtbschecked ingenic-jz4780-hdmi.yaml and made dependent of bridge/synopsys,dw-hdmi.yaml (based on suggestions by max...@cerno.tech) - fixed binding vs. driver use of hdmi-5v regulator (suggested by max...@cerno.tech) - dropped "drm/bridge: synopsis: Fix to properly handle HPD" - was a no longer needed workaround for a previous version (suggested by max...@cerno.tech) PATCH V4 2021-09-27 18:44:38: - fix setting output_port = 1 (issue found by p...@crapouillou.net) - ci
