lkml.org 
[lkml]   [2019]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [V3, 4/4] media: platform: dwc: Add MIPI CSI-2 controller driver
From
Date


On 11-Jan-19 7:25, Eugen.Hristev@microchip.com wrote:
>
>
> On 10.01.2019 18:18, Luis de Oliveira wrote:
>>
>>
>> On 09-Jan-19 13:07, Eugen.Hristev@microchip.com wrote:
>>>
>>>
>>> On 19.10.2018 15:52, Luis Oliveira wrote:
>>>> Add the Synopsys MIPI CSI-2 controller driver. This
>>>> controller driver is divided in platform dependent functions
>>>> and core functions. It also includes a platform for future
>>>> DesignWare drivers.
>>>>
>>>> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
>>>> ---
>>>> Changelog
>>>> v2-V3
>>>> - exposed IPI settings to userspace
>>>> - fixed headers
>>>>
>>>> MAINTAINERS | 11 +
>>>> drivers/media/platform/dwc/Kconfig | 30 +-
>>>> drivers/media/platform/dwc/Makefile | 2 +
>>>> drivers/media/platform/dwc/dw-csi-plat.c | 699 +++++++++++++++++++++++++++++++
>>>> drivers/media/platform/dwc/dw-csi-plat.h | 77 ++++
>>>> drivers/media/platform/dwc/dw-mipi-csi.c | 494 ++++++++++++++++++++++
>>>> drivers/media/platform/dwc/dw-mipi-csi.h | 202 +++++++++
>>>> include/media/dwc/dw-mipi-csi-pltfrm.h | 102 +++++
>>>> 8 files changed, 1616 insertions(+), 1 deletion(-)
>>>> create mode 100644 drivers/media/platform/dwc/dw-csi-plat.c
>>>> create mode 100644 drivers/media/platform/dwc/dw-csi-plat.h
>>>> create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.c
>>>> create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.h
>>>> create mode 100644 include/media/dwc/dw-mipi-csi-pltfrm.h
>>>>
>>>
>>> [snip]
>>>
>>>> +/* Video formats supported by the MIPI CSI-2 */
>>>> +const struct mipi_fmt dw_mipi_csi_formats[] = {
>>>> + {
>>>> + /* RAW 8 */
>>>> + .code = MEDIA_BUS_FMT_SBGGR8_1X8,
>>>> + .depth = 8,
>>>> + },
>>>> + {
>>>> + /* RAW 10 */
>>>> + .code = MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE,
>>>> + .depth = 10,
>>>> + },
>>>
>>> Hi Luis,
>>>
>>> Any reason why RAW12 format is not handled here ?
>>>
>>> Here, namely MEDIA_BUS_FMT_SBGGR12_1X12 etc.
>>>
>> Hi Eugen,
>>
>> My Hw testing setup currently does not support it, so I didn't add it.
>>
>>>> + {
>>>> + /* RGB 565 */
>>>> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
>>>> + .depth = 16,
>>>> + },
>>>> + {
>>>> + /* BGR 565 */
>>>> + .code = MEDIA_BUS_FMT_RGB565_2X8_LE,
>>>> + .depth = 16,
>>>> + },
>>>> + {
>>>> + /* RGB 888 */
>>>> + .code = MEDIA_BUS_FMT_RGB888_2X12_LE,
>>>> + .depth = 24,
>>>> + },
>>>> + {
>>>> + /* BGR 888 */
>>>> + .code = MEDIA_BUS_FMT_RGB888_2X12_BE,
>>>> + .depth = 24,
>>>> + },
>>>> +};
>>>
>>> [snip]
>>>
>>>> +
>>>> +void dw_mipi_csi_set_ipi_fmt(struct mipi_csi_dev *csi_dev)
>>>> +{
>>>> + struct device *dev = csi_dev->dev;
>>>> +
>>>> + if (csi_dev->ipi_dt)
>>>> + dw_mipi_csi_write(csi_dev, reg.IPI_DATA_TYPE, csi_dev->ipi_dt);
>>>> + else {
>>>> + switch (csi_dev->fmt->code) {
>>>> + case MEDIA_BUS_FMT_RGB565_2X8_BE:
>>>> + case MEDIA_BUS_FMT_RGB565_2X8_LE:
>>>> + dw_mipi_csi_write(csi_dev,
>>>> + reg.IPI_DATA_TYPE, CSI_2_RGB565);
>>>> + dev_dbg(dev, "DT: RGB 565");
>>>> + break;
>>>> +
>>>> + case MEDIA_BUS_FMT_RGB888_2X12_LE:
>>>> + case MEDIA_BUS_FMT_RGB888_2X12_BE:
>>>> + dw_mipi_csi_write(csi_dev,
>>>> + reg.IPI_DATA_TYPE, CSI_2_RGB888);
>>>> + dev_dbg(dev, "DT: RGB 888");
>>>> + break;
>>>> + case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
>>>> + dw_mipi_csi_write(csi_dev,
>>>> + reg.IPI_DATA_TYPE, CSI_2_RAW10);
>>>> + dev_dbg(dev, "DT: RAW 10");
>>>> + break;
>>>> + case MEDIA_BUS_FMT_SBGGR8_1X8:
>>>> + dw_mipi_csi_write(csi_dev,
>>>> + reg.IPI_DATA_TYPE, CSI_2_RAW8);
>>>> + dev_dbg(dev, "DT: RAW 8");
>>>> + break;
>>>
>>> Same here, in CSI_2_RAW12 case it will default to a RGB565 case.
>>>
>>> Thanks,
>>>
>>> Eugen
>>>
>>>
>> I will try to add the support for this data type in my next patchset if not I
>> will flag it as unsupported for now in the commit message and code.
>
> Hi Luis,
>
> I am currently trying to see if your driver works , and I need the RAW12
> type, that's why I am asking about it.
>
> One question related to the subdevice you create here, how do you
> register this subdev into the media subsystem ? sync or async, or not at
> all ?
> After the driver probes, there is no call to the set format functions, I
> added a node inside the Device tree, I see you are registering media
> pads, but the other endpoint needs to be an async waiting for completion
> node or your subdev registers in some other way ? (maybe some link
> validation required ?)
>
> Thanks for your help,
>
> Eugen
>
Hi Eugen,

On top of this dphy+controller solution I use a wrapper driver that binds this
two together and create the links.
I use V4L2_ASYNC_MATCH_FWNODE and v4l2_async_notifier_operations to match and
bound all my sensors until completion.

My dt looks like this:

camera wrapper {

video_dev {
dma
}
vif_1 @reg {
...
}
..
vif_n @reg {
...
}
csi_1 @reg {
...
phy
port 1..2 {}
}
csi_n @reg {
...
phy
port 1..2 {}
}

Fundamentally It is the same principle as this
drivers/media/platform/exynos4-is/media-dev.c but my solution has more entities
for testing purposes.
Check the exynos4-is because is very similar to my top solution.

When I started doing this patchset I was thinking of sending the wrapper also
but I then decided to not do it because it is very narrow and focused in my
tests. But I can include it in v4 if everyone think its best.

Thank you,
Luis
>>
>> Thanks for your review,
>> Luis
>>
>>>
>>>> + default:
>>>> + dw_mipi_csi_write(csi_dev,
>>>> + reg.IPI_DATA_TYPE, CSI_2_RGB565);
>>>> + dev_dbg(dev, "Error");
>>>> + break;
>>>> + }
>>>> + }
>>>> +}
>>>> +
>>>
>>> [snip]
>>>
>>

\
 
 \ /
  Last update: 2019-01-11 09:12    [W:1.393 / U:7.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site