[RFC PATCH] drm/panfrost: Add initial panfrost driver

[Neil Armstrong]

On 08/03/2019 15:39, Rob Herring wrote:
> On Fri, Mar 8, 2019 at 2:18 AM Neil Armstrong <narmstrong at baylibre.com> wrote:
>>
>> On 08/03/2019 06:00, Alyssa Rosenzweig wrote:
>>> Oh my onions, it's really here! It's really coming! It's really here!
>>>
>>> ----
>>>
>>
>> <snip>
>>
>>>
>>>> +static const struct of_device_id dt_match[] = {
>>>> +    { .compatible = "arm,mali-t760" },
>>>> +    { .compatible = "arm,mali-t860" },
>>>> +    {}
>>>> +};
>>>
>>> Do we want to add compatibles for the rest of the Mali's on the initial
>>> merge, or wait until they're actually confirmed working so we don't load
>>> and cause problems on untested hardware?
>>
>> We should definitely stick to the midgard bindings here and add all the compatibles
>> even if we haven't tested yet, maybe by adding a warning mechanism reporting
>> when used on an untested mali core ?
> 
> Compatibles is the only thing we have documenting what's tested or
> not. So either we add compatibles when tested or remove warnings when
> tested? Either way a kernel update is needed.

The kernel will be updated only to remove the warning, since midgard is
also HW discoverable, we can add all the bindings compatible without risks.

> 
>> BTW rob, I resent the bifrost binding doc with an unique, "arm,mali-bifrost"
>> compatible, adding it would help starting debugging bifrost aswell !
> 
> There's a lot missing for bifrost, and a compatible string is the
> least of it. I can probably add most of it, but can't test any of it
> (and no one can as the mesa side is not done).

What's the problem into adding the compatibles and add a warning filtered on
tested model on the HW discovered ID instead ?

> 
>>
>>>
>>>> +enum base_hw_feature {
>>>       ...
>>>> +    HW_FEATURE_PROTECTED_MODE
>>>       ...
>>>> +};
>>
>> <snip>
>>
>>>
>>> ----------------------------
>>>
>>> Overall, I'm super happy to see this! Nice work, guys! ^_^
>>
>> Yeah pretty cool work !
>>
>> I'll run it on a T820 ASAP and push fixes on the gitlab repo.
> 
> What SoC is that?

Amlogic S912

The t820 node is not upstream since it needs a bindings change to handle
the soc specific reset lines.
The reset lines are needed because the internal midgard soft-reset does not
work, thus needing the external reset lines.
It also needs some other tweaks, but I'll need to work on it to understand
what's needed on the drm driver, the mali_kbase needs a hacky tweak to
enable all the cores, but you seem to manually enable the core which is fine.

Neil

> 
> Rob
>