* [PATCH v2] [media] davinci: vpif: adaptions for DT support
@ 2017-06-09 16:10 Kevin Hilman
2017-06-15 20:12 ` Kevin Hilman
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Kevin Hilman @ 2017-06-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
The davinci VPIF is a single hardware block, but the existing driver
is broken up into a common library (vpif.c), output (vpif_display.c) and
intput (vpif_capture.c).
When migrating to DT, to better model the hardware, and because
registers, interrupts, etc. are all common,it was decided to
have a single VPIF hardware node[1].
Because davinci uses legacy, non-DT boot on several SoCs still, the
platform_drivers need to remain. But they are also needed in DT boot.
Since there are no DT nodes for the display/capture parts in DT
boot (there is a single node for the parent/common device) we need to
create platform_devices somewhere to instansiate the platform_drivers.
When VPIF display/capture are needed for a DT boot, the VPIF node
will have endpoints defined for its subdevs. Therefore, vpif_probe()
checks for the presence of endpoints, and if detected manually creates
the platform_devices for the display and capture platform_drivers.
[1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
Changes since v1:
- added proper error checking to kzalloc calls
- rebased onto media/master
drivers/media/platform/davinci/vpif.c | 57 ++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index 1b02a6363f77..c2d214dfaa3e 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -26,6 +26,7 @@
#include <linux/pm_runtime.h>
#include <linux/spinlock.h>
#include <linux/v4l2-dv-timings.h>
+#include <linux/of_graph.h>
#include "vpif.h"
@@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
static int vpif_probe(struct platform_device *pdev)
{
- static struct resource *res;
+ static struct resource *res, *res_irq;
+ struct platform_device *pdev_capture, *pdev_display;
+ struct device_node *endpoint = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
vpif_base = devm_ioremap_resource(&pdev->dev, res);
@@ -435,6 +438,58 @@ static int vpif_probe(struct platform_device *pdev)
spin_lock_init(&vpif_lock);
dev_info(&pdev->dev, "vpif probe success\n");
+
+ /*
+ * If VPIF Node has endpoints, assume "new" DT support,
+ * where capture and display drivers don't have DT nodes
+ * so their devices need to be registered manually here
+ * for their legacy platform_drivers to work.
+ */
+ endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+ endpoint);
+ if (!endpoint)
+ return 0;
+
+ /*
+ * For DT platforms, manually create platform_devices for
+ * capture/display drivers.
+ */
+ res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res_irq) {
+ dev_warn(&pdev->dev, "Missing IRQ resource.\n");
+ return -EINVAL;
+ }
+
+ pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture),
+ GFP_KERNEL);
+ if (pdev_capture) {
+ pdev_capture->name = "vpif_capture";
+ pdev_capture->id = -1;
+ pdev_capture->resource = res_irq;
+ pdev_capture->num_resources = 1;
+ pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
+ pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
+ pdev_capture->dev.parent = &pdev->dev;
+ platform_device_register(pdev_capture);
+ } else {
+ dev_warn(&pdev->dev, "Unable to allocate memory for pdev_capture.\n");
+ }
+
+ pdev_display = devm_kzalloc(&pdev->dev, sizeof(*pdev_display),
+ GFP_KERNEL);
+ if (pdev_display) {
+ pdev_display->name = "vpif_display";
+ pdev_display->id = -1;
+ pdev_display->resource = res_irq;
+ pdev_display->num_resources = 1;
+ pdev_display->dev.dma_mask = pdev->dev.dma_mask;
+ pdev_display->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
+ pdev_display->dev.parent = &pdev->dev;
+ platform_device_register(pdev_display);
+ } else {
+ dev_warn(&pdev->dev, "Unable to allocate memory for pdev_display.\n");
+ }
+
return 0;
}
--
2.9.3
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
2017-06-09 16:10 [PATCH v2] [media] davinci: vpif: adaptions for DT support Kevin Hilman
@ 2017-06-15 20:12 ` Kevin Hilman
2017-06-16 8:43 ` Sakari Ailus
` (2 subsequent siblings)
3 siblings, 0 replies; 7+ messages in thread
From: Kevin Hilman @ 2017-06-15 20:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Hans, Mauro,
On Fri, Jun 9, 2017 at 9:10 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> The davinci VPIF is a single hardware block, but the existing driver
> is broken up into a common library (vpif.c), output (vpif_display.c) and
> intput (vpif_capture.c).
>
> When migrating to DT, to better model the hardware, and because
> registers, interrupts, etc. are all common,it was decided to
> have a single VPIF hardware node[1].
>
> Because davinci uses legacy, non-DT boot on several SoCs still, the
> platform_drivers need to remain. But they are also needed in DT boot.
> Since there are no DT nodes for the display/capture parts in DT
> boot (there is a single node for the parent/common device) we need to
> create platform_devices somewhere to instansiate the platform_drivers.
>
> When VPIF display/capture are needed for a DT boot, the VPIF node
> will have endpoints defined for its subdevs. Therefore, vpif_probe()
> checks for the presence of endpoints, and if detected manually creates
> the platform_devices for the display and capture platform_drivers.
>
> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Can this one make it for v4.13 along with the rest of the series that
it was initially sent with?
This one needed a respin for some error checking, but is otherwise
unchanged, and has been tested on top of media/next.
Thanks,
Kevin
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
2017-06-09 16:10 [PATCH v2] [media] davinci: vpif: adaptions for DT support Kevin Hilman
2017-06-15 20:12 ` Kevin Hilman
@ 2017-06-16 8:43 ` Sakari Ailus
2017-06-16 17:49 ` Kevin Hilman
[not found] ` <CGME20170617065837epcas5p49ffbc2fd9831b822ab6e368b86049025@epcas5p4.samsung.com>
2017-06-20 12:55 ` Lad, Prabhakar
3 siblings, 1 reply; 7+ messages in thread
From: Sakari Ailus @ 2017-06-16 8:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
> The davinci VPIF is a single hardware block, but the existing driver
> is broken up into a common library (vpif.c), output (vpif_display.c) and
> intput (vpif_capture.c).
>
> When migrating to DT, to better model the hardware, and because
> registers, interrupts, etc. are all common,it was decided to
> have a single VPIF hardware node[1].
>
> Because davinci uses legacy, non-DT boot on several SoCs still, the
> platform_drivers need to remain. But they are also needed in DT boot.
> Since there are no DT nodes for the display/capture parts in DT
> boot (there is a single node for the parent/common device) we need to
> create platform_devices somewhere to instansiate the platform_drivers.
>
> When VPIF display/capture are needed for a DT boot, the VPIF node
> will have endpoints defined for its subdevs. Therefore, vpif_probe()
> checks for the presence of endpoints, and if detected manually creates
> the platform_devices for the display and capture platform_drivers.
>
> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> Changes since v1:
> - added proper error checking to kzalloc calls
> - rebased onto media/master
>
> drivers/media/platform/davinci/vpif.c | 57 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
> index 1b02a6363f77..c2d214dfaa3e 100644
> --- a/drivers/media/platform/davinci/vpif.c
> +++ b/drivers/media/platform/davinci/vpif.c
> @@ -26,6 +26,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/spinlock.h>
> #include <linux/v4l2-dv-timings.h>
> +#include <linux/of_graph.h>
>
> #include "vpif.h"
>
> @@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
>
> static int vpif_probe(struct platform_device *pdev)
> {
> - static struct resource *res;
> + static struct resource *res, *res_irq;
> + struct platform_device *pdev_capture, *pdev_display;
> + struct device_node *endpoint = NULL;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> vpif_base = devm_ioremap_resource(&pdev->dev, res);
> @@ -435,6 +438,58 @@ static int vpif_probe(struct platform_device *pdev)
>
> spin_lock_init(&vpif_lock);
> dev_info(&pdev->dev, "vpif probe success\n");
> +
> + /*
> + * If VPIF Node has endpoints, assume "new" DT support,
> + * where capture and display drivers don't have DT nodes
> + * so their devices need to be registered manually here
> + * for their legacy platform_drivers to work.
> + */
> + endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
> + endpoint);
> + if (!endpoint)
> + return 0;
> +
> + /*
> + * For DT platforms, manually create platform_devices for
> + * capture/display drivers.
> + */
> + res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (!res_irq) {
> + dev_warn(&pdev->dev, "Missing IRQ resource.\n");
> + return -EINVAL;
> + }
> +
> + pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture),
> + GFP_KERNEL);
> + if (pdev_capture) {
> + pdev_capture->name = "vpif_capture";
> + pdev_capture->id = -1;
> + pdev_capture->resource = res_irq;
> + pdev_capture->num_resources = 1;
> + pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
> + pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
> + pdev_capture->dev.parent = &pdev->dev;
> + platform_device_register(pdev_capture);
Don't both of these (vpif_capture and vpif_display) depend on platform data?
Or do I miss something?
> + } else {
> + dev_warn(&pdev->dev, "Unable to allocate memory for pdev_capture.\n");
> + }
> +
> + pdev_display = devm_kzalloc(&pdev->dev, sizeof(*pdev_display),
> + GFP_KERNEL);
> + if (pdev_display) {
> + pdev_display->name = "vpif_display";
> + pdev_display->id = -1;
> + pdev_display->resource = res_irq;
> + pdev_display->num_resources = 1;
> + pdev_display->dev.dma_mask = pdev->dev.dma_mask;
> + pdev_display->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
> + pdev_display->dev.parent = &pdev->dev;
> + platform_device_register(pdev_display);
> + } else {
> + dev_warn(&pdev->dev, "Unable to allocate memory for pdev_display.\n");
> + }
> +
> return 0;
> }
>
--
Regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
2017-06-16 8:43 ` Sakari Ailus
@ 2017-06-16 17:49 ` Kevin Hilman
2017-06-16 21:10 ` Sakari Ailus
0 siblings, 1 reply; 7+ messages in thread
From: Kevin Hilman @ 2017-06-16 17:49 UTC (permalink / raw)
To: linux-arm-kernel
Sakari Ailus <sakari.ailus@iki.fi> writes:
> Hi Kevin,
>
> On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
>> The davinci VPIF is a single hardware block, but the existing driver
>> is broken up into a common library (vpif.c), output (vpif_display.c) and
>> intput (vpif_capture.c).
>>
>> When migrating to DT, to better model the hardware, and because
>> registers, interrupts, etc. are all common,it was decided to
>> have a single VPIF hardware node[1].
>>
>> Because davinci uses legacy, non-DT boot on several SoCs still, the
>> platform_drivers need to remain. But they are also needed in DT boot.
>> Since there are no DT nodes for the display/capture parts in DT
>> boot (there is a single node for the parent/common device) we need to
>> create platform_devices somewhere to instansiate the platform_drivers.
>>
>> When VPIF display/capture are needed for a DT boot, the VPIF node
>> will have endpoints defined for its subdevs. Therefore, vpif_probe()
>> checks for the presence of endpoints, and if detected manually creates
>> the platform_devices for the display and capture platform_drivers.
>>
>> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> Changes since v1:
>> - added proper error checking to kzalloc calls
>> - rebased onto media/master
>>
>> drivers/media/platform/davinci/vpif.c | 57 ++++++++++++++++++++++++++++++++++-
>> 1 file changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
>> index 1b02a6363f77..c2d214dfaa3e 100644
>> --- a/drivers/media/platform/davinci/vpif.c
>> +++ b/drivers/media/platform/davinci/vpif.c
>> @@ -26,6 +26,7 @@
>> #include <linux/pm_runtime.h>
>> #include <linux/spinlock.h>
>> #include <linux/v4l2-dv-timings.h>
>> +#include <linux/of_graph.h>
>>
>> #include "vpif.h"
>>
>> @@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
>>
>> static int vpif_probe(struct platform_device *pdev)
>> {
>> - static struct resource *res;
>> + static struct resource *res, *res_irq;
>> + struct platform_device *pdev_capture, *pdev_display;
>> + struct device_node *endpoint = NULL;
>>
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> vpif_base = devm_ioremap_resource(&pdev->dev, res);
>> @@ -435,6 +438,58 @@ static int vpif_probe(struct platform_device *pdev)
>>
>> spin_lock_init(&vpif_lock);
>> dev_info(&pdev->dev, "vpif probe success\n");
>> +
>> + /*
>> + * If VPIF Node has endpoints, assume "new" DT support,
>> + * where capture and display drivers don't have DT nodes
>> + * so their devices need to be registered manually here
>> + * for their legacy platform_drivers to work.
>> + */
>> + endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
>> + endpoint);
>> + if (!endpoint)
>> + return 0;
>> +
>> + /*
>> + * For DT platforms, manually create platform_devices for
>> + * capture/display drivers.
>> + */
>> + res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> + if (!res_irq) {
>> + dev_warn(&pdev->dev, "Missing IRQ resource.\n");
>> + return -EINVAL;
>> + }
>> +
>> + pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture),
>> + GFP_KERNEL);
>> + if (pdev_capture) {
>> + pdev_capture->name = "vpif_capture";
>> + pdev_capture->id = -1;
>> + pdev_capture->resource = res_irq;
>> + pdev_capture->num_resources = 1;
>> + pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
>> + pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
>> + pdev_capture->dev.parent = &pdev->dev;
>> + platform_device_register(pdev_capture);
>
> Don't both of these (vpif_capture and vpif_display) depend on platform data?
> Or do I miss something?
The driver can (continue to) work in legacy mode with platform_data. In
that case, there is no VPIF DT node (or a node without endpoints).
However, with recent changes, it can also work in DT mode, where the
VPIF node and endpoints used for display/capture come from DT, in which
case these nodes are created an don't depend on platform_data at all.
Hope that clarifies things, and thanks for the review,
Kevin
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
2017-06-16 17:49 ` Kevin Hilman
@ 2017-06-16 21:10 ` Sakari Ailus
0 siblings, 0 replies; 7+ messages in thread
From: Sakari Ailus @ 2017-06-16 21:10 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 16, 2017 at 10:49:24AM -0700, Kevin Hilman wrote:
> Sakari Ailus <sakari.ailus@iki.fi> writes:
>
> > Hi Kevin,
> >
> > On Fri, Jun 09, 2017 at 09:10:26AM -0700, Kevin Hilman wrote:
> >> The davinci VPIF is a single hardware block, but the existing driver
> >> is broken up into a common library (vpif.c), output (vpif_display.c) and
> >> intput (vpif_capture.c).
> >>
> >> When migrating to DT, to better model the hardware, and because
> >> registers, interrupts, etc. are all common,it was decided to
> >> have a single VPIF hardware node[1].
> >>
> >> Because davinci uses legacy, non-DT boot on several SoCs still, the
> >> platform_drivers need to remain. But they are also needed in DT boot.
> >> Since there are no DT nodes for the display/capture parts in DT
> >> boot (there is a single node for the parent/common device) we need to
> >> create platform_devices somewhere to instansiate the platform_drivers.
> >>
> >> When VPIF display/capture are needed for a DT boot, the VPIF node
> >> will have endpoints defined for its subdevs. Therefore, vpif_probe()
> >> checks for the presence of endpoints, and if detected manually creates
> >> the platform_devices for the display and capture platform_drivers.
> >>
> >> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> >>
> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> >> ---
> >> Changes since v1:
> >> - added proper error checking to kzalloc calls
> >> - rebased onto media/master
> >>
> >> drivers/media/platform/davinci/vpif.c | 57 ++++++++++++++++++++++++++++++++++-
> >> 1 file changed, 56 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
> >> index 1b02a6363f77..c2d214dfaa3e 100644
> >> --- a/drivers/media/platform/davinci/vpif.c
> >> +++ b/drivers/media/platform/davinci/vpif.c
> >> @@ -26,6 +26,7 @@
> >> #include <linux/pm_runtime.h>
> >> #include <linux/spinlock.h>
> >> #include <linux/v4l2-dv-timings.h>
> >> +#include <linux/of_graph.h>
> >>
> >> #include "vpif.h"
> >>
> >> @@ -423,7 +424,9 @@ EXPORT_SYMBOL(vpif_channel_getfid);
> >>
> >> static int vpif_probe(struct platform_device *pdev)
> >> {
> >> - static struct resource *res;
> >> + static struct resource *res, *res_irq;
> >> + struct platform_device *pdev_capture, *pdev_display;
> >> + struct device_node *endpoint = NULL;
> >>
> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> vpif_base = devm_ioremap_resource(&pdev->dev, res);
> >> @@ -435,6 +438,58 @@ static int vpif_probe(struct platform_device *pdev)
> >>
> >> spin_lock_init(&vpif_lock);
> >> dev_info(&pdev->dev, "vpif probe success\n");
> >> +
> >> + /*
> >> + * If VPIF Node has endpoints, assume "new" DT support,
> >> + * where capture and display drivers don't have DT nodes
> >> + * so their devices need to be registered manually here
> >> + * for their legacy platform_drivers to work.
> >> + */
> >> + endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
> >> + endpoint);
> >> + if (!endpoint)
> >> + return 0;
> >> +
> >> + /*
> >> + * For DT platforms, manually create platform_devices for
> >> + * capture/display drivers.
> >> + */
> >> + res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> >> + if (!res_irq) {
> >> + dev_warn(&pdev->dev, "Missing IRQ resource.\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture),
> >> + GFP_KERNEL);
> >> + if (pdev_capture) {
> >> + pdev_capture->name = "vpif_capture";
> >> + pdev_capture->id = -1;
> >> + pdev_capture->resource = res_irq;
> >> + pdev_capture->num_resources = 1;
> >> + pdev_capture->dev.dma_mask = pdev->dev.dma_mask;
> >> + pdev_capture->dev.coherent_dma_mask = pdev->dev.coherent_dma_mask;
> >> + pdev_capture->dev.parent = &pdev->dev;
> >> + platform_device_register(pdev_capture);
> >
> > Don't both of these (vpif_capture and vpif_display) depend on platform data?
> > Or do I miss something?
>
> The driver can (continue to) work in legacy mode with platform_data. In
> that case, there is no VPIF DT node (or a node without endpoints).
>
> However, with recent changes, it can also work in DT mode, where the
> VPIF node and endpoints used for display/capture come from DT, in which
> case these nodes are created an don't depend on platform_data at all.
>
> Hope that clarifies things, and thanks for the review,
Oh, I think I missed the fact that what is parsed from DT is still referred
to as platform data in the driver. (Both of the drivers are testing if
dev->platform_data is non-NULL twice in a row. Unrelated to this patch, just
FYI.)
How do the newly created child devices get their OF nodes?
If endpoint is non-NULL, it needs to be put using of_node_put().
--
Regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
[not found] ` <CGME20170617065837epcas5p49ffbc2fd9831b822ab6e368b86049025@epcas5p4.samsung.com>
@ 2017-06-17 6:58 ` Sylwester Nawrocki
0 siblings, 0 replies; 7+ messages in thread
From: Sylwester Nawrocki @ 2017-06-17 6:58 UTC (permalink / raw)
To: linux-arm-kernel
On 06/09/2017 06:10 PM, Kevin Hilman wrote:
> The davinci VPIF is a single hardware block, but the existing driver
> is broken up into a common library (vpif.c), output (vpif_display.c) and
> intput (vpif_capture.c).
>
> When migrating to DT, to better model the hardware, and because
> registers, interrupts, etc. are all common,it was decided to
> have a single VPIF hardware node[1].
>
> Because davinci uses legacy, non-DT boot on several SoCs still, the
> platform_drivers need to remain. But they are also needed in DT boot.
> Since there are no DT nodes for the display/capture parts in DT
> boot (there is a single node for the parent/common device) we need to
> create platform_devices somewhere to instansiate the platform_drivers.
>
> When VPIF display/capture are needed for a DT boot, the VPIF node
> will have endpoints defined for its subdevs. Therefore, vpif_probe()
> checks for the presence of endpoints, and if detected manually creates
> the platform_devices for the display and capture platform_drivers.
>
> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] [media] davinci: vpif: adaptions for DT support
2017-06-09 16:10 [PATCH v2] [media] davinci: vpif: adaptions for DT support Kevin Hilman
` (2 preceding siblings ...)
[not found] ` <CGME20170617065837epcas5p49ffbc2fd9831b822ab6e368b86049025@epcas5p4.samsung.com>
@ 2017-06-20 12:55 ` Lad, Prabhakar
3 siblings, 0 replies; 7+ messages in thread
From: Lad, Prabhakar @ 2017-06-20 12:55 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jun 9, 2017 at 5:10 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> The davinci VPIF is a single hardware block, but the existing driver
> is broken up into a common library (vpif.c), output (vpif_display.c) and
> intput (vpif_capture.c).
>
> When migrating to DT, to better model the hardware, and because
> registers, interrupts, etc. are all common,it was decided to
> have a single VPIF hardware node[1].
>
> Because davinci uses legacy, non-DT boot on several SoCs still, the
> platform_drivers need to remain. But they are also needed in DT boot.
> Since there are no DT nodes for the display/capture parts in DT
> boot (there is a single node for the parent/common device) we need to
> create platform_devices somewhere to instansiate the platform_drivers.
>
> When VPIF display/capture are needed for a DT boot, the VPIF node
> will have endpoints defined for its subdevs. Therefore, vpif_probe()
> checks for the presence of endpoints, and if detected manually creates
> the platform_devices for the display and capture platform_drivers.
>
> [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Cheers,
--Prabhakar Lad
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-06-20 12:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-09 16:10 [PATCH v2] [media] davinci: vpif: adaptions for DT support Kevin Hilman
2017-06-15 20:12 ` Kevin Hilman
2017-06-16 8:43 ` Sakari Ailus
2017-06-16 17:49 ` Kevin Hilman
2017-06-16 21:10 ` Sakari Ailus
[not found] ` <CGME20170617065837epcas5p49ffbc2fd9831b822ab6e368b86049025@epcas5p4.samsung.com>
2017-06-17 6:58 ` Sylwester Nawrocki
2017-06-20 12:55 ` Lad, Prabhakar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).