Skip to contentSkip to conversation

LVDS (LDB) driver for i.MX53 IPU

DISCUSSION Martin Fuzzey 3 participants 4 messages Mar 4, 2013 – May 24, 2013

lore
Share & tools
lore
#0 lore raw

Hi Sascha,

I need to add LVDS support to your staging imx/drm driver.

First of all are there any patches floating around to do that? (a search of the mailing list didn't turn up any).

From a hardware point of view it looks quite simple (just one register
to configure) but unfortunately that register is in the IOMUXC region.

That means that if I write a new platform driver similar to drivers/staging/imx-drm/parallel-display.c (with a new DT node pointing to the reg) the request_resource() will fail since it will already be claimed by the iomuxc driver.

The only solutions I can think of are:
1) Add exported function to the iomuxc driver to get the register or
2) Directly ioremap() the address

Both of these sound horrible.

Do you have any suggestions?

I guess the generic question I'm asking is how to handle the case where unrelated drivers require access to the same memory regions?

Regards,

Martin

#1 lore raw

Hi Martin,

Quoted 21 lines · Martin Fuzzey

Hi Sascha,

I need to add LVDS support to your staging imx/drm driver.

First of all are there any patches floating around to do that? (a search of the mailing list didn't turn up any).

From a hardware point of view it looks quite simple (just one register to configure) but unfortunately that register is in the IOMUXC region.

That means that if I write a new platform driver similar to drivers/staging/imx-drm/parallel-display.c (with a new DT node pointing to the reg) the request_resource() will fail since it will already be claimed by the iomuxc driver.

The only solutions I can think of are:
1) Add exported function to the iomuxc driver to get the register or
2) Directly ioremap() the address

Quoted 7 lines

Both of these sound horrible.

Do you have any suggestions?

I guess the generic question I'm asking is how to handle the case where unrelated drivers require access to the same memory regions?

We have a driver for the ldb. Indeed the driver itself is trivial, but the integration is tricky. For accessing the register the syscon binding can be used. The clock is also a problem, also the mux to the IPU(s)

I'll talk with Philipp tomorrow and I think we can send you the current state then.

Sascha

Signature · 4 lines
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#2 lore raw

Hi Sascha

Quoted 31 lines · Sascha Hauer

Hi Martin,

Quoted 21 lines · Martin Fuzzey

Hi Sascha,

I need to add LVDS support to your staging imx/drm driver.

First of all are there any patches floating around to do that? (a search of the mailing list didn't turn up any).

From a hardware point of view it looks quite simple (just one register to configure) but unfortunately that register is in the IOMUXC region.

That means that if I write a new platform driver similar to drivers/staging/imx-drm/parallel-display.c (with a new DT node pointing to the reg) the request_resource() will fail since it will already be claimed by the iomuxc driver.

The only solutions I can think of are:
1) Add exported function to the iomuxc driver to get the register or
2) Directly ioremap() the address

Quoted 6 lines

Both of these sound horrible.

Do you have any suggestions?

I guess the generic question I'm asking is how to handle the case where unrelated drivers require access to the same memory regions?

Quoted 6 lines

We have a driver for the ldb. Indeed the driver itself is trivial, but the integration is tricky. For accessing the register the syscon binding can be used. The clock is also a problem, also the mux to the IPU(s)

I'll talk with Philipp tomorrow and I think we can send you the current state then.

How's it looking in the meantime? Any plans to mainline it? Or would you be prepared to publish what you've got to try and see whether others can help you with this?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

#3 lore raw

Hi Guennadi,

Quoted 9 lines · Guennadi Liakhovetski

Hi Sascha

Quoted 5 lines · Sascha Hauer

We have a driver for the ldb. Indeed the driver itself is trivial, but the integration is tricky. For accessing the register the syscon binding can be used. The clock is also a problem, also the mux to the IPU(s)

Quoted 5 lines
Quoted 2 lines

I'll talk with Philipp tomorrow and I think we can send you the current state then.

How's it looking in the meantime? Any plans to mainline it? Or would you be prepared to publish what you've got to try and see whether others can help you with this?

Philipp submitted them on March 28 "[PATCH v3 0/11] LVDS Display Bridge support for i.MX"
The drivers/staging parts don't seem to have been applied (not in linux/next at any rate)

I've added them to my local tree and they work fine (on i.MX53)

Martin