Re: [PATCH 0/4] ARM: Renesas: R-Car3: Add product register support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dirk,

On Fri, May 27, 2016 at 4:56 PM, Dirk Behme <dirk.behme@xxxxxxxxxxxx> wrote:
> On 27.05.2016 05:13, Magnus Damm wrote:
>> I don't think anyone disagrees that it makes sense to be able to
>> determine ES version during runtime. The questions in my mind are how
>> to do it
>
>
>
> I've made a proposal ;) And I'm happy to discuss technically about it.

Thanks! It would be interesting to know the reason behind your
interest in these things. For instance, if you are interested in
reducing run time memory usage, or general source code duplication
reduction. Do you have any target platform that you can upstream board
support for?

>> and the urgency.
>
>
>
> Regarding the urgency: Someone has accepted the hard coded PRODUCT register
> (and MODEMR) being in renesas-drivers, now:
>
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/gpu/drm/rcar-du/rcar_du_crtc.c?h=topic/gen3-latest#n177
>
> This does really hurts us.
>
> Therefore, I try to get this removed as soon as possible to hopefully get a
> Renesas BSP without this, the next time.
>
> If anybody finds an other way to remove that, that would be fine, too.

Please share the underlying issue so we can fix that.

>> So far we have decided to use the compatible string since it is a
>> common driver model abstraction already used by device drivers and
>> hardware description in DT. Using DT compat string matching we can
>> have logic in the drivers to handle ES differences if needed. As for
>> how to enable the workaround, my opinion is that the missing piece
>> consists of ES workaround code that appends ES suffix information to
>> the DT compat strings automatically during boot.
>
> Technically this sounds slightly too complicated to me. As I have to
> advocate my proposal (inspired from an other mainline SoC family) I'd think
> that my proposal is easier.

It may indeed be easier in the short term, but I feel we need to
consider how to support a wide range of SoCs in a consistent way.

>> I suppose the workaround is not yet implemented because no one has
>> deemed this topic as particularly urgent. Until it becomes urgent or a
>> new ES version appears the affected users can simply adjust the DT
>> binding themselves. This is what happened to the "sata-r8a7790-es1"
>> case above.

Can you see any technical reason why using DT compat strings wouldn't
solve your case?

Thanks,

/ magnus



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux