Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()

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

 




On 2013-12-13 10:32, Archit Taneja wrote:
> On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
>> On 2013-12-12 01:10, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>>> omapdss driver uses a omapdss platform device to pass platform specific
>>>> function pointers and DSS hardware version from the arch code to the
>>>> driver. This device is needed also when booting with DT.
>>>>
>>>> This patch adds omapdss_init_of() function, called from
>>>> board-generic at
>>>> init time, which creates the omapdss device.
>>>
>>> Is this a temporary solution that you plan to later replace with DT-only
>>> device instantiation ?
>>
>> It's a long term task to remove the "virtual" omapdss device. Removing
>> the platform data that we pass has been very difficult.
> 
> Even if we remove the platform data, what would be the right place to
> register the drm, fb and vout devices? We need to make sure their
> drivers are probed only after omapdss is initialised.

That's the same issue as we have already, so removing omapdss doesn't
affect that.

I don't think we have any good way to ensure those devices are not
probed before omapdss. We just have to manage the case that omapdss has
not been probed yet, by checking if omapdss is there and if not, return
EPROBE_DEFER.

>> For example, we need to get the OMAP revision to know which OMAP DSS
>> hardware we have. We can't get that information from the DSS hardware
>> (thank you, HW designers! ;).
>>
> 
>> Another is DSI pin muxing. I think we need a new pinmuxing driver for
>> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
>> very simple, but the register fields are varying lengths and at varying
>> positions, so pinmux-single doesn't work for it.
> 
> I have seen other OMAP drivers passing control module register info to
> their DT node. Instead of having a pinmux driver for a single register,
> we might want to consider just passing the control module register, and
> take care of the reg fields and masks in the OMAP DSI driver itself.

Yes, that's also one option. Quite ugly, though =).

 Tomi


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux